[Buildroot] [PATCH 1/2] package/opengl/libgbm: new virtual package

[Buildroot] [PATCH 1/2] package/opengl/libgbm: new virtual package

[Thomas Petazzoni]

Hello all,

+in Cc, Einar (for ti-sgx-libgbm), Maxime Ripard (for
sunxi-mali-mainline) and Paul Kocialkowski (general libgbm knowledge)

On Thu, 13 Sep 2018 21:44:09 +0200, Bernd Kuhls wrote:
> Kodi 18.0-Leia will implement stand-alone gbm support alongside x11 &
> wayland.  To enable building libgbm in mesa3d without x11 & wayland we
> need to create a virtual package for libgbm.
> 
> Also other packages besides mesa3d may provide libgbm.so, see
> http://patchwork.ozlabs.org/patch/647235/
> http://patchwork.ozlabs.org/patch/939703/
> 
> Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>

During the Buildroot Developers meeting and last week, I worked on the
libgbm virtual package, in order to hopefully be able to merge the
patches from Bernd
(https://patchwork.ozlabs.org/project/buildroot/list/?series=65595)
and Einar
(https://patchwork.ozlabs.org/project/buildroot/list/?series=53824).

Unfortunately, it seems like the "libgbm" API is not very well
defined, and each OpenGL implementation has a different view of what
libgbm is. I am wondering how users of libgbm can work with such a
situation.

I have put together at
https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/?h=gbm a
branch that gathers Bernd and Einar patches, plus some additional
fixes on top, and three demo defconfigs. My goal was to be able to:

 - build kmscube with Mesa3D as libgbm provider (this is already
   possible)
 - build kmscube with TI SGX as libgbm provider
 - build kmscube with Sunxi Mali as libgbm provider

It turns out that while kmscube with Mesa3D builds (obviously),
neither kmscube with TI SGX or Sunxi Mali build properly:

 - TI SGX libgbm is named libgbm.so.2, while other libgbm
   implementations, including the one in Mesa3D is named
   libgbm.so.1. Not a big issue by itself, but it hints at the two
   things being different.

   Anyway, it fails to build because the libgbm API is not what
   kmscube expects: http://code.bulix.org/cot991-494068

 - With Sunxi Mali, same issue, it fails to build with libgbm API
   issues: http://code.bulix.org/rulyvo-494069

So I'm really wondering if libgbm has a proper standardized API like
OpenGL has. Another hint is that the recent version of kmscube now
require gbm >= 13.0, and 13.0 is basically a Mesa3D version.

Anybody has some hints/ideas about this ?

How is the libgbm from TI SGX or Sunxi Mali being used ? What will
build against it ?

Best regards,

Thomas

-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/2] package/opengl/libgbm: new virtual package

[Einar Jón]

Hi

I'm not much help here.
My only concern was building QT5 on an embedded AM335x with ti-sgx-*
libraries and update the kernel to 4.9 (bumping TI SDK from 2.0 to
4.0).
There is now a kernel 4.14 (TI SDK 5.0), with only minor changes to
the ti-sgx-* libraries (support gbm_bo and GCC7).
http://www.ti.com/tool/PROCESSOR-SDK-AM335X

kmscube seems to depend heavily on the mesa3d implementation, so I
don't think it's easy to make it work with the other libgbm versions.
Would building a working QT be a valid test of the libgbm build?

On Mon, 5 Nov 2018 at 13:47, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Tue, Oct 30, 2018 at 10:14:20PM +0100, Thomas Petazzoni wrote:
> > Hello all,
> >
> >
> > It turns out that while kmscube with Mesa3D builds (obviously),
> > neither kmscube with TI SGX or Sunxi Mali build properly:
> >
> >  - TI SGX libgbm is named libgbm.so.2, while other libgbm
> >    implementations, including the one in Mesa3D is named
> >    libgbm.so.1. Not a big issue by itself, but it hints at the two
> >    things being different.
> >
> >    Anyway, it fails to build because the libgbm API is not what
> >    kmscube expects: http://code.bulix.org/cot991-494068
> >
> >  - With Sunxi Mali, same issue, it fails to build with libgbm API
> >    issues: http://code.bulix.org/rulyvo-494069
> >
> > So I'm really wondering if libgbm has a proper standardized API like
> > OpenGL has. Another hint is that the recent version of kmscube now
> > require gbm >= 13.0, and 13.0 is basically a Mesa3D version.
> >
> > Anybody has some hints/ideas about this ?

Note that ti-sgx-um depends on wayland, due to a library dependency on
libwayland-server.so.0 and libwayland-client.so.0  (see ldd libpvrs_WAYLAND.so)
So the dropped dependency to wayland in ti-sgx-libgbm should have been
on ti-sgx-um.
Without it, QT5 will not find any EGL backend.

So the ti-sgx-um should be adding
select BR2_PACKAGE_WAYLAND
select BR2_PACKAGE_HAS_LIBEGL_WAYLAND

That way Qt5 can build with a valid EGL backend, using ti-sgx instead
of the ancient ti-gfx.
But this does nothing to help build kmscube.

--
Regards
Einar J?n

[Buildroot] [PATCH 1/2] package/opengl/libgbm: new virtual package

[Thomas Petazzoni]

Hello,

On Mon, 5 Nov 2018 16:35:02 +0100, Einar J?n wrote:

> I'm not much help here.
> My only concern was building QT5 on an embedded AM335x with ti-sgx-*
> libraries and update the kernel to 4.9 (bumping TI SDK from 2.0 to
> 4.0).
> There is now a kernel 4.14 (TI SDK 5.0), with only minor changes to
> the ti-sgx-* libraries (support gbm_bo and GCC7).
> http://www.ti.com/tool/PROCESSOR-SDK-AM335X
> 
> kmscube seems to depend heavily on the mesa3d implementation, so I
> don't think it's easy to make it work with the other libgbm versions.
> Would building a working QT be a valid test of the libgbm build?

Yes, it would be. So what you're saying is that the libgbm
implementation provided by TI SGX mimics well enough the libgbm
implementation of Mesa3D that QT5 is happy with TI SGX libgbm
implementation ?

> Note that ti-sgx-um depends on wayland, due to a library dependency on
> libwayland-server.so.0 and libwayland-client.so.0  (see ldd libpvrs_WAYLAND.so)
> So the dropped dependency to wayland in ti-sgx-libgbm should have been
> on ti-sgx-um.
> Without it, QT5 will not find any EGL backend.
> 
> So the ti-sgx-um should be adding
> select BR2_PACKAGE_WAYLAND
> select BR2_PACKAGE_HAS_LIBEGL_WAYLAND

ACK.

> That way Qt5 can build with a valid EGL backend, using ti-sgx instead
> of the ancient ti-gfx.
> But this does nothing to help build kmscube.

Right. I'm still confused by this libgbm thing though, where everyone
seems to have its own implementation, but there is no common API
implemented by everybody.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/2] package/opengl/libgbm: new virtual package

[Einar Jón]

On Mon, 5 Nov 2018 at 16:43, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Mon, 5 Nov 2018 16:35:02 +0100, Einar J?n wrote:
>
> > I'm not much help here.
> > My only concern was building QT5 on an embedded AM335x with ti-sgx-*
> > libraries and update the kernel to 4.9 (bumping TI SDK from 2.0 to
> > 4.0).
> > There is now a kernel 4.14 (TI SDK 5.0), with only minor changes to
> > the ti-sgx-* libraries (support gbm_bo and GCC7).
> > http://www.ti.com/tool/PROCESSOR-SDK-AM335X
> >
> > kmscube seems to depend heavily on the mesa3d implementation, so I
> > don't think it's easy to make it work with the other libgbm versions.
> > Would building a working QT be a valid test of the libgbm build?
>
> Yes, it would be. So what you're saying is that the libgbm
> implementation provided by TI SGX mimics well enough the libgbm
> implementation of Mesa3D that QT5 is happy with TI SGX libgbm
> implementation ?

That's exactly what I'm saying, but currently only with a big fat
"works for me" caveat.
My company has the same CPU as the beaglebone, but our boards have
considerable HW changes.
We're using an older 3.x kernel with ti-gfx, but I have a working
build with QT 5.9 on kernel 4.9/4.14 and ti-sgx.

I'll try to throw together a minimal working set with QT tomorrow, but
I'm not sure how useful it is without a rootfs
(busybox/kernel/udev/etc).

> > Note that ti-sgx-um depends on wayland, due to a library dependency on
> > libwayland-server.so.0 and libwayland-client.so.0  (see ldd libpvrs_WAYLAND.so)
> > So the dropped dependency to wayland in ti-sgx-libgbm should have been
> > on ti-sgx-um.
> > Without it, QT5 will not find any EGL backend.
> >
> > So the ti-sgx-um should be adding
> > select BR2_PACKAGE_WAYLAND
> > select BR2_PACKAGE_HAS_LIBEGL_WAYLAND
>
> ACK.
>
> > That way Qt5 can build with a valid EGL backend, using ti-sgx instead
> > of the ancient ti-gfx.
> > But this does nothing to help build kmscube.
>
> Right. I'm still confused by this libgbm thing though, where everyone
> seems to have its own implementation, but there is no common API
> implemented by everybody.

So am I. The ti-sgx-libgbm repo seems to be maintained by ti.com, but
there seems to be no real effort into making it more than just the
bare minimum to use ti-sgx-um.

-- 
Regards
Einar J?n

[Buildroot] [PATCH 1/2] package/opengl/libgbm: new virtual package

[Einar Jón]

Hi Thomas,

I finally had time to play with the gbm branch on
https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/
I made 5 commits that add QT with EGLFS-GBM for all 2 setups.
Can I make a pull request, or how do I share them with you?

Overview of comments:
* ca32516 - configs: libgbm defconfigs build qt5 (2018-11-30)<Einar
Jon Gunnarsson>|
|  configs/libgbm_mesa3d_defconfig     | 5 +++++
|  configs/libgbm_sunxi_mali_defconfig | 8 +++++++-
|  configs/libgbm_ti_sgx_defconfig     | 9 +++++----
|  3 files changed, 17 insertions(+), 5 deletions(-)

* f9fc93c - package/sunxi-mali-mainline: Fix QT5 build for EGLFS
(2018-11-30)<Einar Jon Gunnarsson>|
|  configs/libgbm_sunxi_mali_defconfig                | 1 -
|  package/sunxi-mali-mainline/Config.in              | 3 ++-
|  package/sunxi-mali-mainline/sunxi-mali-mainline.mk | 5 +++++
|  3 files changed, 7 insertions(+), 2 deletions(-)

* 4d7f6fb - package/qt5: fix EGLFS for embedded boards
(2018-11-30)<Einar Jon Gunnarsson>|
|  package/qt5/qt5base/qt5base.mk | 3 +++
|  1 file changed, 3 insertions(+)

* a7943f1 - package/qt5: Use any libgbm provider (2018-11-28)<Einar
Jon Gunnarsson>|
|  package/qt5/qt5base/qt5base.mk | 6 +++---
|  1 file changed, 3 insertions(+), 3 deletions(-)

* d964c09 - package/ti-sgx-um: Add dependency on wayland
(2018-11-28)<Einar Jon Gunnarsson>|
|  package/ti-sgx-um/Config.in    | 2 ++
|  package/ti-sgx-um/ti-sgx-um.mk | 1 +
|  2 files changed, 3 insertions(+)

On Tue, 6 Nov 2018 at 14:48, Einar J?n <tolvupostur@gmail.com> wrote:
>
> On Mon, 5 Nov 2018 at 16:43, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Hello,
> >
> > On Mon, 5 Nov 2018 16:35:02 +0100, Einar J?n wrote:
> >
> > > I'm not much help here.
> > > My only concern was building QT5 on an embedded AM335x with ti-sgx-*
> > > libraries and update the kernel to 4.9 (bumping TI SDK from 2.0 to
> > > 4.0).
> > > There is now a kernel 4.14 (TI SDK 5.0), with only minor changes to
> > > the ti-sgx-* libraries (support gbm_bo and GCC7).
> > > http://www.ti.com/tool/PROCESSOR-SDK-AM335X
> > >
> > > kmscube seems to depend heavily on the mesa3d implementation, so I
> > > don't think it's easy to make it work with the other libgbm versions.
> > > Would building a working QT be a valid test of the libgbm build?
> >
> > Yes, it would be. So what you're saying is that the libgbm
> > implementation provided by TI SGX mimics well enough the libgbm
> > implementation of Mesa3D that QT5 is happy with TI SGX libgbm
> > implementation ?
>
> That's exactly what I'm saying, but currently only with a big fat
> "works for me" caveat.
> My company has the same CPU as the beaglebone, but our boards have
> considerable HW changes.
> We're using an older 3.x kernel with ti-gfx, but I have a working
> build with QT 5.9 on kernel 4.9/4.14 and ti-sgx.
>
> I'll try to throw together a minimal working set with QT tomorrow, but
> I'm not sure how useful it is without a rootfs
> (busybox/kernel/udev/etc).
>
> > > Note that ti-sgx-um depends on wayland, due to a library dependency on
> > > libwayland-server.so.0 and libwayland-client.so.0  (see ldd libpvrs_WAYLAND.so)
> > > So the dropped dependency to wayland in ti-sgx-libgbm should have been
> > > on ti-sgx-um.
> > > Without it, QT5 will not find any EGL backend.
> > >
> > > So the ti-sgx-um should be adding
> > > select BR2_PACKAGE_WAYLAND
> > > select BR2_PACKAGE_HAS_LIBEGL_WAYLAND
> >
> > ACK.
> >
> > > That way Qt5 can build with a valid EGL backend, using ti-sgx instead
> > > of the ancient ti-gfx.
> > > But this does nothing to help build kmscube.
> >
> > Right. I'm still confused by this libgbm thing though, where everyone
> > seems to have its own implementation, but there is no common API
> > implemented by everybody.
>
> So am I. The ti-sgx-libgbm repo seems to be maintained by ti.com, but
> there seems to be no real effort into making it more than just the
> bare minimum to use ti-sgx-um.
>
> --
> Regards
> Einar J?n



-- 
Regards
Einar J?n
+31 610 957234

[Buildroot] [PATCH 1/2] package/opengl/libgbm: new virtual package

[Thomas Petazzoni]

Hello Einar,

On Fri, 30 Nov 2018 11:05:11 +0100, Einar J?n wrote:

> I finally had time to play with the gbm branch on
> https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/
> I made 5 commits that add QT with EGLFS-GBM for all 2 setups.

Cool! What are the results ? Can you build Qt with all eglfs/gbm
implementations (mesa3d, ti and mali) ?

> Can I make a pull request, or how do I share them with you?

You can either push your branch somewhere (on Github or elsewhere) or
otherwise post the patches on the mailing list, making it clear in the
cover letter that they depend on another set of patches.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/2] package/opengl/libgbm: new virtual package

[Einar Jón]

On Fri, 30 Nov 2018 at 11:46, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Einar,
>
> On Fri, 30 Nov 2018 11:05:11 +0100, Einar J?n wrote:
>
> > I finally had time to play with the gbm branch on
> > https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/
> > I made 5 commits that add QT with EGLFS-GBM for all 2 setups.
>
> Cool! What are the results ? Can you build Qt with all eglfs/gbm
> implementations (mesa3d, ti and mali) ?

Build: Yes
Run: ????

I don't have the hardware to test any of the setups (Maybe I can test
ti-sgx in December,
 but since "tomorrow" took me over 3 weeks, I'm not going to promise anything).
But I do have QT with EGLFS on all 3 platforms. I disabled kmscube on
the 2 that are not MESA.

> You can either push your branch somewhere (on Github or elsewhere) or
> otherwise post the patches on the mailing list, making it clear in the
> cover letter that they depend on another set of patches.

I'll just push them to the mailing list. See cover letter for details

-- 
Regards
Einar J?n

[Buildroot] [PATCH 1/2] package/opengl/libgbm: new virtual package

[Arnout Vandecappelle]

 Hi Einar, Bernd,

On 30/11/2018 13:02, Einar J?n wrote:
> On Fri, 30 Nov 2018 at 11:46, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>>
>> Hello Einar,
>>
>> On Fri, 30 Nov 2018 11:05:11 +0100, Einar J?n wrote:
>>
>>> I finally had time to play with the gbm branch on
>>> https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/
>>> I made 5 commits that add QT with EGLFS-GBM for all 2 setups.
>>
>> Cool! What are the results ? Can you build Qt with all eglfs/gbm
>> implementations (mesa3d, ti and mali) ?
> 
> Build: Yes
> Run: ????
> 
> I don't have the hardware to test any of the setups (Maybe I can test
> ti-sgx in December,
>  but since "tomorrow" took me over 3 weeks, I'm not going to promise anything).
> But I do have QT with EGLFS on all 3 platforms. I disabled kmscube on
> the 2 that are not MESA.

 I think the conclusion from that series is that it does not make sense to make
a virtual package of libgbm: kmscube only works with mesa, and even qt5 requires
some provider-specific fixups to make it work.

 So the proposal would be to (for now) drop the virtual package, and instead
keep them as separate packages (which are mutually exclusive, of course).

 All these patches are marked as Changes Requested in patchwork.

 Regards,
 Arnout

> 
>> You can either push your branch somewhere (on Github or elsewhere) or
>> otherwise post the patches on the mailing list, making it clear in the
>> cover letter that they depend on another set of patches.
> 
> I'll just push them to the mailing list. See cover letter for details
>