[PATCH 2/3] Modify wayland-scanner to generate inert objects

[Daniel Stone]

Hi,

On 23 September 2015 at 17:33, Derek Foreman <derekf at osg.samsung.com> wrote:
> On 25/02/15 08:03 AM, David FORT wrote:
>> As stated in the very good blog post[1] of Pekka Paalanen, server-side we can have
>> sometime troubles with object that the server has deleted but that the client
>> is still requesting. This patch complements the scanner to create some code
>> that will return inert objects, ie objects that will do nothing and will never
>> return anything else but an inert object. An example is a get_pointer() on
>> a wl_seat, with an unplugged mouse (and so no pointer). Instead of keeping alive
>> the old pointer, we could bind that inert object and wait that the client release
>> it (which should happen very quickly as a wl_global_remove should be in the wire).
>
> Personally, I'd like to NAK this one :/
>
> Adding a way to hand out already-dead objects kind of makes me nervous
> (perhaps for no good reason).
>
> I think we have to keep the old pointers alive in weston for libinput
> backed pointers because we want to retain their position if they go
> away/come back.
>
> This could happen on a USB bus reset and not on an intentional
> unplug/plug event.
>
> So this doesn't actually simplify compositor code?
>
> The capabilities event from the seat should tell you that your pointer
> isn't valid, and that already works.
>
> I guess it's not clear to me what problem this is actually solving.

I have to reluctantly agree with Derek. I think the idea is good, just
not the implementation; it only gets worse when you consider objects
created from those interfaces.

To wit:
  - if someone gets an inert wl_seat, they're probably going to call
get_keyboard or get_pointer on it quite soon
  - those requests _must_ generate valid objects, because there are
very legitimate race conditions where clients can call them, even
though server-side the object is now inert
  - those interfaces can themselves generate other objects
  - some of the behaviours there are interface-specific: e.g. with a
wl_seat, the global remove tells you that it's no longer valid, but
with a wl_pointer / wl_keyboard, you might have to poke the client
with an empty caps event
  - other interfaces want to immediately send a release event as soon
as they're bound

I think the way to do this is ultimately going to require explicit
compositor behaviour that is aware of each object type. We can of
course make this easier by providing common helpers which are easy for
other implementers to copy (and also just to reduce open-coding), but
I've never really been convinced of the scanner approach.

(I know I've said this on IRC, but not sure I ever translated it to
mail - sorry.)

Cheers,
Daniel