Date: Mon, 15 Dec 1997 11:27:47 -0800 From: Julian Elischer <julian@whistle.com> To: Jonathan Mini <j_mini@efn.org> Cc: hm@kts.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org Subject: Re: 132 Column mode on VGA Consoles Message-ID: <349584B3.FF6D5DF@whistle.com> References: <19971215011306.46218@micron.mini.net> <m0xhZVd-00024IC@bert.kts.org> <19971215052432.11830@micron.mini.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Mini wrote: > > 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. > I still have the design and discussion archives from back then do you want them? We actually ended up with a design, but no implementation. > 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?349584B3.FF6D5DF>