RandR 1.3 additions?

[Jerome Glisse]

On 7/16/07, Alex Deucher <alexdeucher at gmail.com> wrote:
> On 7/13/07, Keith Packard <keithp at keithp.com> 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.
> >
>
> These are great additions.
>
> > Are there other things we should consider adding to the RandR protocol
> > at this point?
>
> How about GPU and CRTC properties?  It would be nice to have a
> standard interface to adjust global GPU options (e.g., clock gating
> and other power management stuff, GPU and memory clocks, framebuffer
> compression, tiling, etc.).  The CRTC properties could be useful for
> the projective transforms and on a lot of chips the panel scaler is
> actually part of the crtc rather than the output.
>
> Alex

Talking of power management i have been wondering if it wouldn't be nice
to have some kind of infrastructure to scale down GPU & VRAM clock
(on card which can) anytime we don't have activity. The tricky point is that
is bit hard to find out what we can call activity maybe we should just provide
infrastructure and let a user program/daemon choose what is inactivity (no
input in last minute, or nothing got refreshed, maybe better information is how
many change happen to the currently displayed framebuffer things like damage
extension might provide such information in more or less accurate way).
Thus we can powerdown GPU/VRAM more often specialy if only small part of
the framebuffer get updated (which means that we then likely not need much
power to draw a blinking cursor or update clock because minute just shifted).

Anyway this powermanagement things might not be approriate for randr
extension.

best,
Jerome Glisse