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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
