Seems like you can't use Direct Rendering at same time with mergedfb 2560x1024 dualhead, since even "man radeon" says "The maximum framebuffer size that the 3D engine can handle is 2048x2048." But the fact is, I can do 3D on 2560x1024 on 9200 Pro card but First Monitor gets all blurry like it was 60hz and is going to explode at any time. What I expected, of course, is 3D not to work in part of area.. and 2D would still be good. With 2048x768 it's all good. So, I played around and switched my cables around and did: Option "MergedXineramaCRT2IsScreen0" "true" and I got what I expected.. 3D in 2048 area, and part of screen works only as 2D. But now, the area where 3D is not working.. is in _first_ display and that just.. doesn't work. DRI at full area + mergedfb + 2048x768 = works DRI at full area + mergedfb + 2560x1024 = works, but first display gets blurry DRI only at 2048 + mergedfb + 2560x1024 = works, but only with MergedXineramaCRT2IsScreen0 (and cables flipped around), and then the part where 3D doesn't work is in primary display.. that doesn't work for me, and probably not for anyone. I'm using 9200 Pro card, on X.org 7.0rc0, Mesa 6.3.2+CVS, DRM CVS, Linux 2.6.13- rc7, Gentoo, 32bit system..
(In reply to comment #0) > Seems like you can't use Direct Rendering at same time with mergedfb 2560x1024 > dualhead, since even "man radeon" says "The maximum framebuffer size that the 3D > engine can handle is 2048x2048." > > But the fact is, I can do 3D on 2560x1024 on 9200 Pro card but First Monitor > gets all blurry like it was 60hz and is going to explode at any time. What I > expected, of course, is 3D not to work in part of area.. and 2D would still > be good. With 2048x768 it's all good. I suspect this is a bandwidth issue. 2560x1024 coupled with 3D operations is a lot of data to push. You might try setting the "displaypriority" option to "HIGH". > > So, I played around and switched my cables around and did: Option > "MergedXineramaCRT2IsScreen0" "true" and I got what I expected.. 3D in > 2048 area, and part of screen works only as 2D. But now, the area where > 3D is not working.. is in _first_ display and that just.. doesn't work. > > DRI at full area + mergedfb + 2048x768 = works > DRI at full area + mergedfb + 2560x1024 = works, but first display gets blurry > DRI only at 2048 + mergedfb + 2560x1024 = works, but only with > MergedXineramaCRT2IsScreen0 (and cables flipped around), and then the part where > 3D doesn't work is in primary display.. that doesn't work for me, and probably > not for anyone. > MergedXineramaCRT2IsScreen0 just switches which screen is advertised as "screen 0" by the builtin pseudo-xinerama extension. It doesn't actually change the orientation of the crtcs. You probably don't want that option. If you want to reverse the heads, you should change the "CRT2Position" option between "RightOf" or "LeftOf" (or "Above" and "Below" depending on your set up). Try that and I supect you will get what you want. > I'm using 9200 Pro card, on X.org 7.0rc0, Mesa 6.3.2+CVS, DRM CVS, Linux 2.6.13- > rc7, Gentoo, 32bit system..
> I suspect this is a bandwidth issue. 2560x1024 coupled with 3D operations is > a lot of data to push. You might try setting the "displaypriority" option to > "HIGH". I've tried BIOS and HIGH.. unfortunately nothing changed. > MergedXineramaCRT2IsScreen0 just switches which screen is advertised as > "screen 0" by the builtin pseudo-xinerama extension. It doesn't actually > change the orientation of the crtcs. You probably don't want that option. True, but i've just noticed it helped while experimenting with Options. > If you want to reverse the heads, you should change the "CRT2Position" option > between "RightOf" or "LeftOf" (or "Above" and "Below" depending on your set > up). Try that and I supect you will get what you want. Yes, i'm using that kind of setup. Section "Device" Identifier "r200" Driver "radeon" Option "AGPMode" "8" # tried also dropping to 4. Option "BusType" "AGP" # correct. Option "EnablePageFlip" "on" # tried also without this. Option "MonitorLayout" "CRT, CRT" # they are both CRTs. Option "MergedFB" "true" Option "CRT2HSync" "24-64" # these are 100% correct. Option "CRT2VRefresh" "47-105" Option "CRT2Position" "LeftOf" # like you suggested. Option "MetaModes" "1024x768-1024x768" BusID "PCI:1:0:0" Screen 0 EndSection But if I do 1280x1024-1280x1024 it does that.. blurry on CRT1.
Ok, I tested with Option NonRectangular combination of 1280x1024 and 640x480 so that total amount of size is only 1720x1024 and it's still blurry. I don't get this at all, I can't use 1280x1024 at my first monitor at all same time with DRI, without image getting messed up. Since my information have been so scrambled, I'd just better close this bug and get another pair of monitors to test with.. so this won't take anyone elses time? I'm clueless.
Just out of curiosity, would there be any way to merge framebuffers vertically (to fit e.g. a 1600x1200 and a 1024x768 within the 2048 square limit for the 3d accel engine) but still have the mouse behave like they're side by side?
(In reply to comment #4) > Just out of curiosity, would there be any way to merge framebuffers vertically > (to fit e.g. a 1600x1200 and a 1024x768 within the 2048 square limit for the 3d > accel engine) but still have the mouse behave like they're side by side? Not really. The whole reason mergedfb works is because it's one big framebuffer. if you switched it around like that it would be basically equivalent to regular multi-head. You have to adjust the drawing engine and screen offsets to make it work as if the screens were side by side, in which case you wouldn't really have one big framebuffer anymore.
(In reply to comment #3) > Ok, I tested with Option NonRectangular combination of 1280x1024 and 640x480 > so that total amount of size is only 1720x1024 and it's still blurry. I don't > get this at all, I can't use 1280x1024 at my first monitor at all same time > with DRI, without image getting messed up. I have used radeon MergedFB without problems for a long time under SUSE 10.0 (X.org < 6.8.2). My graphics card is a RADEON 9200 SE with a 1600x1200 monitor on a DVI output (primary) and a 1280x1024 monitor on a VGA output (secondary). When I upgraded to SUSE 10.1 (X.org 6.9.0) MergedFB was broken, with similar symptoms to this bug report (blurry image on secondary / VGA output). Not only was the secondary image blurred, it was also the wrong resolution, like a deformed clone of
(In reply to comment #3) > Ok, I tested with Option NonRectangular combination of 1280x1024 and 640x480 > so that total amount of size is only 1720x1024 and it's still blurry. I don't > get this at all, I can't use 1280x1024 at my first monitor at all same time > with DRI, without image getting messed up. I have used radeon MergedFB without problems for a long time under SUSE 10.0 (X.org < 6.8.2). My graphics card is a RADEON 9200 SE with a 1600x1200 monitor on a DVI output (primary) and a 1280x1024 monitor on a VGA output (secondary). Hence, virtual X resolution is set to 2880x1200. When I upgraded to SUSE 10.1 (X.org 6.9.0) MergedFB was broken, with similar symptoms to this bug report (blurry image on secondary / VGA output). Not only was the secondary image blurred, it was also the wrong resolution, like a deformed clone of the primary output. I found a workaround: Define Option "MetaModes" "1600x1200 1600x1200-1280x1024", and when the X server starts press (CTRL ALT Keypad+) to switch to the next resolution, and everything is fine. Somehow X fails to initialise the VGA output properly, I think. Similarly, when switching to a virtual terminal (e.g., CTRL ALT F2) and back to X (CTRL ALT F7), the secondary video output is also blurred. Pressing (CTRL ALT Keypad-) and (CTRL ALT Keypad+) brings the display back to normal. (PS: DRI output seems to work fine in this setup, glxgears reports about 1300 FPS. When the window with the gears is dragged to the right beyond ca. 2/3 of the horizontal desktop area, they disappear, consistent with the 2048x2048 limit on 3D rendering. Dragging the window back left brings the gears back.)
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status. Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.
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.