[PATCH wayland 2/4] protocol: clarify input region on drags and pointers

[Pekka Paalanen]

On Wed, 10 Oct 2012 16:58:29 +0300
Ander Conselvan de Oliveira <conselvan2 at gmail.com> wrote:

> On 10/10/2012 01:51 PM, Pekka Paalanen wrote:
> > On Wed, 10 Oct 2012 13:28:07 +0300
> > Ander Conselvan de Oliveira <conselvan2 at gmail.com> wrote:
> >
> >> On 10/10/2012 12:47 PM, Pekka Paalanen wrote:
> >>> Drag icon and cursor surfaces must never receive input, so their input
> >>> region is always empty.
> >>>
> >>> Signed-off-by: Pekka Paalanen <ppaalanen at gmail.com>
> >>> ---
> >>>    protocol/wayland.xml |   20 ++++++++++++++++----
> >>>    1 files changed, 16 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> >>> index c45a404..6293f56 100644
> >>> --- a/protocol/wayland.xml
> >>> +++ b/protocol/wayland.xml
> >>> @@ -332,8 +332,13 @@
> >>>    	The icon surface is an optional (can be nil) surface that
> >>>    	provides an icon to be moved around with the cursor.  Initially,
> >>>    	the top-left corner of the icon surface is placed at the cursor
> >>> -	hotspot, but subsequent surface.attach request can move the
> >>> -	relative position.
> >>> +	hotspot, but subsequent wl_surface.attach request can move the
> >>> +	relative position. Attach requests must be confirmed with
> >>> +	wl_surface.commit as usual.
> >>> +
> >>> +	The current and pending input regions of the wl_surface are
> >>> +	cleared, and wl_surface.set_input_region is ignored until the
> >>> +	wl_surface is destroyed.
> >>
> >> That's not the behavior implemented in Weston right now. When the drag
> >> ends the user is able to set the input region again. In fact, the
> >> surface just becomes a regular wl_surface with no specified role.
> >
> > Right, that is different to how wl_shell surface types work, that also
> > use the weston_surface:configure field. More below...
> >
> >> Also, start_drag takes two wl_surface arguments so the paragraph above
> >> should make it clear it is referring to the icon surface.
> >
> > Will do.
> >
> >>>          </description>
> >>>          <arg name="source" type="object" interface="wl_data_source" allow-null="true"/>
> >>>          <arg name="origin" type="object" interface="wl_surface"/>
> >>> @@ -742,7 +747,9 @@
> >>>
> >>>    	wl_surface.set_input_region changes the pending input region.
> >>>    	wl_surface.commit copies the pending region to the current region.
> >>> -	Otherwise the pending and current regions are never changed.
> >>> +	Otherwise the pending and current regions are never changed,
> >>> +	except cursor and icon surfaces are special cases, see
> >>> +	wl_pointer.set_cursor and wl_data_device.start_drag.
> >>>
> >>>    	The initial value for input region is infinite. That means the whole
> >>>    	surface will accept input. Setting the pending input region has copy
> >>> @@ -864,11 +871,16 @@
> >>>
> >>>    	On surface.attach requests to the pointer surface, hotspot_x
> >>>    	and hotspot_y are decremented by the x and y parameters
> >>> -	passed to the request.
> >>> +	passed to the request. Attach must be confirmed by
> >>> +	wl_surface.commit as usual.
> >>>
> >>>    	The hotspot can also be updated by passing the current set
> >>>    	pointer surface to this request with new values for hotspot_x
> >>>    	and/or hotspot_y.
> >>> +
> >>> +	The current and pending input regions of the wl_surface are
> >>> +	cleared, and wl_surface.set_input_region is ignored until the
> >>> +	wl_surface is destroyed.
> >>
> >> Same thing here. Setting a new pointer surface releases the old one,
> >> making it a regular wl_surface with no specified role.
> >
> > Ok, I missed the pointer_unmap_sprite().
> >
> > What should we specify for the input regions after the surface is no
> > longer a pointer sprite or a drag icon? Undefined, empty, infinite, or
> > the region it was before becoming a pointer sprite? We need to specify
> > it for both current and pending input regions.
> 
> 
> When the role of the surface is reset, the surface is unmapped so the 
> current input region is not really relevant. Saving the previous input 
> region is tricky since a buffer of a different size may have been 
> attached to the surface so that it doesn't really make sense. To me the 

We keep the input and opaque regions unchanged over surface size changes
now. It makes as little sense as resetting them on size change, the
effect is the same: if the client does not want default values, it
needs to keep the regions updated anyway. We just make the
specification more straightforward to implement.

> most sensible thing to do is reset the pending input region to infinite 
> since the surface won't be mapped until a new buffer is attached and at 
> that point the client can set the input region appropriately. If it 
> doesn't if gets the default behavior of a newly create surface.

Oh yes, the default of a newly created surface makes sense, some way...
tough it is only the input region being manipulated this way.

I will cook an additional patch.


Thanks,
pq