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 me
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 t
* 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
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
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
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 exp
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
>
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 Q
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
>>> comple
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
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 CL
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 1
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 over
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,
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
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 mak
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.1
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 actuall
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 t
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
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 <[EMAIL PROTEC
--- Rene Herman <[EMAIL PROTECTED]> 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
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 anymo
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
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
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
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 o
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: th
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
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 gr
On Mon, Apr 30, 2007 at 06:33:09PM -0700, H. Peter Anvin wrote:
>Hi all,
>
>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 a
Eric W. Biederman wrote:
>
> I would be very surprised if the high volume commodity boards have
> exceeded 8 megabits.
>
Most of the high-capacity chips are used on laptops, not conventional
motherboards.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Andi Kleen <[EMAIL PROTECTED]> writes:
>>
Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
and ubiquitousness,
>>> Simplicity? That must be why x86 motherbords are shipping with (compresse
Andi Kleen wrote:
>
> At least my Asus board with 8Mb flash doesn't have anything called that.
> There is also no special preboot environment
>
> iirc Asus ships dual BIOS though, but even half that compressed is a lot.
>
8 Mb or 8 MB? Big difference...
So you have 512K worth of compressed co
On Mon, Apr 30, 2007 at 07:54:27PM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
> >> and ubiquitousness,
> >
> > Simplicity? That must be why x86 motherbords are shipping with (compressed)
> > 8MB BIOS flash chips n
Eric W. Biederman wrote:
> Andi Kleen <[EMAIL PROTECTED]> writes:
>
>>> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
>>> and ubiquitousness,
>> Simplicity? That must be why x86 motherbords are shipping with (compressed)
>> 8MB BIOS flash chips now.
>
> Those would be
Andi Kleen <[EMAIL PROTECTED]> writes:
>> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
>> and ubiquitousness,
>
> Simplicity? That must be why x86 motherbords are shipping with (compressed)
> 8MB BIOS flash chips now.
Those would be 8 megabit chips, and those would be
On Mon, Apr 30, 2007 at 07:43:54PM -0700, 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.
heh. it was only recently I gave away a _dual head_ pci et4000.
One of our X guys grabbed it because
Andi Kleen wrote:
>> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
>> and ubiquitousness,
>
> Simplicity? That must be why x86 motherbords are shipping with (compressed)
> 8MB BIOS flash chips now.
Very little of that is the actual BIOS, though. Most of it is generall
> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
> and ubiquitousness,
Simplicity? That must be why x86 motherbords are shipping with (compressed)
8MB BIOS flash chips now.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Mon, 30 Apr 2007, H. Peter Anvin wrote:
>
> Does *anyone* care about these anymore?
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 k
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Dave Jones wrote:
>>
>> I don't really care, but I wonder what the point is of rewriting something
>> that hardly ever gets notably changed, and is rarely (if ever?) a source
>> of bugs. It might be crufty old assembly, but it's worked well for year
Dave Jones wrote:
>
> I don't really care, but I wonder what the point is of rewriting something
> that hardly ever gets notably changed, and is rarely (if ever?) a source
> of bugs. It might be crufty old assembly, but it's worked well for years.
>
Well, it hardly gets notably changed because
On Mon, Apr 30, 2007 at 06:33:09PM -0700, H. Peter Anvin wrote:
> Hi all,
>
> 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 *
Jeff Garzik wrote:
>
> Do you mean the SVGA chip-specific code, or additionally you are ripping
> out CGA and EGA support?
>
I mean the SVGA chip-specific code.
> Out of curiosity what C compiler will you use?
gcc, using the ".code16gcc" feature of any non-prehistoric binutils.
-hpa
-
H. Peter Anvin wrote:
Hi all,
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?
All of these are specific
Hi all,
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?
All of these are specific to cards from a very lon
47 matches
Mail list logo
