Mailinglist Archive: radeonhd (699 mails)

[radeonhd] [ANNOUNCE] RandR 1.2 support merged in master

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@xxxxxxxxxxxx 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" "<list_of_outputs>"

This is an radeonhd specific option, so don't try this at home - err,
with other drivers ;)

There are also some standard RandR Q&As:

- I cannot dynamically add my second monitor --right-of my first one.

The framebuffer cannot be resized after initialization (yet). You have
to either configure this statically (man 5 xorg.conf), or specify the
maximum needed size with "Virtual <width> <height>" in the "Display"
subsection of the "Screen" section.
"xrandr -q" prints the maximum frame buffer size in the first line of
its output.

- My monitor section isn't used any longer.

Right. Now the monitor sections have to specified with
Option "monitor-<output_name>" "<monitor_name>"
in the "Device" section.
Behavior of monitor sections is different to standard modesetting in
radeonhd. With standard modesetting a monitor section replaces the
EDID detected monitor (thus typically reducing the maximum mode size
to 1024x768), in RandR it doesn't. I'm not exactly sure in which cases
which parameters are overridden by the monitor section and how to
override EDID detected parameters and modes in the RandR case.

- How do I configure a multimonitor setup statically?

Add (mostly empty) monitor sections for your monitors like described
in the answer above. Then add
Option "RightOf" "<other_monitor_name>"
to the monitor section representing your right monitor. Alternatively,
you can use "LeftOf" - working correctly only with the latest Xserver
(bugfix). Of course there's also "Above" and "Below".
You can also use "<other_output_name>" instead of "<other_monitor_name>".