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

[Peter Hutterer]

On Wed, Apr 05, 2017 at 11:15:05AM +0100, Steven Newbury wrote:
> On Wed, 2017-04-05 at 11:57 +0200, Bastien Nocera wrote:
> > On Wed, 2017-04-05 at 10:42 +0100, Steven Newbury wrote:
> > > 
> > 
> > <snip>
> > > There's a reason the mouse support from the X DGA Extension out-
> > > survived the "direct framebuffer access".  The latency through the
> > > wire
> > > whether X or Wayland for mouse input it just too high for mouse
> > > controlled high framerate 3D games.  inputfd *will* be wanted for
> > > mice,
> > > and unlike keyboard there isn't the issue of state.
> > 
> > SDL2 doesn't use the DGA extension, which makes me think that it's
> > not
> > as much of a problem as when running Doom in X in the 90's.
> > 
> AFAIK SDL2 uses the Xinput2 extension for pointer/relative mouse
> devices nowadays, which with current Xorg is on its own input thread
> which helps a lot.  That said, gamers do claim better latency from
> Windows DirectX than Xorg.
> 
> > That being said, I see no reason why the compositor couldn't consider
> > the mouse to be a "gaming device" when a number of conditions are
> > met,
> > such as the application being fullscreen, and the mouse having been
> > grabbed.
> > 
> > The compositor could then yank this device out of the application's
> > reach when unfullscreened, or the grab broken. Again, this is the
> > compositor's choice. And I'm certain that we'd extend most
> > compositors
> > that way if game developers requested the functionality.
> Probably benchmarking the difference would suggest whether it's
> worthwhile or not.

there's another factor that matters: inputfd would give coordinates in the
device-native resolution(s) which is a behaviour that gamers are rather
attached to. libinput mangles it to 1000dpi equivalents to provide the same
behaviour on the desktop for (most) hardware, but in games that's not
desired.

but FTR, I too don't see reason why we can't have mice exposed through
inputfd as well.

Cheers,
   Peter