SummerOfCodeIdeas

Google / X.Org Summer of Code 2009 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.

Current Ideas

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.

• XCB ideas

  • A complete implementation of x11perf-xcb. Some preliminary work has already been done by BartMassey <bart@cs.pdx.edu>, but much remains.

  • Complete and comprehensive input support for XCB. This includes some form of Xkb and Xkb2 support.
  • Add support of missing GLX extensions and libs.
• DRI ideas
  • Gallium is still missing a few pipe drivers. The big one for which we have docs but no code is r600. This could be copied from r300 somewhat, but would require some extra changes elsewhere and there's a fair amount of kernel work left to do as well.

  • 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. During last year's Summer of Code, a student successfully implemented MPEG2 decoding as a gallium state tracker (g3dvl). This project separated the video decoding code into two parts: a common g3dvl part, and an XvMC frontend. The result allowed hardware accelerated video playback on all Gallium-supported hardware. This year, another student could build upon this code and add H.264 and VDPAU support. This requires improving the g3dvl 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 will be another challenge. I (StephaneMarchesin) can mentor this project.

  • 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. I (StephaneMarchesin) can mentor this project.

  • Porting DRM to Hurd

  • 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. IanRomanick can mentor this project.

• EXA ideas
  • Migration clairvoyant: Buffer rendering commands (e.g. 100), so EXA can know in advance that a following operation would trigger a fallback, and omit moving contents into VRAM. This could solve migration ping pong for many common cases.
• Driver ideas
  • Implement nouveau TV-out support. This will require picking up a card or two and figuring out how TV encoding works on them (integrated, separate chip, etc.) then how to program the chip (by reverse engineering, or because the chip is documented). Then the student should implement TV-out support as part of the randr 1.2/1.3 framework.
• Core X ideas

  • libpciaccess port to Hurd

  • VT switching on Hurd

  • Support Graphics Card hot-switch -- http://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/312756

• Input ideas
  • XGrabKeysym(), probably as part of Xi2, so clients don't have to monitor for keymap changes on hotplug/xmodmap

  • https://bugs.freedesktop.org/show_bug.cgi?id=11227 (allow >255 keycodes)

  • https://bugs.freedesktop.org/show_bug.cgi?id=931 (replacing libxkbfile with something better)

  • merging xkbcomp into the server
  • X multi-touch hardware and integration with XI2
  • something to replace XEvIE in the new input world
• Automated testing ideas

  • 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. Contact: ChrisBall.

2008 Ideas

Most of these 2008 ideas are still valid.

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

Xinerama

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

Xdmx

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

XCB

• Auto-generate server-side protocol stubs from XCB's protocol descriptions
• Implement a new language binding for XCB
• 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.

Xau/Xdmcp

• 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.

Drivers

• 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)

Misc

• 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.
• Get multiple video cards working again

DRI

• 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.

SummerOfCodeIdeas (last edited 2009-03-23 20:34:44 by IanRomanick)

• Immutable Page

DeleteCache (cached 2009-06-28 02:37:43)

Or try one of these actions: Attachments, CopyPage, Despam, LikePages, Load, LocalSiteMap, MyPages, PackagePages, RenderAsDocbook, Save, SpellCheck, SubscribeUser, SyncPages