Hi

On Wed, Feb 4, 2015 at 2:12 PM, Bruno Prémont [off-list ref] 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html