Bug 73905 - Weston clients receive key events while Weston is locked
Summary: Weston clients receive key events while Weston is locked
Status: VERIFIED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-22 00:42 UTC by Anu Reddy
Modified: 2014-05-08 17:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Anu Reddy 2014-01-22 00:42:49 UTC
Steps:
1. Launch Weston : weston-launch -- -i5
2. Execute weston-terminal
3. Allow Weston to sleep
4. Type weston-flower and press <enter> using keyboard  
5. click on the green circle to unlock the screen
6. Observe weston-flower on the screen


Software Stack
wayland (HEAD) remotes/origin/master-0-g47bbc6b
drm (HEAD) libdrm-2.4.50-0-g4c5de72
mesa (HEAD) remotes/origin/10.0-0-g3a62718
libva (HEAD) libva-1.2.1-0-g88ed1eb
intel-driver (HEAD) 1.2.1-0-g8f306e3
weston (HEAD) 1.3.93-0-g7cccfca
Comment 1 Neil Roberts 2014-04-07 17:29:36 UTC
It looks like the culprit is this commit from July 2012:

http://cgit.freedesktop.org/wayland/weston/commit/?id=2f5faff7f9142f07a872

In the lock function in shell.c there used to be a call to push_focus_state which would remove the focus from all of the seats. That commit removed it so now the surfaces retain keyboard focus when the compositor is locked.
Comment 2 Neil Roberts 2014-04-09 14:28:45 UTC
Another symptom of this bug is that if you switch to a workspace with no surfaces then the active surface from the last workspace will retain focus. For example if you create a terminal window in one workspace and then switch to a blank one you can still type in the invisible terminal on other workspace.
Comment 4 Kristian Høgsberg 2014-04-10 16:48:15 UTC
Committed to master:

commit 4237f50e11826445319864518289ba1733e11223
Author: Neil Roberts <neil@linux.intel.com>
Date:   Wed Apr 9 16:33:31 2014 +0100

    Reset focus on unknown seats when restoring focus state
    
    The focus_state list on a workspace only contains entries for seats
    which have a keyboard focus on that workspace. For workspaces that
    have no surfaces the list will be empty. That means that when a
    workspace with no surfaces is switched to it would previously leave
    the keyboard focus unaffected and you could still type in the surface
    on the old workspace.
    
    This patch makes it instead reset the keyboard focus to NULL for seats
    without a focus_state. It does this by temporarily stealing the
    compositor's list of seats while it iterates the focus_states. After
    all of the focus states have been processed any seats remaining in
    this temporary list have their focus reset.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=73905

and

commit b4a91708e3c440e2d56d476ce71e82af8f79563f
Author: Neil Roberts <neil@linux.intel.com>
Date:   Wed Apr 9 16:33:32 2014 +0100

    Reset the keyboard focus on all seats when the compositor is locked
    
    Before commit 2f5faff7f9142 when the compositor is locked it would
    reset the keyboard focus on all of the seats as part of pushing the
    focus_state. This was removed because it now always keeps track of the
    focus_state in the workspace instead of waiting until the state is
    pushed. However this had the side effect that the active surface would
    retain focus when the compositor is locked. This patch just makes it
    explicitly set the keyboard focus to NULL on all of the seats when
    locking. This will be restored based on the workspace's state when
    unlocking.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=73905


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.