drm properties, ABI and compositors

[Dave Airlie]

> 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.