lkml.org 
[lkml]   [2018]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectThe 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.

\
 
 \ /
  Last update: 2018-02-24 19:25    [W:0.031 / U:0.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site