Re: Console resizing in Linux kernel
Thu, 5 Oct 1995 11:04:08 +0100

: Subject: Console resizing in Linux kernel
: Date: Thu, 05 Oct 95 08:29:40
: From: (Koen Gadeyne)

: I don't know who is really responsible for the latest changes
: in the Linux kernel (with "latest" I mean from 1.3.0 and up)
: pertaining to console resizing.

: I'm a bit worried by an increasing amount of (yet) unexplained
: problem reports and flames from users of a program I wrote which
: does just that console resizing.

: The program I am talking about is called "SVGATextMode", and started to
: appear on the net in January 1995. It basically uses SVGA cards to their
: fullest possible capabilities in the text mode consoles. It's configured
: with an XFree86-like configuration file, and allows ANY possible console
: size you can possibly think of.

: It also uses the extra high clock available on all VGA cards. At this
: moment, I am typing this message on a screen with a 116x48 text mode
: console, at 56kHZ/70Hz refresh. This uses a 75 MHz pixel clock.
: This example should make my point clear enough.

: From kernel 1.3 and up, many new features have been added to make
: using the console easier for some applications. Or not?

: I have seen the introduction of the VT_RESIZEX ioctl, which I think
: is meant to replace the VT_RESIZE I was using in SVGATextMode for
: pre-1.3 kernels.

: I never quite grasped why the kernel needs to know how many video lines a
: text mode has, and what the font size is. Could you explain the reason for
: this? I have searched the kernel sources for an explanation, but with no
: success.

: In addition to that, I noticed the addition of some internal resizing code
: (con_adjust_height()) which reprograms the entire VGA register set when a
: user loads a font with a different font height than what is currently in
: use. Just a random comment: if you REALLY want to do that reliably, you need
: a LOT more code. I've learned the hard way during the last year, and it
: still isn't fully reliable.

: If I interpreted the code correctly, then loading a font of 8 pixels high
: when you are currently working in a 16-pixel high font resizes the screen so
: you actually use an 8-pixel high font cell. THIS ALSO RESIZES THE SCREEN
: GEOMETRY. In the case of my previous example, you get twice as many lines on
: screen as before.

: I would STRONGLY suggest against that!

: Take the case of the typical application which uses the kernel font resizing
: code (maybe you didn't know that there WAS a program that used these
: features already?): SVGATextMode.

: SVGATextMode allows you to use ANY font size the VGA can handle: 1 to 32
: lines. Many people have mentionned the fact that they set SVGATextMode to
: use a 17 or even 18-high font cell, but they download a 16-pixel high font
: in the VGA. Their goal: getting more line spacing. Others do just the
: opposite: they want to cram their lines a little more by using a 16-high
: font in a 15-high charcell.

: Others want to use a certain amount of text lines on a screen, but have to
: revert to an odd number of lines-per-character to get that (e.g. 15 instead
: of 16). Since there are no fonts for such charatcter heights, they use
: either a 14-high, or a 16-high font size.

: If you try any of these tricks on one of the newer kernels, the kernel would
: see you download a 16-high font, and RESIZE THE SCREEN TO USE A 16-HIGH FONT
: CELL. Giving you a DIFFERENT number of lines than you want.

: I was never very enthousiastic about "intelligent" software that ASSUMES all
: sorts of things that are NOT always true, and thus restricts its users to
: unnecessary limitations, which are useless to begin with.

: I think it is the responsability of the user, or, worst case, the
: application programmer to choose such things. Putting it in the kernel is a
: dangerous move, because it sabotages the features a user-level program
: offers, and the possibilities the user has (or had...)

: I am getting TONS of complaints that the new kernels cause a problem with
: SVGATextMode which I will try to describe:

: When they run SVGATextMode, the screen resizes to the desired refresh
: frequencies, etc, but it seems like the kernel thinks there are much more
: text lines than there are on screen. Resizing from e.g. an 132x43 standard
: text mode screen to, say 100x37, makes the screen look as if it is
: extended BELOW the bottom: lines scroll off downwards, and the cursor
: goes along with them. Only after scrolling many more lines, the "old"
: output appears at the bottom of the screen. It seems like their 100x37
: screen (which HAS 37 text lines ON SCREEN) actually has, say, 50 lines
: more BELOW the screen. Useless to say that they are not very pleased...

: It must be said that many people try SVGATextMode at first without the
: automatic font loading feature enabled, leaving the font untouched. This is
: the best way to try a new program: go step by step. With this new "feature"
: in the kernel, they're fried. And then they complain that SVGATextMode does
: not work...

: I am unaware if this problem is caused by the "intelligent" screen resizing
: I just described, or some other feature I didn't notice, but I don't think
: this kind of stuff belong in the kernel.

: -----------

: I am of course being a bit prejudiced on this topic: I would like to keep
: these kinds of features OUTSIDE the kernel, and IN a user-level program.

: But MANY people will (and do) agree with me that if you call the kernel to
: load a new font, it should ONLY load a new font, and not resize the screen
: without asking. If you want that in the kernel, use a DIFFERENT call for
: that, or, better even, let a user program do it.

: I think that as a general system-call policy, a system call should ONLY do
: what it's ASKED to do. This will make it MUCH more flexible, and also much
: less obscure. I'm sure you agree with that. It's plain common sense.

Since 1.3.0 I have not been involved in changes related to
the console driver. Most (all?) was done by H. Peter Anvin
so I forward your letter to him and to the kernel list.