Hi, I am preparing for the console server, and here is sort of a rough outline, call for comments, requests, and opinions, as well as some update on the status.
The console will be built of several parts: * A kernel driver to get the keyboard events from. To reduce kernel code, raw scan code events will be consumed in the ix86 version. Status: GNU Mach can provide them, I have a hack for OSKit-Mach here that needs to be polished and integrated into the source (a cheesy kbd device that sets keyboard in raw mode when being opened). * A way to access the VGA memory and map it into the console server. GNU Mach has it via a special device, OSKit-Mach has it by mapping /dev/mem. I don't remember if it works or if there are bugs, if there are bugs in the mem device in OSKit-Mach I have fixed them locally and can submit a fix (in other words: works for me). * A way to access the bare VGA card's I/O ports. GNU Mach allows it by default :) and my I/O bitmap interface for OSKit-Mach is completed (except that it doesn't behave 100% correct on SMP systems), I have to polish it and submit the code for integration. * A term that can access the console server. This was done recently, and committed. It should work. * A console server. I have a hacked colortext here that should work, but it provides only a minimal console. Because I am going to fix it, I thought I would do it right from the start, and have the following in mind: The console server emits characters in the local encoding, this might be iso8859-1 or something similar common. We are limited to 256 bytes and the lower 128 should be plain 7-bit ASCII, but within that constraints everything is fair game. It receives characters likewise, and although the encoding that is used to emit characters can be different from the encoding that is received, usually this will not be the case. Unicode support is not feasible for us at this stage (for many reasons), but if you were to hack a Hurd system that uses Unicode at the system level, this is the place where you would implement it (and then the rest like term would just need to handle it). The console server will be modular, in particular the architecture specific parts will be isolated from the generic parts. So there will be backends which are responsible to translate keyboard scan codes into characters, for example. I think for now I will limit every console server process to one input device and one output device. Note that you could start several console servers if you have some useful distinct devices to use them for (and drivers for them in the server). The only input driver that will be initially supported is of course the PC keyboard driver, which translates PC keyboard raw scan codes into characters. This will require a configuration file with a translation table. In this configuration file, keys could be also mapped to special functions in the console server (like switching the virtual terminal, or the screen resolution), or to complete strings (like F1 => "ls\n"). The format of the file is not decided yet (GNU/Linux has some format, we might just sneak that, but for special features we will not be compatible, and the files are usually very simple). It will be flexible enough, but specific to the backend driver. The internal interface will just require that the backend driver feeds the input queue with characters in some sort of encoding, and triggers special events when asked to do so by the user. I expect to implement all the common features you would expect (shift, ctrl, left alt, right alt, compose key etc). Here it is possible to either encode directly into the desired system encoding (like iso8859-1), or we could encode into an intermediate encoding (Adobe Standard Encoding, Unicode). The advantage of having an intermediate encoding is that the configuration file becomes independant of the system encoding, which is a good thing. The output half is similar. The only driver initially will be a standard VGA driver (Super VGA might be an option for later). I have found some documentation on VGA cards (FreeVGA Project), and we will do all the VGA card programming in user space. So we just map the VGA card memory and program it's I/O ports. This allows us to implement Text mode switching (more interesting for SuperVGA, I am afraid), Font loading, and other interesting stuff like that. For now, I will settle with font loading, as this is important for i18n. The internal interface will certainly be a bit more complex than just stuffing the characters into the output queue, because if you change the screen mode, the dimensions need to be reported back to the user (SIGWINCH anyone? I think we are missing support for that in the Hurd, and in term in particular). The standard format for fonts will be BDF (Adobe Bitmap Distribution Format, V2.2, 1993), because that is a simple text format (CVS friendly) which is in widespread use (XFree86). Although BDF is often not directly used, but the compiled PCF is used instead, I will stick with BDF for now. PCF and gz support can be added later at any time. If you look for console fonts on other systems (PSF on GNU/Linux, vfont on Solaris(or so?), some .FNT format on BSD), you will be disappointed: They are quite limited to that specific purpose, not well defined and not particularly portable. The BDF font format is independent of the device used (a particular font is bitmapped and thus dependent on the output device, althugh scaling information is included in the font), always includes encoding information (which maps characters to glyphs), is easy to parse, and can be used for other backend drivers as well. For example, if you were to write a framebuffer device, you could use your X fonts on the console (you will be able to use X fonts on the normal VGA text mode console, too, as long as the glyphs fit into 8x14 or so). A BDF font has the additional advantage that it can contain many glyphs (for example a Unicode BDF font can have tens of thousands of glyphs), so you don't need to change the font configuration if you change the character encoding. Which leads me to the next configuration file needed, the mapping of characters (ASCII, iso8859-1 or whatever) to the encoding used in the BDF font (usually Adobe Standard Encoding, about which I have to get more info, but it can be an internal encoding, too). (An implementation detail: If you preload a font to the vga buffer, you can hard code an encoding, so it might be better to leave the decoding to the backend driver, inc ase it can shortcut it). So, a configuration of the console server could look like this: /hurd/console --input pc-kbd:de --output vga --encoding iso8859-1 --font cm (this assumes that the keymap table de maps from scan codes to an internal encoding, that is than decoded to iso8859-1. If you really want to confuse things, we can provide --input-encoding and --output-encoding options). The generic code will deal with virtual terminals, generic screen savers, and similar stuff (like displaying a status bar or a clock). That is the place where you put all the gimmicks. I am not sure how virtual consoles will work. I don't think just creating a new virtual console at every open is a good idea. Instead, we should name them. Maybe the translator should provide a directory, and accessing 1, 2, 3, etc (or even names) accesses the virtual console with that number (created on the fly if necessary). What I am in particular not sure is how we would get a getty on such virtual consoles (surely we would use some /etc/ttys entry, maybe some support needs to be added there). I am open to suggestions. Surely everyone has his or her own ideas how the console should behave and work. For example, I would not clear the scroll back buffer when the virtual console is switched (but have a hot key that empties the buffer, for security reasons). I have some ideas I did not mention here, and I will see how many of these I get done in time. I am sure I will not be able to implement all your ideas, but I would not like to miss a particular good one either. The current status is: * I have written a BDF parser. * I have tried font switching, and verified that it works. As a result, some header files for VGA programming exist now. * The colortext program exists, of course, for a long time now. AFAICR, it has not yet the level of seperation of the backend drivers from the generic parts that I desire. I have a hacked up version that has some scan code mapping already, but it's very ugly. What needs to be done: * Submitting the pending patches for OSKit. * BDF->VGA font converter. * A proper keyboard driver (not the hacked up one that does only know the left shift key as a modifier :) with keymap support. * A nice console font! I will write a psf2bdf converter, so we can sneak the GNU/Linux fonts, but we should have a nice BDF font with many glyps as well. I am considering ec fonts (european variant of computer modern by Knappen) and mftobdf. But I will have to check if metafont produces usable results at such low resultions. (I know that it produces some results, I have used a 4x5 font on a line printer once, it was surprisingly readable, but I would not use it daily :) * Putting it all together. * Virtual consoles. * All the gimmicks and extras (many of them). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
