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

[Pekka Paalanen]

On Wed, 21 Oct 2020 18:09:05 +0100
Daniel Stone <daniel at fooishbar.org> wrote:

> On Wed, 21 Oct 2020 at 17:34, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote:  
> > > 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.

Hi,

I second those concerns.

I would also like to hear the reason why low power should be tied to a
video mode instead of being an orthogonal property. Does low power
depend on different timings? Different resolution?

Maybe extremely low refresh rate plays a role here? Or maybe it goes
into panel self-refresh mode that is somehow different from normal
timing wise?

How does low power mode interact with backlight controls? Does low
power mode automatically change the backlight control range, or the
control value, or does userspace need to dim down the backlight
explicitly, or what should happen?

What if userspace does not do what the driver expects? E.g. the
framebuffer contains too much too bright pixels, or the backlight
control is not set appropriately? What may happen on screen in those
cases?

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

That would seem better to me too, but I got the impression that rather
than non-zero, many dim pixels would be ok in low-power too. So that
may require specifying the formula for how exactly to calculate the
percentage. Mind, that power consumption need not be linear with
luminance, so if power consumption is the primary factor then writing
it down as luminance may not be correct.

Of course, the calculation should be simple and conservative enough
that it can be used with many kinds of hardware.

Also, HDR monitors may have a similar issue: a monitor may be limited
to certain wattage, which means that either you can display a small and
very bright patch, or a large and not that bright patch. It's unclear
to me if the same mechanism would be appropriate for both limiting HDR
display power under normal conditions and cell-phone display power in
low-power conditions.

Maybe "low power" should not even be a yes/no property, but a value
range, like wattage?

I think the problem with switching between KMS clients is something we
just have to solve by userspace restoring also unrecognized KMS
properties on switch-in always, like I have written before. I see no
way around it given the policy that the kernel will not offer any kind
of "defaults" property set (which too would need to be explicitly
used by userspace, or maybe a cap to stop the kernel from applying
it automatically whenever something gains DRM master).


Thanks,
pq

> > 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".  
> 
> If the hardware can actually do that autonomously then great, but I'm
> guessing the reason we're talking about separate opt-in modes here is
> that it can't.
> 
> Cheers,
> Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20201022/9601cadd/attachment.sig>