RandR 1.3 additions?

[Jesse Barnes]

On Friday, July 13, 2007 11:32 am Keith Packard wrote:
> So, if you're monitoring the xorg-commit list, you will have seen an
> addition to RandR float by. I think we should consider what stuff should
> be in a 1.3 version of RandR at this point; we have several good
> suggestions:
>
>      1. DPMS events. This is what Eric added in his randr-dpms branch.
>         This adds an event delivered when an output changes DPMS status,
>         allowing applications to detect when the screen is blanked for
>         any reason.
>      2. Per-output DPMS set/get. Right now, DPMS setting is global.
>         Allowing applications to set DPMS levels individually for each
>         output would provide some useful functionality.
>      3. Panning rectangle. RandR 1.2 drops the old built-in panning
>         functionality as you rarely want your extended-mode monitors to
>         all follow the mouse around the virtual desktop. If we, instead,
>         allowed each crtc to automatically pan within a limited
>         rectangle, we would be able to use panning again in a way
>         consistent with RandR. The Xinerama information provided to
>         applications would then mark the set of panning rectangles
>         instead of the set of crtc mode rectangles.
>
> Are there other things we should consider adding to the RandR protocol
> at this point?

Has there been much progress on this front?  Presumably, the randr changes 
will be targetted at a 1.5 server release...

I'd be willing to help implement a few things I'm interested in adding:
  - output & crtc mode programming w/o using dpms hooks
    this should reduce mode setting flicker (eliminating it entirely in some
    cases) and requires the addition of a ->prepare hook in addition to the
    existing driver hooks
  - an output property ->get method
    this will let properties like the backlight value stay up to date even if
    changed by hotkey events or the system bios w/o the driver's knowledge

I'm interested in feedback on both proposals, especially from other driver 
developers on (1).  I have an Intel driver branch that eliminates any mode 
set flicker entirely on LVDS outputs, but it requires server changes and I 
want to make sure ->prepare is enough for the other drivers too.

The changes really only affect the server<->driver API, not the protocol.  In 
fact, the changes could be done in a backward compatible way so that old 
drivers wouldn't require changes...

Thoughts?

Jesse