On Mon, Apr 24, 2017 at 01:51:39PM +0100, Emil Velikov wrote: > 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? With a big comment, but yeah this is special. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
