hidraw with exclusive access ?

hidraw with exclusive access ?

[Timo Teras]

Hi,

I'm trying to write userland driver for an input controller -
basically a macrokeyboard: some keys act like regular keys, and some
are not really described in the descriptor so it needs custom parser.
It has also extra commands to set/blink LEDs, etc.

I'd need exclusive access to it. Mainly because some of the keys emit
normal looking presses and I would not like them to be fed into the
input system when my application is running. As side effect I get also
in dmesg errors like "input input16: event field not found" due to this.

Now this is of course doable with libusb, not using kernel hid
subsystem, and reimplementing the relevant hid bits (or using some of
the existing hid libraries doing this). But this sounds a bit overkill
and hidraw seems to be exactly for this kind of use case.

The only problem is that I was not able to find a 'grab device' type of
functionality in hidraw. Basically equivalent of EVIOCGRAB in input
subsystem. Something that would make sure the reports come only to
hidraw device.

Would it make sense to implement something like this for hidraw?

As an alternative I think we could have hid-rawonly driver, that would
by default bind to nothing. And when bound, would connect to the hid
device with HID_CONNECT_HIDRAW flag only. I could then in userland
rebind the device from hid-generic to hid-rawonly.

Or finally, to implement a full kernel side driver it. But I'd
rather not go there. Especially since the device has multiple leds, and
the input system allows only limited leds. (The leds could be exported
as led devices, but then I'd need more userland logic to figure out
which led devices map to which input device.)

Thoughts?

Thanks,
Timo

Re: hidraw with exclusive access ?

[Benjamin Tissoires]

Hi,

On Fri, Mar 13, 2015 at 2:37 AM, Timo Teras <timo.teras@iki.fi> wrote:
> Hi,
>
> I'm trying to write userland driver for an input controller -
> basically a macrokeyboard: some keys act like regular keys, and some
> are not really described in the descriptor so it needs custom parser.
> It has also extra commands to set/blink LEDs, etc.
>
> I'd need exclusive access to it. Mainly because some of the keys emit
> normal looking presses and I would not like them to be fed into the
> input system when my application is running. As side effect I get also
> in dmesg errors like "input input16: event field not found" due to this.
>
> Now this is of course doable with libusb, not using kernel hid
> subsystem, and reimplementing the relevant hid bits (or using some of
> the existing hid libraries doing this). But this sounds a bit overkill
> and hidraw seems to be exactly for this kind of use case.
>
> The only problem is that I was not able to find a 'grab device' type of
> functionality in hidraw. Basically equivalent of EVIOCGRAB in input
> subsystem. Something that would make sure the reports come only to
> hidraw device.
>
> Would it make sense to implement something like this for hidraw?

I am not a big fan of this idea. Simply because sensitive information
like key press should not be handled in user space.
Really, we already have keyboards macro support in the kernel (see
drivers/hid/hid-roccat*) and I think you should consider doing your
driver in the kernel.

>
> As an alternative I think we could have hid-rawonly driver, that would
> by default bind to nothing. And when bound, would connect to the hid
> device with HID_CONNECT_HIDRAW flag only. I could then in userland
> rebind the device from hid-generic to hid-rawonly.

That could work (make a special driver and use HID_CONNECT_HIDRAW),
but that's a terrible idea and will be refused I guess.
Users expects their keyboard to be working everywhere, even at boot
and in the console. By doing so, you will just break existing
keyboards.

>
> Or finally, to implement a full kernel side driver it. But I'd
> rather not go there. Especially since the device has multiple leds, and
> the input system allows only limited leds. (The leds could be exported
> as led devices, but then I'd need more userland logic to figure out
> which led devices map to which input device.)

No, that's not true. If you have LEDs, then use the LED class and then
user space deal with the LEDs. If the LEDs are not standard, then you
will need userspace tools to access them so I don't think it is a
problem. Standard LEDs will be handled properly through the input node
(CAPS Lock, Ver Num, etc...).

The good side of having your driver in the kernel is also less
maintenance, and less pain for the users. Once it hits mainline, users
will have a functional keyboard without having to rely on anything
else. For you, if some interface change, you will have less head
aches.

If you *really* don't want to work in the kernel, you should simply
ignore the generic keys in your driver and work only on the special
keys macros that you want to support.

Cheers,
Benjamin

>
> Thoughts?
>
> Thanks,
> Timo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: hidraw with exclusive access ?

[Timo Teras]

On Mon, 16 Mar 2015 11:29:10 -0400
Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:

> On Fri, Mar 13, 2015 at 2:37 AM, Timo Teras <timo.teras@iki.fi> wrote:
> > Hi,
> >
> > I'm trying to write userland driver for an input controller -
> > basically a macrokeyboard: some keys act like regular keys, and some
> > are not really described in the descriptor so it needs custom
> > parser. It has also extra commands to set/blink LEDs, etc.
> >
> > I'd need exclusive access to it. Mainly because some of the keys
> > emit normal looking presses and I would not like them to be fed
> > into the input system when my application is running. As side
> > effect I get also in dmesg errors like "input input16: event field
> > not found" due to this.
> >
> > Now this is of course doable with libusb, not using kernel hid
> > subsystem, and reimplementing the relevant hid bits (or using some
> > of the existing hid libraries doing this). But this sounds a bit
> > overkill and hidraw seems to be exactly for this kind of use case.
> >
> > The only problem is that I was not able to find a 'grab device'
> > type of functionality in hidraw. Basically equivalent of EVIOCGRAB
> > in input subsystem. Something that would make sure the reports come
> > only to hidraw device.
> >
> > Would it make sense to implement something like this for hidraw?
> 
> I am not a big fan of this idea. Simply because sensitive information
> like key press should not be handled in user space.
> Really, we already have keyboards macro support in the kernel (see
> drivers/hid/hid-roccat*) and I think you should consider doing your
> driver in the kernel.

I thought this was the exact idea of hidraw - to allow hardware access
without requiring kernel driver.

> > As an alternative I think we could have hid-rawonly driver, that
> > would by default bind to nothing. And when bound, would connect to
> > the hid device with HID_CONNECT_HIDRAW flag only. I could then in
> > userland rebind the device from hid-generic to hid-rawonly.
> 
> That could work (make a special driver and use HID_CONNECT_HIDRAW),
> but that's a terrible idea and will be refused I guess.
> Users expects their keyboard to be working everywhere, even at boot
> and in the console. By doing so, you will just break existing
> keyboards.

No. The whole point was to have driver that is not automatically
bound to anything. So we would not break anything existing. You'd get
that driver only by manual rebinding via sysfs.

> > Or finally, to implement a full kernel side driver it. But I'd
> > rather not go there. Especially since the device has multiple leds,
> > and the input system allows only limited leds. (The leds could be
> > exported as led devices, but then I'd need more userland logic to
> > figure out which led devices map to which input device.)
> 
> No, that's not true. If you have LEDs, then use the LED class and then
> user space deal with the LEDs. If the LEDs are not standard, then you
> will need userspace tools to access them so I don't think it is a
> problem. Standard LEDs will be handled properly through the input node
> (CAPS Lock, Ver Num, etc...).

There's individial LEDs per each key. Namely I'm looking at the devices
at: http://xkeys.com/XkeysKeyboards/index.php

The protocol they run is published at:
http://xkeys.com/PISupport/DeveloperHIDDataReports.php

And as mentioned - it'd be lot of work to combine which LED is for which
key.

> The good side of having your driver in the kernel is also less
> maintenance, and less pain for the users. Once it hits mainline, users
> will have a functional keyboard without having to rely on anything
> else. For you, if some interface change, you will have less head
> aches.
>
> If you *really* don't want to work in the kernel, you should simply
> ignore the generic keys in your driver and work only on the special
> keys macros that you want to support.

It's not possible. Few of the generic keys default to mouse buttons.
Those I'd like to ignore.

In fact, there's already some code out there that use hidraw and feed
the application from it. The code also opens the corresponding input
device with grab to make sure the events do not leak out to x11. So I'm
not the only one wanting to do this.

/Timo

Re: hidraw with exclusive access ?

[Benjamin Tissoires]

On Mon, Mar 16, 2015 at 2:39 PM, Timo Teras <timo.teras@iki.fi> wrote:
> On Mon, 16 Mar 2015 11:29:10 -0400
> Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:
>
>> On Fri, Mar 13, 2015 at 2:37 AM, Timo Teras <timo.teras@iki.fi> wrote:
>> > Hi,
>> >
>> > I'm trying to write userland driver for an input controller -
>> > basically a macrokeyboard: some keys act like regular keys, and some
>> > are not really described in the descriptor so it needs custom
>> > parser. It has also extra commands to set/blink LEDs, etc.
>> >
>> > I'd need exclusive access to it. Mainly because some of the keys
>> > emit normal looking presses and I would not like them to be fed
>> > into the input system when my application is running. As side
>> > effect I get also in dmesg errors like "input input16: event field
>> > not found" due to this.
>> >
>> > Now this is of course doable with libusb, not using kernel hid
>> > subsystem, and reimplementing the relevant hid bits (or using some
>> > of the existing hid libraries doing this). But this sounds a bit
>> > overkill and hidraw seems to be exactly for this kind of use case.
>> >
>> > The only problem is that I was not able to find a 'grab device'
>> > type of functionality in hidraw. Basically equivalent of EVIOCGRAB
>> > in input subsystem. Something that would make sure the reports come
>> > only to hidraw device.
>> >
>> > Would it make sense to implement something like this for hidraw?
>>
>> I am not a big fan of this idea. Simply because sensitive information
>> like key press should not be handled in user space.
>> Really, we already have keyboards macro support in the kernel (see
>> drivers/hid/hid-roccat*) and I think you should consider doing your
>> driver in the kernel.
>
> I thought this was the exact idea of hidraw - to allow hardware access
> without requiring kernel driver.

Yes it is, but I did not understand which type of device you were
trying to fix. I thought you were dealing with regular keyboards with
some macro keys and with few LEDs. In that case, a user space driver
is not very welcomed IMO.
But the X-keys devices you are fixing are quite different. I don't
think anybody expects them to be able to type his password at prompt
with it, and the purpose is somewhat different from the regular
keyboards.

>
>> > As an alternative I think we could have hid-rawonly driver, that
>> > would by default bind to nothing. And when bound, would connect to
>> > the hid device with HID_CONNECT_HIDRAW flag only. I could then in
>> > userland rebind the device from hid-generic to hid-rawonly.
>>
>> That could work (make a special driver and use HID_CONNECT_HIDRAW),
>> but that's a terrible idea and will be refused I guess.
>> Users expects their keyboard to be working everywhere, even at boot
>> and in the console. By doing so, you will just break existing
>> keyboards.
>
> No. The whole point was to have driver that is not automatically
> bound to anything. So we would not break anything existing. You'd get
> that driver only by manual rebinding via sysfs.

Hmm, still not convinced by the manual re-binding through sysfs. If
the keyboard does not work directly with the generic hid protocol or
send garbage that users can not deal with, then why not simply bind it
to the hidraw driver only?

>
>> > Or finally, to implement a full kernel side driver it. But I'd
>> > rather not go there. Especially since the device has multiple leds,
>> > and the input system allows only limited leds. (The leds could be
>> > exported as led devices, but then I'd need more userland logic to
>> > figure out which led devices map to which input device.)
>>
>> No, that's not true. If you have LEDs, then use the LED class and then
>> user space deal with the LEDs. If the LEDs are not standard, then you
>> will need userspace tools to access them so I don't think it is a
>> problem. Standard LEDs will be handled properly through the input node
>> (CAPS Lock, Ver Num, etc...).
>
> There's individial LEDs per each key. Namely I'm looking at the devices
> at: http://xkeys.com/XkeysKeyboards/index.php
>
> The protocol they run is published at:
> http://xkeys.com/PISupport/DeveloperHIDDataReports.php
>
> And as mentioned - it'd be lot of work to combine which LED is for which
> key.

Then in that case, why not exporting your own sysfs interface to
illuminate the LEDs and set the macro?

We do that for the OLED of the wacom device, and that's fine (I guess).

>
>> The good side of having your driver in the kernel is also less
>> maintenance, and less pain for the users. Once it hits mainline, users
>> will have a functional keyboard without having to rely on anything
>> else. For you, if some interface change, you will have less head
>> aches.
>>
>> If you *really* don't want to work in the kernel, you should simply
>> ignore the generic keys in your driver and work only on the special
>> keys macros that you want to support.
>
> It's not possible. Few of the generic keys default to mouse buttons.
> Those I'd like to ignore.
>
> In fact, there's already some code out there that use hidraw and feed
> the application from it. The code also opens the corresponding input
> device with grab to make sure the events do not leak out to x11. So I'm
> not the only one wanting to do this.
>

So, IMO you can approach the problem through 2 ways:
- make a short out-of-the-tree driver for the X-keys that bind only to
hidraw, when you launch the user-space driver, unbind hid-generic and
bind the device to your small driver and then deal with the keyboard
in userspace.
- keep the kernel input node, reimplement the .raw_event() in the
kernel driver, and provide a control API through sysfs.

The second way allows you to have a UI/config tool which is not a
daemon and which just controls what the kernel does.

BTW, I guessed that the macros are not stored in the keyboard but
rather in your user-space program. If the macros are actually stored
and generated by the device itself, then I think fixing the kernel to
handle them would be a better path, and you need hidraw only to
configure the device.

Cheers,
Benjamin

Re: hidraw with exclusive access ?

[Timo Teras]

On Mon, 16 Mar 2015 15:15:33 -0400
Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:

> On Mon, Mar 16, 2015 at 2:39 PM, Timo Teras <timo.teras@iki.fi> wrote:
> > On Mon, 16 Mar 2015 11:29:10 -0400
> > Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:
> >
> >> On Fri, Mar 13, 2015 at 2:37 AM, Timo Teras <timo.teras@iki.fi>
> >> wrote:
> >> > As an alternative I think we could have hid-rawonly driver, that
> >> > would by default bind to nothing. And when bound, would connect
> >> > to the hid device with HID_CONNECT_HIDRAW flag only. I could
> >> > then in userland rebind the device from hid-generic to
> >> > hid-rawonly.
> >>
> >> That could work (make a special driver and use HID_CONNECT_HIDRAW),
> >> but that's a terrible idea and will be refused I guess.
> >> Users expects their keyboard to be working everywhere, even at boot
> >> and in the console. By doing so, you will just break existing
> >> keyboards.
> >
> > No. The whole point was to have driver that is not automatically
> > bound to anything. So we would not break anything existing. You'd
> > get that driver only by manual rebinding via sysfs.
> 
> Hmm, still not convinced by the manual re-binding through sysfs. If
> the keyboard does not work directly with the generic hid protocol or
> send garbage that users can not deal with, then why not simply bind it
> to the hidraw driver only?

They are complicated and configurable devices. They can work in the
macro mode, and I believe the device can send a sequence of keypresses
- at least some of them, but not all. Additionally some of the devices
appear as multiple HID devices. E.g. the joystick models show up as
three HID devices: their "SPLAT" interface, one keyboard and one
joystick (or mouse) device.

It might make sense to allow the Joystick to show up as regular
joystick by default. But to make the SPLAT interface work properly,
also the other HID events need to be processed. So currently I have
code that reads all three related hidraw devices, but acts only based
on the SPLAT one.

It also depends on the device model whether or not it generates
"conflicting" input events that I'd like to suppress.

In any case, the simplest way for me to was to use hidraw devices.. As
I'm using dedicated machine, there's no real harm by the conflicting
input events (as no X is running currently). The only annoyance is the
dmesg errors about bad input events. But if I ever build boxes running
also X, it'll be a problem. That's why'd appreciate a way to grab the
hidraw device.

> >> > Or finally, to implement a full kernel side driver it. But I'd
> >> > rather not go there. Especially since the device has multiple
> >> > leds, and the input system allows only limited leds. (The leds
> >> > could be exported as led devices, but then I'd need more
> >> > userland logic to figure out which led devices map to which
> >> > input device.)
> >>
> >> No, that's not true. If you have LEDs, then use the LED class and
> >> then user space deal with the LEDs. If the LEDs are not standard,
> >> then you will need userspace tools to access them so I don't think
> >> it is a problem. Standard LEDs will be handled properly through
> >> the input node (CAPS Lock, Ver Num, etc...).
> >
> > There's individial LEDs per each key. Namely I'm looking at the
> > devices at: http://xkeys.com/XkeysKeyboards/index.php
> >
> > The protocol they run is published at:
> > http://xkeys.com/PISupport/DeveloperHIDDataReports.php
> >
> > And as mentioned - it'd be lot of work to combine which LED is for
> > which key.
> 
> Then in that case, why not exporting your own sysfs interface to
> illuminate the LEDs and set the macro?
> 
> We do that for the OLED of the wacom device, and that's fine (I
> guess).

I found it simpler to implement the protocol in my app, instead of
writing a kernel interface for it. Doing the kernel driver would make
more sense if there was a way to map LEDs to keys already. Otherwise
I'm just inventing an abstraction that just makes me write more code...
and will probably eventually be replaced by something else.

> >> The good side of having your driver in the kernel is also less
> >> maintenance, and less pain for the users. Once it hits mainline,
> >> users will have a functional keyboard without having to rely on
> >> anything else. For you, if some interface change, you will have
> >> less head aches.
> >>
> >> If you *really* don't want to work in the kernel, you should simply
> >> ignore the generic keys in your driver and work only on the special
> >> keys macros that you want to support.
> >
> > It's not possible. Few of the generic keys default to mouse buttons.
> > Those I'd like to ignore.
> >
> > In fact, there's already some code out there that use hidraw and
> > feed the application from it. The code also opens the corresponding
> > input device with grab to make sure the events do not leak out to
> > x11. So I'm not the only one wanting to do this.
> 
> So, IMO you can approach the problem through 2 ways:
> - make a short out-of-the-tree driver for the X-keys that bind only to
> hidraw, when you launch the user-space driver, unbind hid-generic and
> bind the device to your small driver and then deal with the keyboard
> in userspace.
> - keep the kernel input node, reimplement the .raw_event() in the
> kernel driver, and provide a control API through sysfs.
>
> The second way allows you to have a UI/config tool which is not a
> daemon and which just controls what the kernel does.

I'd like to have a generic in-tree solution. For my immediate needs,
I'd be happy using hidraw as long as I have some mechanism to exclude
feeding that HID device to regular input system.

> BTW, I guessed that the macros are not stored in the keyboard but
> rather in your user-space program. If the macros are actually stored
> and generated by the device itself, then I think fixing the kernel to
> handle them would be a better path, and you need hidraw only to
> configure the device.

As said, depends likely on the device, and the way it is configured.
But to make the backlighting control work usage of the SPLAT interface
is required.

Btw. one example of code trying to accomplish something similar is:
https://github.com/chrippa/ds4drv/blob/master/ds4drv/backends/hidraw.py
it uses and parses the hidraw stuff, but also opens the corresponding
input device just to grab it for exclusive access.

Thanks,
Timo

Re: hidraw with exclusive access ?

[Benjamin Tissoires]

On Mon, Mar 16, 2015 at 4:17 PM, Timo Teras <timo.teras@iki.fi> wrote:
> On Mon, 16 Mar 2015 15:15:33 -0400
> Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:
>
>> On Mon, Mar 16, 2015 at 2:39 PM, Timo Teras <timo.teras@iki.fi> wrote:
>> > On Mon, 16 Mar 2015 11:29:10 -0400
>> > Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:
>> >
>> >> On Fri, Mar 13, 2015 at 2:37 AM, Timo Teras <timo.teras@iki.fi>
>> >> wrote:
>> >> > As an alternative I think we could have hid-rawonly driver, that
>> >> > would by default bind to nothing. And when bound, would connect
>> >> > to the hid device with HID_CONNECT_HIDRAW flag only. I could
>> >> > then in userland rebind the device from hid-generic to
>> >> > hid-rawonly.
>> >>
>> >> That could work (make a special driver and use HID_CONNECT_HIDRAW),
>> >> but that's a terrible idea and will be refused I guess.
>> >> Users expects their keyboard to be working everywhere, even at boot
>> >> and in the console. By doing so, you will just break existing
>> >> keyboards.
>> >
>> > No. The whole point was to have driver that is not automatically
>> > bound to anything. So we would not break anything existing. You'd
>> > get that driver only by manual rebinding via sysfs.
>>
>> Hmm, still not convinced by the manual re-binding through sysfs. If
>> the keyboard does not work directly with the generic hid protocol or
>> send garbage that users can not deal with, then why not simply bind it
>> to the hidraw driver only?
>
> They are complicated and configurable devices. They can work in the
> macro mode, and I believe the device can send a sequence of keypresses
> - at least some of them, but not all. Additionally some of the devices
> appear as multiple HID devices. E.g. the joystick models show up as
> three HID devices: their "SPLAT" interface, one keyboard and one
> joystick (or mouse) device.
>
> It might make sense to allow the Joystick to show up as regular
> joystick by default. But to make the SPLAT interface work properly,
> also the other HID events need to be processed. So currently I have
> code that reads all three related hidraw devices, but acts only based
> on the SPLAT one.

IMO, none of this seems to be valid reasons to not look into a kernel
solution. you can have cross hid interface knowledge in the driver
(that's what wacom does) and you can fine control what you want to
forward from within the driver.

>
> It also depends on the device model whether or not it generates
> "conflicting" input events that I'd like to suppress.
>
> In any case, the simplest way for me to was to use hidraw devices.. As
> I'm using dedicated machine, there's no real harm by the conflicting
> input events (as no X is running currently). The only annoyance is the
> dmesg errors about bad input events. But if I ever build boxes running
> also X, it'll be a problem. That's why'd appreciate a way to grab the
> hidraw device.
>
>> >> > Or finally, to implement a full kernel side driver it. But I'd
>> >> > rather not go there. Especially since the device has multiple
>> >> > leds, and the input system allows only limited leds. (The leds
>> >> > could be exported as led devices, but then I'd need more
>> >> > userland logic to figure out which led devices map to which
>> >> > input device.)
>> >>
>> >> No, that's not true. If you have LEDs, then use the LED class and
>> >> then user space deal with the LEDs. If the LEDs are not standard,
>> >> then you will need userspace tools to access them so I don't think
>> >> it is a problem. Standard LEDs will be handled properly through
>> >> the input node (CAPS Lock, Ver Num, etc...).
>> >
>> > There's individial LEDs per each key. Namely I'm looking at the
>> > devices at: http://xkeys.com/XkeysKeyboards/index.php
>> >
>> > The protocol they run is published at:
>> > http://xkeys.com/PISupport/DeveloperHIDDataReports.php
>> >
>> > And as mentioned - it'd be lot of work to combine which LED is for
>> > which key.
>>
>> Then in that case, why not exporting your own sysfs interface to
>> illuminate the LEDs and set the macro?
>>
>> We do that for the OLED of the wacom device, and that's fine (I
>> guess).
>
> I found it simpler to implement the protocol in my app, instead of
> writing a kernel interface for it. Doing the kernel driver would make

But this way, only your application can make use of the device. Others
will have to duplicate it or reinvent the logic if they want to use an
other environment You made reference at one point of a program in
python, and I guess people might not want to have python daemon
running in the background. Even if your driver is written in C or any
other language, people won't have a generic access to it.

> more sense if there was a way to map LEDs to keys already. Otherwise
> I'm just inventing an abstraction that just makes me write more code...
> and will probably eventually be replaced by something else.

I doubt that this will be so much of a pain. You just have to port
your code in the kernel and have a small char sysfs interface to
design. And even if something else is more powerful that your custom
made interface, for legacy purposes, we will have to keep it in the
kernel.

>
>> >> The good side of having your driver in the kernel is also less
>> >> maintenance, and less pain for the users. Once it hits mainline,
>> >> users will have a functional keyboard without having to rely on
>> >> anything else. For you, if some interface change, you will have
>> >> less head aches.
>> >>
>> >> If you *really* don't want to work in the kernel, you should simply
>> >> ignore the generic keys in your driver and work only on the special
>> >> keys macros that you want to support.
>> >
>> > It's not possible. Few of the generic keys default to mouse buttons.
>> > Those I'd like to ignore.
>> >
>> > In fact, there's already some code out there that use hidraw and
>> > feed the application from it. The code also opens the corresponding
>> > input device with grab to make sure the events do not leak out to
>> > x11. So I'm not the only one wanting to do this.
>>
>> So, IMO you can approach the problem through 2 ways:
>> - make a short out-of-the-tree driver for the X-keys that bind only to
>> hidraw, when you launch the user-space driver, unbind hid-generic and
>> bind the device to your small driver and then deal with the keyboard
>> in userspace.
>> - keep the kernel input node, reimplement the .raw_event() in the
>> kernel driver, and provide a control API through sysfs.
>>
>> The second way allows you to have a UI/config tool which is not a
>> daemon and which just controls what the kernel does.
>
> I'd like to have a generic in-tree solution. For my immediate needs,
> I'd be happy using hidraw as long as I have some mechanism to exclude
> feeding that HID device to regular input system.

Looks like you already made up your mind. I think I'll need more
arguments in favor of a EVIOCGRAB for the hidraw node. For now, I can
not see a benefit beside your use case, which I am not very found of
(you must have noticed :-P ).
You can still try to write one patch for it, I don't know if Jiri will
take it though (I can try to restrain myself to NACK it).

If all you need is a way to switch off the input reporting, how about
you add a simple hid driver that binds to your devices and has a
parameter (or a sysfs file) which returns -1 in .input_event() when
the flag is set. This way the device won't send events to the
userspace but will keep forwarding hidraw events.

>
>> BTW, I guessed that the macros are not stored in the keyboard but
>> rather in your user-space program. If the macros are actually stored
>> and generated by the device itself, then I think fixing the kernel to
>> handle them would be a better path, and you need hidraw only to
>> configure the device.
>
> As said, depends likely on the device, and the way it is configured.
> But to make the backlighting control work usage of the SPLAT interface
> is required.
>
> Btw. one example of code trying to accomplish something similar is:
> https://github.com/chrippa/ds4drv/blob/master/ds4drv/backends/hidraw.py
> it uses and parses the hidraw stuff, but also opens the corresponding
> input device just to grab it for exclusive access.
>


Cheers,
Benjamin

Re: hidraw with exclusive access ?

[Timo Teras]

On Mon, 16 Mar 2015 16:44:37 -0400
Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:

> On Mon, Mar 16, 2015 at 4:17 PM, Timo Teras <timo.teras@iki.fi> wrote:
> > They are complicated and configurable devices. They can work in the
> > macro mode, and I believe the device can send a sequence of
> > keypresses
> > - at least some of them, but not all. Additionally some of the
> > devices appear as multiple HID devices. E.g. the joystick models
> > show up as three HID devices: their "SPLAT" interface, one keyboard
> > and one joystick (or mouse) device.
> >
> > It might make sense to allow the Joystick to show up as regular
> > joystick by default. But to make the SPLAT interface work properly,
> > also the other HID events need to be processed. So currently I have
> > code that reads all three related hidraw devices, but acts only
> > based on the SPLAT one.
> 
> IMO, none of this seems to be valid reasons to not look into a kernel
> solution. you can have cross hid interface knowledge in the driver
> (that's what wacom does) and you can fine control what you want to
> forward from within the driver.

Well, in perfect world the someone would have written the driver
already. I'd be happy to use it. Unfortunately, I don't currently have
time to write a kernel driver (it's not too complicated or even that
big project - but still, doing the hidraw implementation is still
simpler and faster for my immediate needs).

I should probably fire up the windows drivers for the keyboard. Maybe I
can remap it to not give regular keyboard/mouse events at all.

> > I found it simpler to implement the protocol in my app, instead of
> > writing a kernel interface for it. Doing the kernel driver would
> > make
> 
> But this way, only your application can make use of the device. Others
> will have to duplicate it or reinvent the logic if they want to use an
> other environment You made reference at one point of a program in
> python, and I guess people might not want to have python daemon
> running in the background. Even if your driver is written in C or any
> other language, people won't have a generic access to it.
>
> > more sense if there was a way to map LEDs to keys already. Otherwise
> > I'm just inventing an abstraction that just makes me write more
> > code... and will probably eventually be replaced by something else.
> 
> I doubt that this will be so much of a pain. You just have to port
> your code in the kernel and have a small char sysfs interface to
> design. And even if something else is more powerful that your custom
> made interface, for legacy purposes, we will have to keep it in the
> kernel.

Agreed.

Though if someone was to write this driver. Where should this keys be
mapped to? I don't see any consecutive area of 128 keys that do not
have specific meaning. KEY_F1...KEY_F24 sound appropriate, as well as
KEY_FN_F1... But the largest one is still 128 keys.

Any suggestion on the sysfs interface controlling the backlighting of
each individual key (each key has both blue and red LED underneath it -
they all can be controlled individually). There's also two generic leds
which could be mapped also to the regular input's led system.

> > I'd like to have a generic in-tree solution. For my immediate needs,
> > I'd be happy using hidraw as long as I have some mechanism to
> > exclude feeding that HID device to regular input system.
> 
> Looks like you already made up your mind. I think I'll need more
> arguments in favor of a EVIOCGRAB for the hidraw node. For now, I can
> not see a benefit beside your use case, which I am not very found of
> (you must have noticed :-P ).
> You can still try to write one patch for it, I don't know if Jiri will
> take it though (I can try to restrain myself to NACK it).

I do have most of the hidraw code ready. I would be happy to use kernel
input driver if it existed. But as said, I don't currently have time to
do it. Perhaps later on I'll clean it up and do it like that. But it
would not be anytime soon.

I still find using hidraw like this be the better option. The
manufacturer's Linux example uses libusb to detach kernel drivers, claim
the whole device, and implement the HID stuff in userland:
https://github.com/piengineering/xkeys/
http://xkeys.com/PISupport/DeveloperLinuxSDK.php

> If all you need is a way to switch off the input reporting, how about
> you add a simple hid driver that binds to your devices and has a
> parameter (or a sysfs file) which returns -1 in .input_event() when
> the flag is set. This way the device won't send events to the
> userspace but will keep forwarding hidraw events.

Well - I thought this functionality would be useful to others, so I
was hoping a generic way to do it. Not something specific to my
devices. But apparently your argument is "people will misuse it and I
don't want to allow it in general".

I'd be ok with the hid-rawonly driver as long as it's made non-device
spefic and could be upstreamed. Perhaps ship the list of VIDs/PIDs as
boot option. Or could the existing quirks system be used for this?

Cheers,
Timo

Re: hidraw with exclusive access ?

[Benjamin Tissoires]

On Tue, Mar 17, 2015 at 2:51 AM, Timo Teras <timo.teras@iki.fi> wrote:
> On Mon, 16 Mar 2015 16:44:37 -0400
> Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:
>
>> On Mon, Mar 16, 2015 at 4:17 PM, Timo Teras <timo.teras@iki.fi> wrote:
>> > They are complicated and configurable devices. They can work in the
>> > macro mode, and I believe the device can send a sequence of
>> > keypresses
>> > - at least some of them, but not all. Additionally some of the
>> > devices appear as multiple HID devices. E.g. the joystick models
>> > show up as three HID devices: their "SPLAT" interface, one keyboard
>> > and one joystick (or mouse) device.
>> >
>> > It might make sense to allow the Joystick to show up as regular
>> > joystick by default. But to make the SPLAT interface work properly,
>> > also the other HID events need to be processed. So currently I have
>> > code that reads all three related hidraw devices, but acts only
>> > based on the SPLAT one.
>>
>> IMO, none of this seems to be valid reasons to not look into a kernel
>> solution. you can have cross hid interface knowledge in the driver
>> (that's what wacom does) and you can fine control what you want to
>> forward from within the driver.
>
> Well, in perfect world the someone would have written the driver

No, in a perfect world, you would still have to write the kernel
driver. Most of the upstream developers don't have usage for it (or
were not told by their employer to work on that), so nobody took care
of it.
In an even better perfect world, the hardware maker would have
submitted patches and contributed, but that's impossible to ask
apparently.

> already. I'd be happy to use it. Unfortunately, I don't currently have
> time to write a kernel driver (it's not too complicated or even that
> big project - but still, doing the hidraw implementation is still
> simpler and faster for my immediate needs).

Just to make my point. This really feels like: "can someone please do
my job?". You might not meant it that way, but insisting of the fact
that you don't have the time to do it does not motivate us to
implement it for you.

>
> I should probably fire up the windows drivers for the keyboard. Maybe I
> can remap it to not give regular keyboard/mouse events at all.
>
>> > I found it simpler to implement the protocol in my app, instead of
>> > writing a kernel interface for it. Doing the kernel driver would
>> > make
>>
>> But this way, only your application can make use of the device. Others
>> will have to duplicate it or reinvent the logic if they want to use an
>> other environment You made reference at one point of a program in
>> python, and I guess people might not want to have python daemon
>> running in the background. Even if your driver is written in C or any
>> other language, people won't have a generic access to it.
>>
>> > more sense if there was a way to map LEDs to keys already. Otherwise
>> > I'm just inventing an abstraction that just makes me write more
>> > code... and will probably eventually be replaced by something else.
>>
>> I doubt that this will be so much of a pain. You just have to port
>> your code in the kernel and have a small char sysfs interface to
>> design. And even if something else is more powerful that your custom
>> made interface, for legacy purposes, we will have to keep it in the
>> kernel.
>
> Agreed.
>
> Though if someone was to write this driver. Where should this keys be
> mapped to? I don't see any consecutive area of 128 keys that do not
> have specific meaning. KEY_F1...KEY_F24 sound appropriate, as well as
> KEY_FN_F1... But the largest one is still 128 keys.

No. I was thinking at a custom made one:
Something like:
# echo remap 1 29 46 > /sys/bus/hid/driver/your_driver/macro_keys

where:
- 1 is the key you want to remap
- 29 is the keycode for KEY_LEFTCTRL
- 46 is the keycode for KEY_C

You could allow several keys to be pressed at once this way.

You can also think at a way of passing several bindings through one
call. "remap" could also be omitted.

>
> Any suggestion on the sysfs interface controlling the backlighting of
> each individual key (each key has both blue and red LED underneath it -
> they all can be controlled individually). There's also two generic leds
> which could be mapped also to the regular input's led system.

Let the generic ones be handled by hid, and you can adapt the above to
set the color of the LEDs:

# echo 2 blue > /sys/bus/hid/driver/your_driver/led_color
# echo 2 15 > /sys/bus/hid/driver/your_driver/led_brightness

>
>> > I'd like to have a generic in-tree solution. For my immediate needs,
>> > I'd be happy using hidraw as long as I have some mechanism to
>> > exclude feeding that HID device to regular input system.
>>
>> Looks like you already made up your mind. I think I'll need more
>> arguments in favor of a EVIOCGRAB for the hidraw node. For now, I can
>> not see a benefit beside your use case, which I am not very found of
>> (you must have noticed :-P ).
>> You can still try to write one patch for it, I don't know if Jiri will
>> take it though (I can try to restrain myself to NACK it).
>
> I do have most of the hidraw code ready. I would be happy to use kernel
> input driver if it existed. But as said, I don't currently have time to
> do it. Perhaps later on I'll clean it up and do it like that. But it
> would not be anytime soon.
>
> I still find using hidraw like this be the better option. The
> manufacturer's Linux example uses libusb to detach kernel drivers, claim
> the whole device, and implement the HID stuff in userland:
> https://github.com/piengineering/xkeys/
> http://xkeys.com/PISupport/DeveloperLinuxSDK.php
>
>> If all you need is a way to switch off the input reporting, how about
>> you add a simple hid driver that binds to your devices and has a
>> parameter (or a sysfs file) which returns -1 in .input_event() when
>> the flag is set. This way the device won't send events to the
>> userspace but will keep forwarding hidraw events.
>
> Well - I thought this functionality would be useful to others, so I
> was hoping a generic way to do it. Not something specific to my
> devices. But apparently your argument is "people will misuse it and I
> don't want to allow it in general".

yep. Everything we add in the kernel is here for life. Adding an ioctl
is not something we take easily, and if it is a security problem, it's
even worse.
I think you should not look for something generic at this point, but
something which works for these specific devices first.

>
> I'd be ok with the hid-rawonly driver as long as it's made non-device
> spefic and could be upstreamed. Perhaps ship the list of VIDs/PIDs as
> boot option. Or could the existing quirks system be used for this?

None of the existing quirks will work for your use case. So if you
want to go this way, you'll have to submit the corresponding patch.

Cheers,
Benjamin