[nvidia] Video problems

[VinDuv]

Configuration : real hardware, laptop with an (old) NVIDIA Geforce2 Go and a 1400x1050 internal LCD screen. I tested with hrev27057. After the boot, the screen goes completely unreadable (see the attached screenshot). It works fine in fail-safe video mode.

[VinDuv]

syslog

[VinDuv]

Screenshot

[rudolfc]

Hi there,

Is this bug still current? If so, could you test with an external screen? Could you add a logfile from the accelerant to the bug? Todo so, you need to install nvidia.settings in home/config/settings/kernel/drivers, enable the full logging line and reboot.

Did this bug also exist on BeOS if you used the Haiku driver?

It looks llike horizontal sync is lost btw, which might be related to the modeline being active (or needed) for your internal panel.

Bye!

Rudolf.

[VinDuv]

Replying to rudolfc:

Is this bug still current?

Yes, it still exists in hrev29464.

If so, could you test with an external screen?

Just tested with a CRT monitor, with the internal display disabled. After the rocket icon lights up, the image waves back and forth horizontally for a second, then the monitor very briefly displays "Out of scan range" and goes to sleep mode. Works fine in VESA mode.

Could you add a logfile from the accelerant to the bug? Todo so, you need to install nvidia.settings in home/config/settings/kernel/drivers, enable the full logging line and reboot.

Log attached. I was not sure about what logmask to use, so I used 0xffffffff, is that correct ?

Did this bug also exist on BeOS if you used the Haiku driver?

I don't use the Haiku driver on BeOS, but I could give it a try if you want (I have R5 installed).

[rudolfc]

Hi again,

Thanks. The logfile settings are correct, the mask you selected logs all events. The file reports that the internal panel is being used by the driver. If this log is from the attempt with panel off and VGA monitor connected that could explain the shutting off of the VGA monitor. In this case, you could also modify another setting in the nvidia.settings file to look like this:

switchhead true

switchhead will force the driver to use the VGA screen in your case if all is right. I'm curious if the driver would work with that setting.

For R5 testing: Yes, I'm interested in the results since I think I remember seeing another laptop working correctly with R5/dano, but not with Haiku with the internal panel. If you try that, I'd advice you to install the driver in the home directory structure so that you can reboot using failsafe option "disable user add-ons" to load using the orignal R5 driver instead of the Haiku driver.

Thanks for your time and efforts!

Rudolf.

[VinDuv]

Hi Rudolf,

The internal display was used when I activated logging. I made some other tests with and without the CRT connected (see the attached log).
The driver does not work in BeOS R5 either (same behavior)
But the good news is that the driver is at least partially working !

What I have done :

1. Set switchhead to true, reboot with the external CRT => image OK (on external)
   
2. Reboot => still OK
   
3. Change resolution to the highest provided, 1400x1050 (it is not a standard resolution for the external screen, but it is the native resolution of the internal one - I guess this is a side effect of switchhead) => OK
   
4. Reboot => Not OK, freeze after the rocket icon, with the internal, the external or both screens enabled (even KDL wasn't showing)
   
5. Reboot with switchhead disabled => OK on internal [[BR]]
6. Changing resolution => Not OK (same behavior as before)

So it seems that only the native resolution works properly on the internal screen.

[VinDuv]

nVidia log with different screen configs

[rudolfc]

Hi there,

From the looks of it, you depend on a VESA modeswitch before the driver kicks in. This modeswitch needs to set the your native resolution as you pointed out.

Haiku's Screen preflet has a nasty side effect (as I just encountered) compared to the BeOS version: it overwrites your VESA settings file after exiting this app. If you would want to test with a lower resolution on the panel after bootup: you probably need to set (for instance) 1024x768 with Screen: exit it, then modify the vesa file to read 1400x1050 Again, then do the reboot.

Would that work? (or, probably in other words: if you switch down from 1400x1050 on your correctly working internal panel using 'Screen': does dat immediately kill your display, or does it only kill your display after the next boot-up?

Bye!

Rudolf.

[rudolfc]

I just tested such a thing here: and it turns out that that vesa settings file might not even be written back to disk promptly. I needed a reboot to find that the file was overwritten by Screen, even though I checked it to be correct *after* exiting that app!

So, double-check every step on the way please...

Bye!

Rudolf.

[VinDuv]

Replying to rudolfc:

Would that work? (or, probably in other words: if you switch down from 1400x1050 on your correctly working internal panel using 'Screen': does dat immediately kill your display, or does it only kill your display after the next boot-up?

Yes, changing the resolution immediately results in a garbled screen. When the Screens preferences restore the original resolution, the image goes back.

[rudolfc]

Could you modify nvidia.settings to disable the force_ws option? The aspect ratio mentioned in your logfile is wrong (1.6 instead of 1.33). Maybe panel scaling messes up... Sorry I did not see that before. force_ws is enabled by default these days since a lot of monitors are ws, but maybe that's a problem on some (your) system???

Please test and upload a new logfile with that setting changed.. Thanks!

Rudolf.

[VinDuv]

Replying to rudolfc:

Could you modify nvidia.settings to disable the force_ws option? The aspect ratio mentioned in your logfile is wrong (1.6 instead of 1.33). Maybe panel scaling messes up...

That was it ! It works now :-) Thanks !

[VinDuv]

nVidia log without force_ws

[rudolfc]

Hi!

Well, that's good news indeed! Meanwhile I am implementing DDC/EDID support for the driver, which requires a lot of card-testing over here.

The first thing I'll activate in the driver is detecting all screen's aspect ratio so we can disable the force_ws setting again by default. If a user connects only WS screens before boot then WS-modes will automatically be enabled.

If that's in place you don't need to manually tweak the settings file anymore.

Until that time this tweak remains needed. I'll let you know when the driver is 'fixed'.

Bye!

Rudolf.

[VinDuv]

Since force_ws has been disabled by default in hrev31213, making the display work without the settings file, I guess this bug can be closed ;-)

[rudolfc]

Thanks VinDuv,

You're right :)

Closing..