Added DRM porting to Xorg GSoC ideas list

This is not really a good project description, as it's not very specific
about what work is actually required (I lack the knowledge for that) --
but I gues it doesn't hurt to offer it nevertheless...

1 files changed, 39 insertions, 0 deletions

diff --git a/community/gsoc/xorg_ideas.mdwm b/community/gsoc/xorg_ideas.mdwm
index 513765cc..0899d20c 100644
--- a/community/gsoc/xorg_ideas.mdwm
+++ b/community/gsoc/xorg_ideas.mdwm
@@ -66,3 +66,42 @@ 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.