> In the Fedora VM I've set the keymap to fi-mac

How? Using `localectl set-keymap`? Or some GUI tool?

Has the value of "VC keymap" field in output of `localectl status` changed between 35 and 39?

H,

In the Fedora VM I've set the keymap to fi-mac using `localectl set-keymap`.

Fedora 39:
$ localectl status
System Locale: LANG=sv_FI.UTF-8
    VC Keymap: fi-mac
   X11 Layout: fi
    X11 Model: microsoftpro
  X11 Variant: mac
  X11 Options: terminate:ctrl_alt_bksp

Fedora 35:
$ localectl status
   System Locale: LANG=sv_FI.UTF-8
       VC Keymap: fi
      X11 Layout: fi

(In reply to andersbergsten from comment #2)
> Fedora 39:
> $ localectl status
> System Locale: LANG=sv_FI.UTF-8
>     VC Keymap: fi-mac
>    X11 Layout: fi
>     X11 Model: microsoftpro
>   X11 Variant: mac
>   X11 Options: terminate:ctrl_alt_bksp
> 
> Fedora 35:
> $ localectl status
>    System Locale: LANG=sv_FI.UTF-8
>        VC Keymap: fi
>       X11 Layout: fi

So, it looks to me that the "problem" is that F-39's systemd-localed selects a better match for the requested keymap than the older one. Hence, you should use plain fi instead of fi-mac if you want the old behavior...

Hi,

I can assure you I have tried that too and other keycaps, but it still doesn't work as in Fedora 35. So something has changed regarding this for the worse, i.e. regression. So I think this ticket should be reopened.

I'd like to view the layout, but the preview crashes: https://bugzilla.redhat.com/show_bug.cgi?id=2236832 :(

I don't think that the changes in systemd are relevant. In the last few years, we only
touched the mappings for hu, cz, sk, lt, es, and lv, and made some tweaks to the selection
algorithm. But you tried both maps, and the problem is not in the wrong one being selected,
but it just not working as expected.

I see xkeyboard-config was updated over a few versions to 2.40, it might be related.

> 5. Log in to the Fedora 39 VM.

Are you using the graphical environment (gnome-shell) in Xorg mode, in wayland mode, or the console?

Hi,

Sorry about the late answer.

Looks like I'm using Gnome ... probably in Wayland mode (see below). I've made a Fedora 39 default installation. I haven't made any installation configuration changes out of the ordinary. I merely specified language and timezone. Everything else should be defaults.

fedora@fedora02:~$ printenv XDG_MENU_PREFIX DESKTOP_SESSION XDG_SESSION_DESKTOP XDG_SESSION_TYPE XDG_CURRENT_DESKTOP WAYLAND_DISPLAY GNOME_TERMINAL_SCREEN GNOME_SETUP_DISPLAY GDMSESSION
gnome-
gnome
gnome
wayland
GNOME
wayland-0
/org/gnome/Terminal/screen/7429609e_b744_4994_9627_a6a9daa15a52
:1
gnome

I don't know which component is responsible for this. I don't think it's systemd. Let's get some input from kbd maintainers.

If I understand it correctly, the problem appears in graphical environment - terminal emulator.
Key mapping for graphical environment is within xkeyboard-config package, kbd ships just text
console related stuff.

$ rpm -qf /usr/share/X11/xkb/symbols/fi
xkeyboard-config-2.36-3.fc37.noarch

Can you run `libinput record` please, in the VM - this will tell us what comes out of the kernel so we know what is being mapped in the system then. Press the key combination, then attach the output here.

If you're in X, please attach the output of `xkbcomp -xkb $DISPLAY -`, and `setxkbmap -print`. If you're on Wayland whatever the GNOME configuration lists in Keybard -> Input Sources.

(In reply to Peter Hutterer from comment #9)

Hi,

Here's the output of libinput and setxkbmap commands. The output of xkbcomp is quite long so I guess I shouldn't paste it here, but attach it to the ticket. However I don't know how to do that.

$ libinput record
libinput: record is not installed


$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+fi+us:2+inet(evdev)+terminate(ctrl_alt_bksp)"	};
	xkb_geometry  { include "microsoft(natural)"	};
};

Created attachment 2008348 [details]
Output of xkbcomp

Requested in comment 9.

dnf install libinput-utils to get libinput record

Created attachment 2008428 [details]
Output of libinput

As requested in comment 12. See attachment.

I forgot to tell in comment 13 that I pressed the key combination right after entry '# Current time is 19:16:30' in the attached libinput file.

apologies, I forgot to mention: you need to run with libinput record --show-keycodes, otherwise it will obfuscate the keycodes to avoid accidental password leaks etc.

Created attachment 2008765 [details]
Output of libinput record --show-keycodes

As requested in comment 15. See the attachment. I pressed the key combination right after entry '# Current time is 21:25:45' in the attached libinput2 file.

Thanks, so the libinput record output shows the key event that arrives in the VM is `alt + 7` which matches what you say in the first comment. That key is defined in your keymap as:

     key <AE07> {
          type[group1]= "FOUR_LEVEL",
          symbols[Group1]= [               7,           slash,       braceleft,        NoSymbol ],
          symbols[Group2]= [               7,       ampersand ]
      };

And the FOUR_LEVEL type means you get to level 3 with alt and that is braceleft or {. So, in other words, everything works as expected, there is no bug in the event delivery, this looks like a wrong keymap.

> I've also tried keymaps se-mac, fi and se but the problem is the same.

looking at fi(mac), it is indeed just a single include "se(mac)". But se(mac) defines:

   key <AE07>  {[          7,       slash,            bar,  backslash ]};

So the problem is that somehow your keymap doesn't get the fi(mac) variant and indeed, the variant is missing from the setxkbmap output, you're using the default fi layout, not fi(mac).
You're using gnome on wayland, so this command should look roughly like this

  $ gsettings get org.gnome.desktop.input-sources sources
  [('xkb', 'us'), ('xkb', 'fi+mac')]`

I guess in your case it's just "fi" and that's the problem. How you got there I'm not 100% sure, I don't know if the localectl was taken incorrectly or if you at some point manually set fi in gnome without the mac variant. Either way, should be easy to fix by going to the control center's keyboard configuration and adding Finnish(Macintosh) to the input sources.

Created attachment 2010546 [details]
Fedora 35 to 39 keyboard config comparison

(In reply to comment #17)

Sorry about the late reply.

Well, I guess I messed up when trying to make | work in Fedora 39 by the use of CLI, which was unsuccessful. However the reason I started to mess around was because I don't know how to fix it in the control center's keyboard configuration. See the attached screenshots comparing Fedora 35 with Fedora 39. So I'd say there is a bug lurking around.

I have se+mac show up in Swedish(Sweden) and fi+mac show up in Finnish (the respective Macintosh entry). The Swedish(Finland) section is populated from somewhere else but I don't 100% know where from without having to dig into the source.

This message is a reminder that Fedora Linux 39 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '39'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 39 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26.

Fedora Linux 39 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.