Bug 34441 - radeon 16-bit brokenness in dual-screen setup
Summary: radeon 16-bit brokenness in dual-screen setup
Status: RESOLVED DUPLICATE of bug 33929
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.6 (2010.12)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-18 04:20 UTC by Arno Schuring
Modified: 2011-02-20 04:23 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
current xorg.conf (2.95 KB, text/plain)
2011-02-19 07:07 UTC, Arno Schuring
no flags Details

Description Arno Schuring 2011-02-18 04:20:54 UTC
from http://bugs.debian.org/613918 :
"current video-radeon driver in unstable [1:6.14.0-1] gave me a very blocky and tiled login screen [...] Problems disappeared when I changed "DefaultDepth 16" to 24."

to which KiBi replied: "you shouldn't be using depth 16, it's broken in various ways, and kind of unsupported"

But man 4 radeon still advertises "Full support for 8-, 15-, 16- and 24-bit pixel depths", and http://www.x.org/wiki/radeon does not list lacking <24-bit support as a known issue.

Can anyone confirm the current state of 16-bit support, and bring the code and documentation in line?
Comment 1 Alex Deucher 2011-02-18 08:42:18 UTC
It should work, although it doesn't get tested as often as depth 24 on newer asics.  Can you bisect?
Comment 2 Arno Schuring 2011-02-19 07:00:41 UTC
I could probably perform a bisection if needed, yes, but I'm not looking forward to it; I suspect that bisecting only the -video-radeon driver will not be enough, because of the ABI bump between xserver 1.7.7 and 1.9.4. But if you could provide some pointers to the correct upstream trees/branches, I'll see what I can do.

Anyway, I've found some more time to try different things out, and it seems that things are not all dire: 16-bit mode works as expected if I start in single-screen and then use xrandr to re-enable dual-screen mode. I've also encountered two possible bugs with xrandr, but I have been able to reproduce both on 24-bit as well, so they're not the cause.

I'll list them anyway:
- xrandr CRTC assign seems iffy. When moving from clone mode to dual-display mode, both displays are not reassigned to separate CRTCs. I'll open a new bug for this
- xrandr --verbose still lists the displays as Clones, even after succesfully enabling dual-display mode. Probably a cosmetic issue, I'll open a new bug if you want me to


Maybe the issue is simply that I'm using the wrong xorg.conf entries, I'll attach it and list the relevant entries here:
Section "Monitor"
[...]
        Option      "Rotate"         "left"
        Option      "Position"       "1280 -896"
Section "Screen"
[...]
        SubSection "Display"
                Virtual    2360 1920
Comment 3 Arno Schuring 2011-02-19 07:07:04 UTC
Created attachment 43555 [details]
current xorg.conf
Comment 4 Arno Schuring 2011-02-19 08:19:44 UTC
(In reply to comment #2)
> - xrandr CRTC assign seems iffy.
bug 34481
Comment 5 Michel Dänzer 2011-02-20 02:56:51 UTC
(In reply to comment #5)
> from http://bugs.debian.org/613918 :
> "current video-radeon driver in unstable [1:6.14.0-1] gave me a very blocky and
> tiled login screen [...] Problems disappeared when I changed "DefaultDepth 16"
> to 24."

Isn't this bug 33929? In particular, doesn't Option "ColorTiling" "off" work around it?


> to which KiBi replied: "you shouldn't be using depth 16, it's broken in various
> ways, and kind of unsupported"

Not true.
Comment 6 Arno Schuring 2011-02-20 04:23:19 UTC
(In reply to comment #5)
> Isn't this bug 33929? In particular, doesn't Option "ColorTiling" "off" work
> around it?
Thanks for the pointer. Yes, disabling colortiling fixes the issue:

aschuring@neminis:~$ egrep Tiling\|Depth /var/log/Xorg.0.log
[  2552.677] (**) RADEON(0): Depth 16, (--) framebuffer bpp 16
[  2552.677] (**) RADEON(0): Option "ColorTiling" "false"
[  2552.677] (II) RADEON(0): KMS Color Tiling: disabled

*** This bug has been marked as a duplicate of bug 33929 ***


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.