Skip to content

L
linux
Switch branch/tag
  1. 02 Apr, 2019 2 commits
    • Hans de Goede's avatar
      HID: core: Call request_module before doing device_add · a025a18f
      Hans de Goede authored 
      Recent kernels allow the generic-hid driver to be used as fallback for
devices with a specialized driver, when the hiddev is not listed in
hid_have_special_driver. Over time we are removing more and more
devices from the hid_have_special_driver table as devices get tested
to support this setup.

Before this commit the following happens when a HID device which has a
special-driver and is no longer listed in hid_have_special_driver, gets
enumerated:

1) device_add() gets called
2) bus_add_device() looks for a matching already registered hid driver,
   and bind hid-generic to the new device
3) kobject_uevent(&dev->kobj, KOBJ_ADD) gets called notifying userspace of
   the new hid_dev. udev calls modprobe based on the modalias in the uevent
4) The special driver gets loaded by modprobe
5) __hid_bus_reprobe_drivers() unbinds hid-generic and binds the new driver

There are a couple of downsides to this:

a) The probing messages printend when a HID driver bounds show up twice in
dmesg, which is confusing for the user

b) The (un)binding typically causes one or more evdev device-nodes to get
(un)registered firing of udev events to which e.g. the xserver responds by
(un)registering xinput devices and reporting this to interested clients.
IOW the i. bind generic, ii. unbind generic, iii. bind special driver dance
sets in motion a whole chain of events each step, while we really only want
the events from step iii. to be reported to userspace.

This commits introduces a request_module call before the device_add()
call, so that the special-driver is loaded when step 2) looks for a
matching driver and we directly bind the specialized driver.

Note the request_module call translates to an execve("/sbin/modprobe", ...)
and we now do this for each HID device added. So this is not entirely free,
but adding HID devices is not something which happens 100s of times a
second, so this should be fine.
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
[bentiss: fixed typo in commit message found by checkpatch.pl]
Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      a025a18f
    • Nicolas Saenz Julienne's avatar
      HID: core: move Usage Page concatenation to Main item · 58e75155
      Nicolas Saenz Julienne authored 
      As seen on some USB wireless keyboards manufactured by Primax, the HID
parser was using some assumptions that are not always true. In this case
it's s the fact that, inside the scope of a main item, an Usage Page
will always precede an Usage.

The spec is not pretty clear as 6.2.2.7 states "Any usage that follows
is interpreted as a Usage ID and concatenated with the Usage Page".
While 6.2.2.8 states "When the parser encounters a main item it
concatenates the last declared Usage Page with a Usage to form a
complete usage value." Being somewhat contradictory it was decided to
match Window's implementation, which follows 6.2.2.8.

In summary, the patch moves the Usage Page concatenation from the local
item parsing function to the main item parsing function.
Signed-off-by: default avatarNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: default avatarTerry Junge <terry.junge@poly.com>
Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      58e75155
  3. 08 Mar, 2019 38 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7