[ANNOUNCE] RandR 1.2 support merged in master
Heho,
I've just merged RandR 1.2 support into master, because most user of
that branch had no problems with it any more, and it adds significant
advances to user experience.
With the community patches and RandR support included, we're now aiming
for a first release, probably early next week. So please stress test
this now.
Basically, full RandR 1.2 support is provided, and also some early bits
that might be default or even mandatory with RandR 1.3 (some output
properties). As this standard isn't completely defined yet, things may
change here. Also we might want to add other means of setting modes as
well in the future, so the interface will be abstracted away more
cleanly soon. More info about the properties in the commit message of
dce9ffc40 and in a discussion on xorg-devel.
Some issues are still remaining, and we're actively trying to hunt those
last bugs down ASAP. Still, for the majority the driver should work
out-of-the-box.
Somehow, this driver seems to be the first that uncovers a set of bugs
in both the base RandR system and in the xrandr application. I have
tried hard to fix those upstream, so if xrandr behaves strangely, it
might help to fetch the latest xrandr and xserver bits. xrandr doesn't
have a lot of dependencies, and contains the more important fixes.
There is also the possibility that the fixes introduced regressions, as
always.
I also created a test case for xrandr and we're now finishing it w/o any
problems. Feel free to test it on your system and report breakages - but
only if you're using the latest git version of xrandr and the xserver
(it will fail in different tests with old versions).
The RandR output names are still quite a bit clumsy ATM - they sure will
be changed to something more sane. The current names are created from
AtomBIOS, by combining the output and connector name (RandR has no
abstraction layer for connectors).
Monitor handling is completely different from standard modesetting, as
everything is done by the RandR layer. This might lead to regressions,
as panel modes are not always detected correctly, and scaling isn't
implemented yet.
If anything goes wrong, add
Option "noRandR"
to your Device section, and everything should be back to standard
modesetting as it was used before. But also be sure to report the bug to
radeonhd@opensuse.org if it is unknown so far.
If your outputs are ordered in the wrong way with respect to Xinerama
emulation, you can reorder them by adding their names (separated by
spaces or comas) to
Option "RROutputOrder" "
participants (1)
-
Matthias Hopf