Segfault with K70 RGB in BIOS mode. #48
Comments
|
@tatokis I'm wondering on the vendor and product numbers. seems to be some problems with the stack? with urbcount = 0 you get an undefined array and with this a segv. |
|
It didn't get destroyed.
What happens is that in BIOS mode, the keyboard probably doesn't expose
some endpoints.
kb->epcount ends up being set to 1.
And then, since my keyboard is an RGB one, it executes int urbcount =
IS_RGB(vendor, product) ? (kb->epcount - 1).
but since epcount = 1, it does 1-1=0, and sets urbcount to 0.
|
|
Ah, sorry, the vendor / product info is in decimal. |
|
While I did try it earlier, I tried it again. I switched the keyboard to BIOS mode at "[I] Removed device path /dev/input/ckb1". Basically, it is not an easy fix. We need to find the root cause of it. Not 100% sure, but I think it's supposed to have 3 URBs for RGB keyboards. |
|
Ah, just saw your new reply. I can probably find the relevant commits. |
|
I think this might be related ccMSC/ckb@dfc2fab |
|
Yes, this one and ccMSC/ckb@7eaf1ae. Maybe we get a runtime error in line 113 (in the for-loop with ioctl). with this we have the value kb->epcount still 1. |
|
It just keeps trying to reset the keyboard while leaving it in an unusable state. |
|
yes, I tried it also. Running normal ckb-daemon and KB with 1ms. (I have a K95RGB). If I restart ckb-daemon, I get every time the same error:``` (gdb) run |
|
Just un- / replugging KB with running daemon gives the same error |
|
Closing daemon, un- /replugging KB and then starting daemon is ok: Now I try another thing: Resetting daemon at runtime |
|
What I think happened is that with the new firmware, corsair changed the endpoints and ccMSC only updated the code for the normal (non BIOS) mode. |
|
yes, this might be the reason. |
|
I did some hack into the daemon at the point it says "... assuming...". The driver gives an empty string as number of endpoints: |
|
disconnecting the kb, waiting some seconds and reconnecting brings sometimes the still running daemon to reconnect. All depends on the return value of maybe dev is corrupt, I will check next. |
|
The kernel logging gives some hints, that the KB is not recognized correctly while the daemon is running: |
|
This is the correct kernel info when reconnecting the KB: |
|
IN the opening function setupusb, I get only the firmware number. None of the Name of the KB or the serialNo. Some ggogling gave me a hint, which might fit to our scenario: |
|
I noticed Normal: It is clear that it only exposes a single endpoint in BIOS mode, so forcing the daemon to use more than one will most likely not work. |
|
I believe that would be the best. |
|
The corsair page shows the following info belonging to switching modes while running:
|
|
For now I did some debugging info and I have a solution for the following cases:
Next two days I will do some more testing, then I'll post a PReq. There are a lot of combinations with switching modes while plugged in and switching while unplugged. |
|
Don't forget about mice.
Also, from my recent observations, unless I am mistaken, it appears that there is a K65 non rgb that exposes three endpoints.
Have a look at #31.
And since you are at it, we should ask the person in the device request thread with the rgb mousepad to see how many endpoints it exposes, and also take that into account.
Thanks for looking into this, as I don't have much time to dig into it. Much appreciated.
|
From what I've gathered so far, the urbcount isn't supposed to be 0.
This broke ever since ccMSC updated the USB handling code to work with newer firmware versions.
The text was updated successfully, but these errors were encountered: