Crashes G910 firmware about g810-led

[MatMoul]

What your distrib ?

[CReimer]

Arch Linux x86_64

[MatMoul]

How do you install g810-led?
Now you have my package in aur : g810-led-git
Before installing the aur version, uninstall your current version with make uninstall

[CReimer]

Yeah I just noticed that a few minutes ago. I'm now using your AUR g810-led-git package. Same problem.

[MatMoul]

Can you more discribe symptom of your crash...
Do you have recently maked a firmware upgrade with Windows (grrr).

[CReimer]

Well not between switching g810-led versions. It works with the above mentioned commit. But not with any commit afterwards. Last firmware update in windows was at least two weeks ago.

[MatMoul]

After this commit, I have full refactored the code
It's possible that a byte is false for the g910 in the new refactored version
But is very strange that your keyboard firmware crash
What do you mean by firmware crash ? (keyboard is dead, sending more command don't work, ...)

[CReimer]

All colors except the G logo and the G910 logo are off
It usually keeps like that. Sometimes it switches back to the rainbow effect.

After some more testing I can also switch the color of the logo group but it only does that if I disable the LEDs with the keyboard button and reenable them.

[CReimer]

I just set g810-led up as a project in CLion. If you want me to debug anything... I should be able to do that now.

[MatMoul]

The "disable the LEDs with the keyboard button and reenable them" is a sign that commit don't work...

[MatMoul]

It seem a bug...

[MatMoul]

Try to make your update, new version here

[CReimer]

Thanks. Now it works. But only with libusb. hidapi seems to be broken

[MatMoul]

What's your problem with hidapi, it's the new implementation...

[CReimer]

It works. But it's not stable. A simple -a FF0000 leaves about one third of my keys with the wrong color
After multiple runs it finally changes them all

[MatMoul]

Yes, what's your CPU ?
In the sendDataInternal function of Keyboard.cpp on line 509, I have set the value to 500...
It's a possible bug for more perf cpu than mind

[CReimer]

Intel(R) Core(TM) i5-4690.
a usleep(1000) works a lot better. But I can still trigger an error with a simple while true loop which starts g810-led multiple times very fast.

[MatMoul]

I have not understood everything but the usleep and the CPU is a key...

[MatMoul]

Can you give me the result of time g810-led -a ff0000 with your CPU and usleep 1000

[CReimer]

This should help you understand what I tried to explain before: https://gist.github.com/CReimer/ea69e571945cc874c10f54b85aafa517

And here's the time output

real	0m0,018s
user	0m0,000s
sys	0m0,000s

[MatMoul]

I looked your link and when I launch the script with my G810, it's work and ctrl+c don't breack anything...

For your result : Less than 0.02... try to increase usleep

[CReimer]

That doesn't help. Even very extreme values like 10000 don't fix it. It looks like multiple commands are overlapping.
usleeps don't solve anything here and I can't find anything in hidapi's API documentation which could help fix this.
I'll take a closer look at it tomorrow. Thanks.

[MatMoul]

Thanks for your return, I must also watch if I don't have an other error in g910 data...

[CReimer]

I can't find anything. I think it's a bug in hidapi. It shouldn't be possible that multiple commands to the keyboard overlap. But for me it looks like that.

I'd stick with libusb. It's a well known mature library. If it's too slow, there might be some way to improve that.

[MatMoul]

If you have time, you can test this three options (one at a time) :

• In makefile, remove -O2 on line 2.
• In Keyboard.cpp, in sendDataInternal on line 509 and 512
  comment the usleep
  and replace the 0 by a 1 at the end of hid_read_timeout
• In Keyboard.cpp, in setKeys line 316
  decrease the max key sent at a time. sample :
  const uint8_t maxKeyCount = (data_size - 8) / 4 - 1;

For libusb it's very slow because the libusb_detach_kernel_driver function take 100ms and can not be skipped.

[CReimer]

Hmm. That fixed it. Great.

[MatMoul]

Cool but what option ?
It's just a tempory patch but I need to find the real bug.

[CReimer]

OK. Finally tried these on it's own.

1. Doesn't change anything. BTW. -O3 works quite well too
2. This does the trick. It's not 100% reliable, but it's at least changing all key colors and doesn't leave a few out.
3. Doesn't change anything.

With not 100% reliable I mean, that if i run g810-led -a ff0000 on the console and quickly press arrow up and enter. It crashes and tells me to try the libusb version.

[MatMoul]

The usleep is the devil part of the code...
Need to find best solution

[MatMoul]

With not 100% reliable I mean, that if i run g810-led -a ff0000 on the console and quickly press arrow up and enter. It crashes and tells me to try the libusb version.

This problem is strange ...
Does anyone else encounter this problem?
Bug or not bug?

usleed stay an obscure solution...

[MatMoul]

@CReimer I investigate but I can not reproduce...
What's your distro ?

[CReimer]

Arch Linux x86_64

[MatMoul]

Thanks, Same as me...
I will try to test on other computer than mine.

[CReimer]

With all the tinkering for #39 I stumbled upon this a few times. And I think I found a solution.

Remove the usleep(500) in line 565 of Keyboard.cpp
And replace the 0 at the end in line 568 with a 1.

This makes hidapi wait for something to read for at least 1ms. Which seems to be enough.