On 02/26/2013 09:01 AM, Kristian Høgsberg wrote:
You're confusing keyboard and pointer focus. The pointer_lock kicks
in when the surface receive keyboard focus, not pointer focus. It
would be very nasty if just mousing over a surface would lock the
pointer.
Kristian
Okay that makes a lot mo
On Tue, Feb 26, 2013 at 11:55 AM, Bill Spitzak wrote:
> On 02/25/2013 09:28 PM, Daniel Stone wrote:
>
>> I suppose there still is a race if the user hits the lock-cursor
>> button and then moves the mouse out so fast that it exits before the
>> client sends the lock request. But this i
On 02/25/2013 09:28 PM, Daniel Stone wrote:
I suppose there still is a race if the user hits the lock-cursor
button and then moves the mouse out so fast that it exits before the
client sends the lock request. But this is a lot harder to hit that
the quick enter+exit one.
That's
On Tue, 26 Feb 2013 14:57:12 +0200
Pekka Paalanen wrote:
> On Mon, 25 Feb 2013 21:24:47 -0500
> Kristian Høgsberg wrote:
>
> > The pointer_lock interface is modelled after the HTML5 pointer lock
> > extension:
> >
> > https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
> >
> > Th
On Mon, 25 Feb 2013 21:24:47 -0500
Kristian Høgsberg wrote:
> The pointer_lock interface is modelled after the HTML5 pointer lock
> extension:
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
>
> The extension allows a wayland client to lock the pointer while a surface
> is
On 25 February 2013 20:12, Bill Spitzak wrote:
> I think you are right, that removes the race condition where the pointer
> exits before the client sends the lock. If the client wants to lock when
> the user hits a button always, it can just release on the leave event.
>
> I suppose there still i
I think you are right, that removes the race condition where the pointer
exits before the client sends the lock. If the client wants to lock when
the user hits a button always, it can just release on the leave event.
I suppose there still is a race if the user hits the lock-cursor button
and t
On Mon, Feb 25, 2013 at 9:48 PM, Bill Spitzak wrote:
> The pointer lock is a one-shot (ie on exit and enter the pointer is not
> locked again), right?
It's intended as a persistent condition for the surface. Whenever the
surface receive keyboard focus, the pointer lock is activated. This
stays
The pointer lock is a one-shot (ie on exit and enter the pointer is not
locked again), right?
Kristian Høgsberg wrote:
The pointer_lock interface is modelled after the HTML5 pointer lock
extension:
+
+
+ The lock_pointer request lets the client disable pointer
+ motion
The pointer_lock interface is modelled after the HTML5 pointer lock
extension:
https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
The extension allows a wayland client to lock the pointer while a surface
is active. While the pointer is locked, the client receives relative
motion ev
10 matches
Mail list logo
