On Wed, 21 Oct 2020 18:09:05 +0100 Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > On Wed, 21 Oct 2020 at 17:34, Daniel Vetter <daniel@xxxxxxxx> 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
Attachment:
pgpD67EGl2V7X.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
