#2071 closed bug (fixed)
No accelerated video starting r24669 nightly
Reported by: | tigerdog | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Drivers/Graphics/nVidia | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
Starting with hrev24669 nightly, Haiku does not correctly display accelerated video on my nVidia 7600GS card. Monitor sees no video signal.
Nightly hrev24635 works OK. 24669 or later works OK in VESA mode.
Copying nvidia accelerant and driver from older rev into non-working rev does NOT solve the problem.
Change History (14)
comment:1 by , 17 years ago
Component: | - General → Drivers/Graphics |
---|---|
Platform: | All → x86 |
comment:2 by , 17 years ago
Thought maybe this was caused by a monitor known to report erroneous EDID info, but new monitor does the same thing. :(
comment:3 by , 17 years ago
Hi,
I was pointed at this error and it might be the same one as ticket #1950. Assuming this is the case I am now testing hrev24635 on a GF2Ti (NV15). It does _not_ work. I'll test hrev23198 and up since that's still online (haikufiles) to see if there's a revision working still for bug 1950.
stay tuned.
Rudolf.
follow-up: 14 comment:4 by , 17 years ago
Hi there,
I've traced the versions where it went wrong: hrev24493 is working OK; hrev24511 is faulty.
It's MTRR-WC failed mapping because of overlapping regions after all: commenting out the change in the kernel done in hrev24494 fixes the problem. I'm now running hrev24865 in 32bit accelerated mode on my NV15.
I don't know what is the first mapped region that is later on overlapped by my driver's request, but that deserves to be investigated. If that's legal then overlapping regions may not be blocked I'd say!
Can someone (kernel) have a look at this????
Bye!
Rudolf.
PS: I'm posting this finding in ticket #1950 as well.
comment:5 by , 17 years ago
Rudolph, thanks for finding this! Haiku without your driver is like Irish Coffee without the whiskey - still useable but not nearly as much fun. Kernel team, back to you!
comment:6 by , 17 years ago
On a hunch, I tried starting with "don't call the bios" and accelerated graphics works here! Thought this might be useful info.
comment:7 by , 17 years ago
Hi,
I tried that here as well some week ago or so: nogo. I think some BIOSes map the gfx card with MTRR-WC (if requested in BIOS-SETUP). maybe preventing this 'fixes'the problem as well.. (I'll try that too if I get around to it)
Still, the acc. should work as well if mapping succeeds without WC. It does so on BeOS R5 and Dano. It does not (apparantly) on Haiku. (Did not check yet if non-WC mapping itself fails though).
Bye!
Rudolf.
comment:8 by , 17 years ago
Hi again,
I've looked at the repository, and the MTRR overlap check was disabled with: http://dev.haiku-os.org/changeset/24946
On april 12th. My version was from april 8th so I suffered from this problem.
Tigerdog, would you say that a current version of Haiku works without problems, even if you don't select 'don't call the BIOS' ?
Thanks!
BTW: I've been playing around a bit more with the kernel, and I get the feeling that the function get_mtrr doesn't work reliable.. (?).
Over here MTRR fails sometimes (if overlap check enabled), even though the gfx card isn't the primary card in the system and therefore should not be mapped before.
It looks like fail or not: the driver doesn't work. Until I just disable that overlap check function that is. I don't (fully) grasp the situation here (yet). What I do know (I think) is that the driver is OK since on R5 it's always working, even if I modify the kerneldriver to don't use MTRR.
Bye!
Rudolf.
comment:10 by , 17 years ago
Component: | Drivers/Graphics → Drivers/Graphics/nVidia |
---|
Some one need to close this :) (I don't know how to)
comment:11 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed through disabling MTRR overlap checks. Closing as there is a separate MTRR bug to track those issues.
comment:12 by , 17 years ago
Not 100% working: upon clean install of any nightly after 5/31, same problem exists. Instead of starting, video card output just toggles on and off. If I set a default resolution for VGA at startup to 1600x1200, then continue to boot, accelerated video driver is running at 1024x768 once Haiku starts.
Two other issues: 1920x1200 resolution has troubles (jagged lines down leftmost 5-6 pixels of screen) plus output looks "dim"; white is rendered as dull yellow-grey.
Selecting 32-bit color at any resolution causes my mouse pointer to disappear!
Maybe we should reopen this?
comment:13 by , 17 years ago
Hi tigerdog,
Your description is not clear enough for me to fully grasp what you're trying to say. What I do get is this:
(1920x1200) I get the feeling that this a modeline issue. That won't be solved until the driver has EDID support: you probably need a custom modelin for the 1920x1200 res, if it's going to work at all:
While VESA EDID might get the max/native resolution your panel supports, it's not certain that it's 'pre'-programmed for that mode by the cards VGABIOS. The driver cannot set that mode then since it uses those values still (if all is right though it disables that mode then, you simply cannot choose it).
So, it's theoretical possible that Haiku wants to start-up the nvidia driver in a mode reported by VESA DDC which the nvidia driver actually doesn't support on that machine. I don't know if Haiku does that BTW (copy the mode used for vESA modeswitch to being the actual workspace 0 mode for a real driver??)
About the cursor: that's a Haiku problem, not a driver problem.
(just a thought here:) If Haiku should work failsafe for everyone outrhere I have a simple solution: simple remove _all_ gfx drivers and let everyone use VESA only. If people want more, they should enable a accelerated driver themselves. It's impossible to make every system outthere work perfectly. Period.
Bye!
Rudolf.
comment:14 by , 17 years ago
Replying to rudolfc:
I don't know what is the first mapped region that is later on overlapped by my driver's request, but that deserves to be investigated. If that's legal then
My guess: src/system/kernel/debug/frame_buffer_console.cpp:frame_buffer_console_init_post_modules()
Replying to tigerdog:
In reviewing commits, it seems the possible causes may be commits in rev 24638 or 24648. Is there some way to further narrow this problem?