Subject: Re: Modifier Keys not working as expected

From: Ulrich Sibiller <[email-masked]>
Date: Tue, 26 Sep 2017 12:20:55 +0200

On Tue, Sep 26, 2017 at 12:06 PM, Stefan Baur <[email-masked]> wrote:
> package: x2goclient
>
> (devs: feel free to reassign this to nx-libs/arctica, if the cause is
> not in X2GoClient)
>
> A certain application requires the following keypresses:

Is the spplication's name secret?

> - Hold down ctrl, shift and alt
> - while holding them down, press the space bar
> - let go of shift and space bar, keep holding down ctrl and alt

leaving you with ctrl-alt

> - with ctrl and alt pressed, press a function key (F1-F6)
> - let go of all keys
>
> This works when the application is run on :0 - the "ctrl-alt-Fx" is not
> passed down to X, so no switch to tty1-tty6 occurs, which is the
> intended and expected behavior.

So I guess that the application is consuming that very keypress
somehow by communicating with the X server (grab the key(s) in
question).

> However, with the application running in an X2Go session, the same
> sequence of keys will trigger a switch to tty1-tty6 on the local client.

The application probably also communicates with the X server which
this time is nxagent. So nxagent would probably not pass the grab to
the real X server.

You could try if the coming autograb feature helps here.

But for analysis we'd need the application to see what is doing.

For the records: I think it is nx-libs so we should open an issue
there. But I am not sure if we will be able to fix that at all.

Uli

---

From: Stefan Baur <[email-masked]>
Date: Tue, 26 Sep 2017 13:57:55 +0200

> Is the spplication's name secret?

No, but closed-source/commercial/proprietary.

> leaving you with ctrl-alt

In theory, yes. But somehow the shift and space bar being pressed and
released first tell it to "keep" the keypresses to itself, rather than
sending them and the function key on to the X Server.

> You could try if the coming autograb feature helps here.

I'll keep that in mind.

> But for analysis we'd need the application to see what is doing.

They offer a time-limited trial version [0], but IIRC, you still need to
register somewhere with your E-Mail address (and they'll send you promo
E-Mails during the trial phase, and possibly even afterwards).

> there. But I am not sure if we will be able to fix that at all.

As I said, feel free to do so - you're way more knowledgeable about the
code involved than I am.

-Stefan

[0] <https://www.vmware.com/go/tryworkstation-linux-64-de>

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

---

From: Ulrich Sibiller <[email-masked]>
Date: Tue, 26 Sep 2017 14:14:06 +0200

> sending them and the function key on to the X Server.

No, it's the other way round. The X server gets the keypresses and
passes them on to the client(s). This application probably instructs
the xserver to send these keys only to the app and not to anyone else
(and neither interpret them itself).

https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html states this:

The XGrabKeyboard() function actively grabs control of the keyboard
and generates FocusIn and FocusOut events. Further key events are
reported only to the grabbing client. [...]

If the keyboard_mode argument is GrabModeAsync, keyboard event
processing continues as usual. If the keyboard is currently frozen by
this client, then processing of keyboard events is resumed. If the
keyboard_mode argument is GrabModeSync , the state of the keyboard (as
seen by client applications) appears to freeze, and the X server
generates no further keyboard events until the grabbing client issues
a releasing XAllowEvents() call or until the keyboard grab is
released. Actual keyboard changes are not lost while the keyboard is
frozen; they are simply queued in the server for later processing.

> As I said, feel free to do so - you're way more knowledgeable about the

I can do that eventually.

Uli