Messages in this thread | | | From | Michael Menegakis <> | Date | Sat, 24 Feb 2018 20:24:06 +0200 | Subject | The usage of hid_have_special_driver() in hid_add_device() of hid-core.c makes the usage of /dev/hidraw cumbersome from user space. |
| |
A recent patch of Wine allows to have proper access to raw HID for bluetooth devices expressed at /dev/hidraw* and via libudev. This generally opens the door to a wide array of windows software that relies on raw HID access to be used on Linux.
However, the relevant code at hid_add_device() doesn't create a /dev/hidraw at all if one wants to blacklist a kernel driver from being loaded for that device! That renders userspace incapable to use raw HID unless they recompile the kernel for each device.
Let me know if I miss something or if a recent patch I'm not aware of alters that behavior. If not, I suggest to provide away to retain the existence of /dev/hidraw# if a corresponding module is not loaded, without requiring user space to recompile.
PS. In case that part wasn't clear: We can't use both a special driver + another user space driver access /dev/hidraw in several cases because they may conflict. Therefore one has to recompile the kernel currently in order to avoid conflicts.
PPS. I noticed the existence of ignore_special_drivers parm of hid while I was finishing this message but that appears a catch-all. I generally don't get why /dev/hidraw# isn't retained if a special driver is unloaded (or not loaded) by default.
| |