<div>Hi again,<br></div><div><br></div><div>Yes I propose removing the persistent lifetime, removing the concept of different lifetimes as a whole, and just keeping the oneshot lifetime as the implicit lifetime.<br></div><div><br></div><div>I initially did not consider any of the race conditions, but even then, I do not think it justifies the complex persistent lifetime and the large increase in complexity it brings with it.<br></div><div><br></div><div>I think the approach where the client has to rerequest it each time it enters the region wherein the constraint has to be active, although more prone to slightly incorrect behavior, is superior because of the decreased complexity it burdens the compositor with.<br></div><div><br></div><div>Las<br></div><div><br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user protonmail_signature_block-empty"><br></div></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On 15 May 2018 9:34 AM, Olivier Fourdan <ofourdan@redhat.com> wrote:<br></div><div> <br></div><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><div>Hi,<br></div><div class="gmail_extra"><div><br></div><div class="gmail_quote"><div>On Thu, May 3, 2018 at 10:53 PM, <span dir="ltr"><<a target="_blank" href="mailto:Las@protonmail.ch">Las@protonmail.ch</a>></span> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>I propose removing the concept of persistent pointer constraints and lifetimes in the pointer constraints protocol.<br></div><div><br></div><div>This
 would vastly simplify the implementation of the protocol in the 
compositor, but slightly increase the complexity in the client.<br></div><div><br></div><div><br></div><div>Benefits:<br></div><div><br></div><div>The compositor wouldn't have to keep track of pointer constraints for each valid surface,<br></div><div>since only one pointer constraint could then exist per seat.<br></div><div><br></div><div>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.<br></div><div><br></div><div>This would also allow the removal of regions for locked pointers, since then only confined pointers would make use of them.<br></div><div><br></div><div>Detriments:<br></div><div><br></div><div>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.<br></div><div>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.<br></div></blockquote><div><br></div><div>So if I understand correctly, you'd keep only “oneshot” and that would be implicit?<br></div><div><br></div><div>The concept of “lifetime” appeared in v3 of the protocol review as found here:<br></div><div><br></div><div><a href="https://lists.freedesktop.org/archives/wayland-devel/2016-January/026520.html">https://lists.freedesktop.org/archives/wayland-devel/2016-January/026520.html</a><br></div><div><br></div><div>That explains why there are two different “persistent” modes and which kind of race condition each one induces.<br></div><div><br></div><div>Cheers,<br></div><div>Olivier<br></div></div></div></div></blockquote><div><br></div>