[PATCH libdrm v2] Header: Add rotation property fields

[Emil Velikov]

On 18 April 2017 at 23:16, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> 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, this that mean that we're OK with moving DRM_ROTATE* [+others]
to a ABI header?

Thanks
Emil