[RFC wayland 2/2] protocol: Don't silently fail to create seat device objects

[Jonas Ådahl]

On Thu, Aug 06, 2015 at 11:56:51AM +0100, Daniel Stone wrote:
> Hi,
> 
> On 30 July 2015 at 03:33, Jonas Ådahl <jadahl at gmail.com> wrote:
> > One of the principles of Wayland is that object creation never fails. If
> > the object cannot be created, it should be reported as a protocol error
> > and an offending client should be terminated.
> >
> > A current violation to this principle is the input device creation in
> > wl_seat, as it may silently ignore a request if the set of seat
> > capabilities at the time of the request does not contain the capability
> > associated with the object that is to be created.
> >
> > This violation was introduced in the protocol in 53b57a63eeee06, and I
> > believe it may have been introduced in error, due to the fact that
> > weston implemented the violation.
> >
> > The interface specifies that "the request only takes effect if the seat
> > has the [given] capability", meaning if the seat does not advertise a
> > given capability, a request creating the corresponding object will fail
> > silently.
> >
> > This is racy, as a client may potentially create an object without
> > knowing whether it succeeded or not, and in effect may unknowingly never
> > receive any input events for the given capability.
> >
> > This is worked around in weston by always succeed if the capability has
> > ever been advertised. This goes against the protocol specification.
> >
> > This patch updates the protocol to get rid of the discussed race and the
> > protocol violation. The change should not cause any backward
> > compatibility issues, especially since "half" of the new semantics are
> > already implemented by for example weston.
> 
> Yes, this is very right.

One backward/forward compatibility issue that needs to be considered, if
we do what weston half implements, is that we need to bump the wl_seat
version if a client wants to rely on protocol objects not going invalid.

> 
> I don't think we really need to say anything about ignoring requests:
> wl_pointer::set_cursor can't ever succeed as it can't by definition
> have a valid serial, and the only requests on wl_keyboard and wl_touch
> are release, which are obviously fine (desirable, in fact).
> 
> Maybe compositors could send a capabilities event to a client which
> binds non-existent seat members, but that might be a bit overkill.

What capability event would be sent to such a client? I would assume
capability events simply represent the actual capabilities, but that a
corresponding protocol object would just start working again.


Jonas

> 
> Cheers,
> Daniel