I've discussed drm props and ABI requirements a bit with Dave on irc. In the past we've been pretty lax with properties since connector properties are mostly meant for end-users to set manually, so not really much point in standardizing and treating them like ABI. But now we have props for plane/CRTC and atomic and those are really meant to be used by compositors, so all the problems with ABI start to kick in. And we had them already, e.g. early i915 patches for rotation where cw while existing omap supports was ccw. I also just spotted msm patches which reinvent the mirror flags of the rotation prop with their own flip prop. And there's a lot of things in-progress already like zpos/alpha/blending props, color manager/per-plane gamma, ...

To avoid future ABI disaster I think we should treat these props like any other drm ABI and require full-blown userspace, so here that would be a real implementation in something like weston, -modesetting, the new cros thing or maybe even hwc if that ever happens as an open-source project. And test tools like modetest don't cut it since upside down desktop is obvious, upside down test pattern meh. And modetest doesn't bother with all the TEST_ONLY and failure recory stuff like e.g. weston atomic needs to.

Internally I think we should also try to standarize prop handling by pushing them into drm_*_state structs and adding decoding in core and good helpers. And hopefully soon we have markdown for kerneldoc so can transform that horrible docbook table into something sane. But that's just internals which we can always fix. ABI's forever.

Anyway this is all kinda just clarification at least for i915. props for compositors are ABI like anything else, same rules still apply.

Yes totally, no adding props for closed compositors as well if we can't use it with weston/mutter/open source stuff we can't test it.

(are there any closed source compositors?)

Dave.