Hi On Wed, Feb 4, 2015 at 2:12 PM, Bruno Prémont <bonb...@linux-vserver.org> 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 David -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
