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.

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.

[Michael Menegakis]

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.