Opened 8 years ago

Last modified 6 months ago

#3850 assigned bug

don't set non-existing VESA modes?

Reported by: rudolfc Owned by: Nobody
Priority: normal Milestone: R1
Component: System/Boot Loader Version: R1/pre-alpha1
Keywords: Cc: Rudolf.Cornelissen@…, fredrik.holmqvist@…, matthias.rampke@…
Blocked By: Blocking: #7662
Has a Patch: no Platform: All


It is possible that systems are outthere that have an older gfx card, but a fairly recent monitor. In such a case the native resolution of this monitor can be higher than the highest available VESA mode in the card's BIOS. On top of that, it's very possible that the native resolution can be set by the haiku gfx driver. Since such a resolution will automatically also be preset in the 'vesa' config file, on next boot that non-existing mode will be set. The result is no signal (or hanging cards) during the boot and the boot-icons won't be visible.

The kernel should check a vesa settings file against reported available VESA modes from the card at boot-time, and fall back to a lower mode if the requested mode is not there.

Attachments (1)

vesa_edi_wip.patch (12.5 KB) - added by Fredrik Holmqvist 8 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 8 years ago by rudolfc

I saw this problem on TNT1, TNT2, TNT2-M64, NV11 and NV15 from nvidia.

You'll see the monitor shutoff during boot, and come back on after the gfx driver takes over.

Assigning to Axel because I think you know how the VESA stuff works, correct?

Bye, and thanks in advance for looking into this..


comment:2 Changed 8 years ago by rudolfc

Cc: Rudolf.Cornelissen@… added

BTW: the kernel reports refreshrates instead of colordepths belonging to the modes. colordepths are the important ones here, not the refresh!?!

I know that for the older cards 32bit colordepths are mostly not supported in the VESA bios..

Since the desktop is used in 32bit because otherwise no acc yet, a decent fallback would be 16bit mode VESA during boot.

I think you now have all the info I have here. :-)

Changed 8 years ago by Fredrik Holmqvist

Attachment: vesa_edi_wip.patch added

comment:3 Changed 8 years ago by Fredrik Holmqvist

Cc: fredrik.holmqvist@… added

You can test if this patch makes any difference. It's a bit of duplication of what the platform code does on init, but it might be useful. It might need to filter the initial list compared to the monitor mode though.

comment:4 Changed 8 years ago by rudolfc


I've got extra information: it turns out that the 32bit mode is available, but only for DVI connected screens. On a VGA connected screen the screen turns off.

I am hoping that the VESA definition has info on colordepths supported for the modes, and maybe also have info on the connection type, so that Haiku's kernel can take that into account.

Another option would be checking the modesetting status reported by the VESA BIOS, and on failure fallback to a lower mode. If such a status bit is defined that is..




comment:5 Changed 8 years ago by rudolfc

Additional info: same error is there on NV28, GF4Ti, ID0x0281. Port2 has a less good DAC than port 1, so ort2 can do VESA1280x1024x32 only on DVI connections.. 16bit mode works though. (no icons screen in 32bit.)



comment:6 Changed 8 years ago by rudolfc

More additional info: The same behaviour applies to NV11 and NV15 (GF2MX and GF2Ti): they say they support VESA 1280x1024x16 and x8:, only the 8bit mode actually works. 16bit shutsoff the screen. The strange thing is that on these cards only a VGA connected screen can be used, no DVI. Is the displayed failsave modelist in the bootmanager actually correct or is it 'off by one'? (just ventilating my thoughts here..)



comment:7 Changed 8 years ago by rudolfc


I could get my hands on a NV25 (GF4Ti 4600). It's got the same problem: 1280x1024x32 only works on DVI on the DVI capable port, but not on analog VGA on the same port. 16bit mode works though. On the VGA-only port 32bit mode works OK as well. 32bit mode also fails if two screens are connected.. and it doesn't matter if the DVI port one is a DVI or VGA version.

Looks like 32bit VESA mode (at least 1280x1024) is a troublesome one for nVidia cards?!?



comment:8 Changed 8 years ago by rudolfc

Hi there,

Just tested on the NV28 without nvidia driver. It turns out the kernel fails to set 1280x1024x32 bit mode, but the vesa accelerant does this correctly.

My guess would now be there's a fault in the kernel setting the mode. I'll try to investigate at some point.

kernel reports: KERN: crtc: h 1328/1440/1688, v 1025/1028/1066, pixel clock 108000000, refresh 6064

This modeline is the native one reported via EDID, though the refresh of 6064 seems strange. (should be 60Hz)



comment:9 Changed 8 years ago by Rob Judd

See also #3689

comment:10 Changed 8 years ago by rudolfc

More info (to self):

On NV34 it has become clear that after a failed modeswitch the pixelPLL isn't programmed (at least). Probably it's therefore not selected either. Which in turn means the card was setup for an old (pre) VGA style mode with fixed frequency setting. It's highly unlikely that any 'modern' VESA mode would be programmed without using the pixelPLL to determine the screen's refreshrate.


comment:11 Changed 8 years ago by axeld

Component: - GeneralSystem/Boot Loader

Is there still a problem with this?

And when you say "the kernel fails to set a mode" do you mean the boot loader by any chance?

comment:12 Changed 8 years ago by rudolfc

Hi Axel,

I have to check again to see if this still is a problem. I expect so since noone really looked yet (myself included I'm afraid).

I don't know which component of Haiku exactly is responsible for setting the gfx mode during boot, at the moment the splash screen is going to be displayed: but it fails at that exact moment.

This means the splash screens with the icons is never displayed. Instead the monitor switches off. On most systems it will come on again as soon as the nvidia gfx driver kicks in and sets its first mode. But not on all cards: the init/setup on some cards is messed up apparantly due to the failed call in such a way the nvidia driver is not able to restore it to a working state.

I'll retest asap to see if this problem (failed setmode during boot) is still existing.



comment:13 Changed 8 years ago by rudolfc



about the NV34 pixelPLL is probably bogus: it turned out later on I had a fault in the driver making it show wrong info in the log.



comment:14 Changed 8 years ago by rudolfc

Hi again Axel,

I can now confirm the problem still exists. It hasn't changed. tested hrev33027 from alpha branch (including the latest nvidia driver now in there). 16 bit depth is much safer to use in vesa mode by default upon startup to show the icons screen, at least on nvidia cards.

I hope we can nail this one day though.



comment:15 Changed 8 years ago by rudolfc


I now also confirmed this problem on a Matrox G450 PCI, using the VGA connector. 1280x1024x32 fails, 16 bit mode is OK. The driver is able to restore the card to work, so the desktop correctly comes up in 32bit color.

So: only the booticons screen is missing, monitors powers off with 'no signal' message.


comment:16 Changed 8 years ago by Matthias Rampke

I still have this error (or a similar one?) on hrev33939. When I set the resolution to 1680x1050x32@60Hz (my panel's native) the screen blanks and complains about invalid parameters (75kHz horizontal, 60Hz vertical). The desktop then comes on normally.

The video card is

device Display controller (VGA compatible controller, VGA controller) [3|0|0]

vendor 10de: nVidia Corporation device 0326: NV34 [GeForce FX 5500]

The display is a LG 2242 22".

and the screen is connected via VGA (there is also a DVI connector on the card).

comment:17 Changed 8 years ago by Matthias Rampke

Cc: matthias.rampke@… added

It works when using DVI. (Same card, same display)

comment:18 Changed 6 years ago by scottmc

Blocking: 7662 added

comment:19 Changed 6 months ago by axeld

Owner: changed from axeld to Nobody
Status: newassigned
Note: See TracTickets for help on using tickets.