Date: Sat, 15 Feb 1997 21:37:25 -0700 From: Jeremy Chatfield <jdc@xinside.com> To: hm@kts.org Cc: FreeBSD-hackers@freebsd.org, FreeBSD-current@freebsd.org Subject: Re: pcvt/132 columns Message-ID: <33068F05.708D5F1B@xinside.com> References: <m0vvfSQ-00001yC@ernie.kts.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hellmuth Michaelis wrote: > ... It would be nice if the Xserver > would contain a hook to let programs like this run automatically. > > hellmuth > -- > hellmuth michaelis hm@kts.org hamburg, europe I missed the beginning of this, so apologies if my assumption is incorrect. I am assuming that you are probably complaining about a situation in which X Servers do not return to the text mode you selected, after setting up VT's with a nonstandard (not 80x25) text mode resolution. Bear with me, while I describe some background, and then make a proposal that should make FreeBSD a nicer VT environment than any of the others ;-) We (Xi Graphics) have run into this request on several OS's, so we've looked at it several times. The following suggestion is, however, completely my own idea. Thomas Roell appears to hate it (mostly, I think, because it would mean more OS-specific work for him!) Graphics boards have a BIOS, with a bunch of common functions. One of those functions permits switching text resolutions. The switch is made by directly programming graphics chip and DAC, with no knowledge of the changes to anything external to the BIOS. Switching to a nonstandard resolution *might* (it depends on lots of factors) require programming a write-only register. Depending upon the values of certain registers, a switch to any specific resolution may not be safe, if one of these write-only registers has had certain values stuffed into it. There's always a way to switch back to 'standard' 80x25 mode, though. That's always a safe transition. It is often possible to select many modes using a common clock, which is something that we take advantage of, on Linux. A 'safe' switch, is one in which the graphics board won't lock up the system tight. It is possible to make a system stop dead, totally locked up, buffers unflushed, with an unsafe switch. We think that this is unacceptable. Very few modern graphics boards exhibit the problem. It was much more common on boards that were popular about five years ago. However, graphics boards have a long life, especially on server systems. We think it is prudent to design for worst case, rather than best case. If the BIOS is used to switch to non-standard resolution, then another program should really use the BIOS to switch resolutions to something safe; then the BIOS can set up the registers as it wants and safely switch around. IMO it would be better to have never used the BIOS for a mode switch at all... There are many ways to program a graphics board to give a particular text resolution. It should be possible to write conflicting programs that will interfere when they alternately set up a text mode or a graphics mode switch. With the older boards, it is therefore possible to set up scenarios where those boards will lock up the system, persistently. On UNIX System V Release 4 derivatives, it is possible to start a Virtual Terminal Layer Manager. This can be configured to run a shell script the first time that a VT is switched to. I used to use that to select screen colours. SVR4 also has an ioctl() to control screen text resolution. This ioctl is quite limited, as implemented, but does allow selecting between 80x25, 40x25, 80x43 and perhaps 132x25, if I remember correctly. There was no way to use the BIOS in SVR4 boot or operation, so the ioctl, if conservative, was quite safe. Linux, during bootstrap, before the Linux kernel is running, can have the bootstrap loader set a non-standard resolution. This uses BIOS calls, which are not really accessible once Linux is running. An alternative method is to use a "setvgamode" program. Since this has local knowledge about how it programmed registers, it potentially (if correctly programmed to do so, etc) can be safely used to select and reselect different text modes. However, there is also local knowledge in the X Server about graphics and text switches. There is no guarantee that the knowledge is synchronised, so with certain graphics chips and boards, it may be possible to risk a state in which the machine is locked up. The effect may not be common, but it is possible. This is because the setvideomode program could assume one set of knowledge about how to switch to a certain state, and the X Server can assume a different set of knowledge. Each program running alone would be safe, but the two together are a hazard. We've ended up with our Linux Server deciding what modes are safe, and if it *can* preserve text modes, it will do so, but if it decides that the mode switch involves a possibly dangerous operation, it forces a return to 80x25, which can result in an unpleasant mess on screen, but at least leaves the system consistently running, rather than risking an abrupt halt. What I'd like to see in FreeBSD, are a more complete set of things for handling VT's. Fortunately, I think that the functions can be split to make it manageable, though I'll admit I've no intention of doing any of this work ;-) There are many ways to create a more flexible, more fully featured and safer VT switching mechanism than those in SVR4 and Linux. Here are some desirable characteristics: 1/ doesn't permit VGA BIOS control over switching, at all. 2/ uses a consistent body of knowledge for switching to a mode. 3/ assumes that all switches that it does not make, will be returned to a safe mode. 4/ is triggered whenever switching to a specific VT. 5/ has VT specific configuration modes. 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. 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. Features that I'd expect in the VT manager, include: 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). b) a program that is run each time the screen is switched to; this could be used for setting odd modes. 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. 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. e) screen driven configuration program, feeding a plain text file to allow easy per-system and per-user configurations of modes and programs. 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. Cheers, JeremyC. -- Jeremy Chatfield, Phone: +1 303/298-7478 FAX:+1 303/298-1406 Commercial X Products - for sales/support/information please try: http://www.xinside.com/ mailto:info@xinside.com ftp://ftp.xinside.com Xi Graphics, 1801 Broadway, 17th Floor, Denver, CO 80202
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33068F05.708D5F1B>