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