#9 Support OSX 10.7 (Lion)


Any plans to support 10.7 anytime soon?
Any help needed ?


  • Fritz Elfert

    Fritz Elfert - 2011-07-30

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

  • Hobo

    Hobo - 2011-08-01

    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.

  • Comment has been marked as spam. 

    You can see all pending comments posted by this user  here

    Anonymous - 2011-08-03

    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", "", ""

  • Comment has been marked as spam. 

    You can see all pending comments posted by this user  here

    Anonymous - 2011-08-03

    Ignore the "down arrow" part. It was resulting from a bad .Xmodmap.

  • Fritz Elfert

    Fritz Elfert - 2011-08-08


    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.

    Does it work, if you open the session property dialog and select the keyboard type manually?

  • Fritz Elfert

    Fritz Elfert - 2011-08-09

    I just made an attempt to work aroud those broken XKB rule properties.
    Please try the latest release and report back if this works for you.

  • Hobo

    Hobo - 2011-08-09

    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", ""

    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

  • Fritz Elfert

    Fritz Elfert - 2011-08-12

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

  • rusheee

    rusheee - 2011-08-14

    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!

  • rusheee

    rusheee - 2011-08-18

    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.

  • JM

    JM - 2011-09-02

    I used version with OS X Lion (10.7) and the keyboard mapping was correct but after the switch to version the mapping was messed up, I switched back to and the keyboard mapping is correct again.

  • Erin Simonds

    Erin Simonds - 2011-09-27

    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:


    3) Change it to say:
    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 (RELEASE) on Snow Leopard (OS X 10.6.8)

    Hope that helps.

  • Matt Savoie

    Matt Savoie - 2011-10-14

    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.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks