nv7600go notebook chipset results in a black screen

[humdinger]

This is hrev32241.

My notebook has a nvidia 7600 Go chipset. The model should be supported by Haiku's driver, but I can only use fail-safe VESA mode, because else I end up with a black screen after the boot screen.

I tried to set usebios = false, but that didn't changed anything.
Attached is the log.

Maybe you can see what's wrong here, Rudolf.

[humdinger]

log (defaults)

[aldeck]

Same problem here on my laptop (forgot to report), exact same device 10de:0398. VESA works ok.

[humdinger]

I wouldn't have a problem with VESA, if it would use the panel's native resolution 1680x1050. Unfortunately it doesn't and stretches 1280x1024 which makes it all very blurry.

[rudolfc]

Hi,

Can you somehow force haiku to startup in 1680x1050 mode with the driver? Maybe your screen doesn't like 1024x768 mode which apparantly gets set (from the log).

I am curious if it's just the mode or the entire driver that doesn't work..

Bye!

Rudolf

[humdinger]

Hi Rudolf.

The fact that the log is being generated proves that the nvidia driver is doing something. Can I force it into a specific resolution? You tell me. :)
What I will try, is setting the ~/config/settings/kernel/drivers/vesa file to "mode 1680 1050 32". In theory the boot screen should then be in that resolution until the nvidia takes over, right? Maybe that will start the nvidia driver is the right mood^{W mode...}

What I could also try: use the ~/config/settings/system/app_server/workspaces file of someone running 1680x1050. Could anyone upload such I file, please?

[anevilyak]

That gets more complicated since the resolution alone is not enough, the timing information also has to match the capabilities of your monitor, so I'm not sure how safe it'd be for you to use someone else's app_server_settings.

[humdinger]

Hmmm... yeah... shouldn't it be safe if the file were from someone also with a notebook panel (mine is 15,4"). Shouldn't the timing be reasonably similar?

That vesa thing doesn't work BTW. It didn't even change the boot screen...

[rudolfc]

hmm, I am running in that mode on my laptop right now, but on windows. I just booted a few times and over here the driver always works. Independant of one or both missing files, and independant of the mode I choose. I'll try to grab the file for you (can't get on the net on haiku because wifi isn't enabled by default)

It's unfortunate that haiku's app_server settings file doesn't use ascii like the beos app_server did :-/ would it understand such an old settings file though?

The vesa bios doesn't support ws modes I take it since they don't show in the boot options menu in the bootloader. In fact, I never saw a bios yet that showed such modes there.

Anyhow: if the native mode would work then the problem would be 'solvable' by the driver telling app_server what the native mode of your system is. I got from Axel that there are some new hooks I can implement for just that (if I understand correctly).

Of course, since you can run 1024x768 in vesa mode (correct?) the driver should be able to use that mode as well..

Bye!

Rudolf.

Update: since you are also writing comments ATM :-) The modeline isn't actually used by the driver: it itself determines the right settings from the modeline it fetched from the card GPU programming at bootup. You can safely try my settings (15,4 inch BTW too ;-)

[rudolfc]

OK, it's up (zipped in windows). I think your panel uses the exact same modeline as mine BTW.

Bye!

Rudolf.

BTW: maybe you can try 1400x1050 as vesa modesettings file at some point, that's a valid VESA mode and sits closer to your panel resolution wise..

[humdinger]

Thanks Rudolf!

I replaced the workspaces file via bfs_shell and was disappointed that it didn't seem to work. Then I had a closer look: Your workspaces.zip expands to a 0-byte-file... Could you try that again?

[rudolfc]

1680x1050x32 @ 60Hz, 4 workspaces - same modeline as you

[rudolfc]

Hi again,

I just replaced the file, seems OK to me now. About the modeline use in the driver: as I said, the driver calculates the timing itself so it's the same percentage wise as the native modeline reported by the GPU. That is, this is the timing set in the CRTC. There's a translation layer which converts the CRTC timing to LVDS timing: the latter always runs in the native modeline as programmed by the GPU. The driver does not change that. In other words: the GPU performs modeline scaling for the panel.

The story above is how it works for panels that are connected digitally. Analog connected screens (VGA style connection) really use the modeline in workspaces / the mode as set. As long as the driver determines there's no fault in it (like sync pulses outside the scope of a full line).

I hope it's fully clear now..

Bye!

Rudolf.

[humdinger]

I hope it's fully clear now..

Yeah, totally... NOT! :)

Anyway, it still doesn't work, sadly. I included another log and a syslog from this latest failed try. BTW, the notebook would be there for your inspection at BeGeistert in October if you come... :)

[humdinger]

log with Rudolf's workspaces settings

[humdinger]

syslog with Rudolf's workspaces settings

[rudolfc]

Hi again humdinger,

My workspace settings file doesn't work apparantly, since your log shows 1024x768 as being set at startup. This corresponds to a Haiku first start and come to think of it, Haiku saves info on the screen along with the mode set, and compares that back on startup (if I'm right).

I am now assuming the monitor info as saved in workspaces settings as well which means it won't work I guess.

Can you test using 1400x1050 on your screen? That's the highest supported VESA mode on your system: maybe that gives you a picture.. So, startup in failsafe video mode, set 1400x1050 via Screen prefs, and then reboot.

Does that give you a picture?

Bye!

Rudolf.

[humdinger]

Unfortunately it doesn't. :(

[rudolfc]

OK, thanks.

Anyhow, I'll implement two more Haiku specific driverhooks soon, which should tell the app_server the native mode of your screen. Currently this already works for screens which have (detected) EDID info. For most laptops this unfortunately isn't there so a fallback method needs to be used.

The purpose of these hooks is to display in native resolution from first boot on (instead of in 1024x768 or even 800x600).

I suggest I contact you here after I implement and test these hooks on my own laptop. Hopefully your screen will pop-on then..

Bye!

Rudolf.

[humdinger]

Thanks very much, Rudolf. You're also on my beer list for BeGeistert, BTW. So, if you could come, now it will *really* be worth your while. :)

[rudolfc]

Hi again,

Well, the hooks are implemented. EDID is fully ready. Can you please test?

About BG: Thanks! I am seriously considering coming this fall.. :-)

Bye!

Rudolf.

[rudolfc]

Hi Humdinger,

I tested the driver on my laptop: it indeed comes up in native mode at first boot. You need the current app_server for that to work since the hook used was commented out for a long time as it turned out.

Make sure you delete the app_server_settings file and the vesa file. If you do that and do a reboot app_server sees that as the first boot. If you don't delete these files the newly implemented hook won't get called, so don't forget that.

Good luck!

Rudolf.

Oh, please upload a new log for me here, even if your screen doesn't work.. :-)

Bye!

[humdinger]

Hi Rudolf,

I compiled/installed a new image yesterday evening, which should have all your recent changes to app_server etc. I even formatted the partition, as I've resized it to have another spare. So, the system should have been totally pristine.

Unfortunately, I have to report that it still does not work. See attached new log.

I use the bfs_shell to extract the log from inside Linux. Strangely, there's no syslog in /var/logs/ or I would have included that as well.

Hey, and do consider to come to BG021. I'll bring this annoying laptop... :)
Here I am, luring you with more work... :)

[humdinger]

new syslog after EDID changes

[rudolfc]

Hi again,

Well, at least the driver sets the native mode now. Interestingly your laptop has EDID support which now suddenly works. Might you be running a gcc4 build? There was an error in the common code before that prevented EDID to work with gcc4..

If you are testing gcc4 builds, can you now test a gcc2 build for me please? Just to satisfy my curiousity to know if it might work then.. :-)

Oh, if you goto BG, indeed please take the laptop with you. If I'm there, and it still doesn't work, I indeed like to have a look.

Bye!

Rudolf.

[rudolfc]

BTW, a few more questions:

• does your panel backlight turn off at app_Server start and remain off? or is it on? can you tell?

• does the driver work if you connect an external screen and tell nvidia.settings to do switchhead?

Bye!

Rudolf.

[humdinger]

Replying to rudolfc:

If you are testing gcc4 builds, can you now test a gcc2 build for me please? Just to satisfy my curiousity to know if it might work then.. :-)

I nomally run a gcc4 hybrid build. I tried a gcc2 hybrid build, but there was no difference. Only after I have attached an old CRT and set switchhead=true, it always hit a KDL ("create_app_meta_mime (s)"). Booting in video safe mode worked however!

I then re-configured and svn-upped to use a plain gcc2 build. Now everything's back to normal: Both notebook-LCD and external CRT go black after the last bootloader icon lit up... :(

The backlight of the LCD goes off.

Oh, if you goto BG, indeed please take the laptop with you. If I'm there, and it still doesn't work, I indeed like to have a look.

I'll be there and would very much appreciate if you could take a look.

[rudolfc]

Hi,

I'll gladly look if I'm there :-) I have another thought: can you run the driver once more, with a standard nvidia.settings file, with this time only one thing changed: enable the 'memory' line, and specify 256 or 128Mb memory. The driver detects 512Mb but it seems these days not all cards map that size in the kerneldriver...

Would this help?

Bye!

Rudolf.

[humdinger]

Whoohooo! Sweet success[[BR]] That was it! I set 128mb and now Haiku boots like a champ[[BR]] Thanks, thanks, thanks! I guess one beer isn't enough if you come to BeGeistert. :) Luckily, those come in 200ml dosages in Düsseldorf. :)

Feel free to close this ticket. Or not, if you could do something so this memory setting wouldn't be necessary any more. I'll try out whatever you come up with, but would be content to keep that nvidia.setting.

[rudolfc]

Cool!

I have my moments so to speak ;-) I expect I'll be coming around for that beer anyway..

Could you test 256Mb as well?

I'll leave this ticket open until I fix the problem. I think I'll be posting the mapped memory by/from the kerneldriver into shared_info and use that as a double check inside the accelerant to see if that would help.

Maybe later on I'll implement a memory map function for inside the accelerant by calling the kerneldriver, like the intel gfx driver does to use 'stolen'memory.

I'll keep you posted!

Bye!

Rudolf.

[rudolfc]

Hi there humdinger,

Can you please try hrev32845? I rewrote the memory size detection. Your card should now startup without the nvidia.settings file. Please, upload a new log for me here and tell me if it's fully OK now!

Thanks :-)

Rudolf.

[humdinger]

Fantastic! I just tried, and it actually does work[[BR]] Attached is the newest log with the default nvidia.settings with only full logging on. Call me if you need any further testing in the future.

I wished I had tried this setting a year ago... :)

[humdinger]

Newest full log with all settings in nvidia.setting on default.

[rudolfc]

Nice!

Thanks for your help. Maybe see you on BG then :-)

Closing ticket.

Bye!

Rudolf.

[aldeck]

I confirm it works here too. I can use the native 1280x800 mode now. Many thanks Rudolf, one more beer for you! And one for you Humdinger for taking care of this issue.

[humdinger]

This promises to be a fantastic BG weekend, ey? :)