Bug 68221 - Some issues when running an embedded westion session inside weston
Summary: Some issues when running an embedded westion session inside weston
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-17 14:53 UTC by Axel Davy
Modified: 2013-10-31 06:33 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Axel Davy 2013-08-17 14:53:46 UTC
When running a weston session inside another weston session, there are some event handling issues.


One simple test is to open weston-terminal in the embedded session:
. type a long sentence
. keep backspace pressed to suppress everything.

You expect to see every letter disappear one by one, but you don't: you unpress backspace and everything has disappeared at the same time.

Then do the same thing, but with moving the mouse when suppressing the sentence: you see every letter disappear one by one, everything works as expected.

A second test is to run weston-gears inside the embedded session.
In the top session, open weston-terminal and type something in it.
The embedded session looks freezed, and when the mouse return onto it, weston-gears starts again and the terminal shows that some frames are missing (you didn't hit 60fps).

If you run weston-gears with WAYLAND_DEBUG, there are no issues. Same if you launch weston-simple-egl or weston-simple-shm at the same time.


This bug was discovered when using Wayland 1.2 and Weston 1.2 (The bug is still here with Weston git)
Comment 1 Axel Davy 2013-08-18 09:40:09 UTC
I tried using gdb to find the root of this problem,
and it looks the issue arise in such situation:

. For one frame there is no commit: no repaint is scheduled, no frame handler and new commit are done by weston (the embedded one).
. there is a commit by a client. idle_repaint is called to start again the process of drawing the frames and creating a frame handler.
. But just after this idle_repaint, wl_display_run is blocked in wl_event_loop_dispatch.
Comment 2 Kristian Høgsberg 2013-10-31 06:33:00 UTC
commit 286ff6817b7b127aae30b1daa4e5cb1a69880b72
Author: Jason Ekstrand <jason@jlekstrand.net>
Date:   Sun Oct 27 22:24:57 2013 -0500

    compositor-wayland: Flush the display on commit
    
    This fixes the problem where animations will wait to play until input is
    received.  In general, it also makes the backend far more responsive.
    
    Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
    
    https://bugs.freedesktop.org/show_bug.cgi?id=68221


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.