5:30 a.m.
Hi,
few weeks ago we started working on porting Nemomobile to Fedora 32 as
a base. Now I am hitting an issue when trying to make it work with
libhybris device. On that device, I have GLESv2 and would need Qt that
is not linked to libGL. Is such Qt available for ARM on Fedora? Or
should I recompile Qt with the corresponding settings?
Best wishes,
Rinigus
5:53 a.m.
On Tue, Sep 22, 2020 at 6:31 AM rinigus <rinigus.git(a)gmail.com> wrote:
Hi,
few weeks ago we started working on porting Nemomobile to Fedora 32 as
a base. Now I am hitting an issue when trying to make it work with
libhybris device. On that device, I have GLESv2 and would need Qt that
is not linked to libGL. Is such Qt available for ARM on Fedora? Or
should I recompile Qt with the corresponding settings?
It looks like we removed OpenGL ES support in Qt5 because the
pkgconfig file for glesv2 went missing in Fedora 30. It seems to have
returned now, so I'd suggest filing a bug report to get it turned back
on.
--
真実はいつも一つ！/ Always, there's only one truth!
5:59 a.m.
I am looking for Qt that would not depend on libGL at all, something
like https://mitya57.me/weblog/2020/01/qt-opengl-es-packages-available.html
for debian. I guess there are no plans for that yet.
Rinigus
On Tue, Sep 22, 2020 at 1:54 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Tue, Sep 22, 2020 at 6:31 AM rinigus <rinigus.git(a)gmail.com> wrote:
> >
> > Hi,
> >
> > few weeks ago we started working on porting Nemomobile to Fedora 32 as
> > a base. Now I am hitting an issue when trying to make it work with
> > libhybris device. On that device, I have GLESv2 and would need Qt that
> > is not linked to libGL. Is such Qt available for ARM on Fedora? Or
> > should I recompile Qt with the corresponding settings?
> >
>
> It looks like we removed OpenGL ES support in Qt5 because the
> pkgconfig file for glesv2 went missing in Fedora 30. It seems to have
> returned now, so I'd suggest filing a bug report to get it turned back
> on.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
6:01 a.m.
On Tue, Sep 22, 2020 at 6:59 AM rinigus <rinigus.git(a)gmail.com> wrote:
I am looking for Qt that would not depend on libGL at all, something
like https://mitya57.me/weblog/2020/01/qt-opengl-es-packages-available.html
for debian. I guess there are no plans for that yet.
Is there a good reason for doing it that way vs just also *having* the
GLES modes available?
--
真実はいつも一つ！/ Always, there's only one truth!
6:09 a.m.
libhybris systems don't have libGL.so at all. It is for "regular"
Android devices transformed to glibc Linux through libhybris. So, when
compiling anything that links to libGL, I get into trouble.
Rinigus
On Tue, Sep 22, 2020 at 2:02 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Tue, Sep 22, 2020 at 6:59 AM rinigus <rinigus.git(a)gmail.com> wrote:
> >
> > I am looking for Qt that would not depend on libGL at all, something
> > like https://mitya57.me/weblog/2020/01/qt-opengl-es-packages-available.html
> > for debian. I guess there are no plans for that yet.
> >
>
> Is there a good reason for doing it that way vs just also *having* the
> GLES modes available?
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
6:10 a.m.
On Tue, Sep 22, 2020 at 7:09 AM rinigus <rinigus.git(a)gmail.com> wrote:
libhybris systems don't have libGL.so at all. It is for "regular"
Android devices transformed to glibc Linux through libhybris. So, when
compiling anything that links to libGL, I get into trouble.
Why wouldn't libhybris work through glvnd so that libGL goes through
Mesa (software rendered) and libEGL goes through libhybris (hardware
accelerated)?
--
真実はいつも一つ！/ Always, there's only one truth!
6:23 a.m.
As far as I have seen, having pkgconfig(gl) in Qt devel dependencies
brings in glvnd libs in all kinds of variants clashing with libhybris.
Specific issue I will have to recheck tonight and get back to you.
Maybe such a combination Mesa GL software rendering + hw accelerated
EGL/GLESv2 would work. As far as I know, I can specify it during
runtime. On Sailfish we don't have libGL at all, hence my questions
Rinigus
On Tue, Sep 22, 2020 at 2:11 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Tue, Sep 22, 2020 at 7:09 AM rinigus <rinigus.git(a)gmail.com> wrote:
> >
> > libhybris systems don't have libGL.so at all. It is for "regular"
> > Android devices transformed to glibc Linux through libhybris. So, when
> > compiling anything that links to libGL, I get into trouble.
> >
>
> Why wouldn't libhybris work through glvnd so that libGL goes through
> Mesa (software rendered) and libEGL goes through libhybris (hardware
> accelerated)?
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
6:56 a.m.
Le mar. 22 sept. 2020 à 13:23, rinigus <rinigus.git(a)gmail.com> a écrit :
As far as I have seen, having pkgconfig(gl) in Qt devel dependencies
brings in glvnd libs in all kinds of variants clashing with libhybris.
Specific issue I will have to recheck tonight and get back to you.
Maybe such a combination Mesa GL software rendering + hw accelerated
EGL/GLESv2 would work. As far as I know, I can specify it during
runtime. On Sailfish we don't have libGL at all, hence my questions
You might have a better chance using gl4es than switching to GLES
where the fedora default is to use GL everywhere.
But it's probably not something that can be supported on the fedora
side for the same reason libhybris can't be supported. (you will need
to link libhybris/gl4es to a proprietary gles implementation instead
of the generic/mesa version)
https://bugzilla.redhat.com/show_bug.cgi?id=1788327
https://github.com/ptitSeb/gl4es
7:09 a.m.
You might have a better chance using gl4es than switching to GLES
where the fedora default is to use GL everywhere.
But it's probably not something that can be supported on the fedora
side for the same reason libhybris can't be supported. (you will need
to link libhybris/gl4es to a proprietary gles implementation instead
of the generic/mesa version)
https://bugzilla.redhat.com/show_bug.cgi?id=1788327
https://github.com/ptitSeb/gl4es
yes, I have seen this bug while searching for Qt/GLES, thanks for
pointing to it as well. Could be a way to do it.
As for "better", it would depend on whether we want to support all
Fedora apps or just Qt stack. Right now, I am mainly targeting Qt
which means that recompiling it with GLES enabled and without GL.so,
should help me already. And I think that was a reason why Qt on Debian
was made in such manner as well
Rinigus
6:13 a.m.
libhybris systems don't have libGL.so at all. It is for
"regular"
Android devices transformed to glibc Linux through libhybris. So, when
compiling anything that links to libGL, I get into trouble.
What is the hardware that you want to use via libhybris? Ultimately
libhybris is not something I suspect we'll ever support directly in
Fedora so it would end up being a problem to support and to make sure
works.
> On Tue, Sep 22, 2020 at 2:02 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Tue, Sep 22, 2020 at 6:59 AM rinigus <rinigus.git(a)gmail.com> wrote:
> > >
> > > I am looking for Qt that would not depend on libGL at all, something
> > > like
https://mitya57.me/weblog/2020/01/qt-opengl-es-packages-available.html
> > > for debian. I guess there are no plans for that yet.
> > >
> >
> > Is there a good reason for doing it that way vs just also *having* the
> > GLES modes available?
> >
> >
> >
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> arm mailing list -- arm(a)lists.fedoraproject.org
> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
6:17 a.m.
> libhybris systems don't have libGL.so at all. It is for
"regular"
> Android devices transformed to glibc Linux through libhybris. So, when
> compiling anything that links to libGL, I get into trouble.
What is the hardware that you want to use via libhybris? Ultimately
libhybris is not something I suspect we'll ever support directly in
Fedora so it would end up being a problem to support and to make sure
works.
I am basing it on my Sailfish port for Xperia XZ2, XZ2c, and XZ3. But
in principle, if it will work using a similar approach as we use for
Sailfish, it should be possible to port similar devices to that base
as well. On Sailfish, my hardware works very well. As for libhybris
support, I don't expect it from Fedora.
In parallel, there is a native device work done by others for PinePhone.
Rinigus
1363
days inactive
1363
days old
10 comments
4 participants
participants (4)
-
Neal Gompa -
Nicolas Chauvet -
Peter Robinson -
rinigus