Date: Sun, 16 Feb 1997 11:07:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jdc@xinside.com (Jeremy Chatfield) Cc: hm@kts.org, FreeBSD-hackers@freebsd.org, FreeBSD-current@freebsd.org Subject: Re: pcvt/132 columns Message-ID: <199702161807.LAA07573@phaeton.artisoft.com> In-Reply-To: <33068F05.708D5F1B@xinside.com> from "Jeremy Chatfield" at Feb 15, 97 09:37:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... long discussion on console modes ... ] > 1/ doesn't permit VGA BIOS control over switching, at all. Agree. > 2/ uses a consistent body of knowledge for switching to a mode. Agree. > 3/ assumes that all switches that it does not make, will be returned to > a safe mode. Disagree (see below). > 4/ is triggered whenever switching to a specific VT. Disagree (see below). > 5/ has VT specific configuration modes. Agree. > 6/ may use a VGA library, if one is present, so that games and other > non-X graphics, can use a common knowledge base for safer switching. Agree. > I think that this means either an ioctl(), perhaps with a user level > daemon that does the work, or possibly, using the X approach, an > entirely user level process, perhaps connected to a virtual terminal > manager. Here's the problem. If you invoke a user level process to do this, then it is useless for providing a virtual console for a kernel debugger, and it's useless for graceful panic handling. The *only* way to do this safely is to give the kernel driver specific knowledge of all allowable video modes so that it doesn't have to rely on a user space process to do its job. This means X gets its nose *out* of the mode settings and card I/O address range, etc.. The driver, by default, would be VGA-aware, and you would have to load a better (card specific) driver to provide more (card specific) modes. Write-only registers would have to be shadowed in software so that the state was recoverable (for instance, during a resume following a suspend, in which the video hardware was APM powered-down, or "recovery" of system state after a weekend of being shut of using a "save-state/restore-state" shutdown. The driver would also have to be able to report, to user space programs, the available modes supported by the currently loaded driver... a parametric "INT 10 mode select" for protected mode OS's, in effect (the real mode "INT 10 mode select" should be redesigned to be parametric as well, but that's neither here nor there...). This was first discussed in the fall of 1993, and the LKM system was implemented in early 1994 for the purpose of providing a facility for loading card-specific console drivers. > a) initialisation program on first switching to a VT. This could be > used to start a system monitor whenever there's no process on a > prticular VT, or to start a login program only when switching to that VT > for the first time (or when there's no controlling program for that VT). This can be handled using pseudo-DCD signalling. DCD is low until the first time you switch to a VT. > b) a program that is run each time the screen is switched to; this could > be used for setting odd modes. NO. This violates the abstraction. > c) optional mode setting on each VT switch. For example, this would > permit a switch from the X Server to go to 80x25 on VT1, and then the VT > manager would catch the switch and reselect 132x25 with a blue > background and yellow text with Cyrillic font. Yes. This would be automatic, in any case, with the original 1993 design. > d) experiment mode, in which various modes could be tried and safe ones > marked for use in a per system restrictions file, for use by the > configuration program. This should be run by the System Admin, so that > users can only select between modes that do not upset the screen or > graphics board and risk system integrity. Bad, bad, bad. This implies the card-specific drivers are "scripted" in the generic driver, instead of replacing the generic driver. This is bad because it implies state information that did not result from a standard probe sequence. Clearly, there needs to be some way to "fine-tune" settings for the card-specific drivers, but just as clearly, these vagries are limited to replacing a "monitor database"... and a "monitor database" is a preferrable, if more difficult to implement, soloution. > e) screen driven configuration program, feeding a plain text file to > allow easy per-system and per-user configurations of modes and programs. Have you seen the Win95 display configuration? > The key points that I'm trying to make, are that it should not be the > responsibility of the X Server to guess what knowledge base was used to > set up a text mode, and that this is reasonably a function of an > Operating System (providing controlled access to a shared resource). > Once you start to think like that, wider solutions with more features > are possible. And it should not be the responsibility of the X server (or any other user space code) to restore card settings. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702161807.LAA07573>