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

[Daniel Stone]

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.

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.

Cheers,
Daniel