Bug 186317

Summary: [ums] ums module not loaded by devd for Razer Lachesis mouse
Product: Base System Reporter: lorne
Component: usbAssignee: freebsd-usb mailing list <usb>
Status: Open ---    
Severity: Affects Only Me    
Priority: Normal    
Version: 10.0-RELEASE   
Hardware: Any   
OS: Any   

Description lorne 2014-02-01 04:10:01 UTC
My mouse doesn't work by default in FreeBSD 10.0-RELEASE, but works
fine after manually loading the ums module. This was not a problem
with FreeBSD 9.1-RELEASE where the ums driver was compiled in.

The Razer Lachesis exposes two interfaces:

 interface 0: class=3 (HID), subclass=0 (non-boot), protocol=2 (mouse)
 interface 1: class=3 (HID), subclass=1 (boot)    , protocol=1 (keyboard)

The intended logic of loading the ums driver is to fail at matching
entirely, and fall through to devd's nomatch blocks, which will then
load the ums module.

There are two problems with this approach:

  1. uhid will return a low priority match for all non boot protocol
     devices (3/0/*), (precisely: it explicitly ignores 3/1/1, 3/1/2,
     and quirks). We can see this behaviour in the probing of the
     Razer Lachesis mouse interface with dtrace:

     CPU     ID                    FUNCTION:NAME
       0  27731         device_probe_child:entry dev=fffff80030b73500, child=fffff80029148a00
       0  11436                 ukbd_probe:entry dev=fffff80029148a00
       0  11437                ukbd_probe:return 6
       0  48559                 uhid_probe:entry dev=fffff80029148a00
       0  48560                uhid_probe:return -100

     (here the uhid driver is selected as best match and attached)

       0  48559                 uhid_probe:entry dev=fffff80029148a00
       0  48560                uhid_probe:return -100
       0  27732        device_probe_child:return 

  2. The ums driver's contribution to etc/devd/usb.conf (via ums_devs)
     will only match boot protocol mice (3/1/2)

     nomatch 32 {
         match "bus" "uhub[0-9]+";
         match "mode" "host";
         match "intclass" "0x03";
         match "intsubclass" "0x01";
         match "intprotocol" "0x02";
         action "kldload -n ums";


I think the easiest solution is to compile in ums. A more correct
solution to allow ums to be a module would be to modify uhid_probe to
better reflect the result of ums_probe and ukbd_probe (check
hid_is_mouse and hid_is_keyboard), and relax the the ums module's
matching to only check interface class.

As I workaround, I added ums_load="YES" to /boot/loader.conf.
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:35 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped