Did you try the current version (0.16.648) ? It should work without any change.
I can't test myself, because I only have access to 10.6 (and can't update).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After switching to Lion I have problems w/ the keyboard mapping which is totally screwed up...
Unfortunately the XQuarz version changed as well ( I've updated just today to 2.6.3 - no change though)
I believe the problem is the missing keyboard identification i can see in sshlog:
Did you run xprop -root in a local xterm on the Mac or in a remote session?
If remote: Please run it locally (without NX) and report back with the output.
If local: Apparently, the changed the standard atom names. Not much I can do until someone figures out how to finde out the actual mapping.
@all
Does it work, if you open the session property dialog and select the keyboard type manually?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well without having a Mac for analyzing/fixing, I currently can't do anything about this :(
Since I cannot afford such expensive hardware, I now have created a paypal account and activated the SourceForge donation system for this project. Hopefully there will be some donors enabling me to get a Mac in the future...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The wrong keymap issue has hit me as well and i can confirm everything that has been said so far.
One interesting tidbit is that however not the switch to OSX 10.7 immediately caused problems. I was running a suspended session until the day before and the keyboard mapping was just fine. Then i rebooted my server (after some updates including kernel) and then the newly created NX session had the issue.
Does that maybe mean that the keymap problem is created when spawning a new NX session with OpenNX?
In the light of this i tried to create a new session with the Nomachine Windows Client (that doesn't have the keymap problem at all) to resume this session with OpenNX afterwards and see if that session might behave differently, but OpenNX doesn't show this session in its session window to let me resume it unfortunately.
Btw. ~/.nx/temp/sshlog shows a keyboard variable passed to the server:
Restoresession --session="xxxxxxx" --type="unix-application" --rootless="0" --virtualdesktop="1" --application="\057usr\057bin\057startxfce4" --cache="8M" --images="32M" --link="wan" --screeninfo="1280x800x32+render" --keyboard="pc105\057de"
I am no expert but if there is any other information that might help i will gladly do so.
Furthermore i will make a donation and hope some others will as well. OpenNX really is a great alternative to the official client, please keep up the great work!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much for the detailed instructions.
It was necessary to start a new session after setting up xmodmap on the server, but after that the keyboard mapping has been working correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I used version 0.16.0.648 with OS X Lion (10.7) and the keyboard mapping was correct but after the switch to version 0.16.0.649 the mapping was messed up, I switched back to 0.16.0.648 and the keyboard mapping is correct again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had the same severe keymapping problem with Snow Leopard (i.e. backspace produces a comma on the remote server). I fixed it without using xmodmap or custom keyboard maps specified in the .nxs file as recommended in other comments. Simply disabling the XKB module on the server was sufficient to solve the problem.
Here's how:
1) Open (as root) /etc/nxserver/node.conf
2) Look for the line that says:
AGENT_EXTRA_OPTIONS_X
3) Change it to say:
AGENT_EXTRA_OPTIONS_X="-kb"
4) Save and exit
5) Restart the nx server with:
sudo nxserver --restart
My setup:
Server = CentOS 5.5 with NXSERVER - Version 3.2.0-74-SVN OS
Client = OpenNX Version 0.16.0.649 (RELEASE) on Snow Leopard (OS X 10.6.8)
Hope that helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess I should follow up since my comment below of 2011-10-07 isn't technically correct. I have been under some (un-reproducable) circumstances able to get connected with a proper keyboard, but not with any regularity. I'm trying to connect to kde sessions.
M
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did you try the current version (0.16.648) ? It should work without any change.
I can't test myself, because I only have access to 10.6 (and can't update).
After switching to Lion I have problems w/ the keyboard mapping which is totally screwed up...
Unfortunately the XQuarz version changed as well ( I've updated just today to 2.6.3 - no change though)
I believe the problem is the missing keyboard identification i can see in sshlog:
restoresession --session="NX-YYY" --type="unix-gnome" \ --keyboard="empty/empty"
Using NX from a windows client works - so I believe the server is OK.
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
I was seeing the same issue on 10.6.8, with XQuartz 2.6.3, sporadically.
I haven't figured out yet how to reproduce reliably.
However, the "down arrow" (Keycode 133) is being mapped to Meta_L.
Output of xprop -root | grep XKB:
_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "empty", "empty", "", ""
_XKB_RULES_NAMES(STRING) = "xfree86", "empty", "empty", "", ""
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
Ignore the "down arrow" part. It was resulting from a bad .Xmodmap.
@rodrigofrib:
Did you run xprop -root in a local xterm on the Mac or in a remote session?
If remote: Please run it locally (without NX) and report back with the output.
If local: Apparently, the changed the standard atom names. Not much I can do until someone figures out how to finde out the actual mapping.
@all
Does it work, if you open the session property dialog and select the keyboard type manually?
I just made an attempt to work aroud those broken XKB rule properties.
Please try the latest release 0.16.0.649 and report back if this works for you.
I'm afraid but the new version does'nt fix the problem
Though it reports now on the report terminal:
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "de", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc105", "de", "nodeadkeys", ""
3
the mapping remains screwed
Like with the former version , it does not matter if a keyboard layout for the session has been selected
Thanks anyway for your effort so far - Hobo
Well without having a Mac for analyzing/fixing, I currently can't do anything about this :(
Since I cannot afford such expensive hardware, I now have created a paypal account and activated the SourceForge donation system for this project. Hopefully there will be some donors enabling me to get a Mac in the future...
The wrong keymap issue has hit me as well and i can confirm everything that has been said so far.
One interesting tidbit is that however not the switch to OSX 10.7 immediately caused problems. I was running a suspended session until the day before and the keyboard mapping was just fine. Then i rebooted my server (after some updates including kernel) and then the newly created NX session had the issue.
Does that maybe mean that the keymap problem is created when spawning a new NX session with OpenNX?
In the light of this i tried to create a new session with the Nomachine Windows Client (that doesn't have the keymap problem at all) to resume this session with OpenNX afterwards and see if that session might behave differently, but OpenNX doesn't show this session in its session window to let me resume it unfortunately.
Btw. ~/.nx/temp/sshlog shows a keyboard variable passed to the server:
Restoresession --session="xxxxxxx" --type="unix-application" --rootless="0" --virtualdesktop="1" --application="\057usr\057bin\057startxfce4" --cache="8M" --images="32M" --link="wan" --screeninfo="1280x800x32+render" --keyboard="pc105\057de"
I am no expert but if there is any other information that might help i will gladly do so.
Furthermore i will make a donation and hope some others will as well. OpenNX really is a great alternative to the official client, please keep up the great work!
As a work-around one can modify the keycap of the remote system, see
https://discussions.apple.com/message/15948774#15948774
Thank you very much for the detailed instructions.
It was necessary to start a new session after setting up xmodmap on the server, but after that the keyboard mapping has been working correctly.
I used version 0.16.0.648 with OS X Lion (10.7) and the keyboard mapping was correct but after the switch to version 0.16.0.649 the mapping was messed up, I switched back to 0.16.0.648 and the keyboard mapping is correct again.
I had the same severe keymapping problem with Snow Leopard (i.e. backspace produces a comma on the remote server). I fixed it without using xmodmap or custom keyboard maps specified in the .nxs file as recommended in other comments. Simply disabling the XKB module on the server was sufficient to solve the problem.
Here's how:
1) Open (as root) /etc/nxserver/node.conf
2) Look for the line that says:
AGENT_EXTRA_OPTIONS_X
3) Change it to say:
AGENT_EXTRA_OPTIONS_X="-kb"
4) Save and exit
5) Restart the nx server with:
sudo nxserver --restart
My setup:
Server = CentOS 5.5 with NXSERVER - Version 3.2.0-74-SVN OS
Client = OpenNX Version 0.16.0.649 (RELEASE) on Snow Leopard (OS X 10.6.8)
Hope that helps.
I had the severe keymapping problems also, I could log in, but couldn't type. I found this
http://stackoverflow.com/questions/7093353/keymap-issues-with-nx-from-mac-os-x-lion
The explanation was exactly the problem I was having and I'm using this client now 0.16.0.649
Cheers,
Matt
I guess I should follow up since my comment below of 2011-10-07 isn't technically correct. I have been under some (un-reproducable) circumstances able to get connected with a proper keyboard, but not with any regularity. I'm trying to connect to kde sessions.
M