It might be that the driver for the chip that's running the USB 3.0 ports isn't compiled into kernel. You can check the chipset information using lspci
command:
$ /usr/sbin/lspci |grep -i usb
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)
Then check kernel configuration whether the USB 3.0 driver is indeed enabled...
Ok, turns out the answer was staring me in the face.
Firstly, whether using our custom driver, or using the generic one that normally takes over the device, it's still all ultimately controlled by HID, and not USB.
Previously I tried to unbind it from HID, which is not the way to go. HID has sub-drivers, the one that takes over devices that have no specialized driver is called generic-usb. This is what I needed to unbind from, before binding to hid-g19. Also, I needed to use the HID address which looks like "0003:046d:c229.0036" and not the USB address which looks "1-1.1:1.1".
So before rebinding I would see this on dmesg:
generic-usb 0003:046D:C229.0036: input,hiddev0,hidraw4: USB HID v1.11 Keypad [Logitech G19 Gaming Keyboard] on usb-0000:00:13.2-3.2/input1
Then I do:
echo -n "0003:046D:C229.0036" > /sys/bus/hid/drivers/generic-usb/unbind
echo -n "0003:046D:C229.0036" > /sys/bus/hid/drivers/hid-g19/bind
And then I see on dmesg:
hid-g19 0003:046D:C229.0036: input,hiddev0,hidraw4: USB HID v1.11 Keypad [Logitech G19 Gaming Keyboard] on usb-0000:00:13.2-3.2/input1
So like I said, staring me in the face, because the two key pieces of information are the first two things on the line when the device binds...
Best Answer
I’ve been able to do this with an udev rule, after some trickery (and using
lsusb
to find out the vendor and product ID of the device in flash mode):This rule is triggered when an NXT brick is plugged in while in flash mode, or put into flash mode while plugged in. It does not prevent
cdc_acm
from grabbing it, but immediately after tells it to release the device, sofwflash
can access it.I have not found out what the
:1.0
is, and why use that and not:1.1
which also shows up in sysfs. However, I wanted to share a working (for me) solution. Environment: Debian unstable as of end of October, 2014 (i.e. pretty much Debian jessie).