RandR 1.2 for Xorg 7.2?

[Alex Deucher]

On 9/21/06, Keith Packard <keithp at keithp.com> wrote:
> I've been busy the last couple of weeks finishing up the spec for RandR
> 1.2 and working on an implementation. It's 'working' now, in that the
> new functionality has been seen to work on one laptop.
>
> While the new extension internals are entirely different, they can work
> with existing RandR-enabled drivers, although with reduced
> functionality. Of course, it also works with existing RandR
> applications.
>
> So, the question is whether it makes sense to look at including this new
> code in X.org 7.2. It's a sizable chunk of work:
>
>  34 files changed, 3442 insertions(+), 1187 deletions(-)
>
> But, it offers some fairly cool new features, including the ability to
> dynamically turn on external monitors and place them in a mergefb
> configuration.
>
> Still remaining on the to-do list is a Xinerama implementation so that
> existing multi-monitor/single-screen applications can see what is going
> on without needing to adapt to this new extension. I should have that
> working this evening; there are plenty of existing Xinerama
> implementations to steal from.
>
> Code for the four pieces is available in a suite of git repos:
>
> git://people.freedesktop.org/~keithp/xserver          - randr-1.2
> git://people.freedesktop.org/~keithp/randrproto       - multi-monitor
> git://people.freedesktop.org/~keithp/libXrandr        - randr-1.2
> git://people.freedesktop.org/~keithp/xrandr           - randr-1.2
>
> This last repo, xrandr, contains a temporary hacked-up xrandr that can
> be used to manipulate the new features in the extension. Integrating
> that into a single xrandr program seems desireable, if a bit tricky.
>
> Take a look at the code and the specs and see what you think. It's
> important to realize that new extension functionality can take a long
> tiem to get to end-users; we have to depend on desktop developers to
> carry the new features into their interfaces, so while it's important to
> not screw up, it's also important to provide development platforms as
> early as possible.

Nice work Keith.  Do you have the sample driver implementation
available anywhere?  Once I get back into the country and have some
time to go over it, I can tackle the convertion of other dualhead
capable drivers.  Does anyone see any reason to keep the mergedfb
implementations around once a driver is converted to the new xrandr?
what about the old screen based dualhead?

Alex

>
> --
> keith.packard at intel.com
>