SummerOfCodeIdeas

Google / X.Org Summer of Code Ideas

Goal

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.

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 GSoCApplication for guidelines.

X.Org is a large and comprehensive project with a huge number of possible opportunities for interesting Google / X.Org Summer of Code projects. This list contains a few of those opportunities that are particularly interesting to X.Org developers and potential mentors. Please note that these are just suggestions; if you have an idea for something else please ask.

If you have questions, feel free to contact us on the X.Org mailing list or the X.Org IRC channel.

2011 Ideas

The 2011 Summer of Code program has been announced. See the timeline

Wayland Ideas

Xlib

Gallium H.264 decoding

Write a VDPAU state tracker for Gallium. In Gallium, state trackers implement APIs, and generate card-independent shaders. This allows supporting multiple cards with a single piece of code. As part of Summerof Code 2008, a student successfully implemented g3dvl, a video layer for decoding XvMC on top of Gallium. This project separated the video decoding code into two parts: a common vl part, and an XvMC frontend. The result allowed hardware accelerated MPEG2 playback on all Gallium-supported hardware. The purpose of this project is to build upon this code and add H.264 and VDPAU support. This requires improving the vl code for features that differ between H.262 and H.264, and adding a new VDPAU frontend. Furthermore, not all H.264 features can be implemented using shaders (like for example CABAC), so integrating CPU-based and GPU-based acceleration stages together will be another challenge. Ultimately, the purpose of this project is the production of a fully open source chain for hardware video decoding on any Gallium-supported GPU.

Automated testing

We have a tinderbox (http://tinderbox.x.org/), but it could use some love. Ideas: IRC/mail notification of new regressions, graphing of the performance data cairobench and x11perf give us (with automatic marking of regressions), more functional tests. We use jhautobuild, which is written in Python. Possible mentor: ChrisBall.

Gallium Xorg State Tracker

Improve support for the gallium Xorg state tracker. Get it working well on actual hardware as a viable replacement for the DDX.

2010 Ideas

OpenGL 3.2 State Tracker

Add a pure Gallium state tracker for OpenGL 3.0. Right now, Gallium uses Mesa as its state tracker. However, since the Mesa source code also implements software rendering, as well as old-style DRI drivers, this results in a lot of cruft and in particular holds back the addition of new OpenGL features (as those features must be supported in the whole mesa first). The performance of Gallium also suffers, since the state tracker does a lot of things that are later on duplicated in Gallium. This project involves duplicating the current Mesa state tracker and removing all the legacy bits. Then the student will add the necessary state tracker functionality for supporting OpenGL 3.0.

Possible mentor: StephaneMarchesin

OpenGL fixed function "super shader"

Implement OpenGL fixed-function "super shader". Modern graphics chips have stopped implementing fixed-function vertex and fragment paths. Instead, the driver internally converts the fixed-function state to a vertex shader and a fragment shader. On at least one driver (i965), we are able to measure significant overhead due to program changes triggered by trivial fixed-function state changes. Since the programs are compiled and cached, the overhead is caused by simply changing the active program. It should be possible to eliminate a lot of these program changes by having a few "super shaders" that implement common subsets of fixed-function state. Specific operation of these super shaders would be controlled by a few uniforms to enable or disable certain functionality. Ironically, this would make the programmable shader stages look much more like traditional fixed-function stages.

Possible mentor: IanRomanick

VT Switching for GNU Hurd

While XFree86 was first ported to the Hurd more than a decade ago, and there are updates now and then to make newer versions of X.Org run as well, the support is quite rudimentary: in particular, there is no support for switching back to the text console while X is running.

Implementing this requires creating an interface between the X server and the Hurd console, and implementing the necessary code on both sides.

The goal of this project is to get console switching fully working on the Hurd. Some Hurd-specific and X-specific knowlegde will need to be obtained, but the task should be quite doable without previous experience with either. It requires implementing some pieces of code that are not quite trivial, but shouldn't be terribly hard either.

Exercise: Try fixing http://savannah.gnu.org/bugs/?21000, or perhaps some other minor issue with X on the Hurd.

Initial work on porting DRM to GNU Hurd

The Direct Rendering Manager (DRM) is a kernel driver component taking care of graphics hardware access. Originally, it only took care of the 3D acceleration unit, and was used mostly by the DRI (Direct Rendering Infrastructure) in Mesa.

Around the beginning of 2007, the developers came to the conclusion that a more robust and functional graphics stack requires the kernel driver to take care of other graphics access as well: mode setting in particular. (Essentially what the old KGI project proposed, see http://www.kgi-project.org.) Also, with the new GEM interface, the DRM now takes care of graphics memory management as well.

With the new responsibilities, the DRM is no longer an optional addon for fast 3D support, but a central component of the graphics stack. It needs to be implemented by any operating system that wants good Xorg driver support in the future. (Moreover, it is now also useful outside the context of Xorg.)

The Hurd implementation of DRM will be somewhat special, as -- following the microkernel idea -- we want to run the drivers as privileged user space server processes, rather than actual kernel modules.

This task is about doing the first steps for porting the DRM to the Hurd. This can be done by taking one of the existing DRM modesetting drivers (Intel, Radeon or Nouveau), trying to get parts of it running as a Hurd server, and porting/implementing necessary pieces of the general DRM framework as needed along the way.

It is probably not realistic to get the driver fully working over the summer. The goal however is to get at least some parts going.

This task will require obtaining a considerable amount of knowledge about the Hurd and Mach (especially things like virtual memory management) -- it goes deep into system internals. Previous experience with operating system and/or graphics driver development would definitely be helpful.

Exercise: Try to get some part of the driver compiling on the Hurd, using stubs for any system-specific functionality.

Open Source PRIME multi-gpu support

This SoC project involves taking the nvidia optimus technology and implementing the same technology in open source driver stack. Some work has already been done to flesh this out in http://airlied.livejournal.com/71734.html there needs to be more work done in integrating it into the kernel and X.org stacks along with some client side method of picking which apps should be started where. Also the possibility of rendering 2D apps could be investigated.

Possible mentor: DavidAirlie

Complete input support for XCB

One of the main area preventing XCB wide adoption over Xlib is input support. There are some information there about the current status. This SoC project involves porting Xlib keyboard functions to XCB and working on related X extensions (such as XKB, XKB2...).

You don't really have to know XCB, so this project would definitely be a really good starting point if you are interested in low-level X programming and work on something that will be widely used (XCB is supposed to be the future of X client library).

Ask on xcb@lists.freedesktop.org for questions or further details.

2010 Ideas

Many of these 2010 ideas will be valid for years to come.

2009 Ideas

Many of these 2009 ideas are still valid.

2008 Ideas

Most of these 2008 ideas are still valid.

Xserver core

Xinerama

Xdmx

XCB

Xau/Xdmcp

Drivers

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

Misc

DRI

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