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

[Steven Newbury]

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..?

> 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.

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170404/226eb006/attachment.sig>