[PATCH libevdev 1/4] Add a doxygen page listing the ioctls and their current support

[David Herrmann]

Hi

On Sun, Dec 8, 2013 at 11:12 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Fri, Dec 06, 2013 at 11:23:27AM +0100, David Herrmann wrote:
>> Hi
>>
>> On Thu, Dec 5, 2013 at 10:37 PM, Peter Hutterer
>> <peter.hutterer at who-t.net> wrote:
>> > On Thu, Dec 05, 2013 at 06:13:07PM +0100, David Herrmann wrote:
>> >> Hi
>> >>
>> >> Patch looks good, but besides ioctls, we also lack proper write()
>> >> support.
>> >
>> > can you extend on this - what support do we need here?
>>
>> Well, any event can be written to an evdev device if you can read()
>> it. It usually doesn't make much sense but can be used to overwrite
>> driver values across all evdev readers. But I'm fine with not
>> supporting this unless we have a proper use-case.
>
> fwiw, I've used this in the past for testing where I just emulate an event
> sequence on the physical device instead of the uinput device so there are
> use-cases. writing a wrapper for this would be a relatively trivial task.

Yeah, for testing it's quite nice. Problem is, the evdev core reacts
differently depending on the event type. Some events are broadcasted,
some are forwarded to the device-driver only and some just have no
effect at all. So maybe we're really better off just not providing any
of these features unless we have a specific (proper) use-case.

>> However, there are a bunch of events which require write() support:
>>  - EV_PWR
>>  - REP_*
>>  - SND_*
>> And most important, all of the FF things require write() support. With
>> current libevdev, FF is not supported at all and users need to do all
>> the heavy lifting themselves (which is fine to me, but it's not
>> documented at all).
>
> yeah, I'm aware of the FF-stuff missing but that's likely going to stay that
> way past the 1.0 release unless someone steps up to do it. I'll hack up a
> documentation bit that at least states that.

As long as we keep that in mind, I'm fine. Just wanted to point out
that the few ioctl interfaces are not the only kernel feature that
we're currently not providing wrappers for.

Thanks
David