hidraw support in the kernel(s)

hidraw support in the kernel(s)

[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.

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?

-- 
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.

Re: hidraw support in the kernel(s)

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

On Mon, Sep 11, 2017 at 4:48 AM, Patrick Ohly <patrick.ohly@intel.com>
wrote:

> 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?
>

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.


>
> 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


>
> --
> 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.
>
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 3721 bytes --]