On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote: > On Wed, 21 Oct 2020 at 16:58, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Wed, Oct 21, 2020 at 4:59 PM Ken Huang <kenbshuang@xxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
