[PATCH libdrm v2] Header: Add rotation property fields

[Daniel Vetter]

On Tue, Apr 18, 2017 at 8:33 PM, Kristian Høgsberg <hoegsberg at gmail.com> wrote:
>>> As far as I understand the property mechanism, the numeric values
>>> aren't actually ABI. The string names of the enum values are the ABI
>>> and you're supposed to parse the enum info and discover the numerical
>>> values. For example:
>>> https://git.collabora.com/cgit/user/daniels/weston.git/tree/libweston/compositor-drm.c?h=wip/2017-03/atomic-v10-WIP#n570
>>>
>> Note sure I agree, yet then again my kernel experience is less than yours.
>> Do check the following commit and feel free to search the ML thread
>> that inspired it.
>
> I haven't worked much with the property mechanism tbh, but I know
> Daniel (Stone) jumped through all those hoops to avoid hard-coding the
> enum values.

In theory, this is correct and is how it's supposed to be done. In
practice, for a bunch of properties at least, we deal with the reality
of userspace being lazy and assuming that the enum values match with
the encode they send over the wire and tears result if we ever chance
that. I still think that going through the strings should be the
better way, since it makes it much easier to add/remove certain enum
values, depending upon what the hw/driverr combo can pull off.

The story is different for the properties themselves, there you
definitely need to make the name->prop id lookup, and you also need to
do that mapping for each object separately (because the value range is
attached to the prop, for uabi reasons, but might need to be
per-object).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch