[PATCH 3/3] Add a release request on wl_seat

[Jonas Ådahl]

On Sun, Sep 27, 2015 at 10:51:40PM +0200, Hardening wrote:
> Le 24/09/2015 01:59, Jonas Ådahl a écrit :
> > On Wed, Sep 23, 2015 at 11:17:33AM -0500, Derek Foreman wrote:
> >> On 25/02/15 08:03 AM, David FORT wrote:
> >>> This is required if we want to correctly remove a wl_seat server-side.
> >>> ---
> >>>  protocol/wayland.xml | 6 ++++++
> >>>  1 file changed, 6 insertions(+)
> >>>
> 
> Sorry very late reply.
> 
> [...]
> 
> >>> +    <!-- Version 3 additions -->
> >>> +
> >>> +    <request name="release" type="destructor" since="3">
> >>> +      <description summary="release the seat object"/>
> >>> +    </request>
> >>> +
> >>
> >> wl_seat appears to currently be version="4", so I guess we'd have to
> >> bump the since= and the version in the comment... (and probably the
> >> version of wl_seat as well)
> > 
> > Yes. And we should bump the version of wl_pointer, wl_touch and
> > wl_keyboard as part of it, just to make things clearer.
> > 
> 
> Does it mean that that wl_pointer, wl_touch and wl_keyboard should all
> have the same version as wl_seat ?

Yes they always have the same version. It is not enforced in the XML,
or by the scanner, but it's that way anyway just because how version
inheritance work.

> 
> >>
> >> Unfortunately, I don't think this is necessary or sufficient to solve
> >> the problem at hand (RDP compositor connections are new seats, once apps
> >> bind these seats they're essentially leaked forever even after RDP
> >> client disconnect)
> >>
> 
> [...]
> >>
> >> That is, there's a difference between a disconnected RDP client and a
> >> libinput backed seat with no devices left in it.
> >>
> >> Would a new seat event (say, "removed") solve this sufficiently?
> > 
> > Wouldn't the global advertisement being removed be enough? Every seat is
> > advertised individually in the registry, and removing it there should
> > IMO be interpreted as there no longer any use for objects that was bound
> > to the that global.
> > 
> 
> Nope because the client can send a request on the seat while the
> compositor is announcing the global removal. The release request is
> there so that the client can say tto he compositor "understood I won't
> use that object anymore". That allows the compositor to ref count users
> and free it at the end.

That is what I wrote. The original question, if I did not misunderstand,
was whether a "remove" event would be needed. The "release" request is
for the server not to leak the object though, that is true.


Jonas

> 
> -- 
> David FORT
> website: http://www.hardening-consulting.com/
>