On Thursday, June 10th, 2021 at 23:00, Daniel Vetter daniel.vetter@ffwll.ch wrote:
If there's a strong consensus that we really need this then I'm not going to nack this, but this really needs a pile of acks from compositor folks that they're willing to live with the resulting fallout this will likely bring. Your cc list seems to have an absence of compositor folks, but instead every driver maintainer. That's backwards. We make uapi for userspace, not for kernel driver maintainers!
In wlroots we have a policy of only allowing standard KMS properties to be used. Any vendor-specific property is going to be less well-defined, less widely useful, potentially have more design issues, potentially overlap in functionality with other vendor-specific properties, likely have some hardware-specific assumptions, etc.
What matters here is discussing with other driver & user-space folks to make sure the new property's design is sound. Designing uAPI is hard.
If kernel folks are struggling with a user-space implementation, they should discuss with user-space folks to see which project would be interested. There's a chance a compositor will be interested in the new property and will just do the user-space part for you, if not we can suggest candidate projects.
tl;dr strong agree with Daniel here.