From owner-freebsd-hackers Mon Dec 15 11:54:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA04294 for hackers-outgoing; Mon, 15 Dec 1997 11:54:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA04275 for ; Mon, 15 Dec 1997 11:54:24 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA15748; Mon, 15 Dec 1997 11:30:33 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd015743; Mon Dec 15 11:30:28 1997 Message-ID: <349584B3.FF6D5DF@whistle.com> Date: Mon, 15 Dec 1997 11:27:47 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Jonathan Mini CC: hm@kts.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org Subject: Re: 132 Column mode on VGA Consoles References: <19971215011306.46218@micron.mini.net> <19971215052432.11830@micron.mini.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jonathan Mini wrote: > > Hellmuth Michaelis 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 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."