Um, what exactly do you mean by “clean cache” and “reset KDE settings”? You mean I should reset everything to the Manjaro defaults, after all of the customizations I’ve made to my Plasma?
By the way, I’ve just rebooted after downloading the new manjaro-kde-settings package ─ I had to reboot, because I normally have /usr mounted read-only, and I had to remount it read/write in order to install the update, but the filesystem was busy and I couldn’t remount it read-only again without a reboot ─ and my keyboard repeat rate and repeat delay were reset again to the slower defaults.
It is quite possible that this was a result of the manjaro-kde-settings package ─ I’ll have to check what files it pulls in before I can be sure of that.
What I do know is that until recently, my keyboard repeat rate and repeat delay were just fine, as were my compose key settings. And I know this because I have to use the compose key in Claws Mail for typing an em-dash. In KDE applications and Plasma proper, I can type an em-dash with AltGr+. but Claws Mail is a GTK application, and AltGr+. doesn’t do anything in GTK applications ─ Chromium being the only exception to that rule.
By clean cache I mean remove ~/.cache folder – that shouldn’t reset your settings
If that not help you can remove configuration files (not all but only related to keyboard and/or KDE) in ~/.config. Before you do it you can create new user to see if that help. If not – this is global problem, you should search solution somewhere in root partition instead home.
Well, I’ve completely cleaned out my ~/.cache, but the problem persists, as does the fact that logging out of Plasma and back in resets the keyboard repeat rate settings.
The latter is a global setting (under the Manjaro section of System Settings), because you need to provide a password to store the new settings ─ even though they are evidently not being stored anywhere, or else they wouldn’t get reset upon logout ─ but the compose key settings (if any) are specific to each individual account and must be set under the “Advanced” tab of the Input Devices section in System Settings, and it would appear that anything set under that tab is currently simply being ignored.
Hmm… The problem doesn’t appear to be limited to KDE Plasma, either…
I’m going to ping @philm because insofar I know, he’s the one maintaining the mhwd and manjaro-settings packages.
Upon closer inspection, I have found the following…
1 - The file ~/.xinitrcdoes contain an xset command to set the keyboard repeat rate and delay, and they are set to my preferences, but upon logging out of the GUI and logging back in again, Plasma reverts to a delay of 660 milliseconds and a repeat rate of ─ I think ─ 25 characters per second. These settings also appear to be overriding the Plasma-specific settings under…
System Settings → Hardware → Input Devices
… which are still set to my preferences, but which apparently do not take effect, just as my settings for the compose key and for always having the numeric keypad produce numbers even if NumLock is off are not having any effect anymore.
2 - Setting the keyboard repeat rate and delay to my preferences again via…
System Settings → Manjaro → Keyboard
… does work, but only for the running session. Once you log out and back in, they are reset again to the slower values as I mentioned higher up. The compose key settings and the numeric keypad settings however have no effect anymore, even though they are selected.
3 - I suspect that a system-wide setting overrides the user settings, and although I’m not a developer, I suspect that the update to systemd of a few weeks ago would be responsible for this.
I haven’t noticed any of the other issues mentioned, but I too have lost the compose key feature, following a recent update. I’m running Manjaro on a Hewlett-Packard Laptop-15, (so keyboard is somewhat non-standard, having only 100 keys, but has worked well until now, set as generic-102-key mapped for English-UK), with XFCE and kernel 5.10.61. I had delayed applying updates, since June until just last week. Prior to this last round of updates, pressing and releasing L-Shift+Alt-Gr activated compose mode. Now, this combination does nothing, (as does any other compose key assignment I might select in the keyboard settings).
FWIW, Ctrl-Shift-U still does work, for direct input of Unicode; guess I’ll just have to learn the code-point values for those glyphs I used to get via “compose”, until this compose key failure is resolved.
Having applied the 16-Sept stable update package, I again have a working compose key combination in XFCE … but it isn’t the same combination as I had before, and it’s behaviour is a little bit quirky!
Where I previously didn’t need to make any conscious choice, in the keyboard settings — LShift+AltGr just seemed to work OOTB, and it didn’t seem to matter which of the two keys was depressed first, as long as both ended up being depressed together — I’ve now had to select “3rd level of Left Ctrl” as my assigned compose key combination — there is no “3rd level of Left Shift” option, and it took some experimentation, to figure out that “3rd level of” means “AltGr with” — and it does now matter that AltGr needs to be depressed before LCtrl, but at least I do now have a viable solution.
Which means you do not have any compose key assigned; whatever method you are using to set it is not being honoured, whereas XFCE Settings -> Hardware -> Keyboard -> Layout -> Compose Keyis working for me.
That is precisely the problem, yes. I’m using Plasma and I have the right win-key set as the compose key, which used to work until the update mentioned in the first post. The key also doesn’t do anything else ─ normally, if it’s not assigned as the compose key, it would have the same function as the left win-key, but even that doesn’t work.
The problem also started together with a reset of the keyboard repeat rate and repeat delay whenever I log out of Plasma, and Plasma’s own settings for repeat rate and repeat delay have no effect. They can only be set via the Manjaro section of System Settings, which requires root privileges. But then they are reset again to slow defaults whenever I exit Plasma, which means that wherever those settings are stored is non-persistent, and/or that those settings are being overridden by something else.
I’ve contacted @philm about it, because it obviously has something to do with the Manjaro Settings Manager, and he told me that this package is maintained by @LordTermor. So we brought him in on the exchange, but he in turn hasn’t been online in a long time, and I doubt whether he has seen the PM.
In the Plasma System Settings, under the “Manjaro” section, there is a section for the keyboard. This is where you can set the type of keyboard and the repeat rate. Modifying those settings requires the admin password. Can you tell me where those settings are stored?
Something maybe unrelated but that I noticed the other day when messing with that (maybe when I read this thread initially, I don’t remember), is that you can for example set (for the test) the repeat ‘delay’ to 0 and the ‘speed’ to max, click apply, then cancel when it asks for password, and it actually sets it anyway as you can see if you try to write a message on the forum afterwards (didn’t try to reboot though with these messed up settings though). So it may save locally and system wide?
Other settings are apparently using keyboardctl script that is not installed anymore in Manjaro. So these settings (variant layout etc) possibly are not working but not rate/delay. Not sure I will do anything with this thing, I fix only minor/easy-to-fix bugs. Maybe keyboard module should be removed/disabled completely…
But that’s a user-owned file, so then why does it require the admin password to change those settings?
Furthermore, the settings don’t seem to stick. There is an xset line in my ~/.xinitrc, but it doesn’t have any effect. Upon logging into Plasma, I have to set the repeat and delay manually all over again.
On account of the compose key and the setting for always having the numeric keypad produce numbers (even when NumLock is off), I have now attempted to remedy that by modifying /etc/X11/xorg.conf.d/00-keyboard.conf, but I don’t know yet whether it’ll work, because I’ll have to log out and log back in for that, and I’ve got too much stuff open right now. I’ll see whether I can test it later tonight.
This is my /etc/X11/xorg.conf.d/00-keyboard.conf now…
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "be"
Option "XkbModel" "pc105"
Option "XkbOptions" "compose:rwin"
Option "XkbOptions" "numpad:mac"
EndSection
Probably because of the keyboard part to set the type/lang/variant which seems to be a system setting, not a user one?
Indeed I can confirm that, I did some tests and it does not keep the settings after reboot, even if the .xinitrc file contains the configuration line.
However, if I type this command from .xinitrc into my terminal, and open the System Settings → Keyboard config, the command itself works, so it seems it is not loaded properly on login/boot.
//EDIT: so from my test and research, .xinitrc (or .xprofile, I tried to create that file and use it too) is not executed when the KDE desktop loads. I removed the xset r rate 200 50 line from .xinitrc and added it to System Settings → Startup and Shutdown → Autostart and it works as intended so it is not a race condition or an override I think, it just doesn’t seem to load the .xinitrc file when the desktop loads.
Clearly, we need the upstream package maintainer to take corrective action.
(didn’t try to reboot though with these messed up settings though). So it may save locally and system wide?