Re: [PATCH] HID: use generic driver for ThingM blink(1) if !CONFIG_HID_THINGM

2 messages, 2 authors, 2015-08-03 · open the first message on its own page

Re: [PATCH] HID: use generic driver for ThingM blink(1) if !CONFIG_HID_THINGM

From: Jiri Kosina <hidden>
Date: 2015-08-03 09:25:14

On Sun, 2 Aug 2015, Reilly Grant wrote:
There is existing user space software (not just mine, also from the
manufacturer) that does not use the special driver and instead uses hidraw
or usbdevice_fs to control the device. LED class driver support for this
device is useful but should be optional.
Is there any problem for the userspace software to unbind the kernel 
driver first?

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] HID: use generic driver for ThingM blink(1) if !CONFIG_HID_THINGM

From: Reilly Grant <hidden>
Date: 2015-08-03 16:52:49

If the software is using usbdevice_fs, no, it can simply detach the
kernel driver. If the software is using hidraw then this blacklist
becomes the issue because even if you unload the special driver the
generic HID driver won't load. Is there a mechanism in the HID
subsystem for drivers to build on top of the generic one instead of
replacing it?


On Mon, Aug 3, 2015, 2:25 AM Jiri Kosina [off-list ref] wrote:
On Sun, 2 Aug 2015, Reilly Grant wrote:
quoted
There is existing user space software (not just mine, also from the
manufacturer) that does not use the special driver and instead uses hidraw
or usbdevice_fs to control the device. LED class driver support for this
device is useful but should be optional.
Is there any problem for the userspace software to unbind the kernel
driver first?

--
Jiri Kosina
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help