2

I have multiple sytems running Ubuntu 19.10.
I have a USB HID device which can be detected by each of those systems
and I am using the exact same udev rules file on all 3 of them (99-MyDevice.rules) : 

SUBSYSTEM=="usb",ATTRS{idVendor}=="XXXX",ATTRS{idProduct}=="YYYY",MODE="0660",GROUP="timothy",SYMLINK+="mydevice%n"

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="timothy"

On all 3 sytems the device correctly shows up as /dev/mydevice...

Now when I execute lsusb -t it will output the following: 

Port 4: Dev 3, If 1, Class=Human Interface Device, Driver=, 12M

Notice that the Driver is empty, although sometimes, just every now and then, it will actually load the driver (which is what I want) and output this:

Port 4: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M

When the driver is loaded like this, the software can detect and use the device.
The problem is that the driver is almost never automatically loaded.

So far I've discovered two ways to load the driver manually (with mixed success):

Method 1:
I can manually assign/bind the driver using:

echo -n "4-3:1.0" > /sys/bus/usb/drivers/usbhid/bind

At which point lsusb -t shows the driver is loaded

Port 4: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M

And then I have to modify the acl for /dev/mydevice... in order to use it.

Note that this method does not always work... feels like random at best.

Method 2:

Logically disconnect and reconnect the device to the computer.
(As opposed to physically disconnecting it). I do this by installing
VMWare and connecting the device to the guest system for a few seconds.
After the device is reconnected to the host, most of the times the driver is
bound automatically and the sofware can see/use the device.
(Note that using this method, I do not have to modify any acl)

Some notes:

  • If I use this device on a RaspberryPI with Raspbian I am not having this issue.
  • I have multiple devices of the same type and the issue occurs for all of them.
  • The issue does not occur on Windows
  • The issue does not occur on Windows inside a VM on the Ubuntu systems
  • The issue does not occur on MacOS
  • As far as I remember it did not occur on older version of Ubuntu either (not entirely sure)
  • The device itself is based on STM32F4.

Any idea how I can force the usbhid driver to be bound every time?

Update:

It turns out that if, after physically connecting the device I run
the following command, the usbhid driver is correctly bound every time. 

sudo rmmod usbhid && sudo modprobe usbhid

Note that I really have to use rmmod first,
simply running modprobe does NOT solve the issue.

So:

  1. Physically connect: Driver=, 12MB
  2. Run the command above: Driver=usbhid, 12MB

According to this Source the driver itself chooses what devices it supports.

So I am guessing the command causes the usbhid driver to re-evaluate
whether or not it can handle the device.

Now I still need to figure out how to automate it.

TimothyP
  • 121

1 Answers1

0

Create a one-line file in /etc/modules-load.d/00-my-usbhid.conf

usbhid

It should not be necessary to do this on modern systems because modules are automatically loaded, but sometimes it is still necessary to force loading of a module.

If all else fails, try adding kernel boot parameter

usbhid.quirks=0x0463:0xffff:0x08

to re-enable the NOGET quirk and see if that works.

https://www.cyberciti.biz/faq/linux-how-to-load-a-kernel-module-automatically-at-boot-time/ https://bugzilla.redhat.com/show_bug.cgi?id=1715504 https://github.com/networkupstools/nut/issues/515

hellork
  • 194
  • But this implies one of those drivers get bound instead of usbhid, however in my case no driver is loaded. – TimothyP Feb 19 '20 at 08:32
  • GlennsPref also mentions snd_hda_codec_hdmi has to be blacklisted or removed from the configuration, but I don't see why. Are there any indications in the logs why usbhid isn't loading correctly the first time? – hellork Feb 19 '20 at 20:56
  • Nothing in the logs and there is no indication it is trying to load any other driver either. So it is not the case of another driver binding it before usbhid gets a chance. – TimothyP Feb 20 '20 at 11:45
  • Is the device in question a UPS? There is a similar intermittent problem with usbhid-ups drivers here https://github.com/networkupstools/nut/issues/515 where changing the cable worked. Or the port on that one machine could be corroded. Apparently the device strings are fetched separately, so an error can sometimes occur and sometimes it works fine. There may be a retries setting in the loader scripts somewhere – hellork Feb 20 '20 at 12:49
  • Does it load with modprobe -b (use blacklist)? There are other modprobe options in the man page. --showconfig looks interesting. – hellork Feb 20 '20 at 12:55