On Wed, Jun 20, 2018 at 8:19 AM Adam Jackson <a...@nwnk.net> wrote: > 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. >
I remember trying to do this at one point for gnome-shell's magnifier mode, and found some severe performance issues. I never dug deeper, because of the other issues I saw, but I was seeing actual latency with my eyes. It's probably just a bug, though. > > 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. > Yep. GDK's client-side windows also attempts to emulate an X server given that GdkWindow is modeled after an X window, or at least it was in the GTK+ 2.0 era. It would be wonderful to have the code to Enter/Leave correctly and all that fun stuff in a library for people to reuse, so that they can set up a window tree and "be as X11". To be clear about the full list of issues I encountered, at a basic level: * Active grabs obviously break your COW trick. GTK+ menus broke. I hacked around this by taking an active grab on my COW from start and letting the fallback path of GTK+ take over. * XSendEvent skips passive grabs, which some clients did not like. I forget which app was using passive grabs a lot, but when it saw a ButtonPress event it then tried to call XChangeActivePointerGrab to convert it into an active grab, and when that failed it crashed. I forget if I fixed this. * Clients can call XQueryPointer when receiving a FocusNotify to figure out where their pointer is. Most of the time, this isn't an issue, but the regression is that if you hover over a button in GTK+, Alt-Tab away, then Alt-Tab back, it would highlight the wrong part of the window. I fixed this by sending a fake MotionNotify after focusing the client which mostly got it on the right track. * Similarly, some application set MotionNotifyHint and then called GetMotionEvents. I was unable to fix this. * Java's AWT filters out some synthetic events for some unimaginable reason. Also, similar problems, but now do it all over again for XI2. And touch input. I never even bothered to start with that. > > 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. > Yeah, but this is a compositor implementation detail. Similarly, an X11 window manager could choose to talk some private protocol to other components and help manage windows. gnome-shell certainly does, even on X11. The distinction is that it is *possible* for a compositor to be in charge of the event tree and sending events to clients. It is not possible, at a general sense, to do the same in X11 without severe hacks. Maybe if the RedirectCoordinate and TransformCoordinate parts of Composite were finished and implemented, things would be different today. I don't have any context into why those never got in, though. > - ajax > -- Jasper
_______________________________________________ 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
