Created attachment 60046 [details] black blocks are flowers when it is normal. System Environment: -------------------------- Arch: i386 Libdrm: (master)2.4.33-12-g292da616fe1f936ca78a3fa8e1b1b19883e343b6 Wayland: (master)677c5180e67be18b7a0867fafb7f205b57a6e9ff Mesa: (master)847c89870238fe5813e89831b38d5fab5356158c Cairo: (master)40d6c580cd029f3d330ba28a7728ff36498920cb Xkbcommon: (master)3d672fcfea6b823db4793b9ad1c3aadc4b547a08 Weston: (master)eb04ddb1b651543a46e7d2b87ff3a43070eb8579 Kernel: (drm-intel-next-queued)ec34a01de31128e5c08e5f05c47f4a787f45a33c Bug detailed description: ----------------------------- This issue happens on all platforms. dnd run with black blocks when weston call cairo-gl branch. Reproduce steps: ---------------------------- wayland test 1. start weston 2. ./dnd
Simple investigation shows: when build against cairo-gl, display_create_egl_window_surface() is using type(struct egl_window_surface_data) to set_user_data, while display_get_buffer_for_surface() is using type (struct surface_data) to get_user_data. Two structures are incompatible
(In reply to comment #1) > Simple investigation shows: > when build against cairo-gl, display_create_egl_window_surface() is using > type(struct egl_window_surface_data) to set_user_data, while > display_get_buffer_for_surface() is using type (struct surface_data) to > get_user_data. Two structures are incompatible That's not the cause of the black boxes bug, but that does cause the dnd client to terminate when a drag is started, since it sends garbage as the wl_buffer for the surface attach in dnd_button_handler(). The black boxes problem is that since weston commit bad42973 [1], the cairo surfaces for the dnd items is created from an wl_egl_window. This surface will have an embeded operand of type CAIRO_GL_OPERAND_TEXTURE, but no texture is actually created. The end result is that texture 0 is bound on _cairo_gl_context_setup_operand(). [1] commit bad429738087a851ab293e5a9329efdf30393333 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Tue Apr 10 11:49:45 2012 -0400 window: Drop EGLImage surface type
> > > Reproduce steps: > ---------------------------- > wayland test > 1. start weston > 2. ./dnd > > It's the same here. dnd exhibits black squares for dnd objects and clicking on any of them cause a crash with "read error: Broken pipe" Scott
(In reply to comment #2) > (In reply to comment #1) > > Simple investigation shows: > > when build against cairo-gl, display_create_egl_window_surface() is using > > type(struct egl_window_surface_data) to set_user_data, while > > display_get_buffer_for_surface() is using type (struct surface_data) to > > get_user_data. Two structures are incompatible > > That's not the cause of the black boxes bug, but that does cause the dnd client > to terminate when a drag is started, since it sends garbage as the wl_buffer > for the surface attach in dnd_button_handler(). You are right :)
(In reply to comment #2) > The black boxes problem is that since weston commit bad42973 [1], the cairo > surfaces for the dnd items is created from an wl_egl_window. This surface will > have an embeded operand of type CAIRO_GL_OPERAND_TEXTURE, but no texture is > actually created. The end result is that texture 0 is bound on > _cairo_gl_context_setup_operand(). Moving bug to cairo. The thing that does not work here is doing something like this: item_surface = cairo_gl_surface_create_for_egl(); cr = cairo_create(item_surface); ... cairo_paint(cr); cairo_destroy(cr); and later surface = cairo_gl_surface_create_for_egl(); cr = cairo_create(surface); ... cairo_set_operator(cr, CAIRO_OPERATOR_OVER); cairo_set_source_surface(cr, item_surface, x, y); cairo_paint(cr);
Created attachment 60397 [details] [review] Workaround for the issue
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/211.
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.