Bug#241014: XKB problems after upgrade to 4.3.0
This bug does not exist any longer. The problem was probably due to some
program in gnome-2.6, I'm upgrading from experimental. Maybe it was the
keyboard applet. Unfortunately I don't recall which update solved the
xkb issue. Moreover, since the problem does not exist any longer, I
cannot find out which program is causing it. You can close this bug.
It does not seem to be due to the xserver-xfree86 (4.3.0-7) package.
Thanks for your effort. The only problem remaining now is that the
splash screen after start-up stays a very long time before disappearing
(Is this handled by gnome-session->x-session-manager?)
On Wed, 2004-04-21 at 04:31, Branden Robinson wrote:
> tag 241014 + moreinfo
> thanks
>
> On Wed, Mar 31, 2004 at 08:58:59AM +0200, Svante Signell wrote:
> > On Tue, 2004-03-30 at 22:49, Denis Barbier wrote:
> > > On Tue, Mar 30, 2004 at 12:33:37PM +0200, Svante Signell wrote:
> > > > Package: xserver-xfree86
> > > > Version: 4.3.0-7
> > > > Severity: important
> > > >
> > > Can you please deactivate any session manager, run startx when logged
> > > as root on console and see if this error message is still there?
> > >
> > > Denis
> >
> > I started a clean (no .xsession, .xinirc etc) X server as root with
> > startx. I still did get a gnome session (how?). However, no XKB error
> > occurred.
>
> Looks like some X client may be changing your keyboard config after the
> X server starts. From the Debian X FAQ[1]:
>
> *) Why doesn't my "< >" key work?
>
> [Thanks to Guillem Jover and Ingo Saitz for their assistance researching this
> entry.]
>
> In XFree86 4.3.0, the stock configuration data for the X Keyboard Extension
> (XKB) was overhauled. One of the few downsides to this much-needed update was
> that the "< >" key commonly found on European keyboards stopped functioning.
> Users of 102- or 105-key PC keyboards (as well as miniature and laptop
> keyboards compatible with these models) should ensure that their keyboard is
> configured accordingly in the XF86Config-4 file, using the "pc102" or "pc105"
> XkbModel instead of "pc101" or "pc104", respectively. U.S.-style PC keyboards
> do not have a "< >" key, it is this additional key that distinguishes a pc102
> keyboard from a pc101 keyboard, and a pc105 keyboard from a pc104 keyboard.
>
> If your keyboard has a "< >" key, you probably have a 102- or 105-key model.
> The "< >" key may not work if you do not configure your keyboard model
> correctly. You can use "dpkg-reconfigure xserver-xfree86" to change this
> configuration parameter, or edit /etc/X11/XF86Config-4 directly.
>
> If you have done this, or have already confirmed that your XkbModel is set to
> "pc102" or "pc105" in the XF86Config-4 file, but your "< >" key *still*
> doesn't work in X, then an X client is probably reconfiguring your keyboard
> after the server starts.
>
> To confirm this, start the X server in a way that bypasses all client-side
> initialization, and use the xev program from the xbase-clients package to
> determine whether your "< >" key works when the X server initially starts.
>
> Here's one way to do it from a virtual console:
>
> $ xinit /usr/bin/X11/xev -- :1 vt8 > /tmp/xev.out
>
> This starts the X server using server number 1 (in case you already have a
> session active on :0), on virtual console 8, and runs the xev client,
> redirecting xev's output to a temporary file.
>
> Move the mouse cursor into the white window, then press and release the "< >"
> key. (There will be no visible response to your keystrokes.) Then kill the X
> server, either by using CTRL-ALT-BACKSPACE or by switching back to the virtual
> console from which you ran xinit, and typing CTRL-C.
>
> Next, use your favorite pager program to view xev's output:
>
> $ pager /tmp/xev.out
>
> Near the end (after a whole lot of mouse events), you will see something like
> this:
>
> KeyRelease event, serial 28, synthetic NO, window 0x1a00001,
> root 0x58, subw 0x0, time 19431502, (57,266), root:(553,290),
> state 0x0, keycode 94 (keysym 0x3c, less), same_screen YES,
> XLookupString gives 1 bytes: "<"
>
> Note particularly the "keycode" and "keysym" information.
>
> If, instead, you see something like this:
>
> KeyRelease event, serial 28, synthetic NO, window 0x1e00001,
> root 0x58, subw 0x0, time 20019010, (425,-87), root:(429,281),
> state 0x0, keycode 94 (keysym 0x0, NoSymbol), same_screen YES,
> XLookupString gives 0 bytes: ""
>
> Then the X server is not starting with the correct keymap for your locale, and
> you need to check your XF86Config-4 file again. You may have a subtle
> problem, such as multiple keyboard input devices defined in the file (and the
> wrong one is being used), or the XF86Config-4 file may have been disregarded
> in favor of a different configuration file. See the XF86Config-4(5x) manual
> page for more information on these types of problems.
>
> Also note that the XFree86 X server log file (such as /var/log/XFree86.0.log)
> will not only tell you the name of the configuration file that was used, but
> also what the X server thinks the keyboard configuration is.
>
> If the X server can see your "< >" key when it starts this way, but not
> normally, then you *do* have a problem with an X client changing it after the
> X server starts. Several X clients can do this, including:
> * xmodmap
> * setxkbmap
> * the KDE Control Center
> * the GNOME Control Center
>
> The xmodmap client is deprecated for keyboard manipulation, but some people
> still use it. The best way to see if it is running is to check the system's X
> session scripts as well as your own. E.g.:
>
> $ grep -irs xmodmap /etc/X11/xkb $HOME/.xsession
>
> The setxbdmap client is pretty straightforward, and can be searched for the
> same way. Make sure it is not being invoked with the "-model pc101" "-model
> pc104" arguments, for example. See setxkbmap(1x) for more information.
>
> In KDE 3.2, the relevant Control Center menu is Regional & Accessibility ->
> Keyboard Layout.
>
> In GNOME 2.4, right-click the GNOME keyboard applet and select "Settings...".
>
> > Seems to be an access rights problem.
>
> I don't think so.
>
> > The only non-normal output at the tty was:
> >
> > X:warning; process set to priority -11 instead of requested priority -10
>
> That's interesting. That comes from the following code in our X server
> wrapper:
>
> #if NICE_USES_SUSV2_SEMANTICS
> errno = 0;
> intval = nice(niceval);
> if (errno) perror("X: warning; nice() of process failed");
> if (intval != niceval) (void) fprintf(stderr, "X: warning; process set to "
> "priority %d instead of requested priority %d\n", intval, niceval);
> #else
>
> I wonder what would cause this, though I am very confident it has
> nothing to do with your keyboard problem.
>
> > AUDIT: Wed Mar 31 08:13:10 2004: 1111 X: client 5 rejected from local
> > host
>
> Perhaps that is the GNOME keyboard applet trying to screw up your
> keyboard.
>
> > Further information at the tty when running as non-root:
> > The XKEYBOARD keymap compiler (xkbcomp) reports:
> > > Error: bad length in Symbols
> > > Output file "/var/tmp/server-0.xkm" removed
> > Errors from xkbcomp are not fatal to the X server
>
> This may be a bug in the GNOME keyboard applet (assuming my guess is
> right). Can you try to find out how it is trying to reconfigure your
> keyboard?
>
> [1] /usr/share/doc/xfree86-common/FAQ.gz
Reply to: