Regression: Connecting to FreeNX breaks keyboard layout in Intrepid

I experience the same problem here, connecting from a current intrepid box (i386, also haunted by Bug #255008) via NX to a hardy i386 box. No combination of "setxkbmap -model pc105", "setxkbmap -model evdev" or "gconftool-2 --recursive-unset /desktop/gnome/peripherals/keyboard" on client or server makes the problem go away.

Same problem here. Got most of the keys remapped properly using this link:

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/255008/comments/97

Still the up key maps to printscreen, which is rather annoying to say the least as I code from home.

PeteJ said on the forum:

After reading tons, having no clue, flailing around, on both client and server I did System, Preferences, Keyboard, Layouts, "Evdev-managed keyboard" or similar, and then in the nx session, on the server, I did System, Preference, Keyboard shortcuts, Desktop, Take a screenshot. It was "Print", I pressed "Ctrl+PrtSc", it changed to "Ctrl+Print", and now ALL the nav keys work fine.

This works for me too.

I also tried this, but it didn't work. After setting "Taka a screenshot" to disabled, Cursor Up does no longer make a screenshot, but with xev I see that it still produces the PrtSc scancode, and cursor movement does still not work.

I'm following the intrepid development since the beginning.
To make the keyboard work on an intrepid client, you need to set the model to
evdev on the nx session:
  System -> Preferences -> Keyboard -> Keyboard model -> Generic -> "Evdev-managed keyboard"

Then close the nx session and start another session (This will correct the up-key taking screen shots).
If want to you use another client again, you need to revert the process or you can set the hardy
client to use evdev instead of kbd.

Hope this helps.

The important part was setting the keyboard to Evdev-managed keyboard. Whether it is the remote or local or both that does the trick I'm not sure of.

Changing the print-screen combination is convenient to allow a print screen to be executed remotely, instead of locally only.

This is a bug in gnome-control-center.
The keyboard model is changed, but the key bindings are not updated to use
the new keycodes.

To repeat this behavior you need to:
 1 ) Use evdev driver.
 2 ) Start the X session using xfree86 or xorg xkb rules.
 3 ) Up arrow will take an screenshot.
 4 ) Change keyboard model to evdev.
 5 ) Up arrow will still take an screenshot.
 6 ) Go to keyboard shortcuts and change the "Take screenshot" to ctrl-print and close.
 7 ) Go to keyboard shortcuts and change the "Take screenshot" to print and close.
 8 ) Up arrow will not take an screenshot anymore.

I tried it with Gnome, KDE, IceWM and even a bare xterm on the server side, all with the same effect. So I don't think it has anything to do with the chosen desktop environment.

I'm seeing this as well. Everything works fine locally. Switching the keyboard layout to evdev helps, but the directional keys no longer work (arrows, pg up/down, etc).

Works:
WinXP to Intrepid NoMachine
Hardy to Intrepid NoMachine

Broken:
Intrepid to Intrepid NoMachine

On Sat, Nov 1, 2008 at 3:57 PM, Martin Emrich <email address hidden> wrote:

> I tried it with Gnome, KDE, IceWM and even a bare xterm on the server
> side, all with the same effect. So I don't think it has anything to do
> with the chosen desktop environment.
>

Maybe, but, using an intrepid client and a hardy (or older) server:
 1) Start a xterm session with "new virtual desktop".
 2) Execute gnome-session on xtem.
 3) Change the keyboard model.
 4) Kill the gnome-session.
 5) Start a new gnome-session on the same xterm.
 6) The keyboard now works as spected

So I really think it is a gnome bug, maybe gnome-control-center, maybe
gnome-settings-daemon
or even gnome-session.

On Mon, Nov 3, 2008 at 4:12 PM, Marcelo Boveto Shima <<email address hidden>
> wrote:

>
> On Sat, Nov 1, 2008 at 3:57 PM, Martin Emrich <email address hidden> wrote:
>
>> I tried it with Gnome, KDE, IceWM and even a bare xterm on the server
>> side, all with the same effect. So I don't think it has anything to do
>> with the chosen desktop environment.
>>
>
> Maybe, but, using an intrepid client and a hardy (or older) server:
> 1) Start a xterm session with "new virtual desktop".
> 2) Execute gnome-session on xtem.
> 3) Change the keyboard model.
> 4) Kill the gnome-session.
> 5) Start a new gnome-session on the same xterm.
> 6) The keyboard now works as spected
>
> So I really think it is a gnome bug, maybe gnome-control-center, maybe
> gnome-settings-daemon
> or even gnome-session.
>

I just found the workaround:
 $ killall metacity

This should reset the hotkeys table.

For intrepid I uploaded a new version of nx with a patch to define the xkb rules to xfree86.
So it should revert to the same behavior of a hardy server.

I've updated the freenx-team whiteboard with:

PPA whiteboard:

Intrepid (Xorg 7.4) release changed the default driver (evdev) for inputs (keyboards, mouse, etc).
This new release changed the xkb rules too, so we have the following situations:

These steps must be followed on the remote session.

1) Intrepid client:
    * Change the keyboard model to evdev:
       - GNOME: System -> Preferences -> Keyboard -> Keyboard model -> Generic -> "Evdev-managed keyboard"
    * Restart the window manager that keeps the keyboard hotkeys:
       - GNOME: Go to a terminal and execute $ killall metacity.

2) Hardy client:
    * Revert the settings if you have used an Intrepid client
    * Restart the window manager that keeps the keyboard hotkeys:
       - GNOME: Go to a terminal and execute $ killall metacity.

Changing the affected package to metacity because xorg-server is reporting the right keycode.

I noticed that there were some updates to some of the affected packages. Can anyone confirm that this is fixed? I have downgraded my client to Hardy, so I'm unable to test.

This is still broken for me.

Client: Fully up-to-date Intrepid, NX client version 3.2.0-13

Server: CentOS 4.6, NX server version 2.1.0-72

do you have proposed updates enabled in software sources?

It is not fixed yet. No easy fix, only workarounds.

On Tue, Nov 4, 2008 at 4:26 PM, jmcantrell <email address hidden> wrote:

> I noticed that there were some updates to some of the affected packages.
> Can anyone confirm that this is fixed? I have downgraded my client to
> Hardy, so I'm unable to test.
>
>

Right, the updates from intrepid-proposed do not fix this issue.

I found that setting my keyboard on the client to Generic->102 key (Intl) fixed it for me. I'm running Kubuntu but I installed gnome specifically to address this issue (The KDE system config stuff is crap). Switching back to KDE, it also seemed OK. NB: I am using KDM as my DM.

Using evdev from the gnome configuration settings, oddly, did not stick for a gnome environment but did for kde (every time I decided to click to apply the changes system-wide).

The same at my configuration (Interprid -> Hardy, both system uses NoMachin FreeNX).

Problem has been solved using Keybard -> Layouts -> Generic -> Evdev and killall metacity on both sides.

I too have had this problem. Fixed by Preferences -> Keyboard -> Layouts -> Generic -> Evdev (Apply System-Wide..) followed by killall metacity on the remote.

The problem with the evdev-solution is that it causes problems for those users that may be on the physical machine. E.g. when I log into my home server over FreeNX the keyboard now works. However if I log in locally the keyboard is broken (same problem - except now in reverse).

Hence one must either change the keyboard layout every time one changes login method, or one must choose which keyboard is more important; remote or local.

There have been a number of updates, but the problem seems to persist.

FWIW, I have this exact same problem using VMWare Workstation with this setup:
  host = Ubuntu 8.10
  guest= Ubuntu 8.04
  VMWare Workstation version = 6.5.0 build-118166

In this setup, UpArrow triggers 'save screenshot' (in the guest), RightControl types out "^[[6~", PageDown triggers context menu, PageUp types a '/' character, etc. These are all the same symptoms I get when using nxclient.

Daniel Holbert wrote:
> FWIW, I have this exact same problem using VMWare Workstation with this setup:
> host = Ubuntu 8.10
> guest= Ubuntu 8.04
> VMWare Workstation version = 6.5.0 build-118166
>
> In this setup, UpArrow triggers 'save screenshot' (in the guest),
> RightControl types out "^[[6~", PageDown triggers context menu, PageUp
> types a '/' character, etc. These are all the same symptoms I get when
> using nxclient.
>
>
So far the fixes I have found for these issues are below:

There are a couple other 'hacks' around but this one seems to fix all
the issues including Unity.
Add this to:
/etc/vmware/config

---------- snip ----------------------
xkeymap.keycode.108 = 0x138 # Alt_R
xkeymap.keycode.106 = 0x135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0x148 # Up
xkeymap.keycode.116 = 0x150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0x152 # Insert
xkeymap.keycode.119 = 0x153 # Delete
xkeymap.keycode.110 = 0x147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0x149 # Prior
xkeymap.keycode.117 = 0x151 # Next
xkeymap.keycode.78 = 0x46 # Scroll_Lock
xkeymap.keycode.127 = 0x100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu
--------------snip ---------------------------

The fix for NoMachine is to upgrade to 3.3 (just out 2 days ago) on both
server and client. Obviously restart the server services. BTW... VWware
Workstation 6.5.1 is out.

-Craig Herring

Fixing or working-around this problem for every service does not really feel very satisfactory. I just upgraded NX Free on server and client, and after a quick test it seems to work. But I still sometimes (not always) have to do "setxkbmap -model evdev -layout de" on my laptop to make the keyboard work correctly.

Does anybody know what causes these problems? It is obviously the same keys (mostly cursor keys) for very many people with many different keyboards.

NX 3.3.0 on the build queue on my PPA:
https://edge.launchpad.net/~marceloshima/+archive

1 week of testing before going to freenx-team ppa.
Needs FreeNX >= 0.7.3+svn612-0freenxteam9.

Let me know your experiences.

Troubleshooting:

If "$ xprop -root | grep XKB" prints "_XKB_RULES_NAMES_BACKUP(STRING)" != "_XKB_RULES_NAMES(STRING)",
probably gnome is overriding the settings created by nx session:
"$ gconftool-2 --recursive-unset /desktop/gnome/peripherals/keyboard/kbd"
this will make gnome use NX settings.

If up-arrow triggers screen shot then:
"$ killall metacity"
this will force metacity to update to the new keycodes.

If you have 2 different layouts and gnome-keyboard switcher don't work, then:
$ setxkbmap -layout "us,br"
This will make gnome reload the layout settings from nxagent.

I agree that this is a bug on the client, eg Ubuntu 8.10 - why should I
be forced to upgrade *all* my server systems (which don't run Ubuntu of
any flavour) just because I upgraded my client OS - note "OS" - not
client software.

Alex

On Tue, 2008-11-25 at 18:15 +0000, Martin Emrich wrote:
> Fixing or working-around this problem for every service does not really
> feel very satisfactory. I just upgraded NX Free on server and client,
> and after a quick test it seems to work. But I still sometimes (not
> always) have to do "setxkbmap -model evdev -layout de" on my laptop to
> make the keyboard work correctly.
>
> Does anybody know what causes these problems? It is obviously the same
> keys (mostly cursor keys) for very many people with many different
> keyboards.
>

Another workaround is to use ctrl together with f,b,n and p instead of the arrow keys.

> NX 3.3.0 on the build queue on my PPA:
> https://edge.launchpad.net/~marceloshima/+archive
>
> 1 week of testing before going to freenx-team ppa.
> Needs FreeNX >= 0.7.3+svn612-0freenxteam9.
>
> Let me know your experiences.

I tried the newest version from https://launchpad.net/~freenx-team/+archive for Hardy.

The bug still exists but the keyboard is now broken in a different way. For example the right arrow key does not work from Ubuntu 8.10 and Mac OS X clients. I'm using a german keyboard. MS Windows as client works fine.

I even tried gconftool-2 --recursive-unset /desktop/gnome/peripherals/keyboard/kbd but it did not help.

Upstream bug for reference:
http://www.nomachine.com/tr/view.php?id=TR11F02131

Bug fixed in new NX release
On the build queue on freenx-team ppa.

After th update things have got worse. The down arrow key is mapped to enter and delete is mapped to printscreen. The other navigation keys so not work. The killall metacity workaround no longer works.

Fixed packages work fine here with German keyboard and Intrepid client.

I'd be very happy if this bug could be fixed on the client side. After all, it was a client change that introduced the bug and there are situations where you have no influence over what's installed on the server.

Intrepid server and intrepid client for me. If I change from the edev managed keyboard to the generic 101 keyboard the arrow keys work. However the delete key maps to print screen still.

Same story using an intrepid client and Hardy server. The navigation keys are restored using the generic 101 keyboard but the delete key always maps to printscreen. This configuration worked without any fix prior to the update.

What is your client keymap?

On Wed, Jan 21, 2009 at 8:43 PM, mabawsa <email address hidden> wrote:

> Same story using an intrepid client and Hardy server. The navigation
> keys are restored using the generic 101 keyboard but the delete key
> always maps to printscreen. This configuration worked without any fix
> prior to the update.

I have tried edev managed -US and 101 Generic US. Both produce the same result.

Correction:
The generic 101 US works when it is set on both client and server. I had only tried edev client and Generic 101 on the server. Edev on the server side breaks the navigation keys. This is still a problem as I also access these machines using Japanese keyboards (106 keys).

So, you have this problem with the jp106 keymap?

Did you tried to set the keymap to jp106 on the server too?

There are other keys wrong mapped or just the delete key?

On Thu, Jan 22, 2009 at 2:50 AM, mabawsa <email address hidden> wrote:

> Correction:
> The generic 101 US works when it is set on both client and server. I had
> only tried edev client and Generic 101 on the server. Edev on the server
> side breaks the navigation keys. This is still a problem as I also access
> these machines using Japanese keyboards (106 keys).
>
>

Nope on evdev managed keyboards server-side cause all navigation keys to
map incorrectly.
kb101-us on server and evdev-us on the client causes the delete key to
be mapped as printscrn
For now as long as the client and server are kb101-us the fix works.
I have not tried the jp106 keyboard yet. I will do it as soon as I can.

Thanks

Marcelo Boveto Shima wrote:
> So, you have this problem with the jp106 keymap?
>
> Did you tried to set the keymap to jp106 on the server too?
>
> There are other keys wrong mapped or just the delete key?
>
> On Thu, Jan 22, 2009 at 2:50 AM, mabawsa <email address hidden> wrote:
>
>
>> Correction:
>> The generic 101 US works when it is set on both client and server. I had
>> only tried edev client and Generic 101 on the server. Edev on the server
>> side breaks the navigation keys. This is still a problem as I also access
>> these machines using Japanese keyboards (106 keys).
>>
>>
>>
>
>

By the navigation keys I mean:
up (mapped to enter), left (nothing), down (nothing), right (nothing)
arrow keys
pageup (nothing), pagedn (nothing), Home (nothing), End (nothing)
Delete (prntscrn), Insert (nothing), prntscrn (nothing)

The brackets show what I have seen when I use evdev managed keyboard
serverside.

On Thu, Jan 22, 2009 at 12:00 PM, mabawsa <email address hidden> wrote:

> Nope on evdev managed keyboards server-side cause all navigation keys to
> map incorrectly.

This is the way it works. With this updated nxagent, it converts the evdev
keycodes into pc105 keycodes. So it is a predictable behavior.

>
> kb101-us on server and evdev-us on the client causes the delete key to
> be mapped as printscrn
> For now as long as the client and server are kb101-us the fix works.

This is the way it should be.

I have not tried the jp106 keyboard yet. I will do it as soon as I can.
>
> Thanks
>
>
The workarounds are not needed anymore. So you should not set the
keymap to evdev.

If you still have problems let me know.

Running the following commands when logged in on the server via NX fixes the cursor keys for me:

xmodmap -e "keycode 113=Left"
xmodmap -e "keycode 114=Right"
xmodmap -e "keycode 111=Up"
xmodmap -e "keycode 116=Down"

I have a US keyboard.

Same thing here connecting from Intrepid client (x86) - to an arch linux freenx server - i.e no arrow keys, etc

- I could always connect from gentoo, arch linux and opensuse fine - however I use KDE on these systems

I have just tried connecting from Intrepid with kde4.2 and it works fine.

i.e - this issue only seems to effect connecting from Ubuntu gnome. (this is no issue for me as a prefer KDE)

To fix this bug, on the server type:

  apt-get install xkb-data

then type:

  setxkbmap

(or restart nx)

The file /usr/share/X11/xkb/rules/xorg is the file that was needed.

This could be fixed with a dependency in one of the nx packages.

It also happens with KDE, maybe you have this package already installed

still a problem, reproduced in Jaunty.

Still a problem in karmic

I'm not sure if it is related, but I have noticed that certain apps that pass keypresses (Ctrl+Alt+Delete) to a sub program like virt-manager are still broken even if the keymap is right inside KDE. This works on the console just fine, just not within FreeNX.

Just wanted to say thanks to Johan from comment #44. This works for me. I'm using an Ubuntu 9.04 client, connecting to an OpenSUSE 10.3 server. I've added a few things to Johan's lines...

xmodmap -e "keycode 110=Home"
xmodmap -e "keycode 113=Left"
xmodmap -e "keycode 114=Right"
xmodmap -e "keycode 111=Up"
xmodmap -e "keycode 116=Down"
xmodmap -e "keycode 118=Insert"
xmodmap -e "keycode 112=Page_Up"
xmodmap -e "keycode 115=End"

For some reason, when I press the Page_Down key, xev doesn't seem to think I'm sending _ANY_ key press events on the server. But at least I have my arrow keys and home/end working again.

Using nxserver 3.4.0 on the server (running hardy, with Gnome/metacity as the desktop environment) and nxclient 3.4.0 on the clients (running Ubuntu 9.10 or Windows XP), I did not see this problem since several months. Anyone else?

I've just managed to get things working on my machines.

My guess is that re-loading the evdev module did the trick (I actually did a full server reboot).

I was already using evdev as the keyboard on both the server and client. That was working fine until I upgraded the server to KDE 4. This (re-) broke the keyboard mappings. I tried restarting the free nx service, xdm service, logging out / in. No help. Restarting the server did the trick though.

It just won't work for me.
My cursor keys are still messed up.
i can use xmodmap to make them works, but Alt_R modifier won't (in italian layout i cannot write @,#,[,] )
Also setxkbmap doesn't work, no matter what option i use, i get:
"Error loading new keyboard description"
I don't use any xorg.conf and my xorg server (client and server side) is 1.7.5

Any hope this will be fixed?

This is broken for me and none of the workarounds have helped. My client and server machines are both running Lucid. I am running the official NX client and server so the bug is not in freenx.
I'd be nice if we could get the importance bumped up from low and hopefully get the bug assigned to someone. As a result of this bug, I am completely unable to work on my machine since replacing my openSUSE install with Ubuntu.
Anyone have any other ideas for workarounds or debugging info I can provide?

Please Open a new bug unless you are running Intrepid/FreeNX.

Oh by the way you may want to check the gnome-settings-daemon. This caused the problems for me.

Sure. What do you mean by "check the gnome-settings-daemon"? What am I supposed to do exactly?

I still had this bug on 13.04 with FreeNX ppa package connecting to the 13.04 server from a 12.04 client. The only solution (no specific setkbmap or xmodmap line worked [even matching what I got in 'xev' !], I could not find evdev in keyboard options [despite it in kernel and xorg.conf.d], and no gconf/dconf unset worked either) that succeeded for me was

on client:
xmodmap -pke > localxmodmap

(transfer localxmodmap to server)

on server:
xmodmap localxmodmap

I post on this "resolved" bug (many forums list 12.10 users struggling) only to help others. Solution was found here:
http://askubuntu.com/questions/123867/keyboard-map-is-incorrect-when-using-an-nx-client