2

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.

10
  • 1
    Is the USB hub connected to the same USB port which the tablet was connected to? Also, does the USB hub have it's own power supply?
    – bey0nd
    Mar 3, 2020 at 23:43
  • @bey0nd yes, I've tried the same port of the machine as well other ports with the same result, the usb hub doesn't have it's own power supply, is just an usb cable with 4 usb ports available. Mar 4, 2020 at 15:55
  • Is it REALLY slower, or do you indicate that by the loaded driver? Pls see my answer for clarification.
    – WGRM
    Mar 6, 2020 at 14:42
  • I have read a conversation on the kernel mailing-list. Same problem. Someone pointed out, that the device will choose the speed, so the kernel can't be the problem. But the other side, just as you, clearified that this device works anywhere else. So it might indeed be some kernel-timeout or whatever. This is way above my experience.
    – WGRM
    Mar 6, 2020 at 17:30
  • A wild guess: Try the rear usb ports. The front ones are from the box and might be of some problem.
    – WGRM
    Mar 6, 2020 at 17:33

2 Answers 2

3

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

1
  • I've added more information about the problem. Mar 6, 2020 at 17:26
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .