: 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.
: CONCLUSION:
: -----------
: 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.
Andries