[PATCH v3 weston] Introduce pointer locking and confinement protocol

[Jonas Ådahl]

On Mon, Aug 24, 2015 at 10:44:55AM -0700, Bill Spitzak wrote:
> On Sun, Aug 23, 2015 at 8:19 PM, Jonas Ådahl <jadahl at gmail.com> wrote:
> 
> >
> > 1. the pointer "attaches" to the UI element.
> >
> > One would create a lock region on the scroll handle. When enabled one
> > would hide the cursor, create an identical cursor surface and add it as
> > a subsurface positioning relative to the scroll handle. One would now
> > listen for events from wl_relative_pointer, update the subsurface
> > position and the scroll handle widget under it. When done, one would
> > unlock the lock, destroy the subsurface, and reset the pointer cursor.
> > During the moving, one would set the cursor position hint so when
> > resetting the cursor position would be updated.
> >
> 
> This is the first sign that you have actually thought about this. However
> you seem blind to the trivial solution. Here is my rewrite of the above
> paragraph with the set_cursor_pos proposal:
> 
> "One would create a lock region on the scroll handle. When enabled one
> would now listen for events from wl_relative_pointer, update the cursor
> position and the scroll handle widget under it. When done, one would unlock
> the lock."
> 
> This is the only way to guarantee the "attachment" effect. There is one
> > unsolved issue which is that the cursor sprite and the subsurface might
> > be visible at the same time, and we'd need some kind of "transaction"
> > protocol to solve this. There has been ideas to have a "set_cursor_pos"
> > but this method would never give us any guarantees about "attachment".
> >
> 
> WTF???. Your proposal is that the client draw a fake cursor in a subsurface
> and setting that to some x,y position to move the cursor. I propose that
> the same x,y are sent to set_cursor_pos. THE EXACT SAME NUMBERS!  It is
> impossible for "attachement" to be different between the two proposals!!!!
> 
> All I can guess is that you think that there is going to be synchronization
> between subsurface positioning and the surface image, but for some reason
> such synchronization will be missing for set_cursor_pos. But why? The
> cursor surface belongs to the locking client just as much as any
> subsurface, so any rules for subsurfaces can be applied to it as well. I'd
> also like to know why suddenly this is important, when you have repeatedly
> claimed that avoiding latency is more important that sync image updating.

Not going to go down this road again.

> 
> If the client wants to control the activation, it can simply request the
> > lock exactly at the point it wants it to be activated. resize.c in
> > weston is an example of this - it activates the lock on a pointer button
> > event.
> >
> 
> This is great if it works, however I hope you realize that this will be the
> ONLY way that any clients with small lock regions will turn on pointer
> lock. Having to update the "activation region" for every widget on every
> layout change is extremely bad, it will send large amounts of data to the
> server for no reason, kind of like old X11 toolkits that sent every widget
> as a subwindow. This was known to be a mistake back in the mid 80's when
> lightweight widgets were added to x intrinsics.

Requesting a lock as a response to a click sounds like a reasonable way
to implement it to me.


Jonas