[PATCH 0/2] Add support for Panel Power Savings property
Xaver Hugl
xaver.hugl at gmail.com
Tue May 21 17:40:31 UTC 2024
Am Di., 21. Mai 2024 um 19:28 Uhr schrieb Leo Li <sunpeng.li at amd.com>:
>
>
>
> On 2024-05-21 12:21, Mario Limonciello wrote:
> > On 5/21/2024 11:14, Xaver Hugl wrote:
> >> Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
> >> <mario.limonciello at amd.com>:
> >>>
> >>> On 5/21/2024 08:43, Simon Ser wrote:
> >>>> This makes sense to me in general. I like the fact that it's simple and
> >>>> vendor-neutral.
> >>>>
> >>>> Do we want to hardcode "panel" in the name? Are we sure that this will
> >>>> ever only apply to panels?
> >>>>
> >>>> Do we want to use a name which reflects the intent, rather than the
> >>>> mechanism? In other words, something like "color fidelity" = "preferred"
> >>>> maybe? (I don't know, just throwing ideas around.)
> >>>
> >>> In that vein, how about:
> >>>
> >>> "power saving policy"
> >>> --> "power saving"
> >>> --> "color fidelity"
> >>
> >> It's not just about colors though, is it? The compositor might want to
> >> disable it to increase the backlight brightness in bright
> >> environments, so "color fidelity" doesn't really sound right
> >
> > Either of these better?
> >
> > "power saving policy"
> > --> "power saving"
> > --> "accuracy"
> >
> > "power saving policy"
> > --> "allowed"
> > --> "forbidden"
> >
> > Or any other idea?
>
> Another consideration in addition to accuracy is latency.
>
> I suppose a compositor may want to disable features such as PSR for use-cases
> requiring low latency. Touch and stylus input are some examples.
>
> I wonder if flags would work better than enums? A compositor can set something
> like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example.
I think that's a good idea. With a flag for color accuracy and one for
brightness, the compositor's intent would be communicated well.
> - Leo
>
> >
> >>
> >>>>
> >>>> Would be nice to add documentation for the property in the "standard
> >>>> connector properties" section.
> >>>
> >>> Ack.
> >>>
> >
More information about the dri-devel
mailing list