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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel