On 18 April 2017 at 23:16, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > On Tue, Apr 18, 2017 at 8:33 PM, Kristian Høgsberg <hoegsberg@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
