X.Org GSoC 2010 With KMS, Cairo, Etc. What Was Done?
While most of the X.Org GSoC 2010 projects are centered around graphics (and that's where our interest happens to be too), one of the input-related projects was improving input within XCB (the X-protocol C-language Bindings) by Christoph Reimann. Christoph wanted to add XKB protocol bindings and other utility functions to XCB via the XML protocol description and writing a Python code generator. Unfortunately, this work hasn't made its way into any mainline code-bases for X.Org and the code appears to have not been touched in around three months.
The last XCB mailing list message we found by Reimann was in August when getting ready to test new libxcb and xcb-proto code that seemed to be working at least somewhat for XKB access via XCB. There wasn't much of a discussion that ensued from that announcement and the code hasn't really been touched since then. His Google Summer of Code work can be found in this xcb_proto branch and in this libxcb branch. The last code commits made were from mid-August and we haven't been able to find any activity since that point.
Another one of the 2010 projects for X.Org was creating a Cairo Gallium3D state tracker. This state tracker by Igor Trindade Oliveira would accelerate Cairo operations directly atop the Gallium3D driver architecture rather than needing to use Cairo with a DRM or OpenGL back-end (among others) that in turn would be indirectly communicating with the graphics hardware. Igor wrote a few times on his blog about progress on the Cairo state tracker with the last update being in August. The Cairo state tracker is working atop Gallium3D for some operations and there is Git code available. This code, however, has not been touched since the end of August and there's no sign of it going into the mainline code-base anytime soon.
Lucas Ferreira, another student developer, took a different look at things by trying to use upstream software components to create a fully plug-and-play USB multi-seat solution on the X.Org Server. On his blog are a few posts about creating a setup with Plug-able Dock Stations, GDM, ConsoleKit, and X.Org Server 1.8 using Ubuntu 10.04 LTS. For this, many components from Git need to be pulled manually and the upstream code isn't quite yet ready to make such USB multi-seat solutions an "out of the box" process. The last blog post on the matter was in late July.
One of the other graphics projects this summer was creating a kernel mode-setting driver for the Permedia 3/4 graphics processor and then writing documentation for others to utilize on how to write a KMS-enabled Linux kernel driver. The Permedia GPU came out from 3Dlabs as the first low-cost OpenGL GPU more than a decade ago. The goal wasn't to make the KMS driver itself useful seeing as there aren't many 3Dlabs Permedia GPUs still around and being used, but more importantly to produce some clear and proper documentation for other developers so they can more easily create their own KMS driver for other graphics hardware. The last update we talked about with the KMS/DRM Glit driver was in June where the code was beginning to function but kernel memory management support had to be added. In Matt's personal Git repository is where this KMS driver continues to live and was last worked on in mid-August. Only a handful of commits were made since June when pushing out some initial work on the CRTC support, VGA connector, DAC encoder, and video memory initialization. A very basic TTM memory manager was added along with frame-buffer support to the Glint driver. There, however, appears to be no recent activity on this KMS driver or in producing the KMS driver documentation (we haven't found any yet) nor does the DRM Glint driver appear ready for any upstream integration in the Linux kernel.
Like in past years, the X.Org Foundation should eventually issue a report on whether the Google Summer of Code involvement was once again successful. At future X.Org Developer Summits there will also hopefully be greater involvement by these student developers. As part of my XDS Chicago proposal, I suggested getting the GSoC developers actually involved with XDS. "On a separate but related matter, another suggestion I would like to make – that others have expressed would be a good idea as well – is better inviting active X.Org Google Summer of Code developers to participate in future events. As far as I know, it's currently not part of the standard procedure to pursue these Google Summer of Code developers to attend the X.Org event to talk about their progress or work completed. The X.Org Foundation has expressed there are funds available for sponsoring a greater number of developers to attend these events and inviting these active Google Summer of Code developers to attend could result in a more vibrant selection of talks during such events with the Google Summer of Code projects often focusing upon experimental areas and other topics not generally covered by normal discussions. While these student developers already have a vested interest in successfully completing their work due to the financial incentive from Google, if active Google Summer of Code developers were at these events they may be further motivated to work on their projects and could benefit from the knowledge learned via in-person discussions. It could potentially lead to greater motivation by these student developers to participate further in X.Org upon their formal completion with Google Summer of Code thereby expanding the X.Org development community." Perhaps then we can possibly see more student developers interested in continuing to contribute and finish their work past August.
Update: There's now more information in our forums.
9 Comments
