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

[Daniel Vetter]

On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote:
> 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%?

Yeah exactly, that's what I'm worried about too, these kind of details.
Opt-in flag for special modes, no problem, but we need to make sure we
agree on what flavour of special exactly they are.

> 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.

Yeah, that would make sense too. Or maybe even add read-only hint that
says "if you're below 15% non-black we can do low power for your, please
be nice".
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch