alts_toggle breaks instead of overriding ralt -> l3

I've forwarded that upstream: https://bugs.freedesktop.org/show_bug.cgi?id=4448

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

not specific to the fr layout

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

I wanted to comment on bug #20888 , but since that was marked as a duplicate of
this one, I comment here instead.

I also have problems with setting the keyboard layout with the 'System >
Preferences > Keyboard' tool (in my case, to 'Switzerland German'). I've tested
this only over the last few days, but on two different architectures (i386 and
amd64) and different releases (breezy-colony4 and breezy-preview). I'm not sure,
but I think the behaviour changed slightly in-between breezy-colony4 and
breezy-preview... could that be?

Anyway, setting your keyboard layout under 'System > Preferences > Keyboard' is
buggy.
Even if you changed the language successfully, the changes become ineffective on
logout - even though the setting in the menu still displays 'Switzerland German'
as a default.
In breezy-colony4, I could get the layout to change with some strange fiddling
about. I added the keyboard 'Switzerland German' a second time (don't ask, users
try strange things ;-). Then I mark the new "S.G." as 'default', "move it up" in
the ordering, and then delete the first 'S.G.' and then it works, i.e. the
layout is set to Swiss German for both console and gnome... until the next
logout, that is! Very annoying, indeed. :-(
In breezy-preview, the "adding twice trick" doesn't work any more. However, I
can now change the layout successfully (both console and gnome) with the
'keyboard indicator' tool in the gnome panel.

I don't know if these bugs are related or not, but I thought I'd mention it
anyway (they are all keyboard layout related problems I have): bug 19159 , bug
15142 and bug 17774 .

If anyone sees through all of this weird behaviour, please let me know! :-)

Philipp, I'd say this is irrelevant. The keypoint to analize is the gconf.
Probably, for some reason, you get something broken in gconf. Would you mind
filing a separate bug, CC to me and we'll try to find the matter of problem. Or
just find me (svu) at #gnome-hackers - it may be faster...

I have noticed interesting behaviour. When I remove all layouts from the layout
list and add "Lithuanian US" (Ltu) and "U.S. English" (USA), I have US layout
when Ltu is activated and Ltu layout when USA is activated on the applet (!).

When I add another leyout, e.g. Russian Phonetic, it can be seen on the list
(all 3 layouts), but when I click on the applet only USA and Ltu laytous appear.

mjoc@orion:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [lt us,us,ru phonetic]
 model = pc104
 overrideSettings = false
 options = [grp grp:alts_toggle]

After executing 'setxkbmap "lt(us)"' I have what I need, Lithuanian US keymap.

Martynas,

> I have noticed interesting behaviour. When I remove all layouts from the layout
> list and add "Lithuanian US" (Ltu) and "U.S. English" (USA), I have US layout
> when Ltu is activated and Ltu layout when USA is activated on the applet (!).
>
> When I add another leyout, e.g. Russian Phonetic, it can be seen on the list
> (all 3 layouts), but when I click on the applet only USA and Ltu laytous appear.
Very interesting. I cannot reproduce your situation on my box. What about xprop
-root | grep XKB?
Though it is not relevant to the original bug IMHO:)

mjoc@orion:~$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc104", "us", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc104", "lt,us,ru", "us,,phonetic",
"grp:alts_toggle"

Today after boot I see "Ltu" on the keyboard layout applet, but when I click on
it, other layouts (Ru, USA) do not appear.

I have "us" layout set in /etc/X11/xorg.conf, but it was set in past too and
keybaord layouts worked fine, so this is not the problem I guess.

okay, sergey:
if I remove type[Group1]="ONE_LEVEL" from level3:ralt_switch, then everything
works fine for the first group. l3 is generated as it should be, as is group
switching.
but then when the group changes, ralt l2 becomes NoSymbol, instead of
ISO_Next_Group. so you can't switch out of that one.

so it would appear that the ONE_LEVEL stuff is needed, but is getting badly
scoped; I would assume that ONE_LEVEL would only be valid for the scope it's
declared in, so it would only have an impact on the level3 stuff, but by the
looks, the ONE_LEVEL tag hangs around for the entire compilation, so when we
declare the l2 symbol, it bombs. hm. i don't think anything's changed in the
XKB code; indeed, maprules.c and most of the rest of libxkbfile hasn't changed
since xfree86. any ideas?

okay. this one's a doozy.

symbols/pc: key <RALT> { [ Alt_R ] };
symbols/level3: key <RALT> { [ ISO_Level3_Shift ] };
+group(alts_toggle)
 -> when both Alts pressed, Alt_L generates ISO_Group_Prev, Alt_R generates
NoSymbol, unshifted is fine

symbols/pc: key <RALT> { [ Alt_R ] };
+ group(alts_toggle)
 -> when both Alts pressed, Alt_L generates ISO_Group_Prev, Alt_R generates
ISO_Group_Next (i.e, works), unshifted is fine too

symbols/pc: key <RALT> { [ ISO_Level3_Shift ] };
+ group(alts_toggle)
 -> when both Alts pressed, Alt_L generates ISO_Group_Prev, Alt_R generates
ISO_Group_Next (i.e. works), unshifted is fine too

argh, my head.

so my last comment was kind of unclear.

if you do, say, fr,de,us, the first one will work fine. so both alts will
toggle the group. but after that, RALT ends up as [ ISO_Level3_Shift, NoSymbol
]. so you can shift fr->de with alts_toggle, but not de->us, f.e.

(and no, specifying grp(alts_toggle):2, etc, doesn't help.)

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

> _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "lt,us,ru", "us,,phonetic",
> "grp:alts_toggle"
This looks fine. All

> Today after boot I see "Ltu" on the keyboard layout applet, but when I click on
> it, other layouts (Ru, USA) do not appear.
Very strange. I just tried - it works for me. The only advice I can give - try
running the applet in gnome-terminal, first setting XKL_DEBUG=500. You should be
able see what happens when you click the applet...

> (and no, specifying grp(alts_toggle):2, etc, doesn't help.)
Well, we never specified any rules which would allow using options in "higher
groups", so no wonder.

Daniel, looking at your messages it all smells rather ugly. I don't know whether
anything was changed in xorg xkb code. But I feel like we are trapped in some
logical problem... :( Should we add some rules to allow options specified with
the group number? Like grp:alts_toggle:2... Not that I am excited about it...

svu: no, nothing changed recently. i'd assume the options are still getting
applied, just incorrectly. i'll add some debugging code to xkbfile.

Daniel and Sebastien claim that this bug is crushing in its impact, despite the
fact that it seems like an uncommon non-default configuration. Raising severity.

quite annoying but let's say it's not a stopper because using multi-layout is
not a stopper.

g-s-d should no crash on setxkbmap issue and maybe we can drop "-option 'grp:alt
s_toggle'" from the default call. Sergey, any opinion on that?

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

I raised bug 22395 which has been marked as a duplicate of this one.

In that bug I reported some strange "theme changing" where I see the window
frames change from brown to blue and back again whenever I use the "Up", "Down"
and "Add" buttons in the keyboard notifier. I don't see that mentioned anywhere
in this bug, so I thought I should mention it again to stop it from being lost.

In reply to the last comment, by <email address hidden>

The strange "theme changing" of gnome has been reported in bug 19159, see
comments #5 and #7 there. I don't know how much or little these problems are
interrelated, I just thought I'd mention it here anyway.

Thanks for pointing that out. I had managed to overlook those bugs.

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

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

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

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

It's now possible for me to change keyboard layout from US/EN to German and back
in Gnome on Ubuntu Breezy RC1.

In reply to comment #23

I think marking bug 21767 as a duplicate of this one is a mistake, since that
bug reports other issues that aren't addressed here.

Quoting from bug 21767 comment #8 :

1.) gnome looses CD installer's keyboard settings
2.) 'gnome-keyboard-properties' doesn't work properly
3.) gnome panel 'keyboard indicator' only works for individual windows, rather
than globally, i.e. the whole desktop

1 --> NOT FIXED, compare with comment #8 and also with bug 15142 and bug 19159
2 --> FIXED in bug 21595
3 --> CONFIGURATION ISSUE, compare with bug 19159 , comment #10

Daniel, could you please undo this particular 'duplicate' marking? Many thanks!

On Breezy Release Candidate, I am glad to report a (partial?) success.

I can now successfully add multiple keyboard layouts in 'System > Preferences >
Keyboard' and my setting of a particular keyboard layout to 'default' (using the
checkbox) won't be lost every time I log out. :-)

(Thus, I don't need to apply the 'workaround' solution of unchecking 'Both Ctrl
keys together change group.' and checking 'Right Ctrl key switches group while
pressed.' instead.)

However, other keyboard-related problems still remain. These problems have been
described in other bug reports. Unfortunately, these bugs are somewhat
ill-labelled / intermingled and don't seem to get a lot of attention? Compare
with the bugs I mentioned in my last comment.

Let me mention this one particular problem:
I get the Swiss German layout when the panel indicator shows "USA" and I get an
"us" keyboard layout
when the indicator shows "Che". See bug 19159#c6

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

Revision of my comment #29

I did a fresh install of Breezy RC and tested again.

After I added a second keyboard layout ("Switzerland German") and set that one
as default, the keyboard is still set to the original "us".

However, I *can* change the layout to Switzerland German by pressing both Alt
keys together. But then I am stuck with that layout, i.e. I cannot change the
layout back to "us" when I press both Alt keys again. If I close the window and
start another one, the keyboard setting is "us" as default, rather than
"Switzerland German" which I set to default... Ugh.

Then I rebooted. Again the layout is "us" by default, instead of "Switzerland
German" as displayed in the gnome preferences tool. To make things worse,
pressing both Alt keys won't even change the layout to "S.G." once anymore. :-/
If I shift the "S.G." in the pref tool down and up again (I get that strange
"refresh" of the gnome desktop, as reported elsewhere) and then I *can* change
to "S.G." by pressing both Alts - but only once and not back, as described above.

I'm glad to do specific tests on my machine, just let me know.

Initially, there were two sides of this problem: in xkeyboard-config and
libxkbfile. I hopefully fixed the part in xkeyboard-config - now some small
change in libxkbfile is needed.
Danilo, could you please remove the lines 385-391 in libxkbfile/maprules.c:
   if (((present&PART_MASK)&(1<<OPTION))&&
                                ((present&PART_MASK)!=(1<<OPTION))) {
        PR_DEBUG("Options cannot appear with other parts\n");
        PR_DEBUG("Illegal mapping ignored\n");
        remap->num_remap= 0;
        return;
   }
and see whether current xkeyboard-config (from CVS) fixed this bug. If so, I'd
ask somebody who could commit to xorg tree (I cannot) to update it.

ah, if you're adding layout + option -> symbols, that would make sense. if so,
I'll probably commit it upstream.

> ah, if you're adding layout + option -> symbols, that would make sense. if so,
> I'll probably commit it upstream.
Absolutely! For me, it works ok.

please test:
http://people.ubuntu.com/~daniels/libxkbfile1_7.0.0-3_i386.deb
http://people.ubuntu.com/~daniels/xkeyboard-config_0.6-6_all.deb
(must be installed in the same dpkg run)

and see if this resolves things for all you guys

Downloaded the .debs, did...

$ sudo dpkg -i libxkbfile1_7.0.0-3_i386.deb xkeyboard-config_0.6-6_all.deb

Installation went through ok. I rebooted.

Result: Partial Fix

Two improvements:
1.) Now, my default layout is recognised properly, i.e. I ticked "Switzerland
German" as default in keyb. prefs. and when I log in, this is the indeed the
default (instead of the "US" as before.) :-)

2.) Also, I can change the keyboard layout successfully by moving the layout to
the top position in the keyboard prefs tool with the 'Up' and 'Down' buttons.

2b.) BTW, now, if I move the kb layouts in the keyboard prefs tool with the 'Up'
and 'Down' buttons, I don't get that weird "refresh" of the gnome theme (bug
23552) anymore.

A problem remains:
I still cannot toggle the layout by pressing both Alt keys.

What useful system info could I provide to help?

The detect-keyboard shellskript always returns the same:

$ sudo ./detect-keyboard.sh
Password:
tuple is sg-latin1--en_US
layout is us
rules are xorg
model is pc104
options are

please provide the output of:
setxkbmap -print
setxkbmap -print | xkbcomp - :0
setxkbmap -print | xkbcomp -xkb - - (you probably want to attach this one, it's big)

(In reply to comment #35)
> please test:
> http://people.ubuntu.com/~daniels/libxkbfile1_7.0.0-3_i386.deb
> http://people.ubuntu.com/~daniels/xkeyboard-config_0.6-6_all.deb
> (must be installed in the same dpkg run)

I still have the error message at startup of X and for every change in the
keyconfig I get the error twice.
So nothing changed here.

Do you need my output of
setxkbmap -print
setxkbmap -print | xkbcomp - :0
setxkbmap -print | xkbcomp -xkb -
?

if you installed those two, then yes please

Sorry for not getting around testing this sooner, I was very busy all day.

$ setxkbmap -print
xkb_keymap {
        xkb_keycodes { include "xfree86+aliases(qwerty)" };
        xkb_types { include "complete" };
        xkb_compat { include "complete" };
        xkb_symbols { include
"pc(pc104)+ch(de_nodeadkeys)+us:2+level3(ralt_switch_for_alts_toggle)+level3(ralt_switch_for_alts_toggle):2+group(alts_toggle)"
      };
        xkb_geometry { include "pc(pc104)" };
};

$ setxkbmap -print | xkbcomp - :0
Warning: No symbols defined for <SYRQ> (keycode 92)
Warning: No symbols defined for <BRK> (keycode 114)
Warning: No symbols defined for <FK13> (keycode 118)
Warning: No symbols defined for <FK14> (keycode 119)
Warning: No symbols defined for <FK15> (keycode 120)
Warning: No symbols defined for <FK16> (keycode 121)
Warning: No symbols defined for <FK17> (keycode 122)
Warning: No symbols defined for <KPDC> (keycode 123)
Warning: No symbols defined for <XFER> (keycode 129)
Warning: No symbols defined for <I02> (keycode 130)
Warning: No symbols defined for <NFER> (keycode 131)
Warning: No symbols defined for <I04> (keycode 132)
Warning: No symbols defined for <AE13> (keycode 133)
Warning: No symbols defined for <I06> (keycode 134)
Warning: No symbols defined for <I07> (keycode 135)
Warning: No symbols defined for <I08> (keycode 136)
Warning: No symbols defined for <I09> (keycode 137)
Warning: No symbols defined for <I0A> (keycode 138)
Warning: No symbols defined for <I0B> (keycode 139)
Warning: No symbols defined for <I0C> (keycode 140)
Warning: No symbols defined for <I0D> (keycode 141)
Warning: No symbols defined for <I0E> (keycode 142)
Warning: No symbols defined for <I0F> (keycode 143)
Warning: No symbols defined for <I10> (keycode 144)
Warning: No symbols defined for <I11> (keycode 145)
Warning: No symbols defined for <I12> (keycode 146)
Warning: No symbols defined for <I13> (keycode 147)
Warning: No symbols defined for <I14> (keycode 148)
Warning: No symbols defined for <I15> (keycode 149)
Warning: No symbols defined for <I16> (keycode 150)
Warning: No symbols defined for <I17> (keycode 151)
Warning: No symbols defined for <I18> (keycode 152)
Warning: No symbols defined for <I19> (keycode 153)
Warning: No symbols defined for <I1A> (keycode 154)
Warning: No symbols defined for <I1B> (keycode 155)
Warning: No symbols defined for <K59> (keycode 157)
Warning: No symbols defined for <I1E> (keycode 158)
Warning: No symbols defined for <I1F> (keycode 159)
Warning: No symbols defined for <I20> (keycode 160)
Warning: No symbols defined for <I21> (keycode 161)
Warning: No symbols defined for <I22> (keycode 162)
Warning: No symbols defined for <I23> (keycode 163)
Warning: No symbols defined for <I24> (keycode 164)
Warning: No symbols defi...

Created an attachment (id=4507)
output of $ setxkbmap -print | xkbcomp -xkb -

My bug - http://bugzilla.ubuntu.com/show_bug.cgi?id=15350 - was marked as a
duplicate of this bug. I installed the debfiles as well and rebooted. After a
reboot I noticed that it still didn't work, so I intended to post a comment
about that today. When I turned my PC on today, I noticed that for some reason
the problem is fixed now. I always had the "Netherlands" layout selected in the
keyboard preferences, and now it does really use the Dutch layout, and not the
English like it did in the past.

Should I attach the output of the commands as well, or isn't that necessary
because it works for me?

the 'works for me' is sufficient, thanks

fix has been rejected for breezy final, but will hopefully land in
breezy-updates soon, and dapper, whenever it ends up opening

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

(In reply to comment #44)
> fix has been rejected for breezy final, but will hopefully land in
> breezy-updates soon, and dapper, whenever it ends up opening

I'm don't want to blame the developers here. But because of this kind of
decisions, I think the Ubuntu development team should reconsider either the
principle of releasing every half year or the lenght of the feature freeze period.

Sure, we can update our Ubuntu installation via the internet, but what if you're
a poor person or living in a remote area, without an internet connection? If you
would be such a person, you would have a serious problem with the Breezy release
when this bug would affect you. In my opinion it would have been best to delay
the Breezy release so that this fix could be included, a bug of these
proportions should never go unfixed in a final release.

Ok,

I should add, that if you had customized your layout file, even downloading and
Daniel's debs does not help.
I had modified lt file in pc (/etc/X11/symbols/pc) directory, and upgrade
process left it. Since there is no pc directory in Breezy xorg,
but there is pc file, you are left with broken setup. After removing pc
directory and creating pc file from pc.dpkg_new
everything is working fine now. This bug report sure was helpful. Thanks everybody!

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

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

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

I did like Vaidotas Zemlys said on Comment #47

sudo mv /etc/X11/xkb/symbols/pc /etc/X11/xkb/symbols/pc_old
sudo cp /etc/X11/xkb/symbols/pc.dpkg-new /etc/X11/xkb/symbols/pc

And now it looks working! :)

I'm not sure is it better to reboot before changing keyboard settings.
I did't test those libxkbfile1_7.0.0-3_i386.deb & xkeyboard-config_0.6-6_all.deb
packets.

(In reply to comment #51)
> I did like Vaidotas Zemlys said on Comment #47
>
> sudo mv /etc/X11/xkb/symbols/pc /etc/X11/xkb/symbols/pc_old
> sudo cp /etc/X11/xkb/symbols/pc.dpkg-new /etc/X11/xkb/symbols/pc
>
> And now it looks working! :)
>
> I'm not sure is it better to reboot before changing keyboard settings.
> I did't test those libxkbfile1_7.0.0-3_i386.deb & xkeyboard-config_0.6-6_all.deb
> packets.

I tested the packge
http://people.ubuntu.com/~daniels/xkeyboard-config_0.6-6_all.deb

now i can switch from a keyboard to another without problem
thanks

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

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

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

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

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

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

mdz: what's going on with the upload to breezy-updates?

Let's see how it does in dapper for a bit before unleashing it on breezy-updates

dappered. leaving the bug open, since i'll just spend the next few weeks
closing yet more bugs as duplicates of it anyway.

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

" ...that software tools should be usable by people in their local language and
despite any disabilities... "

Ok. Quote from the website.

This bug predates Breezy's launch.

It was determined not to be a stopper since "sing multi-layout is not a
stopper". Well I was not using multiple layouts. I was using one that simply
required a working r_alt. us_intl. And it broke. I've been able to get it
working on occasion but the bug strangely re-emerges on occasion.

GJ. It's good to know that there is someone out there defining what are the
major concerns. Getting people to use the latest Gnome takes precedence over
letting them work in their native language. Fine.

Will be looking through this bugzilla before the next _____GNOME RELEASE_____.

the modified .deb files (http://bugzilla.ubuntu.com/show_bug.cgi?id=15372#c35)
only helped after making the move magic :-)
(http://bugzilla.ubuntu.com/show_bug.cgi?id=15372#c51)
The messages from "sudo dpkg -i ..." helped me determining it.

The problem seems to be the packaging of the new x.org files
/etc/X11/xkb/symbols/pc was a directory,
which held the keyboard layouts in previous versions and the installation
scripts don't take that into
account.

IMHO it's not a GNOME problem, because the problem also happened with XFCE.

(re comment #64): yes, symbols/pc remaining as a directory can cause a similar
problem to manifest itself, but it's not quite the same as this bug ('error
activating xkb configuration' and friends can be caused by a multitude of
problems). but neither your problem, nor this bug, have anything whatsoever to
do with gnome, gnome releases, or whatever.

Re Comment 63: I have a working right alt. I am using the British keyboard, and
AltGr 4 gives '€', which is the expected behaviour. What I can't do is have two
keyboard layouts (in my case I want British and Greek Polytonic) and switch
between them. I'm not sure why your right alt key doesn't work, but it's a
different issue to the one I have. My issue genuinely isn't a stopper. I'm in
a small minority just by wanting to use this functionality, and even I don't
care about it that much!

I just thought I'd point this out, so anyone investigating this bug realises
that there are two different problems.

(In reply to comment #66)
> I just thought I'd point this out, so anyone investigating this bug realises
> that there are two different problems.

My problem appears to be that the keyboard map I used to have, us_intl, just
isn't there anymore. And still that little widget thingie offers it as an option
and I get no error. Didn't get an error until I tried changing keymaps to
us_intl via the "Configuration editor". I don't know, I guess us_intl is a
miniscule minority keyboard. I never thought this was my problem, someone else
made the problem I reported a copy of this one. Which seems to have happened
alot. Everything and anything involving the right alt key has been marked as a
copy of this particular issue.

My point about Gnome earlier was not that this was a Gnome issue. Read that
again and try to sense the sarcasm.

On that note. Perhaps the solution is not to have right-alt keys functionality
differ from left alt :PPp~~

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

> My point about Gnome earlier was not that this was a Gnome issue. Read that
> again and try to sense the sarcasm.

8-P I was too busy getting the keyboard working. In my case, making the Spanish
keyboard working was not enough... my wife needs a Russian keyboard (sigh)
Do you understand the 'extra pressure'?

(In reply to comment #60)
> Let's see how it does in dapper for a bit before unleashing it on breezy-updates

The breezy-updates upload can't be processed due to some archive weirdness.
I've mailed James about it.

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

Is there some workaround for this bug?

tiago: comment #35 has it

xkeyboard-config_0.6-5breezy1_source.changes
INSTALL
xkeyboard-config_0.6-5breezy1.diff.gz
  to pool/main/x/xkeyboard-config/xkeyboard-config_0.6-5breezy1.diff.gz
xkeyboard-config_0.6-5breezy1.dsc
  to pool/main/x/xkeyboard-config/xkeyboard-config_0.6-5breezy1.dsc
Announcing to <email address hidden>

Breezy users, please report back after upgrading.

Final question: Daniel, have you committed the fix to libxkbfile in xorg CVS?

svu: no, not yet, sorry. will file a bug and request 6.9/7.0 approval after lunch.

(In reply to comment #76)
> svu: no, not yet, sorry. will file a bug and request 6.9/7.0 approval after
lunch.

OK. Thanks. Otherwise I'll get bug reports from other distros.

I've been busy the whole day trying to solve this. I'm quite desperate...
All of a sudden (doesnt everybody say that?) my "Alt Gr"-key (i.e. right Alt Key) stopped working so I could not
enter pipe, at-sign, square-brackets etc. I can only assume this is perhaps because of a previous
"Upgrade all" in Adept (the KDE version of Synaptic). As I've switched from SuSE (RPM-based) to Kubuntu what I
dont know is: Is it perhaps a bad idea to click on Upgrade all? Because of the fact that there is a big fat
button in Adept I thought this is the preferred way to keep my system up-to-date.
Some important things (sorry if this is obvious) for everyone else finally stranding here on this bug:

If you dont have the pc.dpkg_new file mentioned in a previous comment you need to do dpkg -i blabla first as
described. This will fail because the file "pc" cannot be replaced by dpkg as it is a directory, not a file.
So, dpkg cannot overwrite the file and instead calls it pc.dpkg_new. Now, you can rename the directory yourself
to sth. like pc_old and rename the pc.dpkg_new file to "pc". Now you have a file called "pc" not a directory.
I had to run dpkg -i blabla again to really update everything.
Now restart the X server by Ctrl+Alt+Backspace.

This leaves me exactly in the situation described in Comment #40.
setxkbmap still fails, the right Alt Key still doesnt work.
Is there any hope or do I really have to reinstall Breezy from scratch?
If I have to reinstall - what can I do to make sure this does not happen again?

what's the output of 'setxkbmap -rules xorg -model pc104 -layout us -variant ""
-option "" -print | xkbcomp - :0'?

Exactly like comment 40. Lots of Warnings: No symbols defined.
At home my Kubuntu does work. I did not do any updates there.
The same messages apperar there. BUT: If I do a setxkbmap without
anything it works there. But here a message appears:
Error loading new keyboard description.
The message also appears when I do a setxkbmap with the parameters
you have given except the print and the following pipe through the
keymap compiler.

Created an attachment (id=5562)
Complete backup of a working xkb folder

I finally got it to work. Sigh. I renamed /etc/X11/xkb to xkb_old and installed
a copy of xkb from my home computer. I've attached the file for everyone
who doesnt have a working Kubuntu installation anymore. This was the only
way to get this right again. All other attempts to get my keymaps rights
were futile. I did uninstall and reinstall every package with and without
purge the config files without any solution. Hope this helps others who have
their keymap destroyed by this bug.
Note: After unpacking the keymap folder you have to run setxkbmap (without
any parameters). This time there hopefully wont be any error message
and your keys should work instantaneously (without any rebooting).

On a freshly installed Compaq Presario V2200 with everything from breezy +
-updates installed, when I run:

setxkbmap -layout 'ca,gb' -model pc102 -option '' -print | xkbcomp - :0.0

I only get warnings. But, with:

setxkbmap -layout 'ca,gb' -model pc102 -option 'grp:alts_toggle' -print |
xkbcomp - :0.0

I get warnings and this:

X Error of failed request: BadValue (integer parameter out of range for operation)
  Major opcode of failed request: 146 (XKEYBOARD)
  Minor opcode of failed request: 9 (XkbSetMap)
  Value in failed request: 0x16710002
  Serial number of failed request: 77
  Current serial number in output stream: 83

As a result, the layout selection in gnome doesn't work for me.

seb128 told me to whine here :-) He says it is fixed in dapper. Don't know if
we want to try and fix this in breezy, but reopening in case we do.

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

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

I just upgraded from Hoary to Breezy.
My keyboard configuration was OK. The update broke X (I had US layout despite gnome telling me it was swiss), so I set it to fr_CH in xorg.conf, but then
and I got various popups including "Error activating XKB configuration." which brought me here. And I solved the problem like this:
Add new layout from the list "Switzerland, French" I get the above mentioned color flicker and more errors.
Remove the old layout, set the new one as default, remove the alt-alt switching option.
It now works. not shure if this will help everyone.

In #30714 I've reported about gnome-session crashes with keyboard switcher applet (please see my bugreport) and it was said that it's the case of this bug and it's fixed in dapper. Please note that from the day of brand-new Breezy I have the same issue even with the current up-to-date Dapper. I can't set *ANY* Hungarian keyboard, because gnome session crashes and likes, so it can be treated a major desktop show stopper bug, since my wife can only type on Hungarian layout and it cannot be set. After playing a lot it _work_ but theme resets to the GTK default, and keyboard applet shows ???, and of course it only work in this session so it cannot be used for serious work.

hey, i'm having a similar problem on dapper flight 5 and the two .debs solution doesn't work because of dependencies problens. can somebody helps me to figure out how to solve this? i've reported what i know here https://launchpad.net/distros/ubuntu/+ticket/521. thanks, rodrigo.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 16 Mar 2006 14:55:09 +0100
Source: xkeyboard-config
Binary: xkeyboard-config
Architecture: source
Version: 0.8-1
Distribution: dapper
Urgency: low
Maintainer: Daniel Stone <email address hidden>
Changed-By: Tollef Fog Heen <email address hidden>
Description:
 xkeyboard-config - XKB data
Changes:
 xkeyboard-config (0.8-1) dapper; urgency=low
 .
   * New upstream release
     - Fixes group switching (Malone: #21595)
   * Add Korean symbols file.
Files:
 f4604431eff58ae81c70c2f401203399 758 x11 optional xkeyboard-config_0.8-1.dsc
 0058bd23ace232ef90fe7cd53b4e6631 640296 x11 optional xkeyboard-config_0.8.orig.tar.gz
 712c442f9f33b2b8e109f0195b05f7cf 4390 x11 optional xkeyboard-config_0.8-1.diff.gz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRB6Z4ccmO3YsB1PjAQIeawP7B2dC8CI9Hw3fefcx+ZIEZ/Z6wVEWi7ak
hd8L3OB6lWY2evPTg7xgGHkNvBUXIeu+SoqJCQPQBSvFcJ6KCOaN56vBLgJzjHG/
L7kPaZY/1EjhavJEP6c4O9uJi6Efmr9DvFWPCcnreMvAS9tAblHmHFoHwtOPy/q2
ZL2ZwbHJxBA=
=vrD/
-----END PGP SIGNATURE-----

Using the latest dapper here. I wanted to say that this also breaks other users from choosing their own keyboard layout. Being an Argentinian living in Italy, I have an italian keyboard but a spanish layout. I can add layouts alright, but can't switch between them, and nobody else can change the layout to, say, italian.

I also notice that when I change a setting in the applet (such as adding a new layout) the theme does change to some sort of default and doesn't go back to "Human" as someone said earlier.

Adriano, what version of xkeyboard-config are you running? Did you restart your system since the upgrade if you have 0.8 installed?

Heh, this is response! After today's afternoon's update, everything works correctly.
Thanks!

This has been fixed in Dapper for some time, but is flagged for backporting to Breezy. Are we confident enough in xkeyboard-config 0.8 to do that now?

Updating to 0.8 should be fine imho. What do you think Tollef?

I'm fairly happy with the current state of 0.8, so a backport should work fine.

Very well. I don't think the package will build properly unmodified (I see it has an x11-common dep), but should be straightforward to backport.

ok i can here from a duplicate but im running FEISTY

i get the

 Error activating XKB configuration.
It can happen under various circumstances:
- a bug in libxklavier library
- a bug in X server (xkbcomp, xmodmap utilities)
- X server with incompatible libxkbfile implementation

X server version data:
The X.Org Foundation
70200000

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/kbd
the output of those cmds is

Code:

jon@albert:~$ xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc102", "us", "il", "lv3:ralt_switch" _XKB_RULES_NAMES(STRING) = "xorg", "pc102", "us", "il", "lv3:ralt_switch" jon@albert:~$

and

Code:

jon@albert:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd layouts = [us il,il phonetic] model = pc102 options = [lv3 lv3:ralt_switch,grp grp:alts_toggle] overrideSettings = true jon@albert:~$

wert613, could you set your configuration using plain command line (with setxkbmap)? Any errors? Also, could you please try changing pc102 to pc105?

Rejecting breezy task; breezy is unsupported in two weeks and this bug won't be fixed before then.