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