Bug 456210

Is this only on Wayland? I can't reproduce this issue on X11.

Operating System: Arch Linux
KDE Plasma Version: 5.25.2
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5
Kernel Version: 5.18.7-arch1-1 (64-bit)
Graphics Platform: X11

Cannot reproduce on Wayland with either a single screen or multiple screens.

What happens when you click that "Unlock" button? Nothing?

Does the same thing happen if you run `/usr/libexec/kscreenlocker_greet --testing` in a terminal window?

Created attachment 150422 [details]
attachment-25769-0.html

Nothing happens apart from that print on journalctl that I mentioned
before, you get one of those for each attempt.

Exactly the same behaviour running that command.

On Tue, 5 Jul 2022, 6:18 pm Nate Graham, <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=456210
>
> Nate Graham <nate@kde.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>             Product|kwin                        |kscreenlocker
>                  CC|                            |bhush94@gmail.com,
>                    |                            |nate@kde.org
>           Component|general                     |greeter
>            Severity|major                       |critical
>              Status|REPORTED                    |NEEDSINFO
>            Assignee|kwin-bugs-null@kde.org      |plasma-bugs@kde.org
>          Resolution|---                         |WAITINGFORINFO
>
> --- Comment #2 from Nate Graham <nate@kde.org> ---
> Cannot reproduce on Wayland with either a single screen or multiple
> screens.
>
> What happens when you click that "Unlock" button? Nothing?
>
> Does the same thing happen if you run `/usr/libexec/kscreenlocker_greet
> --testing` in a terminal window?
>
> --
> You are receiving this mail because:
> You reported the bug.

(In reply to Nate Graham from comment #2)
> Cannot reproduce on Wayland with either a single screen or multiple screens.
> 
> What happens when you click that "Unlock" button? Nothing?
> 
> Does the same thing happen if you run `/usr/libexec/kscreenlocker_greet
> --testing` in a terminal window?

Nothing happens apart from that print on journalctl that I mentioned
before, you get one of those for each attempt.

Exactly the same behaviour running that command.

I should mention that I'm using fingerprint to unlock.

I am as well.

I'm also using a dock with displaylink for my two extra monitors. Maybe the EDID information reported by the driver is odd and causing the journalctl message I saw along with the lack of unlocking. This happens most of the time but not 100% of the time. I can unlock the season with loginctl.

I'm having this issue too.

I can unlock by writing the password a few times. It either works by itself (some phantom input) or by clicking the Unlock button after writing the password and pressing Enter.

I'm having the same problem, also using fingerprint to unlock. In my case the log shows a different message:
```
jul 11 22:37:40 fprintd[138530]: Authorization denied to :1.547 to call method 'Claim' for device 'Goodix MOC Fingerprint Sensor': Device was already claimed
```

But with a single monitor, it works (unlock) normally, without the warning.

And like Bruno said, when button appears i write my password and press enter and it unlocks, sometimes i need to go to tty and return for it to unlock.

Maybe each screen causes the greeter for that screen to instantiate a new instance of the PAM stack and they're stepping on one another?

Marking as confirmed because multiple people can confirm it, even though I can't myself.

I see this, in combination the spurious unlock button bugs (either bug 455712 or bug 456639, not sure which). I get the unlock button after entering my password, but the button does nothing unless I unplug the external monitor.

Arch Linux. All kscreenlocker 5.25.x seem to be affected. Downgrading to 5.24.90 fixes both this issue and removes the spurious button for me. Or maybe it only hides this issue?

Lenovo Thinkpad T480 with switchable graphics (intel + nvidia), though running in intel-only mode. External monitor uses displayport, connected via USB-C -> DP adapter. Arch Linux, as I said earlier.

Same is happening with me after updating to Plasma 5.25.3 some hours ago. Luckily I'm able to unlock my session by running `loginctl unlock-sessions` in another tty

Can you try again once you get the re-spun version of plasma-workspace? It had a regression in it that caused issues, and the fix for it may have fixed this issue too.

(In reply to Nate Graham from comment #13)
> Can you try again once you get the re-spun version of plasma-workspace? It
> had a regression in it that caused issues, and the fix for it may have fixed
> this issue too.

Sure, I can try if it is available by tomorrow.

(In reply to Vorpal from comment #14)
> (In reply to Nate Graham from comment #13)
> > Can you try again once you get the re-spun version of plasma-workspace? It
> > had a regression in it that caused issues, and the fix for it may have fixed
> > this issue too.
> 
> Sure, I can try if it is available by tomorrow.

Actually it just showed up in the mirror I use so I was able to test it.

Updating plasma-workspace to 5.25.3.1-1 seems to fix this in that I don't see the unlock button and multi screen unlock works. Works with both the password and fingerprint.

I have the following fragment in /etc/pam.d/kde: 

auth            sufficient      pam_unix.so          try_first_pass likeauth nullok
-auth           sufficient      pam_fprintd.so       max_tries=1 timeout=10

I assume this bug could still trigger for someone who uses a password less account and still has the unlock button though? Presumably that needs to be tested too.

John Clark, could you test it too? Thanks!

5.25.3.1-1 fixed the unlock issues here.

 5.25.3.1-1 plasma-workspace  fixed the issue for me.

(needs verification from John Clark too before we can mark it as fixed)

Sure, I'll test this as soon as I can

I have the same problem on Endeavour OS. I use two monitors and after screen lock I'm unable to login back. I'm stuck with a "login" button which does nothing. After I disconnect one monitor I'm able to login again. However, after initial password input I'm redirected to that "login" button which I need to click to get back to OS

The 5.25.3 packages haven't hit a Fedora repo yet (including any copr's that I can see) once they do I'll test it.

This is I have on Solus 5.25.3 after I updated it

(In reply to Nate Graham from comment #19)
> (needs verification from John Clark too before we can mark it as fixed)

Tested the respin fixes as well on Solus

Fixed here too, Neon testing with kscreenlocker 5.25.3+p20.04+tstable+git20220712.1708-0

I've updated to 5.25.3 from the Fedora updates repo and I'm still affected by this bug.

Can you confirm that you have plasma-workspace 5.23.5.1 installed, and not just 5.23.5?

(In reply to Nate Graham from comment #27)
> Can you confirm that you have plasma-workspace 5.23.5.1 installed, and not
> just 5.23.5?

Sure, it's definitely 5.23.5.1:

[john@fedora ~]$ rpm -qi plasma-workspace
Name        : plasma-workspace
Version     : 5.25.3.1
Release     : 1.fc36
Architecture: x86_64
Install Date: Thu 14 Jul 2022 06:05:55 BST
Group       : Unspecified
Size        : 36918392
License     : GPLv2+
Signature   : RSA/SHA256, Wed 13 Jul 2022 06:28:14 BST, Key ID 999f7cbf38ab71f4
Source RPM  : plasma-workspace-5.25.3.1-1.fc36.src.rpm
Build Date  : Tue 12 Jul 2022 23:16:06 BST
Build Host  : buildvm-x86-16.iad2.fedoraproject.org
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://invent.kde.org/plasma/plasma-workspace
Bug URL     : https://bugz.fedoraproject.org/plasma-workspace
Summary     : Plasma workspace, applications and applets
Description :
Plasma 5 libraries and runtime components


I'm getting this message printed in journalctl when I try and unlock:

Jul 14 18:41:24 fedora kwin_wayland[1763]: kwin_wayland_drm: Failed to create gamma blob! Invalid argument

The working version is 5.25.3.1-1

(In reply to matthewsha from comment #29)
> The working version is 5.25.3.1-1

I believe that's what I have installed? See the rpm info above.

(In reply to John Clark from comment #30)
> (In reply to matthewsha from comment #29)
> > The working version is 5.25.3.1-1
> 
> I believe that's what I have installed? See the rpm info above.

maybe not. the pre-fix version was 5.25.3-1

(In reply to matthewsha from comment #31)
> (In reply to John Clark from comment #30)
> > (In reply to matthewsha from comment #29)
> > > The working version is 5.25.3.1-1
> > 
> > I believe that's what I have installed? See the rpm info above.
> 
> maybe not. the pre-fix version was 5.25.3-1

and fixed is 5.25.3.1-1

Darn, I guess the issue we fixed in 5.25.3.1 was separate from the one you're experiencing.

I've gotten this both in Fedora and just now in Endeavour. plasma-workspace is on version 5.25.3.1-1 so that did not seem to fix it for me. And I can confirm it did not happen in 5.24. I think it has only happened when my monitors have been off since the day before.

Worth noting is my two monitors are not the same, and they power on at different speeds. I have a Dell AW3423DW connected over DisplayPort, and a HUION Kamvas Pro 16 over HDMI. The former takes a few seconds to actually power on, the latter powers on almost immediately. In the past it has caused KDE to think I'm switching between a single monitor and multi monitor layout. It's possible something related is going on here?

It happened again this morning, so I looked at `journalctl` in a tty before unlocking it. Nothing appears to show up when I click "Unlock", but there are a few lines that appear to be potentially relevant earlier in the log. Filtered to skip device connect spam from switching back/forth between ttys:

> Jul 18 11:57:58 pc kwin_wayland[2002]: QMetaProperty::read: Unable to handle unregistered datatype 'KWin::SessionState' for property 'KWin::EffectsHandlerImpl::sessionState'
> Jul 18 11:57:59 pc plasmashell[2195]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:70:5: QML Connections: Detected function "onConfigurationChanged" in Connections element. This is probably intended to be a signal handler but no signal of the target matches the name.
> Jul 18 11:57:59 pc plasmashell[2195]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:70:5: QML Connections: Detected function "onRepaintNeeded" in Connections element. This is probably intended to be a signal handler but no signal of the target matches the name.
> Jul 18 11:57:59 pc plasmashell[2195]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:67: TypeError: Cannot read property 'wallpaper' of null
> Jul 18 11:57:59 pc plasmashell[2195]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:71: TypeError: Cannot read property 'wallpaper' of null
> Jul 18 11:57:59 pc plasmashell[2195]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> Jul 18 11:57:59 pc plasmashell[2195]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> Jul 18 11:57:59 pc kscreenlocker_greet[38156]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> Jul 18 11:57:59 pc kscreenlocker_greet[38156]: file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool
> Jul 18 11:57:59 pc kscreenlocker_greet[38156]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> Jul 18 11:58:05 pc kscreenlocker_greet[38156]: file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool
> Jul 18 11:58:05 pc kscreenlocker_greet[38156]: file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool

There's also a bit of bismuth spam since I installed that yesterday to give it a try, but I did not have that installed yet when I ran into this yesterday so it seems unrelated and I thus filtered it out above.

Operating System: EndeavourOS
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.18.12-arch1-1 (64-bit)
Graphics Platform: Wayland

This still occurs on master as of 2022-07-19.

*** Bug 455712 has been marked as a duplicate of this bug. ***

I still have this bug on a system with the following setup:

OS: Fedora 36
KDE Plasma: 5.25.4
KDE Frameworks: 5.96.0
Qt: 5.15.5
Kernel: 5.18.16-200.fc36.x86_64
Graphics Platform: Wayland

I observe a similar `journalctl` output as provided by Johan Sköld in comment 35.

Same problem here

Operating System: Arch Linux
KDE Plasma Version: 5.25.4
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.18.16-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 2 × Intel® Core™ i3-2312M CPU @ 2.10GHz
Memory: 7,7 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 3000
Manufacturer: TOSHIBA
Product Name: SATELLITE L850-1LK
System Version: PSKG6E-00C002EN

Can someone who can reproduce run:

QT_LOGGING_RULES=kscreenlocker_greet.debug=true  /usr/libexec/kscreenlocker_greet --testing

(In reply to David Edmundson from comment #40)
> Can someone who can reproduce run:
> 
> QT_LOGGING_RULES=kscreenlocker_greet.debug=true 
> /usr/libexec/kscreenlocker_greet --testing

Sure:

[john@fedora ~]$ QT_LOGGING_RULES=kscreenlocker_greet.debug=true  /usr/libexec/kscreenlocker_greet --testing
kscreenlocker_greet: Greeter is starting up.
QSocketNotifier: Can only be used with threads started with QThread
kscreenlocker_greet: [PAM] Starting...
Locked at 1660381662
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
kscreenlocker_greet: Start auth
kscreenlocker_greet: "Place your right index finger on the fingerprint reader"
kscreenlocker_greet: Auth done RC 0
kscreenlocker_greet: Start auth
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool
kscreenlocker_greet: "Place your right index finger on the fingerprint reader"
kscreenlocker_greet: Greeter received SIGTERM. Will exit with error.
QEventLoop: Cannot be used without QApplication
kscreenlocker_greet: Auth done RC 6

Greeter does not accept my password but logs no error either

[ugjka@ugjka ~]$ QT_LOGGING_RULES=kscreenlocker_greet.debug=true  /usr/lib/kscreenlocker_greet --testing
kscreenlocker_greet: Greeter is starting up.
kscreenlocker_greet: [PAM] Starting...
Locked at 1660391789
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
kscreenlocker_greet: Start auth
kscreenlocker_greet: Auth done RC 7
kscreenlocker_greet: Start auth
kscreenlocker_greet: Auth done RC 7
kscreenlocker_greet: Start auth
kscreenlocker_greet: Auth done RC 11
kscreenlocker_greet: Start auth
^C

Can reproduce.

After normal password prompt a useless lonely "Unlock" buttons shows up, like the one for password-less users. Clicking it sometimes terminates the lock screen app and thus returns to the desktop, but sometimes does nothing.

Build-in laptop screen + external HDMI 4K@30FPS monitor.
Both with testing and real screen locking.
No fingerprints, no fprint, only password.
Workaround is to run loginctl unlock-session from TTY2
(Ctrl+Alt+F2 or +F8 depending on your distro).

Operating System: Arch Linux
KDE: git master
Qt Version: 5.15.5
Kernel Version: 5.18.16-arch1-1 (64-bit)
Graphics Platform: X11

I'm not getting EDID logs in journalctl, but I do get this line on start of kscreenlocker_greet:

>    kscreenlocker_greet[8858]: pam_systemd_home(kde:auth): systemd-homed is not available:
>    Unit dbus-org.freedesktop.home1.service not found.


I'm also getting these cosmetic error messages after every failed attempt,
even though I can't find any instance where it is defined as "read-only":

>    file:///usr/local/kde/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml:75:
>    TypeError: Cannot assign to read-only property "showPassword"


Consistent observation: when entering a correct password one screen first, the following dummy "Unlock" button terminates the screen locker and returns me to the desktop. But if I enter the password on another screen first — it won't unlock, it'll do nothing. It doesn't matter when do you do next: only first correct password attempt seems to matter.

"One" and "another" screens are randomly chosen laptop's built-in and external HDMI: in other words it would either work on a first try because you guessed the screen correctly, or it won't work no matter how many times you click. So far I'm more lucky with the "one" being the built-in laptop's one.

Basically, the same logs as posted above. The only difference when it's about to enter the unlockable state (i.e. I guessed the screen wrong) is an extra `kscreenlocker_greet: Start auth` line after `kscreenlocker_greet: Auth done RC 0`.

Same problem here, using u2f PAM with a Yubikey to login. Have 3 monitors, using X11. Like other users, `/usr/lib/kscreenlocker_greet --testing` has the same behavior.

On 5.25.4 with u2f PAM (Yubikey), not even the `unlock-sessions` workaround worked. Doing unlock sessions just resulted in a black screen with a block cursor moving and a random character in green on the screen. No amount of locking and unlocking via loginctl got it out of this state. I even unplugged the Yubikey to no avail.

Operating System: Fedora Linux 36
KDE Plasma Version: 5.25.4
KDE Frameworks Version: 5.97.0
Qt Version: 5.15.5
Kernel Version: 5.19.6-200.fc36.x86_64 (64-bit)
Graphics Platform: X11
Processors: 24 × 12th Gen Intel® Core™ i9-12900KS
Memory: 125.5 GiB of RAM
Graphics Processor: AMD Radeon RX 6600 XT
Manufacturer: ASUS

I have an alternative workaround (which has yet to fail me) rather than changing to a different TTY and using loginctl.

I have fingerprint unlocking enabled but instead of using my one registered finger which results in the issue, I use the wrong one until it gives up (3 attempts). It will say "Failed to match fingerprint" but then I use my password instead and it unlocks successfully.

We've got a few threads at once here:

Errors with "kscreenlocker_greet: Auth done RC 7" are probably the following:

KDE screenlocker tries to use the configuration /etc/pam.d/kde

As all distros are random with PAM this is not supplied by us. I think this is by mistake as it used to be part of KDM.
Some distros (Arch at least) ships it in plasma-workspace packaging. Others do not.

If this does not exist we fall back to /etc/pam.d/other

On some distros this will just call pam_deny immediately (which gives us our RC 7)
On other distros (Neon) it calls common-auth which is why it works

I don't think this is a recent regression our side.

*** Bug 455712 has been marked as a duplicate of this bug. ***

I can also have this issue intermittently. I bypass this by entering the password, pressing enter, then when you see the 'unlock' button, I press enter again. If you press the unlock button, you're screwed.

I think I have it intermittently due to my second monitor being slow to initialise

Operating System: Arch Linux
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.19.13-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 31,3 GiB of RAM
Graphics Processor: AMD Radeon RX 6800 XT
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7C84
System Version: 1.0

Experiencing a similar but a bit different issue. I have a black kscreenlocker when logging out while desktop is loading. No way to get it back except via separate terminal (CTRL+ALT+F2..).

- Ubuntu 22.04.1 LTS
- Linux 5.15.0-50-generic x86_64 GNU/Linux
- plasmashell 5.24.6

I've just started experiencing this issue after updating to Plasma 5.25.5 yesterday on Kubuntu 22.04.01 using the backports-extra PPA.
This had not occurred when using 5.24.x prior to updating (though I had experienced some SDDM startup timing issues).

There is no response when I attempt to unlock the screen (and pressing enter twice does not work) so have to now use the 'loginctrl unlock-session' workaround. After unlocking from the terminal, there is a consistent KWin Window Manager notification "Desktop effects were restarted due to a graphics reset".

My system has two monitors, so seems to fit here. Other info: X11, kernel 5.15.0-52-generic, Nvidia 515.76-0ubuntu0.22.04.1

I consistently reproduce this on my system every time the displays have gone to sleep for more than a moment or two.

The only way around it I've found so far (short of loginctl) is, when you wake the screens, type your password and hit enter twice. If you hit enter too slowly the second time, then it won't work. This is on Plasma 5.26, Frameworks 5.98, and Qt 5.15.6; as packaged by Debian Testing.

If it at all matters, I've got an NVMe SSD for the root drive, and an MDADM RAID 6 of 5400RPM HDDs for /home... In case that effects timing somehow.

*** Bug 461326 has been marked as a duplicate of this bug. ***

I think this is fixed for me as of KDE Plasma 5.26.4. I no longer see the unlock screen after authenticating with my fingerprint and it unlocks straight away (probably the change in this MR: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2349).

I won't change the status in case other people are still affected.

That's fabulous news. John Clark, can you confirm that?

(In reply to Miren Radia from comment #54)
> I think this is fixed for me as of KDE Plasma 5.26.4. I no longer see the
> unlock screen after authenticating with my fingerprint and it unlocks
> straight away (probably the change in this MR:
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2349).
> 
> I won't change the status in case other people are still affected.

I can also confirm this.

(In reply to Nate Graham from comment #55)
> That's fabulous news. John Clark, can you confirm that?

Yes, it's now all okay for me too.

Awesome!

Unfortunately still here for me. Using Howdy and dual monitors, Plasma 5.26.4 updated fully as of today.
Wayland, probably irrelevant.
Defunct "Unlock" button on both screens, only way to use the machine is via terminal unlock session
This absolutely critical but is still here after several months ....

(In reply to Andrej Falout from comment #59)
> Unfortunately still here for me. Using Howdy and dual monitors, Plasma
> 5.26.4 updated fully as of today.
> Wayland, probably irrelevant.
> Defunct "Unlock" button on both screens, only way to use the machine is via
> terminal unlock session
> This absolutely critical but is still here after several months ....

Same here on Arch

Operating System: Arch Linux
KDE Plasma Version: 5.26.4
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.7
Kernel Version: 6.0.12-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i3-2312M CPU @ 2.10GHz
Memory: 15,5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 3000
Manufacturer: TOSHIBA
Product Name: SATELLITE L850-1LK
System Version: PSKG6E-00C002EN

> Using Howdy and dual monitors
Howdy is not formally supported so that's a different issue. Please file a new bug report for it. Thanks!

This still happens to me as well. I have a dual monitor setup on X11.

Operating System: EndeavourOS
KDE Plasma Version: 5.26.4
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.7
Kernel Version: 6.0.12-arch1-1 (64-bit)
Graphics Platform: X11

(In reply to Nate Graham from comment #61)
> > Using Howdy and dual monitors
> Howdy is not formally supported so that's a different issue. Please file a
> new bug report for it. Thanks!

Issue has nothing to do with Howdy, I only mentioned it because few people mentioned PAM possibly being involved in tracing the origin of this bug that appears at the same time as did the second unlock button following the successful authentication.
Issue still happens when I use password.

This issue brings Plasma's reliability to 0

Reported: 	2022-07-01 15:25
Importance: 	VHI critical
Version fixed in:  5.26.4

I have 5.26 and I am fully up to date. When can I expect to see this fix on my PC?

Thanks

I would actually like better instructions to send logs to debug the error. Is it possible to attach something do SDDM and generate better logs? It's hard to reproduce this bug.

> This issue brings Plasma's reliability to 0

While I understand that situation kinda sucks for people like you who encounter this bug, that is an emotional overstatement. Please, keep it ethical.

> When can I expect to see this fix on my PC?

As soon as we have someone to reliably reproduce the issue. So far it happened to minority of users (me personally included), and goes away as soon as we try to investigate.  There's only so much extrasensory powers we possess, so it's rather hard to give any reasonable expectations in such situation ¯\_(ツ)_/¯

> I would actually like better instructions to send logs to debug the error. Is it possible to attach something do SDDM and generate better logs? It's hard to reproduce this bug.

First, this is not about SDDM but about kscreenlocker. Although I admit they look almost indistinguishable at a glance. But SDDM is a login manager, for signing into a new session with a new user; while kscreenlocker is a lock screen for an already logged in user.

Second, starting with Plasma 5.27.1 (hopefully?[1]) you could open KDebugSettings app, and raise logging level for "KScreenLocker (greeter)" component. But for now you can put this line in your ~/.bash_profile or ~/.zprofile depending on your shell:

    export QT_LOGGING_RULES=kscreenlocker_greet.debug=true

Lastly, you may try setting up dev environment (it's fairly easy with kdesrc-build[2]) and building kscreenlocker from git. Add print() calls in QML files here and there, and check logs in journal:

    journalctl --user -ef --no-pager

Note that most components are in plasma-workspace repository under lookandfeel/org.kde.breeze directory[3], because they are reused between screen locker and SDDM themes.

I hope that helps!

[1]: https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/129
[2]: https://invent.kde.org/sdk/kdesrc-build
[3]: https://invent.kde.org/plasma/plasma-workspace/-/tree/master/lookandfeel/org.kde.breeze/contents

I am still seeing this issue and can fairly consistently reproduce it. 

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:  Fedora 37
(available in About System)
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.102.0
Qt Version: 5.15.8

Additionally, often times the 'unlock' button itself has no effect. So I will input my password, get directed to the additional 'unlock' button page, but then clicking unlock does nothing.  Sometimes the additional unlock button will work, other times it won't.

Also, in the case where the initial password entry does work, there is a noticeable delay before the password screen actually is actually cleared and I am returned to the desktop.

Is this a duplicate of #374890?

They do not mention the "Unlock" button specifically in 374890.

So with Rocky 8.6 kernel version 4.18.0-372.26.1 I tried several things and I was still having this issue. I check the journalctl and my issue was a file. The file /etc/authselect/system-auth only had read permissions. I changed it to 755 and the unlock function worked. I realize this isn't a full fix for the bug but it turned out to be a good workaround for my situation.

I am also experiencing this bug on the framework laptop and the fingerprint reader on 5.25.5 on ubuntu 22.04. I have the fingerprint setup with libfprint and i have it configured in `/etc/pam.d/common-auth`. With just the internal display, I can move my mouse or press a key on the keyboard and it will ask me to place my finger on the reader and it will show the unlock button which works. With multiple displays connected, the unlock button appears to do nothing and i have to run a loginctl unlock-session from another tty to be able to unlock. I have also tried entering my password before placing my finger on the reader with the same effect. I have a similar setup with my work machine (a HP probook 440 G8) so i'll test that and see how it works

Ubuntu 22.04
Plasma 5.25.5
Wayland

I am also on Ubuntu 22.04 and Plasma 5.25.5 (wayland).

I have not had any lock-screen issues so far (I'm not using it at all) but when I see Plasma crashes I have lines in the log in common with what is mentioned here.

https://bugs.kde.org/show_bug.cgi?id=458469

I am seeing behaviour similar to in this bug and have added comments there; and someone else who was able to get 5.26 also saw that fix it.

Am commenting in case there might be something in common between these issues, and something that has been resolved as of 5.26, but not in the 5.25 branch (which is the latest available for all Ubuntu LTS users, so a reasonably large number may encounter further problems)

I see these lines in common (and searching for them has brought me here):
- Creating a fake screen in order for Qt not to crash
- requesting unexisting screen -1
- qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
- QMetaProperty::read: Unable to handle unregistered datatype 'KWin::SessionState' for property 'KWin::EffectsHandlerImpl::sessionState'
- QML Connections: Detected function "onConfigurationChanged" in Connections element. This is probably intended to be a signal handler but no signal of the target matches the name.

This is unrelated to the screenlocking, and often occurs when I power my display back on after being away form the PC for some time (fully on, not suspended); but I also experience this at times when there is a change in my desktop - e.g. opening a new application.

- Cannot read property 'wallpaper' of null

I'm having this issue as well. I can enter my password, then it goes to a screen with an "Unlock" button, but clicking the button does nothing. I'm on Wayland, plasma 5.27.3, Fedora 37, Qt 5.15.8, and I have three identical monitors connected to an AMD 6700XT GPU. Two via displayport-->hdmi adapters and one normal HDMI.

Same story on Fedora Kinoite. AMD 6800 XT, with two 4K screens of similar, but not same model. 

It is extremely aggravating to the point that it's the single thing that stops me from using KDE, as I can't take a coffee break without being locked out from my desktop and the thing I was working on.

(In reply to Stephane Travostino from comment #74)
> Same story on Fedora Kinoite. AMD 6800 XT, with two 4K screens of similar,
> but not same model. 
> 
> It is extremely aggravating to the point that it's the single thing that
> stops me from using KDE, as I can't take a coffee break without being locked
> out from my desktop and the thing I was working on.

For me, its ALWAYS happening because i have fingerprint auth enabled. As a workaround, i switch over to TTY1 where GDM is running and i can unlock from there, luckily. Still super annoying

There is a lot of talk about fingerprint sensors: this bug has nothing to do with it. It's a red herring.

It is perfectly reproducible on my desktop PC with no fingerprint and no Howdy. Just bog-standard username and password.

(In reply to Stephane Travostino from comment #76)
> There is a lot of talk about fingerprint sensors: this bug has nothing to do
> with it. It's a red herring.
> 
> It is perfectly reproducible on my desktop PC with no fingerprint and no
> Howdy. Just bog-standard username and password.

Do you have dual/multi monitor setup by chance?

(In reply to Andrej Falout from comment #77)
> (In reply to Stephane Travostino from comment #76)
> > There is a lot of talk about fingerprint sensors: this bug has nothing to do
> > with it. It's a red herring.
> > 
> > It is perfectly reproducible on my desktop PC with no fingerprint and no
> > Howdy. Just bog-standard username and password.
> 
> Do you have dual/multi monitor setup by chance?

Not Stephane, but I do.

(In reply to Andrej Falout from comment #77)
> Do you have dual/multi monitor setup by chance?

I do. The problem indeed happens with multi monitor setups, fingerprint sensors have nothing to do with this.

(In reply to Stephane Travostino from comment #76)
> There is a lot of talk about fingerprint sensors: this bug has nothing to do
> with it. It's a red herring.
> 
> It is perfectly reproducible on my desktop PC with no fingerprint and no
> Howdy. Just bog-standard username and password.

I know that the issue isnt directly related to fingerprint readers, etc. Its just when using fingerprint, etc it always displays the unlock button that doesnt work. Not too sure on the behaviour if you are using a password, does it happen randomly?

Git commit a9273c87e8582be7aa1e3de14d92b80ec92c4f44 by Harald Sitter.
Committed on 26/04/2023 at 11:29.
Pushed by sitter into branch 'master'.

greeter: track various properties persistently

There is a fundamental race condition between PamAuthenticator and the
greeter views. PA is a singleton that emits signals that result in
stateful changes to the views (e.g. showing the prompt message).
Meanwhile views are added when they get connected. This leads to
circumstances where pam may have sent a prompt before a view was
created, meaning the view is in an incorrect state.

To mitigate the problem we'll force-emit a number of stateful signals
whenever they are connected to. Thus ensuring that greeter views
definitely receive the most recent states.
The more long-term solution should likely be to move to property
bindings instead, so these stateful signals are now also exposed as
stateful properties.

M  +77   -4    greeter/pamauthenticator.cpp
M  +21   -0    greeter/pamauthenticator.h

https://invent.kde.org/plasma/kscreenlocker/commit/a9273c87e8582be7aa1e3de14d92b80ec92c4f44

Git commit 161f9d4c5151e4f3871e670531883bcb6a198d1f by Harald Sitter.
Committed on 26/04/2023 at 11:31.
Pushed by sitter into branch 'Plasma/5.27'.

greeter: track various properties persistently

There is a fundamental race condition between PamAuthenticator and the
greeter views. PA is a singleton that emits signals that result in
stateful changes to the views (e.g. showing the prompt message).
Meanwhile views are added when they get connected. This leads to
circumstances where pam may have sent a prompt before a view was
created, meaning the view is in an incorrect state.

To mitigate the problem we'll force-emit a number of stateful signals
whenever they are connected to. Thus ensuring that greeter views
definitely receive the most recent states.
The more long-term solution should likely be to move to property
bindings instead, so these stateful signals are now also exposed as
stateful properties.


(cherry picked from commit a9273c87e8582be7aa1e3de14d92b80ec92c4f44)

M  +77   -4    greeter/pamauthenticator.cpp
M  +21   -0    greeter/pamauthenticator.h

https://invent.kde.org/plasma/kscreenlocker/commit/161f9d4c5151e4f3871e670531883bcb6a198d1f

*** Bug 455712 has been marked as a duplicate of this bug. ***

Despite being marked as resolved, this still occurs to me sometimes on Plasma 6.0.

This is a somewhat old bug report and the code has changed a lot since it was reported. There's a very good chance the issue you're experiencing is caused by something else, even if the outward symptoms look and feel the same. Can you please submit a new bug report? Thank you!