Hi Daniel,
On Fri, 10 Mar 2023 at 14:28, Levin, Daniel wrote:
> We are currently attempting to update from Weston 9.0.0 to Weston 10+ and
> facing issues with GLES2 compatibility at both build time and run time.
>
> For instance, gl_renderer_setup() exits with error if GL_EXT_unpack_subimage
> is not present. Other code explicitly includes GLES3/gl3.h and uses pixel
> formats from GL_EXT_texture_storage.
>
> We are using Mali 400 with proprietary Arm userspace GL drivers, which
> supports only GLES2 without extensions above.
>
> Could you please clarify whether for Weston 10+ GLES3 is now mandatory
> dependency? Was this highlighted in any release notes?
>
> If so, then we have to freeze Weston on version 9.0.0.
That did indeed change. We require GLES3 headers at build time (no
requirement for ES3 runtime contexts), and we do require
GL_EXT_unpack_subimage.
It's safe to use newer header sets than your driver supports; you
could just take the headers directly from Khronos, or from Mesa, and
build against those whilst using your other driver at runtime.
GL_EXT_unpack_subimage also has no hardware dependency. It's literally
about two lines to implement in software. If your proprietary driver
can't support this, I strongly recommend switching to the Lima driver
shipped as part of the Linux kernel and Mesa.
> Could you please explain is it safe to keep updating all other Wayland
> components (client, protocols, xwayland), and keep only Weston compositor
> downgraded to 9.0.0? I tested and see that such combination works properly.
> Though I am not sure if that is the correct approach, or it might cause
> issues. And instead we have to downgrade all the Wayland components to the
> same older version (in our case: client 1.19, protocols 1.21, weston 9.0.0).
It's completely safe to use newer wayland + wayland-protocols + etc
with an older Weston.
Cheers,
Daniel
