From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040217 Description of problem: With the brokenness of the gnome-keyboard-layout applet (bug 116162), I found myself in need of finding another way to switch to a mode in which I could enter the cedilla character. I found Preferences -> Keyboard, that enabled me to choose not only U.S. English w/ deadkeys as the Core Layout Configuration, but also Advanced Layout Ooptions `compose' settings, that enabled me to choose Right Alt as the compose key, and from then on, the keystroke `compose' (Right Alt), `,' (the comma key, representing cedilla) and `c' would generate ç. Cool. Unfortunately, choosing more than one layout or enabling other options to switch between them caused XFree86 to print a warning at log in time about the configuration being too complex, and failing to enable the chosen set up. I thought I'd document this here, for the record. Version-Release number of selected component (if applicable): XFree86-4.3.0-59
I have the same issue, see this b.g.o entry: http://bugzilla.gnome.org/show_bug.cgi?id=136007 This is probably also related to rh #114718. It would be good if this could be fixed before the final fc2, as this really makes it impossible to enter texts in more than one language.
This bug is closed - does this mean XFree in Fedora is patched to handle the layout combinations which original XFree 4.3 fails to use? It is known bug in 4.3 (fixed short after its release).
Nope, this is still an issue at least as of 4.3.0-62, which is the latest update in fc2 devel. This really should be reopened and fixed, especially if it's a known issue with a patch available (according to Sergey, the author). It should probably be marked as a blocker for the release bug, as it's definitely one of those things that has a potential to make lots of people unhappy.
Hi guys, I just reviewed the bugzilla bug history for this issue, and Alexandre seems to have opened the bug, and then closed it NOTABUG immediately, so I never saw the issue reported. This issue is new to me, however some people indicate that it is fixed in XFree86 4.4.0. If anyone has a rough idea of when it was fixed, that may help to get the fix out there for testing sooner. In the near future I will be putting X.org X11 into Fedora Core development tree, hopefully prior to test2, and so if this problem was fixed in XFree86 4.4.0, it should also be fixed in the X.org tree, assuming the fix is not included in under the new licensing scheme. One thing I don't quite understand, is wether this was also a bug in Fedora Core 1, Red Hat Linux 9, and Red Hat Enterprise Linux 3 as well. If anyone can confirm wether this problem exists under any of those OS releases as well, that would be useful. Thanks in advance!
Also, could someone please attach the log file that contains this message, so that I can search through the source tree to find it? Thanks again.
*** Bug 114718 has been marked as a duplicate of this bug. ***
Including a comment from the GNOME bugzilla, as it should be useful in reproducing: ------- Additional Comments From Sergey V. Oudaltsov 2004-03-04 18:59 ------- So, this is exactly what message says. The infamous bug in XFree. We really can do nothing about it. The patch should be applied (the code was fixed in XFree CVS long long ago). If you don't believe me, just try this: setxkbmap -layout "us,ca_enhanced(basic)" It will not pass. Just remove american layout - and it will be ok again. Really sorry.
Mike: rh9 and fc1 are using a different keyboard swithching mechanism, so this bug never really surfaced before. Gnome 2.6 has a new keyboard switcher, which relies on certain features of X to try to do things intelligently, and as a result it makes this bug very apparent. Not sure if this is fixed in the X.org tree, but I guess if it gets pushed into devel, I'll find out within a day or two. :)
Ah, I didn't realize that. That is sure to be useful information, thanks.
Well, xorg-x11 doesn't fix the problem. :( -- Error activating XKB configuration. Probably internal X server problem. X server version data: The X.Org Foundation, Inc 40399902 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 -- icon@hagrid:[~]$ xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "xfree86", "pc105", "us,ru", ",", "" icon@hagrid:[~]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [us,ru,ca_enhanced] model = pc105 overrideSettings = false options = [] This really needs to be fixed before the release, as otherwise the bitching and moaning will never cease. Sergey: Do you know the exact patch that fixes this behavior?
X.org X11 is almost exactly the same as XFree86 4.4.0, so if this was really fixed shortly after 4.3.0, then it should also be fixed in XFree86 4.4.0 and X.org X11. It isn't clear to me where or when this bug was allegedly fixed, so if someone knows for sure that it really was fixed, please indicate where/when. That will help to expediate closure of this issue. Thanks in advance.
Okay, let's hope Sergey can shed some light on this issue, since the new keyboard switcher is his baby.
http://cvsweb.xfree86.org/cvsweb/xc/programs/xkbcomp/symbols.c See Revision 3.15. This should be it IIRC. At least give it a try please. If not - I'll ask Ivan directly, since it was him who committed this code in XFree
Just looked in the xorg-x11 code, and this patch is definitely in: if ((key->actsDefined & 1) && key->acts[0]) { key->acts[i]= uTypedCalloc(width, XkbAction); if (key->acts[i] == NULL) continue; memcpy((void *) key->acts[i], (void *) key->acts[0], width * sizeof(XkbAction)); key->actsDefined |= 1 << i; } if ((key->symsDefined & 1) && key->syms[0]) { key->syms[i]= uTypedCalloc(width, KeySym); if (key->syms[i] == NULL) continue; memcpy((void *) key->syms[i], (void *) key->syms[0], width * sizeof(KeySym)); key->symsDefined |= 1 << i; } In fact, the file in the XFree86's cvs is nearly identical to the file in Xorg: icon@hagrid:[~/work/rpmbuild/BUILD/xorg-x11-0.0.6.6/xc/programs/xkbcomp]$ diff -u ~/symbols.c symbols.c --- /home/einstein/staff/icon/symbols.c 2004-03-18 10:48:28.251395448 -0500 +++ symbols.c 2004-03-04 12:49:08.000000000 -0500 @@ -24,7 +24,7 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/programs/xkbcomp/symbols.c,v 3.16 2003/10/31 14:32:04 pascal Exp $ */ +/* $XFree86: xc/programs/xkbcomp/symbols.c,v 3.15 2003/04/19 12:25:31 pascal Exp $ */ #include "xkbcomp.h" #include "tokens.h" Which is in itself a little weird, since revision 3.16 contains some more stuff. Maybe I'm missing something.
Oops. Then, I am stuck. Anyway, I am 101% sure is it a bug in XFree (it is easy to prove - just try setting same layout using setxkbmap utility. But I now I am not sure it was finally fixed by Ivan, sry. I am sending him link to this discussion.
For quick tests: icon@hagrid:[~]$ setxkbmap -layout "ca_enhanced" icon@hagrid:[~]$ setxkbmap -layout "us" icon@hagrid:[~]$ setxkbmap -layout "us,ru" icon@hagrid:[~]$ setxkbmap -layout "us,ca_enhanced" Error loading new keyboard description icon@hagrid:[~]$ setxkbmap -layout "ca" icon@hagrid:[~]$ setxkbmap -layout "us,ca" Error loading new keyboard description icon@hagrid:[~]$ setxkbmap -layout "us,ru,fr" icon@hagrid:[~]$ setxkbmap -layout "us,de,fr" icon@hagrid:[~]$ setxkbmap -layout "ca,ru" Error loading new keyboard description It looks like it just doesn't like Canadians. :) When used standalone, "ca*" works, but when you mix it with anything, it breaks.
> It looks like it just doesn't like Canadians. :) When used standalone, "ca*" works, but when you mix it with anything, it breaks. You are right, absolutely. The layouts "ca*" can be used standalone only. The thing is that those keymaps are very complex themselvs. They use up to five symbols per key and I just had not good idea how to put so many keysyms in a single group. Of course, I could do it somehow but it doesn't mean such map were something Canadian users are used to.
Well, I can tell you that everyone in Québec, parts of Nova Scotia, Newfoundland, and other places (admittedly not very populated) aren't going to be able to switch between the Canadian layout and any other. I mean, I personally need to be able to switch between us, ca, and ru, and there's no way to do it with the new keyboard switcher. Is Canadian layout the only one that uses complex keymaps? I would be surprised if it's the only one, and if there are others, this will be a recurring tune in the bug reports.
New keyboard switched has nothing to do with it, really:). It just exposes what's available from XFree. Can you configure the set of layouts you want in plain XF86Config? Or using setxkbmap? If you are not happy, you can offer some patch (simplification) to Canadian layout - I hope Ivan would be able to commit it, if it is reasonable enough. In a word, could you please offer some viable solution to the problem?
Well, the best solution is to be able to mix any layout available in kb switcher with any other, but I understand if this is not possible because of limitations in X (I would then suggest making the error dialog a little more descriptive to the user -- like "some layouts cannot be mixed with others because of complexity" or somesuch). I can personally cope -- instead of using the canadian layout, I can use the international one that should still allow me to enter all the necessary accents. However, it would be nice to see this fixed in X, so this problem doesn't arise for other people in the future. Is there any way to make xkb happy with lots of symbols per key?
"I would then suggest making the error dialog a little more descriptive to the user" Well, I'd be happy. The only thing is that there are various reasons why the keyboard layout cannot be activated - and various workarounds, checks, .... And if I list them all - GNOME will get the message box 1280x1024. HIG guardians would eat me alive, without salt. Even the current variant is a bit too lengthy.
> Is Canadian layout the only one that uses complex keymaps? I would be surprised if it's the only one, and if there are others, this will be a recurring tune in the bug reports No. There are two ones. :) The Canadian layout itself because it combines English and French and the second one is Mongolian that includes both cyrillic and latin alphabets. >I can personally cope -- instead of using the canadian layout, I can use the international one that should still allow me to enter all the necessary accents. Well, it could be a solution. BTW, can't you use something like us,fr,ru with Canadian keyboard? If 'fr' keymap doesn't fit Canadian keyboard key labels we could make a special variant fr(canadian). Or could it be a solution to split Canadian layout into two sublayouts like ca(basic) and ca(fr)? Of course in this case one has to choose both sublayouts explicitly. > Is there any way to make xkb happy with lots of symbols per key? XKB itself supports up to 64 symbols per key in a single layout. But to access them all you need a lot of modifiers, whereas all of them (eight bits) are already used for Shift, Ctrl, Alt, NumLock, AltGr, etc.
I'm surprised that US(international) can be mixed with others, though -- it's got symbols hanging on every modifier. AltChar, AltChar+Shift, etc. Is it really less complex than French-Canadian? French proper is very different from French Canadian. Québec is still qwerty with a few symbols remapped (such as "/"->"é", etc), while French is azerty, with everything else being more or less impossible to find for someone not used to the layout. What are the complexities in "ca*" that prevent it from working?
Try running gnome-keyboard-layout. As much as the old layout switcher sucks, it's still enables you to use an arbitrary set of keyboard layouts and switch between them with hot keys. Unfortunately, it seems to be somewhat incompatible with the current keyboard layout applet, to the point that the old one is not even listed as an applet any more :-( I'm not sure it even works, but you can start it by running gnome-keyboard-layout (!= gnome-keyboard-properties).
Okay, I will try it out. Unrelated (well, sorta related), it seems like all us_intl layouts in X are incorrect. For key 48 (apostrophe-quotedbl) it lists almost everywhere this order: dead_acute, dead_diaeresis, apostrophe(with AltChar), quotedbl(with AltChar+Shift). The correct order is: apostrophe quotedbl dead_acute dead_diaeresis You can verify here, for example: http://www.csbsju.edu/mcl/resource/Use%20Int%20Keyboard.pdf The chart clearly shows that dead_acute and dead_diaeresis are supposed to be invoked with AltChar and AltChar-Shift. Can this be patched in X?
There is even simpler way. Assigning "setxkbmap ..." shortcuts in metacity - and even should be compatible with the current keyboard capplet. But this way (same as good old gnome 2.4 way) reconfigures the whole xkb each time.
Hmm... I'd file the us_intl layout problem separately, but I don't know where to file. Is there a xorg-x11 bugzilla or something like this? Anyone knows?
Filed a separate bug about us_intl: http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=365
> I'm surprised that US(international) can be mixed with others, though -- it's got symbols hanging on every modifier. AltChar, AltChar+Shift, etc. Is it really less complex than French-Canadian? Yes. You didn't mention all combinations of modifiers but there are four only: none, Shift, AltGr, AltGr+Shift i.e. US international in spite of its seeming complexity has up to four symbols per key and needs two modifiers (for selection among them)only. But ca* keymaps have up to five symbols and that additional symbols requires an additional modifier. BTW, I looked over Canadian keymaps MS Windows offers. There are three such maps: Canadian French (Legacy), Canadian French and Canadian Multilingual. Two French ones are not more complex then other national layouts and only last one (Multilingual) is really big. It uses Right Control key (except AltGr and Shift) for switching between layers. I can make two Canadian French keymaps quickly. The real issue is the multilingual variant only. I'd like to ask again about an approach where this map is splitted to 'Canadian Multilingual (Part I)' and 'Canadian Multilingual (Part II)'. Could it be a solution? > French proper is very different from French Canadian. It's enough. :) > Québec is still qwerty with a few symbols remapped (such as "/"- >"é", etc), while French is azerty, with everything else being more or less impossible to find for someone not used to the layout. Thanks for explaination. I forgot about qwerty/qwertz/azerty difference. > What are the complexities in "ca*" that prevent it from working? Too many symbols per key. Actually I'm still thinking about this issue. But I don't promisse something now. > Filed a separate bug about us_intl: > http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=365 Answered there.
> I can make two Canadian French keymaps quickly. The real issue is > the multilingual variant only. I'd like to ask again about an > approach where this map is splitted to 'Canadian Multilingual (Part > I)' and 'Canadian Multilingual (Part II)'. Could it be a solution? Sure. In fact, in my daily use I only go as far as using AltGr for accessing some very rare keys (most notably "@"), so I'm surprised that there is a fifth-level modifier. Check out: http://www.autoroute.gouv.qc.ca/publica/clavier/clavier-complet.htm This is *the* official Québec layout, and it seems that it's all 4-levels only max. If this is implemented as the "Québec" layout, this should make most everyone happy. Me for certain. :)
Hm.. Okay, never mind, I apparently missed some fifth-level symbols there. I've never used them, clearly. :) I think splitting the layouts into "sane" and "complete" would be fine, if accommodating all 5 levels would be too difficult.
Is there any hope to have this bug solved for fc2 test3 in a few days. This bug is really show stopper for French canadians. I also tried to put back "us" keyboard but get the following message: /usr/X11R6/bin/setxkbmap -layout "us" Couldn't find rules file (xfree86)
Well, if you use *just* "ca" (or "ca_enhanced") you're fine. It's when you mix it with other charsets that it isn't. The second error you are seeing is actually unrelated -- it has to do with the fact that XFree86 went away and became Xorg. Did you just install, or upgraded to devel from test2? If the former, then you should file a separate bug, but just upgrading from test2 will cause this to occur, because your /etc/X11/XF86Config will have the following set for your keyboard rules: Option "XkbRules" "xfree86" which is a holdover from the test2 install. You need to manually change it to: Option "XkbRules" "xorg"
Philippe: it looks like another bug in xorg server - setxkbmap should use the default rules file "xorg" insead of "xfree86".
Your X server config file contains the line: Option "XkbRules" "xfree86" Remove that line by hand, restart the X server, and setxkbmap will use the correct Xkb rules file, which it queries from the X server. The X server has a built in XkbRules default of "xorg". That issue is addressed in bug #121016 The bug isn't an X server nor setxkbmap bug. It's a misconfiguration caused by the config tool forcing the above XkbRules option into the config file unnecessarily. The config tool (system-config-display, and pyxf86config) has been updated to not do that now. Users who have the option in their config file still need to either remove it, or rerun the new config tool however, or the problem will persist.
The French Canadian keyboard layout can not be used along with other keyboard layouts due to the complexities described by Ivan Pascal in comment #17 above. Ivan and Sergey are the upstream experts of this area, and claim the problem is not easily resolveable, so there is nothing that we can do about this issue. Setting status to "WONTFIX", however if the issue does become resolved in the upstream sources in a future X.Org release, then it will get included also in a future Fedora Core OS release.
> The French Canadian keyboard layout can not be used along with other keyboard layouts due to the complexities described by Ivan Pascal in comment #17 above. I'm sorry. I didn't report here that I realised the solution (at least a partial one) I offered in comment #22. The needed changes are made in the current XFree86 and XKeyboardConfig project. (But absent in XOrg source tree.) The 'Canadian Mutilingual' layout is splitted to two layouts ca(multi) and ca(milti-2gr). But there are some other tricks in XKB rules. If one specifies ca layout alone (e.g. "XkbLayout" "ca"), XKB implicitly merges both sub-layouts and a user gets a complete Canadian Multilingual layout. If 'ca' is specified in a mix with other layouts (e.g. "XkbLayout" "ca,ru,el"), XKB includes into the complete keymap another variant of Canadian layout, namely Canadian French that is simplier 'one-layer' layout and can be easy combined with other national layouts. And the most complex case is when a user wants the _real_ Canadian Multilingual layout combined with some other layouts. But even in this case there is a way. Both parts of Canadian Multilingual should be specified explicitly, like: "XkbLayout" "ca(multi),ca(multi-2gr),ru,el" (Of course if someone uses only "basic" part of Multilingual he can omit 'multi-2gr' sub-layout). I hope it is a satisfactory solution.
Neat! I look forward to trying it out in FC3. Thanks!
Ivan: Thanks for the update. This sounds like a reasonable way of solving the problem I believe. Are there plans on integrating this into the X.Org tree in the future? Konstantin: Ivan indicated it is not currently in the X.Org code, and so it's also not in FC3 at this stage. Once it is present in X.Org CVS however, our X team will review it for consideration for FC3. FC3 freezes on Oct 20, 2004 however, so there's not much time left. It's more likely that this will be present in FC4 with X.Org 6.9.0 or whatever the next X.Org release ends up becoming. Thanks again for the update Ivan!
Aw. Well, it's ok. I rigged up my own little switcher that ties to metacity and bypasses the problem of ca-cannot-exist-with-anyone-else. However, I'm looking forward to eventually being able to use the gnome keyboard applet again. :) Thanks for everyone's help.
Regarding the integration process: There is a plan to use xkeyboard-config as a part of the upcoming XOrg release. Being modular, this release will most probably include xkeyboard-config as one of the modules. Regarding Fedora plans - it is better to ask Mike directly. AFAIR Mike told me he was planning to use xkeybard-config in FC4.
We'd very much like to use a modular Xorg for FC4, including xkeyboard-config. Hopefully X.Org will move in this direction for the next X.Org release. In lieu of that however, we will modularize some things ourselves if the next X.Org release has not yet modularized officially. Either way, I'd like to see the modular xkeyboard-config get into FC4 personally. We'll be discussing that during FC4 planning once FC3 is released. Stay tuned... ;)