[Mesa-dev] [PATCH 0/3] Support for Android RGBX/RGBA formats

[Emil Velikov]

On 25 April 2016 at 16:33, Adam Jackson <ajax at redhat.com> wrote:
> On Mon, 2016-04-25 at 15:21 +0100, Emil Velikov wrote:
>
>> Last a I saw you guys were backporting all of mesa, correct ?
>> Are you OK with us deprecating compat. between DRI(2) modules and
>> loaders (GL/EGL/gbm) that are, say 3 years apart ?
>
> At this point that's probably fine. RHEL6 still includes DRI1 drivers
> so changing libGL is pretty rough there, but at least for graphics
> we're soon going to be done with hardware enablement for RHEL6. For EL7
> (and going forward) we just need a mutually compatible libGL, drivers,
> and X server. Our rebases come out on the even-numbered minor RHEL
> versions which are 12-18 months apart so a three year window works just
> fine.
Great.

> Obviously we'd prefer fewer flag days (and possibly some amount
> of slip, one "new" interface and one "compat" interface always
> coexisting to make bisection easier).
>
The thing I was thinking was:
Figure out the cut-off date/feature range.
Print 'errors' on the console, if DRI does not have deprecated feature
X. Similar got for the loaders.
The message will say - a) which is the minimum required version that
should be fine and b) which verison of mesa will 'break' things.

Normally things are removed after 2-3 releases after the deprecation
warnings. And new ones (if needed) are updated simultaneously.

> We don't really support different libGL and drivers, the issue is
> mostly keeping xserver's loader working.
>
Was thinking of that one but forgot to explicitly mention it. What is
the "age gap" between the xserver and the dri modules that you ship ?
I'm thinking that the above 3 years "gap" + ~9months of deprecation
period should be fine with you guys ?

> we're on the subject: if someone wanted to fix framebuffer init
> in Mesa so that window-system buffers were allocated as needed (z/s and
> friends), we could change xserver (and EGL) to be less of a polynomial
> explosion of fbconfigs...
>
Sadly I may not be the best person for this one. Sorry about that :-(

Thanks
Emil