[RFC wayland-protocols] inputfd - direct input access protocol

[Peter Hutterer]

On Tue, Apr 04, 2017 at 08:52:03AM +0100, Steven Newbury wrote:
> On Tue, 2017-04-04 at 13:42 +1000, Peter Hutterer wrote:
> > On Mon, Apr 03, 2017 at 10:19:16PM -0500, Joshua Watt wrote:
> > > 
> > > 
> > > On 04/03/2017 07:22 PM, Peter Hutterer wrote:
> > > > On Tue, Apr 04, 2017 at 08:16:03AM +0900, Carsten Haitzler wrote:
> > > > > On Fri, 31 Mar 2017 17:29:19 +1000 Peter Hutterer <peter.hutter
> > > > > er at who-t.net>
> > > > > said:
> > > > > 
> > > > > If you're going to do this ... why not just do it for
> > > > > keyboards, mice, touch
> > > > > panels etc. too?
> > > > 
> > > > all these have desktop interactions that the compositor needs.
> > > > joysticks
> > > > generally don't, the compositor doesn't care about the events.
> > > 
> > > Is that really true? It seems like there are certainly use cases
> > > where a
> > > compositor *would* use the Joystick or gamepad as a primary
> > > navigation
> > > device (think SteamOS or some IVI shell). Maybe it could be said
> > > that these
> > > are all going to be custom compositors at this point, but I
> > > wouldn't want
> > > discount that such behavior could be desired in the future.
> > 
> > yes, you're right, but let me be more precise: keyboards/mice/...
> > always [1]
> > have desktop interaction, the need to pipe them through to an
> > application is
> > relatively niche. So unlike joysticks, the compositor cannot ignore
> > them.
> > (and this was mostly in reply to the "sticking your head in the sand"
> > accusation)
> > 
> Couldn't it be possible to snoop on the inputfd stream and listen for
> "compositor events", i.e. system global buttons. Obviously modifying
> the stream would add undesirable latency so it probably wouldn't be
> possible to filter out those "compositor event" buttons, not sure how
> much that matters..?

evdev supports masking events, so the solutoin for that would be to open the
device twice, once masking everything but BTN_FOO and once masking only
BTN_FOO - that's the one to pass to the client. Then you don't get wakeups
for other buttons in the compositor and you know the client won't ever
receive BTN_FOO.

> > inputfd only gives you access to a device, it doesn't dictate how the
> > device
> > is used otherwise. IOW inputfd lets you use the joystick in the
> > compositor,
> > all you have to do is implement correct focus management.
> > That's an improvement over the current situation where you have
> > multiple
> > processes accessing the device working with a cooperative model.
> > 
> This is why it's really needed, games need the minimum latency they can
> get, an input arbitration model is essential.  I wonder if a new
> inputfd X extension wouldn't be possible too?  Currently, many games
> just directly open evdev or input/js devices which isn't really ideal.

maybe, but that's a lot more complicated that it would seem at first, and
in the X world of everyone having access to everything directly opening the
evdev node isn't much worse than the situation we already have :)

> > Note that it is also possible with this protocol to have a
> > keyboard/mice/...
> > fd passed to the client if the latency of going through the
> > compositor is
> > too high. Not in the immediate draft, but it's just one
> > get_seat_keyboards()
> > or get_seat_mice() away.
> Getting especially mice through inputfd is something people are
> definitely going to want, especially for FPS type games, and
> particularly now "serious" gamers are using extremely high screen
> refresh rates ie 120/144Hz.

good point.

Cheers,
   Peter