Hi, On 17.09. 03:12, Elmar Stellnberger wrote:
The Freedesktop group is currently implementing Plug and Play support for the radeonhd driver. This is basically a good thing. However it does not work yet as expected - my attached/internal screen stays black, my external screen is out of sync. The basic rescue action is to use framebuffer mode instead of radeonhd by copying /etc/X11/xorg.conf.install to /etc/X11/xorg.conf. However this will still trigger a regression since xrandr does not recognize my external monitor this way and hence no xinerama support is given. For the usage of xinerama mode or just for faster graphics rendering (radeonhd instead of slow framebuffering) you may want to downgrade you radeonhd from Milestone 7 to Milestone 6 so that it becomes usable again. I have created an own x86_64 - xorg-ancient repo for this purpose: zypper ar http://repos.elstel.com/xorg-anc Xorg-anc zypper mr -p 20 Xorg-anc zypper dup -r Xorg-anc
For me it seems that you have 2 problems. The one described above seems like a bug to me. If I understand correctly, you have correct xorg.conf, but it doesn't work with new radeonhd. If yes, than it's clearly a bug.
As things look now it may come the way that there will never again be given good Xinerama support by radeonhd as Novell and the FreeDesktop group are planning to fully drop xorg.conf and all its configuration options. Preconfiguring screen orientation (left/right), screen size (font size!) and the primary screen is a task that can only be done by an appropriate xorg.conf. Alternative desktop environments will perhaps never present xrandr-workarounds to emulate some of that functionality. If you are interested in ongoing xinerama support (with full xorg.configurability) you should give your vote at https://bugs.freedesktop.org/show_bug.cgi?id=18592 and at https://bugzilla.novell.com/show_bug.cgi?id=539004.
Well, here I think that there's a bit of misunderstanding in the bugreport (novell bugzilla). From my point of view (and I have nothing to do with X, so it's my *personal* opinion): Sax is *not* dropped, it's icon only go out of yast control center. This just makes users try the new method (via KDE/Gnome/xrandr/whatever). If sax would stay in yast, many users would use it in *first place* -> no migration to new mechanism even though it would work for them in most cases. If the "new mechanism" is not good for you for any reason (something not working), you can still use sax2! It's not dropped, you can still call it from commandline, etc. Later, when the "new mechanism" is mature and tested, than the xorg.conf support will/can be dropped (maybe). IMHO this seems to be the correct way, enable new feature, that shoud be working, but make it possible to fallback to the old behaviour. Just my 2cents Best regards, -- Lukas Lipavsky, QA Developer GPG Key ID: FF55774A Key fingerprint = 5BEB 6AF2 9653 638E EC0E 7E73 9A11 2BC5 FF55 774A --------------------------------------------------- SUSE LINUX, s.r.o. e-mail: llipavsky@suse.cz Lihovarska 1060/12 tel: +420 284 028 969 190 00 Prague 9 Czech Republic --------------------------------------------------- -- To unsubscribe, e-mail: opensuse-testing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-testing+help@opensuse.org