A question about XCompositeRedirectSubwindows

[Adam Jackson]

On Tue, 2018-06-19 at 17:35 -0700, Jasper St. Pierre wrote:

> First off, there's a super high latency cost here.

There is a latency cost, but I think it's worth being honest about it.
I'm on whatever iteration of the Dell XPS laptop was a Skylake, and:

    2000000 trep @   0.0131 msec ( 76100.0/sec): QueryPointer

You get 70k round trips a second? That... might actually be enough. You
have sixty frames, so that's like a thousand per frame, and then the
USB interrupt rate is only like 1kHz so you only need to service 16
per frame anyway. Okay, this is a 3GHz machine; at 300MHz - assuming it
scales linearly - your round trip budget is a hundred per frame, you'd
still have like 80% of the CPU left.

> Second, actually filling in the correct event is unobvious and
> tricky, especially when dealing with XInput2. It would require
> building the equivalent of an X server inside your CM to send.

It turns out there does already exist a library of code that implements
these state transitions the way an X server would. It is: the X server.
One of my "never got enough around to" projects was making the server
code sufficiently library-like that you could embed an X server the way
libssh means you can embed an ssh server. It's honestly not far off.

> To be honest, this problem was one of the original problems that
> Wayland tried to solve. In the Wayland architecture, the display
> server and compositing manager are combined into a single process, 

This is not an essential feature of the Wayland model. The compositing
manager could, like an X compositing manager, be a separate client,
interacting with an essentially separate set of protocols, and the
display server would merely be a broker of handles to surfaces, some of
which happen to be bound to hardware that displays pixels.

No extant wayland server _does_ this, as far as I know. But it has some
appeal.

- ajax