summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorantrik <antrik@users.sf.net>2010-02-26 05:54:00 +0100
committerantrik <antrik@users.sf.net>2010-02-26 05:54:05 +0100
commit4d9dcd394e72cee2c15559dc1b3d09eeabcf59c0 (patch)
tree2a6970a5d211c89722313693c69c0fd20914afbb
parent1c62d918c8bd50e3c05b29a7e5e1d82dc65932bf (diff)
Update for 2010
Drop libpciaccess task; and a few minor tweaks.
-rw-r--r--community/gsoc/xorg_ideas.mdwn48
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.