Bug 50553 - xkeyboard-config 2.6 breaks layout in FreeNX session (de-nodeadkeys)
Summary: xkeyboard-config 2.6 breaks layout in FreeNX session (de-nodeadkeys)
Status: RESOLVED MOVED
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: xkb
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-31 12:23 UTC by Andreas Radke
Modified: 2018-12-28 00:35 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
local desktop log 2.5.1 (58.77 KB, application/octet-stream)
2012-06-03 02:03 UTC, Andreas Radke
Details
local desktop log 2.6.0 (58.67 KB, application/octet-stream)
2012-06-03 02:03 UTC, Andreas Radke
Details
remote NX log 2.5.1 (54.97 KB, text/plain)
2012-06-03 10:59 UTC, Andreas Radke
Details
remote NX log 2.6.0 (10.45 KB, text/plain)
2012-06-03 11:00 UTC, Andreas Radke
Details

Description Andreas Radke 2012-05-31 12:23:29 UTC
After update to xkeyboard-config 2.6 keyboard my de-nodeadkeys layout is broken for me in my FreeNX session. Downgrading to 2.5.1 makes it work again. Many charakters like ~, Line End, AltGr don't seem to work anymore. I had not noticed this when running that system directly as a desktop system. My Laptop also has a proper layout running 2.6.

Any idea why xkeyboard-config breaks the FreeNX session layout? I'm unsure if this should be brought up to the NX people too.

Any further information needed?
Comment 1 Sergey V. Udaltsov 2012-05-31 13:50:56 UTC
Please attach the result of xkbcomp :0 -xkb out.xkb for both freenx and desktop session
Comment 2 Andreas Radke 2012-06-03 02:01:11 UTC
How to create the output in a NX session?


[root@workstation64 tmp]# xkbcomp :0 -xkb out_2.6.0_nx.xkb
Error:            Cannot open display ":0"
                  Exiting

Attaching now the local output with 2.5.1 and 2.6.0.
Comment 3 Andreas Radke 2012-06-03 02:03:04 UTC
Created attachment 62435 [details]
local desktop log 2.5.1
Comment 4 Andreas Radke 2012-06-03 02:03:28 UTC
Created attachment 62436 [details]
local desktop log 2.6.0
Comment 5 Sergey V. Udaltsov 2012-06-03 04:58:27 UTC
I do not know about FreeNX. What is in your $DISPLAY environment variable?
Comment 6 Andreas Radke 2012-06-03 05:19:45 UTC
In a NX session it's: DISPLAY=:1000.0
Comment 7 Sergey V. Udaltsov 2012-06-03 10:19:04 UTC
In that case:

xkbcomp :1000 -xkb out.xkb
Comment 8 Andreas Radke 2012-06-03 10:59:21 UTC
Created attachment 62460 [details]
remote NX log 2.5.1
Comment 9 Andreas Radke 2012-06-03 11:00:00 UTC
Created attachment 62461 [details]
remote NX log 2.6.0
Comment 10 Andreas Radke 2012-06-03 11:01:25 UTC
in NX it also shows this:

Warning:          Could not load keyboard geometry for :1001.0
                  BadName (named color or font does not exist)
                  Resulting keymap file will not describe geometry

Is this enough information?
Comment 11 Sergey V. Udaltsov 2012-06-03 14:05:30 UTC
The XKB configuration for 2.6.0 is TOTALLY broken. It means for some reason FreeNX cannot configure XKB, fails and the resulting config is useless. Anything in FreeFX logs? Now, the only thing I can offer is trying to analyse the differences between 2.5.1 and 2.6.0 and trying to find which commit causes the trouble.

But, regardless of issues with xkeyboard-config, there is clearly a bug in FreeNX - it cannot handle properly new xk-c that is correct from "usual" X server POV. Or, at least it should provide some sensible error.
Comment 12 Andreas Radke 2012-06-04 11:42:54 UTC
One difference I found in NX logs is that in T-C-xxx/session file 

I get this additional error msg with xkeyboard-config 2.6.0:

nxagentXkbGetRules: WARNING! Failed to stat file [/usr/lib/NX3/lib/X11/xkb/rules/xorg]: Unknown error -1.

(That file does not exist in our FreeNX package set but didn't harm until 2.5.1.)



2.5.1 shows this msg that 2.6.0 won't show:

The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
>                   Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
Comment 13 Sergey V. Udaltsov 2012-06-04 12:27:33 UTC
Not really useful. That warning message is pretty innocent. So, as I said, the only way is to take 2.5.1, apply commits one by one, till 2.6.0 - and see when it breaks.
Comment 14 Andreas Radke 2012-06-14 10:00:11 UTC
I've found some time and found the commit that breaks my keyboard detection here:

http://cgit.freedesktop.org/xkeyboard-config/commit/?id=77d09b66a99b003171cf4d08fbba16b2c74c6c78

So probably something to much has been removed in this commit. Maybe this is because NoMachine NX is built using an outdated Xorg version.

http://code.x2go.org/gitweb?p=nx-libs.git;a=tree;f=nx-X11;h=5b31c78cbbd3a111ec1d64236eea4e56ba7a83ed;hb=HEAD


I hope that helps now.
Comment 15 Sergey V. Udaltsov 2013-03-14 23:00:53 UTC
> nxagentXkbGetRules: WARNING! Failed to stat file
> [/usr/lib/NX3/lib/X11/xkb/rules/xorg]: Unknown error -1.
Can you ask NX to use the file named "rules/base", not "rules/xorg"? Should be somewhere in config.
Comment 16 Andreas Radke 2013-03-15 17:59:28 UTC
Thanks. This is a first step. I've patched NXagents Keyboard.c (line 143) to use "base" instead of xfree86/xorg rule. Now that error msg is gone.

The output of xkbcomp :1000 -xkb out.xkb is still unchanged with newer xkeyboard-config versions. The layout seems out (z and y keys are on the right keys and I have Umlauts), but arrow keys and Pos1/End and such special keys are still messed up.

Maybe you can have a look at the nxagent file that seems to do the keyboard detection. It's should be based on Xorg-server 6.9:

http://code.x2go.org/gitweb?p=nx-libs.git;a=blob;f=nx-X11/programs/Xserver/hw/nxagent/Keyboard.c;h=e3b58b6c72e03a1143b6294cb5812ebcc40fce4b;hb=HEAD

Any further idea?
Comment 17 Andreas Radke 2013-03-15 18:03:01 UTC
 160 #define NXAGENT_KEYMAP_DIR_FILE "keymap.dir"

That yould be the culprint. New xkeyboard-config versions don't seem to have that file(s) anymore.
Comment 18 Sergey V. Udaltsov 2013-03-15 21:27:43 UTC
Yes, keymaps are gone. Obsolete.
Comment 19 Peter Hutterer 2013-03-27 05:14:40 UTC
The relevant code is here:

http://code.x2go.org/gitweb?p=nx-libs.git;a=blob;f=nx-X11/programs/Xserver/xkb/ddxLoad.c;h=e69d956703de78af77602587cfd77478a39afbfc;hb=HEAD#l189

NX stats this file to verify that a directory is an xkb directory.
Comment 20 Steffen Bollmann 2013-06-05 09:49:29 UTC
Dear all,

Are there already news on this bug? I tried the described fix to create an empty file with

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

but this only fixes 90% of the problems (now a connect from Linux NX clients to freenx-server does not break the delete key anymore). Sometimes (and it seems random to me) the fix does not work. The problem occurs when the NX Client for Windows 3.5.0.9 connects to the freenx server freenx-server-0.7.3-30 then the Tab key is not working as a tab completion but it switches the windows. Only pressing CTRL-Tab then produces the normal Tab key behavior. A few reconnects then solve the problem.

I would be very happy for any hint on this :)

Thank you and all the best
Steffen
Comment 21 Sergey V. Udaltsov 2013-06-05 20:11:45 UTC
What is displayed by xev utility when you are pressing Tab? Ctrl-Tab?
Comment 22 Steffen Bollmann 2013-06-06 13:27:46 UTC
(In reply to comment #21)
> What is displayed by xev utility when you are pressing Tab? Ctrl-Tab?

In the cases where it works:
Tab:
KeyPress event, serial 32, synthetic NO, window 0x1e00001,
    root 0x57, subw 0x0, time 451838053, (58,-9), root:(884,383),
    state 0x10, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) "	"
    XmbLookupString gives 1 bytes: (09) "	"
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x1e00001,
    root 0x57, subw 0x0, time 451838366, (58,-9), root:(884,383),
    state 0x10, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) "	"
    XFilterEvent returns: False

CTR-Tab:
KeyPress event, serial 32, synthetic NO, window 0x1e00001,
    root 0x57, subw 0x1e00002, time 451892661, (67,52), root:(893,444),
    state 0x14, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) "	"
    XmbLookupString gives 1 bytes: (09) "	"
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x1e00001,
    root 0x57, subw 0x1e00002, time 451892786, (67,52), root:(893,444),
    state 0x14, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) "	"
    XFilterEvent returns: False


In the cases where it does not work:
Tab:
FocusOut event, serial 32, synthetic NO, window 0x2400001,
    mode NotifyGrab, detail NotifyAncestor

FocusOut event, serial 32, synthetic NO, window 0x2400001,
    mode NotifyUngrab, detail NotifyPointer

FocusIn event, serial 32, synthetic NO, window 0x2400001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 32, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

CTRL-Tab:
KeyPress event, serial 32, synthetic NO, window 0x2400001,
    root 0x57, subw 0x0, time 452167084, (61,126), root:(897,394),
    state 0x14, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) "	"
    XmbLookupString gives 1 bytes: (09) "	"
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x2400001,
    root 0x57, subw 0x0, time 452167209, (61,126), root:(897,394),
    state 0x14, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) "	"
    XFilterEvent returns: False


I'm clueless - Isn't that strange?
Thank you and all the best
Steffen
Comment 23 James Cloos 2013-06-06 14:36:23 UTC
The focus out indicates that something is grabbing the event.

When one configures one's window manager to perform certain tasks
on certain key events, xev(1) typically will show that output.

For instance, when I configure my wm thus:

  key "XF86AudioMicMute" amixer -c 2 sset Mic toggle

then hitting the micmute key when running xev generates:

FocusOut event, serial 38, synthetic NO, window 0x2e00001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 38, synthetic NO, window 0x2e00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 38, synthetic NO, window 0x0,
    keys:  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
Comment 24 Steffen Bollmann 2013-06-06 21:10:13 UTC
(In reply to comment #23)
> The focus out indicates that something is grabbing the event.
> 

That is very interesting. I had the feeling that this behavior correlates with playing with the "Grab the keyboard when the client has focus" checkbox
in the NX Client GUI -> Advanced tab.(Interestingly pressing Ctrl + Alt + K which enables or disables "Grab the keyboard when the client has focus" does not fix it.)

Sometimes it helps to log out, take out this option / or set this option and then after a reconnect the tab key works.

Any idea how I could reset this in case it went wrong by a setxkbmap command? I already tried dumping a working keyboard map from $DISPLAY and than when it is broken importing the working one, but this does not fix it either.
xkbcomp $DISPLAY workingKeyboard.dump
xkbcomp workingKeyboard.dump $DISPLAY

Thank you for the input
All the best
Steffen
Comment 25 Peter Hutterer 2013-07-04 06:54:36 UTC
I strongly suggest to git-bisect if you think this really is xkeyboard-config that breaks it. It will be faster than trying work around and pin-point the culprit quickly enough so we can either fix it or figure out a workaround based on what breaks.
Comment 26 GitLab Migration User 2018-12-28 00:35:21 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/32.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.