Opened 16 years ago

Closed 15 years ago

#2643 closed bug (fixed)

Black screen when DVI connected (non-native resolution)

Reported by: andreasf Owned by: rudolfc
Priority: normal Milestone: R1
Component: Drivers/Graphics/nVidia Version: R1/pre-alpha1
Keywords: Cc: planche2k@…
Blocked By: Blocking: #1845
Platform: x86

Description

When I connect either both VGA and DVI, or just DVI to the following graphics card:

device Unclassified device (Non-VGA unclassified device) [0|0|0]
  vendor 10de: nVidia Corporation
  device 0343: NV36 [GeForce FX 5700LE]

the initial splash screen is displayed nicely on the screen(s) but I then get a black screen (on both screens if both connected).

This appears to be a problem with the Nvidia driver. With VESA (fail-safe mode in boot menu) I get the desktop displayed on both screens.

Attachments (6)

nvidia.dvi-nonworking (75.1 KB ) - added by JeremyVisser 15 years ago.
nvidia.dvi-working (75.0 KB ) - added by JeremyVisser 15 years ago.
nvidia.diff (4.1 KB ) - added by JeremyVisser 15 years ago.
nvidia.10de_0343_010000.0_vga+svhs.log (100.4 KB ) - added by andreasf 15 years ago.
log of VGA+SVHS attached
nvidia.10de_0343_010000.0_multiple.log (453.5 KB ) - added by andreasf 15 years ago.
log of multiple tries, first DVI+VGA+SVHS then VGA+SVHS (failed) then VGA+SVHS (after cold start)
diff_vga_dvi.diff (119.2 KB ) - added by andreasf 15 years ago.
diff of VGA+SVHS vs. DVI+VGA+SVHS

Download all attachments as: .zip

Change History (44)

comment:1 by luroh, 16 years ago

I have the exact same symptom (the card has 2 x DVI, no VGA).

$ lspci -nn | grep VGA

02:00.0 VGA compatible controller [0300]: nVidia Corporation G71 [GeForce 7900 GT/GTO] [10de:0291] (rev a1)

comment:2 by luroh, 16 years ago

Ugh, formatting error, should be:

02:00.0 VGA compatible controller [0300]: nVidia Corporation G71 [GeForce 7900 GT/GTO] [10de:0291] (rev a1)

comment:3 by luroh, 16 years ago

Update: still with us, unfortunately not fixed by hrev27390.

comment:4 by anevilyak, 15 years ago

Owner: changed from axeld to rudolfc

nVidia driver should be Rudolf's territory I believe, reassigning. (Please reassign back if I'm incorrect here).

comment:5 by rudolfc, 15 years ago

Hi there,

Is this bug still existing? If so, could you add a logfile from the accelerant here? To do so, copy nvidia.settings to home/config/settings/kernel/drivers, enable full logging in this file, and reboot.

Thanks for any update.

Rudolf.

in reply to:  5 comment:6 by andreasf, 15 years ago

Hi,

Replying to rudolfc:

Is this bug still existing?

It still is, unfortunately.

If so, could you add a logfile from the accelerant here? To do so, copy nvidia.settings to home/config/settings/kernel/drivers, enable full logging in this file, and reboot.

Where do I get that file from? It doesn't appear to be in trunk/data/settings/.

And where does this log to? Does it log to serial or to a file? Obviously when the screen goes black I can't shutdown Haiku properly so BFS damage would seem likely.

comment:7 by JeremyVisser, 15 years ago

I can confirm this bug too. NVIDIA GeForce 7600GT here.

My monitor normally runs over DVI. The boot splash screen showed fine at 1280x1024@60, but at the point where the desktop shows, it was a blank screen. The monitor stayed on at the 1280x1024 mode, but just blank.

I then connected the monitor to the VGA port on the video card, and it now shows fine. (Albeit more grainy due to the nature of VGA.)

comment:8 by JeremyVisser, 15 years ago

Andreas, I found the nvidia.settings file -- it's in the SVN repository.

comment:9 by JeremyVisser, 15 years ago

I enabled logging, booted up with VGA, then disconnected VGA and connected DVI, and booted up, and my DVI display worked! I suspect this is because when I first booted up with VGA, I went to Preferences → Screen and set my video mode. This seems to have fixed DVI.

How do I "un-set" my video configuration to simulate a fresh install in order to reproduce the black screen symptoms with my DVI?

comment:10 by rudolfc, 15 years ago

Hi,

@andreasf: Hmm, you could very well be right (saw it here on R5 often as well). However, if the system boots up (without vision), you could blindly shut it down normally. You probably need to find a way to navigate to the terminal window by keyboard, and type: shutdown -r

I hope you succeed. Maybe you can try the same sort of trick as Jeremy did BTW using an analog monitor: remove the DVI connected screen and bootup only with the analog connected screen. You can even try both DVI ports on two boots, if they support analog connections (DVI-A with DVI->VGA adaptor)

@JeremyVisser:

Interesting!

If all is right, removing the app server Settings file called "workspaces" removes the programmed resolution I think. You'll find that file in home/config/settings/system/app_server.

Please let me know if I am right (I think it's different from R5/dano here??)

Also, please add a logfile with two boots if you succeed with the above trick: one for the blackscreen DVI, and one for the working DVI.

Thanks!

Rudolf.

comment:11 by JeremyVisser, 15 years ago

Thanks for the info. I'll get back to you when I have access to my machine in 6 or 7 hours time. Yesterday I already did a diff between the working VGA and working DVI logs -- all that's remaining is to collect the non-working DVI logs.

comment:12 by JeremyVisser, 15 years ago

I've added two logs: one of the non-working DVI, and one of the working DVI (which I got working by booting up in VGA, setting the video mode, and rebooting in DVI). Also attached is a diff between the two. Unfortunately, I can't see anything obvious that might be causing the problem in the diff, but my eyes are untrained.

comment:13 by rudolfc, 15 years ago

Thanks Jeremy,

These logs are very interesting. The diffs have to do with the panel being programmed/powered or not I suspect...

Anyhow, Some info at the beginning of the log is missing: after accelerant startup the first message is something like:

init_common: logmask 0xffffffff, memory 0MB, hardcursor 1, usebios 1, switchhead 0, force_pci 0

Did you use logmask 0xffffffff ? If not, could you do that still? And, did you create both logfiles while an analog CRT was connected as well, or did you remove them before Haiku boot for the log creation? (just for my info/correct understanding of the logs..)

Thanks!

Rudolf.

comment:14 by JeremyVisser, 15 years ago

I used the mask 0xfffffff2. I'll re-do them with 0xffffffff.

I don't have a CRT -- my LCD monitor has both VGA and DVI inputs, and my video card has both VGA and DVI outputs. Both logs were generated with the VGA unplugged -- the only difference was the mode that was set in the Screen preferences.

by JeremyVisser, 15 years ago

Attachment: nvidia.dvi-nonworking added

by JeremyVisser, 15 years ago

Attachment: nvidia.dvi-working added

by JeremyVisser, 15 years ago

Attachment: nvidia.diff added

comment:15 by JeremyVisser, 15 years ago

I've attached some fresh logs created with a logmask of 0xffffffff. Hopefully they should be sufficient. If you want a log of me booting up with VGA instead of DVI (with or without mode preferences set), I'd be happy to do that as well.

comment:16 by andreasf, 15 years ago

Booting up with VGA and then rebooting with DVI does not work here.

My graphics card has three connectors - VGA, S-VHS and DVI. When connecting both VGA and S-VHS, it just uses VGA for the desktop. The problem occurs only when DVI is connected, whether VGA is connected or not. There is no obvious error indication in the serial output.

I tried changing the usebios setting, but no difference.

Will try the logmask next, now that Trac is up again.

by andreasf, 15 years ago

log of VGA+SVHS attached

by andreasf, 15 years ago

log of multiple tries, first DVI+VGA+SVHS then VGA+SVHS (failed) then VGA+SVHS (after cold start)

comment:17 by andreasf, 15 years ago

I've attached some logs with the requested logmask. Unfortunately blindly using Terminal didn't work for me, so I hope I waited long enough for the log to be sync'ed. Obviously I couldn't copy/move the log before rebooting either.

In my case, it's three different devices - a 4:3 15" LCD (1024x768 max) on VGA, a 4:3 17" LCD (1280x1024 max) on DVI and a beamer on S-VHS.

comment:18 by andreasf, 15 years ago

Okay, so my long log contains five different logs actually. The first two just differ in the checksum and boot time. The third one has major differences, I'll attach the diff next. Interestingly, the fourth one differs from the third only by boot time despite DVI being disconnected, so it seems some data was not cleared during hot restart. The fifth one is the successful cold boot and as such differs from the original one only by checksum and boot time again.

by andreasf, 15 years ago

Attachment: diff_vga_dvi.diff added

diff of VGA+SVHS vs. DVI+VGA+SVHS

in reply to:  16 ; comment:19 by JeremyVisser, 15 years ago

Replying to andreasf:

Booting up with VGA and then rebooting with DVI does not work here.

While you were booted up in VGA, did you go to Preferences → Screens and choose a new video mode to use? If I didn't do that, then DVI wouldn't work for me either.

If you did the above, I suspect it didn't work because you used different monitors, and Haiku was resetting the mode settings because it detected different display IDs. I have a HP L1740 monitor that has has both DVI and VGA inputs, so it wouldn't reset the display settings if I switch from VGA to DVI.

I found that if I used a live USB copy of Haiku and switched it between a few computers, each computer would remember my unique preferred screen resolution for each screen, so that seems to confirm my suspicions.

in reply to:  19 comment:20 by andreasf, 15 years ago

Replying to JeremyVisser:

Replying to andreasf:

Booting up with VGA and then rebooting with DVI does not work here.

While you were booted up in VGA, did you go to Preferences → Screens and choose a new video mode to use?

No, I didn't. But trying it, that works neither for my above setup nor for my Eizo FlexScan L550 with different connectors. That is, I changed refresh rate and color depth, applied that to all workspaces and did a shutdown, then replugged the connectors and booted again.

comment:21 by luroh, 15 years ago

Dupe of #1845?

comment:22 by JeremyVisser, 15 years ago

Possibly. #1845 doesn't contain enough information to give a definite yes or no. It doesn't mention anything about DVI, which is what this bug is all about.

Plus, this bug has all the logs and things attached. If anything, #1845 should be marked as a dupe of this bug (regardless of chronological order).

comment:23 by anevilyak, 15 years ago

Blocking: 1845 added

(In #1845) Marking as duplicate of #2643 as that ticket has more information.

comment:24 by rudolfc, 15 years ago

Hi again, and sorry for the delays from here.. :-/

-> @ AndreasF: I just looked over your logfiles. The file with 5 attempts doesn't seem strange to me. The last boot does not differ from the first two AFAICT in a sense that explains the VGA screen only working in the last boot.

The DFP panel boot seems normal too: there's one 'anomaly': you specified in nvidia.settings not to program the panel. In some cases that could mean you won't get a picture on the panel (and in some cases it's vice versa).

About (un)plugging DFP panels (or other screens) during power-up time: the driver does *not* support hot-plugging. if it works for someone, then he/she's just lucky.

While in theory it can be done for VGA and TV screens, this is not the case for DVI/HDMI panels since the driver isn't capable of programming the specific link hardware (yet?). This means the driver has to rely on the pre-programming the VGA BIOS does during POST. Hence: no hot-plugging (and thus no pluggin during soft/warm restart).

Now that you know this, I have some questions:

  • did the DVI panel work or not? Did you try without the nvidia.settings option to not program the panel too?
  • so VGA sometimes works, and sometimes it does not? Did you test this with *only* the VGA screen connected? (remove the TVout and DVI/HDMI cables before testing, and make sure you always use the same port for the VGA screen: since one port may work, while the other may not..)

If you did not do testing this way, it's best you start clean to get real clear info.

A hint: try with a vesa settings file in place, set at the resolution/colordepth you use in haiku. Does that solve the problem?

-> @ JeremyVisser: Hi, could you post complete logs for me as requested before? Your system might suffer from another problem.. Good hint BTW about Haiku remembering the setting for each screen (system). I did not know/suspect that yet.

I'm afraid Haiku is 'strange' in more ways compared to BeOS: For instance, I hear Haiku double bufferes the screen. Which means it sets a double-height virtual resolution for every mode you use. On cards with low amounts of mem this could mean not all resolutions are avaible (theoretical problem these days I guess though :)

Another thing: Haiku issues a VESA modecall at the very beginning of the boot. This is not done by BeOS *unless* the user specifically requests it (via vesa settings file). I think haiku sets a mode it wants to set (the 'native' mode of a DVI panel for instance). This is not depending on the vesa settings file. If this file is there as well, I can imagine (don't know unfortunately) Haiku issuing a second call. Only after those calls are done the actual display driver comes into play.

(un)fortunately, this means that the state the hardware is in, is not that simple anymore and the driver apparantly makes wrong assumtions therefore. I (we) need to find out what's apparantly missing (if so..?!?) to make this driver work better on Haiku. Haiku is nolonger comparable to BeOS in this fashion. And on BeOS the driver might work perfectly for your hardware.

Bye!

Rudolf.

in reply to:  24 comment:25 by andreasf, 15 years ago

Cc: planche2k@… added

Hi Rudolf,

Unfortunately for some reason I did not receive a mail notification for your comment, so I apologize for my late reply as well. I had noticed your recent commits and re-tried a couple of times, including DVI connected before cold booting, then building Haiku under Linux and rebooting into Haiku, without luck.

I had this line in my UserBuildConfig:

AddFilesToHaikuImage home config settings kernel drivers : $(HAIKU_TOP)/src/add-ons/kernel/drivers/graphics/nvidia/nvidia.settings ;

Your settings file was unmodified - not sure whether that "programs the panel" or not. VGA-only does work fine with that file in place.

My GeForce FX 5700LE (Leadtek LR2984) card has three different connectors: VGA, S-VHS and DVI. So I cannot connect the non-working DVI connector to the VGA connector or vice versa, they were always identical. (Connecting the DVI monitor via VGA connector did work, the monitor also works on other machines via DVI.)

The DVI panel, when connected, was powered but black whereas the VGA screen went black and powered off after a while. That is, after the rocket icon lighted up. Before, they showed the same image. This is reproducible, VGA never worked when DVI is connected.

Where do I get a vesa settings file, where do I put it?

Thanks for investigating,

Andreas

in reply to:  24 comment:26 by andreasf, 15 years ago

I just tried with this patch

diff --git a/src/add-ons/kernel/drivers/graphics/nvidia/nvidia.settings b/src/add-ons/kernel/drivers/graphics/nvidia/nvidia.settings
index 8474fd7..35482a2 100644
--- a/src/add-ons/kernel/drivers/graphics/nvidia/nvidia.settings
+++ b/src/add-ons/kernel/drivers/graphics/nvidia/nvidia.settings
@@ -26,7 +26,7 @@ block_acc	false		# if true disables the acceleration engine
 
 # WARNING: tweak alert! modify stuff below on your own risk...
 unhide_fw	false		# if true 'unhide' cards AGP fastwrite support on cards that hide it
-pgm_panel	false		# if false don't program DVI and laptop panel pixelclocks (refreshrates)
+pgm_panel	true		# if false don't program DVI and laptop panel pixelclocks (refreshrates)
 vga_on_tv	false		# if true enables VGA output on the head outputting to TV
 #gpu_clk	150			# in Mhz, (tries to) override default GPU clockspeed (be carefull!!!)
 #ram_clk	150			# in Mhz, (tries to) override default cardRAM clockspeed (be carefull!!!)

and it did not make a change.

I found an Apple DVI-to-VGA converter and was able to boot Haiku with two VGA screens connected this way. The desktop image was displayed on the original VGA screen, the other one went black, with no option to mirror or extend the desktop. Am I correct to assume that it's simply not yet implemented in Haiku?

If I connect via the DVI-to-VGA adapter only, the desktop is displayed correctly on that screen.

So no issue with the connector apparently, more a DVI-specific issue here, at hrev30978.

comment:27 by andreasf, 15 years ago

When I connected the other monitor via VGA it runs at 1024x768 while its native resolution is 1280x1024.

If on first boot with that monitor I select fail-safe video mode, in Screen preferences set the resolution to 1280x1024 and reboot, then suddenly the DVI screen works as expected!

So the issue is the combination of DVI and a non-native resolution.

Unfortunately I don't have a very usable workaround yet...

I tried creating a simple /boot/home/config/settings/kernel/drivers/vesa file

mode 1280 1024 32

to set this resolution for each build, but it doesn't have the same effect as manually setting the resolution in VESA mode. Neither has unzipping the /boot/home/config/Screen_data file.

in reply to:  27 ; comment:28 by andreasf, 15 years ago

The key to making it work was (unzipping) the /boot/home/config/settings/system/app_server/workspaces file!

It now shows the correct resolution on first boot with DVI.

I'll see which attempts from the above (nvidia.settings, vesa, Screen_data) I can drop while still making it work.

in reply to:  28 comment:29 by andreasf, 15 years ago

Summary: Black screen when DVI connectedBlack screen when DVI connected (non-native resolution)

Long story short: As a workaround it's sufficient to provide the workspaces settings file. The absence of the vesa file makes the splash screen display at 1024x768, but the desktop comes up okay at 1280x1024. The pgm_panel option and Screen_data file are irrelevant. Sorry for the monologue.

The Nvidia driver not supporting non-native resolution over DVI is still unsolved, so please keep the bug open, unless there is a duplicate already. Thanks.

comment:30 by rudolfc, 15 years ago

Hi again,

Thanks for your experiments! I've located two issues we have currently. -- One is described in ticket #3850 (don't set non existing VESA modes). While I am yet unsure if the modes are non-existing, or if we are dealing with a nVidia BIOS problem, it's clear that using 8 or 16 bit modes seems always OK, while 32bit mode splashscreens don't display on a number of cards. On some cards because of this failure the desktop won't come up either, since the card's state is messed up and the driver can't correct that currently (in most cases).

-- The second problem is that of the 'force widescreen' setting. If you have a non-widescreen monitor, you should set that option to off. otherwise especially DVI connected screens are fed with incorrect setup modelines unless driver in their native resolution.

I'm working on this bug by setting up EDID/DDC to get actual specs from the connected screens to better autodetect where the picture needs to go and if we have ws or not.

-- With these two bugs known to you, can you retest and see if we hit the 'jackpot'?

Thanks!

Rudolf.

BTW: The driver supports dualhead and TVout (TVout only for cards with brooktree or conexant tv encoder). On BeOS you can issue these modes with the app dualhead setup (bebits). Unfortunately this app doesn't work on Haiku. I think that BeOS is being phased out these days, so I should probably rewrite the interface to work with the haiku prefs app (which in theory can handle these things too, and that works on ATI cards).

in reply to:  30 comment:31 by andreasf, 15 years ago

Hi,

Bingo! I just confirmed it does work with force_ws false - it then shows the desktop fine at 1024x768@32bpp, as seen for VGA. This seems independent of the pgm_panel option. Still at hrev30980.

So, I was curious and checked on a widescreen DVI monitor: there, it worked just fine without nvidia.settings file, defaulting to 1024x768 non-native resolution. I then set the resolution to the native 1680x1050, cold-rebooted with the 1280x1024 monitor connected, and then it did come up okay at 1280x1024 without a settings file. (The only thing unexpected was some odd 83.8 Hz refresh rate according to the Screen preflet.)

For comparison, after exchanging my 1280x1024 monitor against a 1024x768 one on VGA, the latter still tried to display at 1280x1024 and needed to be set down to its native resolution through Screen preferences.

Regarding #3850, it does show the splash screen in nice colours, although I can't say for sure whether it's 32bpp or 16bpp.

comment:32 by JeremyVisser, 15 years ago

Sorry - I didn't get notification e-mails either, as they were marked as spam.

I don't understand what's going on anymore -- it's way over my head. I'm still willing to test, though.

comment:33 by rudolfc, 15 years ago

Hi there Jeremy. I've had the same spamming problem here on gmail..

Anyhow, can you test what andreasf just tested with force_ws false? Looking again at the logfiles you provided you have the same problem..

disabling the force_ws option should solve your thing. The first non-working log tried a desktop of 1024x768, the second 1280x1024 which is the native resolution of your screen. Since your screen isn't widescreen, other resolutions won't work since in those other resolutions the driver tries to scale the modes up to your monitor's native modeline, assuming it's a widescreen type. Hence: trouble.

Keep me posted!

Thanks :-)

Rudolf.

comment:34 by JeremyVisser, 15 years ago

Actually, I no longer have that 1280x1024 monitor. I now have a shiny new 1920x1080 (which, I believe, is 16:9) monitor -- will it still have the same symptoms, or if I understand you correctly, are widescreen monitors exempt from this problem?

comment:35 by rudolfc, 15 years ago

Hi Jeremy,

Yes, they should be. But I don't mind if you confirm that.. ;-)

Bye!

Rudolf.

comment:36 by rudolfc, 15 years ago

Hi there,

Since Haiku R31213 the nVidia driver uses DDC/EDID to detect ws screens that are connected using a VGA cable. Also the force_ws setting is reset to being false by default.

If all is right the problems should be gone now and the settings file is nolonger needed.

Can you confirm that please? If the problem is fixed I'll close this ticket.

Thanks!

Rudolf.

in reply to:  36 comment:37 by andreasf, 15 years ago

Hi,

I've confirmed it to boot at hrev31290 and hrev31292, without nvidia.settings file. So I suggest you close the ticket as fixed.

Thanks for your help and overall driver efforts!

Andreas

comment:38 by rudolfc, 15 years ago

Resolution: fixed
Status: newclosed

Ok,

Thanks Andreas for testing!

Closing.

Rudolf.

Note: See TracTickets for help on using tickets.