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.
- 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.
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.)
More DRI-related ideas are visible on http://dri.freedesktop.org/wiki/GSoC_2008
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
- Fix OpenGL support
- Switch to XF86DRI instead of AppleDRI
- Write a Mesa DRI driver that uses OpenGL.framework
- Switch to XF86DRI instead of AppleDRI
- 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.
- 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