ArchitectureToDo

The Grand ToDo List

What is this?

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

" - XAA is totally unsuitable for accelerating modern desktop usage"

XAA is designed around accelerating the wrong primitives.

Solutions include:

• implementing KAA in Xorg
• using the Kdrive X server (has something other than XAA, right?)
• using Xgl (requires MesaSolo and friends to be ready)

Render Acceleration

" - Render is largely unaccelerated"

This depends on the XAA problem above. XAA isn't suitable for accelerating render.

Solutions include:

• replacing XAA
• using Xgl (see above) Does/did the proprietary nvidia driver accelerate render? How?

DRI FBO/pbuffer

" - DRI really needs pbuffers and fbo's"

Self evident?

There's interest in getting DRI to transfer textures from one process to another for a "glcompmgr." Related?

DRI needs a memory manager

_... assume video memory only large enough to store one texture ... _

_ the first client in general can't assume that its textures are still where it left them. thus we have an sarea. "shared area". when DRI clients dirty some bit of state, they leave a note of what state they touched in the sarea. so our second client would have dirtied the texture state, so the first client knows it needs to push its texture again. now remember we're wanting to share textures between clients. so introduce a third client. 1 and 3 want to share their texture. 1 owns it. 2 runs, evicting the shared texture. 3 goes next, and the texture it wants isn't there anymore. except 3 can't push it, because 3 is trying to pull it from 1. see the problem? 3 never had a copy of this texture. _

sounds like a proper dri memory manager would solve that.

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?

Multiple cursors

_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?

Configuration format

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.

X on GL

DRI is being reworked and merged with the linux framebuffer code. MesaSolo 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.