Re: [PATCH weston 2/2] Reset the keyboard focus on all seats when the compositor is locked
On Wed, 09 Apr 2014 17:08:23 +0100 Neil Roberts n...@linux.intel.com wrote: Jasper St. Pierre jstpie...@mecheye.net writes: Why is this necessary? Won't events never be delivered while locked anyway? Events do seem to get delivered, you can try it if you run weston -i5 and then open a terminal and let it lock. You can still type in the terminal and launch programs. Yeah. The original design was because it is just easier to control focus rather than to explicitly check what should be getting which events under various conditions. So, take away focus, and put the lock surface on top. The surfaces are still below the lock surface, but you cannot click them or access any other way, so they won't get focus, and the lock holds. Or at least it was something like that once upon a time. Maybe nowadays we actually remove a list from the layers list, I haven't checked, but if you don't explicitly remove focus, a surface will still get input. Also need to make sure the hidden surfaces cannot regain focus. But yeah, I guess an alternative solution could be to block it at a lower level in the input handling code. I'm not sure whether that's a good idea though because eventually we might want a password entry or something on the lock screen and then we would want the keyboard to work. It would a shame to have to put too much special magic in there to get that to work. Indeed. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/2] Reset the keyboard focus on all seats when the compositor is locked
On Wed, Apr 09, 2014 at 04:33:32PM +0100, Neil Roberts wrote:
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.
Right, nice and simple. Patch applied, thanks.
Kristian
https://bugs.freedesktop.org/show_bug.cgi?id=73905
---
desktop-shell/shell.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index fa081f3..b19965f 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -4498,6 +4498,19 @@ touch_to_activate_binding(struct weston_seat *seat,
uint32_t time, void *data)
}
static void
+unfocus_all_seats(struct desktop_shell *shell)
+{
+ struct weston_seat *seat, *next;
+
+ wl_list_for_each_safe(seat, next, shell-compositor-seat_list, link) {
+ if (seat-keyboard == NULL)
+ continue;
+
+ weston_keyboard_set_focus(seat-keyboard, NULL);
+ }
+}
+
+static void
lock(struct desktop_shell *shell)
{
struct workspace *ws = get_current_workspace(shell);
@@ -4523,6 +4536,11 @@ lock(struct desktop_shell *shell)
launch_screensaver(shell);
+ /* Remove the keyboard focus on all seats. This will be
+ * restored to the workspace's saved state via
+ * restore_focus_state when the compositor is unlocked */
+ unfocus_all_seats(shell);
+
/* TODO: disable bindings that should not work while locked. */
/* All this must be undone in resume_desktop(). */
--
1.8.5.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 2/2] 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
---
desktop-shell/shell.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index fa081f3..b19965f 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -4498,6 +4498,19 @@ touch_to_activate_binding(struct weston_seat *seat,
uint32_t time, void *data)
}
static void
+unfocus_all_seats(struct desktop_shell *shell)
+{
+ struct weston_seat *seat, *next;
+
+ wl_list_for_each_safe(seat, next, shell-compositor-seat_list, link) {
+ if (seat-keyboard == NULL)
+ continue;
+
+ weston_keyboard_set_focus(seat-keyboard, NULL);
+ }
+}
+
+static void
lock(struct desktop_shell *shell)
{
struct workspace *ws = get_current_workspace(shell);
@@ -4523,6 +4536,11 @@ lock(struct desktop_shell *shell)
launch_screensaver(shell);
+ /* Remove the keyboard focus on all seats. This will be
+* restored to the workspace's saved state via
+* restore_focus_state when the compositor is unlocked */
+ unfocus_all_seats(shell);
+
/* TODO: disable bindings that should not work while locked. */
/* All this must be undone in resume_desktop(). */
--
1.8.5.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/2] Reset the keyboard focus on all seats when the compositor is locked
Why is this necessary? Won't events never be delivered while locked anyway?
On Apr 9, 2014 8:36 AM, Neil Roberts n...@linux.intel.com wrote:
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
---
desktop-shell/shell.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index fa081f3..b19965f 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -4498,6 +4498,19 @@ touch_to_activate_binding(struct weston_seat *seat,
uint32_t time, void *data)
}
static void
+unfocus_all_seats(struct desktop_shell *shell)
+{
+ struct weston_seat *seat, *next;
+
+ wl_list_for_each_safe(seat, next, shell-compositor-seat_list,
link) {
+ if (seat-keyboard == NULL)
+ continue;
+
+ weston_keyboard_set_focus(seat-keyboard, NULL);
+ }
+}
+
+static void
lock(struct desktop_shell *shell)
{
struct workspace *ws = get_current_workspace(shell);
@@ -4523,6 +4536,11 @@ lock(struct desktop_shell *shell)
launch_screensaver(shell);
+ /* Remove the keyboard focus on all seats. This will be
+* restored to the workspace's saved state via
+* restore_focus_state when the compositor is unlocked */
+ unfocus_all_seats(shell);
+
/* TODO: disable bindings that should not work while locked. */
/* All this must be undone in resume_desktop(). */
--
1.8.5.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/2] Reset the keyboard focus on all seats when the compositor is locked
Jasper St. Pierre jstpie...@mecheye.net writes: Why is this necessary? Won't events never be delivered while locked anyway? Events do seem to get delivered, you can try it if you run weston -i5 and then open a terminal and let it lock. You can still type in the terminal and launch programs. But yeah, I guess an alternative solution could be to block it at a lower level in the input handling code. I'm not sure whether that's a good idea though because eventually we might want a password entry or something on the lock screen and then we would want the keyboard to work. It would a shame to have to put too much special magic in there to get that to work. - Neil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
