From f553db2dd7258d5b1d326b429040495bcc417320 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 13 Mar 2009 05:30:48 +0100 Subject: Renamed xorg-ideas to xorg_ideas --- community/gsoc/xorg-ideas.mdwm | 68 ------------------------------------------ community/gsoc/xorg_ideas.mdwm | 68 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 68 insertions(+), 68 deletions(-) delete mode 100644 community/gsoc/xorg-ideas.mdwm create mode 100644 community/gsoc/xorg_ideas.mdwm diff --git a/community/gsoc/xorg-ideas.mdwm b/community/gsoc/xorg-ideas.mdwm deleted file mode 100644 index 513765cc..00000000 --- a/community/gsoc/xorg-ideas.mdwm +++ /dev/null @@ -1,68 +0,0 @@ -[[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 , or perhaps some -other minor issue with X on the Hurd. diff --git a/community/gsoc/xorg_ideas.mdwm b/community/gsoc/xorg_ideas.mdwm new file mode 100644 index 00000000..513765cc --- /dev/null +++ b/community/gsoc/xorg_ideas.mdwm @@ -0,0 +1,68 @@ +[[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 , or perhaps some +other minor issue with X on the Hurd. -- cgit v1.2.3