[PATCH 1/2] Introduce keyboard grabbing protocol for Xwayland

[Bill Spitzak]

I cannot see why this api cannot be correctly emulated using some
wayland api that normal wayland clients can also use. Allowing X
clients to have more rights and abilities than Wayland clients seems
horrendously wrong.

The X emulation does not have to do 1:1 translation of X11 calls into
Wayland requests.

In this case I would think an attempt to grab the keyboard would
instead send an "activate" or "raise" or "needs attention" (that seems
to be a popular name) request. The X client would then get keystrokes
(possibly after some more user interaction such as clicking or of
de-iconizing the client). Because the X11 app may not expect to lose
the focus until the grab is lost, the X emulator would also re-request
the focus if it is lost at any time it could, such as on mouse clicks
or mouse enter events.

I suppose the plan is that this does not actually do something that
Wayland clients can't do, but in that case you are just moving "how to
replicate what X does" from the X emulator into the compositor. That
still seems wrong, since compositors may differ, making it impossible
for the client to be rewritten to not use the X emulator but still
have the same behavior. I would much rather see this done by the X
emulator.


On Mon, Apr 3, 2017 at 11:56 AM, Olivier Fourdan <ofourdan at redhat.com> wrote:
> Hi Pekka,
>
>> you cannot ignore a wl_registry.bind request. Did you ever try to see
>> what happens? :-)
>
> Admittedly, I didn't go that far!
>
>> If you do not create a wl_resource when the protocol spec says "this
>> creates a new object", then if the client ever refers to the
>> non-created object, it will hopefully be automatically shot dead for
>> referencing a bad object id.
>
> Ah right, makes sense, of course...
>
>> Furthermore, I think it also violates the object id allocation scheme,
>> so if the client tries to create any new object after the ignored bind
>> request, that would also explode.
>>
>> So you might just let the client out of its misery before anything more
>> confusing can happen. At least you can then deliver a descriptive error
>> message. ;-)
>
> Yeah, I'll use the global filter API, it's the intended use and really simple to put in place :)
>
>> As for the protocol wording, I think it should be enough to say that
>> compositors should restrict the interface to Xwayland. How they do that
>> is up to them.
>
> Yeap, agreed
>
> Thanks
> Olivier
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel