On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote:
On Wed, 21 Oct 2020 at 16:58, Daniel Vetter daniel@ffwll.ch wrote:
On Wed, Oct 21, 2020 at 4:59 PM Ken Huang kenbshuang@google.com 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