pointer-constraints protocol: Removing lifetimes and persistency

Olivier Fourdan ofourdan at redhat.com
Tue May 15 07:34:16 UTC 2018


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

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


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

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

More information about the wayland-devel mailing list