From 362b2a12a5a5d664988ffb51f66c6e1b83f84764 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 13 Mar 2009 12:57:11 +0100 Subject: 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... --- community/gsoc/xorg_ideas.mdwm | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) (limited to 'community') 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 , 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 .) 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. -- cgit v1.2.3