Right Alt not working reliably as compose key unless the layout in effect is first in the list of sources

Hi Steve,

Can you please let us know the output of this command:

gsettings get org.gnome.desktop.input-sources xkb-options

when your settings combo gives you the reported xev output for Right Alt.

The output is:

$ gsettings get org.gnome.desktop.input-sources xkb-options
['lv3:ralt_alt', 'grp:alts_toggle', 'altwin:menu', 'compose:ralt']
$

not sure what 'ralt_alt' means as opposed to 'ralt', but this is at least consistent with the fact that the key is stuck as AltGr instead of Compose.

If I select 'Right Alt' for 'Alternate Characters Key', the gsettings value changes to 'lv3:ralt_switch'. If I select any other option, it shows 'ralt_alt', and the UI shows 'Alternate Characters Key': 'None'.

Was able to force the Compose key to work by running the following command:

gsettings set org.gnome.desktop.input-sources xkb-options "['altwin:menu', 'compose:ralt', 'lv3:none']"

seems impossible to get to this configuration via the UI.

Is 'lv3:none' a valid XKB option?

I can't reproduce your problem on my jammy. Even if I set "Alternate Characters Key" to "Right Alt" in Settings, the 'compose:ralt' option overrides it and RightAlt/AltGr works as a compose key. That's true also if I use the Swedish layout, which — unlike the basic us layout — sets 'lv3:ralt_switch' by default in the background.

More questions:

1. Which keyboard layout are you using?

2. What happens if you drop the 'lv3:none' option, so you only have:
['altwin:menu', 'compose:ralt']

? While you need to set 'altwin:menu' elsewhere (Tweaks?), setting 'compose:ralt' can be accomplished from Settings:

* Disable "Alternate Characters Key" by switching to "Use layout default"

* Select "Right Alt" for "Compose Key"

On Tue, Apr 19, 2022 at 06:42:15AM -0000, Gunnar Hjalmarsson wrote:
> Is 'lv3:none' a valid XKB option?

I have no idea. But until I set it, I was seeing conflicting lv3 options.

> I can't reproduce your problem on my jammy. Even if I set "Alternate
> Characters Key" to "Right Alt" in Settings, the 'compose:ralt' option
> overrides it and RightAlt/AltGr works as a compose key. That's true also
> if I use the Swedish layout, which — unlike the basic us layout — sets
> 'lv3:ralt_switch' by default in the background.

> More questions:

> 1. Which keyboard layout are you using?

English (Dvorak, alt. intl.)

> 2. What happens if you drop the 'lv3:none' option, so you only have:
> ['altwin:menu', 'compose:ralt']

This works.

> ? While you need to set 'altwin:menu' elsewhere (Tweaks?), setting
> 'compose:ralt' can be accomplished from Settings:

> * Disable "Alternate Characters Key" by switching to "Use layout
> default"

> * Select "Right Alt" for "Compose Key"

That was not the behavior here. *Now*, toggling Alternate Characters Key is
not having any effect; but previously, choosing 'Use layout default' was
giving me lv3:ralt_alt, lv3:switch.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
<email address hidden> <email address hidden>

>> 1. Which keyboard layout are you using?
>
> English (Dvorak, alt. intl.)

There is something with that layout. With that enabled I can reproduce the problem. Both on jammy and impish.

>> 2. What happens if you drop the 'lv3:none' option, so you only have:
>> ['altwin:menu', 'compose:ralt']
>
> This works.

It doesn't work for me with the "English (Dvorak, alt. intl.)" layout. Unlike when using for instance the Swedish or "English (US, intl., with dead keys)" layout, 'compose:ralt' does not override the layout's default definition of "Right Alt" as the 3rd level key. Can it be some kind of race condition?

So it seems to be the combination of Right Alt as compose key and the English (Dvorak, alt. intl.) layout which does not work. I changed the bug title accordingly.

And AFAICT gnome-control-center sets the expected XKB options, so it's not a g-c-c bug. Maybe an xkeyboard-config bug.

@Steve: Are we agreed on this problem description?

> And AFAICT gnome-control-center sets the expected XKB options,
> so it's not a g-c-c bug. Maybe an xkeyboard-config bug.

From my initial bug report:

Setting Alternate Characters Key to None, and moving the Compose Key setting around between different options (and then back to Right Alt), the behavior of the Right Alt key is still AltGr and not Compose.

So no, gnome-control-center was not setting the expected XKB options either.

I concluded that the description was related to the use of the us+dvorak-alt-intl layout, and not to g-c-c setting incorrect options. Observations from use of the us+intl layout:

Alternate Characters Key to None
--------------------------------
$ gsettings get org.gnome.desktop.input-sources xkb-options
['lv3:ralt_alt']

Right Alt according to xev: Alt_R

Alternate Characters Key to None + Compose key to Right Ctrl
------------------------------------------------------------
$ gsettings get org.gnome.desktop.input-sources xkb-options
['lv3:ralt_alt', 'compose:rctrl']

Right Alt according to xev: Alt_R
Right Ctrl according to xev: Multi_key

Alternate Charters Key to None + Compose key to Right Alt
---------------------------------------------------------
$ gsettings get org.gnome.desktop.input-sources xkb-options
['lv3:ralt_alt', 'compose:ralt']

Right Alt according to xev: Multi_key

I see only expected options and expected results. So please elaborate on how you think that g-c-c behaves incorrectly, preferably with a reproducible use case.

On Wed, Apr 20, 2022 at 03:58:40AM -0000, Gunnar Hjalmarsson wrote:
> Alternate Charters Key to None + Compose key to Right Alt
> ---------------------------------------------------------
> $ gsettings get org.gnome.desktop.input-sources xkb-options
> ['lv3:ralt_alt', 'compose:ralt']

> Right Alt according to xev: Multi_key

xev also returns Multi_key for me here, but it doesn't actually *work* as a
compose key with the above values. The lv3:ralt_alt conflicts in some
fashion and only when I remove it from the settings do I get Compose key
functionality.

So if your assertion is that the gsettings values are correct and it's a bug
in how xkeyboard-config interprets/applies those settings, then it's not a
bug in gnome-control-center. However if this is a wrong setting to be set
in gsettings, it's a gnome-control-center bug.

Now I have tested a bit more back and forth, and here is a new attempt to describe the nature of the issue:

Whether Right Alt works as the compose key or not depends mostly on where in the list of input sources the keyboard layout in effect is present.

If the layout in effect is the first one in the list, Right Alt works fine as compose key. This is true whether Alternate Characters Key is switched off or set to "None". (No problem with "English (Dvorak, alt., intl.)" either, in other words, if that layout is first in the list of input sources.)

If the layout in effect is further down in the list, Right Alt may or may not work as compose key. Not sure about the exact pattern here.

As regards Alternate Characters Key, I notice a marginal impact. If the English (US) layout is not the first layout in the list, Right Alt works as compose key with that layout if Alternate Characters Key is switched off, but not if it's set to "None". It should be noted that English (US) does not set Right Alt to the 3rd level key by default.

Steve, does the above description reflect your observations too?

Over to the question whether this is a g-c-c bug to some extent. I still think that g-c-c sets sensible options, and that the unexpected behavior is rather an XKB issue. The reason why Alternate Characters Key sets "lv3:ralt_alt" is that it assumes that a user who picks something else but Right Alt wants to be able to use Right Alt as any Alt key.

OTOH, given this issue wrt Right Alt as compose key, you can argue that g-c-c should better not provide Right Alt as a compose key option...

While an annoying issue and a regression, it's impacting some configurations only and is workaroundable so we are not going to handle it as a rls issue. We will work on trying to provide a fix if possible though