On 05/01/2007 04:43 AM, Linus Torvalds wrote:
> Doubtful. The Tseng ET4000 cards may have been the gold standard in 1991,
> but I don't think most people even _remember_ them. And if they have them
> in their machines, they probably tend to run a Linux-1.2 kernel, or at
> least not care a lot about graphics (ie they may have an old card in the
> machine just because they need VGA to boot, rather than because they care
> about Tseng).
My 386 has an ET4000. An ET4000AX/W32 even. And you bet it's because it's
nifty! Okay, I'll admit the thing doesn't currently run a 2.6 kernel...
The answer will probably be "no", but would this be a good point to ask if
this would be a good time to not bother with the mode switching code at all
anymore? I'm generally rather appreciative of old gunk but I haven't cared
for that specific feature for ages now. I personally don't use framebuffer,
but I would if I wanted more than the plain VGA my BIOS sets up.
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...
Rene.
On 05/01/2007 10:32 PM, Rene Herman wrote:
> On 05/01/2007 04:43 AM, Linus Torvalds wrote:
>
>> Doubtful. The Tseng ET4000 cards may have been the gold standard in
>> 1991, but I don't think most people even _remember_ them. And if they
>> have them in their machines, they probably tend to run a Linux-1.2
>> kernel, or at least not care a lot about graphics (ie they may have an
>> old card in the machine just because they need VGA to boot, rather
>> than because they care about Tseng).
>
> My 386 has an ET4000. An ET4000AX/W32 even. And you bet it's because
> it's nifty! Okay, I'll admit the thing doesn't currently run a 2.6
> kernel...
>
> The answer will probably be "no", but would this be a good point to ask
> if this would be a good time to not bother with the mode switching code
> at all anymore? I'm generally rather appreciative of old gunk but I
> haven't cared for that specific feature for ages now. I personally don't
> use framebuffer, but I would if I wanted more than the plain VGA my BIOS
> sets up.
Confusingly put; please consider a "If the switching code in itself is still
considered relevant, " to be present here. But rip it all out, I'd say...
> 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...
Rene.
On Tue, 1 May 2007, Rene Herman wrote:
>
> The answer will probably be "no", but would this be a good point to ask if
> this would be a good time to not bother with the mode switching code at all
> anymore?
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.
> 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.
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.
Linus
Linus Torvalds wrote:
>
> 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 use framebuffer console pretty much for one purpose -- it sucks less
memory bandwidth when you're stuck with a UMA configuration. Text modes
require random access to the font buffer, which means it hogs the DRAM
pretty badly, unless the chipset designer decided to burn an 8K SRAM,
which is still a pretty pricey hunk of chip real estate.
-hpa
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.
On Tue, 2007-05-01 at 14:41 -0700, Linus Torvalds wrote:
>
> On Tue, 1 May 2007, Rene Herman wrote:
> >
> 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 would agree with the lean and mean, but faster, that's another
question. Even vesafb at 640x480-8 with ypan and mtrr is 30% faster
than vgacon (And for those of you with vesafb that cannot ypan, try
vgacon with the 'no-scroll' option for a more apple-to-apple
comparison). And with chipset-specific drivers, it can be as much as 3x
faster than vgacon.
Anyway, my default console is still text mode, even though I'm the
framebuffer maintainer :-)
Tony
On May 1 2007 14:41, Linus Torvalds wrote:
>On Tue, 1 May 2007, Rene Herman wrote:
>>
>> The answer will probably be "no", but would this be a good point to ask if
>> this would be a good time to not bother with the mode switching code at all
>> anymore?
>
>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.
>[...]
>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.
Seconded. 80x50, and where platforms support it, *80x60 and 132x60*,
is kinda handy (despite the font getting smaller and smaller, heh),
esp. when you don't run it in VMware and not have some capturing
device (serial con/netconsole.. takes time to set up)
>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.
You speak for me :)
Jan
--
Jan Engelhardt wrote:
>> [...]
>> 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.
>
> Seconded. 80x50, and where platforms support it, *80x60 and 132x60*,
> is kinda handy (despite the font getting smaller and smaller, heh),
> esp. when you don't run it in VMware and not have some capturing
> device (serial con/netconsole.. takes time to set up)
>
This is what I've decided on doing:
I'm having a framework for multiple drivers (probe and set methods,
basically); the stock distro will have VGA and VESA drivers only.
Dropping new drivers in is trivial if someone wants to. I was going to
leave in the CL54xx and ATI drivers since I actually have specimens of
those, except it appears that on current specimens of those cards, the
probe succeeds but the mode-setting fails, so I dropped those as well.
If someone happens to have algorithms for setting 132-character mode on
especially the CL54xx series with raw register writes I'd actually be
interested, since that's what Bochs and Qemu emulate, and on those it
would be really nice to have a larger text mode.
-hpa
On 05/02/2007 10:59 PM, H. Peter Anvin wrote:
> I'm having a framework for multiple drivers (probe and set methods,
> basically); the stock distro will have VGA and VESA drivers only.
> Dropping new drivers in is trivial if someone wants to.
It sounds like going overboard a bit; 80x25 standard VGA, 80x43/50 line VGA
(settable through simple BIOS calls) and VESA (80x60, 132x25/43/50/60) is
all that anyone wants. If Bochs and Qemu emulata a CL54xx, they'll provide a
VESA BIOS for it as well, I suppose?
Rene.
Rene Herman wrote:
> On 05/02/2007 10:59 PM, H. Peter Anvin wrote:
>
>> I'm having a framework for multiple drivers (probe and set methods,
>> basically); the stock distro will have VGA and VESA drivers only.
>> Dropping new drivers in is trivial if someone wants to.
>
> It sounds like going overboard a bit; 80x25 standard VGA, 80x43/50 line
> VGA (settable through simple BIOS calls) and VESA (80x60,
> 132x25/43/50/60) is all that anyone wants. If Bochs and Qemu emulata a
> CL54xx, they'll provide a VESA BIOS for it as well, I suppose?
Yes, but like most other VESA BIOSen they don't have any support for
extended text modes in their BIOS (they could add it, presumably.)
However, the pluggable framework is quite trivial and makes the code
look really clean, so I'm keeping it regardless.
-hpa
On 05/02/2007 11:15 PM, H. Peter Anvin wrote:
> However, the pluggable framework is quite trivial and makes the code
> look really clean, so I'm keeping it regardless.
Sheesh. Anyways, I know you asked about register writes but in case it's
still useful info: the CL54xx adapters have 132x43 and 132x25 as BIOS modes
0x54 and 0x55 (ie, just int 0x10 modes) respectively. No idea how complete
the Bochs/Qemu video BIOS is.
Rene.
Rene Herman wrote:
> On 05/02/2007 11:15 PM, H. Peter Anvin wrote:
>
>> However, the pluggable framework is quite trivial and makes the code
>> look really clean, so I'm keeping it regardless.
>
> Sheesh. Anyways, I know you asked about register writes but in case it's
> still useful info: the CL54xx adapters have 132x43 and 132x25 as BIOS
> modes 0x54 and 0x55 (ie, just int 0x10 modes) respectively. No idea how
> complete the Bochs/Qemu video BIOS is.
No, they don't. I've found enough Cirrus docs to learn that that was
pulled out of their BIOS when they ran out of space.
The Bochs/Qemu biosen don't have it.
-hpa
On 05/02/2007 11:25 PM, H. Peter Anvin wrote:
>> Anyways, I know you asked about register writes but in case it's
>> still useful info: the CL54xx adapters have 132x43 and 132x25 as BIOS
>> modes 0x54 and 0x55 (ie, just int 0x10 modes) respectively. No idea how
>> complete the Bochs/Qemu video BIOS is.
>
> No, they don't. I've found enough Cirrus docs to learn that that was
> pulled out of their BIOS when they ran out of space.
Mine has them.
Rene.
Rene Herman wrote:
> On 05/02/2007 11:25 PM, H. Peter Anvin wrote:
>
>>> Anyways, I know you asked about register writes but in case it's
>>> still useful info: the CL54xx adapters have 132x43 and 132x25 as BIOS
>>> modes 0x54 and 0x55 (ie, just int 0x10 modes) respectively. No idea how
>>> complete the Bochs/Qemu video BIOS is.
>>
>> No, they don't. I've found enough Cirrus docs to learn that that was
>> pulled out of their BIOS when they ran out of space.
>
> Mine has them.
>
The problem is to detect the ones that have it from the ones that don't.
-hpa
On 05/03/2007 12:11 AM, H. Peter Anvin wrote:
> The problem is to detect the ones that have it from the ones that don't.
Checking here, and mine also has 132x25 as BIOS mode 0x14 in addition to
0x55. Probably also not universal, and 0x54 (132x43) doesn't seem to be
repeated. Unfortunate that Qemu/Bocks don't have the VESA text modes.
Rene.
Rene Herman wrote:
> On 05/03/2007 12:11 AM, H. Peter Anvin wrote:
>
>> The problem is to detect the ones that have it from the ones that don't.
>
> Checking here, and mine also has 132x25 as BIOS mode 0x14 in addition to
> 0x55. Probably also not universal, and 0x54 (132x43) doesn't seem to be
> repeated. Unfortunate that Qemu/Bocks don't have the VESA text modes.
>
Does it export these modes though the VESA interface, or do you have to
"select them blind?"
-hpa
On 05/03/2007 12:59 AM, H. Peter Anvin wrote:
> Rene Herman wrote:
>> Checking here, and mine also has 132x25 as BIOS mode 0x14 in addition to
>> 0x55. Probably also not universal, and 0x54 (132x43) doesn't seem to be
>> repeated. Unfortunate that Qemu/Bocks don't have the VESA text modes.
>
> Does it export these modes though the VESA interface, or do you have to
> "select them blind?"
It also provides them as VESA modes yes. On further inspection, 0x14 is
actually a bit different:
BIOS 0x14 = 132x25, 8x16 char cell on 1056x400
BIOS 0x54 = VESA 0x10A = 132x43, 8x8 char cell on 1056x350
BIOS 0x55 = VESA 0x109 = 132x25, 8x14 char cell on 1056x350
Booting 2.6.20.1 on the machine with vga=ask finds BIOS 0x14 as 0214 and
VESA 0x10A as 030A but allows me to select 0254, 0255 and 0309 as well.
('scan' finds BIOS 0x14 as 0114 and BIOS 0x54 as 0154)
Rene.
Rene Herman wrote:
>
> It also provides them as VESA modes yes.
OK, so no work needed.
-hpa
* From: "H. Peter Anvin"
* Date: Tue, 01 May 2007 14:52:53 -0700
>
> Linus Torvalds wrote:
>>
>> 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 use framebuffer console pretty much for one purpose -- it sucks less
> memory bandwidth when you're stuck with a UMA configuration. Text modes
> require random access to the font buffer, which means it hogs the DRAM
> pretty badly, unless the chipset designer decided to burn an 8K SRAM,
> which is still a pretty pricey hunk of chip real estate.
When i first booted new Intel dualcore PC with
04:00.0 VGA compatible controller: ATI Technologies Inc RV370 [Sapphire X550 Silent]
back in November i discovered, that graphic/BIOS and normal text mode
aren't working right from power-on. I.e. it is with snow and random
switch on/off behavior, unless you do some reset button pushing.
Even after that is OK, shiny new 19" LCD from Sony with black screen and
glass in front of it in 80x25 mode shows contents in kind of unfocused
form. Yes it's because discrete pixels are not matching this legacy
resolution; standard graphic mode is so clear-cut, that i even can't
focus on it myself ;).
Thus, text mode on modern hardware isn't useable that much, only with
Terminus font it is kind of normal (kudos to Dimitar Toshkov Jekov).
But it's only option to unfortunately sucking X11, even with memory
bandwidth, you are talking about.
____
Oleg Verych wrote:
> Thus, text mode on modern hardware isn't useable that much, only with
> Terminus font it is kind of normal (kudos to Dimitar Toshkov Jekov).
> But it's only option to unfortunately sucking X11, even with memory
> bandwidth, you are talking about.
That's another reason to use the framebuffer console on laptops.
-hpa
On Wed, Jun 13, 2007 at 10:11:12PM -0700, H. Peter Anvin wrote:
> Oleg Verych wrote:
> > Thus, text mode on modern hardware isn't useable that much, only with
> > Terminus font it is kind of normal (kudos to Dimitar Toshkov Jekov).
> > But it's only option to unfortunately sucking X11, even with memory
> > bandwidth, you are talking about.
>
> That's another reason to use the framebuffer console on laptops.
Last time i tried, it wasn't so much fun either. Mainly due to wild
cursor, that in normal text mode is well-behaved thing. Visually fb looks
much heavier. What's the benefit, if you see how windows in emacs are
painted? I don't know how giga-hertz/mem in cpu/sys-ram,
mega-hertz/ram in gpu are doing better job WRT to anything in visual
domain.
Also i don't know what to do in case of bugs/oops and "officially" closed
hardware specs on ATI chips{ref}.
About laptop. First and last time i ran new X11 (X.org) there, it drove
VGA fan really crazy. Don't know how it changed now, it was certainly due
to blindly switching 3D on. I don't want to remove *standard* drivers
because of that stupidness [see ref].
And after whole year being with Debian Sarge only, new application update
led me to just drop all that X stuff and run windoze (silently sold to me
with that laptop) if i need a stupid web browser with all that WEB 2.0
and Java crap...
____