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

[Bill Spitzak]

On Tue, Apr 4, 2017 at 3:11 AM, Olivier Fourdan <ofourdan at redhat.com> wrote:
>
> Hi
>
>> 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.
>
> Again, even though the protocol does not specifically target override-redirect windows, those are the main problem here, sensible X11 window managers do not "manage" those, so setting EWMH properties such as "activate" or "demand attention" will be ignored by most X11 window managers on O-R windows.
>
> I have attached a simple code sample to demonstrate this - And this is not an hypothetical issue, this is https://bugs.freedesktop.org/show_bug.cgi?id=96547 - This works fine on X11 thanks to the Xserver issuing the requested grab, it cannot work on Xwayland because Wayland has no similar mechanism.
>
> But if you can solve this issue reliably for all X11 window managers/Wayland compositors in Xwayland alone without the help of any additional protocol, best would be to send your patches for Xwayland to xorg-devel.
>
> Cheers,
> Olivier

You seem to be thinking I am proposing some change to the client that
is using XLib.

I mean to change the code that you are currently proposing will
construct and send this Wayland request. Obviously you are able to do
that since you are modifying it right now to produce that request, and
since it is Wayland it is obviously not the Xlib-using client. My best
guess is that this is in the X server.

The proposal is that it instead sends an "activate" or whatever to
Wayland, and if it then receives a deactivate and loses the focus, it
makes some concerted attempt (ie send another "activate" on the next
mouse click) to get the focus back.

I realize the X server is quite a mess and that it may be very
difficult to do anything other than 1:1 translation of X requests to
Wayland requrests, such as adding spurious extra "activate" requests,
and that it is easier to do this mess in the compositor. If that is
the reason then this api makes sense, but the documentation should
*clearly* specify this reason. And it should say *exactly* what a
Wayland client can do to get the same result, and specify that any
compositor that produces a different result from this than from the
Wayland client is out of spec.

My main concern is that X11 clients not get special super powers that
normal clients don't have.

In a related note I am really scared that X11 apps are allowed to set
window xy positions and Wayland clients are not. That needs to be
fixed. I know our software will (if we ever stop using X11) be forced
to make fudge this somehow, possibly by figuring out how to nest a
Wayland window inside an X11 one. We need the ability to save/restore
window layouts in text files that are portable across operating
systems, so anything other than this is impossible. (in reality I
expect *every* compositor will add this as an "extension" but it is
pretty stupid to not define this from the start so we don't have to do
compositor-specific code).