"Error activating XKB configuration" popup

[Clint Adams]

After an apt-get upgrade today, I get the following message in a pop-up window.

Error activating XKB configuration.
Probably internal X server problem.

X server version data:
The XFree86 Project, Inc
40300001
You are using XFree 4.3.0.
There are known problems with complex XKB configurations.
Try using simpler configuration or taking more fresh version of XFree software.
If you report this situation as a bug, please include:
- The result of xprop -root | grep XKB
- The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb

And here are the respective outputs:

% xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "macintosh", "us", "", ""
_XKB_RULES_NAMES(STRING) = "xfree86", "macintosh", "us", "", ""
% gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb
 layouts = [us]
 model = macintosh
 overrideSettings = false
 options = []
 update_handlers = []

[Daniel Stone (daniels)]

Fixed in xfree86_4.3.0.dfsg.1-6ubuntu15.

[Andrew Bennetts (spiv)]

I have current everything (including version 4.3.0.dfsg.1-6ubuntu15 of the X
stuff), and I'm seeing this.

I created a new user to find out what the new default desktop settings are like,
and ran System Tools -> New Login to try it out. Upon logging in with the new
user, I got 11 windows with the "Error activating XKB configuration" message.

The debug details it asks for:

test@trogdor ~ $ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc104", "us", "hpi6", ""
_XKB_RULES_NAMES(STRING) = "xfree86", "pc104", "us", "hpi6", ""
test@trogdor ~ $ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb
 layouts = [us hpi6]
 model = pc104
 overrideSettings = false
 options = []
 update_handlers = []
test@trogdor ~ $

Logging in a second time to that user, I only get one error message, rather than
eleven. With a new user, I again get eleven copies of the error first time I login.

Logging in to that user via "New Login" *twice*, the second new login doesn't
get the error -- but then, it gets a different (partly broken) theme too,
something odd is happening there.

I can also reproduce this without "New Login", i.e. by logging out of all X
sessions and logging in as one of these test users to the normal gdm prompt.

The debug output for my usual user, that doesn't see the error, is a little
different:

andrew@trogdor ~ $ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc104", "us", "hpi6", ""
_XKB_RULES_NAMES(STRING) = "xfree86", "pc104", "us", "", ""
andrew@trogdor ~ $ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb
 layouts = [us]
 model = pc104
 overrideSettings = false
 options = []
 update_handlers = []
andrew@trogdor ~ $

This is on an i386 laptop, so I'm setting Hardware to "All".

[Matt Zimmerman (mdz)]

This only ever happened on powerpc, due to a broken symlink, and fixing that
solved the problem for me, so this sounds like a different bug.

This only happens when this new user logs in, and not the initial user?

[Daniel Stone (daniels)]

Where did hpi6 come from; did you do that yourself? I don't think that our
configuration is selecting some form of map I've never heard of. ;) Could you
please attach XFree86.0.log from the failure, also (from -6ubuntu14 or later is
preferred)?

[Daniel Stone (daniels)]

The symlink bombing thing was due to having a stray symlink, at which point XKB
couldn't generate a complete map for Mac; it tried to collect one of the
elements, and instead of failing gracefully, it tanked.

To me, this looks like it couldn't find this 'hpi6' variant, which is a HP
Internet Keyboard; looks like a custom type to me.

[Matt Zimmerman (mdz)]

I wonder where GNOME gets the default map from, if it has one...

[Daniel Stone (daniels)]

You can't detect keyboards; I'm thinking hpi6 is a custom modification. Of
course, having the log would be great, because it actually tells us what's
failing in these brave new -DNOISY days.

[Andrew Bennetts (spiv)]

Created an attachment (id=45)
output of running "startx -- :1 > /tmp/xlog2 2>&1" as an affected user

[Andrew Bennetts (spiv)]

Created an attachment (id=46)
My normal XFree86.0.log (as an unaffected user)

[Daniel Stone (daniels)]

How about if you change 'hpi6' to 'inet(hpi6)'?

[Andrew Bennetts (spiv)]

Created an attachment (id=47)
XFree86.1.log created by the startx cmd mentioned in earlier attachment.

Also, note that I'm pretty sure that I didn't set the XkbVariant to "hpi6" --
in fact, I remember being pleasantly surprised when I discovered that it had
done so automatically for me. The only change I've made to my auto-generated
XF86Config-4 was that I recently (about a week ago) added "DisplaySize 285
213" to it.

mdz: I wasn't sure if this was a new bug or not, so I made a guess. Sorry if I
guessed incorrectly :(

[Andrew Bennetts (spiv)]

(In reply to comment #10)
> How about if you change 'hpi6' to 'inet(hpi6)'?

I now get two errors when I log in as the test user, and a question from GNOME
asking:
    The X system keyboard settings differ from your current GNOME keyboard
    settings. Which set would you like to use?
           [Use X Settings] [Use GNOME settings]

I tried "Use X Settings", and got a bunch more of the error dialogs (about six
or so).

The debugging commands it suggests now report the same as before, except
s/hpi6/inet(hpi6)/ :)

Btw (I should've mentioned this earlier), I believe hpi6 is the correct variant
for this keyboard -- my laptop is an HP NC6000.

[Andrew Bennetts (spiv)]

Oh, and I get this xkbcomp error on the console I ran startx from: 'Illegal
include statement "pc/pc(pc104)+pc/us(inet(hpi6))"'

[Daniel Stone (daniels)]

.,.. wicky word. The fact we detected keyboard layouts is news to me since ...
well, I didn't really know we could. Fabio, any idea where this came from?

[Andrew Bennetts (spiv)]

Well, it's entirely possible I did it myself and completely forgot about it...
stranger things have happened. :)

Is there any way I can re-run the autodetection stuff to see what it generates?

[Simon Csaba Endre (secsaba-yahoo)]

Selecting Keyboard Preferences/Layouts/Hungarian and Add I got the following
error:

Error activating XKB configuration.
Probably internal X server problem.

X server version data:
The XFree86 Project, Inc
40300001
You are using XFree 4.3.0.
There are known problems with complex XKB configurations.
Try using simpler configuration or taking more fresh version of XFree
software.
If you report this situation as a bug, please include:
- The result of xprop -root | grep XKB
- The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb

And here are the results:
$ xprop -root| grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc104", "fi", "", ""
_XKB_RULES_NAMES(STRING) = "xfree86", "pc104", "fi", "", "grp:alts_toggle"
$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb
 layouts = [fi,hu]
 model = pc104
 overrideSettings = false
 options = [grp grp:alts_toggle]
 update_handlers = []

Tried many layouts and its seems than only with the "Hungarian" layout is
some problem.

xfree86 4.3.0.dfsg.1-6ubuntu18

[Daniel Stone (daniels)]

I cannot reproduce this at all. What Hungarian layout are you using, specifically?

[Michel (michel)]

I have the same problem on an iMac G3 bondi blue with the original iMac keyboard. Popup errors saying that
there's an error.

[michel@imac michel]$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "macintosh", "us", "", ""
_XKB_RULES_NAMES(STRING) = "xfree86", "macintosh", "us", "", ""
[michel@imac michel]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb
 layouts = [us_intl]
 model = macintosh
 overrideSettings = false
 options = [grp grp:alts_toggle]
 update_handlers = []

[Denis Barbier (barbier)]

I do not have Mac hardware, and so never played with XKB configuration in this area.
Anyway here are some hints to help debugging:
 * XFree86.0.log contains messages displayed when X is launched; when XKB configuration is changed in GNOME, messages are writtent into GDM log file, so providing these error messages is very helpful.
 * setxkbmap has a -print option which displays what will be passed to xkbcomp. When patching XKB files, running
   setxkbmap [options] -print | xkbcomp -w0 -I/etc/X11/xkb - :0
is handy, or the output of setxkbmap is stored into a file which is edited and passed to xkbcomp.
And here is an example with macintosh layout: compare
  setxkbmap -model macintosh -layout us -print
and
  setxkbmap -model macintosh -layout us,gb -print
It seems very buggy to me, so I would not be surprised if macintosh could not handle multiple layouts. And GNOME keyboard switcher should only display symbol files which are relevant to the model, in this case files under /etc/X11/xkb/symbols/macintosh/.

About the Hungarian layout, I sent a file to http://bugs.debian.org/269929 and am interested in knowing if it works fine.

[Daniel Stone (daniels)]

To summarise:
  * Most Mac stuff -- OK.
  * pc104/hu -- apparently buggy, but unreproducible.
  * macintosh/us_intl -- apparently buggy.

I'd be interested in seeing all the XFree86.0.logs, given we're now stupidly
verbose about XKB in them.

[Denis Barbier (barbier)]

Disclaimer: I neither run Ubuntu nor GNOME, and have no Mac hardware, so I can only make guesses, but here are comments based on my knowledge of XKB in Debian, feel free to correct me if they do not apply here.

> * Most Mac stuff -- OK.
No, it should be fine for Mac using PC models, but those needing macintosh model can only load one (and only one!) of the few layouts found in symbols/macintosh/ whereas it seems that GNOME applet displays the full list.

> * pc104/hu -- apparently buggy, but unreproducible.
It is reproducible, try
  setxkbmap -model pc104 -layout fi,hu

> * macintosh/us_intl -- apparently buggy.
Does not exist, see first item.

> I'd be interested in seeing all the XFree86.0.logs
As said in comment #19 (but I may be mistaken), XFree86 log file only contains information about X startup, other useful messages triggered by user settings are stored in gdm log file.
PS: feel free to Cc me for faster replies ;)

[Michel (michel)]

I've copied the us_intl file from /etc/X11/xkb/symbols to the macintosh directory, and now it seems to work
fine. It didn't work when I tried a generic PC 101/104/105 key layout, same error.
From the gdm log:

The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Can't find file "pc/us_intl" for symbols include
> Exiting
> Abandoning symbols file "default"
Errors from xkbcomp are not fatal to the X server
Error loading keymap /usr/X11R6/lib/X11/xkb/compiled/server-0.xkm

That's with trying the PC layout on my mac.

[Matt Zimmerman (mdz)]

*** Bug 8681 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

Bug #8681 points out a similar problem with additional layouts on i386. us and
dvorak at least work fine for me. I can easily reproduce the problem by adding
the "Canadian->Eliminate dead keys" layout, though.

[Daniel Stone (daniels)]

Fabio, do you think Denis's us_intl fix made to Debian's SVN HEAD would solve
this issue? If so, we should probably drag it across.

[Fabio Massimo Di Nitto (fabbione)]

I am taking it for the next X upload. I can't be sure if it will fix this problem.

[Fabio Massimo Di Nitto (fabbione)]

This problem should be fixed with Xfre86 -6ubuntu23 upload. The packages will be
available on the mirrors in a few hours.

Fabio

[Jean-Francois Im (jeanfrancois-im)]

Still occurs for me on 4.3.0.dfsg.1-6ubuntu23. It doesn't do it for all
keyboard layouts, as most are functional. A couple that cause the error are
French Canadian, Japanese, Vietnamian, Hungarian, etc...

After doing two runs of X, one with the broken layout and one without, I get
this.

mjihad@hotaru:~ $ diff test-xbug-xoutput test-xbug-xoutput2 | tail -n 6
< The XKEYBOARD keymap compiler (xkbcomp) reports:
< > Error: Can't find file "pc/ca_enhanced" for symbols include
< > Exiting
< > Abandoning symbols file "default"
< Errors from xkbcomp are not fatal to the X server
< Error loading keymap /var/tmp/server-0.xkm
mjihad@hotaru:~ $ locate ca_enhanced
/etc/X11/xkb/symbols/ca_enhanced

Symlinking /etc/X11/xkb/symbols/pc/ca_enhanced to
/etc/X11/xkb/symbols/ca_enhanced fixes the problem. I assume that the other
broken layouts are also due to missing symlinks to their symbol file.

[Fabio Massimo Di Nitto (fabbione)]

Hi Denis,
        sorry i am taking the freedom to readd you again to this bug.

I did an upload of X that includes all the fixes you did in SVN up to 1912,
but apparently there are more that needs to be done in the same way.

If you know a relatively simple way to fix it, i will be glad to send out
test packages within a few hours.

Thanks
Fabio

[Denis Barbier (barbier)]

I will try to provide better explanations. There are two distinct problems, whether on macintosh models or not.
Layouts for macintosh models (ie with XkbModel "macintosh" or "macintosh_old") are available under /etc/X11/xkb/symbols/macintosh/. As you can see, there are very few of them. GNOME keyboard switcher should only display layouts found in this directory when model is set to macintosh or macintosh_old. Some people add links from symbols/pc/ to be able to load other layouts. This may work for them, but basically this is unsupported. If other layouts are needed, it should be reported upstream.
About layouts like hu or ca_enhanced which cannot be combined with other layouts on PC keyboards, this is not a bug but a feature ;) The $oldlayouts variable in /etc/X11/xkb/rules/xfree86 lists layouts only available in the so-called "old format". They cannot be combined with others, period. Some layouts in the new format are available from XFree86 or freedesktop (in the latter case include paths must be fixed), or they can also be converted manually. For instance, de_CH can be replaced by pc/ch(de), or sometimes the name is unchanged, as for ca or hu. For Debian, I would like to provide as many new layouts as possible, and keep old ones (there are sometimes minor differences, users may prefer the latter). This is not hard, but time consuming because /etc/X11/xkb/rules/xfree86{,.lst,.xml} must be kept in sync, so one has to be very careful when making changes (and having to deal with the whole xfree86 tree is no fun). In short,
you do not have time to fix all $oldlayouts layouts (well at least I do not plan to fix them all in Debian), so you have to decide what to do with the remaining ones. You can mark them as being unsupported in xfree.xml for instance, and after that try to replace some old-format layouts by new ones and remove the "unsupported" marker.

[Fabio Massimo Di Nitto (fabbione)]

Ok, I uploaded a new version of X today that includes all the last changes from
Denis.
This should cover almost all the layouts.

I will still leave this bug open as reference.

Fabio

[Daniel Stone (daniels)]

mmm, you can still search for closed stuff and XKB problems seem to be pretty
rare these days

[Metin Amiroff (amiroff)]

I am having the same error that Clint has when I try to add Azerbajani layout on
fresh install of Hoary. Should I file a new bug, or would we reopen this one
once again?

[Denis Barbier (barbier)]

(In reply to comment #33)

This is a different issue, several layouts (including az) are still
in the old mono-layout format. You can file a new bug to request that
these layouts are updated, e.g. by getting them from xkeyboard-config.

[Julien Olivier (julo)]

Hi !

I've had this bug back for about a week now in breezy. I'm using a pc105/fr
keyboard and I get this message when I log in, and my SHIFt key doesn't work
anymore.

[kikoo (kikoo-de-mars)]

Same problem here. Here's the outputs as requested:

 xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "fr", "oss", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc105", "fr", "oss", ""

 gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = []
 model = macintosh
 overrideSettings = true
 options = []

And for what it's worth:
uname -r
2.6.24-19-generic

[Felipe Bernardo Zorzo (felipe-b-zorzo)]

Same here.

xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "base", "evdev", "br", "", ""
_XKB_RULES_NAMES(STRING) = "base", "evdev", "br", "", "grp:alts_toggle"

gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb: show nothing