Bug 70250 - weston-terminal rendering corrupted with output transform 90 and 270
weston-terminal rendering corrupted with output transform 90 and 270
Product: Mesa
Classification: Unclassified
Component: EGL/Wayland
Other All
: medium normal
Assigned To: Wayland bug list
Depends on:
  Show dependency treegraph
Reported: 2013-10-07 19:04 UTC by U. Artie Eoff
Modified: 2013-12-10 12:47 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

weston-terminal rendering corruption (2.22 MB, video/webm)
2013-10-07 19:04 UTC, U. Artie Eoff

Note You need to log in before you can comment on or make changes to this bug.
Description U. Artie Eoff 2013-10-07 19:04:44 UTC
Created attachment 87252 [details]
weston-terminal rendering corruption

The weston-terminal has various rendering issues when the Weston output is transformed at 90, 270, flipped-90, or flipped-270 on drm-backend:

1. The terminal output gets "chopped" off and/or flickers at chopped axis.
2. The terminal window decorations get corrupted.

See attached wcap clip which highlights the issues.

wayland (HEAD) 1.2.92-0-g260d73b
drm (HEAD) libdrm-2.4.46-0-gc6d73cf
mesa (9.2) heads/9.2-0-gfac3094
libva (HEAD) libva-1.2.1-0-g88ed1eb
intel-driver (HEAD) 1.2.1-0-g8f306e3
weston (HEAD) 1.2.92-0-g8d7bef2
Comment 1 U. Artie Eoff 2013-10-11 00:45:57 UTC
This issue is *not* observed on the x11-backend.  It *does* happen on the drm-backend.  I have not tested other backends.
Comment 2 Kristian Høgsberg 2013-10-26 05:15:53 UTC
This is something that we discussed on the list when we talked about buffer transforms (scaling or rotation).  The problem is that EGL sends damage requests and is supposed to send in the surface coordinate system.  EGL only knows the buffer coordinate system and doesn't know if there is a buffer transform and sends damage in buffer space.

This means that for 90 or 270 rotated buffers, we swap width and height in the damage requests.  One workaround is to just damage a really big area so that we're sure to damage the entire surface:

diff --git a/src/egl/drivers/dri2/platform_wayland.c b/src/egl/drivers/dri2/plat
index c0de16b..3d39113 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -550,6 +550,9 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv,
    if (n_rects == 0) {
       wl_surface_damage(dri2_surf->wl_win->surface, 0, 0,
                         dri2_surf->base.Width, dri2_surf->base.Height);
+      wl_surface_damage(dri2_surf->wl_win->surface, 0, 0, 2 << 16, 2 << 16);
    } else {
       for (i = 0; i < n_rects; i++) {
          const int *rect = &rects[i * 4];

For EGL_swap_buffers_with_damage, we push the problem higher up the stack where the caller of eglSwapBuffersWithDamage should be able to pass in damage coordinates in surface space.
Comment 3 Kristian Høgsberg 2013-12-05 00:14:33 UTC
commit bce64c6c83122b1f4a684cc7890c7a61d2f9ffd7
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Wed Dec 4 16:13:35 2013 -0800

    egl/wayland: Damage INT32_MAX x INT32_MAX region for eglSwapBuffers
    If we're not using EGL_EXT_swap_buffers_with_damage, we have to
    damage the full extent.  EGL operates on buffer coordinates, but
    wl_surface.damage takes surface coordinates.  EGL doesn't know the
    buffer transformation (rotated or scaled) and can't post accurate
    damage in surface coordinates.  The damage event however is clipped to
    the surface extents so we can just damage the maximum rectangle.
    In case of EGL_EXT_swap_buffers_with_damage, the application knows
    the buffer transform and is expected to pass in rectangles in
    surface space.
    Cc: "10.0" mesa-stable@lists.freedesktop.org
Comment 4 Ian Romanick 2013-12-10 01:39:20 UTC

Did this fix the problem for you?  There's no Reviewed-by on the patch, so I want *something* before I cherry pick it over to stable.

Comment 5 Ian Romanick 2013-12-10 01:40:18 UTC
Since you marked the bug as VERIFIED, I'll call that a Tested-by.  Sorry for the noise.
Comment 6 U. Artie Eoff 2013-12-10 12:47:35 UTC
(In reply to comment #5)
> Since you marked the bug as VERIFIED, I'll call that a Tested-by.  Sorry for
> the noise.

Correct.  This is how I've been doing it over here in "Wayland Land"... marking the bug as VERIFIED, that is, to indicate the bug resolution has been tested and/or accepted.

If there's a general process for Mesa bugs and patch reviewing point me to it and I'll be more than happy to comply :-)