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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
