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

[Daniel Stone]

Hi Steven,

On 5 April 2017 at 11:04, Steven Newbury <steve at snewbury.org.uk> wrote:
> On Wed, 2017-04-05 at 10:53 +0100, Daniel Stone wrote:
>> 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
>
> I wondered if I was implying that too strongly as I wrote it, I know it
> didn't provide a direct-to-kernel stream.  Are you sure it didn't also
> reduce latency though, even if only because it skipped the acceleration
> code as you mention below? I suppose latency was bounded by the main
> thread?

As with everything, it depends. ;) The acceleration code is very light
indeed on modern platforms. What it did gain you in some cases was
avoiding traversal of the window tree, which on much older machines
with much much more complex window trees (one per widget!), could make
a difference. So I'd say on older machines you'd see a reduction in
best-case latency, but that would still be utterly blown out by your
worst-case latency blocking on client rendering / buffer copies.

>> 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.
>
> It's certainly sufficient for most use cases.  Are you sure about
> DirectMouse parity?

Yep - conceptually, kernel -> server (much lighter processing than
usual) -> client, with those protocols, is exactly the same as
DirectMouse.

Cheers,
Daniel