Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Julien Cristau]

[dropping -devel, adding mesa and kde maintainers instead]

On 11/27/18 5:42 PM, Steve Langasek wrote:
> On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
>> Steve Langasek <vorlon at debian.org> writes:
> 
>>> Long ago I heard rumors of development work on mesa that would allow it to
>>> function as a proxy library, so that apps would link against libGL as needed
>>> and the GL implementation would use a hardware-accelerated GLES driver where
>>> possible, falling back to software GL where necessary.
> 
>> This seems unlikely -- I believe GLES and GL have different semantics in
>> a few places which makes implementing GL on GLES inefficient; mostly
>> that GLES is missing stuff that GL applications often use, but I think
>> there are places where GLES is just different, including in how GLSL
>> works.
> 
> Perhaps that explains why no one ever actually succeeded in implementing it,
> then?
> 
> Thanks for the context.
> 
>> I haven't tried, but I would expect that applications could use both GL
>> and GLES APIs at the same time, even to the same window. If this does
>> work with Mesa, then linking Qt against GLES wouldn't restrict
>> applications using free drivers at least?
> 
> My recollection is that this becomes a practical problem of applications
> that want to use both Qt and GL being unbuildable due to namespace
> collisions at build time.
> 
Do you know if there have been attempts at resolving those collisions
upstream (either Qt or mesa / khronos)?

I seem to remember a couple of bug reports against mesa on the Debian
side but am curious about any escalations.

Cheers,
Julien