RandR 1.3 additions?

[Alex Deucher]

On Jan 21, 2008 5:45 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
>
> 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 those seem reasonable to me.  It got me thinking again about a
few other things that would improve randr.  I think we need an
additional level of abstraction for encoders and connectors rather
than just outputs.  On a lot of hardware you can have encoders like
DACs that are shared between multiple physical connectors (you might
have a DAC shared between a TV port and a DVI-I port). The other case
would be ports with more than one encoder associated with them (DVI-I
for example: DAC and TMDS).  The question is, do we want to expose
physical connectors (TV port, DVI-I port, DVI-D port, VGA port, etc.)
to users or encoders (DAC, TMDS, etc.)?  For example on a card with
two DVI-I ports and  a TV port would you expose two DACs and two TMDS
outputs or two DVI ports and a TV port?  I would argue that connectors
are a better choice as that's what the user sees.

crtc -> encoder -> output

CRTC
crtc {
    possible_encoders;
}

DAC, TMDS, LVDS
encoder {
    crtc;
    possible_crtcs;
    output;
    possible_outputs;
}

DVI-I, VGA, TV
output {
    crtc;
    encoder;
    possible_encoders;
    monitor;
}

the outputs would still handle the detect() functionality, and they
would choose the encoder.  A driver that didn't want to use the
encoders abstraction would still work so drivers could gradually
update or not.

Then you could do things like xrandr --output DVI-0 --crtc 0 --encoder
DAC-0 --mode 1280x1024

DVI-0 connected 1280x1024+1280+0 (0x4f) normal (normal left inverted
right x axis y axis) 376mm x 301mm
        Identifier: 0x4e
        Timestamp:  27142
        Subpixel:   horizontal rgb
        Clones:
        CRTC:       1
        CRTCs:      0 1
        ENCODER: TMDS-0
        ENCODERS: TMDS-0 DAC-1

Thoughts?

Alex