STRAFE non-RGB: "Unable to read endpoint count from udev" #138
Comments
|
OS? Does ckb say anything? Did you upgrade the firmware while on windows? |
|
Hey sorry to hijack this thread but I've been experiencing the same issue using the Corsair Strafe Mechanical Keyboard, whenever I restart Ubuntu it is no longer detected and I need to reinstall the driver and restart in order to fix the issue. It could possibly be something to do with my Ubuntu install but if you have any insight please help me haha. To clarify I've also tried switching the ports, re running the software, and replugging back in to no avail. |
|
Does it say not detected or is the daemon not running? |
|
Alright I ran the sudo service check and it's running for sure. I'm coming to the realization that I didn't correctly configure my dual boot and having both Windows 10 and Ubuntu running off the same drive means I'm unable to access the OS hard drive because Windows Hibernates it after Logging out. To me it seems like the issue is the software tries to Install itself but can't access the directories (neither can I) so that would explain why it occasionally works after restarting. I'll be looking into how to stop Windows from locking me out of my drive but if you had any insight or next step that would also be greatly appreciated. Thanks for you help! Edit: I'm an idiot I just need to completely shut down Windows and not quick restart it :P Logs If You're Interested: Loaded: loaded (/usr/lib/systemd/system/ckb-daemon.service; enabled; vendor preset: enabled) Apr 29 12:00:46 xcrysdale-MS-7917 systemd[1]: Started Corsair Keyboard Daemon. |
|
@Xcrysdale This does not look good: The message means that there is a problem to identify the amount of endpoints available from your device. Could you please post the content of the following files: |
|
It makes sense that it couldn't read any endpoints, because the actual
path it tried to access does not exist.
This can be seen later on at
Apr 29 12:00:46 xcrysdale-MS-7917 ckb-daemon[4208]: [E] os_setupusb
(usb_linux.c:296): Failed to claim interfaces: No such file or directory
|
|
@tatokis The perror message means, that the ioctl could not find the endpoint: @Xcrysdale So we may also need the output of ckb-dev-detect |
|
Remind me again, why do we assume endpoints?
If we assume them and they don't really exist, then there's no way we
can do anything with them later on.
|
|
That's a really good question. The original code greps the number of endoints via a library function which returns a string with the number of EPs. The function in ckb-daemon assumed always a valid number (2, 3 or 4), but one of our incidents has shown " " as retval. |
|
Here's the file you said you may need, one issue I had been experiencing which could have been effecting the install as well would be the fact that windows Hibernated the OS drive when I restarted instead of hard-shutdown but I've resolved that, and the Ckb is still spotty in detecting my Keyboard. |
|
It looks like from the report the Keyboard doesn't exist, but I've had it working before so I'm a bit confused at the moment. Next time I have it working I'll run the reporter and upload the file but for the moment it won't budge. |
|
The folder at /dev/input/ckb0 contains the following files: Connected.txt (Blank text file) Unfortunately I don't have a ckb1 folder. Also turns out its Outputs of running "journalctl | grep ckb" Sorry for the horrid formatting I'm currently typing using the mouse :) |
|
The report talks about #define P_STRAFE_NRGB 0x1b15Err, what? |
|
Just got it working again, anything you want me to run? |
|
Some more logs with working Keyboard: |
|
@Xcrysdale
This doesn't look healthy. @Sycocylin |
ghost
changed the title
|
Yeah I've tried a new USB port and now it's working. But I've tried this method before and it doesn't last so I'll keep you updated. And the ckb1 folder was just created if you would like the contents of that. It's still registering the keyboard as Input33 and input34, should I attempt a reboot and see if the setting reset or the keyboard fails? And sorry for hijacking the thread as I said before I intended my post to be a quick question but as of now there doesn't seem to be an end in sight. |
|
You definitely should. And after the reboot show us Regardless of the future pace of the discussion, I'm closing this as it's working right now (although poorly). |
|
Alright I know this is closed but; after reboot all setting were lost and the keyboard is not detected. Since it seems like I'm taking this in circles I'll stop taking up your time and do some more research. Apologies for all of this I'm completely new to Ubuntu and Linux as a whole so I need to take the time to look into whether or not I am using BIOS mode. |
|
Thanks for all your guys help, I really appreciate it :) |
|
@Xcrysdale If lsusb can't see your keyboard, it's definitely not a software issue, and there's nothing we can do about it. And no, never EVER turn BIOS mode on with the daemon running. Also, make sure your keyboard is running the latest firmware version. Try the latest code from the testing branch, too. |
|
@Xcrysdale Also, I see this line in your log: This is a very old version of ckb, you should reinstall current After you figured it out and the keyboard is definitely not in BIOS mode, let's try everything once again:
The |
ghost
reopened this
|
@light2yellow on the contrary, it is unlikely that the dev detect script is at fault, since even if Since there are no mentions of the hid driver, it is much more likely that the computer can't properly talk to the keyboard. Output from mine for comparison |
|
Alright here's the ckb-dev-detect output file: Then, I ran the
Finally I switched USB ports to no avail, still no detection. EDIT: I installed and ran the testing version of ckb as well and ran the ckb-dev-detect for it as well and it gave me different information. Such as the "Corsair Strafe" is no longer detected at the bottom of the page. I'm a bit confused as I did not change anything between runs just the software version from Here's the file for comparison: |
|
I did notice when poking through the Detect file that it did see my keyboard, which is an improvement but still no endpoints it seems. I had it working yesterday out of the blue, it seems completely random to me. |
|
Does your keyboard actually work? could very well indicate hardware failure |
|
If you do |
|
The function in static char *get_dev_string_ascii(libusb_device_handle *dev, size_t size,
u_int8_t id)
{
char *buf = malloc(size);
int ret = libusb_get_string_descriptor_ascii(dev, id,
(unsigned char *) buf,
size);
if (ret < 0) {
free(buf);
return strdup("(error)");
}
return buf;
}Reading through This is definitely not an issue with Regarding the output being different - I recall there was a bug in our script and @tatokis was fixing it and it must be he didn't cherry-pick the fix onto one of the branches. He can comment this better. |
|
Nope, the same commit is in both branches. |
|
Ah, I should've made a diff before posting :) For both scripts and reports. being present in one case and missing in the other doesn't let to make any conclusions. I guess if @Xcrysdale made super-clean tests, e. g. rebooting every time, in-before manually stopping the daemon / uninstalling one version before installing the other and not overriding etc. etc. we would eventually witness equalized outputs. But it doesn't matter. The main idea is that device is still half-detected by N. B. @frickler24 was right, we should look into |
|
And to actually execute the command above with git clone https://github.com/libusb/libusb.git
cd libusb
./autogen.sh
make
cd examples
./xusb -d 1b1c:1b15 # thanks, @tatokis :) |
|
|
|
@Xcrysdale Maybe you get some hints what is going wrong if you analyze the usb communication. |
|
@tatokis you wrote
Please have a look at #89, therein is a better handling of unknown EP-connections implemented. |
|
Alright well I think it may be a hardware failure as you guys have been alluding to as literally the day I posted on this thread my GPU flat out died, and upon thoroughly cleaning the computer and changing the USB inputs for the keyboard it works first try. Very odd, but it works so you can mark this thread as resolved, thanks all for your help, you guys are truly god sends. Does the project take donations? If so i'd love to contribute for all the time you've spent helping me. Thanks again all of you guys. TL;DR @tatokis @light2yellow xcrysdale@xcrysdale-MS-7917:~/libusb$ ./autogen.sh
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:37: installing './compile'
configure.ac:29: installing './install-sh'
configure.ac:29: installing './missing'
Makefile.am: installing './INSTALL'
examples/Makefile.am: installing './depcomp'
libusb/Makefile.am:5: error: Libtool library used but 'LIBTOOL' is undefined
libusb/Makefile.am:5: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
libusb/Makefile.am:5: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
libusb/Makefile.am:5: If 'LT_INIT' is in 'configure.ac', make sure
libusb/Makefile.am:5: its definition is in aclocal's search path.
autoreconf: automake failed with exit status: 1From the error it looks like another directory error. Any insight? Once again thanks all for your help, you've been amazing! :) |
|
Closing, because seems resolved. @Xcrysdale Something about 'LT_INIT' not being defined correctly. Please refer to the installation or troubleshooting guides of |
|
@Xcrysdale |
ghost
mentioned this issue
|
@Xcrysdale Here's my output (STRAFE RGB): Looking at it I have some ideas about macOS - instead of bustling with half-working tools targeting 10.9 when it's 2017 outside, we could just advise to run |
ghost
mentioned this issue
Hi, I need help. My keyboard was working fine after a restart but I switched back to windows for a bit and now my keyboard is unrecognized and no imputs work exept for in the BIOS.
The text was updated successfully, but these errors were encountered: