Bug 2871 - Different results for shift-altgr and altgr-shift.
Summary: Different results for shift-altgr and altgr-shift.
Status: RESOLVED MOVED
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: xkb
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
: 7439 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-03-31 08:08 UTC by Tim Hutt
Modified: 2018-12-28 00:46 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Output of xkbcomp -xkb :0 (49.84 KB, text/plain)
2009-02-26 11:03 UTC, Steve Fink
Details

Description Tim Hutt 2005-03-31 08:08:22 UTC
If I'm trying to type a shift-altgr character (for example shift-altgr-4 give 
¼) then I get different results depending on the order I press shift and altgr. 
 
Altgr then shift seems to give the expected results. Shift-altgr on the other 
hand does weird things. You have to press the third key twice to get any 
characters, and then if you keep shift and altgr down and press it a third time 
you get a different character. For example pressing shift-altgr-9 4 times 
gives: '[((' The first time does nothing. altgr-shift-9 gives: '±'. 
 
This surely isn't right is it? The keymap only lists 4 symbols: 
 
    key <AE09> { [         9,  parenleft, bracketright,    plusminus ] }; 
 
I assume this is   [ no modifiers, shift, altgr, shift-altgr ]. 
 
The first three work, and shift-altgr does the right thing but I would assume 
altgr-shift should do the same thing.
Comment 1 Daniel Stone 2006-04-02 10:50:55 UTC
works just fine over here
Comment 2 Tim Hutt 2006-04-02 21:56:45 UTC
Works for me now too. Maybe it was a configuration error, or a related bug fix.
Comment 3 Adrian Fita 2006-07-25 04:26:33 UTC
I have the exact same problem. I use Ubuntu 6.06 with the Romanian keyboard
layout. My "InputDevice" section in xorg.conf looks like this:

Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc104"
        Option          "XkbLayout"     "gb,ro"
        Option          "XkbVariant"  ",std"
        Option          "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll"
        Option          "AutoRepeat"    "250 30"
EndSection

Regardless of the layout that's currently active, when I press AltGr then Right
Shift (AltGr+Shift) I get the characters that I get when I press only AltGr
(this is incorrect). When I press Right Shift then AltGr (Shift+AltGr) I obtain
the characters that are configured for the forth level in the keymap (this is
correct).

For example, in the romanian layout, when I press AltGr+[, I obtain [; when I
press AltGr+Shift (AltGr then Shift), I obtain the same [, as if I only pressed
AltGr (I should have obtained {); when I press Shift+AltGr (Shift then Altgr) I
obtain { like it supposed to be.

I'm wondering why AltGr+Shift (AltGr then Shift) is not the same thing as
Shift+AltGR (Shift then AltGr). This is really annoying.
Comment 4 Adrian Fita 2006-07-25 04:54:46 UTC
I did some research using xev and here is what I have so far (don't know what to
make of it though... Hope it's usefull for someone.).

When I press Shift then AltGr:

KeyPress event, serial 26, synthetic NO, window 0x3800001, root 0x4c, subw 0x0,
time 2776635468, (551,473), root:(561,533), state 0x0, keycode 62 (keysym
0xffe2, Shift_R), same_screen YES, XLookupString gives 0 bytes: XmbLookupString
gives 0 bytes: XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x3800001, root 0x4c, subw 0x0,
time 2776636395, (551,472), root:(561,532), state 0x1, keycode 113 (keysym
0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes: XFilterEvent returns: False


When I press AltGr then Shift:

KeyPress event, serial 29, synthetic NO, window 0x3800001, root 0x4c, subw 0x0,
time 2776640728, (551,470), root:(561,530), state 0x0, keycode 113 (keysym
0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes: XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x3800001, root 0x4c, subw 0x0,
time 2776641687, (551,470), root:(561,530), state 0x80, keycode 62 (keysym 0x0,
NoSymbol), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0
bytes: XFilterEvent returns: False


The "keysym 0x0, NoSymbol" part really puzzles me... It should have been
ISO_Level3_Shift, like when I press Shift+AltGr, no?
Comment 5 Daniel Stone 2006-10-20 04:47:57 UTC
aha! i bet i know what this is.

sergey, can we get shift to be shift on all four/eight levels?
Comment 6 Sergey V. Udaltsov 2006-10-21 11:58:26 UTC
> sergey, can we get shift to be shift on all four/eight levels?

Ghm, I think we could try..

Comment 7 Daniel Stone 2006-11-03 19:56:54 UTC
*** Bug 7439 has been marked as a duplicate of this bug. ***
Comment 8 James Ralston 2007-01-04 15:48:09 UTC
Any progress on this?

If you think you have a patch/fix, and need testers, I'd be happy to help...
Comment 9 Sergey V. Udaltsov 2007-01-04 16:39:55 UTC
James, 
Sorry for delay.
Could you please replace LFSH and RTSH in symbols/pc with:
 key <LFSH> {        [ Shift_L, Shift_L, Shift_L, Shift_L ]       };
and
 key <RTSH> {        [ Shift_R, Shift_R, Shift_R, Shift_R ]       };
Will it work for you?
Comment 10 James Ralston 2007-04-05 08:43:42 UTC
After testing the code in comment 9 over the past few months, I have concluded that making the suggested changes to symbols/pc does not affect the behavior of the bug; it is still the case that for some instances of X servers, pressing Shift-Alt loses the Alt modifier.  I still can't figure out what the determining factor is.

I'm running the FC7 test on my laptop, so I'd be happy to test (more) alpha code/patches.
Comment 11 Sergey V. Udaltsov 2007-04-05 09:20:12 UTC
Daniel, do you have better ideas on how to make shift work on all levels?
Comment 12 Denis Barbier 2007-04-05 11:38:35 UTC
This bug is surely related to BZ7674.
Does everything work fine when adding lv3:ralt_switch option?
Comment 13 James Ralston 2007-04-05 15:13:18 UTC
Can I get away with just patching the installed files, or do I need to recompile?

Also, FYI: I rarely (if ever) use RAlt or LShift; I use almost exclusively RShift and LAlt.  E.g.: RShift-LAlt-@ (to set the mark in Emacs).  So, unless 
lv3:ralt_switch also affects the behavior of LAlt, I don't think these issues are related.
Comment 14 James Ralston 2007-07-03 14:04:09 UTC
Denis, can you elaborate on what you mean by, "Does everything work fine when adding lv3:ralt_switch option?"  This option is already present in some of the files in xkb/rules, so I'm not sure what I should add that too (if anything).

To recap, I'm trying to find a solution to bug 7439 ("keyboard state modifiers depend on keypress order"), which was closed as a dupe of this bug.  This has been an ongoing problem for more than a year.
Comment 15 Denis Barbier 2007-07-04 00:30:25 UTC
This option is present but not enabled for all layouts.  You may need to set
        Option  "XkbOptions"   "lv3:ralt_switch"
in your xorg.conf file.
Comment 16 James Ralston 2007-07-16 11:30:08 UTC
Changing the state of any of the "Third level choosers" options (including lv3:ralt_switch) corrects the Shift+Alt behavior.

And when I say "changing the state", I mean that literally.  Meaning, if I am experiencing the bug with Shift+Alt behavior, and I go to System -> Preferences -> Hardware -> Keyboard and click the "Layout Options" tab, I will see that none of the "Third level choosers" options is selected.  If I click (select) any of those options, xev reports the following X event:

MappingNotify event, serial 30, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

...and the Shift+Alt behavior is magically fixed.  But if I then deselect the option I just selected, the Shift+Alt behavior *stays* fixed.
  
This smells very much like a classic "memory allocated via malloc() is used without first being cleared" initialization bug.  This is the only reason I can think of why the behavior seems to vary randomly at server startup, and why simply *toggling* an option can "fix" the bug.
Comment 17 James Ralston 2007-11-08 13:56:26 UTC
As a follow-up to comment 16: changing the "Layout Options" values (System -> Preferences -> Hardware -> Keyboard) no longer sends the MappingNotify event that corrects the behavior:

MappingNotify event, serial 30, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

Could someone restore the MappingNotify event behavior, please?  That is the only way (other than restarting X) to work around this bug when it manifests...
Comment 18 Sergey V. Udaltsov 2007-11-08 14:00:33 UTC
It looks like a bug in xorg, I'd say... If it does not send that notification on the configuration change.
Comment 19 Simos Xenitellis 2008-02-03 06:09:52 UTC
(In reply to comment #18)
> It looks like a bug in xorg, I'd say... If it does not send that notification
> on the configuration change.
> 

I managed to "fix" this issue by changing the shortcut in Group Shift/Lock Behaviour to switch layouts from Alt-Shift to something else (Ctrl-Shift).
Could someone verify this?

Also, when I have three keyboard layouts (for example US Int, GB, Greek Polytonic; in this order appearing in Keyboard Layouts) and the shortcut to switch between them is Alt-Shift, then
1. when the first keyboard layout is selected (here US Int)
2. and I press Shift-AltGr (in this sequence)
3. the keyboard layout switches to the third layout (here Greek Polytonic).
In 3rd level choosers Ι have nothing selected.
Comment 20 Sergey V. Udaltsov 2008-11-26 15:59:27 UTC
Is it still an issue with the latest xorg?
Comment 21 Steve Fink 2009-02-26 11:03:33 UTC
Created attachment 23330 [details]
Output of xkbcomp -xkb :0
Comment 22 Steve Fink 2009-02-26 11:03:48 UTC
I am getting very similar behavior with Alt-Shift-5 (query-replace in Emacs). I see it in CentOS 5.2 running Xorg 1.1.1 as well as Fedora 10 running Xorg 1.5.3. It seems to happen more often than not. At least at the moment, Alt-Shift-5 gives me modifier 0x9 (good), Shift-Alt-5 gives me modifier 0x1 (bad). I hadn't realized that it was inconsistent; I thought that I was just being inconsistent about the order in which I pressed the keys. But thinking back, I *think* it's probably been working part of the time.

Most of the time it's borked, though.

This isn't exactly the same as the problem reported in this bug, although it is identical to bug 7439, which has been marked as a duplicate of this bug. And it seems like my and 7439's behavior is likelier to be a root cause than something to do with levels. (I think, not knowing what levels are.) There's also the downstream https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189518

Here's an erroneous Shift-Alt-5:

KeyPress event, serial 29, synthetic NO, window 0x4c00001,
    root 0x103, subw 0x0, time 3018940860, (59,154), root:(1744,203),
    state 0x1, keycode 14 (keysym 0x25, percent), same_screen YES,
    XLookupString gives 1 bytes: (25) "%"
    XmbLookupString gives 1 bytes: (25) "%"
    XFilterEvent returns: False
Comment 23 Drew 2017-10-04 01:26:48 UTC
It sounds like AltGr isn't AltGr for every shift level. If you look at the level3 file, a few of the AltGr definitions define the second shift level to be Meta_R or Multi_key in which case hitting shift before hitting AltGr would result in AltGr acting like either a meta or a compose key. Try hitting Shift+AltGr and then o+o and see if it produces a a degree symbol (°).
Comment 24 Kovács Viktor 2017-10-04 05:34:13 UTC
It depends on, which partial level3 combinations included in the given layout variant, and which character-combination can produce another character with multikey. The romanian layout file is in (under ubuntu) /usr/share/X11/symbols/ro. Be careful, modify the text required root rights. If you want to do not permanently, clone the xkeyboard-config git resource, modify, that you want, add a commit, and make a patch, upload to the relevant bug.
Comment 25 GitLab Migration User 2018-12-28 00:46:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/129.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.