What steps will reproduce the problem? 1. server is neatx-0.3.1 on Fedora F11 x86_64 2. client is nxclient-3.3.0-6.x86_64 on Fedora F11 x86_64 3. Session on both ends in kde. keyboard layouts enabled, keyboard model is set to evdev-managed (which I guess is default?) corresponding command is: setxkbmap -model evdev -layout us -variant

Keyboard arrow keys are mapped incorrectly (not numpad arrow keys).

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Please provide any additional information below.

I'm not so sure this is a problem in neatx ; the same problem exists where you have

NX-client (Ubuntu 9.04/GNOME) -> FreeNX server (CentOS 5)

The up arrow ends up bound to the screenshot key and the other arrows don't work ... most irritating.

And I believe it's endemic to a number of configurations.

That said, if the power of Google can fathom this bug out we can fix it everywhere, hooray!

I suspect this is related to 'evdev', but I don't know what the fix is

This seems relevant:

http://www.nabble.com/keyboard-mapping-td24041171.html

That sounds like http://www.nomachine.com/tr/view.php?id=TR11F02131 . Can you confirm what version of nxagent you're using?

I updated the server side to Fedora package nx-3.3.0-35.fc11.x86_64.rpm (from updates-testing), which includes

rpm -ql nx | grep agent /usr/bin/nxagent /usr/libexec/nx/nxagent

I also rebooted machine to make sure it used the new agent. No difference in result.

For example, the up arrow key maps to according to emacs.

3.3.0-35? Looks like that's a madeup version number - the latest version of NoMachine's packages that i can see is -22 (http://www.nomachine.com/download-package.php?Prod_Id=992), so i can't tell you if it contains the fix from NoMachine

35 is fedora internal number - should be same as 3.3.0 source

Ignore previous transmission. I got the fedora src rpm, and here's what it is built from:

Version: 3.3.0 ... Source0: http://64.34.161.181/download/%{version}/sources/nxproxy-%{version}-2.tar.gz Source1: http://64.34.161.181/download/%{version}/sources/nxcomp-%{version}-4.tar.gz Source2: http://64.34.161.181/download/%{version}/sources/nxcompext-%{version}-4.tar.gz Source3: http://64.34.161.181/download/%{version}/sources/nxssh-%{version}-1.tar.gz

Shadowing Libraries

Source4: http://64.34.161.181/download/%{version}/sources/nxcompshad-%{version}-3.tar.gz

X11 Support Programs and Libraries

Source5: http://64.34.161.181/download/%{version}/sources/nx-X11-%{version}-6.tar.gz Source6: http://64.34.161.181/download/%{version}/sources/nxauth-%{version}-1.tar.gz

X11 Agent Sources

Source7: http://64.34.161.181/download/%{version}/sources/nxagent-%{version}-13.tar.gz

NX Example Scripts

Source8: http://64.34.161.181/download/%{version}/sources/nxscripts-%{version}-1.tar.gz

Source9: nxwrapper.in Source10: docs.tar.bz2

Source11: nxfind-provides.sh

Sent via upstream web form on 2009/05/17 (enquiry ID DE05C00477).

Patch0: nx-gcc44.patch

Ok, great. So, from http://www.nomachine.com/news-read.php?idnews=254 (which is when they released their fix), these are the updated components:

nxcompext-3.3.0-3 nxagent-3.3.0-9 nx-X11-3.3.0-4

Curious. If i'm reading this right, you have nxcompext -4 (same as what !M released), nxagent -13 (newer than the above !M release), and nx-X11 -4 (older than !M released). That last one could well be the issue. If you're able to rebuild the fedora package, it would be worth trying with a more recent nx-X11 version.

Did you misread the numbers? Looks to me that the above list of Sources is exactly the same as the ones here: http://www.nomachine.com/sources.php

This is borring issue. I don't have hope that it will be ever corrected =(.

ndbecker2: The problem is that you must NOT use evdev in this case. You should use the correct keyboard for your keyboard. You are using a broken configuration on a workarounded environment. You can read my comment on http://www.nabble.com/keyboard-mapping-td24041171.html

adrian.wilkins: You problem probably is different. FreeNX on CentOS probably is not patched. So follow http://www.nabble.com/keyboard-mapping-td24041171.html

Is there then a workaround for neatx?

You must NOT use evdev. You should use the correct keyboard for your keyboard.

On the client: $setxkbmap -model pc105(??) -layout us

On the server: $setxkbmap -model pc105(??) -layout us

OK, on client I used kde/settings/regional/keyboard layout to select which gives:

setxkbmap -model pc105 -layout us -variant

But any way to automate setting on server, or should client send this to the server?

@ndecker2 Doh, you're right, i did misread the numbers. Sorry.

If somebody can enlighten me. I am encountering this problem with freenx on CentOS, but the one caveat is that it appears only when I am logged in as normal user. If i login as a normal user via nxclient (Ubuntu 9.04) to FreeNX running on CentOS 5.3 then the arrow keys misbehave. If I on the other hand login as a root via nxclient, the arrow keys work just fine. This is fresh installation without any modifications made. If this is a problem of NX server or client, why would it work in one case and not the other. This behavior is consistent between 2 different CentOS servers I have access to from this client.

I have the same issue as the user above miroslave.halas. It's a strange bug.

'yum install xorg-x11-xkb-utils' and restart NX session resolved my issues. CentOS 5.4 + xfce4 and !M provided RPM's on the server. Ubuntu 9.10 on the client with !M provided debs.

I have a possibly related problem:

My server is SuSE 11.2 with nx-3.3.0-38.el5.x86_64 (I know -- this is a RedHat rpm, but there is no SuSE NX-3.3 rpm and building NX seems to be out as well, since they are now distributing 3.4 and I can't find 3.3 sources -- it seems to work fine as far as I can tell -- I've also tried NX-3.2 from SuSE and I see no difference) and neatx -- I also have FreeNX running. Client is also SuSE 11.2 with nxclient-3.4.0-5.x86_64 from !M.

Most of the errors reported here seem to be related to xmodmap problems. My xmodmaps between the machines are fine, but the KEYCODE from the arrow keys is wrong. On the client, the up arrow gets keycode 111 (as reported by xev). When I try the same key in an NX window (running xev on the server), I get keycode 98.

When I switch to FreeNX on the server, I get keycode 111 and the arrow keys behave fine. I've looked through the startup logs in /var/log/messages (with logging set as verbose as possible) and everything LOOKS OK. Where should I look now?

@michael.mattsson: thanks for the tip! I have a patch out for review that adds that package to the spec file's dependancy list.

@brian: what happens if you set "use-xsession" to "false" in neatx.conf?

I tried setting "use-xsession" to "false" in neatx.conf, and saw no difference in behavior at all.

(Sorry for the delay, I tried posting the same comment a few days ago and it seems it never showed up...I don't know what I did wrong....)

@brian: Damn. Actually, i can reproduce the issue here myself, with ubuntu karmic as the client and fedora10 as the server. I'm not really sure what's going on here. If you have both neatx and freenx setup, i'd suggest comparing the difference between the nxagent options file for both sessions, and see if freenx passes in something different.

kormat: Great -- I'm glad you can reproduce this. I already tried turning on full logging for freenx to compare to neatx, and the freenx logging is rather anemic -- I didn't see anything. I'll look again for anything in freenx related to nxagent options, and let you know what I find.

Kormat: I'm attaching a file containing the nxagent command line options and options files from FreeNX (which has correct keyboard mapping and fullscreen initialization) and Neatx. The there are a lot of diffeences, but the ones that stick out to me as possibly important:

Neatx passes "-client=linux" and FreeNX does not FreeNX passed "fullscreen=1" and Neatx does not (fullscreen issue?) Neatx has "geometry" in the options file, FreeNX has it on the command line Neatx has "keyboard" in the options file, FreeNX has it BOTH in the options and command line args Neatx has "resize=0" which FreeNX does not (fullscreen issue ??) FreeNX has "-persistent" on the command line, Neatx does not

Kormat: I hacked node.py to reset the client to "unknown", and now my keys work fine. I remember reading something about this somewhere (NX doing something "special" for the client=linux case), but can't seem to find it anywhere....

I just added the indicated line around line 160 of node.py:

self._ParseClientargs(clientargs)

self.client = "unknown"   # <<<<< added this line

if _env is None:

Finally found it. This post discusses a "workaround" for keyboard issues in the nxagent code that is triggered if "client=linux" is set. Hopefully it sheds some light on things. From what I gather, the "client=linux" should only be used in some cases, depending on whether this workaround is needed or not? I suspect it depends on whether the client and server are using compatible versions of xorg or not?

http://mail.kde.org/pipermail/freenx-knx/2009-June/008219.html

Ahhah. Nice work! I'm not sure what the best way to fix this is, not passing in that client=linux param presumably breaks things for someone. I'll have a play with it and see what i can do.

Neatx currently differs substantially from !M NX/FreeNX in what parameters it passes etc, which i plan to fix. We're likely to be causing ourselves trouble as it is.

For openSUSE11.2, It worked.

$ vi /etc/X11/xorg.conf

Section "ServerFlags" Option "AllowMouseOpenFail" "on" Option "ZapWarning" "on"

Additional

Option "AutoAddDevices" "false" EndSection

Regards, http://www.susethailand.com/suseforum/