GNOME Bugzilla – Bug 150542
Keyboard lost in VNC session after launching keyboard capplet
Last modified: 2010-10-14 08:38:53 UTC
As soon as gnome-session is started in a vnc-session the keyboard stops working. 1. Start a VNC-session with a xterm window. Keyboard works. 2. Start gnome-keyboard-properties. Keyboard stops working in all applications. When I press a key the cursor in xterm flashes as it usually does when the xterm is frozen (ctrl-q). The vnc-server is a gentoo computer. I have tested the client in both Fedora and Windows with same result.
which gnome-keyboard-properties do you start, the version of the vnc window ?
Does vnc server support XKB? Could you please try xdpyinfo -ext all | grep KEYBO?
no reply, bug closed. Feel free to reopen with the asked details if you still get the issue.
Hello, I'm sorry to necromance this bug but I get this issue as well. I'm running tightvnc 1.3.9-3 as my vnc server, with a simple session involving Openbox (and not gnome or gnome-session). If I run gnome-settings-daemon after I connect to the VNC server, my keyboard gets all whacked out and I can't type.. keys type the wrong letter, the enter button doesn't work anymore. From what I've gathered, the VNC server does NOT support XKB. I get this when running the above asked command: (trimmed many Xlib: Missing extension "bla") XKEYBOARD extension not supported by server I get some errors on stdout from gnome-settings-daemon: xmodmap: unable to open file '/home/daf/.Xmodmap' for reading xmodmap: 1 error encountered, aborting. ** (gnome-settings-daemon:25259): WARNING **: numlock: XkbQueryExtension returned an error ** (gnome-settings-daemon:25259): WARNING **: Neither XKeyboard not Xfree86's keyboard extensions are available, no way to support keyboard autorepeat rate settings xmodmap: unable to open file '/home/daf/.Xmodmap' for reading xmodmap: 1 error encountered, aborting. ** (gnome-settings-daemon:25259): WARNING **: Module GnomeSettingsModuleAccessibilityKeyboard could not be started ** (gnome-settings-daemon:25259): WARNING **: Module GnomeSettingsModuleScreensaver could not be started xrdb: "*Label.background" on line 220 overrides entry on line 150 xrdb: "*Text.background" on line 226 overrides entry on line 191 xrdb: "*Label.foreground" on line 232 overrides entry on line 151 xrdb: "*Text.foreground" on line 238 overrides entry on line 192 Most are noise but the keyboard problem is noticed here again. Is there something that g-s-d is doing that would muck up a session without xkeyboard extensions? I'd like to be able to run g-s-d in vnc, even if it can't set autorepeat or anything else.
Subtle hint: You stand a much better chance of getting replies if you don't leave the bug closed ;-) Sergey?
Yes, it seems vnc does not provide XKB. Next question - do you see anything suspicious when you press keys in xev?
xev appears to give the same key results as if i am typing in any application. Keys are completely skewed as to their meaning, for example: key => results in --- ---------- a => a s => b d => f f => h g => j h => k j => ; An actual output line looks like this (pressing the j key): KeyPress event, serial 33, synthetic NO, window 0x2000001, root 0x25, subw 0x0, time 710596437, (-44,-219), root:(646,68), state 0x0, keycode 47 (keysym 0x3b, semicolon), same_screen YES, XLookupString gives 1 bytes: (3b) ";" XFitlerEvent returns: False does this help?
Well, it helps - it explains the issue. But it does not explain why your j key has keycode 47 (rightfully translated to semicolon). As a workaround, you could hack xmodmap file, straightening broken mappings. Otherwise you should move that bug to xorg keyboard driver... What would you prefer?
Just to make sure I was clear before, this odd keymapping only occurs when gnome-settings-daemon is run. It works perfectly normal before I run g-s-d from a terminal, then it becomes unusable. Could it indicate something is off in my g-s-d (or gconf?) settings? I normally run g-s-d in a desktop session when I am at home (not using vnc), so it draws from the same config, which works normally.
Is it perceivable that calling xkb functions if xkb isn't available has such effects? I'm pretty sure g-s-d does that. Dave, in case you're running 2.22, could you please check which plugin causes the problem? You can disable plugins using gconf-editor (/apps/gnome_settings_daemon/plugins/*).
Jens, I just upgraded to 2.22 to try what you suggested, the first plugin I turned off was "Keyboard" and that seemed to fix the problem. I can run g-s-d without it messing up my keyboard. The update from 2.20 to 2.22 had the same behavior prior to turning the keyboard plugin off. I guess this narrows it down slightly? A few more things of note: - If i toggle the keyboard plugin from inactive to active, my keyboard is messed up again, no matter if i turn it back off or not. - If i close gconf-editor after toggling it a few times, g-s-d crashes with this: The program 'gnome-settings-daemon' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 2258 error_code 3 request_code 20 minor_code 0) Not that I plan on actually toggling it a lot, but something with this setting is causing problems.
Created attachment 109008 [details] [review] don't use xkb if not available Can I make you switch to 2.23 (ie. svn trunk)? This patch makes sure that we won't try to use XKB functionality when it's not available, and what I suspect is the problem. It won't help (or even apply) to 2.20, though, and creating a similar patch for 2.20 is a bit more work. In case the patch doesn't help, either, try to comment out the two calls to gsd_keyboard_xkb_* in gsd_keyboard_manager_start. Maybe we can blame it on somebody else, at least. ;-) Enabling/disabling plugins while running is pretty much broken atm, so problems are to be expected when doing that. Not necessarily related to this bug.
I checked out g-s-d from svn (currently rev 292) and tried that, however it crashes. I compiled with -g3 -ggdb but I cannot seem to debug the crash, everything looks fine to me. Here is the backtrace: gdb) bt
+ Trace 194963
Going up to frame 2 there, line 72 is: file = g_build_filename (g_get_home_dir (), (gchar *) tmp->data); and at run time, the parameters to the call are: "/home/daf" and ".Xmodmap" seems fine to me? the tmp->data is not null terminated? although I figured I'd see a lot of garbage in there. It is not so simple for me to rebuild glib with debug symbols, so hopefully this is enough for you.
Should be fixed now. Feel free to drop by in #control-center on irc.gimp.net if you like. That makes insta-communication a bit less cumbersome.
(note to bug readers: the problem still exists, we're working on it in the irc channel) I finally got a chance to try to debug where the keyboard switchover occurs. It definitely happens as teh result of some callback or whatever inside of the gtk_main call, as everything is fine up until that point. I fond some debug code that could be enabled with CFLAGS containing "-DGSDKX" which makes the keyboard plugin spit out some debug log in /tmp. This clued me in to a bunch of MappingNotify events it seemed to be picking up, which made me think, hmm, maybe xmodmap is being called and picking something up. So I strace'd g-s-d and found that indeed it is opening the file /usr/share/xmodmap/xmodmap.us at run time, which I think may be what is causing this mess. I can't make heads or tails of the log output though, so I will attach a tarball of both the gsdkx log and the strace log. If someone can find out what is actually calling xmodmap with that keymap file as an argument, we may have an answer.
Created attachment 109277 [details] gsd debug tracing (gsdkx and strace logs)
gsdkx file looks reasonable. As expected, it initializes xmodmap backend and goes with it...
Yeah, the big thing going on is in the strace where it decides it needs to load my xmodmap.us. I've tried to debug this today with several angles, and I can't seem to get a way to figure out what exactly is doing it. I thought it was related to an xrdb call but it seems it is past that. I tried some tricks like replacing xrdb with a shell script which sent a signal to g-s-d while being debugged but since the xmodmap call didn't occur then, it didn't help finding it. If it was possible to break in gdb when a file was accessed then we'd be in business, but I can't see any way to do that. Maybe replace xmodmap.us with a pipe attached to a program and have that break, thus breaking my already gdb'd gsd? I don't know, this bug is making me insane. I don't know how much help I can be on it without any idea of how to get the call stack from where the problem is. I might just turn off the keyboard plugin when I use vnc so I can actually use g-s-d with vnc. If anyone has any ideas, respond here or ping me on irc, i'll linger around. cheers.
xmodmap.us is loaded by g-s-d, keyboard plugin (using libxklavier). May be, it requires some tweaking? The xmodmap config files in gnome-applets are practically unmaintained - since most of users work with xkb.
Ok, so, to document this: We (that is, Dave) removed all direct callouts to xmodmap from the keyboard plugin, but we still saw a final xmodmap call from somewhere. Presumably that's internal to libgnomekbd or libxklavier? What do gnome-applets files have to do with anything, and if they do why does g-s-d try to load random keymaps?
Yes, libxklavier is calling xmodmap (in case xkb is not available). That depends on the configuration in gconf. If the layout is 'us', xmodmap.us is used. If it is broken - we have to fix it (it is gnome-applets component actually - for historical reasons).
Actually, IIRC xmodmap files are bound to the particular keyboard driver keycodes. And for example for evdev they might be broken. The whole xmodmap is one broken piece of architecture...
*** Bug 569567 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > Created an attachment (id=109008) [edit] > don't use xkb if not available Above patch didn't help me. When g-s-d starts and keyboard plugin is enabled (default behavior) it's changing the keyboard layout. What is current status of this bug? Last comments are pretty old.
First, probably xmodmap.us could be cleared (make it zero size). What would be the change in behavior? There is no such thing as "xmodmap API". It is a core X11 API which is quite bad in kbd department. So I cannot really tell (without stacktrace) which part of libxklavier is faulty. It might be interesting to build libxklavier without xmodmap support, using --enable-xmodmap-support=no option for the configure (this is risky though, I've never tried the library without xmodmodmap support when XKB is not available). Alternatively, there are testing apps in libxklavier. May be, running clean X, then "test_config -s -m us -d 200" and then "test_monitor -l1 -l2 -d 200" would show something... Could it be some issue with vnc X11 server actually?
I completely removed the "xmodmap" code from g-s-d. On older versions you can disable it by enabling the following GConf key: /desktop/gnome/peripherals/keyboard/disable_xmm_and_xkb_warning If there's still a bug in libxklavier, the discussion about fixing it should happen on libxklavier's bug management tool, not in gnome-settings-daemon's.