RandR 1.3 additions?
alexdeucher at gmail.com
Mon Jan 21 23:04:11 PST 2008
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...
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
DAC, TMDS, LVDS
DVI-I, VGA, TV
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
Subpixel: horizontal rgb
CRTCs: 0 1
ENCODERS: TMDS-0 DAC-1
More information about the xorg