Opened 16 years ago
Last modified 5 years 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/BIOS | Version: | R1/pre-alpha1 |
Keywords: | Cc: | Rudolf.Cornelissen@…, fredrik.holmqvist@…, matthias.rampke@… | |
Blocked By: | #7662 | Blocking: | |
Platform: | All |
Description
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)
Change History (22)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Cc: | 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. :-)
by , 16 years ago
Attachment: | vesa_edi_wip.patch added |
---|
comment:3 by , 16 years ago
Cc: | 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 by , 16 years ago
Hi,
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..
Axel?
Bye!
Rudolf.
comment:5 by , 16 years ago
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.)
Bye!
Rudolf.
comment:6 by , 16 years ago
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..)
Bye!
Rudolf.
comment:7 by , 16 years ago
Hi,
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?!?
Bye!
Rudolf.
comment:8 by , 16 years ago
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)
Bye!
Rudolf.
comment:10 by , 16 years ago
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.
Rudolf.
comment:11 by , 15 years ago
Component: | - General → System/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 by , 15 years ago
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.
Bye!
Rudolf.
comment:13 by , 15 years ago
Update:
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.
Bye!
Rudolf.
comment:14 by , 15 years ago
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.
Bye!
Rudolf.
comment:15 by , 15 years ago
Hi,
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.
Rudolf.
comment:16 by , 15 years ago
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:18 by , 14 years ago
Blocking: | 7662 added |
---|
comment:19 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:20 by , 6 years ago
Blocked By: | 7662 added |
---|---|
Blocking: | 7662 removed |
comment:21 by , 5 years ago
Component: | System/Boot Loader → System/Boot Loader/BIOS |
---|
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..
Rudolf.