Mailing List Archive

--- Rene Herman <rene.herman@gmail.com> wrote:
> On 05/02/2007 12:41 AM, Vlad wrote:
>
> > H. Peter Anvin wrote:
>
> >> I'm rewriting the i386 setup code in C, instead of assembly,
> >> and before I spend a very large amount of time translating
> >> all the various card-specific probes, I want to ask the
> >> following question...
> >>
> >> Does *anyone* care about these anymore?
> >
> > Yes, booting Linux on old i386/i486 hardware is still very useful
> for
> > forensic purposes and recovering important data. I've personally
> had
> > to do this many times, and I'm sure others have as well.
> >
> > Booting is such a critical process that a user would be completely
> > lost as to why it fails, especially if they can't see any output
> on
> > the screen. I think it would be a shame to prevent Linux from
> running
> > on these machines.
>
> He wasn't asking about doing away with all video output on 386/486s,
> but
> with special Super VGA adapter specific modes. You'd have normal VGA
>
> available as always, and VESA if the videocard supports it (which
> all cards
> that _can_ do more than 80x25 do).

Oh, OK. Thanks for clarifying this for me.

Vlad

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi!

> I mean the SVGA chip-specific code.

Feel free to kill it, anybody using these cards is very unlikely to run
a 2.6.x kernel.

However, the BIOS mode switching is still useful.

Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wednesday 02 May 2007 09:46:07 Martin Mares wrote:
> Hi!
>
> > I mean the SVGA chip-specific code.
>
> Feel free to kill it, anybody using these cards is very unlikely to run
> a 2.6.x kernel.

I agree; that code can all go.

What also seems to miss are the early CPUID checks I recently added
and which x86-64 has for some time.

Also if you ever add x86-64 support it does an additional BIOS
call to tell the BIOS it is 64bit.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On May 1 2007 15:41, Vlad wrote:
>H. Peter Anvin wrote:
>> I'm rewriting the i386 setup code in C, instead of assembly,
>> and before I spend a very large amount of time translating
>> all the various card-specific probes, I want to ask the
>> following question...
>>
>> Does *anyone* care about these anymore?
>
>Yes, booting Linux on old i386/i486 hardware is still very useful for
>forensic purposes and recovering important data.

Not only that, but there's tons of fun involved. I mean, when was the
last time you ran a *recent* kernel from the 2006/2007 era on an
original i386 from 1990 with 3 bogomips? :) (Though I guess these
boxes don't have any 'modern' video besides 640x480x16 or 320x200x256
anyway.)

Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, May 02, 2007 at 09:46:07AM +0200, Martin Mares wrote:
> > I mean the SVGA chip-specific code.
>
> Feel free to kill it, anybody using these cards is very unlikely to run
> a 2.6.x kernel.
>
> However, the BIOS mode switching is still useful.

I have a 486 with a Mach64 in it running 2.6.18, so well, it just might
happen you know. I do tend to run it plain 80x25 at the moment, but
that is mainly because it is just doing firewall duties. I never was
very impressed by the mach64 fb driver when I played with it years ago,
and vesa isn't an option on that card (needed a DOS TSR to do that).

Not sure if that card is covered by any of the chip specific code.

So what is wrong with a 15 year old machine when it has 48MB ram and
18GB disk space?

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen wrote:
>
> I agree; that code can all go.
>
> What also seems to miss are the early CPUID checks I recently added
> and which x86-64 has for some time.
>
> Also if you ever add x86-64 support it does an additional BIOS
> call to tell the BIOS it is 64bit.
>

Will do. I'd like to make this code unified between i386 and x86-64.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rene Herman wrote:
>
> It also provides them as VESA modes yes.

OK, so no work needed.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen wrote:
>
> I agree; that code can all go.
>
> What also seems to miss are the early CPUID checks I recently added
> and which x86-64 has for some time.
>

I probably need to rebase against your tree. It makes more sense, anyway.

Either way, I just added a pretty decent framework for testing the CPU
features and barfing if they're missing.

> Also if you ever add x86-64 support it does an additional BIOS
> call to tell the BIOS it is 64bit.

Added.

-hpa


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* 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.
____
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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...
____
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/