Am Di., 21. Mai 2024 um 19:28 Uhr schrieb Leo Li <sunpeng.li@xxxxxxx>: > > > > 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 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. > >>> > >
