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 work
On Wed, 09 Apr 2014 17:08:23 +0100
Neil Roberts wrote:
> "Jasper St. Pierre" 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 c
"Jasper St. Pierre" 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 a
Why is this necessary? Won't events never be delivered while locked anyway?
On Apr 9, 2014 8:36 AM, "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 beca
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 t
