pointer-constraints protocol: Removing lifetimes and persistency

[Olivier Fourdan]

Hi,

On Thu, May 3, 2018 at 10:53 PM, <Las at protonmail.ch> wrote:

> I propose removing the concept of persistent pointer constraints and
> lifetimes in the pointer constraints protocol.
>
> This would vastly simplify the implementation of the protocol in the
> compositor, but slightly increase the complexity in the client.
>
>
> Benefits:
>
> The compositor wouldn't have to keep track of pointer constraints for each
> valid surface,
> since only one pointer constraint could then exist per seat.
>
> The compositor would also not have to actively check the position of the
> pointer on the surface, since if it is inactive, it does not exist, and can
> therefore not be reactivated, so it is not needed to check if the pointer
> is in the region of a pointer constraint.
>
> This would also allow the removal of regions for locked pointers, since
> then only confined pointers would make use of them.
>
> Detriments:
>
> The client would have to recreate the pointer constraint each time the
> pointer enters the valid region, instead of just making a persistent
> pointer constraint.
> This is very simple for previously NULL regions, since you can just
> recreate it on each pointer enter event, although it's a bit more complex
> for complex regions, since the client will have to handle that itself now.
>

So if I understand correctly, you'd keep only “oneshot” and that would be
implicit?

The concept of “lifetime” appeared in v3 of the protocol review as found
here:

https://lists.freedesktop.org/archives/wayland-devel/2016-January/026520.html

That explains why there are two different “persistent” modes and which kind
of race condition each one induces.

Cheers,
Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180515/99ddb6bd/attachment-0001.html>