keyboard mapping problems about neatx HOT 28 OPEN

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 <katakana> 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/