[Xevie] My design status

[Deron Johnson]

Amir Bukhari wrote:
> 
>>-----Original Message-----
>>From: xevie-bounces at freedesktop.org [mailto:xevie-bounces at freedesktop.org]
>>On Behalf Of Deron Johnson
>>Sent: Tuesday, November 09, 2004 8:55 PM
>>To: xevie at freedesktop.org
>>Subject: [Xevie] My design status
>>
>>Here is a status update on my thinking regarding the design of the LG
>>event system. Around August of this year I was pursuing a design in
>>which the grabbing was done in the Display Server. In order to achieve
>>this, topology changes to the window tree would be sent from the X
>>server to the LG Display Server whenever a change occurs to the window
>>tree. Based on my last communication with Keith, and other factors, I
>>have for the past few months been prototyping and evaluating what I
>>had hoped would be a simpler approach which I call the "Z model." In
>>this design, the raw device events flow from the X server to the
>>Display Server, the 3D pick happens, and then the events are sent back
>>to the X server for grab processing. If the events are 3D events bound
>>for 3D apps then these events are sent back to the Display Server.
>>(I call it the "Z model" because if you look at the architectural
>>diagram, the stream of 3D events forms a "Z" as it goes between the
>>X server and the Display Server).
>>
>>After investigating this design for several months I have come to the
>>conclusion that the Z model is inferior to my original
>>"grab-in-display-server" model for several reasons:
>>
>>1. The path that 3D events take is more convoluted in the
>>   Z model. Events are bounced between the two processes
>>   like a badminton birdie. This affords more chances to
>>   introduce additional latency overhead.
>>
>>2. In LG, 3D events (for various reasons) need to carry some
>>   information that results from the 3D pick information. This
>>   information is too voluminous to squeeze into an event, so
>>   I tried to store this information on the DS side and match it
>>   back up with the events when they return to the DS. I got
>>   something that sort of works but it has weaknesses. In general,
>>   it has the feeling of a kludge.
>>
>>3. After reviewing countless grabbing scenarios in my mind I have
>>   come to the conclusion that the decision for when a passive
>>   grab activates must occur in only one place in the system.
>>   I've looked at distributing some of the decision making between
>>   the DS and the X server and these designs all have potential
>>   race conditions. What this means is that we must bring the
>>   following three pieces of information together into one place:
>>   the event stream, the X window tree and the 3D scene graph.
>>   I have investigated ways to bring the 3D scene graph over to
>>   the X server but they are all complicated or have poor
>>   performance. I've come to the conclusion that the simplest
>>   and best performing scheme is to bring the necessary
>>   window tree information into the DS.
>>
>>So after several months of spinning my wheels and bumping into
>>a variety of constraints, I have decided that the most robust
>>architecture for the long term is to just rip the necessary
>>guts of the X server event and grab handling out of the X server
>>and put it in the DS, route the event stream from the X server
>>to the DS, do all of the event handling in the DS, and only
>>send back to the X server those events which are destined for
>>X clients. Although this will be a significant implementation
>>effort, it has an architectural simplicity that the Z model
>>lacks. Also, it is an approach which is more forward looking--
>>in the (far?) future when 3D apps predominate, and X apps are
>>merely legacy, the "Grab-in-DS" model will be more concise and
>>have better performance characteristics.
> 
> 
> At that the time Xsever send input event to DS, could it perform other task
> or it block until DS send it an event back as you do it now? 

I'm not sure what you mean by this. Please clarify.

> Or in other
> words would you use an existing extension or you build a new one?

There are several choices for how to send events from the X server
to the DS. First of all, we can probably use XEVIE for this. In my
investigations I discovered some bugs in using XEVIE to send events
from the DS back to the X server, but this wouldn't be needed in the
"Grab-in-DS" model. (Note: the Xserver-to-DS part of XEVIE seems to
work fine, modulo some byte swapping problems).

Another option would be to use the multi-level input redirection feature
that Keith has been talking about. But I'm not sure what his timeframe
is for implementing this.