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. > > > 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". 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
