Does the issue persist for a new user?
This I have not tried yet, but I suspect it would, given that the keyboard repeat rate is set globally for all users.
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
Upon closer inspection, I have found the following…
1 - The file
~/.xinitrc does 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.
I’ve tried your approach here, but it has no effect at all.
Okay; it does work for me, but it clearly isn’t a universal fix. Clearly, we need the upstream package maintainer to take corrective action.
BTW, what (if anything) does
$ xmodmap -pke | grep -i multi_key
show for you?
Nothing at all.
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 Key is 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.
I saw it but I don’t honestly know what’s going on. These settings are working for me just fine.
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?
Rate and delay are being written into
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
# 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,
.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.
Okay, I have now solved all of the keyboard problems I was having, albeit that I had to set up things in different places. I will describe the solutions below.
1. The compose key problem
I managed to solve this by editing
/etc/X11/xorg.conf.d/00-keyboard.conf. The file now looks as follows…
# 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" EndSection
2. The keyboard repeat rate and delay, and the Mac-style “numbers-only” numeric keypad
I have tried the approach proposed by @omano via a script in Plasma’s Autostart section, but that didn’t work. I have solved it now by creating a new (root-owned and world-executable) script under
70-keyboard_settings.sh, whose contents are the following…
#!/bin/sh xset r rate 180 76 setxkbmap -option "numpad:mac"
The behavior is now again as desired, and as it used to be before whatever changes were applied by the update referenced in the opening post…:
The right win-key now works as a compose key again.
The numeric keypad now always produces numbers, regardless of whether Num Lock is on or off and regardless of whether the Shift key is pressed or not, just as it is on a Mac.
Keyboard repeat rate and repeat delay are now as I want them, immediately upon logging into Plasma.
I am therefore going to mark this thread as solved, even though there may be people with yet other keyboard-related problems, to which I have linked here on this thread.
Thank you to everyone who responded and helped me on my way to finding the solution to my multiple and seemingly unrelated keyboard problems.
What I did was actually adding the whole command as an application not a script (it created a .desktop file for it). But your solution may be better anyway as it is system wide now I think, mine was for my user only for the desktop environment only.
//EDIT: there is still an issue though in Manjaro Settings then, if the keyboard delay/speed is saved but not loading after reboot, that might be worth an issue on Gitlab I guess.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.