Update for 2010

Drop libpciaccess task; and a few minor tweaks.

1 files changed, 4 insertions, 44 deletions

diff --git a/community/gsoc/xorg_ideas.mdwn b/community/gsoc/xorg_ideas.mdwn
index 406d370d..26177345 100644
--- a/community/gsoc/xorg_ideas.mdwn
+++ b/community/gsoc/xorg_ideas.mdwn
@@ -8,51 +8,11 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled
 [[GNU Free Documentation License|/fdl]]."]]"""]]
 
-## libpciaccess Support for GNU Hurd
-
-xserver 1.5 introduces libpciaccess as a new method for handling PCI devices.
-The purpose was to get rid of the messy old PCI code in the server, instead
-using a new implementation that is encapsulated in a library, and uses external
-PCI access interfaces provided by the operating systems.
-
-As libpciaccess is written from scratch, support for various operating systems
-needs to be reimplemented individually, writing specific backends for each.
-This task is about creating such a backend for GNU Hurd.
-
-Writing a "proper" native backend for the Hurd is rather involved, as there is
-no kernel PCI interface so far -- it has to be created first. It would also
-have the disadvantage of being somewhat tied to the specific driver framework:
-The present framework is pretty dated (using some ancient Linux drivers with a
-layer of glue code); and when this is replaced, the PCI interface will have to
-be updated as well.
-
-Alternatively, a libpciaccess backend simply doing old-style register poking
-from user space could be implemented. (Either from scratch, or by reusing some
-existing PCI code from the old server or some BSD kernel.) That approach is not
-as elegant; it would be somewhat fragile and limited, like the old PCI code in
-the server. On the other hand, it is much simpler to implement; and it would
-also benefit other non-mainstream platforms that can't afford
-creating/maintaining a native backend.
-
-The goal of this project is getting a recent xorg server, using libpciaccess,
-to run on the Hurd.
-
-This task probably doesn't require any previous X programming knowledge, though
-a bit of experience with PCI programming will probably help. Some Hurd-specific
-knowledge will have to be obtained while working on it -- especially if
-implementing a proper kernel PCI interface. The task is pretty involved in the
-latter case, but shouldn't be too hard if taking the user space register poking
-approach.
-
-Exercise: Implement a stub backend for libpciaccess, which doesn't really do
-anything useful, but compiles fine on the Hurd.
-
-
 ## 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 Xorg run as well (see also
-the libpciaccess task), the support is quite rudimentary: in particular, there
+are updates now and then to make newer versions of Xorg 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
@@ -74,7 +34,7 @@ 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.
 
-About two years ago, the developers came to the conclusion that a more robust
+A few years ago, 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
@@ -90,7 +50,7 @@ microkernel idea -- we want to run the drivers as priviledged 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 or
+can be done by taking one of the existing DRM modesetting drivers (Intel, Nouveau (Nvidia), or
 Radeon), 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.