The X.org board treats GSoC as an opportunity to teach new developers rather than a chance to get a pile of free code. With this perspective, if, in two months, the student actually has learned how to contribute to X Window System, that's a huge step forward. Creating a project which guides this process with a maximal chance of success is the only tricky part.


Ideas for projects for students looking to participate in Google's Summer of Code. Please note that these are just suggestions; if you have an idea for something else please ask.

When writing a proposal, please remember to make it detailed. Include at least the information called for in "What should a student application look like?", but including milestones and a project schedule is even better. See X.Org-GSoC2008-Application for guidelines.

Xserver core

  • Move the dmx muxing code into the server to replace the existing xinerama mux code
  • EXA support for surfaces larger than the hardware limits
  • Infrastructure for direct-rendering GL windows larger than the hardware supports
  • Investigate redoing miarc/miwideline/etc. for smaller size and better performance


  • Composite/Xinerama integration
  • Hotplugging additional local and remote displays
  • Auto enabling and disabling Xinerama screens.
  • Make Xinerama handle more than just X screens


  • Integrate with the rootless code a la Xdarwin and Cygwin/X, for floating window migration
  • Add support for Fixes/Damage/Composite
  • Fix input


  • Auto-generate server-side protocol stubs from XCB's protocol descriptions
  • Implement a new language binding for XCB
    • Finishing the Haskell language binding would be really cool.
  • Implement a more complete test suite for XCB
  • Port Gdk and/or Qt to XCB
  • Port the important X utilities (xdpyinfo, xhost, etc.) to XCB
    • The XCB demos include partial ports of xdpyinfo and xrandr.
    • You'd have to port a lot of applications to make this an interesting Summer of Code project.
  • See XCBToDo and Bugzilla(XCB) for more ideas, or contact jamey@minilop.net or xcb@lists.freedesktop.org.


  • Implement the XDM-AUTHORIZATION-2 authentification protocol for better IPv6/XDM support. (See Bug 277 and the never-adopted draft of the XDM-AUTHORIZATION-2 changes to the XDMCP protocol spec.)
  • Replace the old/uncompiliable KERBEROS-5 authentication with GSS-API authentication.


  • Add more support for EXA in the drivers; see ExaStatus for a list.
  • Add dualhead support to an unsupported chip (trident, mach64, s3virge, nv, etc.)
  • Add basic DRI support to an unsupported chip (trident, s3virge, glint, siliconmotion, etc.)
  • Do some work on nouveau ; ideas include adding 3D support for more cards, better Xv/XvMC support through gallium, suspend/resume support, (see our TODO page for more ideas)
  • More DRI-related ideas are visible on http://dri.freedesktop.org/wiki/GSoC_2008

XQuartz (OSX)

Some of these might require changes to libXplugin (proprietary Apple code), but Apple is more than willing to provide the needed hooks. Just join the xquartz-dev mailing list

  • New extension support
    • RandR
    • Composite
  • Fix OpenGL support
    • Switch to XF86DRI instead of AppleDRI
      • Write a Mesa DRI driver that uses OpenGL.framework
  • Top-Of-Tree syncing
    • input model, keymapping needs to be reworked
  • Copy/Paste proxying between OS-X and X11
  • Eliminate the need for AppleWM extension to allow other WMs to work better
  • Handle exposé / spaces events inside the X server rather than quartz-wm (so other WMs can be used)
  • Compositing window manager to replace quartz-wm (once Composite is enabled)


  • Add test cases for more extensions, especially newer ones like Render, Composite, etc. (possibly to XTS5; see TestGroup wiki)
  • Introspection extension to support tools like xscope
    • Would allow querying for request names and structures in generic fashion
    • Look at xcb-proto descriptions
  • Integrate NX in XCB or X protocol
  • Create GUI or textual tool for assisted editing of XKB configuration database.
  • Formally documenting XKB configuration syntax and configuration database structure.


  • GLX_EXT_texture_from_pixmap
    • Update to latest spec
    • More efficient implementation, ideally texturing directly from offscreen pixmaps
  • Integrate properly with Composite, in particular, render to redirected windows correctly
  • Port new memory manager changes to drivers other than i915
  • make the X server's Xsync extension use DRM vblank waits or signals (really a DRI/X cross project)
    • rough patch is already available
    • developer would get good exposure to server and DRM internals

See also: ToDo, Releases/7.4, DRI ideas list.