Fedora 39 Caps Lock toggle reversed and malfunctioning

Ask Fedora
, , ,
1

After upgrading from Fedora 38 to 39, I have noticed that the CAPS LOCK is reversed.
This issue occurs on multiple devices I own. A laptop and a desktop computer.

This happens with an internal keyboard (laptop) and an external keyboard (desktop)
CAPS LOCK toggle is reset to correct state when:

  • Logging in
  • Restarting device
  • Locking session
  • Interacting with the Gnome Applications Search

The indicator light for CAPS LOCK on the keyboard for these devices also gives the reversed or opposite state.

My current solution to fixing this annoying bug:
Lock or Suspend session, then relogin OR open Gnome Activities and search for any text

I have not timed how quickly after the solution the issue comes back, but it is a temporary fix that needs a permanent solution.

I have not found any other posts. Has anyone else come across this issue?

Ask me for any further information you may need to diagnose this problem.

2 Likes
2

My situation is exactly the same as yours. Itā€™s really annoying!

3

Are you using Wayland or X?

In what other way is caps lock reversed? Are you referring to the indicator on password prompts?

4

I thought I was on Wayland
but neofetch brings up ā€œMutterā€ for window manager

If the indicator light on either of my keyboards are off, then CAPS LOCK is enabled. Visa versa

It is in the correct state for any system prompts like password entry and that fixes the issue just like the other solutions

Edit: My mistake. Yes, compositor or something on Wayland and have always used it for Fedora Workstation and Gnome

5

I Have the same issue too when I restart it goes of but when open laptop after screen goes over it comes back again.

6

I discovered something, if it helps maybe you can try that too. In gnome tweaks settings if you enable shift cancels capslock behavior it might have fix it. It worked for me. Actually I used both of it but you can just try shift cancels capslock option.
Screenshot from 2023-11-09 15-15-21

6 Likes
7

Thank you. I have enabled both options for several hours now and it has been working correctly. I will continue to use them and then set this topic as solved on the 10th of November.

8

Thanks for the pointer Ozgur, this issue has been driving me mad for the last few days.

Iā€™m going to dig around to see where Iā€™d file this as a bug because itā€™s only just started happening in the last couple of days so Iā€™d like to file a BZ so itā€™s not lost. Anyone know what component to use for this?

9

I just started seeing this issue yesterday.

Fedora 39
Gnome 45

Caps Lock off at login screen - no caps
Caps Lock off once logged in - all caps

I have to turn caps lock on once logged in, so caps will behave as if the caps lock is off.

No idea why it just started happeneing. Nothing changed that I can think of.

Anyone figured out why? I see the gnome tweaks ā€œsolutionā€ above, but doesnā€™t really seem like a fix for long term.

10

I tried it for a week and it worked for me, thanks.

  • Arch Linux
  • GNOME 46
11

Sorry, everyone. The solution of configuring inputs worked for some time, but just did not feel right! I am sure many others would agree. I switched from Fedora for a few months and switched back for the beautiful 40, but I believe after updating last night, this bug came back onto both of my systems. Laptop and Desktop are experiencing this bug today. This is very unfortunate and as one other said I hope this does not get buried.

A post on another website mentioned this. /r/Fedora/comments/1bqqxpq/capslock_insanity_f40_beta/

12

This seems to be a bug in Fedora, and it looks like it wasnā€™t solved on Fedora 40. I just wanted to note that, apart from the (excellent but GUI-based) workaround suggested by @fogonte, you can use the CLI command that writes directly to /sys/class/leds/input<n>::capslock/brightness (where is an integer identifier for the keyboard)

So, for example, on my system, to reset the caps-lock light without changing the state, I can use use:
echo 0 | sudo tee /sys/class/leds/input98\:\:capslock/brightness

Turns the caps lock led off my system, and

echo 1 | sudo tee /sys/class/leds/input98\:\:capslock/brightness
Turns it on.

13

good one!
thank you
iā€™ve had the issue last year, never bothered to look it up until today :face_with_peeking_eye:
me being lazy to find out what was it just rebooted hehehe

14

Iā€™ve seen this on a random laptop about a month ago and assumed it was the laptopā€™s EC (or something) being inconsistent with the OS state (laptop thinks caps on and LED indicates but OS thinks itā€™s off; so caps-on to the OS means caps-off to the laptop EC for the LED, but still caps-on for the OS)

I donā€™t remember doing anything about it specifically, but if Intel HID is involved Iā€™d start with forcing an acpi_osi= kernel option to match something in ACPI (my Dell 5591 does something to report Intel HID without-specifying or doing Linux, but doesnā€™t present Intel HID if I do Windows 2017 and Fn shortcuts nor Mic LED work)

15

Hello,
Iā€™m having the same issue on Fedora 40, with caps lock being reversed sometimesā€¦ it is pretty annoying.
From the thread it seems there isnā€™t any longtime fix :astonished: ?

16

This seems to be a known Mutter issue. You can add your comments/information and track progress there.

18

Looks like itā€™s finally fixed! We should explore whether this can be backported or not

19

Hereā€™s a scratch build for F42 with a fairly naive backport. Can you give it a shot?

Aside from the correctness of the backport, I guess thereā€™s a question of when exactly ā€œNowadaysā€ started - does that ā€˜getting modifiers in a detailed manner from ClutterEvent itselfā€™ apply to mutter 48?

I think that might refer to stuff from 2023 like MR 3369 , in which case weā€™re good, but Iā€™m not 100% sure.

20

Oh, darn, the scratch build failed: error: implicit declaration of function ā€˜clutter_keymap_get_modifier_stateā€™; did you mean ā€˜clutter_keymap_get_num_lock_stateā€™? That suggests the necessary interfaces arenā€™t in mutter 48, but Iā€™ll check itā€™s not just a name change or something.

edit: it looks like clutter_keymap_get_modifier_state replaced meta_keymap_native_get_modifier_state so we could potentially twiddle this to use that instead, but Iā€™m not sure how to get the different object (a MetaKeymapNative not a ClutterKeymap) that function tookā€¦

edit 2: nah, even meta_keymap_native_get_modifier_state was added between 48 and 49. so weā€™re basically boned, this isnā€™t really backportable without backporting all the stuff it relies on.