revise keyboard configuration

uli42 commented 7 years ago

NX uses xfree86 rules by default. If the client side is Linux and using evdev rules and model the nxagent activates a keycode mapping (see nxagentConvertKeycode() in hw/nxagent/Keyboard.c) to map evdev keycodes back to xfree86 keycodes. I suppose this was necessary years ago because Xorg did not ship evdev support in the xkb database and NX was using xfree86. Starting 2009 (see https://www.freedesktop.org/wiki/Software/XKeyboardConfig/) evdev was included in XKeyboardConfig. So I think nxagent should try to use it instead of doing the keycode conversion and use the current solution as a fallback only.

Generally I'd like to have nxagent clone the settings from the client side automatically whenever possible (on initial connect and on reconnect).

Currently the -keyboard/-kbtype parameter accepts a value of query which was implemented in nx-2.0.0-22. The changelog describes it like this:

- Implented handling of value "query" for nxagentKbtype. This value
  is passed by the NX client for MacOSX. If value of nxagentKbtype is
  "query" or NULL we init keyboard by core protocol functions reading
  the keyvoard mapping of the X server. The property _XKB_RULES_NAMES
  is always set on the root window with default values of model and
  layout.

I think this behaviour is desirable anywhere and should be extended to work on other OSes, too. And it should be the default.

sunweaver commented 7 years ago

It would be interesting, why NoMachine chose the original approach. In X2Go, we use the keyboard file, which you have already been playing with in https://github.com/ArcticaProject/nx-libs/pull/243.

Keyboard stuff is tricky in remote desktop approaches. Problematic is, that remote desktop shells have its own agenda around keyboard layout and such. In MATE, for example, you can override system-wide keyboard setups and if you do, then this also applies to remote MATE sessions via NX.

So from my X2Go time, I remember various caveats / approaches:

let the desktop shell handle keyboard setup (bad idea)
use keyboard file creation and use setxkbmap externally to apply this config to the nxagent (works always if on Linux, see x2gosetkeyboard script in x2goserver)
set internal nxagentKeyboard variable via cmdline or nx/nx options (can cause conflicts with keyboard layouts set by the remote desktop shell or via setxkbmap)
use xmodmap to manipulate the remote sessions keyboard layout (used in X2Go Client for Mac OS X)

The different approaches should indeed be boiled down to (at best) one method of handling the keyboard.

uli42 commented 7 years ago

Well, the setxkbmap approach using the generated keyboard file did not work for me because of the empty options line. That's why I have fixed that.

The xmodmap approach should always work. So it could be used as the one for all solution.

Regarding Desktop environments setting own keyboards: Nxagent has features to ignore keyboard changes coming from (inside) clients. But they do not seem to work for xkb, must be investigated further.

Using xkb on the server if the remote side does not offer xkb leads to the xmodmap fallback. But it could confuse clients like MATE desktop (and users) as what they see via setxkbmap might not match with what they experience in the session. Can we find a solution for this?

BTW: Am I right that keyboard=query is used for the xmodmap approach?

Vom Smartphone gesendet.

----- Ursprüngliche Nachricht ----- Von: "Mike Gabriel" notifications@github.com Gesendet: ‎28.‎10.‎2016 15:31 An: "ArcticaProject/nx-libs" nx-libs@noreply.github.com Cc: "Ulrich Sibiller" uli42@gmx.de; "Author" author@noreply.github.com Betreff: Re: [ArcticaProject/nx-libs] revise keyboard configuration (#240)

It would be interesting, why NoMachine chose the original approach. In X2Go, we use the keyboard file, which you have already been playing with in #243. Keyboard stuff is tricky in remote desktop approaches. Problematic is, that remote desktop shells have its own agenda around keyboard layout and such. In MATE, for example, you can override system-wide keyboard setups and if you do, then this also applies to remote MATE sessions via NX. So from my X2Go time, I remember various caveats / approaches: let the desktop shell handle keyboard setup (bad idea) use keyboard file creation and use setxkbmap externally to apply this config to the nxagent (works always if on Linux, see x2gosetkeyboard script in x2goserver) set internal nxagentKeyboard variable via cmdline or nx/nx options (can cause conflicts with keyboard layouts set by the remote desktop shell or via setxkbmap) use xmodmap to manipulate the remote sessions keyboard layout (used in X2Go Client for Mac OS X) The different approaches should indeed be boiled down to (at best) one method of handling the keyboard. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

mviereck commented 7 years ago

I'm using nxagent on its own as nested X server. If I try to set german keyboard layout with either setxkbcomp or xmodmap, I have the same issue: Keys like ö ä, ß work fine, but arrow keys and AltGr behave strange. I found this old bugfix, I'm not sure how I should apply it for my needs, but maybe it helps in this thread: https://github.com/debe/freenx/commit/3ceee2fca22fb4e519d37f4ddb66e3f3ef761fec#diff-d801b9ae131364e24fc34d4b08a6933f

uli42 commented 7 years ago

Have you tried using the current 3.6 beta packages of nx-libs? I have removed the os check for evdev so it should just work. There's a page on x2go that explains hiw to use the beta.

Uli

Vom Smartphone gesendet.

----- Ursprüngliche Nachricht ----- Von: "mviereck" notifications@github.com Gesendet: ‎17.‎04.‎2017 06:21 An: "ArcticaProject/nx-libs" nx-libs@noreply.github.com Cc: "Ulrich Sibiller" uli42@gmx.de; "Author" author@noreply.github.com Betreff: Re: [ArcticaProject/nx-libs] revise keyboard configuration (#240)

I'm using nxagent on its own as nested X server. If I try to set german keyboard layout with either setxkbcomp or xmodmap, I have the same issue: Keys like ö ä, ß work fine, but arrow keys and AltGr behave strange. I found this old bugfix, I'm not sure how I should apply it for my needs, but maybe it helps in this thread: debe/freenx@3ceee2f#diff-d801b9ae131364e24fc34d4b08a6933f — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

mviereck commented 7 years ago

I have 3.5.99.5-4 from debian experimental, updated today. On http://packages.arctica-project.org/debian-nightly/pool/main/n/nx-libs/ I find 3.5.99.5-0.1. The version from debian experimental seems to be a bit more actual, or is there some confusion in version numbering? (By the way, it was a bit difficult to find the repository for nightly builds for debian - on the download page of x2go I get "nightly builds" from version 3.5.0 ;-)(Further there seems to be no version option of nxagent on cli to check there).

uli42 commented 7 years ago

On Mon, Apr 17, 2017 at 5:35 PM, mviereck notifications@github.com wrote:

I have 3.5.99.5-4 from debian experimental, updated today. On http://packages.arctica-project.org/debian-nightly/pool/main/n/nx-libs/ I find 3.5.99.5-0.1. The version from debian experimental seems to be a bit more actual, or is there some confusion in version numbering? (By the way, it was a bit difficult to find the repository for nightly builds for debian - on the download page of x2go I get "nightly builds" from version 3.5.0 ;-)(Further there seems to be no version option of nxagent on cli to check there).

I can confirm that evdev handling is not (no longer?) working in plain nxagent. I will have a look at this the next days.

Uli

uli42 commented 7 years ago

On Tue, Apr 18, 2017 at 12:18 AM, Ulrich Sibiller uli42@gmx.de wrote:

On Mon, Apr 17, 2017 at 5:35 PM, mviereck notifications@github.com wrote:

I have 3.5.99.5-4 from debian experimental, updated today. On http://packages.arctica-project.org/debian-nightly/pool/main/n/nx-libs/ I find 3.5.99.5-0.1. The version from debian experimental seems to be a bit more actual, or is there some confusion in version numbering? (By the way, it was a bit difficult to find the repository for nightly builds for debian - on the download page of x2go I get "nightly builds" from version 3.5.0 ;-)(Further there seems to be no version option of nxagent on cli to check there).

I can confirm that evdev handling is not (no longer?) working in plain nxagent. I will have a look at this the next days.

You can, if you like, have a look at my (experimental) "autokeyboard" branch. I made it some months ago and don't know the current state anymore (and I cannot test it right now) but maybe it helps: https://github.com/uli42/nx-libs/commits/autokeyboard (especially this commit: https://github.com/uli42/nx-libs/commit/a472784cfb49bf47c930b552a456249eaee1012f)

Uli

uli42 commented 7 years ago

Also, does "echo nx/nx,keyboard=evdev/de$DISPLAY >/tmp/opt" work for you?

On Tue, Apr 18, 2017 at 11:49 AM, Ulrich Sibiller uli42@gmx.de wrote:

On Tue, Apr 18, 2017 at 12:18 AM, Ulrich Sibiller uli42@gmx.de wrote:

On Mon, Apr 17, 2017 at 5:35 PM, mviereck notifications@github.com wrote:

I have 3.5.99.5-4 from debian experimental, updated today. On http://packages.arctica-project.org/debian-nightly/pool/main/n/nx-libs/ I find 3.5.99.5-0.1. The version from debian experimental seems to be a bit more actual, or is there some confusion in version numbering? (By the way, it was a bit difficult to find the repository for nightly builds for debian - on the download page of x2go I get "nightly builds" from version 3.5.0 ;-)(Further there seems to be no version option of nxagent on cli to check there).

I can confirm that evdev handling is not (no longer?) working in plain nxagent. I will have a look at this the next days.

You can, if you like, have a look at my (experimental) "autokeyboard" branch, especially this commit. I made it some months ago and don't know the current state anymore (and I cannot test it right now) but maybe it helps: https://github.com/uli42/nx-libs/commits/autokeyboard (especially this commit: https://github.com/uli42/nx-libs/commit/a472784cfb49bf47c930b552a456249eaee1012f)

Uli

mviereck commented 7 years ago

Also, does "echo nx/nx,keyboard=evdev/de$DISPLAY >/tmp/opt" work for you?

Yes, that works fine! All keys including AltGr with {[|@€]} work fine! Now I parse the output of setxkbmap -query to have the right settings on every machine my script may run on.

setxkbmap -query also shows model: pc105. Should that be regarded, too, and can be set in keyboard= ?

You can, if you like, have a look at my (experimental) "autokeyboard" branch.

I will test it later.

Martin

Edit: Just checked, -keyboard evdev/de on cli works, too

mviereck commented 7 years ago

I tried to build your autokeyboard branch,but got an error.

$ debuild -uc -us
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
(expected one of nx-libs_3.5.0.29.orig.tar.gz, nx-libs_3.5.0.29.orig.tar.bz2,
nx-libs_3.5.0.29.orig.tar.lzma,  nx-libs_3.5.0.29.orig.tar.xz or nx-libs.orig)
continue anyway? (y/n) y
 dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: Information: Quellpaket nx-libs
dpkg-buildpackage: Information: Quellversion 2:3.5.0.29-0x2go2
dpkg-buildpackage: Information: Quelldistribution UNRELEASED
dpkg-buildpackage: Information: Quelle geändert durch Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
 dpkg-source --before-build nx-libs
dpkg-buildpackage: Information: Host-Architektur amd64
dpkg-checkbuilddeps: Fehler: Baukonflikte: x11proto-kb-dev x11proto-randr-dev x11proto-record-dev x11proto-xinerama-dev
dpkg-buildpackage: Warnung: Bauabhängigkeiten/-konflikte nicht erfüllt; Abbruch
dpkg-buildpackage: Warnung: (Verwenden Sie -d, um sich darüber hinwegzusetzen.)
debuild: fatal error at line 1116:
dpkg-buildpackage -rfakeroot -us -uc failed

Packages x11proto-kb-dev x11proto-randr-dev x11proto-record-dev x11proto-xinerama-dev are installed on my system. I'm not sure what is wrong.

Ionic commented 7 years ago

Read the error message again.

These are build conflicts, so the mentioned packages must not be installed.

mviereck commented 7 years ago

Thanks! I've tried the build again, now I get a bunch of error messages: https://nopaste.me/view/6d6848af Last lines:

Hunk #49 FAILED at 1592.
26 out of 49 hunks FAILED -- rejects in file nx-X11/lib/Xft/config.sub
Patch 017_nx-X11_update-autotools-helper-files.full.patch lässt sich nicht anwenden (erzwingen mit -f)
dh_quilt_patch: quilt --quiltrc /dev/null push -a || test $? = 2 returned exit code 1
debian/rules:14: die Regel für Ziel „build“ scheiterte
make: *** [build] Fehler 25
dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2
debuild: fatal error at line 1116:
dpkg-buildpackage -rfakeroot -us -uc failed

uli42 commented 7 years ago

I'd say you build the wrong source. nx 3.5.99.x does not use any patch files. Also there's no nx-X11/lib/Xft in nx 3.5.99.X

But you do not need to go on for now. I have compiled the branch and it still does not work properly. I will work on that the nex days.

On Wed, Apr 19, 2017 at 12:38 AM, mviereck notifications@github.com wrote:

Thanks! I've tried the build again, now I get a bunch of error messages: https://nopaste.me/view/6d6848af Last lines:

Hunk #49 FAILED at 1592. 26 out of 49 hunks FAILED -- rejects in file nx-X11/lib/Xft/config.sub Patch 017_nx-X11_update-autotools-helper-files.full.patch lässt sich nicht anwenden (erzwingen mit -f) dh_quilt_patch: quilt --quiltrc /dev/null push -a || test $? = 2 returned exit code 1 debian/rules:14: die Regel für Ziel „build“ scheiterte make: *** [build] Fehler 25 dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2 debuild: fatal error at line 1116: dpkg-buildpackage -rfakeroot -us -uc failed

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

uli42 commented 7 years ago

I addition to all the above I think we should drop keyboard conversion altogether. And we should replace "xfree86" by "base".

uli42 commented 7 years ago

Just a note: "query" was not meant to query the xserver for the keyboard layout but to limit XKEYBOARD requests and only allow querying calls. You then can modify the keyboard with xmodmap (or other sw that uses plain X) only. I have

ArcticaProject / nx-libs

revise keyboard configuration #240