Xorg always needs more work and more contributors. Several tasks anyone can help with are listed below. Don't feel limited to these suggestions, and feel free to add your own suggestions to the list.
Server
Janitorial things
These are largely mechanical things, suitable for someone who's just getting started and needs a way to get familiar with the server.
- The diagnostic messages printed in the log file are confusing. They range from uninformative, to misleading, to flat out wrong. The message severity levels are frequently wrong as well. Bug 3116
- Driver option names are inconsistent.
- Many drivers are underdocumented.
- The X codebase is quite crufty and could use a lot of cleaning up.
- Triage open bugs in bugzilla.
- Review and test patches in bugzilla and from the xorg mailing list.
- Remove CVS tags inside of files.
See more possible work in the Janitor page.
Minor development
These are relatively self-contained problems, suitable for someone who knows how to program but doesn't necessarily understand the whole server.
- X server backtraces could potentially be more useful. glibc's backtrace() isn't great. Maybe fork() gdb? Maybe link against libelf and walk the the symbols ourselves?
- XAA is lacking. See ExaStatus for status on the replacement.
- X server protocol dispatch is still handwritten. We should generate it from xcb-proto instead.
- Extend shadow to be something you can have per-drawable instead of per-screen.
- Loader: Remove the abstraction from the loader (hw/xfree86/loader) so it's just a simple libdl wrapper with the same API, and punt it up to the DIX, so all DDXes can use it.
- Remove statics: Make MAXSCREENS and MAXFORMATS run-time configurable, ditto MAXCLIENTS. ajax started a patch for MAXFORMATS, bother him about it.
- Code removal: Remove anything that's unused and/or bad.
- Port the int10 code to libx86. mjg59 and vignatti had started on this (from opposite ends).
- Build the "X server awesome scheduler":
- What we want is simple: a preemptive scheduler with priorities (real-time scheduler) to deal with multiple clients and with a special care for input events. One interesting thing to considerer is that the issue of long-lived requests is mostly a thing of the past. PolyLines are not that common, fonts are mostly client side, and OpenGL is usually client-side as well due to DRI. Moreover, clients can block each other. Just try to execute a
x11perf -getimagexy500plus play a video to see. x11perf eats all the X process. Isn't wiser to give a tiny quantum here for each client? The funny thing is that -dumbSched gives a better result than with the smart scheduler :) So simultaneous client requests aren't dealt by smart scheduler at all. This is quite interesting for those who is trying to start in the X world because it doesn't touch much of the graphics oddities :)
- What we want is simple: a preemptive scheduler with priorities (real-time scheduler) to deal with multiple clients and with a special care for input events. One interesting thing to considerer is that the issue of long-lived requests is mostly a thing of the past. PolyLines are not that common, fonts are mostly client side, and OpenGL is usually client-side as well due to DRI. Moreover, clients can block each other. Just try to execute a
Major development
These are big cross-cutting things. Much of this is just ajax's wishlist.
- Rewrite the bottom of the rendering layer. The old Get/Set/FillSpans API was appropriate when your memory aperture was all of 16 bytes, but this is really not the case anymore. Should move to GetImage/PutImage/PolyFillRect/CopyArea.
- Redo Pictures. Right now they're like a GC and a Drawable in one, which makes things really awkward.
- More generally, detach rendering from the ScreenRec. Wrapping is a useful technique, but most useful if the thing with the wrap chain is something you can create temporaries of, which ScreenRec is not.
- Extend Xdmx to act as a drop-in replacement for Xnest, and delete the latter.
- Extend Xdmx to use the XI2 model of input devices.
- Port to any new platforms we need support for.
- Make one set of Xinerama protocol routines for use by Xinerama and Xinerama-emulating code such as randr-1.2 and driver MergedFB code.
- Make one set of logical screen to graphics device splitting code out of the Xinerama & Xdmx code bases.
- Enable more input devices, in particular speech recognition, by allowing events to specify keysyms. It can be very difficult to convert dictation to keystrokes; it is much easier to transmit unicode directly to the application.
DRM
- See DRMJanitors
Utilities
- xrandr is still a bit touchy. The failure modes are not obvious, CRTCs are magical, etc.
- Input device utilities (xmodmap, setxkbmap, xkbutils etc.) need to deal with multiple devices (MPX/Xi2).
- xev needs to learn how to display events added in recent extensions, such as Xi2, RandR
- Should xprop work with input device (Xi2) and output device (randr) properties too?
- xdpyinfo could probably use some updates to the -ext support for newer extensions.
- Port utilities (one at a time) from libX11 to xcb
Testing
- For general information on helping with Xorg testing, see the TestGroup page.
- Specific information about release testing can be found on the XorgTesting page.
Related Projects
- xcb: See XCBToDo