Force VM86 when VESA framebuffer is enabled and fix a typo
in the VM86 config entry. If VM86 is disabled there will
be problems when starting X using the VESA driver.
Signed-off-by: Chuck Ebbert <[email protected]>
--- 2.6.16-rc6-d2.orig/drivers/video/Kconfig
+++ 2.6.16-rc6-d2/drivers/video/Kconfig
@@ -456,6 +456,7 @@ config FB_TGA
config FB_VESA
bool "VESA VGA graphics support"
depends on (FB = y) && X86
+ select VM86
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--- 2.6.16-rc6-d2.orig/init/Kconfig
+++ 2.6.16-rc6-d2/init/Kconfig
@@ -224,7 +224,7 @@ config UID16
This enables the legacy 16-bit UID syscall wrappers.
config VM86
- depends X86
+ depends on X86
default y
bool "Enable VM86 support" if EMBEDDED
help
--
Chuck
"Penguins don't come from next door, they come from the Antarctic!"
On Mon, 2006-03-13 at 09:13 -0500, Chuck Ebbert wrote:
> Force VM86 when VESA framebuffer is enabled and fix a typo
> in the VM86 config entry. If VM86 is disabled there will
> be problems when starting X using the VESA driver.
this sounds wrong.
The kernel works fine; it's X that needs vm86.. (but it needs that
anyway).... but that's no reason to make one kernel option require
another....
On Llu, 2006-03-13 at 09:13 -0500, Chuck Ebbert wrote:
> Force VM86 when VESA framebuffer is enabled and fix a typo
> in the VM86 config entry. If VM86 is disabled there will
> be problems when starting X using the VESA driver.
VESA does not require VM86 so this change is completely wrong. Worse
still the x86-64 does not support VM86 so you have just crippled the
x86-64 port unneccessarily.
Please sort out your personal X server problem instead. To start with X
doesn't require VM86 to be present at all and can do software 8086 int
10 emulation for BIOS code.
Alan
In-Reply-To: <[email protected]>
References: <[email protected]>
On Mon, 13 Mar 2006 14:44:56 +0000, Alan Cox wrote:
> VESA does not require VM86 so this change is completely wrong.
What is this all about then?
Begin quote ------------------------------------------------------------------
Date: 10 Mar 2006 11:23:18 GMT
From: Kenneth Parrish <[email protected]>
Subject: [2.6.16-rc5-git13] Xorg.log difference
To: [email protected]
Message-ID: <[email protected]>
i see this difference with 2.6.16-rc5-git13 kernel. more info on request -kp
5c5
< Current Operating System: Linux fret 2.6.16-rc5-git13 #2 Fri Mar 10 10:45:41
2006 i686
---
> Current Operating System: Linux fret 2.6.15.6 #1 Tue Mar 07 13:44:04 2006 i686
13c13
< (==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar 10 04:49:26 2006
---
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar 10 05:02:35 2006
327,337c327,383
< (EE) ATI(0): unknown type(0xffffffff)=0xff
< (II) ATI(0): EAX=0x00004f00, EBX=0x00000000, ECX=0x00000000, EDX=0x00000000
< (II) ATI(0): ESP=0x00000ffa, EBP=0x00000000, ESI=0x00000000, EDI=0x00002000
< (II) ATI(0): CS=0xc000, SS=0x0100, DS=0x0040, ES=0x0000, FS=0x0000, GS=0x0000
< (II) ATI(0): EIP=0x00001306, EFLAGS=0x00003200
< (II) ATI(0): code at 0x000c1306:
< fb fc 80 fc a0 0f 84 a6 3c 80 fc 4f 0f 84 c0 2d
< 1e 06 57 56 55 52 51 53 50 50 8a c4 32 e4 d1 e0
< (II) stack at 0x00001ffa:
< 00 06 00 00 00 32
< (II) ATI(0): VESA BIOS not detected
---
> (II) ATI(0): VESA BIOS detected
> (II) ATI(0): VESA VBE Version 2.0
> (II) ATI(0): VESA VBE Total Mem: 4096 kB
> (II) ATI(0): VESA VBE OEM: ATI MACH64
> (II) ATI(0): VESA VBE OEM Software Rev: 1.0
> (II) ATI(0): VESA VBE OEM Vendor: ATI Technologies Inc.
> (II) ATI(0): VESA VBE OEM Product: MACH64GT
> (II) ATI(0): VESA VBE OEM Product Rev: 01.00
End quote ------------------------------------------------------------------
Begin quote ------------------------------------------------------------------
Date: 11 Mar 2006 03:01:00 GMT
From: Kenneth Parrish <[email protected]>
Subject: Re: [2.6.16-rc5-git13] Xorg.log difference
To: [email protected]
Message-ID: <[email protected]>
-=> In article 10 Mar 06 17:20:10, Ingo Oeser wrote to All <=-
yo Ingo :)
[ mach64 rage 3d dual pci+agp1 vbe undetected x11-6.7.0-i586-4 ]
[..]
IO> Did you disable vm86 support, too?
IO> # CONFIG_VM86 is not set
bet that's it - thank ya :)
End quote ------------------------------------------------------------------
> Worse
> still the x86-64 does not support VM86 so you have just crippled the
> x86-64 port unneccessarily.
Huh? I checked my working x86_64 .config and found this:
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
...
CONFIG_VM86=y
so I assumed it was OK to force VM86.
--
Chuck
"Penguins don't come from next door, they come from the Antarctic!"
Chuck Ebbert wrote:
> In-Reply-To: <[email protected]>
> References: <[email protected]>
>
> On Mon, 13 Mar 2006 14:44:56 +0000, Alan Cox wrote:
>
>
>> VESA does not require VM86 so this change is completely wrong.
>
> What is this all about then?
>
that is about X requiring it. Not about anything kernel related.
On Monday, March 13, 2006 9:01 am, Arjan van de Ven wrote:
> Chuck Ebbert wrote:
> > In-Reply-To: <[email protected]>
> > References: <[email protected]>
> >
> > On Mon, 13 Mar 2006 14:44:56 +0000, Alan Cox wrote:
> >> VESA does not require VM86 so this change is completely wrong.
> >
> > What is this all about then?
>
> that is about X requiring it. Not about anything kernel related.
And X doesn't actually require it, it's just that some builds of the X
int10 and VBE libraries assume it's available. They can be configured
to use an x86 emulator instead, and probably should be by default so
that non-x86 systems have a better chance of working (code coverage and
all that).
Jesse
On Mon, Mar 13, 2006 at 01:58:49PM -0800, Jesse Barnes wrote:
> On Monday, March 13, 2006 9:01 am, Arjan van de Ven wrote:
> > Chuck Ebbert wrote:
> > > In-Reply-To: <[email protected]>
> > > References: <[email protected]>
> > >
> > > On Mon, 13 Mar 2006 14:44:56 +0000, Alan Cox wrote:
> > >> VESA does not require VM86 so this change is completely wrong.
> > >
> > > What is this all about then?
> >
> > that is about X requiring it. Not about anything kernel related.
>
> And X doesn't actually require it, it's just that some builds of the X
> int10 and VBE libraries assume it's available. They can be configured
> to use an x86 emulator instead, and probably should be by default so
> that non-x86 systems have a better chance of working (code coverage and
> all that).
You can only disable CONFIG_VM86 if you have set CONFIG_EMBEDDED=y.
That's OK considering that CONFIG_EMBEDDED=y has the semantics:
Allow me to disable more options to save space no matter how much
this can break since I do _really_ know what I'm doing when I'm
enabling CONFIG_EMBEDDED.
Expecting working kernels when randomly toggling options that get
available with CONFIG_EMBEDDED=y is simply silly.
> Jesse
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Llu, 2006-03-13 at 23:16 +0100, Adrian Bunk wrote:
> You can only disable CONFIG_VM86 if you have set CONFIG_EMBEDDED=y.
Or are runnig under Xen or 32bit binaries on 64bit. Either way X can
already handle this if properly configured.
On Po 13-03-06 15:30:26, Arjan van de Ven wrote:
> On Mon, 2006-03-13 at 09:13 -0500, Chuck Ebbert wrote:
> > Force VM86 when VESA framebuffer is enabled and fix a typo
> > in the VM86 config entry. If VM86 is disabled there will
> > be problems when starting X using the VESA driver.
>
>
> this sounds wrong.
>
> The kernel works fine; it's X that needs vm86.. (but it needs that
> anyway).... but that's no reason to make one kernel option require
> another....
How does X solve it on x86-64? x86-64 has no vm86. I agree it is X
that needs fixing.
Pavel
--
199: private byte [] sbuffer;
On Tue, 2006-03-14 at 22:56 +0100, Pavel Machek wrote:
> On Po 13-03-06 15:30:26, Arjan van de Ven wrote:
> > On Mon, 2006-03-13 at 09:13 -0500, Chuck Ebbert wrote:
> > > Force VM86 when VESA framebuffer is enabled and fix a typo
> > > in the VM86 config entry. If VM86 is disabled there will
> > > be problems when starting X using the VESA driver.
> >
> >
> > this sounds wrong.
> >
> > The kernel works fine; it's X that needs vm86.. (but it needs that
> > anyway).... but that's no reason to make one kernel option require
> > another....
>
> How does X solve it on x86-64? x86-64 has no vm86. I agree it is X
> that needs fixing.
X has a complete enough x86 emulator for this stuff. Some builds of X
don't use it on x86, but it works just fine; all other architectures
use it always anyway