On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen ppaalanen@gmail.com wrote:
yes, I think this makes sense, even if it is a property that one can't tell for sure what it does before hand.
Using a pair of properties, preference and active, to ask for something and then check what actually worked is good for reducing the combinatorial explosion caused by needing to "atomic TEST_ONLY commit" test different KMS configurations. Userspace has a better chance of finding a configuration that is possible.
OTOH, this has the problem than in UI one cannot tell the user in advance which options are truly possible. Given that KMS properties are rarely completely independent, and in this case known to depend on several other KMS properties, I think it is good enough to know after the fact.
If a driver does not use what userspace prefers, there is no way to understand why, or what else to change to make it happen. That problem exists anyway, because TEST_ONLY commits do not give useful feedback but only a yes/no.
By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one property at a time), user-space can discover which property makes the atomic commit fail.
I'm not a fan of this "preference" property approach. The only way to find out whether it's possible to change the color format is to perform a user-visible change (with a regular atomic commit) and check whether it worked after-the-fact. This is unlike all other existing KMS properties.
I'd much rather see a more general approach to fix this combinatorial explosion than to add special-cases like this.