[PATCH] drm: add client cap to expose low power modes

[Daniel Stone]

On Wed, 21 Oct 2020 at 16:58, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Oct 21, 2020 at 4:59 PM Ken Huang <kenbshuang at google.com> wrote:
> > It's useful in Android and other embedded devices to implement Always On Display (ex. showing clock faces with less than 15% OPR on screen).
> >
> > OPR (On Pixel Ratio) is the percentage of luminance amount over the display area.
> > It's derived by gray levels of display image pattern and the backlight (or OLED) driving force (or current).
> > ex: OPR=100% means a full white pattern with maximum backlight (or OLED) brightness, while full black would be OPR=0%.
> >
> > In userspace, when the client initializes, we can set capability via drmSetClientCap() to ask the display driver to expose the drm modes with DRM_MODE_FLAG_LOW_POWER flag.
> > Userspace can check DRM_MODE_FLAG_LOW_POWER flag to know which modes can be used to consume the least amount of power during Always On Display.
> > Ignoring modes with this flag set during normal operating mode.
>
> Hm I'm not really sure what this changes ... I think we need the
> entire pile of patches: Userspace, driver, drm core, anything else.
> Just adding this flag doesn't make much sense really, since I have no
> idea what the semantics are. Even after you've explained the use-case.

It makes sense to me: some modes are annotated with a 'low-power'
flag, tucked away behind a client cap which makes clients opt in, and
they can switch into the low-power mode (letting the display/panel
save a lot of power) _if_ they only have at most 15% of pixels lit up.

My worry is about the 15% though ... what happens when hardware allows
up to 20%, or only allows 10%?

If we can reuse the same modelines, then rather than create new
modelines just for low-power modes, I'd rather create a client CRTC
property specifying the number/percentages of pixels on the CRTC which
are lit non-zero. That would give us more wriggle room to change the
semantics, as well as redefine 'low power' in terms of
monochrome/scaled/non-bright/etc modes. But it does make the
switching-between-clients problem even worse than it already is.

Cheers,
Daniel