[Mesa-dev] [PATCH] [rfc] dri3: allow building against older xcb

Dave Airlie airlied at gmail.com
Mon Mar 12 18:48:44 UTC 2018


On 13 March 2018 at 03:24, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hi Dave,
>
> On 11 March 2018 at 23:26, Dave Airlie <airlied at gmail.com> wrote:
>> From: Dave Airlie <airlied at redhat.com>
>>
>> I'm not sure everyone wants to be updating their dri3 in a forced
>> march setting, this allows a nicer approach, esp when you want
>> to build on distro that aren't brand new.
>>
>> I'm sure there are plenty of ways this patch could be cleaner,
>> and I've also not built it against an updated dri3.
>
> Have you considered cases where the build server is using 1.12, while
> at run-time we have 1.13?
> Are you explicitly forbidding that, say via the packaging? It tends to
> be allowed on most(all?) distributions.

Yes I am because really who does that, and why do I care.

If you build against a newer libxcb it won't run against the older one either,
why do you expect building against the older one will magically work against
a newer one with all the features?

> That said, if updating XCB is a serious no-go, may I suggest something
> like the following:
>  - add local fallback definitions/declarations
>  - add local functions (annotated as weak) which return 'the correct'
> value so that the fallback paths kick in

I can sorta see the first part being useful, the second is definitely
over engineering
the solution.

The thing is most of the features in dri3.1 are gated on the X server
having support,
Most people are not updating their X servers, I'm guessing apart from
the modifiers
devs there'll be at most 10 people who update their X server for this
feature in advance
of a distro moving them to it. I know I won't personally be going
around all 10 boxes I
keep running updating their X server for a feature that doesn't add
anything on those
hw configurations yet. When distros move to the 1.20 X server they'll
also move to newer
xcb, this is for distros that won't move at all.

Dave.


More information about the mesa-dev mailing list