Closed dlk3 closed 5 years ago
After further testing, this seems to be a byproduct of how conky (a system monitor utility) is started. To restate the way in which I'm using OpenCorasirLink: conky calls a Python script which calls the "sudo OpenCorsaidLink --device=0" command. The script parses the output from OpenCorairLink and returns it to conky for display. Conky gets started on my desktop automagically by XFCE when my session starts, it's part of the memorized session that XFCE restores for me at login. This is the scenario where I see this outpouring of dmesg messages. I do not see these messages when I run OpenCorsairLink directly from the command line, when I run my Python script, nor when I kill conky after logging in and restart it. So something about the timing of when conky/OpenCorsairLink gets started seems to be causing the issue.
So now I've implemented a different process that waits 30 seconds after login before it starts up conky calling OpenCorsairLink and with that change I'm no longer seeing these dmesg messages. I guess there's no need to pursue this any further so I'll close this.
Every time I call OpenCorsairLink I get a series of 22 identical dmesg messages like this: "[3972.155922] usb 1-2: usbfs: process 26651 (OpenCorsairLink) did not claim interface 0 before use"
OpenCorsairLink returns the status information expected so I don't know that this error is causing me any problems. I ran across this when investigating the X11 desktop freeze-ups I've been experiencing since I built this new system last week. OpenCorsairLink is being called from a script that is in turn called by the conky system monitoring utility every 5 seconds.
I am using the latest code from the main branch of OpenCorsairLink. I am using the libusb RPM that comes with my distribution, Fedora 29, libusb version 0.1.5.
The cooler I am using is the Corsair H150i Pro. OpenCorsairLink identifies it correctly.