On 24.06.2015 20:38, Emil Velikov wrote: > On 23 June 2015 at 02:46, Michel Dänzer <[email protected]> wrote: >> 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. >> > [...] > 2) Distros provides xserver package, annotate against a meta gbm > (with multiple providers of gbm, properly versioned) - user can swap > between mesa gbm and other supported implemenations without any > problems. This approach is not addopted for gbm yet, but other > packages do make use it.
I meant: How can this deal with one GBM implementation supporting a flag such as GBM_BO_USE_LINEAR but the other not? -- 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
