public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andi Kleen <ak@suse.de>, Jeff Garzik <jeff@garzik.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: arch/i386/boot rewrite, and all the hard-coded video cards
Date: Wed, 02 May 2007 00:59:29 +0200	[thread overview]
Message-ID: <4637C651.9080102@gmail.com> (raw)
In-Reply-To: <alpine.LFD.0.98.0705011433050.3808@woody.linux-foundation.org>

On 05/01/2007 11:41 PM, Linus Torvalds wrote:

> The standard extended modes are actually really useful, if for a very 
> simply reason: they give you bigger more lines on screen when a bug 
> happens.
> 
> So I _still_ occasionally use "vga=extended" just for that reason. The  
> default 80x25 thing scrolls most oops away.

Not the right time, but I've wanted to ask for ages... why can't we keep 
hardware scrolling through the VGA text buffer on a OOPS available from 
Shift-PageUp/Down? With hardware scrolling it's really minimal code IIRC.

>> I'd consider keeping anything but VESA 1.2 (which that ET4000 and most all
>> other Super VGA cards of the era also do!) nonsensical and as far as I'm
>> concerned this includes all the VGA modes with the strange number of lines; a
>> 43/60-line VGA screen is too horrible to look at anyway...
> 
> 80x50 is useful for the above reason. Yeah, it's ugly, but it's useful for 
> the "It's too much work to try to do anything but just take a digital 
> photo of the screen". And that 50-line mode will actually be 43 in EGA 
> mode, I think.
> 
> The 132x50 mode is probably a bit prettier, and is fairly common too, and 
> useful for the same reason.
> 
> And once you support those, you might as well support all the VESA text 
> modes.

Yes, keeping VESA is sensible if you keep anything but note that many of the 
extended text modes video.S can set are not VESA modes but modes available 
on any standard VGA through tweaking VGA registers. The standard VGA text 
modes are:

Mode 0/1:	40x25 (monochrome/colour)
Mode 2/3:	80x25 (monochrome/colour)
Mode 7:		80x25 (monochrome, MDA/Hercules)

VESA 1.2 adds text modes:

Mode 0x108:	80x60
Mode 0x109:	132x25
Mode 0x10a:	132x43
Mode 0x10b:	132x50
Mode 0x10c:	132x60

That 80x43 mode is one of the "specially tweaked VGA modes" (by using a 8x8 
character cell instead of the normal 8x14 on the 640x350 screen; it turns 
into 80x50 on 640x400).

Well, yes, for symetry with the 132x VESA fonts I guess that 80x43/50 may be 
kept; they're sort of "standard" in the sense that they've been widely used 
  and VESA probably only didn't include them since that was the case already 
anyway. And you can set them through standard BIOS calls to replace the font.

But note there are also tweaked "80x28", "80x30", "80x34", and "80x60" modes 
there that I feel do not serve any purpose whatsoever and do make for rather 
involved code that I expect HPA wouldn't so much mind killing. Having:

1) the standard CGA/MDA/HGA/EGA/VGA modes on an adapter that can do them
2) 80x43/80x50 on the EGA/VGA
3) the VESA 1.2 alphanumeric modes if we have VESA.

should really be enough I feel (and 2 only since it's simple and well-known)

> And yes, I'm literally talking about the *text* modes. Not all of us want 
> to have fbcon built in - I prefer my text-mode lean and mean and fast as 
> hell, and if I want a frame buffer, I'll take X11, thank you very much.

I agree and don't use fbcon myself. This is (slowly, very slowly) becoming a 
bit of an obsolete standpoint even on a PC though; doing away with VGA may 
not be all that bad on new machines. And with the absolutely horrible 
interpolation TFTS do on anything but their native resolutions, looking at a 
640x350/400 screen is sometimes almost too painful even for short purposes 
when you have one of those.

Rene.


  parent reply	other threads:[~2007-05-01 23:02 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-01  1:33 arch/i386/boot rewrite, and all the hard-coded video cards H. Peter Anvin
2007-05-01  1:40 ` Jeff Garzik
2007-05-01  1:42   ` H. Peter Anvin
2007-05-02  7:46     ` Martin Mares
2007-05-02  9:22       ` Andi Kleen
2007-05-02 20:49         ` H. Peter Anvin
2007-05-03  2:15         ` H. Peter Anvin
2007-05-02 19:05       ` Lennart Sorensen
2007-05-01  1:51 ` Dave Jones
2007-05-01  2:17   ` H. Peter Anvin
2007-05-01  2:34     ` Eric W. Biederman
2007-05-01  3:46       ` Andi Kleen
2007-05-01  2:54         ` H. Peter Anvin
2007-05-01  4:29           ` Andi Kleen
2007-05-01  3:38             ` H. Peter Anvin
2007-05-01  3:06         ` Eric W. Biederman
2007-05-01  3:21           ` H. Peter Anvin
2007-05-01  3:41             ` Eric W. Biederman
2007-05-01  3:44               ` H. Peter Anvin
2007-05-01  2:43 ` Linus Torvalds
2007-05-01  2:59   ` Dave Jones
2007-05-01 20:32   ` Rene Herman
2007-05-01 21:01     ` Rene Herman
2007-05-01 21:41     ` Linus Torvalds
2007-05-01 21:52       ` H. Peter Anvin
2007-06-14  4:51         ` Oleg Verych
2007-06-14  5:11           ` H. Peter Anvin
2007-06-14  7:18             ` Oleg Verych
2007-05-01 22:59       ` Rene Herman [this message]
2007-05-01 23:18       ` Antonino A. Daplas
2007-05-02 18:22       ` Jan Engelhardt
2007-05-02 20:59         ` H. Peter Anvin
2007-05-02 21:07           ` Rene Herman
2007-05-02 21:15             ` H. Peter Anvin
2007-05-02 21:20               ` Rene Herman
2007-05-02 21:25                 ` H. Peter Anvin
2007-05-02 21:39                   ` Rene Herman
2007-05-02 22:11                     ` H. Peter Anvin
2007-05-02 22:49                       ` Rene Herman
2007-05-02 22:59                         ` H. Peter Anvin
2007-05-02 23:18                           ` Rene Herman
2007-05-03  2:09                             ` H. Peter Anvin
2007-05-01  3:56 ` WANG Cong
  -- strict thread matches above, loose matches on Subject: below --
2007-05-01 22:41 Vlad
2007-05-01 23:22 ` Rene Herman
2007-05-02  1:10   ` Vlad
2007-05-02 18:25 ` Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4637C651.9080102@gmail.com \
    --to=rene.herman@gmail.com \
    --cc=ak@suse.de \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jeff@garzik.org \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox