RFC: Presentation for Desktop Architecture meeting

[Lionel Ulmer]

OK, here is my wish list from the X.org guys:

 - relative mouse movement reporting. This is a must-have to have proper
   DInput support without the hacks we currently have in the code. Extension
   already discussed with X people on the mailing lists and they seem OK
   with it. Now we just need to find someone who codes it :-)

   As said, need to check if the XInput stuff could be re-used (last time I
   checked no as you cannot take control with XInput of the 'core' device -
   i.e. the mouse).

 - full support for resolution / depth switching. A nice idea was discussed
   the other day on the fd.o lists: what about being able to easily start a
   new display using an X API which would start a new X screen. This screen
   could then be used for full-screen games and would support any requested
   depth / resolution change (the problem with the former - depth change -
   is that clients need to support it and so the 'new screen' idea would
   solve this problem as one could still have legacy X applications running
   on the 'main screen' while still have complete control of depth /
   resolution on this secondary screen).

Then some 'nice to have' which would help in the GL / D3D front but may be
out of FD.O scope (and for which work-arounds are known):

 - GL (GLX ?) extension which would remove the 'thread-affinity' from GL.
   I.e. a GL context would be at the process level and not at an application
   level. An even better solution would to be able to create 'shareable'
   contexts which another thread could attach to (i.e. remove the one thread
   <=> one context rule).

 - GLX extension that would export the 'clip-list' functionnalities of cards
   (or at lest the one which is in the X code itself). Would help on
   applications (like Wine) that do their own in-window clipping.

 - same point as before but for Xv the day we will re-add this code for
   accelerated YUV display.

Some 'misc' stuff that is really in the 'we could use it' category:

 - have 'connection-level' configuration. Basically, if a client X change an
   X setting (resolution, mouse acceleration, ...), as soon as this client
   exits, restore the previous configuration. Would be useful to prevent
   having people restarting X because Wine crashed after having changed the
   resolution using XRand.

 - have a non-connection limited mouse-grab. To explain better, this would
   enable one to grab the pointer into a window (i.e. the mouse would never
   leave this window) while still sending events to all connections and not
   only to the connection which started the grab. This could be nice to
   simulate 'full-screen desktop mode' or for DXGrab. No idea if with Wine's
   current event model this is still usefull though.

Another 'let's dream' possibilities:

 - direct frame buffer access :-)

And finally, not in my domain, but investigate re-using something from FD.O
for the fabled DIB engine (extensions to Cairo, ...) ?

       Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/