From owner-freebsd-arch Fri Jan 24 14:35:54 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E55B337B401 for ; Fri, 24 Jan 2003 14:35:51 -0800 (PST) Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD0C143F13 for ; Fri, 24 Jan 2003 14:35:50 -0800 (PST) (envelope-from ortalo@laas.fr) Received: by laas.laas.fr (8.12.7/8.12.7) with ESMTP id h0OMZh0j021762; Fri, 24 Jan 2003 23:35:44 +0100 (CET) Date: Fri, 24 Jan 2003 22:58:12 +0100 (CET) From: Rodolphe Ortalo To: Marcel Moolenaar Cc: Nicolas Souchu , arch@freebsd.org Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) In-Reply-To: <20030123234431.GB555@athlon.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 23 Jan 2003, Marcel Moolenaar wrote: > Not all low-level consoles are (graphical) display adapters. If > the low-level console is a serial interface, you need to preserve > the communication settings. In general though I like to take the > approach that the low-level console has done some work, possibly > non-trivial, to get the state/information it currently has and it > seems wasteful to destroy that state simply because we run into > that device during bus enumeration and we then have the resources > available to use the device to its fullest potential, but end up > not doing that. So, unless there's a good reason not to, preserving > state can only proof beneficial. > > I realize it's mostly subjective. I think you should have the > mechanism to allow preserving state, so that you have the freedom > to make use of it or not... I understand clearly why doing so may be important for serial consoles (or possibly other non-display adapters), but wrt most (modern) VGA adapters, I have the feeling that discarding the state and switching to some advanced mode should be done as soon as possible! :-) Note that this does not necessarily mean discarding VGA-style display mode; but for example if the board allows to access all needed VGA registers via a MMIO area (instead of the usual fixed adresses regs around 0x3C0) and its framebuffer (including the VGA part) via another area, it is urgent to take advantage of it: even if the console layer simply re-sets an VGA mode identical to the one set by the boot driver; then, all potential conflicts due to the fixed (and non-shareable, or at least very difficult to share) VGA adresses in a multiple-boards configuration are cleared, and further initialisations of remaining boards can proceed more cleanly. This is still an experimental subject for me with KGI/Linux, but I'd really like to try this one of these days. (I have a computer with, say a G200 AGP board and a Matrox Mystique) Currently, I use one of the board as the boot board (primary in my own terminology) and starts a driver on the other one, then raise my initlevel to active some virtual consoles on this secondary head. (At boot, these consoles are directed on a "display-null" which is basically a /dev/null. My driver instance replaces one of these "display-null". [1]) What I have to experiment yet is to replace the primary head VGA-only boot driver with another instance of the Matrox driver (and get rid entirely of the boot drivers), and do this first in the rc scripts. (Of course, I wanted to have more confidence in the drivers themselves before doing this in such a permanent and possibly dangerous way.) In this case, it would be possible to add another PCI board (like my old S3 Trio) and use a simple (but generic) VGA driver to use it in text mode only (S3 does not have a driver in KGI currently, and probably won't until some more time). If I do not have the ability to replace the initial boot VGA driver (targetted at one of the Matrox boards) with a more complete driver (using MMIO accesses), to do that, I would be obliged to set the S3 board as the primary (BIOS initialized) board. Something most users will probably not want to do (even though it is not absurd at all): use the oldest graphic board in the computer as the primary boot display. (Plus the fact that it may compromise some nice boot logo. :-) Well, sorry for going into such futile remarks in the end... :-) Rodolphe [1] The total number of available displays is a compiled-in default (4). Nicholas, please correct me if I'm wrong. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message