led_keyboard patch is not only fw-dependent, but also HW specific.

[frickler24]

Normally a firmware version >= 2.05 runs with the new compare array.
Up to now there is a 2.04 running in K70 RGB Lux with the same behavior.
So a detection part is included in led_keyboard.c

[frickler24]

references an issue found while testing #89

[tatokis]

I'll be downgrading the firmware on my keyboard tomorrow to test this.

[frickler24]

OK!

[hevanaa]

I've added this patch in addition to the one from #89 (so testing + #89 + #96). What am I looking for here?

Here is the boot log:
boot_89_96.txt

(just for the record: keyboard is K70 LUX (non-RGB) with fw 2.0.4)

[frickler24]

@hevanaa please look at the following lines (which are a bit a surprise to me, because they shouldn't be there...)

mar 01 19:16:24 yggdrasil ckb-daemon[809]: [I] Starting input thread for /var/run/ckb1
mar 01 19:16:25 yggdrasil ckb-daemon[809]: [E] loadrgb_kb (led_keyboard.c:231): Bad input header
mar 01 19:16:25 yggdrasil ckb-daemon[809]: [E] loadrgb_kb (led_keyboard.c:234): color = 0, i = 1, mode = 0
mar 01 19:16:25 yggdrasil ckb-daemon[809]: Input(Antwort): 0e ff 01 3c ff ff ff ff
mar 01 19:16:25 yggdrasil ckb-daemon[809]: Output (Frage): ff 01 3c 00

[hevanaa]

For this particular keyboard, it should be P_K70_LUX_NRGB on row 226. Let me try again.

[frickler24]

@hevanaa just to be sure: Your Keyboard is a non RGB. Does it have monochrome lights?

[hevanaa]

Yes, this is non-RGB, with only blue lights. I guess same light patterns can be created as with RGB keyboards (except that it is blue only). So it doesn't really make sense to treat it differently from an RGB keyboard (on low level, that is). The code is a bit messy from this standpoint.

[hevanaa]

OK, with "&& (kb->product == P_K70_LUX_NRGB)" it works better. Here is latest boot log:
boot_89_96_2.txt

[frickler24]

looks good!
We have monochrome as a special form (the code divides into RGB, monochrome and no lights).
The code for NRGB and RGB is similar, bot not identical.
So I added your KB to the monochrome definition and changed the line as you did.
Comes in a few minutes.

[frickler24]

OK, it is pushed into the same branch as we had before:

To git@github.com:frickler24/ckb-next.git
   c8ff495..b1d65e3  testing-led_bug_K70RGBPro -> testing-led_bug_K70RGBPro

Please try again with this additional entry in usb.h.

[hevanaa]

Yes, it works. But the "light pattern" functionality is different now. E.g. the Rainbow demo is barely visible at all now, it only changes brightness by a really small amount, almost unnoticeable. I tried this a few days ago to put this KB in the Monochrome list and thought that it was broken because of this, but now when I'm really looking, I see that the brightness changes.

[tatokis]

If I recall correctly, we just decided to merge it in the testing branch as a normal RGB keyboard, as it seems to discard the colour packets with no issues. Should be able to find the PR and look at the conversation.

[hevanaa]

Yes, that's what I thought.

[hevanaa]

It was this: #87

[frickler24]

OK, I did not read that issue carefully. So I will change it back and comment it instead.

[hevanaa]

It definitely doesn't belong in the current monochrome list. I prefer the previous behaviour. Maybe in its own list then, together with the P_K70_RFIRE_NRGB variant (and possibly other non-RGB variants?).

[frickler24]

For now I changed it back to handle it as a color device:
b1d65e3..205800c testing-led_bug_K70RGBPro -> testing-led_bug_K70RGBPro

[ghost]

@RaymondSchnyder do you have 2.04 firmware on your Strafe non-RGB?

[cactushydrocodone]

@light2yellow I have the 2.04 firmware on my Strafe non-RGB

[ghost]

@RaymondSchnyder then please test this. The process of the installation is the same, just clone this branch instead of any other.

[webdev23]

@light2yellow Same identical bug here, leading to black freezing. Tested on the branch master and testing-led_bug_K70RGBPro as you asked.

[I] Connecting Corsair Gaming K70 LUX RGB Keyboar at /dev/input/ckb1
[I] Starting input thread for /dev/input/ckb1
[E] loadrgb_kb (led_keyboard.c:224): Bad input header
[E] loadrgb_kb (led_keyboard.c:228): color = 0, i = 1, mode = 0
Input(Antwort): 0e ff 01 3c ff ff ff ff
Output (Frage): 0e ff 01 3c
[E] os_usbrecv (via led_keyboard.c:233): Connection timed out
[W] _start_dev (device.c:45): Unable to load hardware profile
[I] Setup finished for /dev/input/ckb1

It had works with the ckb-next master branch driver until reboot, on a fresh install. My keyboard was working fine with an older driver of ckb, but not the one given on the ckb master branch.

Anyway, beside the alerts, and while ckb-next isn't working (black keys on program launch) with the driver Corsair RGB driver beta-v0.2.7 from the testing branch, it works smooth with my little workaround phpCorsair.
To try a rainbow from the command line.(dependencies: php7.0 and curl)

php <(curl -s https://raw.githubusercontent.com/webdev23/phpCorsair/master/rainbow)

[frickler24]

@RaymondSchnyder could you please post the content of the file /dev/input/ckb1/features ?
The ckb gui tries to determine the type of interface on that content.
In my case it is corsair k95 rgb pollrate bind notify fwversion fwupdate

[cactushydrocodone]

@frickler24
Im not at my arch system right now, i will post it during the day :)

[webdev23]

The firmware is labeled 2.04, this should be it. This is K70 lux RGB.

fd8763 does not works either.

Thanks for the diff link.

/dev/input/ckb1 09017011AEB8180455B92567F5001946 Corsair Gaming K70 LUX RGB Keyboard

[frickler24]

And lsusb gives a 0x1b33 for the device?

[webdev23]

This seems correct:
Bus 001 Device 003: ID 1b1c:1b33 Corsair

[frickler24]

OK. Because some debug outputs have changed, please send me the logging info from ckb-daemon again (as you sent Mar 14.).

[webdev23]

I saw the ckb1 reborn every time after killing him, so i removed the pid file in /dev/input/ckb0 folder.
And from my other keyboard when launching sudo ckb-daemon this goes to an infinite loop.
First time i saw it.
Then i used fuser.

Now the log say:
ckb: Corsair RGB driver beta-v0.2.7
[I] Root controller ready at /dev/input/ckb0
[I] Connecting Corsair Gaming K70 LUX RGB Keyboard at /dev/input/ckb1
[I] Starting input thread for /dev/input/ckb1
[E] os_usbrecv (via firmware.c:15): Device or resource busy
[W] _start_dev (device.c:38): Unable to load firmware version/poll rate
[I] Setup finished for /dev/input/ckb1
[E] os_sendindicators (usb_linux.c:216): Device or resource busy
[E] os_sendindicators (usb_linux.c:216): Device or resource busy
[E] os_usbsend (via device_keyboard.c:38): Device or resource busy
[I] Attempting reset...
[E] os_usbsend (via device_keyboard.c:38): Device or resource busy
[E] os_usbsend (via device_keyboard.c:38): Device or resource busy
[E] os_usbsend (via device_keyboard.c:38): Cannot send after transport endpoint shutdown
[E] os_usbsend (via device_keyboard.c:38): Cannot send after transport endpoint shutdown

[frickler24]

seems that your service is still running.
pls try systemctl stop ckb-daemon
or sudo service ckb-daemon stop

[ghost]

@webdev23
To do a clean, proper test:

sudo systemctl stop ckb-daemon
sudo killall ckb
sudo killall ckb-daemon
sudo ckb-daemon

[frickler24]

and for a real proper test, add
sudo rm -rf /dev/input/ckb*
before startting the daemon again.
But be careful with typing this cmd - a space at the wrong position will erase your root device.

[webdev23]

Thank you. Yeah rm is risky, i force myself to use wipe instead.

Now ckb-daemon start without errors:
sudo ckb-daemon
ckb: Corsair RGB driver beta-v0.2.7
[I] Root controller ready at /dev/input/ckb0
[I] Connecting Corsair Gaming K70 LUX RGB Keyboard at /dev/input/ckb1
[I] Starting input thread for /dev/input/ckb1
[I] Setup finished for /dev/input/ckb1

The keyboard stay darken off.

[frickler24]

Does your KB have 256 colors or 16.8 Mio?
And at what position is your poll rate switch?
Did you connect one usb cable or both?

[webdev23]

While not sure how many, it is clearly more than 256, or 64000 with no doubt.

[tatokis]

But the driver is fine, as i use it in my scripts.
Are you running the ckb GUI at all? You kinda need that for anything to happen

[webdev23]

I usually left it to 1, both usb are plugged in, different combinations had been tried. And not both combinations works. I don't think it is a power failure.

@tatokis No i wrote a wrapper in php, the basic example is https://github.com/webdev23/phpCorsair/blob/master/rainbow
The ckb is closed when i run it. It is just giving info directly to the ckb-daemon alone, by sending commands to > /dev/input/ckb1/cmd
I did that because i am way more productive in php, and the ckb-daemon docs was not too bad.
This said it could be very nice if can found a way to run shell scripts like that #! inside ckb.
It can be very creative, because most of us are mostly web devs.

Thanks guys.

[frickler24]

So please check the ckb gui. It is clear, that your KB stays black if you do not use it.
All dynamic color changes are controlled by the gui, it does a frequent update of color information up to 60 times per second.

If it runs, I will update the testing branch with the last change I made for the patch today and close the issue.

[webdev23]

No, my friend, of course, i am talking about ckb.
If i open it -> black keyboard
If I run echo rgb FFFF00 > /dev/input/ckb1/cmd in the terminal, the keyboard is full yellow.

The ckb says that k70 lux rgb is connected.

[frickler24]

OK, then we have corrected the daemon now, but we need a look on the client.
If you call ckb from a terminal without any argument, what debug infos do you get from the gui?

[webdev23]

ckb
Path to settings is "/home/zen/.config/ckb/ckb.conf"
Scanning "/usr/lib/ckb-animations/ckb-gradient"
Scanning "/usr/lib/ckb-animations/ckb-heat"
Scanning "/usr/lib/ckb-animations/ckb-mviz"
Scanning "/usr/lib/ckb-animations/ckb-pinwheel"
Scanning "/usr/lib/ckb-animations/ckb-rain"
Scanning "/usr/lib/ckb-animations/ckb-random"
Scanning "/usr/lib/ckb-animations/ckb-ripple"
Scanning "/usr/lib/ckb-animations/ckb-wave"
Downloaded new firmware list. 12 entries found.

[frickler24]

That look good.
What happens, if you change the lightning in the gui for one or more keys? Any meaningful debug output?

[webdev23]

Nothing, including creating new modes and profiles.
Note while clicking save to hardware, it light up with the settings given on the gui, but go dark in less than a second.

[tatokis]

Try deleting or moving /home/zen/.config/ckb/

[frickler24]

I've never seen that effect.
Please let's try to create a new config file:
stop ckb (use Settings-Tab + Quit)
mv /home/zen/.config/ckb/ckb.conf{,.20170515}
start ckb

[frickler24]

Hi @tatokis - same idea :-)
Means: In the moḿent no other idea. Communication between client and daemon i ok, he has seen some light for a moment.
Never had this effect

[tatokis]

@frickler24 This could happen if the brightness is set to 0%, saving to hardware temporarily switches the keyboard to hardware mode (making it read the rgb data from its eprom/flash memory), and then shortly after switches it back to software mode for ckb to control it.

Brightness settings can not be saved in the keyboard itself, which is possibly why it turns on momentarily.

[frickler24]

Ah, thanks, I've seen the HW-mode/SW-mode switching in the code when updating the profiles, but now I understand the reason for it.

[webdev23]

This is okay guys, i just removed the config file, the gui now ask my default layout and the keyboard light up.

Thanks. GG

[frickler24]

OK, Thanks for debugging it!
We should mention this as a known bug in the appropriate file.
@tatokis I've seen, that VERSION in branch testing is still at 0.2.7.
When I now update the branch, should I update to 0.2.8 or is there a special reason for staying on the older version?

[tatokis]

@frickler24 ever since we cut a release, the testing branch went out of sync with master and there were many conflicts.
Me and @light2yellow were discussing merging the two branches again, resolving all conflicts, and completely removing testing to prevent such issues in the future.

Not really sure what to do, to be honest.

[frickler24]

Yes, I've seen the discussion about testing / master.
Because yesterday I merged into testing (and today another PR), I need to update this branch also.