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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

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




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux