Re: Rivafb won't work with DVI connector

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

--- Andrew Walrond <andrew@walrond.org> wrote:

> On Tuesday 23 Nov 2004 18:26, Antonino A. Daplas
> wrote:
> >
> > Does vesafb work in x86_64?  If it does you can
> add this in your
> > commandline:
> >
> > vga=0x307
> >
> > 0x306 is the code for 1280x1024, see
> Documentation/fb/vesafb.txt.
> >
> > Then check your dmesg if the panel size also
> changed.  If it did, then
> > you can do this:
> >
> > vga=0x307 video=nvidiafb:1280x1024@60.
> >
> 
> If I did this right, it doesn't help. I built in the
> vesafb as well as your 
> new nvidafb, then booted with the commandline
> 
>  vga=0x31b video=nvidiafb:1280x1024-32@60

That's assuming 0x31b is supported by your card.  Why not
try:

vga=ask

Choose 'scan', choose the highest size, and check if the panel
size changed again.

> 
> It looks like the nvidafb got the first bite of the
> cherry:

No, vesafb will always get the first bite, it's initialized when the OS is in
real mode.

> 
>  ...
>  nvidiafb: CRTC 1 is currently programmed for DFP
>  nvidiafb: Using DFP on CRTC 1
>  Panel size is 1024 x 768
>  nvidiafb: MTRR set to ON
>  Console: switching to colour frame buffer device
> 128x48
>  nvidiafb: PCI nVidia NV25 framebuffer (128MB @
> 0xE0000000)
>  vesafb: probe of vesafb0 failed with error -6
>  ...
> 
> 
> Do you know if the nvidia developers lurk on lkml? I

I did not subscribe to lkml.  But I do occassionally look at the archives.

> seem to remember somebody 
> saying that they do. If so, is it worth asking them
> for a bit of help with 
> this? I know they're not about to open source their
> binary driver due to ip 
> license problems, but the information we require to
> overcome this problem in 
> the fb driver is probably quite trivial in nature. I

Well, checking the latest Xorg again, it seems that the nv driver also
depends on the BIOS for the panel size.  And they are the people who does
have access to the docs.

> assume they have been 
> forthcoming in the past wrt the open source X
> driver.
> 
> What do you think? Worth asking?

Sure, no harm in asking.  But I would rather ask the Xorg people first.  If
we can't get the vga=ask to work, then I really don't know what to do,
besides perhaps experimenting with VBE calls.  I can  do that, but I do not
have any flatpanel to test on.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Thursday 25 Nov 2004 00:07, Antonino A. Daplas wrote:
>
> That's assuming 0x31b is supported by your card.  Why not
> try:
>
> vga=ask
>
> Choose 'scan', choose the highest size, and check if the panel
> size changed again.

vesafb 'scan' can only find 80xwhatever text modes with dvi connnection, and 
upto 132xwhatever text modes with dsub. It does not display any graphics 
modes at all, and rejects them if I try. (I also tried with vesafb only, 
nvidafb removed - same result).

>
> Well, checking the latest Xorg again, it seems that the nv driver also
> depends on the BIOS for the panel size.  And they are the people who does
> have access to the docs.

Ok; But remember that I can run this screen with DVI connection at 1600x1200 
just fine with the proprietary nvidia driver. (Infact I routinely run it dual 
head with both TFTs at 1600x1200, one on dvim one on dsub) so its not the 
case that it can't be done. Iff the Xorg guys have docs, perhaps they can 
work out how to do it.

>
> Sure, no harm in asking.  But I would rather ask the Xorg people first.  If

Ok, go ask Xorg. If you don't have any luck, I'll get in touch with Nvidia 
directly and see if they will help.

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

On Thursday 25 November 2004 23:27, Andrew Walrond wrote:
> On Thursday 25 Nov 2004 00:07, Antonino A. Daplas wrote:
> > That's assuming 0x31b is supported by your card.  Why not
> > try:
> >
> > vga=ask
> >
> > Choose 'scan', choose the highest size, and check if the panel
> > size changed again.
>
> vesafb 'scan' can only find 80xwhatever text modes with dvi connnection,
> and upto 132xwhatever text modes with dsub. It does not display any
> graphics modes at all, and rejects them if I try. (I also tried with vesafb
> only, nvidafb removed - same result).
>
> > Well, checking the latest Xorg again, it seems that the nv driver also
> > depends on the BIOS for the panel size.  And they are the people who does
> > have access to the docs.
>
> Ok; But remember that I can run this screen with DVI connection at
> 1600x1200 just fine with the proprietary nvidia driver. (Infact I routinely

I'm pretty sure it's not a hardware limitation or I would have mentioned that
before.

> run it dual head with both TFTs at 1600x1200, one on dvim one on dsub) so
> its not the case that it can't be done. Iff the Xorg guys have docs,
> perhaps they can work out how to do it.
>
> > Sure, no harm in asking.  But I would rather ask the Xorg people first. 
> > If
>
> Ok, go ask Xorg. If you don't have any luck, I'll get in touch with Nvidia
> directly and see if they will help.

I sent mail to devel@xfree86.org.  Particularly one member Mark Vojkovich
actually works for nvidia and helps in the development of both the open and
closed source driver.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

On Thursday 25 November 2004 23:27, Andrew Walrond wrote:
> On Thursday 25 Nov 2004 00:07, Antonino A. Daplas wrote:
> > That's assuming 0x31b is supported by your card.  Why not
> > try:
> >
> > vga=ask
> >
> > Choose 'scan', choose the highest size, and check if the panel
> > size changed again.
>
> vesafb 'scan' can only find 80xwhatever text modes with dvi connnection,
> and upto 132xwhatever text modes with dsub. It does not display any
> graphics modes at all, and rejects them if I try. (I also tried with vesafb
> only, nvidafb removed - same result).

You can also try this.  1600x1200 is not a standard VESA mode but is most
probably supported by your card as an OEM mode.  However, we do not know the
mode id of 1600x1200 since it's different from vendor to vendor.  

You can use X though to find out what modes are supported by your Video
BIOS.  

1. Boot with DVI attached
2. Change the X driver to 'vesa' (instead of probably 'nv')
3. Launch X
4. Check /var/log/XFree86.?.log
5. Find the mode id you want, add 0x200 and use it in your 'vga='
   boot line

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]

On Friday 26 Nov 2004 14:09, Antonino A. Daplas wrote:
> On Thursday 25 November 2004 23:27, Andrew Walrond wrote:
> > On Thursday 25 Nov 2004 00:07, Antonino A. Daplas wrote:
> > > That's assuming 0x31b is supported by your card.  Why not
> > > try:
> > >
> > > vga=ask
> > >
> > > Choose 'scan', choose the highest size, and check if the panel
> > > size changed again.
> >
> > vesafb 'scan' can only find 80xwhatever text modes with dvi connnection,
> > and upto 132xwhatever text modes with dsub. It does not display any
> > graphics modes at all, and rejects them if I try. (I also tried with
> > vesafb only, nvidafb removed - same result).
>
> You can also try this.  1600x1200 is not a standard VESA mode but is most
> probably supported by your card as an OEM mode.  However, we do not know
> the mode id of 1600x1200 since it's different from vendor to vendor.
>
> You can use X though to find out what modes are supported by your Video
> BIOS.
>
> 1. Boot with DVI attached
> 2. Change the X driver to 'vesa' (instead of probably 'nv')
> 3. Launch X
> 4. Check /var/log/XFree86.?.log
> 5. Find the mode id you want, add 0x200 and use it in your 'vga='
>    boot line
>

Hi Tony,

The X vesa driver finds lots of modes when connected with DSUB,including 145 
(1600x1200-8) and 146 (1600x1200-16)

However, when booting with DVI, it only finds these (from X log, full log 
attached)

 andrew@orac ~ $ grep Mode:  Xorg.dvi.vesa.log
 Mode: 100 (640x400)
 Mode: 101 (640x480)
 Mode: 102 (800x600)
 Mode: 103 (800x600)
 Mode: 10e (320x200)
 *Mode: 10f (320x200)
 Mode: 111 (640x480)
 *Mode: 112 (640x480)
 Mode: 114 (800x600)
 *Mode: 115 (800x600)
 Mode: 130 (320x200)
 Mode: 131 (320x400)
 Mode: 132 (320x400)
 *Mode: 133 (320x400)
 Mode: 134 (320x240)
 Mode: 135 (320x240)
 *Mode: 136 (320x240)
 Mode: 13d (640x400)
 *Mode: 13e (640x400)

none which are useful. Trying some of the modes from the DSUB log (ie 145 = 
vga=0x345 etc ) results always in (from memory) "Unsupported mode supplied; 
hit enter for list for wait 30s to continue" during boot. As I said, scan 
only finds text modes.

So, not only is this not going to work, but the vesa driver also seems broken 
when used with dvi.

Andrew

[-- Attachment #2: Xorg.dvi.vesa.log --]
[-- Type: text/x-log, Size: 47216 bytes --]


X Window System Version 6.8.0
Release Date: 8 September 2004
X Protocol Version 11, Revision 0, Release 6.8
Build Operating System: Linux 2.6.8.1 x86_64 [ELF] 
Current Operating System: Linux orac.walrond.org 2.6.10-rc2 #14 SMP Sat Nov 27 12:03:10 GMT 2004 x86_64
Build Date: 09 September 2004
	Before reporting problems, check http://wiki.X.Org
	to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/pkg/x11.2/state/log/Xorg.0.log", Time: Sat Nov 27 12:13:07 2004
(==) Using config file: "/pkg/x11.2/lib/X11/xorg.conf"
(==) ServerLayout "X.org Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "Card0"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(==) FontPath set to "/pkg/x11.2/lib/X11/fonts/misc/,/pkg/x11.2/lib/X11/fonts/TTF/,/pkg/x11.2/lib/X11/fonts/Type1/,/pkg/x11.2/lib/X11/fonts/CID/,/pkg/x11.2/lib/X11/fonts/75dpi/,/pkg/x11.2/lib/X11/fonts/100dpi/"
(**) RgbPath set to "/pkg/x11.2/lib/X11/rgb"
(**) ModulePath set to "/pkg/x11.2/lib64/modules"
(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.2
	X.Org Video Driver: 0.7
	X.Org XInput driver : 0.4
	X.Org Server Extension : 0.2
	X.Org Font Renderer : 0.4
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /pkg/x11.2/lib64/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	Module class: X.Org Font Renderer
	ABI class: X.Org Font Renderer, version 0.4
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /pkg/x11.2/lib64/modules/libpcidata.a
(II) Module pcidata: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	ABI class: X.Org Video Driver, version 0.7
(--) using VT number 5

(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x8000c29c, mode1Res1 = 0x80000000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:06:0: chip 1022,7460 card 0000,0000 rev 07 class 06,04,00 hdr 01
(II) PCI: 00:07:0: chip 1022,7468 card 1022,7468 rev 05 class 06,01,00 hdr 80
(II) PCI: 00:07:1: chip 1022,7469 card 1022,7469 rev 03 class 01,01,8a hdr 00
(II) PCI: 00:07:2: chip 1022,746a card 1022,746a rev 02 class 0c,05,00 hdr 00
(II) PCI: 00:07:3: chip 1022,746b card 1022,746b rev 05 class 06,80,00 hdr 00
(II) PCI: 00:07:5: chip 1022,746d card 10f1,2885 rev 03 class 04,01,00 hdr 00
(II) PCI: 00:0a:0: chip 1022,7450 card 0000,0000 rev 12 class 06,04,00 hdr 81
(II) PCI: 00:0a:1: chip 1022,7451 card 1022,36c0 rev 01 class 08,00,10 hdr 00
(II) PCI: 00:0b:0: chip 1022,7450 card 0000,0000 rev 12 class 06,04,00 hdr 81
(II) PCI: 00:0b:1: chip 1022,7451 card 1022,36c0 rev 01 class 08,00,10 hdr 00
(II) PCI: 00:18:0: chip 1022,1100 card 0000,0000 rev 00 class 06,00,00 hdr 80
(II) PCI: 00:18:1: chip 1022,1101 card 0000,0000 rev 00 class 06,00,00 hdr 80
(II) PCI: 00:18:2: chip 1022,1102 card 0000,0000 rev 00 class 06,00,00 hdr 80
(II) PCI: 00:18:3: chip 1022,1103 card 0000,0000 rev 00 class 06,00,00 hdr 80
(II) PCI: 00:19:0: chip 1022,1100 card 0000,0000 rev 00 class 06,00,00 hdr 80
(II) PCI: 00:19:1: chip 1022,1101 card 0000,0000 rev 00 class 06,00,00 hdr 80
(II) PCI: 00:19:2: chip 1022,1102 card 0000,0000 rev 00 class 06,00,00 hdr 80
(II) PCI: 00:19:3: chip 1022,1103 card 0000,0000 rev 00 class 06,00,00 hdr 80
(II) PCI: 02:09:0: chip 14e4,16a7 card 10f1,2885 rev 02 class 02,00,00 hdr 00
(II) PCI: 03:00:0: chip 1022,7464 card 1022,7464 rev 0b class 0c,03,10 hdr 80
(II) PCI: 03:00:1: chip 1022,7464 card 1022,7464 rev 0b class 0c,03,10 hdr 00
(II) PCI: 03:0a:0: chip 102b,0519 card 0000,0000 rev 01 class 03,80,00 hdr 00
(II) PCI: 03:0b:0: chip 1095,3114 card 1095,3114 rev 02 class 01,80,00 hdr 00
(II) PCI: 03:0c:0: chip 104c,8023 card 10f1,2885 rev 00 class 0c,00,10 hdr 00
(II) PCI: 04:00:0: chip 1022,7454 card 1022,7454 rev 14 class 06,00,00 hdr 00
(II) PCI: 04:01:0: chip 1022,7455 card 0000,0000 rev 14 class 06,04,00 hdr 01
(II) PCI: 05:00:0: chip 10de,0250 card 1462,8724 rev a2 class 03,00,00 hdr 00
(II) PCI: End of PCI scan
(II) PCI-to-PCI bridge:
(II) Bus 3: bridge is at (0:6:0), (0,3,3), BCTRL: 0x0406 (VGA_EN is cleared)
(II) Bus 3 I/O range:
	[0] -1	0	0x0000a000 - 0x0000a0ff (0x100) IX[B]
	[1] -1	0	0x0000a400 - 0x0000a4ff (0x100) IX[B]
	[2] -1	0	0x0000a800 - 0x0000a8ff (0x100) IX[B]
	[3] -1	0	0x0000ac00 - 0x0000acff (0x100) IX[B]
	[4] -1	0	0x0000b000 - 0x0000b0ff (0x100) IX[B]
	[5] -1	0	0x0000b400 - 0x0000b4ff (0x100) IX[B]
	[6] -1	0	0x0000b800 - 0x0000b8ff (0x100) IX[B]
	[7] -1	0	0x0000bc00 - 0x0000bcff (0x100) IX[B]
(II) Bus 3 non-prefetchable memory range:
	[0] -1	0	0xfc700000 - 0xfc8fffff (0x200000) MX[B]
(II) Bus 3 prefetchable memory range:
	[0] -1	0	0xdb300000 - 0xdc2fffff (0x1000000) MX[B]
(II) PCI-to-ISA bridge:
(II) Bus -1: bridge is at (0:7:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set)
(II) PCI-to-PCI bridge:
(II) Bus 2: bridge is at (0:10:0), (0,2,2), BCTRL: 0x0005 (VGA_EN is cleared)
(II) Bus 2 non-prefetchable memory range:
	[0] -1	0	0xfc600000 - 0xfc6fffff (0x100000) MX[B]
(II) Bus 2 prefetchable memory range:
	[0] -1	0	0xdb200000 - 0xdb2fffff (0x100000) MX[B]
(II) PCI-to-PCI bridge:
(II) Bus 1: bridge is at (0:11:0), (0,1,1), BCTRL: 0x0005 (VGA_EN is cleared)
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:24:0), (0,0,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 0 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Bus 0 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Host-to-PCI bridge:
(II) Bus -1: bridge is at (0:24:1), (-1,-1,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus -1 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus -1 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Bus -1 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Host-to-PCI bridge:
(II) Bus -1: bridge is at (0:24:2), (-1,-1,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus -1 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus -1 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Bus -1 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Host-to-PCI bridge:
(II) Bus -1: bridge is at (0:24:3), (-1,-1,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus -1 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus -1 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Bus -1 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Host-to-PCI bridge:
(II) Bus -1: bridge is at (0:25:0), (-1,-1,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus -1 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus -1 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Bus -1 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Host-to-PCI bridge:
(II) Bus -1: bridge is at (0:25:1), (-1,-1,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus -1 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus -1 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Bus -1 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Host-to-PCI bridge:
(II) Bus -1: bridge is at (0:25:2), (-1,-1,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus -1 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus -1 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Bus -1 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Host-to-PCI bridge:
(II) Bus -1: bridge is at (0:25:3), (-1,-1,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus -1 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus -1 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Bus -1 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Host-to-PCI bridge:
(II) Bus 4: bridge is at (4:0:0), (4,4,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 4 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 4 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) Bus 4 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
(II) PCI-to-PCI bridge:
(II) Bus 5: bridge is at (4:1:0), (4,5,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 5 non-prefetchable memory range:
	[0] -1	0	0xfca00000 - 0xfeafffff (0x2100000) MX[B]
(II) Bus 5 prefetchable memory range:
	[0] -1	0	0xdc400000 - 0xec4fffff (0x10100000) MX[B]
(--) PCI: (3:10:0) Matrox Graphics, Inc. MGA 2064W [Millennium] rev 1, Mem @ 0xfc8f4000/14, 0xdb800000/23
(--) PCI:*(5:0:0) nVidia Corporation NV25 [GeForce4 Ti 4600] rev 162, Mem @ 0xfd000000/24, 0xe0000000/27, 0xec480000/19, BIOS @ 0xfeae0000/17
(II) Addressable bus resource ranges are
	[0] -1	0	0x00000000 - 0xffffffff (0x100000000) MX[B]
	[1] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) OS-reported resource ranges:
	[0] -1	0	0xffe00000 - 0xffffffff (0x200000) MX[B](B)
	[1] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[2] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[3] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[4] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[5] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[6] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) PCI Memory resource overlap reduced 0xf0000000 from 0xf7ffffff to 0xefffffff
(II) Active PCI resource ranges:
	[0] -1	0	0xf0000000 - 0xefffffff (0x0) MX[B]O
	[1] -1	0	0xfc8f8000 - 0xfc8fbfff (0x4000) MX[B]
	[2] -1	0	0xfc8ff000 - 0xfc8ff7ff (0x800) MX[B]
	[3] -1	0	0xfc8ffc00 - 0xfc8fffff (0x400) MX[B]
	[4] -1	0	0xfc8fe000 - 0xfc8fefff (0x1000) MX[B]
	[5] -1	0	0xfc8fd000 - 0xfc8fdfff (0x1000) MX[B]
	[6] -1	0	0xfc6f0000 - 0xfc6fffff (0x10000) MX[B]
	[7] -1	0	0xfc9ff000 - 0xfc9fffff (0x1000) MX[B]
	[8] -1	0	0xfc9fe000 - 0xfc9fefff (0x1000) MX[B]
	[9] -1	0	0xfeae0000 - 0xfeafffff (0x20000) MX[B](B)
	[10] -1	0	0xec480000 - 0xec4fffff (0x80000) MX[B](B)
	[11] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[12] -1	0	0xfd000000 - 0xfdffffff (0x1000000) MX[B](B)
	[13] -1	0	0xdb800000 - 0xdbffffff (0x800000) MX[B](B)
	[14] -1	0	0xfc8f4000 - 0xfc8f7fff (0x4000) MX[B](B)
	[15] -1	0	0x0000ac00 - 0x0000ac0f (0x10) IX[B]
	[16] -1	0	0x0000b000 - 0x0000b003 (0x4) IX[B]
	[17] -1	0	0x0000b400 - 0x0000b407 (0x8) IX[B]
	[18] -1	0	0x0000b800 - 0x0000b803 (0x4) IX[B]
	[19] -1	0	0x0000bc00 - 0x0000bc07 (0x8) IX[B]
	[20] -1	0	0x0000cc00 - 0x0000cc3f (0x40) IX[B]
	[21] -1	0	0x0000c800 - 0x0000c8ff (0x100) IX[B]
	[22] -1	0	0x0000c400 - 0x0000c41f (0x20) IX[B]
	[23] -1	0	0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
(II) Active PCI resource ranges after removing overlaps:
	[0] -1	0	0xf0000000 - 0xefffffff (0x0) MX[B]O
	[1] -1	0	0xfc8f8000 - 0xfc8fbfff (0x4000) MX[B]
	[2] -1	0	0xfc8ff000 - 0xfc8ff7ff (0x800) MX[B]
	[3] -1	0	0xfc8ffc00 - 0xfc8fffff (0x400) MX[B]
	[4] -1	0	0xfc8fe000 - 0xfc8fefff (0x1000) MX[B]
	[5] -1	0	0xfc8fd000 - 0xfc8fdfff (0x1000) MX[B]
	[6] -1	0	0xfc6f0000 - 0xfc6fffff (0x10000) MX[B]
	[7] -1	0	0xfc9ff000 - 0xfc9fffff (0x1000) MX[B]
	[8] -1	0	0xfc9fe000 - 0xfc9fefff (0x1000) MX[B]
	[9] -1	0	0xfeae0000 - 0xfeafffff (0x20000) MX[B](B)
	[10] -1	0	0xec480000 - 0xec4fffff (0x80000) MX[B](B)
	[11] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[12] -1	0	0xfd000000 - 0xfdffffff (0x1000000) MX[B](B)
	[13] -1	0	0xdb800000 - 0xdbffffff (0x800000) MX[B](B)
	[14] -1	0	0xfc8f4000 - 0xfc8f7fff (0x4000) MX[B](B)
	[15] -1	0	0x0000ac00 - 0x0000ac0f (0x10) IX[B]
	[16] -1	0	0x0000b000 - 0x0000b003 (0x4) IX[B]
	[17] -1	0	0x0000b400 - 0x0000b407 (0x8) IX[B]
	[18] -1	0	0x0000b800 - 0x0000b803 (0x4) IX[B]
	[19] -1	0	0x0000bc00 - 0x0000bc07 (0x8) IX[B]
	[20] -1	0	0x0000cc00 - 0x0000cc3f (0x40) IX[B]
	[21] -1	0	0x0000c800 - 0x0000c8ff (0x100) IX[B]
	[22] -1	0	0x0000c400 - 0x0000c41f (0x20) IX[B]
	[23] -1	0	0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
(II) OS-reported resource ranges after removing overlaps with PCI:
	[0] -1	0	0xffe00000 - 0xffffffff (0x200000) MX[B](B)
	[1] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[2] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[3] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[4] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[5] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[6] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) All system resource ranges:
	[0] -1	0	0xffe00000 - 0xffffffff (0x200000) MX[B](B)
	[1] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[2] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[3] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[4] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[5] -1	0	0xf0000000 - 0xefffffff (0x0) MX[B]O
	[6] -1	0	0xfc8f8000 - 0xfc8fbfff (0x4000) MX[B]
	[7] -1	0	0xfc8ff000 - 0xfc8ff7ff (0x800) MX[B]
	[8] -1	0	0xfc8ffc00 - 0xfc8fffff (0x400) MX[B]
	[9] -1	0	0xfc8fe000 - 0xfc8fefff (0x1000) MX[B]
	[10] -1	0	0xfc8fd000 - 0xfc8fdfff (0x1000) MX[B]
	[11] -1	0	0xfc6f0000 - 0xfc6fffff (0x10000) MX[B]
	[12] -1	0	0xfc9ff000 - 0xfc9fffff (0x1000) MX[B]
	[13] -1	0	0xfc9fe000 - 0xfc9fefff (0x1000) MX[B]
	[14] -1	0	0xfeae0000 - 0xfeafffff (0x20000) MX[B](B)
	[15] -1	0	0xec480000 - 0xec4fffff (0x80000) MX[B](B)
	[16] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[17] -1	0	0xfd000000 - 0xfdffffff (0x1000000) MX[B](B)
	[18] -1	0	0xdb800000 - 0xdbffffff (0x800000) MX[B](B)
	[19] -1	0	0xfc8f4000 - 0xfc8f7fff (0x4000) MX[B](B)
	[20] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[21] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[22] -1	0	0x0000ac00 - 0x0000ac0f (0x10) IX[B]
	[23] -1	0	0x0000b000 - 0x0000b003 (0x4) IX[B]
	[24] -1	0	0x0000b400 - 0x0000b407 (0x8) IX[B]
	[25] -1	0	0x0000b800 - 0x0000b803 (0x4) IX[B]
	[26] -1	0	0x0000bc00 - 0x0000bc07 (0x8) IX[B]
	[27] -1	0	0x0000cc00 - 0x0000cc3f (0x40) IX[B]
	[28] -1	0	0x0000c800 - 0x0000c8ff (0x100) IX[B]
	[29] -1	0	0x0000c400 - 0x0000c41f (0x20) IX[B]
	[30] -1	0	0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
(II) LoadModule: "extmod"
(II) Loading /pkg/x11.2/lib64/modules/extensions/libextmod.a
(II) Module extmod: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 0.2
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "glx"
(II) Loading /pkg/x11.2/lib64/modules/extensions/libglx.a
(II) Module glx: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.2
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /pkg/x11.2/lib64/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.2
(II) Loading extension GLX
(II) LoadModule: "dri"
(II) Loading /pkg/x11.2/lib64/modules/extensions/libdri.a
(II) Module dri: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.2
(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /pkg/x11.2/lib64/modules/linux/libdrm.a
(II) Module drm: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.2
(II) Loading extension XFree86-DRI
(II) LoadModule: "dbe"
(II) Loading /pkg/x11.2/lib64/modules/extensions/libdbe.a
(II) Module dbe: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 0.2
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "record"
(II) Loading /pkg/x11.2/lib64/modules/extensions/librecord.a
(II) Module record: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.13.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 0.2
(II) Loading extension RECORD
(II) LoadModule: "xtrap"
(II) Loading /pkg/x11.2/lib64/modules/extensions/libxtrap.a
(II) Module xtrap: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 0.2
(II) Loading extension DEC-XTRAP
(II) LoadModule: "vesa"
(II) Loading /pkg/x11.2/lib64/modules/drivers/vesa_drv.o
(II) Module vesa: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 0.7
(II) LoadModule: "mouse"
(II) Loading /pkg/x11.2/lib64/modules/input/mouse_drv.o
(II) Module mouse: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 0.4
(II) LoadModule: "kbd"
(II) Loading /pkg/x11.2/lib64/modules/input/kbd_drv.o
(II) Module kbd: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 0.4
(II) VESA: driver for VESA chipsets: vesa
(II) Primary Device is: PCI 05:00:0
(--) Chipset vesa found
(II) resource ranges after xf86ClaimFixedResources() call:
	[0] -1	0	0xffe00000 - 0xffffffff (0x200000) MX[B](B)
	[1] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[2] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[3] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[4] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[5] -1	0	0xf0000000 - 0xefffffff (0x0) MX[B]O
	[6] -1	0	0xfc8f8000 - 0xfc8fbfff (0x4000) MX[B]
	[7] -1	0	0xfc8ff000 - 0xfc8ff7ff (0x800) MX[B]
	[8] -1	0	0xfc8ffc00 - 0xfc8fffff (0x400) MX[B]
	[9] -1	0	0xfc8fe000 - 0xfc8fefff (0x1000) MX[B]
	[10] -1	0	0xfc8fd000 - 0xfc8fdfff (0x1000) MX[B]
	[11] -1	0	0xfc6f0000 - 0xfc6fffff (0x10000) MX[B]
	[12] -1	0	0xfc9ff000 - 0xfc9fffff (0x1000) MX[B]
	[13] -1	0	0xfc9fe000 - 0xfc9fefff (0x1000) MX[B]
	[14] -1	0	0xfeae0000 - 0xfeafffff (0x20000) MX[B](B)
	[15] -1	0	0xec480000 - 0xec4fffff (0x80000) MX[B](B)
	[16] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[17] -1	0	0xfd000000 - 0xfdffffff (0x1000000) MX[B](B)
	[18] -1	0	0xdb800000 - 0xdbffffff (0x800000) MX[B](B)
	[19] -1	0	0xfc8f4000 - 0xfc8f7fff (0x4000) MX[B](B)
	[20] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[21] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[22] -1	0	0x0000ac00 - 0x0000ac0f (0x10) IX[B]
	[23] -1	0	0x0000b000 - 0x0000b003 (0x4) IX[B]
	[24] -1	0	0x0000b400 - 0x0000b407 (0x8) IX[B]
	[25] -1	0	0x0000b800 - 0x0000b803 (0x4) IX[B]
	[26] -1	0	0x0000bc00 - 0x0000bc07 (0x8) IX[B]
	[27] -1	0	0x0000cc00 - 0x0000cc3f (0x40) IX[B]
	[28] -1	0	0x0000c800 - 0x0000c8ff (0x100) IX[B]
	[29] -1	0	0x0000c400 - 0x0000c41f (0x20) IX[B]
	[30] -1	0	0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
(II) resource ranges after probing:
	[0] -1	0	0xffe00000 - 0xffffffff (0x200000) MX[B](B)
	[1] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[2] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[3] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[4] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[5] -1	0	0xf0000000 - 0xefffffff (0x0) MX[B]O
	[6] -1	0	0xfc8f8000 - 0xfc8fbfff (0x4000) MX[B]
	[7] -1	0	0xfc8ff000 - 0xfc8ff7ff (0x800) MX[B]
	[8] -1	0	0xfc8ffc00 - 0xfc8fffff (0x400) MX[B]
	[9] -1	0	0xfc8fe000 - 0xfc8fefff (0x1000) MX[B]
	[10] -1	0	0xfc8fd000 - 0xfc8fdfff (0x1000) MX[B]
	[11] -1	0	0xfc6f0000 - 0xfc6fffff (0x10000) MX[B]
	[12] -1	0	0xfc9ff000 - 0xfc9fffff (0x1000) MX[B]
	[13] -1	0	0xfc9fe000 - 0xfc9fefff (0x1000) MX[B]
	[14] -1	0	0xfeae0000 - 0xfeafffff (0x20000) MX[B](B)
	[15] -1	0	0xec480000 - 0xec4fffff (0x80000) MX[B](B)
	[16] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[17] -1	0	0xfd000000 - 0xfdffffff (0x1000000) MX[B](B)
	[18] -1	0	0xdb800000 - 0xdbffffff (0x800000) MX[B](B)
	[19] -1	0	0xfc8f4000 - 0xfc8f7fff (0x4000) MX[B](B)
	[20] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B]
	[21] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B]
	[22] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B]
	[23] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[24] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[25] -1	0	0x0000ac00 - 0x0000ac0f (0x10) IX[B]
	[26] -1	0	0x0000b000 - 0x0000b003 (0x4) IX[B]
	[27] -1	0	0x0000b400 - 0x0000b407 (0x8) IX[B]
	[28] -1	0	0x0000b800 - 0x0000b803 (0x4) IX[B]
	[29] -1	0	0x0000bc00 - 0x0000bc07 (0x8) IX[B]
	[30] -1	0	0x0000cc00 - 0x0000cc3f (0x40) IX[B]
	[31] -1	0	0x0000c800 - 0x0000c8ff (0x100) IX[B]
	[32] -1	0	0x0000c400 - 0x0000c41f (0x20) IX[B]
	[33] -1	0	0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
	[34] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B]
	[35] 0	0	0x000003c0 - 0x000003df (0x20) IS[B]
(II) Setting vga for screen 0.
(II) Loading sub module "vbe"
(II) LoadModule: "vbe"
(II) Loading /pkg/x11.2/lib64/modules/libvbe.a
(II) Module vbe: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.1.0
	ABI class: X.Org Video Driver, version 0.7
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /pkg/x11.2/lib64/modules/linux/libint10.a
(II) Module int10: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	ABI class: X.Org Video Driver, version 0.7
(II) VESA(0): initializing int10
(II) VESA(0): Primary V_BIOS segment is: 0xc000
(II) VESA(0): VESA BIOS detected
(II) VESA(0): VESA VBE Version 3.0
(II) VESA(0): VESA VBE Total Mem: 131072 kB
(II) VESA(0): VESA VBE OEM: NVidia
(II) VESA(0): VESA VBE OEM Software Rev: 4.37
(II) VESA(0): VESA VBE OEM Vendor: NVidia Corporation
(II) VESA(0): VESA VBE OEM Product: NV25 Board
(II) VESA(0): VESA VBE OEM Product Rev: Chip Rev   
(**) VESA(0): Depth 24, (--) framebuffer bpp 32
(==) VESA(0): RGB weight 888
(==) VESA(0): Default visual is TrueColor
(==) VESA(0): Using gamma correction (1.0, 1.0, 1.0)
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Loading /pkg/x11.2/lib64/modules/libddc.a
(II) Module ddc: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	ABI class: X.Org Video Driver, version 0.7
(II) VESA(0): VESA VBE DDC supported
(II) VESA(0): VESA VBE DDC Level 2
(II) VESA(0): VESA VBE DDC transfer in appr. 1 sec.
(II) VESA(0): VESA VBE DDC read successfully
(II) VESA(0): Manufacturer: IVM  Model: 4800  Serial#: 1001
(II) VESA(0): Year: 2002  Week: 1
(II) VESA(0): EDID Version: 1.3
(II) VESA(0): Digital Display Input
(II) VESA(0): Max H-Image Size [cm]: horiz.: 39  vert.: 29
(II) VESA(0): Gamma: 2.20
(II) VESA(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display
(II) VESA(0): First detailed timing is preferred mode
(II) VESA(0): redX: 0.619 redY: 0.340   greenX: 0.279 greenY: 0.600
(II) VESA(0): blueX: 0.140 blueY: 0.090   whiteX: 0.289 whiteY: 0.300
(II) VESA(0): Supported VESA Video Modes:
(II) VESA(0): 720x400@70Hz
(II) VESA(0): 640x480@60Hz
(II) VESA(0): 640x480@67Hz
(II) VESA(0): 640x480@72Hz
(II) VESA(0): 640x480@75Hz
(II) VESA(0): 800x600@56Hz
(II) VESA(0): 800x600@60Hz
(II) VESA(0): 800x600@72Hz
(II) VESA(0): 800x600@75Hz
(II) VESA(0): 832x624@75Hz
(II) VESA(0): 1024x768@60Hz
(II) VESA(0): 1024x768@70Hz
(II) VESA(0): 1024x768@75Hz
(II) VESA(0): 1280x1024@75Hz
(II) VESA(0): 1152x870@75Hz
(II) VESA(0): Manufacturer's mask: 0
(II) VESA(0): Supported Future Video Modes:
(II) VESA(0): #0: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
(II) VESA(0): #1: hsize: 1024  vsize 819  refresh: 85  vid: 39265
(II) VESA(0): #2: hsize: 800  vsize 640  refresh: 85  vid: 39237
(II) VESA(0): #3: hsize: 640  vsize 512  refresh: 85  vid: 39217
(II) VESA(0): Supported additional Video Mode:
(II) VESA(0): clock: 65.0 MHz   Image Size:  386 x 290 mm
(II) VESA(0): h_active: 1024  h_sync: 1040  h_sync_end 1104 h_blank_end 1344 h_border: 0
(II) VESA(0): v_active: 768  v_sync: 781  v_sync_end 783 v_blanking: 817 v_border: 0
(II) VESA(0): Supported additional Video Mode:
(II) VESA(0): clock: 162.0 MHz   Image Size:  386 x 290 mm
(II) VESA(0): h_active: 1600  h_sync: 1664  h_sync_end 1856 h_blank_end 2160 h_border: 0
(II) VESA(0): v_active: 1200  v_sync: 1201  v_sync_end 1204 v_blanking: 1250 v_border: 0
(II) VESA(0): Ranges: V min: 56  V max: 85 Hz, H min: 30  H max: 80 kHz, PixClock max 170 MHz
(II) VESA(0): Monitor name: iiyama
(II) VESA(0): Searching for matching VESA mode(s):
Mode: 100 (640x400)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 640
	XResolution: 640
	YResolution: 400
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 8
	NumberOfBanks: 1
	MemoryModel: 4
	BankSize: 0
	NumberOfImages: 14
	RedMaskSize: 0
	RedFieldPosition: 0
	GreenMaskSize: 0
	GreenFieldPosition: 0
	BlueMaskSize: 0
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 640
	BnkNumberOfImagePages: 14
	LinNumberOfImagePages: 14
	LinRedMaskSize: 0
	LinRedFieldPosition: 0
	LinGreenMaskSize: 0
	LinGreenFieldPosition: 0
	LinBlueMaskSize: 0
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
Mode: 101 (640x480)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 640
	XResolution: 640
	YResolution: 480
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 8
	NumberOfBanks: 1
	MemoryModel: 4
	BankSize: 0
	NumberOfImages: 10
	RedMaskSize: 0
	RedFieldPosition: 0
	GreenMaskSize: 0
	GreenFieldPosition: 0
	BlueMaskSize: 0
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 640
	BnkNumberOfImagePages: 10
	LinNumberOfImagePages: 10
	LinRedMaskSize: 0
	LinRedFieldPosition: 0
	LinGreenMaskSize: 0
	LinGreenFieldPosition: 0
	LinBlueMaskSize: 0
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
Mode: 102 (800x600)
	ModeAttributes: 0x31f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 100
	XResolution: 800
	YResolution: 600
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 4
	BitsPerPixel: 4
	NumberOfBanks: 1
	MemoryModel: 3
	BankSize: 0
	NumberOfImages: 14
	RedMaskSize: 0
	RedFieldPosition: 0
	GreenMaskSize: 0
	GreenFieldPosition: 0
	BlueMaskSize: 0
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0x0
	LinBytesPerScanLine: 100
	BnkNumberOfImagePages: 14
	LinNumberOfImagePages: 14
	LinRedMaskSize: 0
	LinRedFieldPosition: 0
	LinGreenMaskSize: 0
	LinGreenFieldPosition: 0
	LinBlueMaskSize: 0
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 108500000
Mode: 103 (800x600)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 800
	XResolution: 800
	YResolution: 600
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 8
	NumberOfBanks: 1
	MemoryModel: 4
	BankSize: 0
	NumberOfImages: 6
	RedMaskSize: 0
	RedFieldPosition: 0
	GreenMaskSize: 0
	GreenFieldPosition: 0
	BlueMaskSize: 0
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 800
	BnkNumberOfImagePages: 6
	LinNumberOfImagePages: 6
	LinRedMaskSize: 0
	LinRedFieldPosition: 0
	LinGreenMaskSize: 0
	LinGreenFieldPosition: 0
	LinBlueMaskSize: 0
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
Mode: 10e (320x200)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 640
	XResolution: 320
	YResolution: 200
	XCharSize: 8
	YCharSize: 8
	NumberOfPlanes: 1
	BitsPerPixel: 16
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 30
	RedMaskSize: 5
	RedFieldPosition: 11
	GreenMaskSize: 6
	GreenFieldPosition: 5
	BlueMaskSize: 5
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 640
	BnkNumberOfImagePages: 30
	LinNumberOfImagePages: 30
	LinRedMaskSize: 5
	LinRedFieldPosition: 11
	LinGreenMaskSize: 6
	LinGreenFieldPosition: 5
	LinBlueMaskSize: 5
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
*Mode: 10f (320x200)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 1280
	XResolution: 320
	YResolution: 200
	XCharSize: 8
	YCharSize: 8
	NumberOfPlanes: 1
	BitsPerPixel: 32
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 14
	RedMaskSize: 8
	RedFieldPosition: 16
	GreenMaskSize: 8
	GreenFieldPosition: 8
	BlueMaskSize: 8
	BlueFieldPosition: 0
	RsvdMaskSize: 8
	RsvdFieldPosition: 24
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 1280
	BnkNumberOfImagePages: 14
	LinNumberOfImagePages: 14
	LinRedMaskSize: 8
	LinRedFieldPosition: 16
	LinGreenMaskSize: 8
	LinGreenFieldPosition: 8
	LinBlueMaskSize: 8
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 8
	LinRsvdFieldPosition: 24
	MaxPixelClock: 229500000
Mode: 111 (640x480)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 1280
	XResolution: 640
	YResolution: 480
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 16
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 4
	RedMaskSize: 5
	RedFieldPosition: 11
	GreenMaskSize: 6
	GreenFieldPosition: 5
	BlueMaskSize: 5
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 1280
	BnkNumberOfImagePages: 4
	LinNumberOfImagePages: 4
	LinRedMaskSize: 5
	LinRedFieldPosition: 11
	LinGreenMaskSize: 6
	LinGreenFieldPosition: 5
	LinBlueMaskSize: 5
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
*Mode: 112 (640x480)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 2560
	XResolution: 640
	YResolution: 480
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 32
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 1
	RedMaskSize: 8
	RedFieldPosition: 16
	GreenMaskSize: 8
	GreenFieldPosition: 8
	BlueMaskSize: 8
	BlueFieldPosition: 0
	RsvdMaskSize: 8
	RsvdFieldPosition: 24
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 2560
	BnkNumberOfImagePages: 1
	LinNumberOfImagePages: 1
	LinRedMaskSize: 8
	LinRedFieldPosition: 16
	LinGreenMaskSize: 8
	LinGreenFieldPosition: 8
	LinBlueMaskSize: 8
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 8
	LinRsvdFieldPosition: 24
	MaxPixelClock: 229500000
Mode: 114 (800x600)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 1600
	XResolution: 800
	YResolution: 600
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 16
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 2
	RedMaskSize: 5
	RedFieldPosition: 11
	GreenMaskSize: 6
	GreenFieldPosition: 5
	BlueMaskSize: 5
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 1600
	BnkNumberOfImagePages: 2
	LinNumberOfImagePages: 2
	LinRedMaskSize: 5
	LinRedFieldPosition: 11
	LinGreenMaskSize: 6
	LinGreenFieldPosition: 5
	LinBlueMaskSize: 5
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
*Mode: 115 (800x600)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 3200
	XResolution: 800
	YResolution: 600
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 32
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 1
	RedMaskSize: 8
	RedFieldPosition: 16
	GreenMaskSize: 8
	GreenFieldPosition: 8
	BlueMaskSize: 8
	BlueFieldPosition: 0
	RsvdMaskSize: 8
	RsvdFieldPosition: 24
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 3200
	BnkNumberOfImagePages: 1
	LinNumberOfImagePages: 1
	LinRedMaskSize: 8
	LinRedFieldPosition: 16
	LinGreenMaskSize: 8
	LinGreenFieldPosition: 8
	LinBlueMaskSize: 8
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 8
	LinRsvdFieldPosition: 24
	MaxPixelClock: 229500000
Mode: 130 (320x200)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 320
	XResolution: 320
	YResolution: 200
	XCharSize: 8
	YCharSize: 8
	NumberOfPlanes: 1
	BitsPerPixel: 8
	NumberOfBanks: 1
	MemoryModel: 4
	BankSize: 0
	NumberOfImages: 62
	RedMaskSize: 0
	RedFieldPosition: 0
	GreenMaskSize: 0
	GreenFieldPosition: 0
	BlueMaskSize: 0
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 320
	BnkNumberOfImagePages: 62
	LinNumberOfImagePages: 62
	LinRedMaskSize: 0
	LinRedFieldPosition: 0
	LinGreenMaskSize: 0
	LinGreenFieldPosition: 0
	LinBlueMaskSize: 0
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
Mode: 131 (320x400)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 320
	XResolution: 320
	YResolution: 400
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 8
	NumberOfBanks: 1
	MemoryModel: 4
	BankSize: 0
	NumberOfImages: 30
	RedMaskSize: 0
	RedFieldPosition: 0
	GreenMaskSize: 0
	GreenFieldPosition: 0
	BlueMaskSize: 0
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 320
	BnkNumberOfImagePages: 30
	LinNumberOfImagePages: 30
	LinRedMaskSize: 0
	LinRedFieldPosition: 0
	LinGreenMaskSize: 0
	LinGreenFieldPosition: 0
	LinBlueMaskSize: 0
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
Mode: 132 (320x400)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 640
	XResolution: 320
	YResolution: 400
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 16
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 14
	RedMaskSize: 5
	RedFieldPosition: 11
	GreenMaskSize: 6
	GreenFieldPosition: 5
	BlueMaskSize: 5
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 640
	BnkNumberOfImagePages: 14
	LinNumberOfImagePages: 14
	LinRedMaskSize: 5
	LinRedFieldPosition: 11
	LinGreenMaskSize: 6
	LinGreenFieldPosition: 5
	LinBlueMaskSize: 5
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
*Mode: 133 (320x400)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 1280
	XResolution: 320
	YResolution: 400
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 32
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 6
	RedMaskSize: 8
	RedFieldPosition: 16
	GreenMaskSize: 8
	GreenFieldPosition: 8
	BlueMaskSize: 8
	BlueFieldPosition: 0
	RsvdMaskSize: 8
	RsvdFieldPosition: 24
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 1280
	BnkNumberOfImagePages: 6
	LinNumberOfImagePages: 6
	LinRedMaskSize: 8
	LinRedFieldPosition: 16
	LinGreenMaskSize: 8
	LinGreenFieldPosition: 8
	LinBlueMaskSize: 8
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 8
	LinRsvdFieldPosition: 24
	MaxPixelClock: 229500000
Mode: 134 (320x240)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 320
	XResolution: 320
	YResolution: 240
	XCharSize: 8
	YCharSize: 8
	NumberOfPlanes: 1
	BitsPerPixel: 8
	NumberOfBanks: 1
	MemoryModel: 4
	BankSize: 0
	NumberOfImages: 30
	RedMaskSize: 0
	RedFieldPosition: 0
	GreenMaskSize: 0
	GreenFieldPosition: 0
	BlueMaskSize: 0
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 320
	BnkNumberOfImagePages: 30
	LinNumberOfImagePages: 30
	LinRedMaskSize: 0
	LinRedFieldPosition: 0
	LinGreenMaskSize: 0
	LinGreenFieldPosition: 0
	LinBlueMaskSize: 0
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
Mode: 135 (320x240)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 640
	XResolution: 320
	YResolution: 240
	XCharSize: 8
	YCharSize: 8
	NumberOfPlanes: 1
	BitsPerPixel: 16
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 19
	RedMaskSize: 5
	RedFieldPosition: 11
	GreenMaskSize: 6
	GreenFieldPosition: 5
	BlueMaskSize: 5
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 640
	BnkNumberOfImagePages: 19
	LinNumberOfImagePages: 19
	LinRedMaskSize: 5
	LinRedFieldPosition: 11
	LinGreenMaskSize: 6
	LinGreenFieldPosition: 5
	LinBlueMaskSize: 5
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
*Mode: 136 (320x240)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 1280
	XResolution: 320
	YResolution: 240
	XCharSize: 8
	YCharSize: 8
	NumberOfPlanes: 1
	BitsPerPixel: 32
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 10
	RedMaskSize: 8
	RedFieldPosition: 16
	GreenMaskSize: 8
	GreenFieldPosition: 8
	BlueMaskSize: 8
	BlueFieldPosition: 0
	RsvdMaskSize: 8
	RsvdFieldPosition: 24
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 1280
	BnkNumberOfImagePages: 10
	LinNumberOfImagePages: 10
	LinRedMaskSize: 8
	LinRedFieldPosition: 16
	LinGreenMaskSize: 8
	LinGreenFieldPosition: 8
	LinBlueMaskSize: 8
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 8
	LinRsvdFieldPosition: 24
	MaxPixelClock: 229500000
Mode: 13d (640x400)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 1280
	XResolution: 640
	YResolution: 400
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 16
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 6
	RedMaskSize: 5
	RedFieldPosition: 11
	GreenMaskSize: 6
	GreenFieldPosition: 5
	BlueMaskSize: 5
	BlueFieldPosition: 0
	RsvdMaskSize: 0
	RsvdFieldPosition: 0
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 1280
	BnkNumberOfImagePages: 6
	LinNumberOfImagePages: 6
	LinRedMaskSize: 5
	LinRedFieldPosition: 11
	LinGreenMaskSize: 6
	LinGreenFieldPosition: 5
	LinBlueMaskSize: 5
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 0
	LinRsvdFieldPosition: 0
	MaxPixelClock: 229500000
*Mode: 13e (640x400)
	ModeAttributes: 0x39f
	WinAAttributes: 0x7
	WinBAttributes: 0x0
	WinGranularity: 64
	WinSize: 64
	WinASegment: 0xa000
	WinBSegment: 0x0
	WinFuncPtr: 0xc000a455
	BytesPerScanline: 2560
	XResolution: 640
	YResolution: 400
	XCharSize: 8
	YCharSize: 16
	NumberOfPlanes: 1
	BitsPerPixel: 32
	NumberOfBanks: 1
	MemoryModel: 6
	BankSize: 0
	NumberOfImages: 2
	RedMaskSize: 8
	RedFieldPosition: 16
	GreenMaskSize: 8
	GreenFieldPosition: 8
	BlueMaskSize: 8
	BlueFieldPosition: 0
	RsvdMaskSize: 8
	RsvdFieldPosition: 24
	DirectColorModeInfo: 0
	PhysBasePtr: 0xe0000000
	LinBytesPerScanLine: 2560
	BnkNumberOfImagePages: 2
	LinNumberOfImagePages: 2
	LinRedMaskSize: 8
	LinRedFieldPosition: 16
	LinGreenMaskSize: 8
	LinGreenFieldPosition: 8
	LinBlueMaskSize: 8
	LinBlueFieldPosition: 0
	LinRsvdMaskSize: 8
	LinRsvdFieldPosition: 24
	MaxPixelClock: 229500000

(II) VESA(0): Total Memory: 2048 64KB banks (131072kB)
(II) VESA(0): Monitor0: Using default hsync range of 30.00-80.00 kHz
(II) VESA(0): Monitor0: Using default vrefresh range of 56.00-85.00 Hz
(--) VESA(0): Virtual size is 800x600 (pitch 800)
(**) VESA(0): *Built-in mode "800x600"
(**) VESA(0): *Built-in mode "640x480"
(**) VESA(0): *Built-in mode "640x400"
(--) VESA(0): Display dimensions: (390, 290) mm
(--) VESA(0): DPI set to (52, 52)
(II) VESA(0): Attempting to use 85Hz refresh for mode "800x600" (115)
(II) VESA(0): Attempting to use 85Hz refresh for mode "640x480" (112)
(II) VESA(0): Attempting to use 85Hz refresh for mode "640x400" (13e)
(**) VESA(0): Using "Shadow Framebuffer"
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /pkg/x11.2/lib64/modules/libshadow.a
(II) Module shadow: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	ABI class: X.Org ANSI C Emulation, version 0.2
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /pkg/x11.2/lib64/modules/libfb.a
(II) Module fb: vendor="X.Org Foundation"
	compiled for 6.8.0, module version = 1.0.0
	ABI class: X.Org ANSI C Emulation, version 0.2
(--) Depth 24 pixmap format is 32 bpp
(II) do I need RAC?  No, I don't.
(II) resource ranges after preInit:
	[0] -1	0	0xffe00000 - 0xffffffff (0x200000) MX[B](B)
	[1] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[2] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[3] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[4] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[5] -1	0	0xf0000000 - 0xefffffff (0x0) MX[B]O
	[6] -1	0	0xfc8f8000 - 0xfc8fbfff (0x4000) MX[B]
	[7] -1	0	0xfc8ff000 - 0xfc8ff7ff (0x800) MX[B]
	[8] -1	0	0xfc8ffc00 - 0xfc8fffff (0x400) MX[B]
	[9] -1	0	0xfc8fe000 - 0xfc8fefff (0x1000) MX[B]
	[10] -1	0	0xfc8fd000 - 0xfc8fdfff (0x1000) MX[B]
	[11] -1	0	0xfc6f0000 - 0xfc6fffff (0x10000) MX[B]
	[12] -1	0	0xfc9ff000 - 0xfc9fffff (0x1000) MX[B]
	[13] -1	0	0xfc9fe000 - 0xfc9fefff (0x1000) MX[B]
	[14] -1	0	0xfeae0000 - 0xfeafffff (0x20000) MX[B](B)
	[15] -1	0	0xec480000 - 0xec4fffff (0x80000) MX[B](B)
	[16] -1	0	0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B)
	[17] -1	0	0xfd000000 - 0xfdffffff (0x1000000) MX[B](B)
	[18] -1	0	0xdb800000 - 0xdbffffff (0x800000) MX[B](B)
	[19] -1	0	0xfc8f4000 - 0xfc8f7fff (0x4000) MX[B](B)
	[20] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B]
	[21] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B]
	[22] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B]
	[23] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[24] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[25] -1	0	0x0000ac00 - 0x0000ac0f (0x10) IX[B]
	[26] -1	0	0x0000b000 - 0x0000b003 (0x4) IX[B]
	[27] -1	0	0x0000b400 - 0x0000b407 (0x8) IX[B]
	[28] -1	0	0x0000b800 - 0x0000b803 (0x4) IX[B]
	[29] -1	0	0x0000bc00 - 0x0000bc07 (0x8) IX[B]
	[30] -1	0	0x0000cc00 - 0x0000cc3f (0x40) IX[B]
	[31] -1	0	0x0000c800 - 0x0000c8ff (0x100) IX[B]
	[32] -1	0	0x0000c400 - 0x0000c41f (0x20) IX[B]
	[33] -1	0	0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
	[34] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B]
	[35] 0	0	0x000003c0 - 0x000003df (0x20) IS[B]
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /pkg/x11.2/lib64/modules/linux/libint10.a
(II) VESA(0): initializing int10
(II) VESA(0): Primary V_BIOS segment is: 0xc000
(II) VESA(0): VESA BIOS detected
(II) VESA(0): VESA VBE Version 3.0
(II) VESA(0): VESA VBE Total Mem: 131072 kB
(II) VESA(0): VESA VBE OEM: NVidia
(II) VESA(0): VESA VBE OEM Software Rev: 4.37
(II) VESA(0): VESA VBE OEM Vendor: NVidia Corporation
(II) VESA(0): VESA VBE OEM Product: NV25 Board
(II) VESA(0): VESA VBE OEM Product Rev: Chip Rev   
(==) VESA(0): Write-combining range (0xe0000000,0x8000000)
(II) VESA(0): virtual address = 0x2a95c7d000,
	physical address = 0xe0000000, size = 134217728
(==) VESA(0): Default visual is TrueColor
(==) VESA(0): Backing store disabled
(**) Option "dpms"
(**) VESA(0): DPMS enabled
(==) RandR enabled
(II) Setting vga for screen 0.
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension LBX
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
(**) Option "Protocol" "auto"
(**) Mouse0: Device: "/dev/input/mouse0"
(**) Mouse0: Protocol: "auto"
(**) Option "CorePointer"
(**) Mouse0: Core Pointer
(**) Option "Device" "/dev/input/mouse0"
(==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50
(==) Mouse0: Buttons: 3
(**) Option "CoreKeyboard"
(**) Keyboard0: Core Keyboard
(**) Option "Protocol" "standard"
(**) Keyboard0: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) Keyboard0: XkbRules: "xorg"
(**) Option "XkbModel" "pc101"
(**) Keyboard0: XkbModel: "pc101"
(**) Option "XkbLayout" "gb"
(**) Keyboard0: XkbLayout: "gb"
(**) Option "CustomKeycodes" "off"
(**) Keyboard0: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)
(II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
(--) Mouse0: PnP-detected protocol: "ExplorerPS/2"
(II) Mouse0: ps2EnableDataReporting: succeeded
Could not init font path element /pkg/x11.2/lib/X11/fonts/TTF/, removing from list!
Could not init font path element /pkg/x11.2/lib/X11/fonts/Type1/, removing from list!
Could not init font path element /pkg/x11.2/lib/X11/fonts/CID/, removing from list!
SetClientVersion: 0 8

Re: Rivafb won't work with DVI connector

[Michel Dänzer]

On Sat, 2004-11-27 at 12:40 +0000, Andrew Walrond wrote:
> 
> So, not only is this not going to work, but the vesa driver also seems broken 
> when used with dvi.

s/vesa driver/on-card video BIOS/


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Saturday 27 Nov 2004 18:29, Michel Dänzer wrote:
> On Sat, 2004-11-27 at 12:40 +0000, Andrew Walrond wrote:
> > So, not only is this not going to work, but the vesa driver also seems
> > broken when used with dvi.
>
> s/vesa driver/on-card video BIOS/

Quite probably :)


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

On Saturday 27 November 2004 20:40, Andrew Walrond wrote:
> On Friday 26 Nov 2004 14:09, Antonino A. Daplas wrote:
> > On Thursday 25 November 2004 23:27, Andrew Walrond wrote:
> > > On Thursday 25 Nov 2004 00:07, Antonino A. Daplas wrote:
>
> none which are useful. Trying some of the modes from the DSUB log (ie 145 =
> vga=0x345 etc ) results always in (from memory) "Unsupported mode supplied;
> hit enter for list for wait 30s to continue" during boot. As I said, scan
> only finds text modes.
>
> So, not only is this not going to work, but the vesa driver also seems
> broken when used with dvi.

It's the BIOS that's broken.

If we can't even rely on the BIOS to set up an acceptable mode, I guess this
problem is for nVidia (if they're going to release the info).

Tony 




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Rivafb won't work with DVI connector

[Andrew Walrond]

I have a TFT LCD screen (1600x1200) with both D-Sub and DVI inputs, and a NV25 
[GeForce4 Ti 4600] with same outputs.

Using the old D-Sub cable works fine:

 rivafb: nVidia device/chipset 10DE0250
 rivafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
 rivafb: Detected CRTC controller 0 being used
 rivafb: RIVA MTRR set to ON
 rivafb: Found EDID Block from BUS 2
 rivafb: setting virtual Y resolution to 83886
 Console: switching to colour frame buffer device 200x75
 rivafb: PCI nVidia NV25 framebuffer ver 0.9.5b (128MB @ 0xE0000000)

but with the DVI cable (dsub disconnected) I get a blank screen as soon as 
rivafb takes over:

 rivafb: nVidia device/chipset 10DE0250
 rivafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
 rivafb: Detected CRTC controller 0 being used
 rivafb: RIVA MTRR set to ON
 rivafb: Found EDID Block from BUS 3
 EDID checksum failed, aborting
 rivafb: setting virtual Y resolution to 209715
 Console: switching to colour frame buffer device 80x30
 rivafb: PCI nVidia NV25 framebuffer ver 0.9.5b (128MB @ 0xE0000000)

I then have to plug the d-sub back in to see the output.
[side note: 2.6.8.1 shows only garbage on reconnecting dsub, so rc2 is an 
improvement.]

No I don't understand the lingo here, but I assume EDID/BUS2/BUS3 and the 
checksum failure are the bits I'm interested in here.

I'm willing to do the grunt work to get this fixed, but can you guys give me a 
heads up on how this stuff works, and what might be involved in a fix?

Thanks

Andrew Walrond


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

On Friday 19 November 2004 19:37, Andrew Walrond wrote:
> I have a TFT LCD screen (1600x1200) with both D-Sub and DVI inputs, and a
> NV25 [GeForce4 Ti 4600] with same outputs.
>
> Using the old D-Sub cable works fine:
>
>  rivafb: nVidia device/chipset 10DE0250
>  rivafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
>  rivafb: Detected CRTC controller 0 being used
>  rivafb: RIVA MTRR set to ON
>  rivafb: Found EDID Block from BUS 2
>  rivafb: setting virtual Y resolution to 83886
>  Console: switching to colour frame buffer device 200x75
>  rivafb: PCI nVidia NV25 framebuffer ver 0.9.5b (128MB @ 0xE0000000)
>
> but with the DVI cable (dsub disconnected) I get a blank screen as soon as
> rivafb takes over:
>
>  rivafb: nVidia device/chipset 10DE0250
>  rivafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
>  rivafb: Detected CRTC controller 0 being used
>  rivafb: RIVA MTRR set to ON
>  rivafb: Found EDID Block from BUS 3
>  EDID checksum failed, aborting
>  rivafb: setting virtual Y resolution to 209715
>  Console: switching to colour frame buffer device 80x30
>  rivafb: PCI nVidia NV25 framebuffer ver 0.9.5b (128MB @ 0xE0000000)
>
> I then have to plug the d-sub back in to see the output.
> [side note: 2.6.8.1 shows only garbage on reconnecting dsub, so rc2 is an
> improvement.]
>
> No I don't understand the lingo here, but I assume EDID/BUS2/BUS3 and the
> checksum failure are the bits I'm interested in here.

You can try the following:

1. turn on verbose debug output in drivers/video/fbmon.c

2. Try just grabbing the EDID from BUS2, since the EDID checksum failed from
BUS3.

3. if you can, send me your EDID block.  You can use the utility 'read-edid'. 

Tony




-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

[-- Attachment #1: Type: text/plain, Size: 3686 bytes --]

On Friday 19 Nov 2004 22:08, Antonino A. Daplas wrote:
> On Friday 19 November 2004 19:37, Andrew Walrond wrote:
> > I have a TFT LCD screen (1600x1200) with both D-Sub and DVI inputs, and a
> > NV25 [GeForce4 Ti 4600] with same outputs.
> >
> > Using the old D-Sub cable works fine:
> >
> >  rivafb: nVidia device/chipset 10DE0250
> >  rivafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
> >  rivafb: Detected CRTC controller 0 being used
> >  rivafb: RIVA MTRR set to ON
> >  rivafb: Found EDID Block from BUS 2
> >  rivafb: setting virtual Y resolution to 83886
> >  Console: switching to colour frame buffer device 200x75
> >  rivafb: PCI nVidia NV25 framebuffer ver 0.9.5b (128MB @ 0xE0000000)
> >
> > but with the DVI cable (dsub disconnected) I get a blank screen as soon
> > as rivafb takes over:
> >
> >  rivafb: nVidia device/chipset 10DE0250
> >  rivafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
> >  rivafb: Detected CRTC controller 0 being used
> >  rivafb: RIVA MTRR set to ON
> >  rivafb: Found EDID Block from BUS 3
> >  EDID checksum failed, aborting
> >  rivafb: setting virtual Y resolution to 209715
> >  Console: switching to colour frame buffer device 80x30
> >  rivafb: PCI nVidia NV25 framebuffer ver 0.9.5b (128MB @ 0xE0000000)
> >
> > I then have to plug the d-sub back in to see the output.
> > [side note: 2.6.8.1 shows only garbage on reconnecting dsub, so rc2 is an
> > improvement.]
> >
> > No I don't understand the lingo here, but I assume EDID/BUS2/BUS3 and the
> > checksum failure are the bits I'm interested in here.
>
> You can try the following:
>
> 1. turn on verbose debug output in drivers/video/fbmon.c

Done; but nothing gets displayed when checksum fails. Displays lots of nice 
stuff with dsub connection though :)
>
> 2. Try just grabbing the EDID from BUS2, since the EDID checksum failed
> from BUS3.

Ok - I modified riva_get_EDID_i2c to probe only BUS 2, but the checksum still 
fails unless the dsub is (also) connected. Infact, I hard coded each bus, 1-3 
in turn. With just DVI connected, the returned EDID failed the checksum for 
all three buses. With the Dsub connected, I got valid EDID's on BUS 1 and 2, 
and a message saying none was available on BUS 3.

I cannot get a DVI display, whatever I try. I have also tried various 
combinations of video:rivafb:forceCRTC=0/1 and video:rivafb:flatpanel, all to 
no effect (flatpanel gives me a corrupt dsub display)

>
> 3. if you can, send me your EDID block.  You can use the utility
> 'read-edid'.

EDID attached. Parsed output:

./read-edid-1.4.1/parse-edid: parse-edid version 1.4.1
./read-edid-1.4.1/parse-edid: EDID checksum passed.

        # EDID version 1 revision 3
Section "Monitor"
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
        Identifier "iiyama "
        VendorName "IVM"
        ModelName "iiyama "
        # Block type: 2:0 3:fd
        HorizSync 30-80
        VertRefresh 56-85
        # Max dot clock (video bandwidth) 170 MHz
        # Block type: 2:0 3:fc
        # DPMS capabilities: Active off:yes  Suspend:yes  Standby:yes

        Mode    "1024x768"      # vfreq 59.196Hz, hfreq 48.363kHz
                DotClock        65.000000
                HTimings        1024 1040 1104 1344
                VTimings        768 781 783 817
                Flags   "-HSync" "-VSync"
        EndMode
        Mode    "1600x1200"     # vfreq 60.000Hz, hfreq 75.000kHz
                DotClock        162.000000
                HTimings        1600 1664 1856 2160
                VTimings        1200 1201 1204 1250
                Flags   "+HSync" "+VSync"
        EndMode
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
EndSection

[-- Attachment #2: edid.dsub.32 --]
[-- Type: application/octet-stream, Size: 128 bytes --]

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

On Saturday 20 November 2004 23:52, Andrew Walrond wrote:
> On Friday 19 Nov 2004 22:08, Antonino A. Daplas wrote:
> > On Friday 19 November 2004 19:37, Andrew Walrond wrote:
> > > I have a TFT LCD screen (1600x1200) with both D-Sub and DVI inputs, and
> > > a NV25 [GeForce4 Ti 4600] with same outputs.

Can you try this driver rewrite for nVidia chipsets? I'm planning to add
this driver because it's getting harder and harder to support newer chipsets with
the old code.

- based on the most recent Xorg nv driver
- supports console acceleration via DMA instead of PIO
- should support all chipsets supported by rivafb except for 
  Riva128 (NV_ARCH_03) and in theory should also support
  NV_ARCH_30 and NV_ARCH_40 chipsets. I've already added
  a few pci_ids for these newer chipsets.

The reference file that I based the driver on seems to have better DVI
support, so hopefully this works.

You have to disable rivafb in your kernel config.  The module name is
nvidiafb and boot options are very similar to rivafb:

video=nvidiafb:<your options>

This is a preliminary patch, but it should be almost as functional as rivafb.

Tony 

 drivers/video/Kconfig             |    7
 drivers/video/Makefile            |    4
 drivers/video/nvidia/Makefile     |   11
 drivers/video/nvidia/nv_accel.c   |  342 ++++++++
 drivers/video/nvidia/nv_dma.h     |  180 ++++
 drivers/video/nvidia/nv_local.h   |   91 ++
 drivers/video/nvidia/nv_proto.h   |   59 +
 drivers/video/nvidia/nv_setup.c   |  626 +++++++++++++++
 drivers/video/nvidia/nv_type.h    |  171 ++++
 drivers/video/nvidia/nvidia-i2c.c |  229 +++++
 drivers/video/nvidia/nvidia.c     | 1221 ++++++++++++++++++++++++++++++
 drivers/video/nvidia/nvidia_hw.c  | 1509 ++++++++++++++++++++++++++++++++++++++
 include/linux/pci_ids.h           |   49 +


[-- Attachment #2: nvidiafb.diff.gz --]
[-- Type: application/x-gzip, Size: 30961 bytes --]

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Monday 22 Nov 2004 00:11, Antonino A. Daplas wrote:
> On Saturday 20 November 2004 23:52, Andrew Walrond wrote:
> > On Friday 19 Nov 2004 22:08, Antonino A. Daplas wrote:
> > > On Friday 19 November 2004 19:37, Andrew Walrond wrote:
> > > > I have a TFT LCD screen (1600x1200) with both D-Sub and DVI inputs,
> > > > and a NV25 [GeForce4 Ti 4600] with same outputs.
>
> Can you try this driver rewrite for nVidia chipsets? I'm planning to add
> this driver because it's getting harder and harder to support newer
> chipsets with the old code.
>
> - based on the most recent Xorg nv driver
> - supports console acceleration via DMA instead of PIO
> - should support all chipsets supported by rivafb except for
>   Riva128 (NV_ARCH_03) and in theory should also support
>   NV_ARCH_30 and NV_ARCH_40 chipsets. I've already added
>   a few pci_ids for these newer chipsets.
>
> The reference file that I based the driver on seems to have better DVI
> support, so hopefully this works.
>
> You have to disable rivafb in your kernel config.  The module name is
> nvidiafb and boot options are very similar to rivafb:
>
> video=nvidiafb:<your options>
>
> This is a preliminary patch, but it should be almost as functional as
> rivafb.
>

Hi Tony,

Some results. I both cases I booted with
 video=nvidia:1600x1200-16@60
on an Iiuama AU4831D 1600x1200 TFT LCD with both dsub and dvi connectors.

Using the dsub connector, everything works fine. From dmesg:

 nvidiafb: nVidia device/chipset 10DE0250
 nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
   ...can't find one
   ...found one
 nvidiafb: CRTC 0appears to have a CRT attached
 nvidiafb: Using CRT on CRTC 0
 nvidiafb: MTRR set to ON
 Console: switching to colour frame buffer device 200x75
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)

Using the dvi connector, I get lovely shade of green filling the whole screen. 
Dmesg is interesting:

 nvidiafb: nVidia device/chipset 10DE0250
 nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
   ...can't find one
   ...can't find one
 nvidiafb: CRTC 1 is currently programmed for DFP
 nvidiafb: Using DFP on CRTC 1
 Panel size is 1024 x 768
 nvidiafb: MTRR set to ON
 warning: many lost ticks.
 Your time source seems to be instable or some driver is hogging interupts
 rip default_idle+0x20/0x30
 Console: switching to colour frame buffer device 200x75
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)

Notice in particular
 - "some driver hogging interrupts"
 - "Panel size is 1024x768" (should be 1600x1200)

I'll try to boot on dvi without and module parameters and report back shortly.

Anything else I can do to help, let me know.

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Monday 22 Nov 2004 09:23, Andrew Walrond wrote:
>
> I'll try to boot on dvi without and module parameters and report back
> shortly.
>

Ok, some progress. Booting without any module parameters on dvi connector gets 
me what is probably a 1024x768 display on my 1600x1200 tft screen. However, 
the console text is shifted right a bit less than half a screen width such 
that the right hand of the display appears wrapped on the left. There also 
seem to be two cursors, seperated by about two character widths. (Note these 
are not artifacts of the screen, which handles 1024x768 just fine under 
normal circumstances, either with a large border, or scaled to fit the whole 
screen)

Dmesg:

 nvidiafb: nVidia device/chipset 10DE0250
 nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
   ...can't find one
   ...can't find one
 nvidiafb: CRTC 1 is currently programmed for DFP
 nvidiafb: Using DFP on CRTC 1
 Panel size is 1024 x 768
 nvidiafb: MTRR set to ON
 Console: switching to colour frame buffer device 80x30
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)

But hell, at least I am seeing some stuff through the dvi !

Anything I can do, let me know.

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On Monday 22 November 2004 17:43, Andrew Walrond wrote:
> On Monday 22 Nov 2004 09:23, Andrew Walrond wrote:
> > I'll try to boot on dvi without and module parameters and report back
> > shortly.
>
> Ok, some progress. Booting without any module parameters on dvi connector
> gets me what is probably a 1024x768 display on my 1600x1200 tft screen.
> However, the console text is shifted right a bit less than half a screen
> width such that the right hand of the display appears wrapped on the left.
> There also seem to be two cursors, seperated by about two character widths.
> (Note these are not artifacts of the screen, which handles 1024x768 just
> fine under normal circumstances, either with a large border, or scaled to
> fit the whole screen)
>
> Dmesg:
>
>  nvidiafb: nVidia device/chipset 10DE0250
>  nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
>    ...can't find one
>    ...can't find one
>  nvidiafb: CRTC 1 is currently programmed for DFP
>  nvidiafb: Using DFP on CRTC 1
>  Panel size is 1024 x 768
>  nvidiafb: MTRR set to ON
>  Console: switching to colour frame buffer device 80x30
>  nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)
>
> But hell, at least I am seeing some stuff through the dvi !

That sounds like progress :-)

Try this patch (reverse the previous one first)

- update code against the latest CVS version of Xorg
- added VESA blanking support
- added backlight support for powermacs
- added hardware cursor support using option 'hwcur'.
- clean-up of i2c code

Let me know, again, of the results.  Thanks.

Tony


[-- Attachment #2: nvidiafb2.diff.gz --]
[-- Type: application/x-gzip, Size: 32894 bytes --]

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Monday 22 Nov 2004 22:13, Antonino A. Daplas wrote:
>
> Try this patch (reverse the previous one first)
>
> - update code against the latest CVS version of Xorg
> - added VESA blanking support
> - added backlight support for powermacs
> - added hardware cursor support using option 'hwcur'.
> - clean-up of i2c code
>
> Let me know, again, of the results.  Thanks.
>

Ok; getting closer. In all cases booting with DVI connection: 

Booting with no module params gives an almost working 80x30 console, but 
shifted/wrapped half a screen to the right as with the previous version.

 nvidiafb: nVidia device/chipset 10DE0250
 nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
 nvidiafb: CRTC0 not found
 nvidiafb: CRTC1 not found
 nvidiafb: CRTC 1 is currently programmed for DFP
 nvidiafb: Using DFP on CRTC 1
 Panel size is 1024 x 768
 nvidiafb: MTRR set to ON
 Console: switching to colour frame buffer device 80x30
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)

Note the erroneous panel detection; this is a 1600x1200 tft lcd. The panel is 
detected as 1024x768 in every following case.

Now, with params. If I omit the @60 refresh rate, all I get is a screen of 
dots; I can make out that there is are a couple of penguin smeared across the 
top, but thats about all. So all the following have @60 which produces a 
better display.

video=nvidia:1024x768-16@60

This produces a readable 128x48 display, but shifted about a quarter of a 
display to the right. The penguins are a bit disjointed aswell.

 nvidiafb: nVidia device/chipset 10DE0250
 nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
 nvidiafb: CRTC0 not found
 nvidiafb: CRTC1 not found
 nvidiafb: CRTC 1 is currently programmed for DFP
 nvidiafb: Using DFP on CRTC 1
 Panel size is 1024 x 768
 nvidiafb: MTRR set to ON
 Console: switching to colour frame buffer device 128x48
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)

video=nvidia:1024x768-32@60

Same results as -16, but my test programme confirms display is 32bpp.
Dmesg is identical

Interestingly, on all the shifted/wrapped displays, If I hit ctrl-L to clear 
the screen, the prompt moves back to the correct position for just that one 
top line. The next and subsequent lines are shifted right again.

video=nvidia:1280x1024-16@60
video=nvidia:1280x1024-32@60
video=nvidia:1600x1200-16@60
video=nvidia:1600x1200-32@60

All modes above 1024x768 produce the same result; a FULLY WORKING console, but 
ONLY AT 80x25. No sign of the shifting/wrapping problem though.

 nvidiafb: nVidia device/chipset 10DE0250
 nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
 nvidiafb: CRTC0 not found
 nvidiafb: CRTC1 not found
 nvidiafb: CRTC 1 is currently programmed for DFP
 nvidiafb: Using DFP on CRTC 1
 Panel size is 1024 x 768
 nvidiafb: MTRR set to ON
 Console: switching to colour frame buffer device 80x25
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)


So, the main problems as I see them are:

 - Panel is misdetected as 1024x768. Refresh rates are also likely misdetected 
since I only get gibberish unless I add @60 (although monitor doesn't report 
"out of range")

 - Displays <= 1024x768 have this shifted/wrapped to the right problem.

Getting closer though!

I'll try the dsub connection next.

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Monday 22 Nov 2004 23:47, Andrew Walrond wrote:
>
> I'll try the dsub connection next.
>

Booting with dsub connection and video=1600x1200-32@60 works perfectly.

 nvidiafb: nVidia device/chipset 10DE0250
 nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
 nvidiafb: CRTC0 not found
 nvidiafb: CRTC1 found
 nvidiafb: CRTC 0appears to have a CRT attached
 nvidiafb: Using CRT on CRTC 0
 nvidiafb: MTRR set to ON
 Console: switching to colour frame buffer device 200x75
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]

On Tuesday 23 November 2004 07:47, Andrew Walrond wrote:
> On Monday 22 Nov 2004 22:13, Antonino A. Daplas wrote:
> > Try this patch (reverse the previous one first)
> >
> > - update code against the latest CVS version of Xorg
> > - added VESA blanking support
> > - added backlight support for powermacs
> > - added hardware cursor support using option 'hwcur'.
> > - clean-up of i2c code
> >
> > Let me know, again, of the results.  Thanks.
>
> Ok; getting closer. In all cases booting with DVI connection:
>
> Booting with no module params gives an almost working 80x30 console, but
> shifted/wrapped half a screen to the right as with the previous version.
>
>  nvidiafb: nVidia device/chipset 10DE0250
>  nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
>  nvidiafb: CRTC0 not found
>  nvidiafb: CRTC1 not found
>  nvidiafb: CRTC 1 is currently programmed for DFP
>  nvidiafb: Using DFP on CRTC 1
>  Panel size is 1024 x 768
>  nvidiafb: MTRR set to ON
>  Console: switching to colour frame buffer device 80x30
>  nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)
>
> Note the erroneous panel detection; this is a 1600x1200 tft lcd. The panel
> is detected as 1024x768 in every following case.

The panel size is programmed by the BIOS, not sure what what we can do
about that.  So even if your display supports 1600x1200, you're still limited
to 1024x768.  

Perhaps, if we can combine the vesafb code so the BIOS forces it to 
1600x1200, then have nvidiafb detect and use the vesa mode, we can
get a resolution higher than 1024x768.  I'll play around with this, and I'll
give you a test patch later.
 
>
> Now, with params. If I omit the @60 refresh rate, all I get is a screen of
> dots; I can make out that there is are a couple of penguin smeared across
> the top, but thats about all. So all the following have @60 which produces
> a better display.
>
> video=nvidia:1024x768-16@60

It seems that EDID block is not detected whether digital or analog. I think
I missed a Kconfig changeset. Should be fixed with the included patch.
 
Select y to FB_NVIDIA_I2C.
 
>  - Panel is misdetected as 1024x768. Refresh rates are also likely
> misdetected since I only get gibberish unless I add @60 (although monitor
> doesn't report "out of range")
>
>  - Displays <= 1024x768 have this shifted/wrapped to the right problem.

Most probably the 1024x768@60 entry in the mode database is wreaking
havoc to the timings.  Let's use the VESA standard 1024x768-60 timing.

Try the attached patch.  It's an incremental patch so apply it on top of
nvidiafb2.diff

Tony

[-- Attachment #2: nvidiafb2-inc.diff --]
[-- Type: text/x-diff, Size: 1929 bytes --]

diff -Nru a/drivers/video/Kconfig b/drivers/video/Kconfig
--- a/drivers/video/Kconfig	2004-11-21 11:48:41 +08:00
+++ b/drivers/video/Kconfig	2004-11-23 08:17:32 +08:00
@@ -444,11 +444,32 @@
 	  <http://www.erd.epson.com/vdc/html/products.htm>.
 
 config FB_NVIDIA
-       tristate "nVidia Support"
-       depends on FB && PCI
-       select FB_MODE_HELPERS
+	tristate "nVidia Framebuffer Support"
+	depends on FB && PCI
+	select I2C_ALGOBIT if FB_NVIDIA_I2C
+	select I2C if FB_NVIDIA_I2C
+	select FB_MODE_HELPERS
+	help
+	  This driver supports graphics boards with the nVidia chips, TNT
+	  and newer. For very old chipsets, such as the RIVA128, then use
+	  the the rivafb.
+	  Say Y if you have such a graphics board.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called nvidiafb.
+          none yet
+
+config FB_NVIDIA_I2C
+       bool "Enable DDC Support"
+       depends on FB_NVIDIA
        help
-         none yet
+	  This enables I2C support for nVidia Chipsets.  This is used
+	  only for getting EDID information from the attached display
+	  allowing for robust video mode handling and switching.
+
+	  Because fbdev-2.6 requires that drivers must be able to
+	  independently validate video mode parameters, you should say Y
+	  here.
 
 config FB_RIVA
 	tristate "nVidia Riva support"
diff -Nru a/drivers/video/modedb.c b/drivers/video/modedb.c
--- a/drivers/video/modedb.c	2004-11-17 18:15:20 +08:00
+++ b/drivers/video/modedb.c	2004-11-23 09:42:18 +08:00
@@ -86,8 +86,8 @@
 	FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
     }, {
 	/* 1024x768 @ 60 Hz, 48.4 kHz hsync */
-	NULL, 60, 1024, 768, 15384, 168, 8, 29, 3, 144, 6,
-	0, FB_VMODE_NONINTERLACED
+	NULL, 60, 1024, 768, 15384, 160, 24, 29, 3, 136, 6,
+	0, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA
     }, {
 	/* 640x480 @ 100 Hz, 53.01 kHz hsync */
 	NULL, 100, 640, 480, 21834, 96, 32, 36, 8, 96, 6,

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Tuesday 23 Nov 2004 01:50, Antonino A. Daplas wrote:
> On Tuesday 23 November 2004 07:47, Andrew Walrond wrote:
> >
> > Note the erroneous panel detection; this is a 1600x1200 tft lcd. The
> > panel is detected as 1024x768 in every following case.
>
> The panel size is programmed by the BIOS, not sure what what we can do
> about that.  So even if your display supports 1600x1200, you're still
> limited to 1024x768.

What, the video-card BIOS? Shouldn't it get the correct info from the EDID?

andrew@orac fbdev $ read-edid-1.4.1/parse-edid edid.dsub.32
read-edid-1.4.1/parse-edid: parse-edid version 1.4.1
read-edid-1.4.1/parse-edid: EDID checksum passed.

        # EDID version 1 revision 3
Section "Monitor"
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
        Identifier "iiyama "
        VendorName "IVM"
        ModelName "iiyama "
        # Block type: 2:0 3:fd
        HorizSync 30-80
        VertRefresh 56-85
        # Max dot clock (video bandwidth) 170 MHz
        # Block type: 2:0 3:fc
        # DPMS capabilities: Active off:yes  Suspend:yes  Standby:yes

        Mode    "1024x768"      # vfreq 59.196Hz, hfreq 48.363kHz
                DotClock        65.000000
                HTimings        1024 1040 1104 1344
                VTimings        768 781 783 817
                Flags   "-HSync" "-VSync"
        EndMode
        Mode    "1600x1200"     # vfreq 60.000Hz, hfreq 75.000kHz
                DotClock        162.000000
                HTimings        1600 1664 1856 2160
                VTimings        1200 1201 1204 1250
                Flags   "+HSync" "+VSync"
        EndMode
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
EndSection

>
> It seems that EDID block is not detected whether digital or analog. I think
> I missed a Kconfig changeset. Should be fixed with the included patch.
>
> Select y to FB_NVIDIA_I2C.
>

Ok, with your incremental patch, DSUB connection and no kernel params, the 
kernel boots into a corruption free 1600x1200 (200xwhatever) console with two 
nice penguins, after detecting EDIDs on BUS2 and BUS3.
Unfortunately, it then  Oops's like this: (copied by hand)

 Oops : PREEMPT SMP

 tty_open+342  chrdev_open+457
 dentry_open+315 filp_open+62
 get_unused_fd+244 sys_open+76
 init+652   child_rip+8
 init+0    child_rip+0

 RIP: check_tty_count+58

Booting with DVI connection and no params gives me a corruption free 1024x768 
console with two nice penguins. It also then Oopses in an identical way to 
above.

Getting closer...

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

On Tuesday 23 November 2004 20:32, Andrew Walrond wrote:
> On Tuesday 23 Nov 2004 01:50, Antonino A. Daplas wrote:
> > On Tuesday 23 November 2004 07:47, Andrew Walrond wrote:
> > > Note the erroneous panel detection; this is a 1600x1200 tft lcd. The
> > > panel is detected as 1024x768 in every following case.
> >
> > The panel size is programmed by the BIOS, not sure what what we can do
> > about that.  So even if your display supports 1600x1200, you're still
> > limited to 1024x768.
>
> What, the video-card BIOS? Shouldn't it get the correct info from the EDID?

If the display has an analog input, then yes.  It's different when the input
is digital. 

(Also, the EDID block may differ depending on the input type, this I'm not
sure).


> Ok, with your incremental patch, DSUB connection and no kernel params, the
> kernel boots into a corruption free 1600x1200 (200xwhatever) console with
> two nice penguins, after detecting EDIDs on BUS2 and BUS3.
> Unfortunately, it then  Oops's like this: (copied by hand)
>
>  Oops : PREEMPT SMP
>
>  tty_open+342  chrdev_open+457
>  dentry_open+315 filp_open+62
>  get_unused_fd+244 sys_open+76
>  init+652   child_rip+8
>  init+0    child_rip+0
>

Okay, try the attached patch.

Tony


[-- Attachment #2: nvidiafb2-inc2.diff --]
[-- Type: text/x-diff, Size: 3653 bytes --]

diff -Nru a/drivers/video/nvidia/nv_setup.c b/drivers/video/nvidia/nv_setup.c
--- a/drivers/video/nvidia/nv_setup.c	2004-11-23 06:01:00 +08:00
+++ b/drivers/video/nvidia/nv_setup.c	2004-11-23 22:19:56 +08:00
@@ -289,7 +289,8 @@
 	u16 implementation = par->Chipset & 0x0ff0;
 	u8 *edidA, *edidB;
 	struct fb_monspecs monitorA, monitorB;
-	int mobile = 0, validA = 0, validB = 0;
+	struct fb_monspecs *monA = NULL, *monB = NULL;
+	int mobile = 0;
 	int tvA = 0;
 	int tvB = 0;
 	int FlatPanel = -1;   /* really means the CRTC is slaved */
@@ -397,13 +398,13 @@
 		nvidia_probe_i2c_connector(par, 1, &edidA);
 		if(edidA && !fb_parse_edid(edidA, &var)) {
 			printk("nvidiafb: EDID found from BUS1\n");
-			fb_edid_to_monspecs(edidA, &monitorA);
-			FlatPanel = (monitorA.input == FB_DISP_DDI) ? 1 : 0;
+			monA = &monitorA;
+			fb_edid_to_monspecs(edidA, monA);
+			FlatPanel = (monA->input == FB_DISP_DDI) ? 1 : 0;
 			
 			/* NV4 doesn't support FlatPanels */
 			if((par->Chipset & 0x0fff) <= 0x0020)
 				FlatPanel = 0;
-			validA = 1;
 		} else {
 			VGA_WR08(par->PCIO, 0x03D4, 0x28);
 			if(VGA_RD08(par->PCIO, 0x03D5) & 0x80) {
@@ -484,15 +485,15 @@
 		nvidia_probe_i2c_connector(par, 1, &edidA);
 		if (edidA && !fb_parse_edid(edidA, &var)) {
 			printk("nvidiafb: EDID found from BUS1\n");
-			fb_edid_to_monspecs(edidA, &monitorA);
-			validA = 1;
+			monA = &monitorA;
+			fb_edid_to_monspecs(edidA, monA);
 		}
 
 		nvidia_probe_i2c_connector(par, 2, &edidB);
 		if (edidB && !fb_parse_edid(edidB, &var)) {
 			printk("nvidiafb: EDID found from BUS2\n");
-			fb_edid_to_monspecs(edidB, &monitorB);
-			validB = 1;
+			monB = &monitorB;
+			fb_edid_to_monspecs(edidB, monB);
 		}
 
 		if(slaved_on_A && !tvA) {
@@ -529,10 +530,10 @@
 			Television = 1;
 			printk("nvidiafb: CRTC 1 is currently programmed for "
 			       "TV\n");
-		} else if (validA) {
-			FlatPanel = (monitorA.input == FB_DISP_DDI) ? 1 : 0;
-		} else if (validB) {
-			FlatPanel = (monitorB.input == FB_DISP_DDI) ? 1 : 0;
+		} else if (monA) {
+			FlatPanel = (monA->input == FB_DISP_DDI) ? 1 : 0;
+		} else if (monB) {
+			FlatPanel = (monB->input == FB_DISP_DDI) ? 1 : 0;
 		}
 		
 		if(par->FlatPanel == -1) {
@@ -572,25 +573,30 @@
 			       "specified\n", par->CRTCnumber);
 		}
 		
-		if (validA) {
-			if (((monitorA.input == FB_DISP_DDI) &&
+		if (monA) {
+			if (((monA->input == FB_DISP_DDI) &&
 			     par->FlatPanel) ||
-			    ((monitorA.input != FB_DISP_DDI) &&
-			     !par->FlatPanel)) { 
-				if(validB)
-					fb_destroy_modedb(monitorB.modedb);
-			} else 
-				fb_destroy_modedb(monitorA.modedb);
+			    ((monA->input != FB_DISP_DDI) &&
+			     !par->FlatPanel)) {
+				if (monB) {
+					fb_destroy_modedb(monB->modedb);
+					monB = NULL;
+				}
+			} else {
+				fb_destroy_modedb(monA->modedb);
+				monA = NULL;
+			}
 		}
 		
-		if (validB) {
-			if (((monitorB.input == FB_DISP_DDI) &&
+		if (monB) {
+			if (((monB->input == FB_DISP_DDI) &&
 			     !par->FlatPanel) ||
-			    ((!monitorB.input != FB_DISP_DDI) &&
-			     par->FlatPanel)) 
-				fb_destroy_modedb(monitorB.modedb);
-			else
-				monitorA = monitorB;
+			    ((monB->input != FB_DISP_DDI) &&
+			     par->FlatPanel)) {
+				fb_destroy_modedb(monB->modedb);
+				monB = NULL;
+			} else 
+				monA = monB;
 		}
 
 		if(implementation == 0x0110)
@@ -615,10 +621,12 @@
 		printk("Panel size is %i x %i\n", par->fpWidth, par->fpHeight);
 	}
 	
-	if (validA || validB)
-		info->monspecs = monitorA;
+	if (monA)
+		info->monspecs = *monA;
+
 	kfree(edidA);
 	kfree(edidB);
+	
 	if(!par->FlatPanel || (info->var.bits_per_pixel != 24) ||
 	   !par->twoHeads)
 		par->FPDither = 0;

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Tuesday 23 Nov 2004 14:28, Antonino A. Daplas wrote:
>
> Okay, try the attached patch.
>

Ok, booting on dsub without params now results in a good 1024x768 (128x48) 
console and boots cleanly. (Note this was a 1600x1200 (200xwhatever) before 
the patch, which is the preferred, native resolution of the screen.)

 nvidiafb: nVidia device/chipset 10DE0250
 nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
 i2c_adapter i2c-0: registered as adapter #0
 i2c_adapter i2c-1: registered as adapter #1
 i2c_adapter i2c-2: registered as adapter #2
 nvidiafb: CRTC0 not found
 nvidiafb: CRTC1 found
 i2c_adapter i2c-0: master_xfer: with 2 msgs.
 nvidiafb: EDID found from BUS1
 i2c_adapter i2c-1: master_xfer: with 2 msgs.
 nvidiafb: EDID found from BUS2
 nvidiafb: CRTC 0appears to have a CRT attached
 nvidiafb: Using CRT on CRTC 0
 nvidiafb: MTRR set to ON
 Console: switching to colour frame buffer device 128x48
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)

Booting on dvi with no kernel params results in a broken (right shifted) 80x30 
display as before.

 nvidiafb: nVidia device/chipset 10DE0250
 nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
 i2c_adapter i2c-0: registered as adapter #0
 i2c_adapter i2c-1: registered as adapter #1
 i2c_adapter i2c-2: registered as adapter #2
 nvidiafb: CRTC0 not found
 nvidiafb: CRTC1 not found
 i2c_adapter i2c-0: master_xfer: with 2 msgs.
 nvidiafb: EDID found from BUS1
 i2c_adapter i2c-1: master_xfer: with 2 msgs.
 i2c_adapter i2c-1: master_xfer: with 2 msgs.
 i2c_adapter i2c-1: master_xfer: with 2 msgs.
 nvidiafb: CRTC 1 is currently programmed for DFP
 nvidiafb: Using DFP on CRTC 1
 Panel size is 1024 x 768
 nvidiafb: MTRR set to ON
 Console: switching to colour frame buffer device 80x30
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)

Booting on dvi with video=nvidiafb:1600x1200-32@60 results in a fully working 
console, but only at 80x25

 nvidiafb: nVidia device/chipset 10DE0250
 nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
 i2c_adapter i2c-0: registered as adapter #0
 i2c_adapter i2c-1: registered as adapter #1
 i2c_adapter i2c-2: registered as adapter #2
 nvidiafb: CRTC0 not found
 nvidiafb: CRTC1 not found
 i2c_adapter i2c-0: master_xfer: with 2 msgs.
 nvidiafb: EDID found from BUS1
 i2c_adapter i2c-1: master_xfer: with 2 msgs.
 i2c_adapter i2c-1: master_xfer: with 2 msgs.
 i2c_adapter i2c-1: master_xfer: with 2 msgs.
 nvidiafb: CRTC 1 is currently programmed for DFP
 nvidiafb: Using DFP on CRTC 1
 Panel size is 1024 x 768
 nvidiafb: MTRR set to ON
 Console: switching to colour frame buffer device 80x25
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)

The Oops has gone though :)

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

On Tuesday 23 November 2004 23:09, Andrew Walrond wrote:
> On Tuesday 23 Nov 2004 14:28, Antonino A. Daplas wrote:
> > Okay, try the attached patch.
>
> Ok, booting on dsub without params now results in a good 1024x768 (128x48)
> console and boots cleanly. (Note this was a 1600x1200 (200xwhatever) before
> the patch, which is the preferred, native resolution of the screen.)
>

Can you enable debugging in drivers/video/fbmon.c?  Just change the "undef" to
define in this line:

#undef DEBUG  /* define this for verbose EDID parsing output */

Send me the dmesg output for both dvi and dsub.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Tuesday 23 Nov 2004 15:18, Antonino A. Daplas wrote:
> On Tuesday 23 November 2004 23:09, Andrew Walrond wrote:
> > On Tuesday 23 Nov 2004 14:28, Antonino A. Daplas wrote:
> > > Okay, try the attached patch.
> >
> > Ok, booting on dsub without params now results in a good 1024x768
> > (128x48) console and boots cleanly. (Note this was a 1600x1200
> > (200xwhatever) before the patch, which is the preferred, native
> > resolution of the screen.)
>

Actually, I think this is die to having both dsub and dvi attached during that 
test. Just dsub boots to 1600x1200 as before

> Can you enable debugging in drivers/video/fbmon.c?  Just change the "undef"
> to define in this line:
>
> #undef DEBUG  /* define this for verbose EDID parsing output */
>
> Send me the dmesg output for both dvi and dsub.
>

DSUB

nvidiafb: nVidia device/chipset 10DE0250
nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
i2c_adapter i2c-0: registered as adapter #0
i2c_adapter i2c-1: registered as adapter #1
i2c_adapter i2c-2: registered as adapter #2
nvidiafb: CRTC0 not found
nvidiafb: CRTC1 found
i2c_adapter i2c-0: master_xfer: with 2 msgs.
i2c_adapter i2c-0: master_xfer: with 2 msgs.
i2c_adapter i2c-0: master_xfer: with 2 msgs.
i2c_adapter i2c-1: master_xfer: with 2 msgs.
nvidiafb: EDID found from BUS2
========================================
Display Information (EDID)
========================================
   EDID Version 1.3
   Manufacturer: IVM
   Model: 4800
   Serial#: 95
   Year: 2001 Week 44
   Monitor Name: iiyama
   Monitor Name: AU4831D
   Display Characteristics:
      Monitor Operating Limits: From EDID
           H: 24-80KHz V: 50-85Hz DCLK: 170MHz
      Analog Display Input: Input Voltage - 0.700V/0.000V
      Sync: Separate Composite
      Max H-size in cm: 39
      Max V-size in cm: 29
      Gamma: 2.20
      DPMS: Active yes, Suspend yes, Standby yes
      RGB Color Display
      Chroma
         RedX:     0.619 RedY:     0.340
         GreenX:   0.279 GreenY:   0.600
         BlueX:    0.140 BlueY:    0.090
         WhiteX:   0.289 WhiteY:   0.300
      First DETAILED Timing is preferred
   Supported VESA Modes
      720x400@70Hz
      640x480@60Hz
      640x480@67Hz
      640x480@72Hz
      640x480@75Hz
      800x600@56Hz
      800x600@60Hz
      800x600@72Hz
      800x600@75Hz
      832x624@75Hz
      1024x768@60Hz
      1024x768@70Hz
      1024x768@75Hz
      1280x1024@75Hz
      Manufacturer's mask: 0
   Standard Timings
      1600x1200@60Hz
      1280x1024@60Hz
      1280x1024@70Hz
      1152x864@75Hz
      1152x864@85Hz
      1024x768@66Hz
      1024x768@70Hz
      1024x768@85Hz
   Detailed Timings
      162 MHz 1600 1664 1856 2160 1200 1201 1204 1250 +HSync +VSync

========================================
nvidiafb: CRTC 0appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0
nvidiafb: MTRR set to ON
Console: switching to colour frame buffer device 200x75
nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)



DVI

nvidiafb: nVidia device/chipset 10DE0250
nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
i2c_adapter i2c-0: registered as adapter #0
i2c_adapter i2c-1: registered as adapter #1
i2c_adapter i2c-2: registered as adapter #2
nvidiafb: CRTC0 not found
nvidiafb: CRTC1 not found
i2c_adapter i2c-0: master_xfer: with 2 msgs.
nvidiafb: EDID found from BUS1
========================================
Display Information (EDID)
========================================
   EDID Version 1.3
   Manufacturer: IVM
   Model: 4800
   Serial#: 1001
   Year: 2002 Week 1
   Monitor Name: iiyama
   Display Characteristics:
      Monitor Operating Limits: From EDID
           H: 30-80KHz V: 56-85Hz DCLK: 170MHz
      Digital Display Input
      Sync: Serration on
      Max H-size in cm: 39
      Max V-size in cm: 29
      Gamma: 2.20
      DPMS: Active yes, Suspend yes, Standby yes
      RGB Color Display
      Chroma
         RedX:     0.619 RedY:     0.340
         GreenX:   0.279 GreenY:   0.600
         BlueX:    0.140 BlueY:    0.090
         WhiteX:   0.289 WhiteY:   0.300
      First DETAILED Timing is preferred
   Supported VESA Modes
      720x400@70Hz
      640x480@60Hz
      640x480@67Hz
      640x480@72Hz
      640x480@75Hz
      800x600@56Hz
      800x600@60Hz
      800x600@72Hz
      800x600@75Hz
      832x624@75Hz
      1024x768@60Hz
      1024x768@70Hz
      1024x768@75Hz
      1280x1024@75Hz
      1152x870@75Hz
      Manufacturer's mask: 0
   Standard Timings
      1280x1024@60Hz
      1024x819@85Hz
      800x640@85Hz
      640x512@85Hz
   Detailed Timings
      65 MHz 1024 1040 1104 1344 768 781 783 817 -HSync -VSync

      162 MHz 1600 1664 1856 2160 1200 1201 1204 1250 +HSync +VSync

========================================
i2c_adapter i2c-1: master_xfer: with 2 msgs.
i2c_adapter i2c-1: master_xfer: with 2 msgs.
i2c_adapter i2c-1: master_xfer: with 2 msgs.
nvidiafb: CRTC 1 is currently programmed for DFP
nvidiafb: Using DFP on CRTC 1
Panel size is 1024 x 768
nvidiafb: MTRR set to ON
Console: switching to colour frame buffer device 80x30
nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Wednesday 24 November 2004 00:08, Andrew Walrond wrote:
> On Tuesday 23 Nov 2004 15:18, Antonino A. Daplas wrote:
> > On Tuesday 23 November 2004 23:09, Andrew Walrond wrote:
> > > On Tuesday 23 Nov 2004 14:28, Antonino A. Daplas wrote:
> > > > Okay, try the attached patch.
> > >
> > > Ok, booting on dsub without params now results in a good 1024x768
> > > (128x48) console and boots cleanly. (Note this was a 1600x1200
> > > (200xwhatever) before the patch, which is the preferred, native
> > > resolution of the screen.)
>
> Actually, I think this is die to having both dsub and dvi attached during
> that test. Just dsub boots to 1600x1200 as before
>

Okay, I think I this should fix the dvi misdetection, and I think it should
also fix the preferred timing of 1600x1200 even if both dsub and dvi are
attached.  Try the attached patch.

Tony

[-- Attachment #2: nvidiafb2-inc3.diff --]
[-- Type: text/x-diff, Size: 1571 bytes --]

diff -Nru a/drivers/video/nvidia/nv_setup.c b/drivers/video/nvidia/nv_setup.c
--- a/drivers/video/nvidia/nv_setup.c	2004-11-23 22:19:56 +08:00
+++ b/drivers/video/nvidia/nv_setup.c	2004-11-24 01:02:51 +08:00
@@ -400,7 +400,7 @@
 			printk("nvidiafb: EDID found from BUS1\n");
 			monA = &monitorA;
 			fb_edid_to_monspecs(edidA, monA);
-			FlatPanel = (monA->input == FB_DISP_DDI) ? 1 : 0;
+			FlatPanel = (monA->input & FB_DISP_DDI) ? 1 : 0;
 			
 			/* NV4 doesn't support FlatPanels */
 			if((par->Chipset & 0x0fff) <= 0x0020)
@@ -531,9 +531,9 @@
 			printk("nvidiafb: CRTC 1 is currently programmed for "
 			       "TV\n");
 		} else if (monA) {
-			FlatPanel = (monA->input == FB_DISP_DDI) ? 1 : 0;
+			FlatPanel = (monA->input & FB_DISP_DDI) ? 1 : 0;
 		} else if (monB) {
-			FlatPanel = (monB->input == FB_DISP_DDI) ? 1 : 0;
+			FlatPanel = (monB->input & FB_DISP_DDI) ? 1 : 0;
 		}
 		
 		if(par->FlatPanel == -1) {
@@ -574,9 +574,9 @@
 		}
 		
 		if (monA) {
-			if (((monA->input == FB_DISP_DDI) &&
+			if (((monA->input & FB_DISP_DDI) &&
 			     par->FlatPanel) ||
-			    ((monA->input != FB_DISP_DDI) &&
+			    ((!(monA->input & FB_DISP_DDI)) &&
 			     !par->FlatPanel)) {
 				if (monB) {
 					fb_destroy_modedb(monB->modedb);
@@ -589,9 +589,9 @@
 		}
 		
 		if (monB) {
-			if (((monB->input == FB_DISP_DDI) &&
+			if (((monB->input & FB_DISP_DDI) &&
 			     !par->FlatPanel) ||
-			    ((monB->input != FB_DISP_DDI) &&
+			    ((!(monB->input & FB_DISP_DDI)) &&
 			     par->FlatPanel)) {
 				fb_destroy_modedb(monB->modedb);
 				monB = NULL;

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Tuesday 23 Nov 2004 17:07, Antonino A. Daplas wrote:
>
> Okay, I think I this should fix the dvi misdetection, and I think it should
> also fix the preferred timing of 1600x1200 even if both dsub and dvi are
> attached.  Try the attached patch.
>

Not quite, but close...

With just dsub and no params, we get a perfect 1600x1200 (200x75) console

nvidiafb: nVidia device/chipset 10DE0250
nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
i2c_adapter i2c-0: registered as adapter #0
i2c_adapter i2c-1: registered as adapter #1
i2c_adapter i2c-2: registered as adapter #2
nvidiafb: CRTC0 not found
nvidiafb: CRTC1 found
i2c_adapter i2c-0: master_xfer: with 2 msgs.
i2c_adapter i2c-0: master_xfer: with 2 msgs.
i2c_adapter i2c-0: master_xfer: with 2 msgs.
i2c_adapter i2c-1: master_xfer: with 2 msgs.
nvidiafb: EDID found from BUS2
========================================
Display Information (EDID)
========================================
   EDID Version 1.3
   Manufacturer: IVM
   Model: 4800
   Serial#: 95
   Year: 2001 Week 44
   Monitor Name: iiyama
   Monitor Name: AU4831D
   Display Characteristics:
      Monitor Operating Limits: From EDID
           H: 24-80KHz V: 50-85Hz DCLK: 170MHz
      Analog Display Input: Input Voltage - 0.700V/0.000V
      Sync: Separate Composite
      Max H-size in cm: 39
      Max V-size in cm: 29
      Gamma: 2.20
      DPMS: Active yes, Suspend yes, Standby yes
      RGB Color Display
      Chroma
         RedX:     0.619 RedY:     0.340
         GreenX:   0.279 GreenY:   0.600
         BlueX:    0.140 BlueY:    0.090
         WhiteX:   0.289 WhiteY:   0.300
      First DETAILED Timing is preferred
   Supported VESA Modes
      720x400@70Hz
      640x480@60Hz
      640x480@67Hz
      640x480@72Hz
      640x480@75Hz
      800x600@56Hz
      800x600@60Hz
      800x600@72Hz
      800x600@75Hz
      832x624@75Hz
      1024x768@60Hz
      1024x768@70Hz
      1024x768@75Hz
      1280x1024@75Hz
      Manufacturer's mask: 0
   Standard Timings
      1600x1200@60Hz
      1280x1024@60Hz
      1280x1024@70Hz
      1152x864@75Hz
      1152x864@85Hz
      1024x768@66Hz
      1024x768@70Hz
      1024x768@85Hz
   Detailed Timings
      162 MHz 1600 1664 1856 2160 1200 1201 1204 1250 +HSync +VSync

========================================
nvidiafb: CRTC 0appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0
nvidiafb: MTRR set to ON
Console: switching to colour frame buffer device 200x75
nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)


With both dsub and dvi, another perfect 1600x1200 console. (first EDID 
truncated due to dmesg log not big enough; I can fix this if you need)

      1024x768@60Hz
      1024x768@70Hz
      1024x768@75Hz
      1280x1024@75Hz
      1152x870@75Hz
      Manufacturer's mask: 0
   Standard Timings
      1280x1024@60Hz
      1024x819@85Hz
      800x640@85Hz
      640x512@85Hz
   Detailed Timings
      65 MHz 1024 1040 1104 1344 768 781 783 817 -HSync -VSync

      162 MHz 1600 1664 1856 2160 1200 1201 1204 1250 +HSync +VSync

========================================
i2c_adapter i2c-1: master_xfer: with 2 msgs.
nvidiafb: EDID found from BUS2
========================================
Display Information (EDID)
========================================
   EDID Version 1.3
   Manufacturer: IVM
   Model: 4800
   Serial#: 95
   Year: 2001 Week 44
   Monitor Name: iiyama
   Monitor Name: AU4831D
   Display Characteristics:
      Monitor Operating Limits: From EDID
           H: 24-80KHz V: 50-85Hz DCLK: 170MHz
      Analog Display Input: Input Voltage - 0.700V/0.000V
      Sync: Separate Composite
      Max H-size in cm: 39
      Max V-size in cm: 29
      Gamma: 2.20
      DPMS: Active yes, Suspend yes, Standby yes
      RGB Color Display
      Chroma
         RedX:     0.619 RedY:     0.340
         GreenX:   0.279 GreenY:   0.600
         BlueX:    0.140 BlueY:    0.090
         WhiteX:   0.289 WhiteY:   0.300
      First DETAILED Timing is preferred
   Supported VESA Modes
      720x400@70Hz
      640x480@60Hz
      640x480@67Hz
      640x480@72Hz
      640x480@75Hz
      800x600@56Hz
      800x600@60Hz
      800x600@72Hz
      800x600@75Hz
      832x624@75Hz
      1024x768@60Hz
      1024x768@70Hz
      1024x768@75Hz
      1280x1024@75Hz
      Manufacturer's mask: 0
   Standard Timings
      1600x1200@60Hz
      1280x1024@60Hz
      1280x1024@70Hz
      1152x864@75Hz
      1152x864@85Hz
      1024x768@66Hz
      1024x768@70Hz
      1024x768@85Hz
   Detailed Timings
      162 MHz 1600 1664 1856 2160 1200 1201 1204 1250 +HSync +VSync

========================================
nvidiafb: CRTC 0appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0
nvidiafb: MTRR set to ON
Console: switching to colour frame buffer device 200x75



With dvi connection and no params, I get a fully working console, but at 
1024x768 (128x48)

nvidiafb: nVidia device/chipset 10DE0250
nvidiafb: nVidia Corporation NV25 [GeForce4 Ti 4600]
i2c_adapter i2c-0: registered as adapter #0
i2c_adapter i2c-1: registered as adapter #1
i2c_adapter i2c-2: registered as adapter #2
nvidiafb: CRTC0 not found
nvidiafb: CRTC1 not found
i2c_adapter i2c-0: master_xfer: with 2 msgs.
nvidiafb: EDID found from BUS1
========================================
Display Information (EDID)
========================================
   EDID Version 1.3
   Manufacturer: IVM
   Model: 4800
   Serial#: 1001
   Year: 2002 Week 1
   Monitor Name: iiyama
   Display Characteristics:
      Monitor Operating Limits: From EDID
           H: 30-80KHz V: 56-85Hz DCLK: 170MHz
      Digital Display Input
      Sync: Serration on
      Max H-size in cm: 39
      Max V-size in cm: 29
      Gamma: 2.20
      DPMS: Active yes, Suspend yes, Standby yes
      RGB Color Display
      Chroma
         RedX:     0.619 RedY:     0.340
         GreenX:   0.279 GreenY:   0.600
         BlueX:    0.140 BlueY:    0.090
         WhiteX:   0.289 WhiteY:   0.300
      First DETAILED Timing is preferred
   Supported VESA Modes
      720x400@70Hz
      640x480@60Hz
      640x480@67Hz
      640x480@72Hz
      640x480@75Hz
      800x600@56Hz
      800x600@60Hz
      800x600@72Hz
      800x600@75Hz
      832x624@75Hz
      1024x768@60Hz
      1024x768@70Hz
      1024x768@75Hz
      1280x1024@75Hz
      1152x870@75Hz
      Manufacturer's mask: 0
   Standard Timings
      1280x1024@60Hz
      1024x819@85Hz
      800x640@85Hz
      640x512@85Hz
   Detailed Timings
      65 MHz 1024 1040 1104 1344 768 781 783 817 -HSync -VSync

      162 MHz 1600 1664 1856 2160 1200 1201 1204 1250 +HSync +VSync

========================================
i2c_adapter i2c-1: master_xfer: with 2 msgs.
i2c_adapter i2c-1: master_xfer: with 2 msgs.
i2c_adapter i2c-1: master_xfer: with 2 msgs.
nvidiafb: CRTC 1 is currently programmed for DFP
nvidiafb: Using DFP on CRTC 1
Panel size is 1024 x 768
nvidiafb: MTRR set to ON
Console: switching to colour frame buffer device 128x48
nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)


With DVI and video=nvidiafb:1600x1200-32@60 I get a kernel hang like this 
(copied by hand and shortened in places)

Decompressing linux
Bootdata ok (command line is root=... video=nvidiafb:1600x1200-32@60)
Linux version 2.6.10-rc2 ...
BIOS-provided physical map
Scanning NUMA topology in Northbridge 24
Number of nodes 2 (10010)
Node 0 using interleaving mode 1/0
No NUMA configuration found


and thats as far as it gets.

Getting closer by the hour :)

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

On Wednesday 24 November 2004 02:01, Andrew Walrond wrote:
> On Tuesday 23 Nov 2004 17:07, Antonino A. Daplas wrote:
> > Okay, I think I this should fix the dvi misdetection, and I think it
> > should also fix the preferred timing of 1600x1200 even if both dsub and
> > dvi are attached.  Try the attached patch.
>
> Not quite, but close...
>
> With just dsub and no params, we get a perfect 1600x1200 (200x75) console

Great.

>
> With both dsub and dvi, another perfect 1600x1200 console. (first EDID

Great :-)

> truncated due to dmesg log not big enough; I can fix this if you need)

No need.  The first EDID block is for dvi, the second is for dsub.

>
> With dvi connection and no params, I get a fully working console, but at
> 1024x768 (128x48)

Okay, this is what I wanted to fix.  Note that the preferred timing when
dvi is attached is 1024x768. When dsub, it's 1600x1200.  You see this
in your dmesg "First DETAILED Timing is preferred", and without options
the first detailed timing block will be used.

>
> With DVI and video=nvidiafb:1600x1200-32@60 I get a kernel hang like this
> (copied by hand and shortened in places)

Okay, this is expected.  Since the panel size is only 1024x768, using a mode
of 1600x1200 failed.  So the framebuffer exited initialization with an error which
caused an oops.

Note, that you may not be able to force resolutions > panel size.  You can
try, all you need to do is remove this code in
drivers/video/nvidia/nvidia.c:nvidiafb_check_var:

	if (par->fpWidth && par->fpHeight && (par->fpWidth < var->xres ||
					      par->fpHeight < var->yres))
		return -EINVAL;

But I don't know if your display can tolerate that.

For now, I'll add checks during the initializatiion that will refuse modes
greater than the panel size.

Unfortunately, without any docs on how to adjust the default panel size,
you will be limited to this resolution only.

Does vesafb work in x86_64?  If it does you can add this in your
commandline:

vga=0x307 

0x306 is the code for 1280x1024, see Documentation/fb/vesafb.txt.

Then check your dmesg if the panel size also changed.  If it did, then
you can do this:

vga=0x307 video=nvidiafb:1280x1024@60.

>
> Decompressing linux
> Bootdata ok (command line is root=... video=nvidiafb:1600x1200-32@60)
> Linux version 2.6.10-rc2 ...
> BIOS-provided physical map
> Scanning NUMA topology in Northbridge 24
> Number of nodes 2 (10010)
> Node 0 using interleaving mode 1/0
> No NUMA configuration found
>
>
> and thats as far as it gets.
>
> Getting closer by the hour :)

Yes.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Tuesday 23 Nov 2004 18:26, Antonino A. Daplas wrote:
> On Wednesday 24 November 2004 02:01, Andrew Walrond wrote:
>
> > With dvi connection and no params, I get a fully working console, but at
> > 1024x768 (128x48)
>
> Okay, this is what I wanted to fix.  Note that the preferred timing when
> dvi is attached is 1024x768. When dsub, it's 1600x1200.  You see this
> in your dmesg "First DETAILED Timing is preferred", and without options
> the first detailed timing block will be used.
>

Can you explain further...
This is £1000 of TFT LCD panel with 1600x1200 _physical_ pixels. The panel 
size is 1600x1200, not 1024x768. So where is this erroneous value coming 
from?

> Note, that you may not be able to force resolutions > panel size.  You can
> try, all you need to do is remove this code in
> drivers/video/nvidia/nvidia.c:nvidiafb_check_var:

I don't want to force illegal modes, I'd rather just have the real panel size 
reported, then all modes would be legal :(

I wonder; does DVI have any recommended limits on bandwidth, resulting in a 
max resolution with dvi of 1024x768? Something at the back of my mind is 
triggering bells here. Anyone know? I guess google is my friend ;)

I'll try the other things you mention and report back later.

Thanks for your efforts this far!

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Tuesday 23 Nov 2004 19:00, Andrew Walrond wrote:
>
> I wonder; does DVI have any recommended limits on bandwidth, resulting in a
> max resolution with dvi of 1024x768? Something at the back of my mind is
> triggering bells here. Anyone know? I guess google is my friend ;)
>

Further to this, I found
 "single link DVI supports a maximum bandwidth of 165 MHz (1920x1080 at 60 Hz, 
1280x1024 at 85Hz)"

Here
 http://www.bnoack.com/index.html?http&&&www.bnoack.com/data/DVI-conn.html

So it seems it's not a fundamental limit of dvi.

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Tuesday 23 Nov 2004 18:26, Antonino A. Daplas wrote:
>
> For now, I'll add checks during the initializatiion that will refuse modes
> greater than the panel size.
>
Even if they are listed in the list of supported modes and detailed modes in 
the EDID?

My (dvi) edid lists valid modes of

      First DETAILED Timing is preferred
   Supported VESA Modes
      720x400@70Hz
      640x480@60Hz
      640x480@67Hz
      640x480@72Hz
      640x480@75Hz
      800x600@56Hz
      800x600@60Hz
      800x600@72Hz
      800x600@75Hz
      832x624@75Hz
      1024x768@60Hz
      1024x768@70Hz
      1024x768@75Hz
      1280x1024@75Hz
      1152x870@75Hz
      Manufacturer's mask: 0
   Standard Timings
      1280x1024@60Hz
      1024x819@85Hz
      800x640@85Hz
      640x512@85Hz
   Detailed Timings
      65 MHz 1024 1040 1104 1344 768 781 783 817 -HSync -VSync

      162 MHz 1600 1664 1856 2160 1200 1201 1204 1250 +HSync +VSync

Ok, the first detailed mode is preferred, but the second is equal;y supported.

> Unfortunately, without any docs on how to adjust the default panel size,
> you will be limited to this resolution only.

I'm a bit confused now. On one hand you seem to be testing for and rejecting 
modes > panel size in the driver; But here I infer that the hardware won't 
accept these modes unless we can somehow reset the panel size first?

>
> Does vesafb work in x86_64?  If it does you can add this in your
> commandline:
>
> vga=0x307
>
> 0x306 is the code for 1280x1024, see Documentation/fb/vesafb.txt.
>
> Then check your dmesg if the panel size also changed.  If it did, then
> you can do this:
>
> vga=0x307 video=nvidiafb:1280x1024@60.

And this is just a possible means of tricking the hardware into adjusting the 
panel size for us?

Sorry about all the questions, but I want to understand so I can investigate 
further. Its frustrating having massively expensive screens with the latest 
digital dvi cables behaving like a cheap 1024x768 monitor ;)

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Geert Uytterhoeven]

On Tue, 23 Nov 2004, Andrew Walrond wrote:
> On Tuesday 23 Nov 2004 18:26, Antonino A. Daplas wrote:
> > Does vesafb work in x86_64?  If it does you can add this in your
> > commandline:
> >
> > vga=0x307
> >
> > 0x306 is the code for 1280x1024, see Documentation/fb/vesafb.txt.
> >
> > Then check your dmesg if the panel size also changed.  If it did, then
> > you can do this:
> >
> > vga=0x307 video=nvidiafb:1280x1024@60.
> 
> And this is just a possible means of tricking the hardware into adjusting the 
> panel size for us?

No, this will use the BIOS to switch to a 1280x1024 mode before starting the
kernel. Remember that Tony told you the panel size is set up by the BIOS. If
that's really the case, it should help.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Tuesday 23 Nov 2004 19:59, Geert Uytterhoeven wrote:
>
> No, this will use the BIOS to switch to a 1280x1024 mode before starting
> the kernel. Remember that Tony told you the panel size is set up by the
> BIOS. If that's really the case, it should help.
>

Hi Geert,

I got that. I guess I'm asking whether the problem is self imposed by our 
driver by rejecting modes > panel size. Ie could we just ignore the panel 
size and allow any EDID supported modes?
Or, is it the video card that in any case would not allow us to set modes > 
panel size?

Chad explains it well in his email.

I guess I need to start reading the code :)

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

On Wednesday 24 November 2004 04:53, Andrew Walrond wrote:
> On Tuesday 23 Nov 2004 19:59, Geert Uytterhoeven wrote:
> > No, this will use the BIOS to switch to a 1280x1024 mode before starting
> > the kernel. Remember that Tony told you the panel size is set up by the
> > BIOS. If that's really the case, it should help.

When the input is digital, it seems that there are other registers that are
programmed besides that of the CRTC registers.  During the setup, some
of the registers are actually read by the code, and these are the panel width
and height.  The rest of the registers we don't know about (no
documentation).

So the safe approach is to accept what the BIOS programmed for us, use
scaling for res < panel size, and reject all res > panel size. If we know
how to program the rest of the registers, then this should be no problem.

Therefore, using vesafb to pre-program the registers for higher resolutions
means that the BIOS can setup the undocumented registers for us so we can
have a limit greater than 1024x768.

If the input is analog, then all that is required are the CRTC registers. The
panel size is actually not read in analog input. And since we know what to
do with CRTC registers, even if the preferred mode is 1024x768 but the EDID
tells us that it can support timings other than that, we can still use that
mode.

In short, the main difference is the type of input and lack of documentation.

>
> Hi Geert,
>
> I got that. I guess I'm asking whether the problem is self imposed by our
> driver by rejecting modes > panel size. Ie could we just ignore the panel
> size and allow any EDID supported modes?

As I've said, you can try to ignore the registers pre-programmed by the
BIOS, but I don't know the side effects of this.

> Or, is it the video card that in any case would not allow us to set modes >
> panel size?

No, it's the undocumented registers that prevents us from using modes >
panel size.

>
> Chad explains it well in his email.

Yes, what Chad said is true if the input is analog.  It's a different story if
the input is digital.

Anyway, attached is a patch that prevents an oops if the boot mode is
illegal.  It will still limit your resolution to panel size if input is digital.

Tony

BTW: How does X behave if the input is digital.  Does it accept modes
greater than panel size?  If it does, then the documentation is actually
there.  I'll look at the X code again.  And I'll probably do some googling
on this.  If you happen to encounter any kind of programming info about
this, let me know also.

Thanks for testing.



[-- Attachment #2: nvidiafb2-inc4.diff --]
[-- Type: text/x-diff, Size: 1672 bytes --]

diff -Nru a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
--- a/drivers/video/nvidia/nvidia.c	2004-11-23 06:01:00 +08:00
+++ b/drivers/video/nvidia/nvidia.c	2004-11-24 06:15:15 +08:00
@@ -1101,15 +1101,16 @@
                     | FBINFO_HWACCEL_YPAN
 	            | FBINFO_MISC_MODESWITCHLATE;
 
-	info->var = nvidiafb_default_var;
-	if (mode_option) {
-		fb_find_mode(&info->var, info, mode_option, specs->modedb,
-			     specs->modedb_len, NULL, 8);
-	} else if (specs->modedb != NULL) {
+	fb_videomode_to_modelist(info->monspecs.modedb,
+				 info->monspecs.modedb_len,
+				 &info->modelist);
+	fb_var_to_videomode(&modedb, &nvidiafb_default_var);
+
+	if (specs->modedb != NULL) {
 		/* get preferred timing */
 		if (specs->misc & FB_MISC_1ST_DETAIL) {
 			int i;
-
+			
 			for (i = 0; i < specs->modedb_len; i++) {
 				if (specs->modedb[i].flag & FB_MODE_IS_FIRST) {
 					modedb = specs->modedb[i];
@@ -1121,16 +1122,18 @@
 			modedb = specs->modedb[0];
 		}
 		info->var.bits_per_pixel = 8;
-		fb_videomode_to_var(&info->var, &modedb);
+		fb_videomode_to_var(&nvidiafb_default_var, &modedb);
 	}
 
+	if (mode_option)
+		fb_find_mode(&nvidiafb_default_var, info, mode_option,
+			     specs->modedb, specs->modedb_len, &modedb, 8);
+
+	info->var = nvidiafb_default_var;
 	info->fix.visual = (info->var.bits_per_pixel == 8) ?
 		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
 	info->pseudo_palette = par->pseudo_palette;
 	fb_alloc_cmap(&info->cmap, 256, 0);	
-	fb_videomode_to_modelist(info->monspecs.modedb,
-				 info->monspecs.modedb_len,
-				 &info->modelist);
 	fb_destroy_modedb(info->monspecs.modedb);
 	info->monspecs.modedb = NULL;
 

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

Hi Tony,

Thanks for taking the time to explain; there is a lot of knowledge in your 
post that it would have taken an age to acquire from scratch.

On Tuesday 23 Nov 2004 22:44, Antonino A. Daplas wrote:
>
> BTW: How does X behave if the input is digital.  Does it accept modes
> greater than panel size?  If it does, then the documentation is actually
> there.  I'll look at the X code again.  And I'll probably do some googling
> on this.  If you happen to encounter any kind of programming info about
> this, let me know also.
>

I'll try all the stuff you has suggested and report back some results 
tomorrow.

> Thanks for testing.

Not an issue. I want the linux frame buffer to work well on _all_ modern 
graphics hardware for my own selfish reasons ;)

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Tuesday 23 Nov 2004 22:44, Antonino A. Daplas wrote:
>
> BTW: How does X behave if the input is digital.  Does it accept modes
> greater than panel size?  If it does, then the documentation is actually
> there.  I'll look at the X code again.  And I'll probably do some googling
> on this.  If you happen to encounter any kind of programming info about
> this, let me know also.
>

Just tried this; No joy. The screen just goes blank. I think we need to find 
out about those undocumented registers.

I'll try the vesafb trick next.

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Chad Daelhousen]

At Tue, Nov 23, 2004 at 07:23:40PM +0000, Andrew Walrond wrote:
> On Tuesday 23 Nov 2004 18:26, Antonino A. Daplas wrote:
> >
> > For now, I'll add checks during the initializatiion that will refuse modes
> > greater than the panel size.
> >
> Even if they are listed in the list of supported modes and detailed modes in 
> the EDID?
> 
> My (dvi) edid lists valid modes of
> 
>       First DETAILED Timing is preferred
>    Supported VESA Modes
...
>    Detailed Timings
>       65 MHz 1024 1040 1104 1344 768 781 783 817 -HSync -VSync
> 
>       162 MHz 1600 1664 1856 2160 1200 1201 1204 1250 +HSync +VSync
> 
> Ok, the first detailed mode is preferred, but the second is equal;y supported.
> 
> > Unfortunately, without any docs on how to adjust the default panel size,
> > you will be limited to this resolution only.
> 
> I'm a bit confused now. On one hand you seem to be testing for and rejecting 
> modes > panel size in the driver; But here I infer that the hardware won't 
> accept these modes unless we can somehow reset the panel size first?
> 

It sounds to me like the driver is assuming that the preferred mode is
the maximum size that the panel can display. In your case, this is
wrong, since the panel is claiming 1024x768 as a preferred mode. If that
assumption were fixed, it should be able to pull 1600x1200 out of the
EDID block and run fine with it. You'd still need a video=1600x1200 to
override the "preferred" mode, but at least you'd have it.

AFAIK, when doing I2C and reading the EDID block, the driver is
bypassing any BIOS, so there should be no need to fiddle with vga=.

Someone else will have to write the patch, though, since I don't have an
nvidia card to test on.

-- 
...: Chad Daelhousen :.........
"The Soviet Union tried to restrict academic freedom along national
lines, and it didn't do the country any good. We should try not to
follow in those footsteps." --Bruce Schneier, CRYPTO-GRAM, Oct. 2004


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Rivafb won't work with DVI connector

[Andrew Walrond]

On Tuesday 23 Nov 2004 18:26, Antonino A. Daplas wrote:
>
> Does vesafb work in x86_64?  If it does you can add this in your
> commandline:
>
> vga=0x307
>
> 0x306 is the code for 1280x1024, see Documentation/fb/vesafb.txt.
>
> Then check your dmesg if the panel size also changed.  If it did, then
> you can do this:
>
> vga=0x307 video=nvidiafb:1280x1024@60.
>

If I did this right, it doesn't help. I built in the vesafb as well as your 
new nvidafb, then booted with the commandline

 vga=0x31b video=nvidiafb:1280x1024-32@60

It looks like the nvidafb got the first bite of the cherry:

 ...
 nvidiafb: CRTC 1 is currently programmed for DFP
 nvidiafb: Using DFP on CRTC 1
 Panel size is 1024 x 768
 nvidiafb: MTRR set to ON
 Console: switching to colour frame buffer device 128x48
 nvidiafb: PCI nVidia NV25 framebuffer (128MB @ 0xE0000000)
 vesafb: probe of vesafb0 failed with error -6
 ...


Do you know if the nvidia developers lurk on lkml? I seem to remember somebody 
saying that they do. If so, is it worth asking them for a bit of help with 
this? I know they're not about to open source their binary driver due to ip 
license problems, but the information we require to overcome this problem in 
the fb driver is probably quite trivial in nature. I assume they have been 
forthcoming in the past wrt the open source X driver.

What do you think? Worth asking?

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/