<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 8, 2013 at 11:32 AM, Rob Bradford <span dir="ltr"><<a href="mailto:robert.bradford@intel.com" target="_blank">robert.bradford@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 8 July 2013 17:25, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>

<br>
> That's exactly what weston *was* doing.  However, thanks to the destroyed<br>
> proxies, the clients were getting NULL anyway.  We could to go through a<br>
> bunch of trouble to keep the resource valid and call wl_pointer.leave on a<br>
> valid resource.  However, that's a lot more work than I thought it was worth<br>
> for no change client-side.<br>
<br>
</div>Right - you spell this out nice and clearly in your excellent commit<br>
message. So although this is technically an API change all the clients<br>
already deal with this anyway - so I guess it's right to spell that<br>
out in the protocol.<br>
<br>
Out of interest - when does the compositor emit a motion event without<br>
a resource?<br></blockquote></div><br><br></div><div class="gmail_extra">The motion event doesn't have a wl_surface associated with it, so never.  However, due to the asynchronous nature of things, the client may receive any number of motion events between the time that it calls wl_surface.destroy and the time that it receives wl_pointer.leave.  I don't think the compositor sends any motion events as it process surface destruction though.<br>
<br></div><div class="gmail_extra">--Jason Ekstrand<br></div></div>