What do you mean "not detected"?

(In reply to Andrey from comment #1)
> What do you mean "not detected"?

My formulation is indeed a bit clumsy.
I mean I get the base character instead of the suited accentuated one.
E.g. : ^ + a gives "a" instead of "â", ^ + e gives "e", and so on.
To summarize, it's like the "^¨" key was ignored.

Is your report for Wayland session?
Can you test both X11/Wayland?
Do you have some ibus daemon running?

I'm running X11, not Wayland.
No ibus daemon running.
I'll try with Wayland tomorrow or wednesday if I can.

Tried Wayland a bit later than I wanted.
The problem is not present.

Thanks.
Just to clarify: can you use Wayland as a workaround?

Well I could try more intensively, as the situation is now a lot better with Nvidia proprietary drivers.
However, I feel moderately confident about potential problems that could arise sooner or later.
So I would appreciate a bugfix though, unless this represents a real pain of course.

I do not have ideas, nor the time to investigate it for X11. Sorry.
If someone have ones, we could consider the fix.

No problem, I understand your position.
I'll try to use Wayland, as I said.
If I have to fallback to X11 for one reason or another, then I'll change the password to avoid this bug.
However as you said, if someone has an idea...

*TL;DR: If deadkeys don't work, it's probably because KDE/Qt is looking for a UTF-8 encoding but X11 is assuming your encoding is a LatinN or other native character set. See end for fix*

This is a general observation about non-funcitoning deadkeys, and may or may not be applicable to this particular bug report.

I used to have this problem with deadkeys all the time. My system language is Esperanto and I use the Canadian Multilingual (CSA) keyboard. Over the years, I have found out that when deadkeys don't work, it is usually because of mismatched language/locale/encoding assumptions between different layers of software. (I am using Debian with KDE)

KDE/Qt language settings assume your system is UTF-8 and define environment variables without encodings, for example `LANG=fr_CA` instead of `LANG=fr_CA.UTF-8` or `LANG=fr_CA.iso8859-1`. Type `locale` in Konsole to verify.

X11, which gets the keyboard before Qt does, has different behaviours as defined in /usr/share/X11/locale/locale.dir and other places. For Esperanto, this file needs to be edited and re-edited every time X11 is updated.

Debian, which defines what the system locale is to be before X11 ever starts, also has different behaviours. Debian uses `/etc/default/locale` to define the system's default locale, but often leaves the encoding up to assumption the same way as KDE does. It defines which locales are to be supported via `/usr/share/i18n/SUPPORTED`. According to this file languages specified without encoding default to native encodings like Latin1 etc. 

The Fix: Don't EVER use KDE's language settings KCM. Or, maybe just use it once to create a template `.config/plasma-localerc`. You should directly edit $XDG_CONFIG_HOME/plasma-localerc to make sure that it specifies UTF-8. Make sure that `/etc/default/locale` also does not leave encoding to assumption. This won't have much effect on KDE, but it does affect keyboard behaviour on your virtual terminals, so keep things consistent. Also, for old-school X11 applications like XTerm and Emacs, consistency demands that `/usr/share/X11/locale/*` also be reviewed and possibly edited for consistency with a UTF-8 only system.

Hello,

I think I have the same issue. My password contains the character "^".
To enter such a character, you have to type "^" then "space."
When I do that, it says that my password is invalid.
I'm pretty sure that it only displays a space.

Also, if I type, for instance, ^^^^^^ it displays nothing.

At first, I thought my keyboard was in qwerty (not azerty), but that is not the case.

I confirmed this by doing the following:
Let's say my password is "azerty^azerty."

1. I type (on keyboard) "azerty."
2. I type (on keyboard) "^ " (I can see one character displayed). (Guessing it's only the space)
3.  I type (on keyboard) "azerty."
4. Then it says login failed.

However,

1. I type (on keyboard) "azerty."
2. I type "^" using the virtual keyboard.
3. I type (on keyboard) "azerty."
4. Then I can log in.

I've tried with Wayland and X11, and it's the same behavior.
I don't see issues with special characters using SDDM (or any other applications).

So the workaround for now is to click to switch users to go back to the SDDM login screen.

Do you have any ideas ?

Thanks for your help.

Could you please post the output of 
locale
from a text-only virtual console? (Press Ctrl-Alt-F4, log in, type "locale")
and also the output from the same command issued in a Konsole window in X11 or Wayland?

Also, if it exists, the contents of ~/.config/plasma-localerc or $XDG_CONFIG_HOME/plasma-localerc?

(In reply to David from comment #12)
> Could you please post the output of 
> locale
> from a text-only virtual console? (Press Ctrl-Alt-F4, log in, type "locale")
> and also the output from the same command issued in a Konsole window in X11
> or Wayland?
> 
> Also, if it exists, the contents of ~/.config/plasma-localerc or
> $XDG_CONFIG_HOME/plasma-localerc?

That was it. Sorry, I should have paid more attention to your previous message.
For those who may have the same issue, here is how I fixed it.

1/ Check the locale issue
$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory  
locale: Cannot set LC_MESSAGES to default locale: No such file or directory  
locale: Cannot set LC_ALL to default locale: No such file or directory  
LANG=en_US.UTF-8  
LC_CTYPE="en_US.UTF-8"  
LC_NUMERIC="en_US.UTF-8"  
LC_TIME="en_US.UTF-8"  
LC_COLLATE="en_US.UTF-8"  
LC_MONETARY="en_US.UTF-8"  
LC_MESSAGES="en_US.UTF-8"  
LC_PAPER="en_US.UTF-8"  
LC_NAME="en_US.UTF-8"  
LC_ADDRESS="en_US.UTF-8"  
LC_TELEPHONE="en_US.UTF-8"  
LC_MEASUREMENT="en_US.UTF-8"  
LC_IDENTIFICATION="en_US.UTF-8"  
LC_ALL=

$ locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory  
locale: Cannot set LC_MESSAGES to default locale: No such file or directory  
locale: Cannot set LC_COLLATE to default locale: No such file or directory  
C  
C.utf8  
POSIX

2/ On arch linux, follow wiki https://wiki.archlinux.org/title/locale
(See specific information for your linux distribution)
2-1/ Edit /etc/locale.gen to include the locale used in command "locale". In my case "en_US.UTF-8"
2-2/ Run command to generate locale
$ locale-gen
2-3/ Set locale
$ localectl set-locale LANG=en_US.UTF-8

3/ Check again with command locale and locale -a that there is no error

I wonder how this relate to a touch on keyboard that can not be input. (but be input via the virtual keyboard).

Anyway,
Thanks a lot for your help.

My previous message as about test I did in Wayland.
The solution I posted did help me to fix the issue in Wayland however I still have the same problem using X11.
(I have to use X11 because of graphical/lag issue I have on specific other application)

So I tried :
- Change keyboard layout
- Change LC_* or LANG Env var
- Trying to debug locally (kscreenlocker_greeter.sh --testing)
- Remove ~/.config/plasma-localerc

However in X11, the issue remain for me.

Here is a log of :

(there are the same in crtl + F4 term as in kconsole in kde)
$ locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES=en_US.UTF-8
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

$ cat cat /etc/locale.conf 
LANG=fr_FR.UTF-8
LC_MESSAGES=en_US.UTF-8

(I seems to make to difference, if it is all to "fr_FR.UTF-8" or "en_US.UTF-8")

When i'm using kscreenlocker_greeter.sh --testing and copy paste the character ^ then it's working.

For now, i'm using a different password. I'm not sure if a lot of users are in the same situation.

Thanks for you help

I think I figured it out!

On some systems, KScreenLocker has a virtual keyboard feature in the bottom left corner of the screen. I do not have this on my Debian machine, but with fresh install of Manjaro/X11/KDE it is there. This virtual keyboard interferes with keyboard input even while not being used.

On Manjaro, after verifying that all locale settings were correct from the OS to X11 to KDE, and that accents were working everywhere except in KScreenLocker, I uninstalled the virtual keyboard like this:

pacman -Rdd qt6-virtualkeyboard    #-Rdd forces pacman to ignore dependencies when removing

After that, I had full use of deadkey accents effective immediately.

---
<editorial>I don't know why that keyboard is there as a dependency; it seems ridiculous. If I need/want a virtual keyboard, I will install one system-wide. There is no point in having a special input method just for my screensaver. What would be way more effective is if KScreenLocker had an interface for IBus/FCITX to allow keyboard switching and possibly a system-wide virtual keyboard module that worked through one of those well-established input methods. I've had it happen to me where I walked away from my computer with my keyboard switched to Persian and when I got back I was locked out because there is no way to change back to a Latin layout to enter my password. I supposed that is why the virtual keyboard is there, but it is still a stupid way to solve the problem.</editorial>

Ouah Thank you !

I don't know how you found it, but that was it. After uninstalling the package on archlinux the special character can now be input and the password is working as espected.
Come to think of it, I did found odd that the virtual keyboard was in qwerty and not in azerty, but I didn't think this was causing the issue because the other keystroke were working correctly (I could type my password normally and add the special character via copy/paste or ironically via the virtual keyboard)

For housecleaning, I am marking this bug as CONFIRMED and adding some meta-information, including a reference to Bug 487276, which is also about keyboard input in KScreenLocker.

Even though the problem we discussed here lies in qt6-virtualkeyboard, I would say that KScreenLocker's reliance on qt6-virtualkeyboard is itself a bug for the reasons discussed here and in Bug 487276. At best, the use of the onscreen keyboard is a "misfeature", as it creates unexpected behaviours and interferes with configured keyboards and input methods such as FCITX.

Hello,

It looks like David has found the cause in the end, well done!
Even if it's not useful for this particular bug, I would like also to thank him for his very educational explanation about the locale mechanics in #comment 10. ;)

Adding the x11-only keyword