This is a list of fundamental problems standing in the way of a better implementation of the desktop. On-topic items include graphics and input problems and needed features.
To anyone working on these problems, or working on a large problem not listed here: please update this page with comments. It is intended to be a kind of road map, so feel free to comment on what you believe is the preferred solution to a problem.
Non-coding mailing list lurkers are encouraged to update this page if they see a mistake or something that looks out of date. If unsure about a change, put it in italics and put a question mark after it. (Got that?) Someone else will come along and confirm/deny the question.
XAA is designed around accelerating the wrong primitives.
- implementing KAA in Xorg
- using the Kdrive X server (has something other than XAA, right?)
- using Xgl (requires and friends to be ready)
This depends on the XAA problem above. XAA isn't suitable for accelerating render.
- replacing XAA
- using Xgl (see above) Does/did the proprietary nvidia driver accelerate render? How?
There's interest in getting DRI to transfer textures from one process to another for a "glcompmgr." Related?
_... assume video memory only large enough to store one texture ... _
Right now DRI uses some kind of "peer to peer" memory management technique. DRI really needs to start managing video and agp memory for the clients. This would enable passing textures from one client to another without copying and without the possibility of deadlocking.
Additionally this would reduce the complexity of clients.
Presumably, DRIMM would be responsible for moving data between video memory, agp memory, and it's own storage in main memory tying all of the information to the process it belongs to.
Would this eliminate the need to map video memory into the client's address space? or Would it make it easier to implement memory protection so that one client can't start scribbling on another client's video data just for fun?
_Shared projector systems have serious need for multiple simultaneous streams of input. _
_I recently had a chance to play with the projector table at MERL, and we can expect similar such devices as commercial products over the next couple years; it provides a compelling demonstration of the need. _
- - Jim Do we handle this with multiple cursors? Or do with handle with by making applications explicitly request input from many cursors?
There has been noise about an elektrified x server and machine vs human readable configuration file format. The x server itself does need a configuration makeover, but by a more general mechanism. XHotplugProposal would like to do with with some sort of external configuration client. This would enable a legacy X! client, an elektrified client, a HAL-based client using dbus, etc without introducing dependancies for the X server itself. The other advantage to using a client is hotplug. See the dynamic reconfiguration section above.
DRI is being reworked and merged with the linux framebuffer code.is being prepared and mode selection code is being rewritten. (right?)
Xgl is a proof of concept server, but without the above, it cannot run except inside an ordinary X server. As soon as the above are ready, we will have a legitimate possibility for moving all rendering onto the GL API as a standalone GL X server.