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

[Steven Newbury]

On Wed, 2017-04-05 at 10:25 +0100, Daniel Stone wrote:
> Hi,
> 
> On 5 April 2017 at 04:40, Carsten Haitzler <raster at rasterman.com>
> wrote:
> > On Tue, 04 Apr 2017 14:45:13 +0200 Bastien Nocera <hadess at hadess.ne
> > t> said:
> > > There's two possible solutions to this problem:
> > > - evdev gives you the ability the mask certain events. The
> > > compositor
> > > can keep one fd open masking everything but the power/menu/etc.
> > > buttons, and pass an fd to the app with just the power/menu/etc.
> > > buttons masked. The compositor can then choose to do something
> > > special
> > > with those buttons
> > > - you can specify a new fd_type, as mentioned in the spec, which
> > > your
> > > application would need to know how to handle. That can be used to
> > > implement the simpler protocol that got sent a couple of months
> > > ago.
> > 
> > then explain to me the argument where for example keyboard input
> > should NOT
> > also then do the same thing?
> 
> Because, as stated up thread, keyboard and mouse devices involve
> desktop interaction. So there we have our reason why it is essential
> for the compositor to intercept _all_ keyboard and mouse events (any
> keyboard event could be Alt-Tab, any mouse event could be moving out
> of focus, etc: you cannot filter individual events), which does not
> hold true for gamepad/joystick events (the filter suffices).
> 
> Secondly, keyboard and mouse events work completely differently.
> Mouse
> events have acceleration applied, and the client's view of
> acceleration _must_ match that of the compositor's in order to
> achieve
> the same view of position. I don't much feel like encoding an
> acceleration algorithm in the protocol for all time, just because it
> seemed like a good idea from 50,000ft.
> 
> Keyboard events carry state which is longer-lived than focus. For
> example, press caps lock and change your focus. (Please no-one
> smartly
> chime in about ctrl:nocaps, which FTR I also use.)
> 
> The compositor _must_ interpose every single keyboard/mouse event,
> and
> they are simple enough that it is possibly to easily encode them with
> universally-accepted concepts. Neither is true of gamepads or
> joysticks. Hence, a different protocol.
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.  Arbitration
between desktop use and focused application utilising inputfd is the
issue IMHO, and as Carsten says, I don't see why that is any different
than if a game controller is your primary input device.
-------------- 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/20170405/752a4680/attachment.sig>