On 5/21/2024 12:27, Leo Li wrote:
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@xxxxxxx>:
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 thought we had said the PSR latency issue discussed at the hackfest
was likely just a bug and that nominally it won't matter?
If it really will matter enough then yeah I think you're right that
flags would be better. More drivers would probably want to opt into the
property for the purpose of turning off PSR/PSR2/panel replay as well then.
- Leo
Would be nice to add documentation for the property in the "standard
connector properties" section.
Ack.
