Re: [PATCH] Input: evdev - add EVIOCREVOKE ioctl

["Bruno Prémont" <bonbons@linux-vserver.org>]

Hi David,

On Wed, 04 February 2015 David Herrmann wrote:
> On Wed, Feb 4, 2015 at 2:12 PM, Bruno Prémont wrote:
> > Hi David,
> >
> > Sorry for reviving this old thread (I didn't find more recent patch series
> > at first glance or have not been using the proper keyword while searching).
> >
> > At FOSDEM 2015 last Sunday Hans presented libinput X input driver and mentioned
> > evdev FD revoking.
> >
> > A question I raise was how are input devices to be put in a reasonable
> > state on FD revoking?
> > The specific case of force-feedback game-pads/wheels and the like that libinput
> > is expected to pass through to games was the main trigger.
> >
> > Assume:
> > - Game triggers some force-feedback event like vibrating device
> > - Game looses focus and gets its evdev FD revoked
> > - Newly focused application does not care about the game-pad/wheel
> >
> > How should the force-feedback activity get stopped on that focus change
> > and thus FD revoking?
> > Is the game expected to react before the FD being revoked (how long to
> > wait?) or should the kernel somehow reset the device to a sane state on
> > revoke (and if so, under which conditions?).
> >
> > Should some other evdev devices also receive a special treatment to reset
> > them into a known/idle state (eventually LEDs on keyboards, beep, ...)?
> 
> We call input_device_flush() on EVIOCREVOKE, which stops any ongoing
> FF owned by this handle. Same should be done for any per-handle state.
> However, LEDs are not associated with a handle, so it will stay the
> same. Applications are expected to re-sync their LEDs after they
> revoked a file-descriptor of someone else.

Thanks for the explanation!
It answers my question.

So all that's needed should be there unless a specific kernel-side driver
does not properly have state associated to handles.

> Thanks
> David

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