Not enough info. I need:

- The result of xprop -root | grep XKB
- The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb

I forgot to attach them, these are the results:


Result of: xprop -root | grep XKB

_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc101", "us,hu", ",", "grp:
alt_shift_toggle"
_XKB_RULES_NAMES(STRING) = "xfree86", "pc101", "us,hu", "", "grp:
alt_shift_toggle"

Result of: gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb

 layouts = [hu,us]
 model = pc101
 overrideSettings = false
 options = [grp	grp:alt_shift_toggle]

I am not sure whether severity "minor" is correct. We may have to revert to an
earlier version of gnome for one of our labs...

Sorry. It is famous problem with "hu" layouts (and "ca" as well). They are
broken - even in XOrg server (it seems, up to 6.8.0). I mean they cannot be used
together with other layouts. I am really sorry but we cannot do anything about
it. There is a chance the situation will be fixed in XOrg 6.9.0. I realize it is
high priority, but gnome cannot do much about it.

Just to prove I am right, could you please try this in the command line:

setxkbmap -layout hu,us -model pc101 -option grp:alt_shift_toggle

We have the problem with en,de and en,el.  No hu or ca in sight.

Andreas: I answered about original configuration. Could you please provide your
results of your xprop and gconftool-2?

My configuration:

aguelzow@m36:~$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc105", "us,de", ",",
"grp:caps_toggle,grp_led:caps"
_XKB_RULES_NAMES(STRING) = "xfree86", "pc105", "us,de", "",
"grp:caps_toggle,grp_led:caps"
aguelzow@m36:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb
 layouts = [us,de]
 model = pc105
 overrideSettings = false
 options = [grp	grp:caps_toggle,grp_led	grp_led:caps]

I ma using the same account with an NFS mounted home directory also on another
computer in my office where I don't get that warning. 

Andreas, sorry, one more question (very important): what is your X server?

On the machines in question:

XFree86 Version 4.2.1.1 (Debian 4.2.1-15 20031230220653
root@cyberhq.internal.cyberhqz.com) / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 18 October 2002

I also checked the setup on my office machine, and the X server there is newer.

OK. Actually, I did not get reports from people using XFree 4.2 yet - so you are
the first case.

So are you saying you managed to configure "us,de" on XFree 4.2? This is kind of
strange. It should not be possible. XFree 4.2 does not support "multiple
layouts", so syntax "us,de" is non valid from their POV. Actually, if
gnome-keyboard-preferences support this syntax in 4.2 - it is a bug - this tool
should not allow to select more than one layout. So, can you confirm that you
managed to choose two layouts on XFree 4.2? If so, I'll have to patch
libxklavier somehow - the detection of "old" XFree does not work properly.

I am not saying that I _successfully_ configured it on XFree 4.2.

We have 2 types of machines: office machines and lab machines. On the office
machines we are running 4.3 on the lab machines 4.2.11 as indicated above. On
the office machines we successfully set up switching between keyboard layouts:
us,de for some and us,el for others. On the lab machines we simply stuck with
en. That was in Gnome2.4 days.

Then we updated everything to Gnome2.6.

On the office machine we had to fix the set-up to let us again switch between
layouts using capslock, since the upgrade broke that.

On the lab machines we started getting those warnings. Assuming that it had
something to do with the fact that we didn't list us,de in the X configuration
file we added it for testing purposes on one machine (m36). The output is from
that machine. THe warning also appears on machines with
_XKB_RULES_NAMES(STRING) = "xfree86", "pc101", "", "","" or so (I can't check
until Monday.)

OK. So can I assume your office machines are ok (with 4.3)? And will we continue
with the lab machines with xfree 4.2? If so, I'd be delighted if you give me
their own xprop and gconftool-2 results. Though please keep in mind - you'll
only be able to use one layout with 4.2 - because, as I said, this version does
not support multiple layouts.

Yes the office machines with 4.3 are fine. I'll get you the original xprop info
and gconftool-2 result on Monday. The gconftool-2 result will of course be the same.

on the lab machines:

Error activating XKB configuration.
Probably internal X server problem.

X server version data:
The XFree86 Project, Inc
40201001

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
--------------------------------------------------------------------------
aguelzow@m40:~$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc101", "us", "", ""
_XKB_RULES_NAMES(STRING) = "xfree86", "pc101", "us", "", ""
aguelzow@m40:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb
 layouts = [us,de]
 model = pc105
 overrideSettings = false
 options = [grp	grp:caps_toggle,grp_led	grp_led:caps]
---------------------------------------------------------------------------

the warning disappears if I change teh layouts in gconftool to us, but this also
affects teh office machines and so is not an acceptable solution.

Arrrgh. The problem is that XFree 4.2 does NOT support multiple layouts. What I
can advise you is to disable xkb completely (in XF86Config) - so you'll see the
old gkb again - and will be able to use xmodmap-based approach. I do not see any
good solution on XKB field for you - other than upgrading to XFree 4.3.

But we do not need layout switching on the XFree4.2 machines. Our problem is
_not_ that we can't switch layouts on those machines. Our problem is that at
login we get that stupid warning message. (We didn't get it before we updated to
gnome 2.6 from gnome 2.4)

Sorry, I did not understand you right. I thought you needed switching. OK. Could
you please run gconf-editor and change
/desktop/gnome/peripherals/keyboard/xkb/layouts to just "us" (remove the second
element from the list) and clean the list
/desktop/gnome/peripherals/keyboard/xkb/options? Will it remove the error
message at startup?

Yes, (of course) it will. We have already done that for some staff members and
our students. But it also disables switching on our office machines and so it is
not an acceptable solution.

Ugh. Now I see. You want to use the same gconf setting on machinges with XFree
4.2 and with XFree 4.3 (and have the keyboard switching). Bad case:/ I do not
have any particularly bright ideas other than having some startup script which
would analyze your configuration (X server version) and tweak the gconf using
gconftool-2. And you have to ensure this script is run before g-s-d starts
(because it is actually g-s-d which gives you this warning at startup).

g-s-d did not used to present this stupid warning dialog in 2.4. 

Tweaking at login  may work if those settings are only used at login time.
(Users may be logged in on lab and office machines simultaneously. In fact I
tend to be logged into my office machine continuously.)

Nevertheless tweaking at login seems to be a very bad hack that should not be
necessary.

COnsidering the warning dialog does not provide any information the average user
can use to avoid the dialog, why is it presented?

We could easily add a gconf key to suppress the warning.  Something on par with
the existing
   /desktop/gnome/peripherals/keyboard/disable_xmm_and_xkb_warning

which stops warnings about .modmap files.

Andreas : would that be sufficient for your needs ?

True. g-s-d did not know about xkb in 2.4.

> Users may be logged in on lab and office machines simultaneously

Well, I never tried this configuration. How many gconfd daemons are running? Is
one instance aware of the changes made by another one? Sorry, I am not aware of
these details. Actually, g-s-d looks for these settings constantly - so if you
change them at any point (not only login time) - they will be picked up (at
least within one gconfd scope).

I do not particularly like the idea of this hack. But I do not know how to
handle properly single environment when you need some feature on one system -
and another system does not support it.

About the warning dialog. In most cases this dialog really indicates that chosen
configuration is not supported by the X server. And since users ask _me_
questions  "What should I do to get rid of it?" - I want them to provide the
information I need. Sure, in your situation it is not exactly the case. If you
could come up with some better idea on how to handle your tricky configuration...

Jody: but still on xfree 4.2, the xkb configuration will not be setup properly
(for example, if they want to use some options or non-default keyboard model -
they can cause troubles). It is important to keep in mind.

Sergey, there is only on gconf daemon running. This way the settings are
consistent across all machines a user may be using (45 machines in our case).

My configuration isn't really tricky. The problem is that you are using
something stored in gconf globally and apply it to a local installation where it
may not fit. If you want to store something in gconf that is machine specific
you should probably tag it with the machine name.

Jody, just stopping the warnings would be great and definitely sufficient.

Well, it is quite easy to introduce one extra boolean gconf flag and do not show
this warning. I can do it. I just think whether it is ok to hide problems
instead of fix it properly. Since we already missed 2.8 train - can we invent
something proper for 2.10? Could gconf provide us with per-machine settings
somehow? Do we have to do it manually? What do you think, jody? Do you see any
solution which would not look like some hack?

Well, since I can't wait until 2.10, I have decided to risk upgrading one of the
lab machines to xfree86 4.3 but still get the warnings:

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

with:
aguelzow@m02:~$ xprop -root | grep XKB
aguelzow@m02:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb
 layouts = [us,de]
 model = pc105
 overrideSettings = false
 options = [grp	grp:caps_toggle,grp_led	grp_led:caps]

of course not having any output from the xprop command is strange.

This is really really strange situation. Are your sure your did not break the X
server configuration somehow? Could you please try "xdpyinfo -ext all | grep
XKEYBO"? Could you please also try "setxkbmap -layout 'us,de'"?

I am sure I did. Checking the log file I find at the beginning:

(**) |-->Screen "Display 1" (0)
(**) |   |-->Monitor "Display 1"
(**) |   |-->Device "MATROX CARD 1"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xfree86"
(**) XKB: rules: "xfree86"
(**) Option "XkbModel" "pc101"
(**) XKB: model: "pc101"
(**) Option "XkbLayout" "us,de"
(**) XKB: layout: "us,de"
(**) Option "XkbOptions" "grp:caps_toggle,grp_led:caps"
(**) XKB: options: "grp:caps_toggle,grp_led:caps"
(==) Keyboard: CustomKeycode disabled

but later on:

(II) Keyboard "Keyboard0" handled by legacy driver
(II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
Couldn't load XKB keymap, falling back to pre-XKB keymap
(II) Server_Terminate keybinding not found

These keymaps seem to be part of xlibs. Updating xlibs is not acceptable.

Hmm. I do not understand why would keymaps be in xlibs package (actually, since
xfree is monolitic, it is up to the packager how to split it). But you really
need the directory /usr/X11R6/lib/X11/xkb from xfree4.3 - there are keymaps and
other xkb config stuff, tailored for multiple layouts. About this particular
problem - I'd adwise to play with the command line "setxkbmap" utility (with
-print option) and "xkbcomp" utility (with "-w" option). Sometimes they help to
understand why XKB fails at X startup (one I even did "strace X" to debug
similar problem - I found some missing files).

debian has the XKB data in xlibs. Currently trying to install xlibs tries to
uninstall most of gnome. I'll play with it later and see what I can do.

Actually, if you are interested in some experimenting you could try to take XKB
data from xkeyboard-config
(http://www.freedesktop.org/Software/XKeyboardConfig). It is separate standalong
XKB configuration repository - and it should work ok with xfree4.3.

Closing it - it is about broken X server (XKB data)

Actually, I thought it was clear that this is not really ablout a broken Xserver
but about a stupid and completely useless warning message.

OK. In 2.9.x the message is changed. Could you please have a look whether it
makes sense to you now - for this situation? But I cannot remove it - because it
really indicates that your XKB configuration cannot applied be in the current
environment, so you should do something about it.

For us the problem is the _existence_ of the error message that is the problem,
not it's content. I can see that hte message is shown _once_, potentially
_once_per_host, but showing the message again_and_again_and_again is the
problem. Especially if you are telling us that with a certain X server mix
across our machines we supposedly can't have multi-keyboard support provided the
x-server supports it.

Having said this, for us this is currently not an issue anymore since we are
currently using the same X server across all machines running GNOME. I will be
filing a new bug report about a similar error message dialog though which is
even more annoying.

Since I am currently fighting for us to retain GNOME despite the general
regression in usefullness, such annoying error messages do not help this case. 

well, I am not really sure about the right way to make this solution generic.
Sure, the most generic solution is to have some key which would stop this dialog
forever. This is easy. And I'm afraid it is the only way. It is highly
problematic to support several configurations on different X servers with
different XKB capabilities. But if we suppres this message - user will never
know about problems - and can complain about "silently not working" GNOME. It is
good?

The annoyance of warning dialogs on every start-up is clearly much worse. (One
could always write supplemeantary warnings into .xsession-erors.)

Oh yeah and I should file a separate bug about the "use GNOME keymap" annoyance.

"use GNOME keymap" is a feature, not a bug! It detects the situation when admin
changed his xorg.conf - so probably user may want to update his personal
configuration. 
Actually, IMHO the problem of using single $HOME on multiple machines should be
treated GNOME-wide, not on tool-per-tool basis. There should be multiple
profiles in gconf (with decent profile management etc). I don't think it is fair
to require each separate tool to be "host-switching"-friendly on individual,
per-tool basis.

I can live with being askes _once_. But de-facto I and many of our 300+ users
are being asked on any single login. gconf is designed to provide general
configuration information. Everybody knows that it is not machine specific, So
it _is_ a bug if a tool uses gconf to store info that is machine specific. 

For example gnumeric avoids storing window location in gconf since since screen
size and number may differ, So if we were going to use gconf we would at the
least store machine name with the configuration. In fact that is _not_ very hard
to do.

Only each tool can know whether a certain setting is machine independent or
machine specific.

Well, if gconf would have a notion of "per-machine" and "machine-agnostic"
settings - it would be a great support. But the thing is that
layouts/model/options configuration is NOT machine specific - if all your
machines (X Servers) support the configuration you chosen once. For example, if
you have one machine with XFree 4.3, another - XFree 4.4, third - XOrg - you'll
be able to switch between machines (well, there are some "bad" cases - but not
to many of them). And I think user would not be happy to reconfigure each
machine separately. The demarcation is not between machines - but between "good"
and "bad" X servers. And nowadays most of the machines have reasonably "good"
servers - XFree 4.3 and older. So putting this switching machinery (in GNOME
2.12 - which is due next autumn!) into g-s-d, just to support 4.2 (several years
old!) - IMHO would be too much.

Yeah, I could store machine name with the config - but I am convinced it all
should be on GConf level - the support of the per-machine configuration.
Introducing the machine name into the gconf path name is some artificial hack
intended to replace the proper solution on the lower level. And I think it is a
good idea to discuss this matter on d-d-l - the overall gnome policy in
multi-machine, shared $HOME enviromnent (and if d-d-l enforces me to put the
machine name - or better X server name - into GConf, I'll do so).

We are now runing the same X servers on all machines. (Whatever was current in
debian sid in late December.) Obviously the configuration differs, since the
hardware does. Everytime I move from one cluster to another I get the same
question although I always answer "use gnome keymap" so do other users.

One cluster of machines has within X only one keyboard configured. (It's  a
public freshmen lab and switching keyboard layouts is not a good idea.)

THe other cluseter is for more advanced users and we have keyboard switching
configured in X. (We dnon't always use GNOME on those machines.) 

Ok, with same X servers on all machines - do you see "error activating xkb
config" or "system configuration changed" dialog? I presume - the latter. Yeah,
in this case it has nothing to do with the version of X server itself - the
problem (from g-s-d POV) is that your xorg.conf files are different...

Overall, your configuration looks very specific (non-trivial). For the problem
you described - there is a point of saving per-system configuration on
per-system basis. But if we want to make it right - it should be in GConf API.
This problem is definitely worth public discussion...

For a university setting our situation is not that strange: I and my colleague
across th ewhole like to switch between German and US layout. The colleague next
door switches between Greek and US, others between French and US etc. Our junior
computer lab of course only has US in its X configuration. 

We could remove any keyboard switching from the X conf files. I would hope that
suffices in quietening GNOME, but then we loose the ability to switch when we
don't use GNOME. That isn't acceptable either.

I gather our best solution is to recompile the control center after ripping out
the warning. Can you point me to the source file that is responsible for that
warning?

Thanks

> We could remove any keyboard switching from the X conf files. I would hope that
suffices in quietening GNOME, but then we loose the ability to switch when we
don't use GNOME. 

I see the problem. But you know - you could have /etc/X11/XF86Config (on all
machines) which would always contain single "us" layout - and allow users (who
do not use GNOME) to have their own, local XF86Config in $HOME (and use
-xf86config option, as described in man:
http://www.xfree86.org/4.3.0/XF86Config.5.html). Would this solve the problem?

Sure you can remove the warning message, it is in
gnome-control-center/gnome-settings-daemon/gnome-settings-keyboard-xkb.c,
function gnome_settings_keyboard_xkb_analyze_sysconfig.

Forwarded Havoc's reply:
---
You just have to define "per-system" somehow; what is the system
identifier.

If it's the hostname, then in your shell init scripts you can set
HOSTNAME=`hostname` and then you can have a gconf source with the
hostname in the path. Put this in ~/.gconf.path:

xml:readwrite:$(HOME)/.gconf-$(ENV_HOSTNAME)

Of course, then *all* your settings will be host-specific. To avoid
that, you could manually copy only some settings to the host-specific
location, and then make it xml:readonly: to gconf.

If you want an identifier other than hostname, just use it instead...

I've never added any kind of standard per-user-per-system config path
because I don't see how it can happen automatically without creating
unreasonable levels of user-visible complexity. But if someone figured
it out, we could do it.
---

If we would have _all_ settings host specific we could just use local lock files
and not let gconf talk via the network. But that is clearly not what one wants.
I think those system specific settings should not be in gconf! It would be so
easy to keep them in a configuration file
.gnome/.keyboard-steiner.lab.math.concordia.ab.ca
 

"http://www.xfree86.org/4.3.0/XF86Config.5.html). Would this solve the problem?"

According to that manual page, when a non-root user starts X, it does _not_ look
for a configuration file in the home directory. Of course one could put some
more custom files into /etc/X11/ but all of that doesn't work when one uses gdm
or kdm or xdm, so it isn't really a feasible option.

So, as a minimal solution, I added a GConf key and a checkbox into the error
message.

Created attachment 37048 [details]
New version of the warning