keyboard mapping problems

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by ndbeck...@gmail.com on 10 Jul 2009 at 11:21

[GoogleCodeExporter]

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!

Original comment by adrian.w...@gmail.com on 14 Jul 2009 at 2:34

[GoogleCodeExporter]

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

Original comment by ndbeck...@gmail.com on 14 Jul 2009 at 2:48

[GoogleCodeExporter]

This seems relevant:

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

Original comment by ndbeck...@gmail.com on 14 Jul 2009 at 2:56

[GoogleCodeExporter]

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

Original comment by kormat on 14 Jul 2009 at 6:50

[GoogleCodeExporter]

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.

Original comment by ndbeck...@gmail.com on 15 Jul 2009 at 12:01

[GoogleCodeExporter]

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

Original comment by kormat on 15 Jul 2009 at 7:05

[GoogleCodeExporter]

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

Original comment by ndbeck...@gmail.com on 15 Jul 2009 at 7:15

[GoogleCodeExporter]

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

Original comment by ndbeck...@gmail.com on 15 Jul 2009 at 7:26

[GoogleCodeExporter]

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.

Original comment by kormat on 15 Jul 2009 at 7:33

[GoogleCodeExporter]

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

Original comment by ndbeck...@gmail.com on 16 Jul 2009 at 1:16

[GoogleCodeExporter]

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

Original comment by marcelos...@gmail.com on 16 Jul 2009 at 5:04

[GoogleCodeExporter]

Is there then a workaround for neatx?

Original comment by ndbeck...@gmail.com on 16 Jul 2009 at 11:00

[GoogleCodeExporter]

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

Original comment by marcelos...@gmail.com on 16 Jul 2009 at 1:09

[GoogleCodeExporter]

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?

Original comment by ndbeck...@gmail.com on 16 Jul 2009 at 1:37

[GoogleCodeExporter]

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

Original comment by kormat on 16 Jul 2009 at 7:43

[GoogleCodeExporter]

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.

Original comment by miroslav...@gmail.com on 22 Aug 2009 at 6:30

[GoogleCodeExporter]

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

Original comment by Spenser...@gmail.com on 2 Dec 2009 at 1:16

[GoogleCodeExporter]

'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.

Original comment by michael....@gmail.com on 6 Jan 2010 at 4:27

[GoogleCodeExporter]

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?

Original comment by br...@lstc.com on 8 Feb 2010 at 11:34

[GoogleCodeExporter]

@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?

Original comment by kormat on 10 Feb 2010 at 5:45

[GoogleCodeExporter]

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....)

Original comment by br...@lstc.com on 12 Feb 2010 at 3:25

[GoogleCodeExporter]

@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.

Original comment by kormat on 12 Feb 2010 at 6:41

• Changed state: Accepted

[GoogleCodeExporter]

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.

Original comment by br...@lstc.com on 12 Feb 2010 at 6:57

[GoogleCodeExporter]

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

Original comment by br...@lstc.com on 12 Feb 2010 at 8:53

Attachments:

• compare_options

[GoogleCodeExporter]

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:

Original comment by br...@lstc.com on 12 Feb 2010 at 9:08

[GoogleCodeExporter]

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

Original comment by br...@lstc.com on 13 Feb 2010 at 1:07

[GoogleCodeExporter]

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.

Original comment by kormat on 19 Feb 2010 at 12:53

[GoogleCodeExporter]

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/

Original comment by susethai...@gmail.com on 21 Jun 2010 at 6:13