works just fine over here

Works for me now too. Maybe it was a configuration error, or a related bug fix.

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.

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?

aha! i bet i know what this is.

sergey, can we get shift to be shift on all four/eight levels?

> sergey, can we get shift to be shift on all four/eight levels?

Ghm, I think we could try..

*** Bug 7439 has been marked as a duplicate of this bug. ***

Any progress on this?

If you think you have a patch/fix, and need testers, I'd be happy to help...

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?

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.

Daniel, do you have better ideas on how to make shift work on all levels?

This bug is surely related to BZ7674.
Does everything work fine when adding lv3:ralt_switch option?

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.

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.

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.

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.

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...

It looks like a bug in xorg, I'd say... If it does not send that notification on the configuration change.

(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.

Is it still an issue with the latest xorg?

Created attachment 23330 [details]
Output of xkbcomp -xkb :0

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

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 (°).

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.

-- 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.