Bug 1033876

Can you try https://admin.fedoraproject.org/updates/x2goserver-4.0.1.8-1.fc20

The changelog mentions some keyboard fixes, but not sure if it covers this.

I'm afraid that new version doesn't help.

For info, in the session directory there is a file 'keyboard' which contains:
rules=xorg
model=pc105
layout=gb
variant=
options=grab:break_actions

which seems to be correct, but this keyboard type is not being set.

The session.log file still has:
nxagentXkbGetRules: WARNING! Failed to stat file [/usr/lib64/nx/X11/xkb/rules/xorg]: Unknown error 
-1.

I wonder if this is relevant?

Roderick

Do you have xkeyboard-config installed on the server?  If not, please test with it installed.

Yes, that was already installed on the server.

I'm not really familiar with how this is supposed to work.  My guess is that it is trying the run the following command:

setxkbmap -rules xorg -model pc105 -layout gb -option grab:break_actions

What is the output of that command if you run it directly?

If that does not result in an error, can you edit /etc/x2go/x2goserver.conf and set loglevel=info.  The when you start a session you should get some messages regarding the keyboard in /var/log/messages.

Also, what happens if you do not set the keyboard preferences in the client?

Does it help if you link:

ln -s /usr/share/X11/xkb /usr/lib64/nx/X11/

Orion

> setxkbmap -rules xorg -model pc105 -layout gb -option grab:break_actions
> What is the output of that command if you run it directly?

The command successfully changes the keyboard map and gives no output.

> If that does not result in an error, can you edit /etc/x2go/x2goserver.conf and set loglevel=info.  The when > you start a session you should get some messages regarding the keyboard in /var/log/messages.

I can send a complete log, but the relevant lines seem to be (I have changed the real host and user names):

Nov 26 12:11:57 dummyhost /usr/bin/x2gostartagent: blocking creation of agent's keyboard file /home/dummyuser/.x2go/C-dummyuser-59-1385467913_stDKDE_dp32/keyboard as requested by session startup command
Nov 26 12:11:59 dummyhost /usr/bin/x2gosetkeyboard: x2gosetkeyboard called with options:
Nov 26 12:11:59 dummyhost /usr/bin/x2gosetkeyboard: /home/dummyuser/.x2go/C-dummyuser-59-1385467913_stDKDE_dp32/keyboard is blocked, not setting keyboard parameters from client-side settings

I wonder what the bit about session startup blocking agent's keyboard file is about? That file does not seem to be created, but in Comment 2 I did have a keyboard file.

> Also, what happens if you do not set the keyboard preferences in the client?
I've tried that, and setting the layout and model to auto. Always the same thing. US keyboard map is loaded.

>Does it help if you link:
>
>ln -s /usr/share/X11/xkb /usr/lib64/nx/X11/

No, just the same US keyboard layout.

IAll this has been starting a KDE session, so I tried gnome but get a sad face in my client and the words "Oh no! Something has gone wrong".

Then I tried a custom session with Terminal application and it works and the keyboard mappings are correct!

The x2gostartagent commands from /var/log/messages are:
x2gostartagent called with options: 800x600 adsl 16m-jpeg-9 unix-kde-depth_32 us pc105/gb 1 D KDE
x2gostartagent called with options: 800x600 adsl 16m-jpeg-9 unix-kde-depth_32 us pc105/gb 1 D GNOME
2gostartagent called with options: 800x600 adsl 16m-jpeg-9 unix-kde-depth_32 us pc105/gb 1 R TERMINAL

According to man x2gostartagent the fifth argument is the keyboard layout so this doesn't seem to be being passed down properly.

For some reason that doesn't seem to matter for the simple terminal case.

Thanks for your attention to this.

Roderick

Please try editing /usr/bin/x2gostartagent and here:

if [ "$X2GO_SET_KBD" == "0" ] || [ "$X2GO_KBD_TYPE" != "auto" ]; then
        $X2GO_LIB_PATH/x2gosyslog "$0" "info" "blocking creation of agent's keyboard file ${SESSION_DIR}/keyboard as requested by session startup command"
        mkdir -p ${SESSION_DIR}/keyboard
fi

change the != "auto" to == "auto".

x2goserver-4.0.1.8-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/x2goserver-4.0.1.8-2.fc20

x2goserver-4.0.1.8-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/x2goserver-4.0.1.8-2.el6

x2goserver-4.0.1.8-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/x2goserver-4.0.1.8-2.fc19

Orion

It still doesn't work. The x2gosetkeyboard messages are:
/usr/bin/x2gosetkeyboard: x2gosetkeyboard called with options:

ie the options are blank, but then a couple of lines later:

/usr/bin/x2gosetkeyboard: Setting X keyboard according to /home/testuser/.x2go/C-testuser-70-1385660130_stDKDE_dp32/keyboard

and this contains:
rules=xorg
model=pc105
layout=gb
variant=
options=grab:break_actions

which all looks correct.

Later there is:
 /usr/bin/x2goruncommand: launching session with Xsession-x2go mechanism, using STARTUP="startkde"

so I wonder if kde is somehow overriding what was set by x2gosetkeyboard, especially since the simple terminal session I described in comment #6 does have the correct keyboard mappings.

Roderick

Orion

I put some debug messages into x2gosetkeyboard and it looks like this is now setting the correct keyboard type. This makes me suspicious that the startkde which is setting up the KDE session is overriding these keyboard mappings. However, I also tried an xfce session and that had the wrong keyboard mappings as well, so I'm confused. Only the plain terminal session seems to get the mappings right.

Roderick

What is the output of "setxkbmap -print"?  What does System Settings -> Input -> Keyboard -> Layout report in KDE?

Package x2goserver-4.0.1.8-2.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing x2goserver-4.0.1.8-2.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-22368/x2goserver-4.0.1.8-2.fc20
then log in and leave karma (feedback).

In a simple terminal session, setxkbmap -print gives:
#xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete+xfree86(grab_break)"  };
        xkb_symbols   { include "pc+gb+inet(pc105)"     };
        xkb_geometry  { include "pc(pc105)"     };
};

In a KDE session, setxkbmap -print gives:
xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete+xfree86(grab_break)"  };
        xkb_symbols   { include "pc+us+inet(evdev)"     };
        xkb_geometry  { include "pc(pc104)"     };
};

System Settings -> Input -> Keyboard -> Layout report in KDE shows:
In the Layout Indicator:
Show layout indicator is checked is checked
Show label radio button is selected

In the Switching policy:
Global radio button is checked

Shortcuts for Switching Layout
Alternative shortcut is set to ctrl+alt+K
Other shortcuts are set to none.

Configure Layouts is unchecked and there are no layouts defined.

This is essentially the same as I see in my KDE session running on an NX3 server. The only difference is that on the NX server session all the shortcuts for switching layout are set to None.

Orion

This may not be x2go's problem after all, but rather, a KDE configuration issue.

Having said that, I found a kludge that I had to put in last year for NX, which I had forgotten about. This involved calling a script using the setting UserScriptAfterSessionStart in nxnode.cfg to parse the session keyboard file and then call the correct setxkbmap command.

I'll ask on the x2go list what is the equilvalent in x2go.

I also found that by setting the correct keyboard hardware and layout in the KDE setting I could get the correct keyboard mapping ok. Curiously, this is not needed when logging in at the console.

However, although the KDE keyboard switcher can handle several different layouts its not obvious that it can handle switching between hardware models. Our use case is PC 104/5 keyboard at the PC console and then a Mac keyboard over x2go.

I'll ask on one of the kde lists about this.

Roderick

I'm starting to think this may be an issue with using an Windows client.  I've asked on the x2go-dev list.

Orion

I may have solved this.

I had cause to disable the kscreen kded module as recommended here (https://bugs.kde.org/show_bug.cgi?id=319065) because it was causing problems by resetting the desktop session dimensions.

Since then, the keyboard mappings have been fine when connecting from my UK keyboard laptop. So, for the moment I think this could have been a kscreen issue.

However, I have made lots of changes in my testing account and in the x2go config while trying to sort this out and bits of the system see to have a memory, so I'm reserving final judgement for now. But, it is looking promising.

I'll try to give a status update in a few days time when I've had a chance to re-install my testing system from scratch.

Thanks for all your help with this.

Roderick

Just to report that I have a workable x2go connection in the Fedora 20 release now with the keyboard set correctly.

I'm using: x2goserver-4.0.1.6-5.fc20.x86_64 and the windows client version 4.0.1.2.

I'm running with the kscreen2 daemon switched off so that the desktop doesn't get resized by it.

To get the keyboard mapping working reliably I found that I had to set the keyboard model and layout explicitly in the client and then:

1) touch /usr/share/X11/xkb/keymap.dir

2) remove all the ibus packages

Without step 2) the keyboard mapping is correctly set the first time you connect from a client, but subsequent connects from other clients with different keyboards get the keyboard mapping set from the first client connection.

Its possible that there is a way to configure ibus to work nicely with the x2go client but I haven't figured it out yet.

nx-libs-3.5.0.21-5.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/nx-libs-3.5.0.21-5.fc20

Package nx-libs-3.5.0.21-5.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nx-libs-3.5.0.21-5.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-0142/nx-libs-3.5.0.21-5.fc20
then log in and leave karma (feedback).

Any chance to get nx-libs-3.5.0.21-5 for Fedora 19 as well?

It's there:

https://admin.fedoraproject.org/updates/nx-libs-3.5.0.21-5.fc19

since this bug report is for F20, I only linked that update.

nx-libs-3.5.0.22-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/nx-libs-3.5.0.22-1.fc19

nx-libs-3.5.0.22-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/nx-libs-3.5.0.22-1.fc20

nx-libs-3.5.0.22-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/nx-libs-3.5.0.22-1.el6

nx-libs-3.5.0.22-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

nx-libs-3.5.0.22-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

nx-libs-3.5.0.22-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.