Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
On Tue, 19 Aug 2014 13:04:54 -0700 Bill Spitzak spit...@gmail.com wrote: On 08/19/2014 12:29 AM, Pekka Paalanen wrote: + Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. Destroying the last protocol object for the role does not remove the role, correct? The client can recreate a new protocol object for that role and it still works? Recreating the same role works, because that is kind of required with cursors and drag icons. + Losing a role means losing all the role-specific state. I'm not sure what you are saying here. I think maybe you are talking about a surface that was used for drag drop when the drag drop ends? No. I mean that, for example, if you have a wl_surface, that has a xdg_surface and is mapped at some location on screen with some window state (maximized etc.), and you destroy the xdg_surface protocol object, all the xdg_surface state will be lost, and the window disappears from the desktop. If you then keep the wl_surface a re-create the xdg_surface object for it, the outcome is the same as if you destroyed the wl_surface all the way, and created a new one. You have to set all xdg_surface state from scratch, which also means the client cannot guarantee a floating top-level window shows up at the same position where it left. IOW, if you want to keep the role-related state, don't lose the role. That is also something that protocol designers need to keep in mind. I thought in that case the surface must be destroyed: ie once a surface loses a role it cannot be assigned any role, including the same one. But in that case the state is irrelevant. Yeah, but the cursor spec does not yet talk about roles and does not exactly guarantee wl_pointer.set_cursor is always effective. That needs more writing. Are you allowed to reuse the drag drop surface for another drag drop? If the creation request also sets some state it is obvious that portion of the state is not preserved. But it seems a lot easier on both clients and compositors if other state is allowed to be preserved. Yes, this wording allows re-using a wl_surface that once was a drag icon, to be a drag icon again. What other state, the role's or the wl_surface's? We have to be explicit in any case about the role's state, because inconsistency between implementations would be very bad, whatever the spec ends up. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
On Tue, 19 Aug 2014 10:16:34 -0700 Jason Ekstrand ja...@jlekstrand.net wrote: Pekka, I have one nitpick below. However, if we can't find a good solution, I'm ok with pushing as-is. Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com On Tue, Aug 19, 2014 at 1:41 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Tue, 19 Aug 2014 10:29:21 +0300 Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Define what a role is, and what restrictions there are. A change to existing behaviour is that a role cannot be changed at all once set. However, this is unlikely to cause problems, as there is no reason to re-use wl_surfaces in clients. v2: give more concrete examples of roles, define losing a role, Jasper rewrote the paragraph on how a role is set. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- protocol/wayland.xml | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..d3fcaec 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -973,8 +973,30 @@ local coordinates of the pixel content, in case a buffer_transform or a buffer_scale is used. - Surfaces are also used for some special purposes, e.g. as - cursor images for pointers, drag icons, etc. + A surface without a role is fairly useless, a compositor does + not know where, when or how to present it. The role is the + purpose of a wl_surface. Examples of roles are a cursor for a + pointer (as set by wl_pointer.set_cursor), a drag icon + (wl_data_device.start_drag), a sub-surface + (wl_subcompositor.get_subsurface), and a window as defined by a + shell protocol (e.g. wl_shell.get_shell_surface). + + A surface can have only one role at a time. Initially a + wl_surface does not have a role. Once a wl_surface is given a + role, it can never be given a different role again, even if the + wl_surface loses the role in between. I don't really like the term looses its role. Once a surface is a cursor surface it is always a cursor surface, it just might not be the *current* currsor surface. How about: Ok, we have to fix the wl_pointer spec, the spec for dd, and review others. We would need to do that anyway, since at least wl_pointer.set_cursor does not say anything about a role right now. A surface can only have one role in its lifetime. Even if the surface stops being actively used in its role, it can never be used in any other role. For instance, once you call wl_pointer.set_cursor on a surface, the surface is now a cursor surface. Even if it stops being the active cursor, the wl_surface object retains the cursor role cannot be used in a different role. Thoughts? Ok, though I'd probably put it in other words. Does everyone agree that losing a role is not a thing at all? That brings us back to http://lists.freedesktop.org/archives/wayland-devel/2014-August/016550.html on the implementation commentary. It also means we have to change the wl_subsurface spec. I don't recall off-hand if it requires changing other specs. The cursor and drag icon never had a spec to begin with in this sense, and wl_shell_surface does not even have destructor protocol, so simply cannot lose that role. Okay, I will write a patch where setting a role is permanent. Let's see how it looks like. I think someone else needs to implement it in Weston though, before Friday so we get it into the alpha for testing. Hopefully no-one was re-using wl_surfaces yet... If that patch gets accepted, I can write the follow-ups to fix cursor, drag icon, and sub-surface specs. Thanks, pq + + Surface roles are set by requests in other interfaces such as Bah... forgot to save one tiny change: Surface roles are given by ... ---^ Thanks, pq + wl_pointer.set_cursor. The request should explicitly mention + that this request gives a role to a wl_surface. Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. + + A wl_surface may lose its role as specified in the interface + that gave it the role or in the interface of the role object. + Losing a role means losing all the role-specific state. /description enum name=error ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list
Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
On Wed, 20 Aug 2014 13:26:44 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Tue, 19 Aug 2014 10:16:34 -0700 Jason Ekstrand ja...@jlekstrand.net wrote: Pekka, I have one nitpick below. However, if we can't find a good solution, I'm ok with pushing as-is. Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com On Tue, Aug 19, 2014 at 1:41 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Tue, 19 Aug 2014 10:29:21 +0300 Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Define what a role is, and what restrictions there are. A change to existing behaviour is that a role cannot be changed at all once set. However, this is unlikely to cause problems, as there is no reason to re-use wl_surfaces in clients. v2: give more concrete examples of roles, define losing a role, Jasper rewrote the paragraph on how a role is set. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- protocol/wayland.xml | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..d3fcaec 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -973,8 +973,30 @@ local coordinates of the pixel content, in case a buffer_transform or a buffer_scale is used. - Surfaces are also used for some special purposes, e.g. as - cursor images for pointers, drag icons, etc. + A surface without a role is fairly useless, a compositor does + not know where, when or how to present it. The role is the + purpose of a wl_surface. Examples of roles are a cursor for a + pointer (as set by wl_pointer.set_cursor), a drag icon + (wl_data_device.start_drag), a sub-surface + (wl_subcompositor.get_subsurface), and a window as defined by a + shell protocol (e.g. wl_shell.get_shell_surface). + + A surface can have only one role at a time. Initially a + wl_surface does not have a role. Once a wl_surface is given a + role, it can never be given a different role again, even if the + wl_surface loses the role in between. I don't really like the term looses its role. Once a surface is a cursor surface it is always a cursor surface, it just might not be the *current* currsor surface. How about: Ok, we have to fix the wl_pointer spec, the spec for dd, and review others. We would need to do that anyway, since at least wl_pointer.set_cursor does not say anything about a role right now. A surface can only have one role in its lifetime. Even if the surface stops being actively used in its role, it can never be used in any other role. For instance, once you call wl_pointer.set_cursor on a surface, the surface is now a cursor surface. Even if it stops being the active cursor, the wl_surface object retains the cursor role cannot be used in a different role. Thoughts? Ok, though I'd probably put it in other words. Does everyone agree that losing a role is not a thing at all? That brings us back to http://lists.freedesktop.org/archives/wayland-devel/2014-August/016550.html on the implementation commentary. It also means we have to change the wl_subsurface spec. I don't recall off-hand if it requires changing other specs. The cursor and drag icon never had a spec to begin with in this sense, and wl_shell_surface does not even have destructor protocol, so simply cannot lose that role. Okay, I will write a patch where setting a role is permanent. Let's see how it looks like. I think someone else needs to implement it in Weston though, before Friday so we get it into the alpha for testing. Hopefully no-one was re-using wl_surfaces yet... If that patch gets accepted, I can write the follow-ups to fix cursor, drag icon, and sub-surface specs. Eh, so what do we say about the role state, when the role object gets destroyed? Let's say there is a wl_surface with xdg_surface, and it is a mapped top-level floating window. What happens when the xdg_surface object is destroyed, but the wl_surface remains? Does the window stay up, or does it get unmapped? After that, if the client creates a new xdg_surface for the same wl_surface that got its old xdg_surface destroyed, what happens? Is it an error? Does the window reappear at the same place where it left, i.e. is the role state preserved? Looking at the current xdg-shell.xml, role-specific state gets lost, and the window is unmapped. So that is everything I already specified except actually losing the role. Seems like re-creating the same role must be allowed for wl_pointer.set_cursor to keep working, because that request sets the role, and the role is permanent now. Which in the end makes this change just a verbal one, to avoid the phrase lose the role. Okay,
Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
On 08/20/2014 03:06 AM, Pekka Paalanen wrote: On Tue, 19 Aug 2014 13:04:54 -0700 Bill Spitzak spit...@gmail.com wrote: Destroying the last protocol object for the role does not remove the role, correct? The client can recreate a new protocol object for that role and it still works? Recreating the same role works, because that is kind of required with cursors and drag icons. Yes I think my questions were also asked and answered (mostly) in another thread of this email. It sounds like removing a role is not actually something that happens. I feel that destroying the role object should not have any effect. So destroying the xdg_shell_surface would not change how the surface is displayed. The client could create a new xdg_shell_surface object and continue manipulating the surface with it. The reason is that it seems very inconsistent with the ability to create more than one instance of the same role object. Now destroying all except the last one has no effect, but destroying the last one does? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland v2] protocol: define the concept of wl_surface role
From: Pekka Paalanen pekka.paala...@collabora.co.uk Define what a role is, and what restrictions there are. A change to existing behaviour is that a role cannot be changed at all once set. However, this is unlikely to cause problems, as there is no reason to re-use wl_surfaces in clients. v2: give more concrete examples of roles, define losing a role, Jasper rewrote the paragraph on how a role is set. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- protocol/wayland.xml | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..d3fcaec 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -973,8 +973,30 @@ local coordinates of the pixel content, in case a buffer_transform or a buffer_scale is used. - Surfaces are also used for some special purposes, e.g. as - cursor images for pointers, drag icons, etc. + A surface without a role is fairly useless, a compositor does + not know where, when or how to present it. The role is the + purpose of a wl_surface. Examples of roles are a cursor for a + pointer (as set by wl_pointer.set_cursor), a drag icon + (wl_data_device.start_drag), a sub-surface + (wl_subcompositor.get_subsurface), and a window as defined by a + shell protocol (e.g. wl_shell.get_shell_surface). + + A surface can have only one role at a time. Initially a + wl_surface does not have a role. Once a wl_surface is given a + role, it can never be given a different role again, even if the + wl_surface loses the role in between. + + Surface roles are set by requests in other interfaces such as + wl_pointer.set_cursor. The request should explicitly mention + that this request gives a role to a wl_surface. Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. + + A wl_surface may lose its role as specified in the interface + that gave it the role or in the interface of the role object. + Losing a role means losing all the role-specific state. /description enum name=error -- 1.8.5.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
On Tue, 19 Aug 2014 10:29:21 +0300 Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Define what a role is, and what restrictions there are. A change to existing behaviour is that a role cannot be changed at all once set. However, this is unlikely to cause problems, as there is no reason to re-use wl_surfaces in clients. v2: give more concrete examples of roles, define losing a role, Jasper rewrote the paragraph on how a role is set. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- protocol/wayland.xml | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..d3fcaec 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -973,8 +973,30 @@ local coordinates of the pixel content, in case a buffer_transform or a buffer_scale is used. - Surfaces are also used for some special purposes, e.g. as - cursor images for pointers, drag icons, etc. + A surface without a role is fairly useless, a compositor does + not know where, when or how to present it. The role is the + purpose of a wl_surface. Examples of roles are a cursor for a + pointer (as set by wl_pointer.set_cursor), a drag icon + (wl_data_device.start_drag), a sub-surface + (wl_subcompositor.get_subsurface), and a window as defined by a + shell protocol (e.g. wl_shell.get_shell_surface). + + A surface can have only one role at a time. Initially a + wl_surface does not have a role. Once a wl_surface is given a + role, it can never be given a different role again, even if the + wl_surface loses the role in between. + + Surface roles are set by requests in other interfaces such as Bah... forgot to save one tiny change: Surface roles are given by ... ---^ Thanks, pq + wl_pointer.set_cursor. The request should explicitly mention + that this request gives a role to a wl_surface. Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. + + A wl_surface may lose its role as specified in the interface + that gave it the role or in the interface of the role object. + Losing a role means losing all the role-specific state. /description enum name=error ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
Pekka, I have one nitpick below. However, if we can't find a good solution, I'm ok with pushing as-is. Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com On Tue, Aug 19, 2014 at 1:41 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Tue, 19 Aug 2014 10:29:21 +0300 Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Define what a role is, and what restrictions there are. A change to existing behaviour is that a role cannot be changed at all once set. However, this is unlikely to cause problems, as there is no reason to re-use wl_surfaces in clients. v2: give more concrete examples of roles, define losing a role, Jasper rewrote the paragraph on how a role is set. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- protocol/wayland.xml | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..d3fcaec 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -973,8 +973,30 @@ local coordinates of the pixel content, in case a buffer_transform or a buffer_scale is used. - Surfaces are also used for some special purposes, e.g. as - cursor images for pointers, drag icons, etc. + A surface without a role is fairly useless, a compositor does + not know where, when or how to present it. The role is the + purpose of a wl_surface. Examples of roles are a cursor for a + pointer (as set by wl_pointer.set_cursor), a drag icon + (wl_data_device.start_drag), a sub-surface + (wl_subcompositor.get_subsurface), and a window as defined by a + shell protocol (e.g. wl_shell.get_shell_surface). + + A surface can have only one role at a time. Initially a + wl_surface does not have a role. Once a wl_surface is given a + role, it can never be given a different role again, even if the + wl_surface loses the role in between. I don't really like the term looses its role. Once a surface is a cursor surface it is always a cursor surface, it just might not be the *current* currsor surface. How about: A surface can only have one role in its lifetime. Even if the surface stops being actively used in its role, it can never be used in any other role. For instance, once you call wl_pointer.set_cursor on a surface, the surface is now a cursor surface. Even if it stops being the active cursor, the wl_surface object retains the cursor role cannot be used in a different role. Thoughts? + + Surface roles are set by requests in other interfaces such as Bah... forgot to save one tiny change: Surface roles are given by ... ---^ Thanks, pq + wl_pointer.set_cursor. The request should explicitly mention + that this request gives a role to a wl_surface. Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. + + A wl_surface may lose its role as specified in the interface + that gave it the role or in the interface of the role object. + Losing a role means losing all the role-specific state. /description enum name=error ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
On 08/19/2014 12:29 AM, Pekka Paalanen wrote: + Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. Destroying the last protocol object for the role does not remove the role, correct? The client can recreate a new protocol object for that role and it still works? + Losing a role means losing all the role-specific state. I'm not sure what you are saying here. I think maybe you are talking about a surface that was used for drag drop when the drag drop ends? I thought in that case the surface must be destroyed: ie once a surface loses a role it cannot be assigned any role, including the same one. But in that case the state is irrelevant. Are you allowed to reuse the drag drop surface for another drag drop? If the creation request also sets some state it is obvious that portion of the state is not preserved. But it seems a lot easier on both clients and compositors if other state is allowed to be preserved. In any case I find this sentence really confusing. Also it might help if there was a concrete example of a surface losing a role. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
