Force the usage of usb driver for an specific device

Question

I'm facing a really odd issue with a Wacom STU-530 device on Ubuntu 16.04.

If I connect the tablet in any port it will start as USB 1.1 (really slow) because it loads the driver: ohci-pci

[  230.708046] usb 4-1: new full-speed USB device number 3 using ohci-pci
[  230.883203] usb 4-1: New USB device found, idVendor=056a, idProduct=00a5
[  230.883217] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  230.883226] usb 4-1: Product: STU-530
[  230.883234] usb 4-1: Manufacturer: Wacom Co.,Ltd.
[  230.883242] usb 4-1: SerialNumber: 8LZQ000683
[  230.896179] input: Wacom Co.,Ltd. STU-530 Pen as /devices/pci0000:00/0000:00:12.0/usb4/4-1/4-1:1.0/0003:056A:00A5.0009/input/input20
[  230.896691] wacom 0003:056A:00A5.0009: hidraw2: USB HID v1.10 Device [Wacom Co.,Ltd. STU-530] on usb-0000:00:12.0-1/input0

But if I instead connect a (really cheap usb hub) and then the tablet into the usb hub, the correct driver ehci-pci is configured and the tablet runs at usb 2.0:

[  335.120117] usb 1-1.1: new full-speed USB device number 5 using ehci-pci
[  335.214488] usb 1-1.1: New USB device found, idVendor=056a, idProduct=00a5
[  335.214501] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  335.214511] usb 1-1.1: Product: STU-530
[  335.214519] usb 1-1.1: Manufacturer: Wacom Co.,Ltd.
[  335.214527] usb 1-1.1: SerialNumber: 8LZQ000683
[  335.221870] input: Wacom Co.,Ltd. STU-530 Pen as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.0/0003:056A:00A5.000A/input/input23
[  335.222255] wacom 0003:056A:00A5.000A: hidraw2: USB HID v1.10 Device [Wacom Co.,Ltd. STU-530] on usb-0000:00:12.2-1.1/input0

Is there a way to force the usage of ehci-pci when I connect the tablet? Maybe using udev?

PD: The device runs at 2.0 in other computers without problem.

ADDITIONAL INFORMATION:

I'm executing the DemoButtons (Java) from the Wacom's SDK. It just open a window and let me interact with the tablet.

Cases:

1) If I connect directly the tablet to the "PC" the software won't work, will end with error LIBUSB -99 Error.

2) If I connect the tablet through the cheap USB 2.0 HUB the software will run without problems.

3) The computer has (2/two) USB 3.0 ports, I've repeated the first two tests on them and the tablet only will work if the hub is in the middle.

When connecting the tablet to the 3.0 port the BUS Class = root_hub with driver xhci_hcd will handle the device but the driver will be usbhid / 12M (so the device is still USB 1.1).

I've already fixed the Wacom's software by changing an internal timeout of LIBUSB_BULK_TRANSFER so the software will run correctly no matter if the tablet is connected directly or through the hub.

The thing is, I would need to find a way to understand why the device is running slower in this hardware since from 3000 computers only in ~350 this error appears, all of them are the same model, same version, same vendor, same O.S (like clones).

Maybe is something related to an specific chiptset or low quality usb chipset?

All the info from hwinfo, lsusb, lsusb -t are the same in the computers (compared by vimdiff).

WHAT I KNOW:

• libusb_bulk_transfer is running slower (for some unknown reason)
• The O.S is handling the device as USB 1.1 when it clearly works as 2.0
• In about 3,000 PC's with same HW/SW this error only will be present in about ~350. (Same bios versions/same O.S and software installed).

Regards.

M.

Answer 1

First of all, the reason for this behaviour seems to be USB specific. Kernel.org (here) states the following:

When USB 1.1 devices plug into USB 2.0 hubs, they interact with the EHCI controller through a “Transaction Translator” (TT) in the hub, which turns low or full speed transactions into high speed “split transactions” that don’t waste transfer bandwidth.

Since there is no specific USB 1.0 module (the USB 2.0 will handle USB 1.1 devices), which could be black-listed, this is no option.

The product page states the device as USB 2. (here) Since the device is not USB 3, we cant unload all modules and load the XHCI first, to let it grab the device.

Please try: udevadm trigger And see, if it get recognized correctly.

And don't forget to upvote my effort! :p

Answer 2

Well... I've tried many things:

• Running java with extra parameters to see if the application would run correctly
• Tried to update the BIOS of the device (but it is too old and has no updates)
• Looked for a way to disable the ohci driver of being taken, achieved it by using udev but the device won't be recognized or would use another driver. (There would be nosense to make the built-in modules of *HCD, the result would be exactly the same)

Finally I gave up and went for the workaround, setting a timeout for the usb bulk operations of libusb on the libwgssSTU.so driver, the Wacom Demo Buttons would fail by setting:

EncodingMode.EncodingMode_24bit_Bulk

I've passed our foundings (I've worked on this with a co-worker) to the Wacom Developer Support by JIRA and they would add the change to the source code of the libwgssSTU.so driver, the new driver works fine but takes 2 to 3 seconds more of delay in this particular hardware.

I wasn't able to find out why the software would run randomly 1/60 or 1/30 or 1/45 on the machine, but at least I found the workaround.