Remove *.dir generation It's only used by the X server's ListComponents call, which I intend to stub out shortly. (For bonus points, that call will fork xkbcomp to generate the necessary listings itself if it can't find the *.dir files.) Signed-off-by: Daniel Stone <daniel@fooishbar.org>
symbols: ossmath is CTRL+ALT, not FOUR_LEVEL (#43541) having KPMU defined as FOUR_LEVEL, with 4 symbols only, triggers an xkb error when the keypad stuff picks up the CTRL+ALT (from x11) and waits for 5 symbols instead. X.Org Bug 43541 <http://bugs.freedesktop.org/show_bug.cgi?id=43541> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Remove redundant `include' in definition of xkb_symbols "alt-intl-unicode" The definition of: xkb_symbols "alt-intl-unicode" contains: include "level3(ralt_switch)" However, it also contains: include "us(intl-unicode)" which in turn already contains: include "level3(ralt_switch)" Now, an argument can be made that it's more self-documenting to repeat the directive, but that seems like a fairly weak argument, especially given that most of "alt-intl-unicode" is inherited from "intl-unicode" anyway.
Remove extant reference to the `symbols/extras' directory The following command: setxkbmap -layout us -variant alt-intl-unicode was yielding this unhelpful error: Error loading new keyboard description": The reason is that the following commit: commit f836c210a4e4007715b149d4736a447c56b7cbaa Author: Sergey V. Udaltsov <svu@gnome.org> Date: Wed Mar 2 23:56:25 2011 +0000 The extra symbols are merged back into the base files The rules are not powerful enough to support the extras subdir. So the variants are merged into "main" files. From now on, the "extra" term only affects the directory: whether the record is in base.xml.in or base.extras.xml.in removed the `symbols/extras' directory, but accidentally left a reference to it in the definition of xkb_symbols "alt-intl-unicode": include "extras/us(intl-unicode)"
Update FR OLPC layout Some keys have only two characters printed: the unmodified character, and a character in the Shift+AltGr position (upper right). For such keys, users were confused why the "other" character could not be accessed with AltGr alone. Make such keys behave shift-invariant to remove this confusion. Also add some obvious omissions from the previous submission fixing various other keys that weren't working as printed. The corresponding keyboard can be seen here: http://wiki.laptop.org/go/OLPC_Azerty_Keyboard Investigation and original patch from Walter Bender. https://bugs.freedesktop.org/show_bug.cgi?id=50064