Created attachment 20388 [details] XKB configuration just after plugging kbd out (still good) I have valid XKB configuration of my USB keyboard. The keyboard is plugged into monitor which also works as USB hub. When I turn monitor off/on, the keyboard is effectively looking as plugged out/in. And as a result, XKB configuration is messed. I checked - when the keyboard just plugged out, the config is still ok. Shit happens when the keyboard is back. Actually, xkbcomp cannot even get geometry from X. See 2 xkb files (attached): before and after plugging in.
Created attachment 20389 [details] XKB configuration after plugging kbd in (broken!) Look at the symbols mapping. The 'ru' part is lost. The geometry is missing altogether. xkbcomp gives the error: Warning: Could not load keyboard geometry for :0 BadAlloc (insufficient resources for operation) Resulting keymap file will not describe geometry
I'd need your xorg.log to be sure but my guess is that you selected your xkb configuration in your desktop environment. This applies to all connected keyboards, but if you then add a new keyboard it gets added with the defaults (specified in the HAL fdi file, "us" by default). This causes the "ru" part to be 'lost'. The solution is either to specify your xkb config in the HAL fdi, or to fix the desktop environment to re-set the xkb configuration on a device presence event.
Sure my XKB config is setup by DE. My questions are: why plugging keyboard back leads to some strange/broken configuration (without geometry!) Also, my second question - why is hal used instead of keeping the current configuration (available from _XKB_RULES_NAMES)? Sorry I did not make my questions clear with the initial description.
On Tue, Nov 18, 2008 at 11:59:50AM -0800, bugzilla-daemon@freedesktop.org wrote: > --- Comment #3 from Sergey V. Udaltsov <svu@gnome.org> 2008-11-18 11:59:49 PST --- > Sure my XKB config is setup by DE. > My questions are: why plugging keyboard back leads to some strange/broken > configuration (without geometry!) That'd be a good one to track down actually. I never bothered to because it didn't really affect me, but I guess finding that bug may fix other (potential) bugs. > Also, my second question - why is hal used instead of keeping the current > configuration (available from _XKB_RULES_NAMES)? The server doesn't actually know the _XKB_RULES_NAMES values*. It just sets the property up once and then leaves it be. The prop is also not safe in the multi-keyboard environment, forcing the same layout onto all keyboards. HAL otoh allows you to configure a specific device with a specific layout. * well, of course it does, being the server and everything, but you get the drift.
In addition, the state of the keyboard is strange after re-inserting. Even if I reload the configuration (xkbcomp), some things do not work. For example, Shift+Lower/UpperVolume is ignored (produces no events).
I guess I know what could trigger that. I had "kbd" driver in xorg.conf. Which caused Xorg to use it at initial startup (looking at Xorg.log). When the keyboard got plugged out/in, the driver (according to the log) switched to evdev. Could that mess XKB config?
(In reply to comment #6) > I guess I know what could trigger that. I had "kbd" driver in xorg.conf. Which > caused Xorg to use it at initial startup (looking at Xorg.log). When the > keyboard got plugged out/in, the driver (according to the log) switched to > evdev. Could that mess XKB config? > no, kbd is basically ignored in server 1.5, but there's a weird race condition you can trigger (depends on your distro, we have patches to avoid that in fedora and I think most other distros have it too). the server starts with the base ruleset, inits the keyboard. if you run xkbcomp before hitting a key you ge the xkbmap with the xfree86 keycodes. if you then re-run it on the devices, you set the wrong keycodes for all evdev devices.
> no, kbd is basically ignored in server 1.5, Interesting. How could I see it in Xorg.log?... > the server starts with the base ruleset, inits the keyboard. if you run xkbcomp > before hitting a key you ge the xkbmap with the xfree86 keycodes. if you then > re-run it on the devices, you set the wrong keycodes for all evdev devices. Well, I usually does not press the key immediately after X startup...
> --- Comment #8 from Sergey V. Udaltsov <svu@gnome.org> 2008-12-15 10:50:55 PST --- > > no, kbd is basically ignored in server 1.5, > Interesting. How could I see it in Xorg.log?... 1.5.3 should actually tell you. Before that, behaviour is a bit different, requiring evdev to grab the devices. So kbd is still there, but doesn't generate any events. > > the server starts with the base ruleset, inits the keyboard. if you run xkbcomp > > before hitting a key you ge the xkbmap with the xfree86 keycodes. if you then > > re-run it on the devices, you set the wrong keycodes for all evdev devices. > Well, I usually does not press the key immediately after X startup... do you log in though? or do you have autologin in gdm?
> 1.5.3 should actually tell you. Before that, behaviour is a bit different, > requiring evdev to grab the devices. So kbd is still there, but doesn't > generate any events. Well, I actually asked how happened that in my xorg I could see kbd driver to be loaded... > do you log in though? or do you have autologin in gdm? I do manual login in gdm.
> --- Comment #10 from Sergey V. Udaltsov <svu@gnome.org> 2008-12-15 17:14:12 PST --- > > 1.5.3 should actually tell you. Before that, behaviour is a bit different, > > requiring evdev to grab the devices. So kbd is still there, but doesn't > > generate any events. > Well, I actually asked how happened that in my xorg I could see kbd driver to > be loaded... 1.5.2 still loads the driver but the device is "mute" (doesn't send events). 1.5.3 actually ignores it completely. > > do you log in though? or do you have autologin in gdm? > I do manual login in gdm. when/how did you get your xkbcomp output? through ssh? a script? or manually on the terminal?
> when/how did you get your xkbcomp output? through ssh? a script? or manually > on the terminal? In gnome-terminal
I start X with startx (because of frequent X breakage I don't use gdm). I set my keyboard configuration with setxkbmap in my .Xsession. When I start X everything works but when I unplug and re-plug a keyboard xkb stops working. The keyboard has US keymap and I cannot load any keymap with xkb anymore.
indeed, omitting the setxkbmap script from my .Xsession fixes the problem.
sergey, can we close this bug or is it still broken with 1.7?
I think it is closed in 1.7. Can be reopen, if it happens again
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.