Bug 73485

Summary:	Compositor Bypass does not work on secondary display
Product:	Wayland	Reporter:	Anu Reddy <anasuyax.r.nannuri>
Component:	wayland	Assignee:	Wayland bug list <wayland-bugs>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Anu Reddy 2014-01-10 21:21:58 UTC

When weston-terminal or weston-simple-egl is fullscreen mode on secondary display, compositing is not bypassed (always in green shade). 

1. Two cold plugged displays 
2. Identify display1 as primary and display2 as secondary
3. execute weston-launch
4. Press <mod>+<shift>+<space>+s. Both the displays will have green overlay
5. Launch weston-terminal on display1
6. Press <f11> for terminal fullscreen mode from display1.
7. Observe compositor bypasses the green overlay and the display1 will not have green shade(correct)
8. Launch weston-terminal on display2 
9. Press <f11> for terminal fullscreen from display2 
10. Observe compositing is not bypassed. Display2 still have green shade(Incorrect)


Expected result:
weston-terminal or weston-simple-egl is in fullscreen mode, compositing should be bypassed and evident by no green shade on display2. This means weston should communicate directly with the client on Multi display.


wayland (HEAD) remotes/origin/master-0-gcd0dccd
drm (HEAD) libdrm-2.4.50-0-g4c5de72
mesa (HEAD) remotes/origin/10.0-0-ge833368
libva (HEAD) libva-1.2.1-0-g88ed1eb
intel-driver (HEAD) 1.2.1-0-g8f306e3
weston (HEAD) remotes/origin/master-0-g917711b

Comment 1 Kristian Høgsberg 2014-01-17 22:27:14 UTC

commit 1be87e3c8155204852509f47f8e239b479da6feb
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Fri Jan 17 14:22:41 2014 -0800

    compositor-drm: Make composite bypass work on secondary outputs
    
    The opaque region is in surface coordinates, which we compare to the
    output region, which is in compositor coordinates.  For non-primary
    outputs, that means that the output region is not located at 0,0 but
    something like 1920,0 instead.  That means that the output region isn't
    contained in the surface opaque region and then we decide we can't scan
    out from it.
    
    Instead, compare the surface opaque region to the output region
    translated to 0,0.
    
    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=7348i5

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.