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

[Peter Hutterer]

On Sun, Dec 08, 2013 at 11:15:48PM +0100, David Herrmann wrote:
> 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.

heh, one use-case that'd have saved me some time debugging in the past is
libevdev complaining that a specific event doesn't exist on the device...
copy-paste made me do things like
   write_event(EV_KEY, REL_X, value); 

which libevdev could prevent to some degree. but yeah, let's leave that out
for now until we get a real use-case. for now the uinput code makes it easy
enough to create a device and let it perform properly.

Cheers,
   Peter


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