hidraw support in the kernel(s)
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.
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.htmlSo is there a reason why
CONFIG_HIDRAWis 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 OhlyThe 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"