Yes, xkb was very shitty last years, now sucks bit less:
Option "XkbLayout" "us+cz:2+inet6720+group(switch)+group(shifts_toggle)"
So I have us keyboard as group 1, czech keyboard as group 2,
inet6720 defines additional keys on my usb keyboard, group(switch) changes
AltGr to group modifier, and group(shifts_toggle) makes press of both
shifts to be inerpreted as group-lock. Also I use xkbvleds swallowed by
statusbar (as tray application) to indicate status of group-lock and
all three standard locks. - my notebook doesn't have keyboard leds and also
it is more comfortable to have the leds in front of my head instead of
"below fingers".
Speaking about the additional keys: I have some bindings in ion, and after
last upgrade of Xorg/debian it complains it does not know the keysyms like
XF86WWW and so on (these I map in inet6720 file). But it complains only
when X is is started. Later, when restarted it founds these keysyms. I did
not searched what the xorg did fu**ed up, so if anybody knows...
Dne 28 Květen 2008, 13:23, Tuomo Valkonen napsal(a):
> On 2008-05-27 09:45 +0000, Tuomo Valkonen wrote:
>
>> On further inspection, standard Mode_Switch also seems to
>> set the state mask 0x2000, but it is typically non-locking, so there's no
>> problem. We certainly should not ignore a non-locking Mode_Switch bit
>> (typically AltGr in non-braindead
>> xmodmap user-customisable keymaps). Perhaps the only solution is
>> configurability of locking mods. (Or does Xkb offer that info? In any
>> case I CBA.)
>
> Another strange thing is that ISO_Level3_Shit does not set
> a special "group" bit. Rather, to even remotely emulate appearing to
> work^1, it seems to depend on being mapped to _some_ modifier. I suppose
> Xlib then uses Dirty Hacks to check whether modifiers
> are mapped to that key specifically.
>
> ---
>
>
> ^1 My keymap depends heavily on remapping of AltGr, traditionally mapped
> as Mode_Switch, configurable in the third and fourth fields of xmodmap
> keycode lines. Xkb keymaps killed that user configurability, by switching
> to ISO_Level3_Shit not accessible with xmodmap at that time -- and not as
> conveniently as Mode_Switch even now, plus ISO_Level3_Shit+j and a few
> other keys also don't work at all. (No, it's not keyboard hardware
> crappiness; the same keycombo as Mode_Switch+j works.) I therefore use a
> full custom .Xmodmap stored from pre-Xkb X. (Xkb isn't user-configurable;
> its keymaps are essential program source code, as are fontconfig's XML
> crap and udev's properietary shit. They're not configuration files,
> they're source code meant for developers only.)
>
> As for my keymap, as it might be of some interest:
>
>
> The mostly useless caps lock has of course become a control key.
> Tilde and caret have swapped the shift modifier from standard
> .fi layout. The _very_ conveniently placed altgr (=Mode_Switch)
> right of left shift has <>| (plain, shift, altgr) on it in the standard
> layout, whereas the standard altgr is right of spacebar, which makes for
> very cumbersome combos for braces etc. found in the number row of the
> altgr map. That row of my altgr map along with the euro sign and the two
> accents on the right are standard (in the X map; some of the keys are not
> printed on the layouts), the rest are my additions. (The key left of right
> shift is n-dash, quite undistinguishable from a short dash in a
> fixed-width font.)
>
> plain
>
> § 1 2 3 4 5 6 7 8 9 0 + ´ bsp
> tab q w e r t y u i o p ? ~ ent ctrl a s d f g h j k l ö ä
> ' er
> lshift altgr z x c v b n m , . - rshift
>
> shift
>
> ? ! " # ¤ % & / ( ) = ? ` bsp
> tab Q W E R T Y U I O P ? ^ ent ctrl A S D F G H J K L Ö Ä
> * er
> lshift altgr Z X C V B N M ; : _ rshift
>
> altgr (= Mode_Switch)
>
> ? ? @ ? $ ? ? { [ ] } \ ¸ bsp
> tab ? [ ] ¨ ent ctrl < | > { } ( ) \
> ´ er
> lshift altgr ? ? ? ? ? ? rshift
>
>
> --
> Tuomo
>
>
>
--
Tomas Ebenlendr
http://drak.ucw.cz/~ebik
