the layout ca(multix) is broken

It looks like the upstream developers aren't quite sure how this would be properly fixed.

Well, according to that bug it is generally fixed - at least people tested and found it was ok for them.

Well, I'm a bit lost.
Using xkb-data 0.8-7ubuntu2 (edgy).

Let's me reformulate the problem, the right-ctrl key (the one
with a right-arrow on the multix keyboard), rathen than choosing
caracters to the right of each keys, choose the one written on the
front.

Using the notation in http://externe.net/clavier-normalise/touche.gif
right control (arrow toward right) gives level 3 rather than level 2a.

Manually switching between multi-part 1 and multi-part2 works,
but I would much prefer right-ctrl key to temporarily select
multi-part2.

Now, I found that /etc/X11/xkb/symbols/ca contains for multix
layout:
    include "level3(ralt_switch)"
    include "level5(rctrl_switch)"
which would seems ok, but in practice, rctrl seems to use level3
just like ralt.

Why, the rctrl seems to act like ralt then?

It is unclear to me if this problem is the same as the original poster.
Is it?

And things seems to be a bit diffferent than what appears on:
https://bugs.freedesktop.org/show_bug.cgi?id=4411, so...
Like now using F35 rather than F21 to select level5, but I don't
understand well these FNN keys.

Ok, I was finally able to fix my system by using info in
https://bugs.freedesktop.org/show_bug.cgi?id=4411

Well, I did hack directly the files in /etc/X11/xkb .
I am including compat/level5.diff here, and will
include symbols/level5.diff in next comment.

And now diff file for /etc/X11/xkb/symbols/level5.

I guess I should now download the source, and make REALs
patches if I want that to be included for edgy release.

I have included diff files made directly on /etc/X11/xkb/compat/level5 and to /etc/X11/xkb/symbols/level5 files.

But I should now download xkeyboard-config source, and make
a real patch. But since I am not used to this, can take time.

Ok, the following patch seems to work for me, making my
Right Control key work as expected. Somehow, a note should
be taken somewhere to remember to change hexadecimal to
meaningful names, when they will be in keysyms.h.

was made 'In progree' because I suggested a patch.
Now I think that Confirmed is better, because I have no access to apply my package, not being a developer.

In my keysymdef.h file, there are already definitions:

#define XK_ISO_Level5_Shift 0xfe11
#define XK_ISO_Level5_Latch 0xfe12
#define XK_ISO_Level5_Lock 0xfe13

Could you please try using these symbols? I am not putting these into xkeyboard-config yet in order not to break compatibility - but I'll make it soon. The solution with F33-F35 looks like a hack - so I think I will not put it into CVS.

I found this bug report while trying to get ISO_Level5_Shift working for a Berber/Tuareg keyboard i'm working on, and I think it is the same problem as I have (on Intrepid).

I have 'right control' set to generate ISO_Level5_Shift, just like the Canadian multilingual all-in-one layout.
With xev I can see the correct keysym 0xfe11 ISO_Level5_Shift. But pressing right control with keys does nothing (no level 5 shift), even though I have defined keysyms for all 8 levels.
I had the same problem on Hardy - the only difference was that the xkb files all had numbers (like 0xfe11) instead of keysym names.

For the French oss layout there are 2 bugs, 198759 and 208224, where people have found that right CTRL doesn't seem to do anything when it's mapped to ISO_Level5_Shift. Their workaround was a hack: to implement a new LOCAL_EIGHT_LEVEL type. This might be the same problem too.

To access my extra set of letters, I too could use a hack for the moment, based on the FOUR_LEVEL_PLUS_LOCK used by the German keyboard for capital sharp s.
But it would be cleaner to fix the bug and use a level 5 switch key instead of Caps Lock.

Possible cause:

ISO_Level3_Shift works perfectly so I configured right control to generate this instead of ISO_Level5_Shift. It worked fine just like AltGr.
So then I edited compat/level5 to switch or lock the LevelFive modifier according to an incoming ISO_Level3_Shift keysym. It worked fine - the compat apparatus saw the ISO_Level3_Shift keysym, made the correct interpretations, and the level 5 shift happened correctly for the Canadian layout.

Only ISO_Level3_Shift or 0xfe03 is seen by the compat part of xkb, not ISO_Level3_Lock/Latch, ISO_Level5_*, or several 0x type keysyms (including old F33 just in case) that I tried putting into compat/level5 to be 'interpret'ed.

Summary:

Some bug seems to be preventing keysyms that look fine on xev from being interpreted at compat/level5. Levels 5 and up can therefore never be accessed. Maybe there is a filter for control-like keysyms like meta, level3_shift etc, and Level5 was never included in it, or maybe a flag is missing on the keysym.

Can anyone else replicate my findings?

> Only ISO_Level3_Shift or 0xfe03 is seen by the compat part of xkb, not ISO_Level3_Lock/Latch, ISO_Level5_*,
Do you see the correct 'compat' part if you save your xkb configuration using "xkbcomp :0 -xkb out.xkb" - in the resulting out.xkb file?

Hi Sergey.

It seems OK, all the 'interpret' info is there - see the out.kbd below.

The only slightly odd thing is that some of the later ISO_Level5_ lines
come after a lot of other stuff, but the order of the dump probably
doesn't match the includes in compat/complete.

So the ISO_Level5_Shift keysym event somehow isn't being processed for
compat interprets? The config seems to be read in OK though.

Note that that I remapped Level3_Shift to set level 5, as I said in the
bug report, it's not any weirdness.

xkb_compatibility "complete" {

virtual_modifiers NumLock,Alt,LevelThree,LAlt,RAlt,RControl,LControl,ScrollLock,LevelFive,AltGr,Meta,Super,Hyper;

interpret.useModMapMods= AnyLevel;
interpret.repeat= False;
interpret.locking= False;
interpret ISO_Level2_Latch+Exactly(Shift) {
useModMapMods=level1;
action= LatchMods(modifiers=Shift,clearLocks,latchToLock);
};
interpret Shift_Lock+AnyOf(Shift+Lock) {
action= LockMods(modifiers=Shift);
};
interpret Num_Lock+AnyOf(all) {
virtualModifier= NumLock;
action= LockMods(modifiers=NumLock);
};
interpret ISO_Lock+AnyOf(all) {
action= ISOLock(modifiers=modMapMods,affect=all);
};
interpret ISO_Level3_Shift+AnyOf(all) {
virtualModifier= LevelFive;
useModMapMods=level1;
action= SetMods(modifiers=LevelFive,clearLocks);
};
interpret ISO_Level3_Latch+AnyOf(all) {
virtualModifier= LevelThree;
useModMapMods=level1;
action= LatchMods(modifiers=LevelThree,clearLocks,latchToLock);
};
interpret ISO_Level3_Lock+AnyOf(all) {
virtualModifier= LevelThree;
useModMapMods=level1;
action= LockMods(modifiers=LevelThree);
};
interpret Alt_L+AnyOf(all) {
virtualModifier= Alt;
action= SetMods(modifiers=modMapMods,clearLocks);
};
interpret Alt_R+AnyOf(all) {
virtualModifier= Alt;
action= SetMods(modifiers=modMapMods,clearLocks);
};
interpret Meta_L+AnyOf(all) {
virtualModifier= Meta;
action= SetMods(modifiers=modMapMods,clearLocks);
};
interpret Meta_R+AnyOf(all) {
virtualModifier= Meta;
action= SetMods(modifiers=modMapMods,clearLocks);
};
interpret Super_L+AnyOf(all) {
virtualModifier= Super;
action= SetMods(modifiers=modMapMods,clearLocks);
};
interpret Super_R+AnyOf(all) {
virtualModifier= Super;
action= SetMods(modifiers=modMapMods,clearLocks);
};
interpret Hyper_L+AnyOf(all) {
virtualModifier= Hyper;
action= SetMods(modifiers=modMapMods,clearLocks);
};
interpret Hyper_R+AnyOf(all) {
virtualModifier= Hyper;
action= SetMods(modifiers=modMapMods,clearLocks);
};
interpret Scroll_Lock+AnyOf(all) {
virtualModifier= ScrollLock;
action= LockMods(modifiers=modMapMods);
};
interpret ISO_Level5_Shift+AnyOf(all) {
virtualModifier= LevelFive;
useModMapMods=level1;
action= SetMods(modifiers=LevelFive,clearLocks);
};
interpret ISO_Level5_Latch+AnyOf(all) {
virtualModifier= LevelFive;
action= LatchMods(modifiers=LevelFive,clearLocks,latchToLock);
};
interpret ISO_Level5_Lock+AnyOf(all) {
virtualModifier= LevelFive;
action= LockMods(modifiers=LevelFive);
};
interpret Mode_switch+AnyOfOrNone(all) {
virtualModifier= AltGr;
useModMapMods=level1;
action= SetGroup(group=+1);
};
interpret ISO_Level3_Shift+AnyOfOrNone(all) {
action= SetMods(modifiers=LevelFive,clearLocks);
};
interpret ISO_Level3_Latch+AnyOfOrNone(all) {
action= LatchMods(mod...

The way you described it - it looks like an issue with XKB code in xorg. I do not see any trouble in your config.

OK. It's now in freedesktop.org's bugzilla under xorg, input/keyboard.

http://bugs.freedesktop.org/show_bug.cgi?id=19311

This bug has been around a while. I've not studied the complete comment list in totality, but I get the impression that the original issue is long since resolved, and recent discussion feels like it's covering a somewhat different issue which really ought to be handled as a separate bug report - since it's already upstreamed (thanks) that's probably sufficient.

So I'm going to close this out. If there *is* some additional work needed, please file new bug reports for the issues. Following the work here would probably be too tedious due to the lengthy comment history.