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

[Daniel Stone]

Hi Steven,

On 5 April 2017 at 10:42, Steven Newbury <steve at snewbury.org.uk> wrote:
> On Wed, 2017-04-05 at 10:25 +0100, Daniel Stone wrote:
>> 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.

DGA's DirectMouse doesn't change the latency. It doesn't give the
client a direct-to-kernel stream. It still results in the server doing
some light internal processing in a signal handler, placing them on a
queue, waiting to wake up, and then posting them to the client from
the main thread. Its actual benefit was to give clients access to
unaccelerated relative motion vectors. So the relative/confined
pointer protocols put us on a par with 'DirectMouse' already there.

I would suggest it only outlasted the direct framebuffer access
because we later got DRI{1,2,3} for free with GL games, and because
unlike direct framebuffer access, it wasn't catastrophically broken by
later hardware.

Cheers,
Daniel