[Xevie] Re: My current design efforts

[Deron Johnson]

Keith Packard wrote:

> It would be nice if Xevie could work with the event redirection client 
> running on a separate address space.  Otherwise, we'd be adding the first 
> ever non-network capable extension; a distinction I'd certainly like to 
> avoid...

I don't think I'll need to affect Xevie in any way which makes it use
shared memory. But if the Display Server needs some fast way to get
data from the X server I am not adverse to using shared memory to get
it, provided that it results in a significant performance boost. I see
the Display Server as a special client which is more or less a local
process which is an augmentation of the server. It has taken over
responsibilities (such as drawing) that were once in the exclusive
province of the server. Also, because it controls the display, the
Display Server will never be a remote client.

Here's a quick status update on my progress so far. I've implemented
the "Z model" where the events go from the X server through Xevie to
my Display Server, which does a pick and then sends the events back
through Xevie to the Xserver. The Xserver processes these events and
sends the X ones to X clients and sends the 3D ones back to the Display
Server. It turns out that there is a whole bunch of information that
needs to ride along inside a 3D event so in order to deal with this
for each 3D event the DS sends back to the X server it creates a "buddy
event" which it keeps around in the DS address space and it sticks a
reference to this buddy event in an unused field of the xEvent structure
(I'm using 'child' right now). When the event comes back to the Display
Server after being processed by the X server, I extract the buddy
reference from the event and use this to access the rest of the 3D event
data. I've implemented this model and I've achieved basic sanity, but
there are a variety of bugs still to be fixed.

I did need to make some modifications to Xevie in order to achieve this,
but they are all bug fixes that I'll deal with through bugzilla.

One issue that we need to address with Xevie is that xevie shuts off
when a client grabs the server. We'll have to introduce a mode to make
xevie immune from server grabs.

I've done some timing studies on the cost of the initial round trip from
the X Server -> Display Server -> X server. The incremental latency
overhead is negligible most of the time (around 0.25 ms). But
occasionally I measure an overhead spike of about 220 ms. This blows
by latency budget (which is about 20-30ms per event). I suspect that
these spikes are due to context switching between the Display Server and
the X server but I haven't yet proved it. If this is the case, then I
may be able to tune the Display Server kernel thread priorities to
minimize this problem. But at this point I still haven't ruled out the
use of shared memory to help solve the problem. If I can't reduce the
latency spikes then I may need to revert to my previous design of doing
the grab processing over in the Display Server. But rather than shipping
window hierarchy information from the X server to the Display Server
using the event channel, I may try to introduce shared memory access
to the window hierarchy itself. I hope that I don't have to go this
route, but I'm not yet sure enough of the Z model to eliminate the
need for a backup plan.