Skip to contentSkip to conversation

hidraw support in the kernel(s)

DISCUSSION Patrick Ohly 2 participants 2 messages Sep 11, 2017

lore
Share & tools
lore
#0 lore raw

Hello!

I am currently trying to get fwupd [1] working. For updating a Lenovo Unifying Dongle (the USB thingie which connects to wireless mice and keyboards), the kernel has to support hidraw, aka CONFIG_HIDRAW, otherwise fwupd does not find the dongle.

http://www.signal11.us/oss/udev/ is an article that seems to explain the underlying API used by fwupd. Other apps might also need it. The recommendation is to enable it unless there are reasons not to do so:
http://cateee.net/lkddb/web-lkddb/HIDRAW.html

So is there a reason why CONFIG_HIDRAW is disabled in linux-intel and (presumably, I haven't checked) linux-yocto for intel-corei7-64?

What would be the right way of enabling it? On by default as part of some existing kernel feature perhaps? Or a new feature?

Signature · 6 lines
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
#1 lore raw
Quoted 7 lines · Patrick Ohly

Hello!

I am currently trying to get fwupd [1] working. For updating a Lenovo Unifying Dongle (the USB thingie which connects to wireless mice and keyboards), the kernel has to support hidraw, aka CONFIG_HIDRAW, otherwise fwupd does not find the dongle.

Quoted 8 lines

http://www.signal11.us/oss/udev/ is an article that seems to explain the underlying API used by fwupd. Other apps might also need it. The recommendation is to enable it unless there are reasons not to do so:
http://cateee.net/lkddb/web-lkddb/HIDRAW.html

So is there a reason why CONFIG_HIDRAW is disabled in linux-intel and (presumably, I haven't checked) linux-yocto for intel-corei7-64?

The only reason it wouldn't be enabled is simply that we haven't had a use case for it (up until now), and (for the most part) anything that isn't strictly needed (or has a known peripheral) is disabled to keep the default kernel's smaller.

For this option, it doesn't add much size to the kernel, has broad arch support and could be generally useful .. so there really isn't much of an issue enabling it in the core configs.

A lot of the HID enablement is currently in BSP fragments, but that tends to limit their ability to be reused.

Quoted 4 lines

What would be the right way of enabling it? On by default as part of some existing kernel feature perhaps? Or a new feature?

There are several features that already deal with HID devices, so it could be added there (i.e. features/iio/iio.cfg) done there, or create a similar feature
if there's a reason do not enable what is in the existing fragments when this
one is used.

Once the option is in a fragment, it is a matter of just ensuring that either a
ktype (i.e. standard) includes it, if we want it everywhere .. or the relevant
BSPs include it if you want to limit it.

And finally, KERNEL_FEATURES are available if you want it to be optionally enabled via a kernel recipe.

Cheers,

Bruce

Quoted 11 lines

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.

Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"