On 23.06.2015 04:28, Emil Velikov wrote: > On 22 June 2015 at 07:56, Michel Dänzer <[email protected]> wrote: >> On 20.06.2015 07:32, Dave Airlie wrote: >>>> >>>>> at which point you'd want to continue >>>>> the versioning from the mesa point to avoid epochs. So I don't >>>>> take your argument, the API version is what we ship in the gbm.pc >>>>> file, compatible implementations should make the same API changes >>>>> in their same versions. >>>>> >>>> Other companies may use different versionning schemes (YYYY/MM/DD) and >>>> which they cannot shift away from for whatever reason. Based on that >>>> (plus the libEGL <> libgbm ABI mentioned above) sticking with "use >>>> mesa's version" seems a bit impossible/narrow minded imho. I think we >>>> can all agree things are less than perfect and checking the version in >>>> the pc file is not a good idea. >>> >>> gbm.pc is the gbm API version number. It isn't the Mesa version number, >>> it just happens at the moment they are the same thing because nobody >>> has split them, and because there isn't much value to Mesa in doing so. >>> >>> Other projects implementing the gbm API need to use the same version >>> number for their gbm.pc file. it sucks but otherwise they are not API >>> compatible. This doesn't mean they cannot use other versioning schemes >>> for their project, but their gbm.pc needs to be compatible with Mesa. >>> >>> But yes checking the version sucks and I'd rather not do it, but it doesn't >>> escape the fact that other gbm implementations are currently doing it >>> wrong if they want to be API compatible. >> >> I think one fundamental issue is that we're trying to determine the GBM >> runtime ABI from compile time constants. One possible solution might be >> to add something like >> >> enum gbm_bo_flags gbm_bo_get_supported_flags(struct gbm_device *gbm) >> >> which returns the mask of flags supported by the implementation. >> > In theory the "packager's responsibility" should kick way before that, > although this would be a great addition.
Not sure how that could work with different GBM implementations having different capabilities. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
