Bug#270235: xserver-xfree86: ALT+SHIFT keys have to be pushed in *exact* order to get int chars

[barbier@linuxfr.org (Denis Barbier)]

tags 270235 - l10n
thanks

On Mon, Sep 06, 2004 at 11:46:39AM +0200, Bartosz Fenski aka fEnIo wrote:
> Package: xserver-xfree86
> Version: 4.3.0.dfsg.1-6
> Severity: normal
> Tags: l10n
> 
> Hello.
> 
> Seems that keyboard driver is somehow broken.
> To get Polish international uppercase character I have to push
> 
> ALT | SHIFT | Z/X/C/E/L/O/N/A
> 
> Exactly at this order.
> Pushing:
> 
> SHIFT | ALT | Z/X/C/E/L/O/N/A
> 
> doesn't work for me. That can be easily reproduced cause many friends of
> mine checked it too, and they got the same results. 
> 
> That's quite weird. Should work with every order.
> I checked it with both keyboard and kbd driver. 

You are right, the problem is that Alt_R is defined by
  key <RALT> {
      type[Group1]="TWO_LEVEL",
      symbols[Group1] = [ ISO_Level3_Shift, Multi_key ]
  };

So when you press Alt_R, ISO_Level3_Shift is returned, then Shift+A
returns the 4th column, ie. Aogonek.
When Shift is pressed first, Alt_R expands to Multi_key, and XKB is
then waiting for a compose sequence beginning with lower 'a'.

This has been fixed for pl and pl2 keymaps in XFree86 and freedesktop,
but it should be fixed for all keymaps with 4 columns.

The fix is to replace
  include "level3(ralt_switch_multikey)"
by
  include "level3(ralt_switch)"
in /etc/X11/xkb/symbols/pc/pl{,2} and Multi_key can be redefined via
the 'compose:*' options.

I will send a patch to the BTS soon.

Denis