1 files changed, 107 insertions, 0 deletions
diff --git a/community/gsoc/xorg_ideas.mdwn b/community/gsoc/xorg_ideas.mdwn
new file mode 100644
index 00000000..0899d20c
--- /dev/null
+++ b/community/gsoc/xorg_ideas.mdwn
@@ -0,0 +1,107 @@
+[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+
+[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+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 particualar, 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.
+
+About two 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
+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 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
+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.
+
+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.