[PATCH 00/13] RandR 1.3 Panning support

[Matthias Hopf]

This set of patches adds panning support to RandR. Maybe it needs some
tweaking when Keith's transformation patches are applied.

The patches include version bumps to 1.3.0, dunno whether that should be
delayed until being actually final, please comment.


After applying the patches panning can be enabled e.g. by

  xrandr --output DVI --mode 1024x768 --fb 1600x1200 --panning 1600x1200

Please note that due to some stupidity in xrandr I haven't analyzed yet you
always have to set the frame buffer size before panning. xrandr tries to
reset the frame buffer size to the mode size by default.

You can also specify the pointer area for which the screen should be panned
(tracking area, useful for multi-monitor setups with partially panning
displays), and borders that let the screen pan before you actually hit the
physical borders, e.g. with

  xrandr --output DVI --fb 1600x1200 --panning 1600x1200+0+0/1600x1200+0+0/50/50/50/50

The current implementation behaves nicely on screen size changes and mode
changes, but I'd like to have it verified more before removing the
documentation parts that state that behavior on these actions is undefined.


I'm not completely satisfied with the abstraction, as panning is a purely
crtc related thing, but xrandr doesn't support setting crtc related
properties yet. Thus the to-be-set panning information is analyzed per
output, while it is actually set per crtc. Still, you probably won't notice
with typical use cases.

Also, there is no startup time support for about the same reason, as there
is no per-crtc configuration in xorg.conf.


Because the current RandR driver interface doesn't have support for panning,
each time a mode_set() is called on the crtc. As this typically disrupts
signal generation, a pan() call has been added for just updating the x/y
crtc coordinates. See patch 13, which adds support for the radeonhd driver.

Originally I planed to allow mode_set() with a NULL mode, but it's
impossible to verify in the server whether the driver will support that or
not, thus a separate call.


Matthias

-- 
Matthias Hopf <mhopf at suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de