package/opengl/libgbm: new virtual package
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/2 package/opengl/libgbm: new virtual package
Hello all,
+in Cc, Einar (for ti-sgx-libgbm), Maxime Ripard (for sunxi-mali-mainline) and Paul Kocialkowski (general libgbm knowledge)
Quoted 9 lines · Bernd Kuhls
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 <[email protected]>
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
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
A message that is not in the archive (sent off-list or not yet received): 20181105124735.3qbms4ymnrgpw3op@flea
PATCH 1/2 package/opengl/libgbm: new virtual package
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?
Quoted 16 lines · Maxime Ripard
Quoted 14 lines · Thomas Petazzoni
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
Quoted 8 lines
Quoted 8 lines
- With Sunxi Mali, same issue, it fails to build with libgbm API
issues: http://code.bulix.org/rulyvo-494069So 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
PATCH 1/2 package/opengl/libgbm: new virtual package
Hello,
Quoted 11 lines · Einar J?n
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 (supportgbm_boand GCC7).
http://www.ti.com/tool/PROCESSOR-SDK-AM335Xkmscube 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 ?
Quoted 9 lines
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
selectBR2_PACKAGE_WAYLAND
selectBR2_PACKAGE_HAS_LIBEGL_WAYLAND
ACK.
Quoted 3 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/2 package/opengl/libgbm: new virtual package
Quoted 13 lines · Thomas Petazzoni
Hello,
Quoted 8 lines · Einar J?n
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 (supportgbm_boand GCC7).
http://www.ti.com/tool/PROCESSOR-SDK-AM335X
Quoted 8 lines
Quoted 3 lines
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).
Quoted 12 lines
Quoted 9 lines
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
selectBR2_PACKAGE_WAYLAND
selectBR2_PACKAGE_HAS_LIBEGL_WAYLANDACK.
Quoted 7 lines
Quoted 3 lines
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.
Signature · 2 lines
Regards Einar J?n
PATCH 1/2 package/opengl/libgbm: new virtual package
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(+)
Quoted 63 lines · Einar J?n
Quoted 13 lines · Thomas Petazzoni
Hello,
Quoted 8 lines · Einar J?n
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 (supportgbm_boand GCC7).
http://www.ti.com/tool/PROCESSOR-SDK-AM335XQuoted 8 lines
Quoted 3 lines
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).
Quoted 12 lines
Quoted 9 lines
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
selectBR2_PACKAGE_WAYLAND
selectBR2_PACKAGE_HAS_LIBEGL_WAYLANDACK.
Quoted 7 lines
Quoted 3 lines
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
Signature · 3 lines
Regards Einar J?n +31 610 957234
PATCH 1/2 package/opengl/libgbm: new virtual package
Hello Einar,
Quoted 3 lines · Einar J?n
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) ?
Quoted 1 line
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
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/2 package/opengl/libgbm: new virtual package
Quoted 11 lines · Thomas Petazzoni
Hello Einar,
Quoted 3 lines · Einar J?n
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.
Quoted 3 lines
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
Signature · 2 lines
Regards Einar J?n
PATCH 1/2 package/opengl/libgbm: new virtual package
Hi Einar, Bernd,
Quoted 14 lines · Einar J?n
Quoted 11 lines · Thomas Petazzoni
Hello Einar,
Quoted 3 lines · Einar J?n
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) ?
Quoted 8 lines
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
Quoted 7 lines
Quoted 4 lines
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