NVidia GeForce 6150 (NV44) graphics issues

[vidrep]

hrev50533 x86_64 ASUS A8N-VM CSM motherboard

• display showing horizontal lines during boot sequence (attached IMG_0241.JPG)
• (VGA output) native resolution of monitor (1680x1050) not supported in screen preferences (attached screenshot1.png)
• (VGA output) selecting any higher resolution than 1024x768 results in distorted image
• (DVI output) native resolution of monitor is supported in screen preferences, but Haiku auto selects 1024x768 on first boot. (attached screenshot2.png)
• (DVI output) selecting native monitor resolution (1680x1050) works OK. There are red vertical lines across the desktop. (attached screenshot3.png)

attached syslog_vga attached syslog_dvi attached listdev

[rudolfc]

From the looks of this (the 'lines' in the pictures with the desktop) the card has not enough bandwidth for the DAC/CRTC accessing the graphics ram by default.

The trouble with the native resolution not coming up or not being selectable has something todo with EDID. Possibly your monitor does not report correctly, or possibly the I2C bus wiring for some ports are not known correctly to the driver.

It would be interesting to see the accelerant's own log for this. You can enable full logging via a config file called nvidia.settings. The log will get created in your home folder, something like nv.xxx.0.log (xxx being the /dev/graphics/ name of the driver).

if you can't find the config info you are looking for have a look at my original driver pages here: ​http://rudolfs-place.nl/BeOS/NVdriver/setinst.html#settings

[vidrep]

This NVidia graphics chipset is integrated on the motherboard. Normally this computer serves as my HTPC, so it means pulling it out, swapping HDD and installing Haiku. I'm happy to do it if there's some chance it helps further NVidia graphics support for this chipset. I'll post results as per your instructions within the week.

[rudolfc]

Yes, I suspected as much, the gfx being integrated. That's also a bit of a problem since I cannot get my hands on such a thing..

Anyhow, if you have enough info to use the settings file and fetch the logfile then this at least gives us a bit more info. If for some reason you cannot get it going please install the driver into the non-system way as I also describe on my pages. Since Haiku has got this protection scheme in place I am kind of in trouble fiddling with the os in a way I can easily work on the drivers for instance..

If your monitor is part of the problem then there's a trick way around that using one of the possible settings in the driver. For the memory problem I need to have a new look at the linux opensource drivers to see if I can find a fix there for your type of card. BTW: the type of system memory used on your mainboard, could that have influence? By that I mean: can you select part of it as display memory for the gfx, trough the BIOS? If so, a faster type might just have some influence..

[vidrep]

Is there any way to enable logging with the Nvidia driver that comes with Haiku, or must I use the old driver found on your webpage? I've tried both, but neither creates a log. I've also tried renaming the settings file from nv.config to nvidia.config. Any suggestions?

[rudolfc]

Hi, I just tested it on my fresh installed very recent Haiku hybrid image. Works perfectly. Just create a textfile called nvidia.settings in your ~/config/settings/kernel/drivers/ folder. It needs just one single activated line for you at this moment: logmask 0xffffffff

Reboot, grab the new file created in your home folder called something like: nvidia.10de_0140_010000.0.log And post it here. Thank you :)

[vidrep]

That worked. The log is attached.

[rudolfc]

From the log I see two problems that need to be solved:

1. I2C buses are not found/configured correctly (no EDID readable therefore)
2. CAS RAM access errors, indeed detected by the driver, tuning is needed, but the needed code is unknown.

I'll try to find info in the/a linux project for these problems. Last time I looked (is some time ago indeed..) this was not yet known. I'll get back to you on this. Thanks for the log!

[vidrep]

Thanks for the prompt reply. I'll be returning that computer to HTPC service, but can pull it again for testing once you think you might have a solution in hand. Whatever I can do to help further hardware support for Haiku.

[rudolfc]

We have a general GF 61xx card problem, if I remember correctly,this is a card-type which is integrated on the mainboard of systems. I need such a mainboard to be able to test this card type. Which did not happen yet unfortunately.

The GF61x0 problem is the last remaining item which should be fixed in the existing nVidia Haiku driver.

Related tickets: #2780, #4670, #6292, #12955.

[rudolfc]

For Geforce 6000-6200, notably Nforce 4 and 4xx, but possibly more cards, added detection of a 25Mhz GPU base frequency crystal. This fixes too low refreshrates, wobbly screens, no picture at all, only part of a picture and that kind of trouble.

Fixed in hrev55039.

Closing ticket.

If the problem still exists the ticket can be reopened.

Thanks!

[vidrep]

Not much difference. I'm using a different monitor now which is 1920 x 1080. While booting up, my monitor says "out of range". Only 1024x768 and 1280x1024 work. 1920x1080 is not listed. I have created a new nvidia.settings file (as before) and attached the log.

[rudolfc]

Ah, ok. back to the drawing board. So I see you do have the 25Mhz crystal on that card, and RAM access is now OK as well. The I2C buses aren't found wired, so that's maybe something I can search a solution for still.

Can you do a check for me regarding the PLL? Try set all modes that work, one by one, and make a list with the resolution you selected along with it's requested refreshrate. Try multiple refeshrates per mode. If all is right you can ask your screen via it's menu what resolution and refreshrate it is receiving. Write that along with the set resolution and refresh as well. So this will be a listing of requested resolutions with requested refreshrate, and if the screen sees another resolution this will be noted on the same line, and also on the same line is the refreshrate the screen reports.

This is just a doublecheck (But an important one) to see if the PLLs indeed work OK.. I think it might be handy to also create a fresh logfile when you start with this test: so the log will contain all modes you tried as well: the info in there will tell me for all modes the details of the PLL setup which can help me determine if the limits are correctly adhered to (a bit).

Also, please try some modes your screen should support but won't work. For each not-working mode try a few different refreshrates (i,e 60, 65, 70, 72Hz) If one of these modes works after all please note the exaxt settings requested and reported back by the screen. Also if you get for instance momentary flashes of screen, or wobbling screen or something else make a note of it along with the set mode.

Last but not least: how is your screen connected to the card? analog VGA or DVI?

And do you still have the old effects (horizontal stripes etc you decribed earlier) or are these gone?

Good luck and thanks for any effort you make!

[rudolfc]

Vidrep, I have another request:

Can you dump the VGA bios and upload it here? You can do this with the nvidia driver (dumprom = true in the settings file).

I see there's been a lot of development with the company nvidia in the last years. Unbelievable the kind of docs that are available today! (We need to have the nouveau driver on Haiku ;-)

Seriously, it makes no sense whatsoever to again do all this 'ourselves' since they even have direct support from nvidia these days.

Anyhow, the BIOS might be a valuable source of info with these docs.. (searching for DDC channel info ATM)

[rudolfc]

Update: With this information, and the nouveau sources (DRM), which are based on this info (driver part written by redhat in 2019), I was for the first time ever able to determine the locations of my I2C ports on my laptop with NV34 purely from looking at it's ROM. I see that the setup in the driver is exactly correct indeed for my laptop (and most other cards in practice) concerning the fixed locations I have in there.

If this new information was known back then the driver would have looked a lot different from how it is now (much more Nouveau like).

So, please indeed upload your ROM as I also saw that your specific card type has a bit of a difference here. Let's see if I can locate your buses from the rom.. (for now a manual search for me, but mighty interesting.. ;-)

[vidrep]

I should be able to get to this tomorrow. Is it helpful to gather data from more then one monitor or use different connection methods (DVI, VGA, DP, HDMI)? I still have the monitor that was used when creating the ticket 5 years ago (1680x1050, DVI, VGA, DP) and my new HD monitor (1920x1080, VGA, HDMI).

[rudolfc]

If you could create different logfiles for the different connection methods, and with each method a resolution/refreshrate test, that would be interesting indeed. Also with mutiple types of screens, but all in all that's a lot to create/test.

So dump the rom, and test a screen on VGA and on the other connectors (one by one): we can see if at least one connector has a working DDC channel, and the ROM is interesting for me to know where to poke next so to speak.

[vidrep]

Here's a log with dumprom = true enabled VGA 1280x1024

[vidrep]

Next working resolution is VGA 1024x768 log attached

[vidrep]

Next attached log, I cycled through each listed resolution at 60Hz and then "undo" to return to a known working screen. See attached screenshot

[rudolfc]

Thanks! Can you grab the .rom file from your home folder and upload it here as well? dumprom = true makes the driver create that file: that's my target so to speak ;-)

[rudolfc]

if this file is not there, it's probably 'dumprom true' (without the =)

If you start your system the first lines in the logfile show you the actual settings:

init_common: logmask 0xffffffff, memory 0MB, hardcursor 1, usebios 1, switchhead 0, force_pci 0 init_common: dumprom 0, unhide_fw 0, pgm_panel 0, dma_acc 1, tv_output 0, vga_on_tv 0 init_common: force_sync 0, gpu_clk 0Mhz, ram_clk 0Mhz, force_ws 0, block_acc 0, check_edid

you can see from the .4.log that here the dumprom feature was disabled (dumprom reads 0, not 1).

[vidrep]

My mistake Here's the log and rom for VGA 1024x768 60Hz

[rudolfc]

Thanks for the logs, I looked trhough them. I do have a lot more questions, hope you don't mind. Have a look please and see which ones you can provide an answer for: every bit of info is important and is what I normally look at/for when I have a malfunctioning system in front of me. (you are my eyes)

• You did not add a list of reported back resolutions+refreshrates as the monitor reported. For a few modes that would be enough (need that to verify the programmed settings have the intended effect on your screen).
• Also you did not let me know which modes do, and which modes don't show a picture.
• Are the distortions still the same as when you first created this ticket?
• So you only tested a analog connected screen, always on head2. How is the behaviour with a DVI connected screen for instance? or the analog screen on the other connector (DVI<>VGA adapter i.e.)
• Do actually all modes work, but you only have more distortions on each higer resolution?
• What if you set a resolution that works but has distortions. What happens if you lower or increase the colordepth for that same mode? lower colordepth has less distortions than higher depts in same resolution? or is it all approx. the same?
• If you select a high res startup mode in the bootmenu (-not failsave video mode-): but you have set for instance 1024x768 in the screenprefs before: does the system startup in 1024x768? I would expect so (at least this is how it worked on BeOS, very handy).
• If so: try a few modes and colordepths: are there now (much) less distortions visible on the modes?

Thanks for your efforts!

[rudolfc]

Yet another update.

I processed your BIOS for the I2C/DDC ports. I could trace the specific registers on your card for that this way. I also think I know how this works in the nouveau driver so I can use the knowledge from there now.

I will update the driver with additional specific lowlevel I2C code for your cardtype and activate that in the driver. Once that's done I'll inform you so you can test it. The expectation is that the monitor's EDID will be read correctly, though the displaying artifacts you are also seeing will remain (this is another problem for which I am awaiting feedback from you first for now).

[rudolfc]

Please test hrev55046, as I have setup the I2C code needed for your card so it should (hopefully) work fetching the screen's specs now:

• The screenprefs panel should indicate the screen name, and give the correct resolutions automatically.
• First time bootup should now be in the native resolution AFAIK.

In order for you to see this working correctly you should remove any 'force' options from the nvidia.settings file to let the driver auto decide things.

Please upload a new logfile from this driver and let me know how the driver holds up. It might for instance be that the head detection is reversed in which case I need to do an extra update based on your findings and the logfile.

Thanks!

[vidrep]

It looks like it's working. Screenshot from first boot after update attached. I'll do a few tests later today with different monitors, connections, resolutions etc and report back.

[vidrep]

HP Monitor is now correctly identified, and operates at it's native resolution of 1920x1080 60Hz VGA. Attached is a photo of my monitors display on bootup, showing "Input signal out of range". Also attached are the log and rom.

[vidrep]

Dell monitor is correctly identified (see attached screenshot). However, the native resolution 1680x1050 60Hz VGA is showing distortion (as if about to go out of sync). Eventually the monitor will go to black screen. I have attached a log and rom for this monitor as well.

[vidrep]

Dell monitor now connected using DVI. All listed resolutions working without any noticable distortion. Attached are another log and rom using this connection method.

[rudolfc]

Nice! Thank you again for testing!

A few remarks:

• What happens during Haiku boot (upto/including the last icon) is outside of the Haiku driver. The Haiku driver (accelerant) is started as soon as the icons screen disappears.
• You are running 64bit Haiku, correct? I am going to need to send you a testversion or two where I force singlehead screen mode, as Haiku these days (apparantly) forces dualhead clone mode. This means we cannot determine atm if the conclusions in the driver about head connections are correct.

I'll try to locate the source for Mark Watsons dualhead setup utility which is a better fit for my dualhead drivers than the Haiku prefs panel is: in this utility you can set singlehead mode also explicitly.

• Don't upload any more rom images: they will all be the same since it's the same card you are testing.. ;-)

I would still like some more info:

• So: you run 64bit Haiku, or can you run 32bit haiku as well (simpler for me since my dev system is 32bit atm)
• So DVI connections are now OK. For the analog connections I have some more questions/requests:
• HP monitor: You sent a photo with out of range. You state it turns off after that. Can you resend a photo from this situation as well, but taken when Haiuku is fully loaded? (desktop visible). If the screen is off, disconnect and re-attach it to the same port if possible, might well be it will show the desktop for a few seconds again.
• Dell monitor: you describe what you see instead of uploading a photo. Can you please do that again and make a photo and upload it? Also I am hoping you can tell me what the monitor says about the input mode. there should be a menu in your monitor with the option to show modeinfo.
• I really want to stress to you again that the -monitor's- report about set modes in something I cannot do without.. -only- that piece of info will tell me if the PLL is programmed correctly or not (along with the logfile belonging with that mode)
• If modes are correctly displayed I do not need a photo of that, but, if a mode is displaying with artifacts/trouble, please do upload a photo of that.

Next steps for me:

• come up with testdriver and/or another screen prefs app to set driver modes, once I know if you can run 32bit haiku, or if you only run 64bit
• once I have enough info from the monitors themselves (if they can display a mode, always ask the monitor which mode it is receiving and let me know exactly what it states) I need to have correlation between what the driver thinks it is sending, and what the monitor connected is actually receiving.
• Depending upon the monitor info, revisit PLL programming, probably for discriminator and/or VCO frequency limiting updates.

BTW I am curious: you sent a screenshot taken from the prefs app a few times: I am guessing that at that moment the monitor did not display anything? If so, how did you manage to do this? :-)

[rudolfc]

Matrox/Nvidia driver's native Dualhead setup utililty 32 bit

[rudolfc]

Hmm I am apparantly unable to compile a 64-bit version (I get: undefined reference to `operator new(unsigned long)' when linking. No idea what's wrong..

Anyhow would be cool if you could test this app in singlehead mode (try 'test' button to see if a mode would work, that auto-reverts after 10 secs or so). So it would be nice to ascertain the head order is the same as the DDC/I2C/EDID channel order: we still lack confirmation of that ATM (Since the haiku panel only sets dualhead (clone) modes) currently. )

[vidrep]

I did a series of tests with the Dell P2210. Several of the preset display modes just give me a blank screen. On the ones that did work the monitor agreed with the screen settings, with one exception. When screen setting is set to 640x480@75Hz, the monitor reports 848x480@72Hz. I went through each supported resolution and attached another log for that.

[vidrep]

I just noticed than on line 36 in the log it says: 1680x1680@60Hz (id=179) That should be 1680x1050, which is the native resolution of the monitor. Why the difference?

[vidrep]

I wiped my HDD and created partitions for x86_gcc2 and x86_64. One thing that surprised me, was that both booted to the native resolution of the monitor (1680x1050), whereas previously I only got a black screen at that resolution. I’ll resume testing tomorrow with the dual head setup you provided.

[diver]

Replying to rudolfc:

Hmm I am apparantly unable to compile a 64-bit version (I get: undefined reference to `operator new(unsigned long)' when linking. No idea what's wrong..

Usually linking against libstdc++ fixes that.

[rudolfc]

Matrox/nVidia native screenprefs panel for Haiku, 64bit

[rudolfc]

Super Diver! Thanks!

[rudolfc]

Vidrep,

Will you please tell me exactly which modes did not (or did) work then? As said: I need to crosscheck that against the logfile to find out in which direction to look for the solution :-)

And: if you say that 'the monitor agrees' do you actually mean to tell me that the monitor not only accepts the mode, but it also reports the mode, including refreshrate, correctly? Please confirm.. :-)

The 1680x1680 mode is a thing I see more often from monitors (rectangle mode). No idea why it's there. Anyway: your monitor reports it can do this mode, but we simply do not offer it.

What we do is:

• we have a modelist inside each driver which will be offered for the modes that your monitor is expected to be able to do. The rest is surpressed. There's (if I remember correctly) one exception to this rule:
• the 'extra mode' a monitor reports is added to the modelist explicitly as this is the native mode, and sometimes it has more restrictions (in timing) compared to a standard modeline for the same resolution. Don't know by heart if we actually check these other restrictions, but in practice there's no problem there.

In your case I think/hope/expect that the PLL is still having trouble for certain settings for the pixelclock (and so refreshrate). It might be programmed outside it's workable limits and then it simply fails to output that what's requested and does something else: this can well result in a black screen.

[vidrep]

I have attached a pdf of a spreadsheet I made for the tests. Selected display mode, Horizontal frequency, Vertical frequency and Pixel clock are taken from the Preset Display Modes chart in the Dell P2210 Monitor owners manual. The reported display mode is what the monitor is actually displaying.

Please provide instructions on exactly what I need to do with the Dual Head Setup app provided.

[vidrep]

Attached are a couple of photos of the kind of distortion seen on the screen at certain resolutions.

[vidrep]

Attached is a third photo which shows that the monitor is displaying at 1400x1050, even though the screen preferences is set at 1680x1050. This only occurs on gcc2h. On 64 bit the correct reolution is set, but the screen is distorted (see photo from previous comment).

[rudolfc]

Thank you for the detailed report! I'll dive in again.

• From the combined info you now added I can already confirm that the PLL is programmed correctly as far as reference clock assumptions are concerned, but indeed it's programmed outside acceptable limits with the result that the PLL does not lock (frequency keeps being modulated, sine-wave like, resulting in the waves you see onscreen). I'll see what I can dig up for the VCO and discriminator limits wise.
• the mode not being set according to horizontal specs we have to look at seperately. Would be best if you can set that mode again and clip exactly the belonging piece from the logfile for me, both for 32 and 64 bit Haiku.
• For Dualhead Setup: please try (on one platform is enough) to set a single head mode as mentioned before, and see if you indeed have a working screen. Try modes you already know would probably work OK. Please try a number of modes, just one or two modes would be too limited to more or less come to a trustwurthy conclusion.

Thank you!

[rudolfc]

BTW: for the singlehead modes experiment, please also provide the belonging logfile.

[rudolfc]

Another request: I would love to see the logfile belonging to the PDF file you created. The previous log shows different settings at least on a number of occasions. Still not a good enough correlation this way I fear.. (to check VCO/discr. limiting) Do you still have the log from the PDF test? If it's included in a large log (by now), just upload it anyway..

Thanks!

Update: Hmm, Maybe I should get some sleep first.. I'll first finish the current log anyway, now I can't see what I thought I saw when I wrote above message. Forget about it for now (sorry!)

Update2: Yes: I see why I wrote this message: I saw the picture with shiver @ 1152x768x60Hz: but this entry is missing in the spreadsheet..

[rudolfc]

OK, done checking:

• Please elaborate on the 1152x864 @ 60Hz image (shiver): this entry is missing in the logfile. Please try that mode once more and upload part of the logfile containing that mode (just delete the file, set the mode, and send the resulting small log)
• Please also do this for the 640x480 @ 75Hz: this one is also missing in the logfile.
• Was the logfile created with 32bit Haiku or 64bit Haiku? Would you happen to have a log for the other system during that PDF test as well? I'd love to see that then.

Still no conclusions though from the test: looks like everyting is in order, and the monitor's specs are never violated. Though I am wondering if it thinks there's a violation in the 1280x1024 @75Hz mode (don't know how picky that DELL is). From the log I see that the actually set mode has Htotal=1688, Vtotal=1066, Pixclk=134.6Mhz, hFreq= 79.7kHz and Refresh set=74.8Hz. Monitor says it can do upto 160Mhz, 83kHz and 75Hz.

[rudolfc]

Hi again, another test I'd like you to do: with the analog monitor connected, let the card do a coldstart at boot. This will make the driver execute the startup scripts inside it's BIOS and dump a lot of information about that in the logfile.

• In nvidia.settings, add a line with: 'usebios false' (without the ' thingies).
• remove logfile and reboot.
• if you get a picture: it would be very nice if you could test again the modes that did not work correctly, and all other modes as well and tell me which modes failed.
• When done: upload the logfile here: I'll examine it again. It will (among other things) contain the BIOS advised PLL VCO limits so we can see if I have it very wrong or not for your card as it is in the driver's defaults currently.
• You can now remove the usebios line again, or replace 'false' with 'true' (does the same). A reboot will get you back in the previous state.

Thank you!

[vidrep]

I added the usebios line in nvidia.settings and did a cold boot on 32 bit. I went through each of the resolutions in the spreadsheet. There were two notable differences from last test.

800x600@60Hz did not produce a black screen, but rather a shimmer as in the earlier attahed photos.

1280x1024@75Hz also did not produce a black screen, but instead it flashed on and off with the same shimmer.

I have attached a log for this test (see nvidia.gcc2h.log)

[vidrep]

I have attached a log for 64 bit (nvidia.x86_64.log) As I did for x86_gcc2h, I added the usebios line in nvidia settings, cold boot, and went through the resolutions listed in the spreadsheet. Results were the same as before.

[vidrep]

Attached is a log for singlehead on 64 bit. As before, I went through each of the listed resolutions on the spreadsheet.

[rudolfc]

Thank you, unfortunately it went wrong somehow:

• Did you add 'usebios false'? the logs report usebios true.. Could you doublecheck and retry?
• You did indeed set some singlehead modes. What I was hoping to hear from you is if the modes behave more or less the same as mentioned in the spreadsheet. Or did you see other behaviour? If so, what was different?

Since you now reported that the black screens do sometimes show something we know that we are close to a solution.. I hope you can retry once more?

[vidrep]

Checked nvidia.settings and indeed I had set it to true. Now set to false. Tried all resolutions again. Same results as before. Singlehead mode gives same results as in spreadsheet. Attached latest log for x86_gcc2h and x86_64.

[rudolfc]

OK, I see the BIOS does not have the startup scripts that the driver knows. So, only tell me how singlehead modes behaved next up?

[rudolfc]

For the VCO limits I have collected enough luckily by browsing trough -all- the logs you uploaded: each log shows one entry of the PLL setup it found done by the BIOS. Combined with your mode test reports I think I know what the limits should be approximately now. I will once more check the nouveau driver to see if they did a piece here they did -not- copy from me ;-) and then I'll create a testdriver for you. Do you know how to install a custom driver (so in the non-packaged hierarchy)?

Expected specs distilled from 13 logs:

• VCO range approx 500-1000Mhz
• Discriminator range approx 1.7-12.5Mhz
• Postscaler can do 1,2,4,8,16 and 32. That's more than I currently use.

[vidrep]

I ran another set of tests on 64 bit with singlehead. The shimmering goes away when activating singlehead mode. Unfortunately 1680x1050@60Hz just gave me a black screen this time. Log attached.

[vidrep]

Do you want me to run a similar set of tests on the Dell with DVI? The other HP monitor as well?

[rudolfc]

• So the singlehead modes all work OK except for 1680x1050?
• Well, if you can manage, more tests is still more information here. So, with singlehead modes I mean.

[vidrep]

Single head modes work for all the same resolutions shown in the spreadsheet. What is different is that the shimmering which is evident on 64 bit on most resolutions disappears in singlehead mode. 1680x1050 is hit and miss on 64 bit. When it works it is unstable (lots of shimmering). When tested with singlehead this last time, the screen went black.

[rudolfc]

Checked the singlehead modes from your last uploaded log:

• you reported that the shimmering mode 1152x864 works OK with this. But you tested 65Hz, not 75: which is probably the cause for the difference in results here.
• The 1680x1050 mode has the same settings as with dualhead mode, so is more or less the same in results as well.
• You also tested one more singlehead mode: 800x600 in approx 57-58Hz from the looks of it.

I'll get back to you with a testversion of the driver after checking nouveau I expect.

[vidrep]

Perhaps when we are both working on this we can connect on IRC. I'm on now, if you want me to do any further testing.

[vidrep]

I just retested 800x600 singlehead at different frequencies (64 bit Haiku). 56.3Hz, OK. 56.9Hz, black screen. 60.6Hz, black screen.

[rudolfc]

Thanks! (Sorry, it was bedtime already here). Anyway, just looked at your rom again and the nouveau code. There are too many indirect pointers to pointers to tables for me to really find the specs from the ROM. Finally I just searched for a few dmesg nouveau dumps for NV4E cards and indeed 500-1000Mhz is reported by the BIOS.

• next up: driver update. In a day or two I hope..

[rudolfc]

Hi again, Could you please test the attached 32-bit driver and report if all modes work OK (also upload a new logfile)? install it in the non-packaged folder hierarchy. If you are having trouble doing that, please check my homesite for instructions:

​http://rudolfs-place.nl/BeOS/NVdriver/setinst.html#installation

I cannot build a 64bit version atm so I hope this will suffice.

[vidrep]

Tested the new driver using the Dell P21210 (hrev55064 x86_gcc2h)

Most of the preset display modes are now working without any shimmer.

640x480@60Hz - black screen

640x480@75Hz - 75 Hz refresh rate greyed out (selecting other... causes a crash)

1680x1050@60Hz - display indicates a 1400x1050@60Hz screen resolution

nvidia log and syslog of the crash is attached.

[rudolfc]

Thanks! I'll upload a new version in a few minutes. The crash is probably a fault in the screenprefs app. It cannot handle a non-requested mode apparantly (driver limits settings to be within it's capabilities, but that lies outside of what screenprefs requested. This is something that wasn't a problem on the BeOS).

[rudolfc]

Please test the version 1.15 driver and see if all problems are gone.. Upload log again also please :-)

[vidrep]

Results same as before, with the exception that the screen preferences no longer crashes.

640x480@60Hz, @75Hz - black screen at both refresh rates

1680x1050@60Hz - 1400x1050@60Hz detected by monitor

Log attached

[rudolfc]

x86 nVidia testdriver nr.3 for C51/NV44 chipset - fixed programming extended postscaler

[rudolfc]

Thanks again: please try number 3 for me:

• Check the 640x480 modes. The rest should be the same in behaviour.
• For the 1680x1050 mode please do a seperate test with variing refreshrates. Try the sllider and make very small refreshrate steps (i.e. 0.1Hz) to see where the monitor shuts off (upper and lower limit). Also look at the reported horizontal spec: is there a refreshrate where it is actually reporting 1680x1050? at what rate? (i.e. @ 59.9Hz: as that's reported on the 64bit driver with correct resolution you reported earlier..)
• Please upload the log as well.

[rudolfc]

Oh, please also tell me if the 1680x1050 mode which is reported wrong -does- show the full 1680x1050 pixels (all items onscreen?). Thanks!

[vidrep]

640x480@60Hz - working

640x480@75Hz - monitor reports 848x480@75Hz reolution

1680x1050@60Hz - monitor reports 1400x1050@60Hz

1680x1050@59Hz - working, all items on-screen (monitor reports 1680x1050@59Hz)

Log attached

At 1680x1050 resolution, I started at 60Hz and moving the slider down in .1Hz increments. The monitor does not report 1680x1050 until I get to 59.1Hz.

[rudolfc]

So: when the monitor reports the error: all onscreen also?? (so @ 640x480 @ 75Hz and @1680x1050 @ 60Hz?

[vidrep]

640x480@75Hz and 1680x1050@60Hz all on screen

[vidrep]

The screen preferences list a number of screen resolutions not listed in the preset diplay modes. Do you want these resolutions tested as well?

800x500

1024x640

1280x768

1280x800

1400x1050

1440x900

[rudolfc]

Yes please,

So: It would be nice to know all modes work correctly, that is:

• display stable picture
• display correct refresh on your screen
• display all pixels meant to be onscreen indeed onscreen.

The fact that your monitor is rather picky when it comes to precise modelines is of less importance here, though it would be nice to know exactly where it comes from and have a fix for that. Would you know what this specific type of monitor does on other OSes with different resolutions when you play around with the refresh? Would it also detect something else than is actually sent by the driver?

Another nice thing to retest now would be if you can test all modes on that other analog connected screen. And of course, if that screen would also sometimes show incorrect horizontal resolution information..

This would be a pointer towards:

• indeed picky monitor OR
• still something not entirely right in the driver.

Anyway: looks like we just made another important (and maybe even final) step. Once you complete your testing I will commit this to GIT.

[vidrep]

800x500@60Hz - 848x480@60Hz

1024x640@60Hz - 800x600@60Hz

1280x768@60Hz - 1366x768@60Hz

1280x800@60Hz - 1280x800@60Hz

1400x1050@60Hz - 1400x1050@60Hz

1440x900@60Hz - 1440x900@60Hz

[vidrep]

800x500@75Hz - 640x480@75Hz

1024x640@75Hz - 800x600@75Hz

1280x768@75Hz - 1024x768@75Hz

1280x800@75Hz - 1280x800@75Hz

1400x1050@75Hz - 1400x1050@75Hz

1440x900@75Hz - 1440x900@75Hz

[vidrep]

I connected my other monitor (HP 24fw). All resolutions give a stable picture etc. All of the preset display modes work correctly. The non-preset display modes return resolutions other than that selected. Some examples below:

800x500@60Hz - 31.0kHz 60Hz

1024x640@60Hz - 800x600@60Hz

1152x864@60Hz - 53.8kHz 60Hz

1280x768@60Hz - 47.7kHz 60Hz

1400x1050@60Hz - 1680x1050@60Hz

[rudolfc]

Thank you. In the meantime I also tested an external monitor on my NV34/FX5200Go laptop to see what it would report resolution wise compared to the set mode: I see likewise behaviour as on your monitors.

• Apparantly analog connected screens are not that good in measuring the input signals. Most reliable is refresh, then Vres, then Hres. Vres and Hres are sometimes reported wrong. Some screens just report the line-rate and picture refreshrate instead of a resolution if it's not a preset mode (I see resolution errors and linerates here as well on a Samsung screen).
• The driver is now working within operational specs on your system.

I will push the modifications to the driver to the Haiku sourcetree and close this ticket again. There are no more reported problems by you, correct me if I'm wrong. Thank you for your indispensable help!

[vidrep]

I have a third (ViewSonic) monitor I could test as well. I guess it wouldn’t hurt...just in case. I also have a few older nVidia cards (some AGP) that might we worth a look.

[rudolfc]

Fixed in hrev55069. Closing Ticket. Maybe finally doublecheck the 64-bit Haiku version, though should be Ok as well.

[rudolfc]

Hi, go ahead I'd say. If you encounter trouble on other cards, that would mean a new ticket though ;-) BTW You can always send me a private message via the Haiku community site, or indeed we could meet on vision or so.