| Message ID | 6d4c564432948310ca9502dc94c2d50a7c97f460.1471968455.git.yann.morin.1998@free.fr |
|---|---|
| State | Accepted |
| Headers | show |
Hello, On Tue, 23 Aug 2016 18:26:32 +0200, Yann E. MORIN wrote: > Wayland requires that an OpenGL/EGL implementation provides a few > extensions, so that wayland servers and clients can exchange buffers. > > Currently, only one OpenGL/EGL implementation provides those extensions: > mesa3d. > > However, other implementations are catching up, especially the > proprietary NVidia driver, which has as of late introduced those > extensions. Other, non-public implementations may also provide those > extensions. > > A lot of wayland-related packages require those extensions, and > currently they have to depend on mesa3d to provide OpenGL/EGL, which > precludes using those packages when a non-mesa3d provider is enabled, > even when that providers implements the necessary extensions. > > Add an option to the libegl virtual package, that providers on > OpenGL/EGL can select to state they provide those extensions. > > Pacakges that need those extensions can additionally depend on this new > option, instead of the existing libegl package. > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > --- > package/opengl/libegl/Config.in | 4 ++++ > 1 file changed, 4 insertions(+) Applied to next, thanks. One thing that surprises me though is that weston itself doesn't use this new option, and still has: config BR2_PACKAGE_WESTON_DRM bool "DRM compositor" depends on BR2_PACKAGE_MESA3D_OPENGL_EGL select BR2_PACKAGE_LIBDRM select BR2_PACKAGE_WESTON_HAS_COMPOSITOR # Uses libgbm from mesa3d comment "DRM compositor needs an OpenGL EGL backend provided by mesa3d" depends on !BR2_PACKAGE_MESA3D_OPENGL_EGL So it's weird to have a new OpenGL implementation that is said to be Wayland capable, but doesn't allow to build the reference Wayland implementation. Thomas
Thomas, All, On 2016-08-23 22:02 +0200, Thomas Petazzoni spake thusly: > On Tue, 23 Aug 2016 18:26:32 +0200, Yann E. MORIN wrote: > > Wayland requires that an OpenGL/EGL implementation provides a few > > extensions, so that wayland servers and clients can exchange buffers. > > > > Currently, only one OpenGL/EGL implementation provides those extensions: > > mesa3d. > > > > However, other implementations are catching up, especially the > > proprietary NVidia driver, which has as of late introduced those > > extensions. Other, non-public implementations may also provide those > > extensions. > > > > A lot of wayland-related packages require those extensions, and > > currently they have to depend on mesa3d to provide OpenGL/EGL, which > > precludes using those packages when a non-mesa3d provider is enabled, > > even when that providers implements the necessary extensions. > > > > Add an option to the libegl virtual package, that providers on > > OpenGL/EGL can select to state they provide those extensions. > > > > Pacakges that need those extensions can additionally depend on this new > > option, instead of the existing libegl package. > > > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > > --- > > package/opengl/libegl/Config.in | 4 ++++ > > 1 file changed, 4 insertions(+) > > Applied to next, thanks. > > One thing that surprises me though is that weston itself doesn't use > this new option, and still has: > > config BR2_PACKAGE_WESTON_DRM > bool "DRM compositor" > depends on BR2_PACKAGE_MESA3D_OPENGL_EGL > select BR2_PACKAGE_LIBDRM > select BR2_PACKAGE_WESTON_HAS_COMPOSITOR > > # Uses libgbm from mesa3d > comment "DRM compositor needs an OpenGL EGL backend provided by mesa3d" > depends on !BR2_PACKAGE_MESA3D_OPENGL_EGL > > So it's weird to have a new OpenGL implementation that is said to be > Wayland capable, but doesn't allow to build the reference Wayland > implementation. That's because not everything was converted. Yet. Regards, Yann E. MORIN.
Hello, On Tue, 23 Aug 2016 23:43:51 +0200, Yann E. MORIN wrote: > > One thing that surprises me though is that weston itself doesn't use > > this new option, and still has: > > > > config BR2_PACKAGE_WESTON_DRM > > bool "DRM compositor" > > depends on BR2_PACKAGE_MESA3D_OPENGL_EGL > > select BR2_PACKAGE_LIBDRM > > select BR2_PACKAGE_WESTON_HAS_COMPOSITOR > > > > # Uses libgbm from mesa3d > > comment "DRM compositor needs an OpenGL EGL backend provided by mesa3d" > > depends on !BR2_PACKAGE_MESA3D_OPENGL_EGL > > > > So it's weird to have a new OpenGL implementation that is said to be > > Wayland capable, but doesn't allow to build the reference Wayland > > implementation. > > That's because not everything was converted. Yet. OK, this is definitely a good explanation. So I should take it that you expect Weston to build and work with the latest version of the NVidia driver? Thanks, Thomas
Thomas, All, On 2016-08-23 23:58 +0200, Thomas Petazzoni spake thusly: > On Tue, 23 Aug 2016 23:43:51 +0200, Yann E. MORIN wrote: > > > > One thing that surprises me though is that weston itself doesn't use > > > this new option, and still has: > > > > > > config BR2_PACKAGE_WESTON_DRM > > > bool "DRM compositor" > > > depends on BR2_PACKAGE_MESA3D_OPENGL_EGL > > > select BR2_PACKAGE_LIBDRM > > > select BR2_PACKAGE_WESTON_HAS_COMPOSITOR > > > > > > # Uses libgbm from mesa3d > > > comment "DRM compositor needs an OpenGL EGL backend provided by mesa3d" > > > depends on !BR2_PACKAGE_MESA3D_OPENGL_EGL > > > > > > So it's weird to have a new OpenGL implementation that is said to be > > > Wayland capable, but doesn't allow to build the reference Wayland > > > implementation. > > > > That's because not everything was converted. Yet. > > OK, this is definitely a good explanation. So I should take it that you > expect Weston to build and work with the latest version of the NVidia > driver? Eventually. Eventually... ;-) To be honest, this is not my highest priority for 2016.11; I have multi br2-external and systemd skeleton to handle first. This quick egl-wayland series (which I did not expect would be applied so fast!) was just a little distraction along the way. ;-) But at least, it paves the way toward more egl-wayland providers and users. As for Weston and the DRM compositor, I guess Gustavo did with what we had at the time... And I'm not totally up-to-speed with all the complexity of the graphics stack... Regards, Yann E. MORIN.
Hello, On Wed, 24 Aug 2016 00:06:12 +0200, Yann E. MORIN wrote: > > OK, this is definitely a good explanation. So I should take it that you > > expect Weston to build and work with the latest version of the NVidia > > driver? > > Eventually. Eventually... ;-) > > To be honest, this is not my highest priority for 2016.11; I have multi > br2-external and systemd skeleton to handle first. Sure, makes perfect. I was certainly not asking for this to be *done*, but more on what is the general direction we are going to. > This quick egl-wayland series (which I did not expect would be applied > so fast!) was just a little distraction along the way. ;-) But at least, > it paves the way toward more egl-wayland providers and users. Sure. IMO it also makes the libgtk3 dependency a little bit easier to understand, which is also why I applied it quickly. Thanks, Thomas
diff --git a/package/opengl/libegl/Config.in b/package/opengl/libegl/Config.in index 8401bb2..f756fbe 100644 --- a/package/opengl/libegl/Config.in +++ b/package/opengl/libegl/Config.in @@ -1,6 +1,10 @@ config BR2_PACKAGE_HAS_LIBEGL bool +config BR2_PACKAGE_HAS_LIBEGL_WAYLAND + bool + depends on BR2_PACKAGE_HAS_LIBEGL + config BR2_PACKAGE_PROVIDES_LIBEGL depends on BR2_PACKAGE_HAS_LIBEGL string
Wayland requires that an OpenGL/EGL implementation provides a few extensions, so that wayland servers and clients can exchange buffers. Currently, only one OpenGL/EGL implementation provides those extensions: mesa3d. However, other implementations are catching up, especially the proprietary NVidia driver, which has as of late introduced those extensions. Other, non-public implementations may also provide those extensions. A lot of wayland-related packages require those extensions, and currently they have to depend on mesa3d to provide OpenGL/EGL, which precludes using those packages when a non-mesa3d provider is enabled, even when that providers implements the necessary extensions. Add an option to the libegl virtual package, that providers on OpenGL/EGL can select to state they provide those extensions. Pacakges that need those extensions can additionally depend on this new option, instead of the existing libegl package. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> --- package/opengl/libegl/Config.in | 4 ++++ 1 file changed, 4 insertions(+)