Date: Mon, 15 Dec 1997 05:24:32 -0800 From: Jonathan Mini <j_mini@efn.org> To: hm@kts.org Cc: j_mini@efn.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: 132 Column mode on VGA Consoles Message-ID: <19971215052432.11830@micron.mini.net> In-Reply-To: <m0xhZVd-00024IC@bert.kts.org>; from Hellmuth Michaelis on Mon, Dec 15, 1997 at 01:20:29PM %2B0100 References: <19971215011306.46218@micron.mini.net> <m0xhZVd-00024IC@bert.kts.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hellmuth Michaelis <hm@kts.org> stands accused of saying: > Jonathan Mini wrote: > > > > As soon as the vesa code goes in, there will be _three_ possible sources of > > contention over the system console's device(s), the Xfree86 system, the VESA > > library, and syscons itself. > > Hopefully this implementation will allow other "drivers" than syscons. If it > would, it would we one step towards the unified console driver we are talking > about since 386bsd 0.1. Of course. Why else would I want to layer the code? Personally, I am annoyed with syscons as it is now, and would (at least) like to see two other 'drivers' : one that is _much_ smaller (a TTY-only implementation, for example) and one that is vt100 instead of SCO compatable. I'm sure there are other things that people will want to see. But, for now, I just want to get rid of the contention over the display hardware, and since my only option to fix that is to layer the console code, I might as well Get It Right. The layering is simple : 1) The lowest layer is, of course, the devices. VESA VBE, the BIOS int 10 services, and a hardware-specific driver are three that come to mind. Also, input devices such as the keyboard and mouse. 2) A layer which implements the user-interface which binds the other two layers together. This layer could be anything from a NOOP to a virtual terminal system like syscons is now, to a full-flegded windowing system. I don't care. :) 3) A layer which uses a tty to interface with the rest of the world. this layer implements junk like VT100 support, SCO or whatever. Two things should be noted : 1) The kernel's private interface to the console needs to be changed, as well as /dev/cons's mutilation of the tty methidology. The kernel console code also needs to be moved out of the i386 tree. This is no hardware dependant, layer 1 of the console system is. (The console code as it is now isn't really hardware dependant either) 2) I will personally write the code to provide ALL of the functionality of syscons, so don't even go down the road of "but you need to provide blah blah blah blah blah." I could go into long discussions about how wonderful this would be in the future, but I'm sure you've all already heard the advantages of a layered console. For now, it will just remove the device contention of the the current console system via the second layer. (It will have support for handling multiple consumers, and switching between them) In the very short term, little will be gained from this, except that the code will probably get slightly larger, but then again perhaps not. A few minor features will be gained, such as being able to use VESA video modes. However, in the long run, the code could feasably be MUCH smaller (a BIOS int 10 layer with a NOOP layer with a TTY emulation layer would be MUCH smaller) and feasably be able to do more <insert wonders of a unified/layered console system here>. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971215052432.11830>