Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs
On Wed, Jun 10, 2015 at 5:20 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho carl...@gnome.org wrote: On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote: What is the value of clients having this information? The same there is in having wl_touch.cancelled. See the cases in the original email in the thread. I think we've tried to hide grab semantics from the point of view of the client and simply say we can revoke input at any time, including in response to a request you make, which gives us, the compositor, a lot more leeway with future possibilities. Sure, I'm all for that. What I'd really want is having a way to tell clients we do so. I'm totally fine with documenting the places where this potentially happens on a per-case basis, even if the final wording is compositor dependent, same as for seat.release_input emission. That said, toolkits/clients will surely expect some consistence across compositors, so the leeway is relative. Grabs were a major pain point in X11 since they were overspecified, so we're trying to not fall into that same trap again. I'm sure there is a lot of ground between let's not overspecify and let's go shopping. It would be convenient first to identify what are the sore points with X grabs. AFAICT, most of these come from grabs not being easily transferred, and the WM/screensaver/etc not being more of a client to revoke/break grabs. On wayland the compositor is completely free to do as it pleases, with and without this change I'm proposing. Yeah, transferring grabs race-free, a lack of being able to override or revoke grabs are the top two. But focus management + grabs in X11 is tricksy and sort of awkward: if I take a keyboard grab, key focus can still navigate around as usual, we'll just get NotifyWhileGrabbed as our detail. However, one thing that X did well is defining a consistent event delivery model when grabs were being taken (well, except for touch events...), so both the grabbing and the pre-grab windows are well aware of what's going on, I think one is due in wayland, at least face to clients. Did it? I don't know of any model that lets me know when a client has taken a grab or ungrabs their existing grab. The exception is that I believe if I'm the key or pointer focus, I'll get a FocusOut / Leave event with the NotifyGrabbed detail, and when the grab is dropped (and I am still the key focus / pointer focus, which is not guaranteed!), we'll get the reverse event with NotifyUngrabbed. And in X11, this is actually good, because such an event would be racy: some other client might have taken a grab in such a time. And it happens all the time because of passive grabs, including X11's own implicit passive grab on the pointer. Anyway, this model matches well with wl_keyboard.leave / wl_pointer.leave being sent at the start of device grabs. For instance, if the user is in a game that has a keyboard grab and presses Alt-Tab to switch out, the client should just have its keyboard grab revoked without having to have that as a possibility in the protocol spec. Same thing with tray icon behavior, etc. sure, in that case you'd still get wl_keyboard.leave and the client can properly undo the key press / mods. But notice there is always a need to know when to undo (eg. in your example above, the game might have bound Alt to release flares, if you first press Alt and then Tab, and the client doesn't get the Alt key release, you don't want to leave that stuck when you focus back) The client gets a wl_keyboard.leave. Is that not good enough? What use cases does this new event solve? There's a case where that doesn't happen: if the key press triggers the activation of an input method, which grabs the keyboard. The client still keeps the focus and has no way to know if has to stop generating key repeats for the key that triggered the activation. I'm getting exactly this issue, the keyboard grab is needed in the virtual keyboard to be usable with the arrow keys. Clients need to cope with losing mouse and keyboard focus at any time, and with seats going away at any time. It's just how it is. Toolkits are nothing else than giant state machines, they rely on a meaningful event order, or some proper notification when things go south. If you mess with that, you'll get clients in inconsistent states, including: - stuck buttons - gestures listening to vanished touch sequences, unable to trigger anymore - stuck repeat keys -- Arnaud ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs
If the client still has key focus, then it should get the key release. That sounds like a compositor bug to me. On Thu, Jul 16, 2015 at 10:28 AM, Arnaud Vrac raw...@gmail.com wrote: On Wed, Jun 10, 2015 at 5:20 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho carl...@gnome.org wrote: On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote: What is the value of clients having this information? The same there is in having wl_touch.cancelled. See the cases in the original email in the thread. I think we've tried to hide grab semantics from the point of view of the client and simply say we can revoke input at any time, including in response to a request you make, which gives us, the compositor, a lot more leeway with future possibilities. Sure, I'm all for that. What I'd really want is having a way to tell clients we do so. I'm totally fine with documenting the places where this potentially happens on a per-case basis, even if the final wording is compositor dependent, same as for seat.release_input emission. That said, toolkits/clients will surely expect some consistence across compositors, so the leeway is relative. Grabs were a major pain point in X11 since they were overspecified, so we're trying to not fall into that same trap again. I'm sure there is a lot of ground between let's not overspecify and let's go shopping. It would be convenient first to identify what are the sore points with X grabs. AFAICT, most of these come from grabs not being easily transferred, and the WM/screensaver/etc not being more of a client to revoke/break grabs. On wayland the compositor is completely free to do as it pleases, with and without this change I'm proposing. Yeah, transferring grabs race-free, a lack of being able to override or revoke grabs are the top two. But focus management + grabs in X11 is tricksy and sort of awkward: if I take a keyboard grab, key focus can still navigate around as usual, we'll just get NotifyWhileGrabbed as our detail. However, one thing that X did well is defining a consistent event delivery model when grabs were being taken (well, except for touch events...), so both the grabbing and the pre-grab windows are well aware of what's going on, I think one is due in wayland, at least face to clients. Did it? I don't know of any model that lets me know when a client has taken a grab or ungrabs their existing grab. The exception is that I believe if I'm the key or pointer focus, I'll get a FocusOut / Leave event with the NotifyGrabbed detail, and when the grab is dropped (and I am still the key focus / pointer focus, which is not guaranteed!), we'll get the reverse event with NotifyUngrabbed. And in X11, this is actually good, because such an event would be racy: some other client might have taken a grab in such a time. And it happens all the time because of passive grabs, including X11's own implicit passive grab on the pointer. Anyway, this model matches well with wl_keyboard.leave / wl_pointer.leave being sent at the start of device grabs. For instance, if the user is in a game that has a keyboard grab and presses Alt-Tab to switch out, the client should just have its keyboard grab revoked without having to have that as a possibility in the protocol spec. Same thing with tray icon behavior, etc. sure, in that case you'd still get wl_keyboard.leave and the client can properly undo the key press / mods. But notice there is always a need to know when to undo (eg. in your example above, the game might have bound Alt to release flares, if you first press Alt and then Tab, and the client doesn't get the Alt key release, you don't want to leave that stuck when you focus back) The client gets a wl_keyboard.leave. Is that not good enough? What use cases does this new event solve? There's a case where that doesn't happen: if the key press triggers the activation of an input method, which grabs the keyboard. The client still keeps the focus and has no way to know if has to stop generating key repeats for the key that triggered the activation. I'm getting exactly this issue, the keyboard grab is needed in the virtual keyboard to be usable with the arrow keys. Clients need to cope with losing mouse and keyboard focus at any time, and with seats going away at any time. It's just how it is. Toolkits are nothing else than giant state machines, they rely on a meaningful event order, or some proper notification when things go south. If you mess with that, you'll get clients in inconsistent states, including: - stuck buttons - gestures listening to vanished touch sequences, unable to trigger anymore - stuck repeat keys -- Arnaud -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org
Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs
late to the party, but anyway: On Tue, Jun 09, 2015 at 07:30:31PM +0200, Carlos Garnacho wrote: A good piece of this commit is actually defining as protocol documentation the de-facto behavior in weston and other compositors. Additionally, a wl_seat.release_input event is being added, and the cases where it should be emitted has been added in the relevant places. In short, the compositor should emit it on all surfaces where there was any input interaction that is being redirected away by any means, although some degree of sloppyness is allowed here, and clients are recommended to expect it on surfaces there's nothing really going on. With this event in place, we can define further how do the different input interfaces deal at either side of the input redirection induced by grabs. Taking this out of undefined or compositor dependent land is the final goal of this commit. I'm a bit worried you're conflating multiple issues that have some overlap but aren't the same. all the touch issues to me sound like focus management issues to me. there's one use-case that I thought about and that's the one where you interact with an application with one finger held down, trigger an action you _know_ will cause a popup, then use a finger to ack the popup while holding the original finger down, continuing the original action. a rough idea: that use-case would call for touch focus events. a touch-focus-out signals touch still active but not yours. the compositor may discard any events while out of focus (but doesn't have to) and can send the enter event when the touch comes back. since usually we assume touch==focus you wouldn't send the enter event by default, only if the touch started elsewhere or it's a returning touch. the client can keep the state until the touch is ended or cancelled, or resume from that state once the touch is focused again. Signed-off-by: Carlos Garnacho carl...@gnome.org --- protocol/wayland.xml | 77 +++- 1 file changed, 76 insertions(+), 1 deletion(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index c3b8ae4..3017ff0 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -668,6 +668,16 @@ wl_surface is no longer used as the icon surface. When the use as an icon ends, the current and pending input regions become undefined, and the wl_surface is unmapped. + + After this call, the compositor will consume events from all + input capabilities, compositors are free to implement additional + behavior with other input than the pointer/touch sequence driving + the drag-and-drop operation. + + This request should trigger the emission of seat.release_input + events on, at least, the surfaces that are currently being + interacted with, the surface passed in the origin argument + is implicitly included there. /description arg name=source type=object interface=wl_data_source allow-null=true/ arg name=origin type=object interface=wl_surface/ @@ -890,6 +900,9 @@ This request must be used in response to a button press event. The server may ignore move requests depending on the state of the surface (e.g. fullscreen or maximized). + + This request will trigger the emission of seat.release_input + events on all interacted surfaces, including this one. /description arg name=seat type=object interface=wl_seat summary=the wl_seat whose pointer is used/ arg name=serial type=uint summary=serial of the implicit grab on the pointer/ @@ -901,6 +914,9 @@ is being dragged in a resize operation. The server may use this information to adapt its behavior, e.g. choose an appropriate cursor image. + + This request will trigger the emission of seat.release_input + events on all interacted surfaces, including this one. /description entry name=none value=0/ entry name=top value=1/ @@ -1478,7 +1494,7 @@ /request /interface - interface name=wl_seat version=4 + interface name=wl_seat version=5 description summary=group of input devices A seat is a group of keyboards, pointer and touch devices. This object is published as a global during start up, or when such a @@ -1549,6 +1565,34 @@ arg name=name type=string/ /event +!-- Version 5 additions -- +event name=release_input + description summary=release all input + This events notifies that the given surface will temporarily or + permanently stop receiving input from the given capabilities, so + it should prepare to undo any interaction with these. + + The situations where this event may be emitted are variated, some + examples are: + - When a popup is shown by this or other client. + - When a drag-and-drop operation is initiated from this or + any other
Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs
On mié, 2015-06-10 at 08:20 -0700, Jasper St. Pierre wrote: On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho carl...@gnome.org wrote: On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote: What is the value of clients having this information? The same there is in having wl_touch.cancelled. See the cases in the original email in the thread. I think we've tried to hide grab semantics from the point of view of the client and simply say we can revoke input at any time, including in response to a request you make, which gives us, the compositor, a lot more leeway with future possibilities. Sure, I'm all for that. What I'd really want is having a way to tell clients we do so. I'm totally fine with documenting the places where this potentially happens on a per-case basis, even if the final wording is compositor dependent, same as for seat.release_input emission. That said, toolkits/clients will surely expect some consistence across compositors, so the leeway is relative. Grabs were a major pain point in X11 since they were overspecified, so we're trying to not fall into that same trap again. I'm sure there is a lot of ground between let's not overspecify and let's go shopping. It would be convenient first to identify what are the sore points with X grabs. AFAICT, most of these come from grabs not being easily transferred, and the WM/screensaver/etc not being more of a client to revoke/break grabs. On wayland the compositor is completely free to do as it pleases, with and without this change I'm proposing. Yeah, transferring grabs race-free, a lack of being able to override or revoke grabs are the top two. But focus management + grabs in X11 is tricksy and sort of awkward: if I take a keyboard grab, key focus can still navigate around as usual, we'll just get NotifyWhileGrabbed as our detail. However, one thing that X did well is defining a consistent event delivery model when grabs were being taken (well, except for touch events...), so both the grabbing and the pre-grab windows are well aware of what's going on, I think one is due in wayland, at least face to clients. Did it? I don't know of any model that lets me know when a client has taken a grab or ungrabs their existing grab. The same happens on wayland *between clients*, and that's a good thing. Sure, it wasn't convenient on X11 for a WM, as yet another client. The exception is that I believe if I'm the key or pointer focus, I'll get a FocusOut / Leave event with the NotifyGrabbed detail, and when the grab is dropped (and I am still the key focus / pointer focus, which is not guaranteed!), we'll get the reverse event with NotifyUngrabbed. Precisely, a focus out/leave event with NotifyGrabbed means I may never see this device again, The second enter/focus in event may not happen because the pointer/keyboard focus went elsewhere mid-grab, but for all that matters, the client already forgot about the device(s), so is in a consistent state. And in X11, this is actually good, because such an event would be racy: some other client might have taken a grab in such a time. And it happens all the time because of passive grabs, including X11's own implicit passive grab on the pointer. Anyway, this model matches well with wl_keyboard.leave / wl_pointer.leave being sent at the start of device grabs. For instance, if the user is in a game that has a keyboard grab and presses Alt-Tab to switch out, the client should just have its keyboard grab revoked without having to have that as a possibility in the protocol spec. Same thing with tray icon behavior, etc. sure, in that case you'd still get wl_keyboard.leave and the client can properly undo the key press / mods. But notice there is always a need to know when to undo (eg. in your example above, the game might have bound Alt to release flares, if you first press Alt and then Tab, and the client doesn't get the Alt key release, you don't want to leave that stuck when you focus back) The client gets a wl_keyboard.leave. Is that not good enough? Ok, we fixed keyboards. Keyboard is actually an easy usecase, they in the end have a binary state, even if for multiple keys, and not much retained state behind. Some observations though: - This works here because in this alt-tab example focus is being taken elsewhere, say we're raising a notification area or anything else that only steals focus temporarily, how do we convey the app you should still consider yourself focused nonetheless, and still should appear as such? - Do we take the same approach with wl_pointer, start telling You must forget everything about this pointer on wl_pointer.leave events and issue it mid-press if necessary? What about the legit places you may want enter/leave events while a button is pressed (eg. moving across
Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs
On Thu, Jun 11, 2015 at 02:33:34PM +0200, Carlos Garnacho wrote: On mié, 2015-06-10 at 08:20 -0700, Jasper St. Pierre wrote: On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho carl...@gnome.org wrote: On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote: What is the value of clients having this information? The same there is in having wl_touch.cancelled. See the cases in the original email in the thread. I think we've tried to hide grab semantics from the point of view of the client and simply say we can revoke input at any time, including in response to a request you make, which gives us, the compositor, a lot more leeway with future possibilities. Sure, I'm all for that. What I'd really want is having a way to tell clients we do so. I'm totally fine with documenting the places where this potentially happens on a per-case basis, even if the final wording is compositor dependent, same as for seat.release_input emission. That said, toolkits/clients will surely expect some consistence across compositors, so the leeway is relative. Grabs were a major pain point in X11 since they were overspecified, so we're trying to not fall into that same trap again. I'm sure there is a lot of ground between let's not overspecify and let's go shopping. It would be convenient first to identify what are the sore points with X grabs. AFAICT, most of these come from grabs not being easily transferred, and the WM/screensaver/etc not being more of a client to revoke/break grabs. On wayland the compositor is completely free to do as it pleases, with and without this change I'm proposing. Yeah, transferring grabs race-free, a lack of being able to override or revoke grabs are the top two. But focus management + grabs in X11 is tricksy and sort of awkward: if I take a keyboard grab, key focus can still navigate around as usual, we'll just get NotifyWhileGrabbed as our detail. However, one thing that X did well is defining a consistent event delivery model when grabs were being taken (well, except for touch events...), so both the grabbing and the pre-grab windows are well aware of what's going on, I think one is due in wayland, at least face to clients. Did it? I don't know of any model that lets me know when a client has taken a grab or ungrabs their existing grab. The same happens on wayland *between clients*, and that's a good thing. Sure, it wasn't convenient on X11 for a WM, as yet another client. The exception is that I believe if I'm the key or pointer focus, I'll get a FocusOut / Leave event with the NotifyGrabbed detail, and when the grab is dropped (and I am still the key focus / pointer focus, which is not guaranteed!), we'll get the reverse event with NotifyUngrabbed. Precisely, a focus out/leave event with NotifyGrabbed means I may never see this device again, The second enter/focus in event may not happen because the pointer/keyboard focus went elsewhere mid-grab, but for all that matters, the client already forgot about the device(s), so is in a consistent state. And in X11, this is actually good, because such an event would be racy: some other client might have taken a grab in such a time. And it happens all the time because of passive grabs, including X11's own implicit passive grab on the pointer. Anyway, this model matches well with wl_keyboard.leave / wl_pointer.leave being sent at the start of device grabs. For instance, if the user is in a game that has a keyboard grab and presses Alt-Tab to switch out, the client should just have its keyboard grab revoked without having to have that as a possibility in the protocol spec. Same thing with tray icon behavior, etc. sure, in that case you'd still get wl_keyboard.leave and the client can properly undo the key press / mods. But notice there is always a need to know when to undo (eg. in your example above, the game might have bound Alt to release flares, if you first press Alt and then Tab, and the client doesn't get the Alt key release, you don't want to leave that stuck when you focus back) The client gets a wl_keyboard.leave. Is that not good enough? Ok, we fixed keyboards. Keyboard is actually an easy usecase, they in the end have a binary state, even if for multiple keys, and not much retained state behind. Some observations though: - This works here because in this alt-tab example focus is being taken elsewhere, say we're raising a notification area or anything else that only steals focus temporarily, how do we convey the app you should still consider yourself focused nonetheless, and still should appear as such? - Do we take the same approach with wl_pointer, start telling You must forget everything about
Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs
On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote: What is the value of clients having this information? The same there is in having wl_touch.cancelled. See the cases in the original email in the thread. I think we've tried to hide grab semantics from the point of view of the client and simply say we can revoke input at any time, including in response to a request you make, which gives us, the compositor, a lot more leeway with future possibilities. Sure, I'm all for that. What I'd really want is having a way to tell clients we do so. I'm totally fine with documenting the places where this potentially happens on a per-case basis, even if the final wording is compositor dependent, same as for seat.release_input emission. That said, toolkits/clients will surely expect some consistence across compositors, so the leeway is relative. Grabs were a major pain point in X11 since they were overspecified, so we're trying to not fall into that same trap again. I'm sure there is a lot of ground between let's not overspecify and let's go shopping. It would be convenient first to identify what are the sore points with X grabs. AFAICT, most of these come from grabs not being easily transferred, and the WM/screensaver/etc not being more of a client to revoke/break grabs. On wayland the compositor is completely free to do as it pleases, with and without this change I'm proposing. However, one thing that X did well is defining a consistent event delivery model when grabs were being taken (well, except for touch events...), so both the grabbing and the pre-grab windows are well aware of what's going on, I think one is due in wayland, at least face to clients. For instance, if the user is in a game that has a keyboard grab and presses Alt-Tab to switch out, the client should just have its keyboard grab revoked without having to have that as a possibility in the protocol spec. Same thing with tray icon behavior, etc. sure, in that case you'd still get wl_keyboard.leave and the client can properly undo the key press / mods. But notice there is always a need to know when to undo (eg. in your example above, the game might have bound Alt to release flares, if you first press Alt and then Tab, and the client doesn't get the Alt key release, you don't want to leave that stuck when you focus back) Clients need to cope with losing mouse and keyboard focus at any time, and with seats going away at any time. It's just how it is. Toolkits are nothing else than giant state machines, they rely on a meaningful event order, or some proper notification when things go south. If you mess with that, you'll get clients in inconsistent states, including: - stuck buttons - gestures listening to vanished touch sequences, unable to trigger anymore - stuck repeat keys Cheers, Carlos ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs
On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho carl...@gnome.org wrote: On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote: What is the value of clients having this information? The same there is in having wl_touch.cancelled. See the cases in the original email in the thread. I think we've tried to hide grab semantics from the point of view of the client and simply say we can revoke input at any time, including in response to a request you make, which gives us, the compositor, a lot more leeway with future possibilities. Sure, I'm all for that. What I'd really want is having a way to tell clients we do so. I'm totally fine with documenting the places where this potentially happens on a per-case basis, even if the final wording is compositor dependent, same as for seat.release_input emission. That said, toolkits/clients will surely expect some consistence across compositors, so the leeway is relative. Grabs were a major pain point in X11 since they were overspecified, so we're trying to not fall into that same trap again. I'm sure there is a lot of ground between let's not overspecify and let's go shopping. It would be convenient first to identify what are the sore points with X grabs. AFAICT, most of these come from grabs not being easily transferred, and the WM/screensaver/etc not being more of a client to revoke/break grabs. On wayland the compositor is completely free to do as it pleases, with and without this change I'm proposing. Yeah, transferring grabs race-free, a lack of being able to override or revoke grabs are the top two. But focus management + grabs in X11 is tricksy and sort of awkward: if I take a keyboard grab, key focus can still navigate around as usual, we'll just get NotifyWhileGrabbed as our detail. However, one thing that X did well is defining a consistent event delivery model when grabs were being taken (well, except for touch events...), so both the grabbing and the pre-grab windows are well aware of what's going on, I think one is due in wayland, at least face to clients. Did it? I don't know of any model that lets me know when a client has taken a grab or ungrabs their existing grab. The exception is that I believe if I'm the key or pointer focus, I'll get a FocusOut / Leave event with the NotifyGrabbed detail, and when the grab is dropped (and I am still the key focus / pointer focus, which is not guaranteed!), we'll get the reverse event with NotifyUngrabbed. And in X11, this is actually good, because such an event would be racy: some other client might have taken a grab in such a time. And it happens all the time because of passive grabs, including X11's own implicit passive grab on the pointer. Anyway, this model matches well with wl_keyboard.leave / wl_pointer.leave being sent at the start of device grabs. For instance, if the user is in a game that has a keyboard grab and presses Alt-Tab to switch out, the client should just have its keyboard grab revoked without having to have that as a possibility in the protocol spec. Same thing with tray icon behavior, etc. sure, in that case you'd still get wl_keyboard.leave and the client can properly undo the key press / mods. But notice there is always a need to know when to undo (eg. in your example above, the game might have bound Alt to release flares, if you first press Alt and then Tab, and the client doesn't get the Alt key release, you don't want to leave that stuck when you focus back) The client gets a wl_keyboard.leave. Is that not good enough? What use cases does this new event solve? Clients need to cope with losing mouse and keyboard focus at any time, and with seats going away at any time. It's just how it is. Toolkits are nothing else than giant state machines, they rely on a meaningful event order, or some proper notification when things go south. If you mess with that, you'll get clients in inconsistent states, including: - stuck buttons - gestures listening to vanished touch sequences, unable to trigger anymore - stuck repeat keys Cheers, Carlos -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs
What is the value of clients having this information? I think we've tried to hide grab semantics from the point of view of the client and simply say we can revoke input at any time, including in response to a request you make, which gives us, the compositor, a lot more leeway with future possibilities. Grabs were a major pain point in X11 since they were overspecified, so we're trying to not fall into that same trap again. For instance, if the user is in a game that has a keyboard grab and presses Alt-Tab to switch out, the client should just have its keyboard grab revoked without having to have that as a possibility in the protocol spec. Same thing with tray icon behavior, etc. Clients need to cope with losing mouse and keyboard focus at any time, and with seats going away at any time. It's just how it is. On Tue, Jun 9, 2015 at 10:30 AM, Carlos Garnacho carl...@gnome.org wrote: A good piece of this commit is actually defining as protocol documentation the de-facto behavior in weston and other compositors. Additionally, a wl_seat.release_input event is being added, and the cases where it should be emitted has been added in the relevant places. In short, the compositor should emit it on all surfaces where there was any input interaction that is being redirected away by any means, although some degree of sloppyness is allowed here, and clients are recommended to expect it on surfaces there's nothing really going on. With this event in place, we can define further how do the different input interfaces deal at either side of the input redirection induced by grabs. Taking this out of undefined or compositor dependent land is the final goal of this commit. Signed-off-by: Carlos Garnacho carl...@gnome.org --- protocol/wayland.xml | 77 +++- 1 file changed, 76 insertions(+), 1 deletion(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index c3b8ae4..3017ff0 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -668,6 +668,16 @@ wl_surface is no longer used as the icon surface. When the use as an icon ends, the current and pending input regions become undefined, and the wl_surface is unmapped. + + After this call, the compositor will consume events from all + input capabilities, compositors are free to implement additional + behavior with other input than the pointer/touch sequence driving + the drag-and-drop operation. + + This request should trigger the emission of seat.release_input + events on, at least, the surfaces that are currently being + interacted with, the surface passed in the origin argument + is implicitly included there. /description arg name=source type=object interface=wl_data_source allow-null=true/ arg name=origin type=object interface=wl_surface/ @@ -890,6 +900,9 @@ This request must be used in response to a button press event. The server may ignore move requests depending on the state of the surface (e.g. fullscreen or maximized). + + This request will trigger the emission of seat.release_input + events on all interacted surfaces, including this one. /description arg name=seat type=object interface=wl_seat summary=the wl_seat whose pointer is used/ arg name=serial type=uint summary=serial of the implicit grab on the pointer/ @@ -901,6 +914,9 @@ is being dragged in a resize operation. The server may use this information to adapt its behavior, e.g. choose an appropriate cursor image. + + This request will trigger the emission of seat.release_input + events on all interacted surfaces, including this one. /description entry name=none value=0/ entry name=top value=1/ @@ -1478,7 +1494,7 @@ /request /interface - interface name=wl_seat version=4 + interface name=wl_seat version=5 description summary=group of input devices A seat is a group of keyboards, pointer and touch devices. This object is published as a global during start up, or when such a @@ -1549,6 +1565,34 @@ arg name=name type=string/ /event +!-- Version 5 additions -- +event name=release_input + description summary=release all input + This events notifies that the given surface will temporarily or + permanently stop receiving input from the given capabilities, so + it should prepare to undo any interaction with these. + + The situations where this event may be emitted are variated, some + examples are: + - When a popup is shown by this or other client. + - When a drag-and-drop operation is initiated from this or + any other surface. + + The common denominator in these situations is that input is being + redirected partly or entirely somewhere else, so
