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
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
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
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
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.
