Created attachment 22680 [details] Xorg log Enabling Option RandR12 in xorg.conf results in black screen. Server starts up fine, seems to be usable, only screen stays black. Monitor doesn't turn off. VT switching works, albeit with picture degradation (bad resolution?) which isn't recovered even when killing X (also, crash on killing X, with or without RandR12, see messages). Operating system: Gentoo Linux ppc64 with 64bit userland (problem the same on 32bit userland). Hardware: Apple G5 with DVI-only GeForce7800GT PCI-E Apple OEM version, screen is a Dell 30 inch 2560x1600 display on DVI connector 1. drm commit: 97fdadee6a79f9406a55c235ee46104814321152 xf86-video-nouveau commit: 98b8cada6c355d437925a92ef0413e96751ed567 Legacy render path with RandR12 disabled works fine.
Created attachment 22681 [details] drm messages
Created attachment 22682 [details] xorg conf
Can you attach a full kernel log? Or more precisely, I suspect you may be using nvidiafb (or rivafb). Danny
(In reply to comment #3) > Can you attach a full kernel log? Or more precisely, I suspect you may be using > nvidiafb (or rivafb). > > Danny > I'm using the OpenFirmware framebuffer, passing video=ofonly to the kernel. Nvidiafb isn't even in the kernel. Do you still need the full log?
Maybe not then (would not hurt though). Are you sure you are not hitting bug 15206? If so, I guess you should install the nouveau branch of radeontool and dump registers with and without randr1.2 mode d.
(In reply to comment #5) > Maybe not then (would not hurt though). > > Are you sure you are not hitting bug 15206? > > If so, I guess you should install the nouveau branch of radeontool and dump > registers with and without randr1.2 mode > > d. > I read that bug before but it states that the second display doesn't get a signal. Mine does (it doesn't go into powersave), but it's black. So I figured I had something different going on. I'll post a full log with drm debug later when I'm back at the machine, though.
Created attachment 22724 [details] full dmesg Full dmesg with drm debug=1. Kernel oops at the end happens on server kill, not on its own.
Created attachment 22726 [details] non-randr12 mode register dump
Created attachment 22729 [details] randr12 mode register dump
Hi, from looking at the two dumps, it looks like either we're doing something very wrong (a possibility), or the two dumps were made with the monitor connected to different dvi connectors. If this was the case, can you please re-make the dumps leaving the monitor on the same connector, otherwise it makes side-by-side comparison very hard?
(In reply to comment #10) > Hi, from looking at the two dumps, it looks like either we're doing something > very wrong (a possibility), or the two dumps were made with the monitor > connected to different dvi connectors. If this was the case, can you please > re-make the dumps leaving the monitor on the same connector, otherwise it makes > side-by-side comparison very hard? > That would be stupid on my part, but absolutely a possibility. ;-) Now, re-dumped registers follow.
Created attachment 22851 [details] non-randr12 register dump
Created attachment 22852 [details] randr12 register dump
Created attachment 22859 [details] [review] changes which are unlikely to help, but should be ruled out Hi, here's the first of three patches. They apply on top of each other, but please test the changes individually, i.e. test 1, then 1+2, then 1+2+3. If any changes in behaviour are observed please note what changed and which patches were applied to cause the change. Also, please do the test with the monitor attached to the same port the earlier dumps were made with, or else the results are not very helpful :-) If there is no change with all three patches applied, please make a new register dump of the "randr12 + patch 1 + patch 2 + patch 3" case.
Created attachment 22860 [details] [review] a more interesting change 2 / 3
Created attachment 22861 [details] [review] disable bios output scripts 3/3 Note all patches can be simply applied on top a clean git checkout using "git am $PATCHNAME"
Created attachment 22894 [details] randr12 and patches register dump Patch 0001 didn't do anything visibly, patch 0002 "fixes" the problem (more in a second) and I couldn't see if patch 0003 improved anything over 0002. The "fix" is that I finally get a picture (can see xterms, xclock, interact with them), but it's still horribly wrong somehow. Looks like the picture is missing vertical lines, but somehow still not everywhere (TWM resize lines may disappear, but there are no gaps in the windows themselves). This is consistent over all modes I've tried (2560x1600, 1920x1200, 1280x800) and doesn't show up on a screenshot. It also doesn't get restored back to normal when quitting the X server: the brokenness remains when using the console afterwards.
(In reply to comment #17) > Created an attachment (id=22894) [details] > randr12 and patches register dump Thanks. Some quick questions to help in making the next patch, and some other things to try in the future: This register dump is with all three patches, or just the first two? > Patch 0001 didn't do anything visibly, patch 0002 "fixes" the problem (more in > a second) and I couldn't see if patch 0003 improved anything over 0002. Just to clarify, you tried 0003 on top of 0002, but could see no difference? > The "fix" is that I finally get a picture (can see xterms, xclock, interact > with them), but it's still horribly wrong somehow. Looks like the picture is > missing vertical lines, but somehow still not everywhere (TWM resize lines may > disappear, but there are no gaps in the windows themselves). Hmm, might be interesting to see a picture should you have a digital camera, but don't worry if it's not convenient. > This is consistent over all modes I've tried (2560x1600, 1920x1200, 1280x800) > and doesn't show up on a screenshot. It also doesn't get restored back to > normal when quitting the X server: the brokenness remains when using the > console afterwards. Is it worse than the "picture degradation (bad resolution?) which isn't recovered even when killing X" you mentioned previously, or the same? One other thing that would be interesting to know next time you test (using a clean checkout (no patches)), if you add `Option "FPScale" "off"' in the driver section of your xorg.conf, and set 1280x800, whether that works any better.
(In reply to comment #18) > (In reply to comment #17) > This register dump is with all three patches, or just the first two? All three. Do you want one with just 1+2? > Just to clarify, you tried 0003 on top of 0002, but could see no difference? Exactly. I started seeing something with 1+2 and 1+2+3 didn't visibly change anything. > Hmm, might be interesting to see a picture should you have a digital camera, > but don't worry if it's not convenient. I'm pretty happy you're taking so much time helping me, so I certainly won't complain about small inconveniences. I'll have to charge the camera's batteries first, though. :-) > Is it worse than the "picture degradation (bad resolution?) which isn't > recovered even when killing X" you mentioned previously, or the same? It is the same, only that before I couldn't see it in X but only after killing it. But it is exactly the same. > One other thing that would be interesting to know next time you test (using a > clean checkout (no patches)), if you add `Option "FPScale" "off"' in the driver > section of your xorg.conf, and set 1280x800, whether that works any better. I'll try that and report back along with the promised photo.
BIG CORRECTION!!! As the picture error didn't get corrected when killing the server, I didn't notice that patches 1+2+3 actually give a GOOD PICTURE, until I retested after a reboot. Your other suggestion, concerning FPScale, didn't seem to have any effect. I tested: patches 1+2+3, FPScale on: good picture patches 1+2, FPScale on: bad picture patches 1+2, FPScale off: bad picture no patches, FPScale on: no picture no patches, FPScale off: no picture Are you still interested in a photo of the screen distortion?
(In reply to comment #20) > BIG CORRECTION!!! > > As the picture error didn't get corrected when killing the server, I didn't > notice that patches 1+2+3 actually give a GOOD PICTURE, until I retested after > a reboot. Ok, that's more like I expected (sorry, should have noted the reboot requirement) :-) > Your other suggestion, concerning FPScale, didn't seem to have any effect. I > tested: Even at 1280x800? interesting > patches 1+2+3, FPScale on: good picture > patches 1+2, FPScale on: bad picture > patches 1+2, FPScale off: bad picture > no patches, FPScale on: no picture > no patches, FPScale off: no picture > > Are you still interested in a photo of the screen distortion? No, that's fine, I've a better idea of the problem now. I'll try to come up with some more things next week.
(In reply to comment #21) > No, that's fine, I've a better idea of the problem now. I'll try to come up > with some more things next week. That's fine, the patched version is working good so far, so no big hurry here. :-)
The patched version is just a hack, try hotplugging a (2nd) dvi monitor and see the failure ;-)
Ok, a few more things I would like: 1) a copy of the video bios image. this can be found in /proc/device-tree and is called "NVDA,BMP" 2) using an *unpatched* copy, change the first "#if 0" of nv_bios.c (around line 41) to "#if 1", then attach the more verbose xorg.0.log to this bug (obviously it won't work, as it's unpatched) 3) (from a clean boot, if you've done 2) beforehand), see which of the previous patches are absolutely necessary. I imagine just 2+3 will work, and it's somewhat possible that 3 alone would do
Created attachment 23008 [details] NVDA,BMP
Created attachment 23009 [details] Xorg.0.log with "#if 1" in nv_bios.c
Just patch 0003 wouldn't give me any picture, but 0002 + 0003 seem to work fine.
Created attachment 23015 [details] [review] improved workaround Please test with this patch on a clean checkout. If it works, can you also try removing the line it adds to nv_crtc.c and see if the change to nv_bios.c is sufficient?
(In reply to comment #28) > Created an attachment (id=23015) [details] > improved workaround > > Please test with this patch on a clean checkout. If it works, can you also try > removing the line it adds to nv_crtc.c and see if the change to nv_bios.c is > sufficient? Patch works fine, no picture again without the change to nv_crtc.c though.
Created attachment 23087 [details] [review] Partial fix Ok, here's a partial fix, the other part being something wrong with scaling modes which I don't presently understand. To test the fix, apply the patch, and to work-around the scaling problem add `Option "ScalingMode" "panel"' to the device section of your xorg.conf ("noscale" should work as well as panel, "aspect" and "fullscreen" won't). Assuming this works and you feel like a new challenge, if booting with the monitor on the other dvi port gets an image with randr12 turned off (or even with the "nv" driver), feel free to make comparison regdumps of that and we can look at fixing it for randr12 :-)
(In reply to comment #30) > Created an attachment (id=23087) [details] > Partial fix > > Ok, here's a partial fix, the other part being something wrong with scaling > modes which I don't presently understand. To test the fix, apply the patch, > and to work-around the scaling problem add `Option "ScalingMode" "panel"' to > the device section of your xorg.conf ("noscale" should work as well as panel, > "aspect" and "fullscreen" won't). > > Assuming this works and you feel like a new challenge, if booting with the > monitor on the other dvi port gets an image with randr12 turned off (or even > with the "nv" driver), feel free to make comparison regdumps of that and we can > look at fixing it for randr12 :-) Alright, bear with me here, fresh clone, patch applied, 'Option "ScalingMode" "panel"'... black as ever. Am I missing something?
(In reply to comment #31) > Alright, bear with me here, fresh clone, patch applied, 'Option "ScalingMode" > "panel"'... black as ever. Am I missing something? Huh, weird. maybe "noscale" would work better than "panel"? otherwise (to test I've not totally misdiagnosed this), in nv_crtc.c change the line with SCALE_PANEL to "if (1 || nv_encoder->scaling_mode == SCALE_PANEL ||". If that doesn't work I'm confused :-)
(In reply to comment #32) > Huh, weird. maybe "noscale" would work better than "panel"? otherwise (to > test I've not totally misdiagnosed this), in nv_crtc.c change the line with > SCALE_PANEL to "if (1 || nv_encoder->scaling_mode == SCALE_PANEL ||". If that > doesn't work I'm confused :-) I had tried both 'noscale' and 'panel', neither worked. Sorry for the confusion. But that's apparently really not the problem, since the '1' didn't fix anything either.
Created attachment 23122 [details] [review] dpms lolz ok, I think I see what I overlooked. apply this patch on top of the previous "partial fix", and hopefully it should work, even without a specific scaling mode.
Yes, this works!
Fix pushed: http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=e09f50e5f9126c682289b7ba790f16b93a80b876 I'd be interested in fixing the other dvi port, if non-randr12-mode or nv can work with it, so we reach parity of functionality. Otherwise, I think this can be resolved FIXED :)
(In reply to comment #36) > I'd be interested in fixing the other dvi port, if non-randr12-mode or nv can > work with it, so we reach parity of functionality. Otherwise, I think this can > be resolved FIXED :) Sure, what do you need? Register dumps using nv or non-randr12 nouveau, as you said above? Does it matter that the second port can only drive the panel at 1920x1200?
(In reply to comment #37) > Sure, what do you need? Register dumps using nv or non-randr12 nouveau, as you > said above? Does it matter that the second port can only drive the panel at > 1920x1200? So long as non-randr12/nv can get it to light up, and randr12-nouveau doesn't, 1920x1200 is fine. Register dumps and Xorg.0.logs would be great.
Created attachment 23213 [details] Xorg Log noveau without randr12 Xorg log. Somewhat of a WTF moment here, DVI-I-1 apparently will drive the panel at 2560x1600 in non-randr12 mode. Thought this was supposed to be a single link DVI port... Good news: nouveau works on this port in randr12-mode, although only in 1920x1200 (as I would have had expected). Register dump non-randr12 follows.
Created attachment 23214 [details] Register dump nouveau no randr12
(In reply to comment #39) > Xorg log. Somewhat of a WTF moment here, DVI-I-1 apparently will drive the > panel at 2560x1600 in non-randr12 mode. Thought this was supposed to be a > single link DVI port... > Good news: nouveau works on this port in randr12-mode, although only in > 1920x1200 (as I would have had expected). Register dump non-randr12 follows. Interesting, what resolution does OSX let you have on that connector (assuming you've got OSX installed)? You can allow dual-link modes on that connector in nouveau by editing nv_output_mode_valid() in nv_output.c; a simple change being to replace the MODE_CLOCK_HIGH after the (mode->Clock > 165000) test with MODE_OK, but I've no idea whether that would work :-)
(In reply to comment #41) > Interesting, what resolution does OSX let you have on that connector (assuming > you've got OSX installed)? > > You can allow dual-link modes on that connector in nouveau by editing > nv_output_mode_valid() in nv_output.c; a simple change being to replace the > MODE_CLOCK_HIGH after the (mode->Clock > 165000) test with MODE_OK, but I've no > idea whether that would work :-) Sorry this took so long, I needed to get hold of a copy of OSX. As anticipated, OSX would only drive the panel at 1920x1200 on DVI-I-1 (just like nouveau in non-randr12 mode). However, with the change you proposed, nouveau will do dual-link on the second connector without complaining. What is this? Did Apple cripple a dual-dual-link card so the could sell more high-end cards instead? Or might this break down if I tried to drive two dual-link displays simultaneously?
(In reply to comment #42) > ...(just like nouveau in > non-randr12 mode)... I meant, "randr12-mode" of course, not "non-randr12".
(In reply to comment #42) > Sorry this took so long, I needed to get hold of a copy of OSX. As anticipated, > OSX would only drive the panel at 1920x1200 on DVI-I-1 (just like nouveau in > non-randr12 mode). Thanks for the effort, I wasn't expecting you to have to find a copy :) > However, with the change you proposed, nouveau will do dual-link on the second > connector without complaining. > > What is this? Did Apple cripple a dual-dual-link card so the could sell more > high-end cards instead? Or might this break down if I tried to drive two > dual-link displays simultaneously? According to http://en.wikipedia.org/wiki/Nvidia_Quadro the fx4500 (the Apple option for 2 x dual-link) is the same silicon as the 7800gtx, which according to http://www.nvidia.com/object/extreme_hd_gpu.html is only 1 x dual-link; the difference is normally whether the board manufacturer has connected up the traces for the second link pins, and it seems your board manufacturer did, but then crippled it in the bios image. We can't really ignore the image though, as there's going to be a majority of cases where the extra link isn't wired up. As for using 2 x dual-link, I don't know :) It's certainly possible that the card isn't clocked high enough for some part to have the bandwidth to drive two such displays, or (less likely) that the board is populated with some cheaper components that can't handle the additional electrical demands. Assuming you don't have access to another 30" :) we're probably not going to find out. Unless you can argue a good case for it, I think I'll leave things as they are -- an option for "let me do 2 x dual link on a card I bought thinking it couldn't" seems like something with very low demand (I guess I could add a pci id based override for this Apple card, but that still doesn't resolve whether the hardware can run 2 x dual-link simultaneously).
(In reply to comment #44) > Thanks for the effort, I wasn't expecting you to have to find a copy :) No problem, I was planning to do it some day so I could replay some of my old games. :-) > According to http://en.wikipedia.org/wiki/Nvidia_Quadro the fx4500 (the Apple > option for 2 x dual-link) is the same silicon as the 7800gtx, which according > to http://www.nvidia.com/object/extreme_hd_gpu.html is only 1 x dual-link; the > difference is normally whether the board manufacturer has connected up the > traces for the second link pins, and it seems your board manufacturer did, but > then crippled it in the bios image. We can't really ignore the image though, > as there's going to be a majority of cases where the extra link isn't wired up. > > As for using 2 x dual-link, I don't know :) It's certainly possible that the > card isn't clocked high enough for some part to have the bandwidth to drive two > such displays, or (less likely) that the board is populated with some cheaper > components that can't handle the additional electrical demands. Assuming you > don't have access to another 30" :) we're probably not going to find out. > > Unless you can argue a good case for it, I think I'll leave things as they are > -- an option for "let me do 2 x dual link on a card I bought thinking it > couldn't" seems like something with very low demand (I guess I could add a pci > id based override for this Apple card, but that still doesn't resolve whether > the hardware can run 2 x dual-link simultaneously). There is some oddity about an Apple S-Video adapter only working on DVI-I-0 on these cards, I think, so there actually may be cases where people would want to drive their 30" on DVI-I-1. But considering that there probably are less than a 10000 of these machine-card combinations out there, 99 per cent of which probably will never run anything but OSX, the effort seems wasted. Nevertheless, thanks a bunch for fixing this so promptly, I'm a happier person now. ;-)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.