System Environment: -------------------------- Distro: F17 Arch: x86_64 wayland (master) heads/master-0-gc1fd097 fontconfig (master) heads/master-0-g338ffe6 drm (master) heads/master-0-gfea5408 mesa (master) heads/master-0-g07cdf42 libxkbcommon (master) heads/master-0-g7f1b7a1 pixman (master) heads/master-0-g279bdcd cairo (master) heads/master-0-g3cd6c59 weston (master) heads/master-0-gc30c4bd Detailed Description: ----------------------------- Running weston or weston-launch results in just a black screen popping up. Happens in both X11 and DRM backends. I've tested this on two machines, the one above (F17) and on Ubuntu 13.04 - both of them use an Intel graphics chip. The mesa commit that causes this issue is: 00a945f61e5d3e1a28fd20fcd18402b9300d1ca8 Before this commit Weston would launch successfully. Steps to Reproduce: ---------------------------- 1. Start weston or weston-launch under DRM backend or X11 backend.
After additional research it's been discovered this bug is observed only if you are NOT using cairo-gl; so recompile cairo without --enable-gl and this bug can be observed.
After upgrading git mesa I got the same issue. Distro: Debian jessie/sid Arch: x86_64 The latest git versions of wayland and weston.
(In reply to comment #1) > After additional research it's been discovered this bug is observed only if > you are NOT using cairo-gl; so recompile cairo without --enable-gl and this > bug can be observed. Furthermore, when using Weston on cairo-gl, no mouse cursor is displayed and shm based clients render as solid black surfaces. Hence, shm rendering seems to be the broken piece here.
I see what happened. Weston's GL renderer used to have an #ifdef GL_UNPACK_ROW_LENGTH check to check the availability of the GL_EXT_unpack_subimage extension in the GLES2 headers. The said Mesa commit renamed GL_UNPACK_ROW_LENGTH to GL_UNPACK_ROW_LENGTH_EXT. That caused the Weston build to think that GL_EXT_unpack_subimage is not available at build time, so it never compiled that code at all. However, the runtime check for GL_EXT_unpack_subimage in the GL extension string was not protected with an #ifdef, and when Weston ran, it found the extension. The end result is, that gl_renderer_flush_damage() did not do a plain glTexImage2D because GL_EXT_unpack_subimage was available, and it did not try glTexSubImage2D either because the code was not compiled. So it never uploaded the texture.
commit 1c4f163c6d74c8aab69d2dbb9a03dc0e0e80f374 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Aug 7 12:11:27 2013 -0700 gl-renderer: Only check for subimage when we have extension at compile time If weston is compiled against a gl2ext.h that doesn't have the subimage extension, but then run against a gles2 library that does provide it, we end up disabling the glTexImage2D falback without having the subimage code paths compiled in. commit 59758a8a9e732dfda83b87fb0082af3c924d3530 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Aug 7 12:05:08 2013 -0700 Add workaround for broken GL_EXT_unpack_subimage tokens Earlier versions of gl2ext.h defined the GL_EXT_unpack_subimage tokens without the _EXT suffix. That's been fixed and we're using the _EXT tokens now, but just in case we're using an older, broken header, define the _EXT tokens manually. commit ce7a5d8794831732127632ee60531b81f444625e Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Aug 7 09:55:07 2013 -0700 gl-renderer: Test for GL_EXT_unpack_subimage not GL_UNPACK_ROW_LENGTH It is defined by the mesa #include, which is just a copy of the official Khronos header. It's just defined in a different section than the extension tokens. In the mean time, the extension tokens were renamed to add a _EXT suffix (eg GL_UNPACK_ROW_LENGTH -> GL_UNPACK_ROW_LENGTH_EXT) and we silently failed to used the subimage extension.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.