[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 <vor...@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