Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Fri, Jan 15, 2016 at 04:08:57PM +, Daniel Stone wrote: > Hi, > > On 12 January 2016 at 22:28, Bill Spitzak wrote: > > There should *only* be "one shot" requests, which are very quickly accepted > > or denied by the compositor. The client creates it in response to an input > > event, and it includes the input event id. > > > > Most/all things that triggers pointer lock (the mouse entering the region, > > the mouse being pressed in the region, a press+release in the region, a > > keystroke) could be implemented by clients and it does not do any pointer > > lock protocol until after it has detected the triggering event, and thus can > > include the event id. > > For what it's worth - post-hoc expansion on my reasoning - I think > Bill has the genesis of a point here. Usually, our requests have > followed one of two patterns: either you request activation in > response to a specific event (button or key event allows you to create > a selection), or retained state (creating a wl_data_device gets you > selection/etc events on that seat until you destroy it). > > The proposed one-shot-but-delayed request to me felt like a really > awkward compromise between the two, and not really one backed up by a > strong enough usecase to justify a third (delayed but not retained) > model for requests taking effect. tbh, I think this is just a difference in how we view the approach. I never saw it as a "oneshot-delayed" approach, I thought of it as a "need it once" vs "need it forever". however, the main issue I see is that there is always a race condition. with any delayed trigger you're guaranteed that if you request the lock, you'll get it when appropriate. Without the immediate approach, you are racing the user and compositor to request the lock before the trigger is undone again (e.g. moved out of the window). I don't know how much that will be an issue in practice though. Cheers, Peter > > It's entirely possible that there's something I'm missing here, but > for consistency if nothing else, having the split instead be between > these two classic methods (oneshot-immediate vs. fully-retained, > rather than oneshot-delayed vs. fully-retained) could be good for > future versions. > > Cheers, > Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Mon, Jan 18, 2016 at 06:28:29PM +, Daniel Stone wrote: > Hi, > > On 15 January 2016 at 19:30, Bill Spitzak wrote: > > On Fri, Jan 15, 2016 at 8:08 AM, Daniel Stone wrote: > >> The proposed one-shot-but-delayed request to me felt like a really > >> awkward compromise between the two, and not really one backed up by a > >> strong enough usecase to justify a third (delayed but not retained) > >> model for requests taking effect. > >> > >> It's entirely possible that there's something I'm missing here, but > >> for consistency if nothing else, having the split instead be between > >> these two classic methods (oneshot-immediate vs. fully-retained, > >> rather than oneshot-delayed vs. fully-retained) could be good for > >> future versions. > > > > I would agree there is something missing here. > > > > I do not see any reason for anything other than a "one shot" which is > > created by the client *AFTER* it receives the possibly-triggering input > > event. > > I can see the reasoning behind it, at least. I'm not sure I agree, but > those aren't the same thing. > > > I am still waiting for a description of how one of these pre-set > > locks is triggered, I have serious doubts that any possible trigger could be > > something other than an action that would send an event to the client, or at > > a moment the client is doing something like configuring the surface. > > Yes, the triggers would involve events being sent to clients indeed. > Codifying every exact trigger would be borderline impossible, and > unnecessarily restrictive to compositors, so I don't think there's any > need to do that. If we limit lock activation to only happen as replies to events we'd limit the compositors ability to decide when such locks should activate. It might not always result in any input event (timeout of being within a surface, compositor keybinding for accpeting a lock for example). > > > Nor do I see any problem with race conditions provided the one-shot request > > has an id for the triggering event: > > The race here is that if you react on pointer entry, having a one-shot > request will mean that the events you get in between entry and the > request activating, won't be relative. I can imagine that being > frustrating to users. > > > - Client can read relative motion events (these are identical whether or not > > pointer lock works, > > ??? > > Relative motion does not occur without lock. Yes they do. wp_relative_pointer is a completely separate thing. It will emit events no matter the lock/confine situation. > > Anyway, I think we all largely agree on the details, so let's look for > the implementations (compositor and client) both, and see what > real-world feedback falls out of those. Yes. We should concentrate on real world applications for a while, and luckily we can change the protocol if we see the need for it. Jonas > > Cheers, > Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
Hi, On 15 January 2016 at 19:30, Bill Spitzak wrote: > On Fri, Jan 15, 2016 at 8:08 AM, Daniel Stone wrote: >> The proposed one-shot-but-delayed request to me felt like a really >> awkward compromise between the two, and not really one backed up by a >> strong enough usecase to justify a third (delayed but not retained) >> model for requests taking effect. >> >> It's entirely possible that there's something I'm missing here, but >> for consistency if nothing else, having the split instead be between >> these two classic methods (oneshot-immediate vs. fully-retained, >> rather than oneshot-delayed vs. fully-retained) could be good for >> future versions. > > I would agree there is something missing here. > > I do not see any reason for anything other than a "one shot" which is > created by the client *AFTER* it receives the possibly-triggering input > event. I can see the reasoning behind it, at least. I'm not sure I agree, but those aren't the same thing. > I am still waiting for a description of how one of these pre-set > locks is triggered, I have serious doubts that any possible trigger could be > something other than an action that would send an event to the client, or at > a moment the client is doing something like configuring the surface. Yes, the triggers would involve events being sent to clients indeed. Codifying every exact trigger would be borderline impossible, and unnecessarily restrictive to compositors, so I don't think there's any need to do that. > Nor do I see any problem with race conditions provided the one-shot request > has an id for the triggering event: The race here is that if you react on pointer entry, having a one-shot request will mean that the events you get in between entry and the request activating, won't be relative. I can imagine that being frustrating to users. > - Client can read relative motion events (these are identical whether or not > pointer lock works, ??? Relative motion does not occur without lock. Anyway, I think we all largely agree on the details, so let's look for the implementations (compositor and client) both, and see what real-world feedback falls out of those. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Fri, Jan 15, 2016 at 8:08 AM, Daniel Stone wrote: > Hi, > > On 12 January 2016 at 22:28, Bill Spitzak wrote: > > There should *only* be "one shot" requests, which are very quickly > accepted > > or denied by the compositor. The client creates it in response to an > input > > event, and it includes the input event id. > > > > Most/all things that triggers pointer lock (the mouse entering the > region, > > the mouse being pressed in the region, a press+release in the region, a > > keystroke) could be implemented by clients and it does not do any pointer > > lock protocol until after it has detected the triggering event, and thus > can > > include the event id. > > For what it's worth - post-hoc expansion on my reasoning - I think > Bill has the genesis of a point here. Usually, our requests have > followed one of two patterns: either you request activation in > response to a specific event (button or key event allows you to create > a selection), or retained state (creating a wl_data_device gets you > selection/etc events on that seat until you destroy it). > > The proposed one-shot-but-delayed request to me felt like a really > awkward compromise between the two, and not really one backed up by a > strong enough usecase to justify a third (delayed but not retained) > model for requests taking effect. > > It's entirely possible that there's something I'm missing here, but > for consistency if nothing else, having the split instead be between > these two classic methods (oneshot-immediate vs. fully-retained, > rather than oneshot-delayed vs. fully-retained) could be good for > future versions. > I would agree there is something missing here. I do not see any reason for anything other than a "one shot" which is created by the client *AFTER* it receives the possibly-triggering input event. I am still waiting for a description of how one of these pre-set locks is triggered, I have serious doubts that any possible trigger could be something other than an action that would send an event to the client, or at a moment the client is doing something like configuring the surface. Nor do I see any problem with race conditions provided the one-shot request has an id for the triggering event: - Client gets event that it thinks should trigger pointer-lock/confine - Client sends pointer-lock/confine request which includes the event serial number (and creates the pointer-lock proxy object) - Client can read relative motion events (these are identical whether or not pointer lock works, and also correct for motion before the pointer lock request was received by the compositor). Client can also read absolute pointer motion events, but it needs to know these change depending on whether they are before or after the accept event. - Client can change the confinement region (ie it can move the cursor). These are ignored if pointer lock has been rejected or has expired - Client (may) get an accepted event stating that pointer lock worked. - Client gets a cancelled event. If it did not get an accepted event then it knows pointer lock did not work. Imagine the compositor cancels pointer-lock on the next mouse-up event, and a client tries to grab pointer-lock on mouse down. Normal event sequence (--> indicates requests) button-down event --> pointer lock request --> set cursor image --> cursor motion motion event --> cursor motion motion event --> cursor motion accepted event motion event --> cursor motion motion event --> cursor motion button-up event cancelled event motion/enter/exit events due to grab being lost --> set cursor image Now imagine the simplest race, where the compositor sees the mouse button being released before it gets the pointer-lock request: button-down event --> pointer lock request --> set cursor image --> cursor motion motion event --> cursor motion motion event --> cursor motion motion event --> cursor motion motion event --> cursor motion button-up event motion/enter/exit events due to grab being lost cancelled event (due to compositor finally seeing the pointer lock request) --> set cursor image Client can tell this happened because it did not get an accepted event. But it is also interesting that a client may not care: it should act exactly the same and to the user it looks like the pointer-lock gesture worked, except the end position of the cursor is different. I can imagine schemes where the end cursor position is correct, but I think it requires putting an event serial number on the cursor motion requests. The idea is that if the mouse button has not been pressed again, it is warped back to the set position plus the result of any later motion events. Compositor sends accepted+cancelled to indicate this happened. Not sure if it is worth the complexity however. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waylan
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
Hi, On 12 January 2016 at 22:28, Bill Spitzak wrote: > There should *only* be "one shot" requests, which are very quickly accepted > or denied by the compositor. The client creates it in response to an input > event, and it includes the input event id. > > Most/all things that triggers pointer lock (the mouse entering the region, > the mouse being pressed in the region, a press+release in the region, a > keystroke) could be implemented by clients and it does not do any pointer > lock protocol until after it has detected the triggering event, and thus can > include the event id. For what it's worth - post-hoc expansion on my reasoning - I think Bill has the genesis of a point here. Usually, our requests have followed one of two patterns: either you request activation in response to a specific event (button or key event allows you to create a selection), or retained state (creating a wl_data_device gets you selection/etc events on that seat until you destroy it). The proposed one-shot-but-delayed request to me felt like a really awkward compromise between the two, and not really one backed up by a strong enough usecase to justify a third (delayed but not retained) model for requests taking effect. It's entirely possible that there's something I'm missing here, but for consistency if nothing else, having the split instead be between these two classic methods (oneshot-immediate vs. fully-retained, rather than oneshot-delayed vs. fully-retained) could be good for future versions. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Mon, Jan 11, 2016 at 11:03 PM, Jonas Ådahl wrote: > > Come to think of it, we would still introduce a race condition, just for > the other use case. If the intention is that the lock should be > one-shot, the client may not be able to respond with a .destroy() in > time, resulting in the compositor potentially re-locking when that is > not what the client intended. To support both use cases race free we'd > need to bake that into the request creating the lock. Is it worth > complicating the request for fixing both races? > There should *only* be "one shot" requests, which are very quickly accepted or denied by the compositor. The client creates it in response to an input event, and it includes the input event id. Most/all things that triggers pointer lock (the mouse entering the region, the mouse being pressed in the region, a press+release in the region, a keystroke) could be implemented by clients and it does not do any pointer lock protocol until after it has detected the triggering event, and thus can include the event id. It is extremely unclear from your proposal whether you are going to allow a pointer lock to happen without an input event to the client. Some description of how pointer lock looks to a user would help here. Some guesses of mine: - Pointer lock is "grabbed" immediately on program startup, or when the surface is full-screened. I think this could be done by the client making the request at these points with a zero event id. Also responding to mouse-enter events would probably cover all the real-world examples. - Some kind of global compositor-chosen hot key triggers pointer lock. But then it is rather mysterious how you deal with pointer lock requests from more than one client at the same time. If that is chosen by the keyboard focus, then the client will get the keystroke and thus the client can trigger pointer lock in response to the keystroke. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Tue, Jan 12, 2016 at 02:48:38PM +0800, Jonas Ådahl wrote:
> On Sat, Jan 09, 2016 at 04:38:51PM +, Daniel Stone wrote:
> > Hi,
> >
> > On 4 January 2016 at 04:21, Peter Hutterer wrote:
> > > On Fri, Jan 01, 2016 at 04:54:14PM +, Daniel Stone wrote:
> > >> I almost wonder if we couldn't make peoples' lives easier by merging
> > >> locking and confinement into a single interface, adding a bool for
> > >> whether or not to allow pointer movement (confine) or not (lock). Or
> > >> perhaps, rather than a bool, we could add an allow-null
> > >> wp_relative_pointer argument instead: gives you lock if non-null, or
> > >> confine if null.
> > >
> > > you get a much less expressive API, less checking, etc. for a fairly
> > > minimal
> > > benefit. Furthermore, any extension to *either/or* the lock/confine
> > > interface would need to handle the appropriate NULL cases for the other
> > > interface. Right now we can easily add a locking-specific request without
> > > messing up the logic of the confinement, and vice versa.
> > >
> > > I don't think merging the two is a good long-term strategy.
> >
> > I'm not deeply wedded to this (hence 'almost wonder'), but just as
> > long as we're aware of the downside that it does make compositor
> > implementations significantly more complex - see the infrastructure
> > required to support both interfaces whilst mostly treating them as the
> > same interface inside the Weston patch. So, if you're both against it,
> > then shrug, fair enough.
> >
> > >> > + If the compositor decides to unlock the pointer the unlocked
> > >> > event is
> > >> > + sent. The wp_locked_pointer object is at this point defunct and
> > >> > should be
> > >> > + destroyed.
> > >>
> > >> Egads. :( This is a bit hostile - what's the harm in allowing latent
> > >> objects to remain? To my mind, once a previously-locked/confined
> > >> wp_{locked,confined}_pointer object is unlocked, it is for all intents
> > >> and purposes the same as one which just hasn't yet been activated.
> > >
> > > what happens whe the wl_pointer goes away on the wl_seat? does the client
> > > expect the wp_locked_pointer object to hang around and reattach to the new
> > > pointer should it come back on the seat?
> > > see the mess with documenting the capabilities and lifetime of wl_pointer
> > > objects, forcing this object to be dead avoids all that for very little
> > > cost.
> >
> > Eh? Destroying the object after a single use doesn't make the problem
> > go away, because you still have to specify what happens to a
> > wp_locked_pointer on which the lock has never triggered, when the
> > pointer goes away. Arguably it just makes clients _more_ likely to get
> > that case wrong.
> >
> > I don't see what making the object single-use buys us. Surely the
> > common usecase is to react to destruction by immediately recreating a
> > new object with the exact same properties. And it introduces a really
> > annoying corner case where input arrives before you have the time to
> > recreate (say you have a very temporal exit), in which you receive
> > normal rather than locked pointer events. Given that it makes clients
> > more complex, introduces an unfortunate race condition, doesn't avoid
> > the case that is its stated reason to exist, and also makes protocol
> > tracing a bit more difficult, why do it?
>
> FWIW, I'd be fine making the objects outlive an unlock. It'd need
> changes to set_region etc, but thats trivial. The pointer seat
> capability going away I would make it do the same as wl_pointer i.e.
> it'll become useless, won't ever re-lock and should be destroyed.
Come to think of it, we would still introduce a race condition, just for
the other use case. If the intention is that the lock should be
one-shot, the client may not be able to respond with a .destroy() in
time, resulting in the compositor potentially re-locking when that is
not what the client intended. To support both use cases race free we'd
need to bake that into the request creating the lock. Is it worth
complicating the request for fixing both races?
Jonas
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Sat, Jan 09, 2016 at 04:38:51PM +, Daniel Stone wrote:
> Hi,
>
> On 4 January 2016 at 04:21, Peter Hutterer wrote:
> > On Fri, Jan 01, 2016 at 04:54:14PM +, Daniel Stone wrote:
> >> I almost wonder if we couldn't make peoples' lives easier by merging
> >> locking and confinement into a single interface, adding a bool for
> >> whether or not to allow pointer movement (confine) or not (lock). Or
> >> perhaps, rather than a bool, we could add an allow-null
> >> wp_relative_pointer argument instead: gives you lock if non-null, or
> >> confine if null.
> >
> > you get a much less expressive API, less checking, etc. for a fairly minimal
> > benefit. Furthermore, any extension to *either/or* the lock/confine
> > interface would need to handle the appropriate NULL cases for the other
> > interface. Right now we can easily add a locking-specific request without
> > messing up the logic of the confinement, and vice versa.
> >
> > I don't think merging the two is a good long-term strategy.
>
> I'm not deeply wedded to this (hence 'almost wonder'), but just as
> long as we're aware of the downside that it does make compositor
> implementations significantly more complex - see the infrastructure
> required to support both interfaces whilst mostly treating them as the
> same interface inside the Weston patch. So, if you're both against it,
> then shrug, fair enough.
>
> >> > + If the compositor decides to unlock the pointer the unlocked
> >> > event is
> >> > + sent. The wp_locked_pointer object is at this point defunct and
> >> > should be
> >> > + destroyed.
> >>
> >> Egads. :( This is a bit hostile - what's the harm in allowing latent
> >> objects to remain? To my mind, once a previously-locked/confined
> >> wp_{locked,confined}_pointer object is unlocked, it is for all intents
> >> and purposes the same as one which just hasn't yet been activated.
> >
> > what happens whe the wl_pointer goes away on the wl_seat? does the client
> > expect the wp_locked_pointer object to hang around and reattach to the new
> > pointer should it come back on the seat?
> > see the mess with documenting the capabilities and lifetime of wl_pointer
> > objects, forcing this object to be dead avoids all that for very little
> > cost.
>
> Eh? Destroying the object after a single use doesn't make the problem
> go away, because you still have to specify what happens to a
> wp_locked_pointer on which the lock has never triggered, when the
> pointer goes away. Arguably it just makes clients _more_ likely to get
> that case wrong.
>
> I don't see what making the object single-use buys us. Surely the
> common usecase is to react to destruction by immediately recreating a
> new object with the exact same properties. And it introduces a really
> annoying corner case where input arrives before you have the time to
> recreate (say you have a very temporal exit), in which you receive
> normal rather than locked pointer events. Given that it makes clients
> more complex, introduces an unfortunate race condition, doesn't avoid
> the case that is its stated reason to exist, and also makes protocol
> tracing a bit more difficult, why do it?
FWIW, I'd be fine making the objects outlive an unlock. It'd need
changes to set_region etc, but thats trivial. The pointer seat
capability going away I would make it do the same as wl_pointer i.e.
it'll become useless, won't ever re-lock and should be destroyed.
Jonas
>
> This is my one remaining objection; the rest looks peachy.
>
> Cheers,
> Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
Hi,
On 4 January 2016 at 04:21, Peter Hutterer wrote:
> On Fri, Jan 01, 2016 at 04:54:14PM +, Daniel Stone wrote:
>> I almost wonder if we couldn't make peoples' lives easier by merging
>> locking and confinement into a single interface, adding a bool for
>> whether or not to allow pointer movement (confine) or not (lock). Or
>> perhaps, rather than a bool, we could add an allow-null
>> wp_relative_pointer argument instead: gives you lock if non-null, or
>> confine if null.
>
> you get a much less expressive API, less checking, etc. for a fairly minimal
> benefit. Furthermore, any extension to *either/or* the lock/confine
> interface would need to handle the appropriate NULL cases for the other
> interface. Right now we can easily add a locking-specific request without
> messing up the logic of the confinement, and vice versa.
>
> I don't think merging the two is a good long-term strategy.
I'm not deeply wedded to this (hence 'almost wonder'), but just as
long as we're aware of the downside that it does make compositor
implementations significantly more complex - see the infrastructure
required to support both interfaces whilst mostly treating them as the
same interface inside the Weston patch. So, if you're both against it,
then shrug, fair enough.
>> > + If the compositor decides to unlock the pointer the unlocked event
>> > is
>> > + sent. The wp_locked_pointer object is at this point defunct and
>> > should be
>> > + destroyed.
>>
>> Egads. :( This is a bit hostile - what's the harm in allowing latent
>> objects to remain? To my mind, once a previously-locked/confined
>> wp_{locked,confined}_pointer object is unlocked, it is for all intents
>> and purposes the same as one which just hasn't yet been activated.
>
> what happens whe the wl_pointer goes away on the wl_seat? does the client
> expect the wp_locked_pointer object to hang around and reattach to the new
> pointer should it come back on the seat?
> see the mess with documenting the capabilities and lifetime of wl_pointer
> objects, forcing this object to be dead avoids all that for very little
> cost.
Eh? Destroying the object after a single use doesn't make the problem
go away, because you still have to specify what happens to a
wp_locked_pointer on which the lock has never triggered, when the
pointer goes away. Arguably it just makes clients _more_ likely to get
that case wrong.
I don't see what making the object single-use buys us. Surely the
common usecase is to react to destruction by immediately recreating a
new object with the exact same properties. And it introduces a really
annoying corner case where input arrives before you have the time to
recreate (say you have a very temporal exit), in which you receive
normal rather than locked pointer events. Given that it makes clients
more complex, introduces an unfortunate race condition, doesn't avoid
the case that is its stated reason to exist, and also makes protocol
tracing a bit more difficult, why do it?
This is my one remaining objection; the rest looks peachy.
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Sun, Jan 03, 2016 at 10:07:42PM -0800, Bill Spitzak wrote: > On 01/03/2016 08:21 PM, Peter Hutterer wrote: > >On Fri, Jan 01, 2016 at 04:54:14PM +, Daniel Stone wrote: > >> > >>I almost wonder if we couldn't make peoples' lives easier by merging > >>locking and confinement into a single interface, adding a bool for > >>whether or not to allow pointer movement (confine) or not (lock). Or > >>perhaps, rather than a bool, we could add an allow-null > >>wp_relative_pointer argument instead: gives you lock if non-null, or > >>confine if null. > > > >you get a much less expressive API, less checking, etc. for a fairly minimal > >benefit. Furthermore, any extension to *either/or* the lock/confine > >interface would need to handle the appropriate NULL cases for the other > >interface. Right now we can easily add a locking-specific request without > >messing up the logic of the confinement, and vice versa. > > You have a confinement protocol where the client updates a region to move > the cursor. > > You have the lock protocol where the client updates an x/y and it moves the > cursor (though you call it the "hint" and it does not move the cursor until > after the lock is destroyed, but since this is useless unless the client > hides the cursor, the behavior would be identical if it moved the cursor > immediately). > > An x/y position is a degenerate region. > > Therefore the two are the same, provided you let the lock version actually > move the cursor, rather than it being a "hint". Which would be incredibly > useful, too! > > >>Also, for symmetry with wp_relative_pointer, should this take a > >>wl_pointer instead of wl_seat? > > > >you'd be restricting locking and confinement to a pointer device, with a > >wl_seat you can confine and lock devices that are not wl_pointer devices, > >e.g. a wl_tablet tool in relative mode. > > I'm pretty certain that would provide a wl_pointer. Absolute mode maybe I > could understand, but not relative. the tablet mode does not need to be exposed to the client, it's a compositor thing only. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Tue, Jan 05, 2016 at 09:21:27AM +0800, Jonas Ådahl wrote: > On Mon, Jan 04, 2016 at 02:21:37PM +1000, Peter Hutterer wrote: > > On Fri, Jan 01, 2016 at 04:54:14PM +, Daniel Stone wrote: > > > Hi, > > > A couple of (belated) comments ... > > > > > > On 3 December 2015 at 07:28, Jonas Ådahl wrote: > > > > + > > > > + > > > > + The lock_pointer request lets the client request to disable > > > > movements of > > > > + the virtual pointer (i.e. the cursor), effectively locking the > > > > pointer > > > > + to a position. This request may not take effect immediately; in > > > > the > > > > + future, when the compositor deems implementation-specific > > > > constraints > > > > + are satisfied, the pointer lock will be activated and the > > > > compositor > > > > + sends a locked event. > > > > + > > > > + The protocol provides no guarantee that the constraints are ever > > > > + satisfied, and does not require the compositor to send an error > > > > if the > > > > + constraints cannot ever be satisfied. It is thus possible to > > > > request a > > > > + lock that will never activate. > > > > + > > > > + There may not be another lock of any kind requested or active > > > > on the > > > > +surface for the seat when requesting a lock. If there is, an > > > > error will > > > > +be raised. See general pointer lock documentation for more > > > > details. > > > > + > > > > + The intersection of the region passed with this request and the > > > > input > > > > + region of the surface is used to determine where the pointer > > > > must be > > > > + in order for the lock to activate. It is up to the compositor > > > > whether to > > > > + warp the pointer or require some kind of user interaction for > > > > the lock > > > > + to activate. If the region is null the surface input region is > > > > used. > > > > + > > > > + A surface may receive pointer focus without the lock being > > > > activated. > > > > + > > > > + The request will create a new object wp_locked_pointer which is > > > > used to > > > > + interact with the lock as well as receive updates about its > > > > state. See > > > > + the the description of wp_locked_pointer for further > > > > information. > > > > + > > > > + Note that while a pointer is locked, the wl_pointer objects of > > > > the > > > > + corresponding seat will not emit any wl_pointer.motion events, > > > > but > > > > + relative motion events will still be emitted via > > > > wp_relative_pointer > > > > + objects of the same seat. wl_pointer.axis and wl_pointer.button > > > > events > > > > + are unaffected. > > > > + > > > > + > > > > + > > > > + > > > + summary="surface to lock pointer to"/> > > > > + > > > + summary="seat where the pointer should be locked"/> > > > > + > > > allow-null="true" > > > > + summary="region of surface"/> > > > > + > > > > + > > > > + > > > > + > > > > + The confine_pointer request lets the client request to confine > > > > the > > > > + pointer cursor to a given region. This request may not take > > > > effect > > > > + immediately; in the future, when the compositor deems > > > > implementation- > > > > + specific constraints are satisfied, the pointer confinement > > > > will be > > > > + activated and the compositor sends a confined event. > > > > + > > > > + The intersection of the region passed with this request and the > > > > input > > > > + region of the surface is used to determine where the pointer > > > > must be > > > > + in order for the confinement to activate. It is up to the > > > > compositor > > > > + whether to warp the pointer or require some kind of user > > > > interaction for > > > > + the confinement to activate. If the region is null the surface > > > > input > > > > + region is used. > > > > + > > > > + The request will create a new object wp_confined_pointer which > > > > is used > > > > + to interact with the confinement as well as receive updates > > > > about its > > > > + state. See the the description of wp_confined_pointer for > > > > further > > > > + information. > > > > + > > > > + > > > > + > > > interface="zwp_confined_pointer_v1"/> > > > > + > > > + summary="surface to lock pointer to"/> > > > > + > > > + summary="seat where the pointer should be locked"/> > > > > + > > > allow-null="true" > > > > + summary="region of surface"/> > > > > + > > > > + > > > > > > I almost wonder if we couldn't make peoples' lives easier by merging > > > locking and confinement into a single interface, adding a bool for > > > whether or not to allow pointer movement (confine) or not (lock). Or > > > perhap
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Mon, Jan 04, 2016 at 02:21:37PM +1000, Peter Hutterer wrote: > On Fri, Jan 01, 2016 at 04:54:14PM +, Daniel Stone wrote: > > Hi, > > A couple of (belated) comments ... > > > > On 3 December 2015 at 07:28, Jonas Ådahl wrote: > > > + > > > + > > > + The lock_pointer request lets the client request to disable > > > movements of > > > + the virtual pointer (i.e. the cursor), effectively locking the > > > pointer > > > + to a position. This request may not take effect immediately; in > > > the > > > + future, when the compositor deems implementation-specific > > > constraints > > > + are satisfied, the pointer lock will be activated and the > > > compositor > > > + sends a locked event. > > > + > > > + The protocol provides no guarantee that the constraints are ever > > > + satisfied, and does not require the compositor to send an error > > > if the > > > + constraints cannot ever be satisfied. It is thus possible to > > > request a > > > + lock that will never activate. > > > + > > > + There may not be another lock of any kind requested or active on > > > the > > > +surface for the seat when requesting a lock. If there is, an > > > error will > > > +be raised. See general pointer lock documentation for more > > > details. > > > + > > > + The intersection of the region passed with this request and the > > > input > > > + region of the surface is used to determine where the pointer must > > > be > > > + in order for the lock to activate. It is up to the compositor > > > whether to > > > + warp the pointer or require some kind of user interaction for the > > > lock > > > + to activate. If the region is null the surface input region is > > > used. > > > + > > > + A surface may receive pointer focus without the lock being > > > activated. > > > + > > > + The request will create a new object wp_locked_pointer which is > > > used to > > > + interact with the lock as well as receive updates about its > > > state. See > > > + the the description of wp_locked_pointer for further information. > > > + > > > + Note that while a pointer is locked, the wl_pointer objects of the > > > + corresponding seat will not emit any wl_pointer.motion events, but > > > + relative motion events will still be emitted via > > > wp_relative_pointer > > > + objects of the same seat. wl_pointer.axis and wl_pointer.button > > > events > > > + are unaffected. > > > + > > > + > > > + > > > + > > + summary="surface to lock pointer to"/> > > > + > > + summary="seat where the pointer should be locked"/> > > > + > > allow-null="true" > > > + summary="region of surface"/> > > > + > > > + > > > + > > > + > > > + The confine_pointer request lets the client request to confine the > > > + pointer cursor to a given region. This request may not take effect > > > + immediately; in the future, when the compositor deems > > > implementation- > > > + specific constraints are satisfied, the pointer confinement will > > > be > > > + activated and the compositor sends a confined event. > > > + > > > + The intersection of the region passed with this request and the > > > input > > > + region of the surface is used to determine where the pointer must > > > be > > > + in order for the confinement to activate. It is up to the > > > compositor > > > + whether to warp the pointer or require some kind of user > > > interaction for > > > + the confinement to activate. If the region is null the surface > > > input > > > + region is used. > > > + > > > + The request will create a new object wp_confined_pointer which is > > > used > > > + to interact with the confinement as well as receive updates about > > > its > > > + state. See the the description of wp_confined_pointer for further > > > + information. > > > + > > > + > > > + > > > + > > + summary="surface to lock pointer to"/> > > > + > > + summary="seat where the pointer should be locked"/> > > > + > > allow-null="true" > > > + summary="region of surface"/> > > > + > > > + > > > > I almost wonder if we couldn't make peoples' lives easier by merging > > locking and confinement into a single interface, adding a bool for > > whether or not to allow pointer movement (confine) or not (lock). Or > > perhaps, rather than a bool, we could add an allow-null > > wp_relative_pointer argument instead: gives you lock if non-null, or > > confine if null. > > you get a much less expressive API, less checking, etc. for a fairly minimal > benefit. Furthermore, any extension to *either/or* the lock/confine > interface would need to handle the appropriate NULL cases for the other > interface. Right now we
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Mon, Jan 04, 2016 at 02:21:37PM +1000, Peter Hutterer wrote: > On Fri, Jan 01, 2016 at 04:54:14PM +, Daniel Stone wrote: > > Hi, > > A couple of (belated) comments ... > > > > On 3 December 2015 at 07:28, Jonas Ådahl wrote: > > > + > > > + > > > + The lock_pointer request lets the client request to disable > > > movements of > > > + the virtual pointer (i.e. the cursor), effectively locking the > > > pointer > > > + to a position. This request may not take effect immediately; in > > > the > > > + future, when the compositor deems implementation-specific > > > constraints > > > + are satisfied, the pointer lock will be activated and the > > > compositor > > > + sends a locked event. > > > + > > > + The protocol provides no guarantee that the constraints are ever > > > + satisfied, and does not require the compositor to send an error > > > if the > > > + constraints cannot ever be satisfied. It is thus possible to > > > request a > > > + lock that will never activate. > > > + > > > + There may not be another lock of any kind requested or active on > > > the > > > +surface for the seat when requesting a lock. If there is, an > > > error will > > > +be raised. See general pointer lock documentation for more > > > details. > > > + > > > + The intersection of the region passed with this request and the > > > input > > > + region of the surface is used to determine where the pointer must > > > be > > > + in order for the lock to activate. It is up to the compositor > > > whether to > > > + warp the pointer or require some kind of user interaction for the > > > lock > > > + to activate. If the region is null the surface input region is > > > used. > > > + > > > + A surface may receive pointer focus without the lock being > > > activated. > > > + > > > + The request will create a new object wp_locked_pointer which is > > > used to > > > + interact with the lock as well as receive updates about its > > > state. See > > > + the the description of wp_locked_pointer for further information. > > > + > > > + Note that while a pointer is locked, the wl_pointer objects of the > > > + corresponding seat will not emit any wl_pointer.motion events, but > > > + relative motion events will still be emitted via > > > wp_relative_pointer > > > + objects of the same seat. wl_pointer.axis and wl_pointer.button > > > events > > > + are unaffected. > > > + > > > + > > > + > > > + > > + summary="surface to lock pointer to"/> > > > + > > + summary="seat where the pointer should be locked"/> > > > + > > allow-null="true" > > > + summary="region of surface"/> > > > + > > > + > > > + > > > + > > > + The confine_pointer request lets the client request to confine the > > > + pointer cursor to a given region. This request may not take effect > > > + immediately; in the future, when the compositor deems > > > implementation- > > > + specific constraints are satisfied, the pointer confinement will > > > be > > > + activated and the compositor sends a confined event. > > > + > > > + The intersection of the region passed with this request and the > > > input > > > + region of the surface is used to determine where the pointer must > > > be > > > + in order for the confinement to activate. It is up to the > > > compositor > > > + whether to warp the pointer or require some kind of user > > > interaction for > > > + the confinement to activate. If the region is null the surface > > > input > > > + region is used. > > > + > > > + The request will create a new object wp_confined_pointer which is > > > used > > > + to interact with the confinement as well as receive updates about > > > its > > > + state. See the the description of wp_confined_pointer for further > > > + information. > > > + > > > + > > > + > > > + > > + summary="surface to lock pointer to"/> > > > + > > + summary="seat where the pointer should be locked"/> > > > + > > allow-null="true" > > > + summary="region of surface"/> > > > + > > > + > > > > I almost wonder if we couldn't make peoples' lives easier by merging > > locking and confinement into a single interface, adding a bool for > > whether or not to allow pointer movement (confine) or not (lock). Or > > perhaps, rather than a bool, we could add an allow-null > > wp_relative_pointer argument instead: gives you lock if non-null, or > > confine if null. > > you get a much less expressive API, less checking, etc. for a fairly minimal > benefit. Furthermore, any extension to *either/or* the lock/confine > interface would need to handle the appropriate NULL cases for the other > interface. Right now we
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On 01/03/2016 08:21 PM, Peter Hutterer wrote: On Fri, Jan 01, 2016 at 04:54:14PM +, Daniel Stone wrote: I almost wonder if we couldn't make peoples' lives easier by merging locking and confinement into a single interface, adding a bool for whether or not to allow pointer movement (confine) or not (lock). Or perhaps, rather than a bool, we could add an allow-null wp_relative_pointer argument instead: gives you lock if non-null, or confine if null. you get a much less expressive API, less checking, etc. for a fairly minimal benefit. Furthermore, any extension to *either/or* the lock/confine interface would need to handle the appropriate NULL cases for the other interface. Right now we can easily add a locking-specific request without messing up the logic of the confinement, and vice versa. You have a confinement protocol where the client updates a region to move the cursor. You have the lock protocol where the client updates an x/y and it moves the cursor (though you call it the "hint" and it does not move the cursor until after the lock is destroyed, but since this is useless unless the client hides the cursor, the behavior would be identical if it moved the cursor immediately). An x/y position is a degenerate region. Therefore the two are the same, provided you let the lock version actually move the cursor, rather than it being a "hint". Which would be incredibly useful, too! Also, for symmetry with wp_relative_pointer, should this take a wl_pointer instead of wl_seat? you'd be restricting locking and confinement to a pointer device, with a wl_seat you can confine and lock devices that are not wl_pointer devices, e.g. a wl_tablet tool in relative mode. I'm pretty certain that would provide a wl_pointer. Absolute mode maybe I could understand, but not relative. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On Fri, Jan 01, 2016 at 04:54:14PM +, Daniel Stone wrote: > Hi, > A couple of (belated) comments ... > > On 3 December 2015 at 07:28, Jonas Ådahl wrote: > > + > > + > > + The lock_pointer request lets the client request to disable > > movements of > > + the virtual pointer (i.e. the cursor), effectively locking the > > pointer > > + to a position. This request may not take effect immediately; in the > > + future, when the compositor deems implementation-specific > > constraints > > + are satisfied, the pointer lock will be activated and the compositor > > + sends a locked event. > > + > > + The protocol provides no guarantee that the constraints are ever > > + satisfied, and does not require the compositor to send an error if > > the > > + constraints cannot ever be satisfied. It is thus possible to > > request a > > + lock that will never activate. > > + > > + There may not be another lock of any kind requested or active on the > > +surface for the seat when requesting a lock. If there is, an error > > will > > +be raised. See general pointer lock documentation for more details. > > + > > + The intersection of the region passed with this request and the > > input > > + region of the surface is used to determine where the pointer must be > > + in order for the lock to activate. It is up to the compositor > > whether to > > + warp the pointer or require some kind of user interaction for the > > lock > > + to activate. If the region is null the surface input region is used. > > + > > + A surface may receive pointer focus without the lock being > > activated. > > + > > + The request will create a new object wp_locked_pointer which is > > used to > > + interact with the lock as well as receive updates about its state. > > See > > + the the description of wp_locked_pointer for further information. > > + > > + Note that while a pointer is locked, the wl_pointer objects of the > > + corresponding seat will not emit any wl_pointer.motion events, but > > + relative motion events will still be emitted via wp_relative_pointer > > + objects of the same seat. wl_pointer.axis and wl_pointer.button > > events > > + are unaffected. > > + > > + > > + > > + > + summary="surface to lock pointer to"/> > > + > + summary="seat where the pointer should be locked"/> > > + > allow-null="true" > > + summary="region of surface"/> > > + > > + > > + > > + > > + The confine_pointer request lets the client request to confine the > > + pointer cursor to a given region. This request may not take effect > > + immediately; in the future, when the compositor deems > > implementation- > > + specific constraints are satisfied, the pointer confinement will be > > + activated and the compositor sends a confined event. > > + > > + The intersection of the region passed with this request and the > > input > > + region of the surface is used to determine where the pointer must be > > + in order for the confinement to activate. It is up to the compositor > > + whether to warp the pointer or require some kind of user > > interaction for > > + the confinement to activate. If the region is null the surface input > > + region is used. > > + > > + The request will create a new object wp_confined_pointer which is > > used > > + to interact with the confinement as well as receive updates about > > its > > + state. See the the description of wp_confined_pointer for further > > + information. > > + > > + > > + > > + > + summary="surface to lock pointer to"/> > > + > + summary="seat where the pointer should be locked"/> > > + > allow-null="true" > > + summary="region of surface"/> > > + > > + > > I almost wonder if we couldn't make peoples' lives easier by merging > locking and confinement into a single interface, adding a bool for > whether or not to allow pointer movement (confine) or not (lock). Or > perhaps, rather than a bool, we could add an allow-null > wp_relative_pointer argument instead: gives you lock if non-null, or > confine if null. you get a much less expressive API, less checking, etc. for a fairly minimal benefit. Furthermore, any extension to *either/or* the lock/confine interface would need to handle the appropriate NULL cases for the other interface. Right now we can easily add a locking-specific request without messing up the logic of the confinement, and vice versa. I don't think merging the two is a good long-term strategy. > Also, for symmetry with wp_relative_pointer, should this take a > wl_pointer instead of wl_seat? you'd be restricting locking and confinement to a pointer device, with a wl_seat you can confine
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
On 01/01/2016 08:54 AM, Daniel Stone wrote: I almost wonder if we couldn't make peoples' lives easier by merging locking and confinement into a single interface, adding a bool for whether or not to allow pointer movement (confine) or not (lock). Or perhaps, rather than a bool, we could add an allow-null wp_relative_pointer argument instead: gives you lock if non-null, or confine if null. Yes please merge these two almost-identical apis into a single one. Base it on the confinement version. This already allows the client to update the confinement region as often as wanted. A zero-sized region can force the cursor to be at a particular point, which is what the pointer lock does (with my oft-requested enhancement that the normal cursor-setting code can be reused to set the cursor image). If you want to duplicate the almost-useless current pointer-lock, the client can just hide the cursor, and make a fake one using a new surface. Setting the region also sets the "hint" as he calls it. Also, for symmetry with wp_relative_pointer, should this take a wl_pointer instead of wl_seat? Seems like a good idea + If the compositor decides to unlock the pointer the unlocked event is + sent. The wp_locked_pointer object is at this point defunct and should be + destroyed. Egads. :( This is a bit hostile - what's the harm in allowing latent objects to remain? I think he is just trying to say that the object is now useless. The client does not have to destroy it, but it probably should. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol
Hi, A couple of (belated) comments ... On 3 December 2015 at 07:28, Jonas Ådahl wrote: > + > + > + The lock_pointer request lets the client request to disable movements > of > + the virtual pointer (i.e. the cursor), effectively locking the pointer > + to a position. This request may not take effect immediately; in the > + future, when the compositor deems implementation-specific constraints > + are satisfied, the pointer lock will be activated and the compositor > + sends a locked event. > + > + The protocol provides no guarantee that the constraints are ever > + satisfied, and does not require the compositor to send an error if the > + constraints cannot ever be satisfied. It is thus possible to request a > + lock that will never activate. > + > + There may not be another lock of any kind requested or active on the > +surface for the seat when requesting a lock. If there is, an error > will > +be raised. See general pointer lock documentation for more details. > + > + The intersection of the region passed with this request and the input > + region of the surface is used to determine where the pointer must be > + in order for the lock to activate. It is up to the compositor whether > to > + warp the pointer or require some kind of user interaction for the lock > + to activate. If the region is null the surface input region is used. > + > + A surface may receive pointer focus without the lock being activated. > + > + The request will create a new object wp_locked_pointer which is used > to > + interact with the lock as well as receive updates about its state. See > + the the description of wp_locked_pointer for further information. > + > + Note that while a pointer is locked, the wl_pointer objects of the > + corresponding seat will not emit any wl_pointer.motion events, but > + relative motion events will still be emitted via wp_relative_pointer > + objects of the same seat. wl_pointer.axis and wl_pointer.button events > + are unaffected. > + > + > + > + + summary="surface to lock pointer to"/> > + + summary="seat where the pointer should be locked"/> > + allow-null="true" > + summary="region of surface"/> > + > + > + > + > + The confine_pointer request lets the client request to confine the > + pointer cursor to a given region. This request may not take effect > + immediately; in the future, when the compositor deems implementation- > + specific constraints are satisfied, the pointer confinement will be > + activated and the compositor sends a confined event. > + > + The intersection of the region passed with this request and the input > + region of the surface is used to determine where the pointer must be > + in order for the confinement to activate. It is up to the compositor > + whether to warp the pointer or require some kind of user interaction > for > + the confinement to activate. If the region is null the surface input > + region is used. > + > + The request will create a new object wp_confined_pointer which is used > + to interact with the confinement as well as receive updates about its > + state. See the the description of wp_confined_pointer for further > + information. > + > + > + > + + summary="surface to lock pointer to"/> > + + summary="seat where the pointer should be locked"/> > + allow-null="true" > + summary="region of surface"/> > + > + I almost wonder if we couldn't make peoples' lives easier by merging locking and confinement into a single interface, adding a bool for whether or not to allow pointer movement (confine) or not (lock). Or perhaps, rather than a bool, we could add an allow-null wp_relative_pointer argument instead: gives you lock if non-null, or confine if null. Also, for symmetry with wp_relative_pointer, should this take a wl_pointer instead of wl_seat? > + > + > + The wp_locked_pointer interface represents a locked pointer state. > + > + While the lock of this object is active, the wl_pointer objects of the > + associated seat will not emit any wl_pointer.motion events. > + > + This object will send the event 'locked' when the lock is activated. > + Whenever the lock is activated, it is guaranteed that the locked > surface > + will already have received pointer focus and that the pointer will be > + within the region passed to the request creating this object. > + > + To unlock the pointer, send the destroy request. This will also destroy > + the wp_locked_pointer object. > + > + If the compositor decides to unlock the pointer the unlocked event is > + sent. The wp_locked_pointer object is at this poin
