I see something similar on my machine.
External monitor via HDMI, notebook lid is closed: login doesn't work.

A workaround seems to be to move the mouse to the not visible notebook display (to the left and out of the monitor) and *click* there once.
After that typing the password blindly works for login.

I'm having the same issue on my machine. When logging in on my main monitor connected via Display Port - the SDDM hangs after entering the password and confirming it. The password can only be entered on the second monitor connected via HDMI. 

Also the Splash screen after login seems to stay longer than before the KDE 6.2.1 update. I can hear Thunderbird notification coming in but the Splash screen is still visible.

I'm having the same issue on my machine. 
* I use Arch on a laptop.
* The laptop is connected to an external monitor with a displayport cable.
* I use the external monitor as main monitor.

Till the latest update, which brought me among other things "plasma-* packages 6.2.1-1" for example, login into kde plasma (x11 session) was not a problem.

But now nothing happens if I insert my password at the KDE login-screen (default breeze).
The workarourd is to unconnect the DP cable, make the login and after that connect the cable again.
The 2nd monitor works propely. (I am using it now)

Same issue here, on a desktop with arch, with Wayland.
Primary screen is on HDMI, second screen is an old VGA with a VGA -> Display port adapter, both 1080p connected to my RDNA3 AMD card (in case it is somehow connected to the problem).
When I start my PC, after typing the password, the login screen on my primary screen freeze, and I need to type the password on the second screen to login. Also the boot time seems to be longer than before.
The problem is not here when I manually lock the computer

Can confirm the issue.

After switching the SDDM theme from "Breeze" to "Maldives" the login worked again. After switching back the error also came back.

Maybe this helps finding the issue.

(In reply to Alexander Stehlik from comment #5)
> Can confirm the issue.
> 
> After switching the SDDM theme from "Breeze" to "Maldives" the login worked
> again. After switching back the error also came back.
> 
> Maybe this helps finding the issue.

This worked also for me. Changing from <DEFAULT> "Breeze" SDDM theme to "Maldives" fixed the issue! I really don't like the look of the "Maldives" SDDM theme because i am more a dark theme minimalistic lover - but thank you so much for sharing!

See also the post from Alexander Stehlik here: https://discuss.kde.org/t/solved-sddm-does-not-start-any-session/23670?u=astehlik

Same here, two monitors connected per DP. When entering the password, it automatically selects me (wrong) second screen first, where nothing happens after entering the password and pressing enter. I then move the mouse to the main monitor and enter the password there and can log in as normal.

Same bug here but on a desktop not a laptop, when I log in if I try to login from main screen nothing happens it just stays there with the password "greyed out", if I try to log in to any of my left and right monitor it logs in. I am on arch

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

FTR, this is caused by Qt 6.8, not Plasma 6.2.1

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

I managed to kinda fix it by setting my primary monitor on ssdm with xrand (also I fixed the weird order and resolution of the monitors buts that's unrelated) by putting this on my /usr/share/sddm/scripts/Xsetup file.
xrandr --output DP-0 --mode 1280x1024 --rotate normal --auto --noprimary \
--output DP-4 --mode 2560x1440 --rotate normal --auto --primary --right-of DP-0 \
--output DP-3 --mode 1920x1080 --rotate normal --auto --noprimary --right-of DP-4 \
--output HDMI-0 --mode 1920x1080 --rotate normal --auto --noprimary --right-of DP-3

You have to run `xrandr | grep -w connected` in an X11 session to get the correct names though, Wayland will report the display names wrong.

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

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

Created attachment 175029 [details]
Journalctl messages from sddm startup

Added a journald log showing some sddm-greeter-qt6 errors which might help analyzing the problem.

Yup, same thing happening to me on my main Arch Linux desktop computer. Dual monitors. I enter my password on my main monitor... it freezes. I mouse over to my second monitor, enter my password and it all works as normal.

It's something wrong with the Breeze theme for SDDM as I don't have this issue with Elarun.

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

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

Having a similar problem. Using Archlinux, Kernel 6.11.4, Plasma 6.2.1, KDE framework 6.7.0, Qt 6.8.0. I've "normal" workstation, AMD Ryzen CPU and AMD GPU RX 6700XT. The graphics card is connected via DisplayPort to my LG monitor. The problem happens when the monitor is turned off. I've configured in "Power Management" settings "Turn off screen" "When locked: 5 minutes". When I then hit any key on the keyboard the login screen appears as usual. I can type the password, hit "enter" and nothing happens. Same clicking the ">" button on the right of the password field. The only thing I can do is to "Switch user" and login as the same user again. The brings back my screen as I left it. But then all X11 remote sessions don't work anymore. Using "ssh" command and then running "xterm" on the remote computer only issues an error. So this "workaround" isn't really usable.

In general Plasma 6.2.1 seems to be pretty buggy. I've a lot of issues with this release. Upgrading Plasma from 5.x to 6.0 was pretty smooth but this minor release broke a lot of things and even crashes the whole Plasma session: https://bugs.kde.org/show_bug.cgi?id=494976 That never happened to me before.

(In reply to Antonio Rojas from comment #17)
> *** Bug 495083 has been marked as a duplicate of this bug. ***

Snap! openSUSE Tumbleweed here.

(In reply to RW from comment #19)
> Having a similar problem. Using Archlinux, Kernel 6.11.4, Plasma 6.2.1, KDE
> framework 6.7.0, Qt 6.8.0. I've "normal" workstation, AMD Ryzen CPU and AMD
> GPU RX 6700XT. The graphics card is connected via DisplayPort to my LG
> monitor. The problem happens when the monitor is turned off. I've configured
> in "Power Management" settings "Turn off screen" "When locked: 5 minutes".
> When I then hit any key on the keyboard the login screen appears as usual. I
> can type the password, hit "enter" and nothing happens. Same clicking the
> ">" button on the right of the password field. The only thing I can do is to
> "Switch user" and login as the same user again. The brings back my screen as
> I left it. But then all X11 remote sessions don't work anymore. Using "ssh"
> command and then running "xterm" on the remote computer only issues an
> error. So this "workaround" isn't really usable.
> 
> In general Plasma 6.2.1 seems to be pretty buggy. I've a lot of issues with
> this release. Upgrading Plasma from 5.x to 6.0 was pretty smooth but this
> minor release broke a lot of things and even crashes the whole Plasma
> session: https://bugs.kde.org/show_bug.cgi?id=494976 That never happened to
> me before.

Pulling the DisplayPort cable and putting it in again (as some others reported) does indeed help in my case. After doing so I'm able to login normally. Looking at journald logs I see the following messages. Not sure if they're relevant to this problem (esp. those "Couldn't map window" messages) but they were recorded while I tried to login:

"""
Oct 21 17:30:28 sulu firefox[15167]: [Parent 15167, Main Thread] WARNING: Couldn't map window 0x7c2022db63e0 as subsurface because its parent is not mapped.: 'glib warning', file /usr/src/debug/firefox-developer-edition/firefox-132.0/toolkit/xre/nsSigHandlers.cpp:187
Oct 21 17:30:28 sulu firefox[15167]: [Parent 15167, Main Thread] WARNING: Couldn't map window 0x7c2022db6f40 as subsurface because its parent is not mapped.: 'glib warning', file /usr/src/debug/firefox-developer-edition/firefox-132.0/toolkit/xre/nsSigHandlers.cpp:187
Oct 21 17:30:28 sulu firefox[15167]: Couldn't map window 0x7c2022db63e0 as subsurface because its parent is not mapped.
Oct 21 17:30:28 sulu thunderbird[4903]: [Parent 4903, Main Thread] WARNING: Couldn't map window 0x74f6685060e0 as subsurface because its parent is not mapped.: 'glib warning', file /usr/src/debug/thunderbird/thunderbird-128.3.1/toolkit/xre/nsSigHandlers.cpp:187
...
Oct 21 17:30:28 sulu firefox[15167]: Couldn't map window 0x7c2022db6f40 as subsurface because its parent is not mapped.
Oct 21 17:30:28 sulu firefox[15167]: Couldn't map window 0x7c2022db9640 as subsurface because its parent is not mapped.
Oct 21 17:30:28 sulu firefox[15167]: Couldn't map window 0x7c203c82bda0 as subsurface because its parent is not mapped.
Oct 21 17:30:28 sulu firefox[15167]: Couldn't map window 0x7c2022db9e60 as subsurface because its parent is not mapped.
Oct 21 17:30:28 sulu firefox[15167]: Couldn't map window 0x7c20add86fc0 as subsurface because its parent is not mapped.
Oct 21 17:30:28 sulu thunderbird[4903]: Couldn't map window 0x74f6685060e0 as subsurface because its parent is not mapped.
Oct 21 17:30:28 sulu thunderbird[4903]: Couldn't map window 0x74f6617fe300 as subsurface because its parent is not mapped.
...
Oct 21 17:30:29 sulu org_kde_powerdevil[2557]: dh=Display_Handle[i2c-6: fd=131], Replacing adjusted sleep multiplier 0.00 with 1.00 for SE_POST_WRITE or SE_POST_SAVE_SETTINGS
Oct 21 17:30:35 sulu kwin_wayland_wrapper[74856]: xkbcommon: ERROR: couldn't find a Compose file for locale "en_US.UTF8" (mapped to "en_US.UTF8")
Oct 21 17:30:35 sulu kscreenlocker_greet[74856]: qt.qpa.input.methods: failed to create compose table
Oct 21 17:30:35 sulu kscreenlocker_greet[74856]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockScreenUi.qml:128: TypeError: Property 'startAuthenticating' of object TypeError: Type error is not a function
Oct 21 17:30:37 sulu kscreenlocker_greet[74856]: file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockScreenUi.qml:280: TypeError: Property 'respond' of object length is not a function
Oct 21 17:30:59 sulu kwalletd6[2044]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu kded6[2413]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu kactivitymanagerd[2474]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu polkit-kde-authentication-agent-1[2556]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
...
Oct 21 17:30:59 sulu xdg-desktop-portal-kde[2558]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu thunderbird[4903]: [Parent 4903, Main Thread] WARNING: Couldn't map window 0x74f6664a45c0 as subsurface because its parent is not mapped.: 'glib warning', file /usr/src/debug/thunderbird/thunderbird-128.3.1/toolkit/xre/nsSigHandlers.cpp:187
Oct 21 17:30:59 sulu thunderbird[4903]: [Parent 4903, Main Thread] WARNING: Couldn't map window 0x74f6555f93e0 as subsurface because its parent is not mapped.: 'glib warning', file /usr/src/debug/thunderbird/thunderbird-128.3.1/toolkit/xre/nsSigHandlers.cpp:187
Oct 21 17:30:59 sulu kclockd[2776]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu DiscoverNotifier[2803]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu kdeconnectd[2779]: 2024-10-21T17:30:59 qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu corectrl[2905]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu kded5[3247]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu konsole[2906]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu kmix[2818]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu konsole[8391]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu konsole[5147]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu konsole[8639]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu kate[14780]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu krunner[3414]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu thunderbird[4903]: Couldn't map window 0x74f6685060e0 as subsurface because its parent is not mapped.
Oct 21 17:30:59 sulu thunderbird[4903]: Couldn't map window 0x74f6617fe300 as subsurface because its parent is not mapped.
...
Oct 21 17:30:59 sulu plasmashell[2516]: kde.plasmashell: requesting unexisting screen available rect -1
Oct 21 17:30:59 sulu plasmashell[2516]: kde.plasmashell: requesting unexisting screen available rect -1
Oct 21 17:30:59 sulu plasmashell[2516]: kde.plasmashell: requesting unexisting screen available rect -1
Oct 21 17:30:59 sulu plasmashell[2516]: kde.plasmashell: requesting unexisting screen available rect -1
Oct 21 17:30:59 sulu konsole[23114]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu kscreenlocker_greet[74856]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu org_kde_powerdevil[2557]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu plasmashell[2516]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
Oct 21 17:30:59 sulu plasmashell[2516]: kf.plasma.quick: Exposed with no visual parent. Window positioning broken.
Oct 21 17:30:59 sulu plasmashell[2516]: kf.plasma.quick: Exposed with no visual parent. Window positioning broken.
Oct 21 17:30:59 sulu plasmashell[2516]: kf.plasma.quick: Exposed with no visual parent. Window positioning broken.
Oct 21 17:30:59 sulu plasmashell[2516]: kf.plasma.quick: Exposed with no visual parent. Window positioning broken.
Oct 21 17:30:59 sulu plasmashell[2516]: kf.plasma.quick: Exposed with no visual parent. Window positioning broken.
Oct 21 17:30:59 sulu plasmashell[2516]: kf.plasma.quick: Exposed with no visual parent. Window positioning broken.
Oct 21 17:31:03 sulu thunderbird[4903]: Couldn't map window 0x74f6685060e0 as subsurface because its parent is not mapped.
Oct 21 17:31:03 sulu firefox[15167]: [Parent 15167, Main Thread] WARNING: Couldn't map window 0x7c2022db63e0 as subsurface because its parent is not mapped.: 'glib warning', file /usr/src/debug/firefox-developer-edition/firefox-132.0/toolkit/xre/nsSigHandlers.cpp:187
...
Oct 21 17:31:03 sulu thunderbird[4903]: Couldn't map window 0x74f665f4b460 as subsurface because its parent is not mapped.
Oct 21 17:31:03 sulu thunderbird[4903]: Couldn't map window 0x74f6664a45c0 as subsurface because its parent is not mapped.
Oct 21 17:31:03 sulu thunderbird[4903]: Couldn't map window 0x74f6555f93e0 as subsurface because its parent is not mapped.
Oct 21 17:31:05 sulu org_kde_powerdevil[2557]: dh=Display_Handle[i2c-6: fd=131], Replacing adjusted sleep multiplier 0.00 with 1.00 for SE_POST_WRITE or SE_POST_SAVE_SETTINGS
Oct 21 17:31:07 sulu kscreenlocker_greet[74856]: pam_systemd_home(kde:auth): New sd-bus connection (system-bus-pam-systemd-home-74856) opened.
Oct 21 17:31:09 sulu kdeconnectd[2779]: 2024-10-21T17:31:09 kdeconnect.core: Error sending MDNS query response
Oct 21 17:31:10 sulu kscreenlocker_greet[74856]: Failed to write to the pipe: Bad file descriptor.
Oct 21 17:31:24 sulu firefox[3792]: Unable to load ew-resize from the cursor theme
"""

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

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

Hey, I think I have the same problem. I have also noticed that, when the external screen is connected, the "Shutdown", "Restart", and "Sleep" buttons are greyed out and not working. My journalctl output is very similar to Jan Hambrecht's.

I also encounter this same bug. Shouldn't it be marked as a bug of the Breeze (SDDM) theme?

Created attachment 175178 [details]
text logs from journalctl for sddm

I'm experiencing a login issue with KDE Plasma where the login screen freezes after entering my password. This problem specifically occurs when my System76 Pangolin 15 laptop is connected to an external monitor via HDMI using a dock. Here are some details:

System: System76 Pangolin 15
Distribution: EndeavourOS (based on Arch, with KDE Plasma)
Plasma Version: 6.2.2
Qt Version: 6.8.0

Workarounds Attempted:
When connected to my docking station, I can see the login screen perfectly and enter my password. But nothing happens by clicking “Login” or hitting the “Enter” key.

I have ensured that the docking station model is fully compatible with my version of KDE Plasma and my laptop’s hardware (JSAUX 12-Port RGB Docking Station Model:HB1201B).

I can successfully login while the laptop is displaying only to the laptop display and is not connected to the dock or external monitor. After that, I can plug back into the dock and the external monitor functions properly with my KDE/Plasma desktop running SDDM.

I have made sure my system and all KDE/Plasma components are up to date, but the problem persists.

I have tried setting the configuration to extend or mirror displays while connected to the dock to see if there’s a setting that might bypass the login issue. But no matter what I do, the problem with the login while connected to the dock is reproduced.

Logs:
Attached to comment 26 are logs from journalctl for the relevant time frame

(In reply to Alexander Stehlik from comment #5)
> Can confirm the issue.
> 
> After switching the SDDM theme from "Breeze" to "Maldives" the login worked
> again. After switching back the error also came back.
> 
> Maybe this helps finding the issue.

Switching to Andromeda (another sddm theme) the login worked agian.
It is, indeed, a bug on Breeze theme, not SDDM itself.

Yep, Breeze SDDM theme + QT 6.8 = broken SDDM.

I saw this exactly once on my work laptop, but am unable to reproduce it using sddm-greeter-qt6 --testing.

The log from comment 26 shows:

Okt 19 17:49:29  sddm-greeter-qt6[850]: Loading file:///usr/share/sddm/themes/breeze/Main.qml...
Okt 19 17:49:29  sddm-greeter-qt6[850]: libpng warning: iCCP: known incorrect sRGB profile
Okt 19 17:49:30  sddm-greeter-qt6[850]: Adding view for "eDP1" QRect(0,0 1920x1080)
Okt 19 17:49:30  sddm-greeter-qt6[850]: Loading file:///usr/share/sddm/themes/breeze/Main.qml...
Okt 19 17:49:30  sddm-greeter-qt6[850]: Adding view for "DP1-2" QRect(0,0 1920x1080)
Okt 19 17:49:30  sddm-greeter-qt6[850]: Message received from daemon: Capabilities
Okt 19 17:49:30  sddm-greeter-qt6[850]: file:///usr/share/sddm/themes/breeze/Main.qml:221:25: Unable to assign [undefined] to bool
Okt 19 17:49:30  sddm-greeter-qt6[850]: file:///usr/share/sddm/themes/breeze/Main.qml:215:25: Unable to assign [undefined] to bool
Okt 19 17:49:30  sddm-greeter-qt6[850]: file:///usr/share/sddm/themes/breeze/Main.qml:209:25: Unable to assign [undefined] to bool
Okt 19 17:49:30  sddm-greeter-qt6[850]: Message received from daemon: HostName
Okt 19 17:49:32  sddm-greeter-qt6[850]: file:///usr/share/sddm/themes/breeze/Login.qml:133:13: QML Connections: Detected function "onLoginFailed" in Connections element. This is probably intended to be a signal handler but no signal of the target matches the name.
Okt 19 17:49:32  sddm-greeter-qt6[850]: <Unknown File>: Can't assign to existing role 'icon' of different type [Url -> String]
Okt 19 17:49:32  sddm-greeter-qt6[850]: file:///usr/share/sddm/themes/breeze/Login.qml:134:17: Unable to assign QString to QObject*
Okt 19 17:49:32  sddm-greeter-qt6[850]: file:///usr/share/sddm/themes/breeze/Main.qml:348:25: Unable to assign [undefined] to bool
Okt 19 17:49:32  sddm-greeter-qt6[850]: file:///usr/share/sddm/themes/breeze/Main.qml:354:25: Unable to assign [undefined] to bool
Okt 19 17:49:32  sddm-greeter-qt6[850]: file:///usr/share/sddm/themes/breeze/Main.qml:360:25: Unable to assign [undefined] to bool
Okt 19 17:49:50  sddm-greeter-qt6[850]: file:///usr/share/sddm/themes/breeze/Main.qml:337:17 Parameter "username" is not declared. Injection of parameters into signal handlers is deprecated. Use JavaScript functions with formal parameters instead.
Okt 19 17:49:50  sddm-greeter-qt6[850]: file:///usr/share/sddm/themes/breeze/Main.qml:339: TypeError: Property 'login' of object Loader is not a function

The "Unable to assign [undefined]" errors can only happen if the "sddm" global property isn't set properly, which I don't see a way that can happen. They're also only printed once per occurence, i.e. only for one of the views.

That only the breeze theme is affected by this is also strange, the ones provided by sddm itself also rely on the context property.

Maybe one of the libraries the breeze theme pulls in breaks the QML engine somehow?

Can everyone affected answer these questions:
1. If you log in using the laptop screen rather than the external screen, does it work as expected?
2. What GPU(s) are present on your system, and which one is used to show the SDDM login screen?
3. Is SDDM set up in native Wayland mode, or X11 mode?
4. When you hit Enter or click the arrow button, does it *never* log in? Or does it *eventually* log in after 30-60 seconds?

Trying to get a sense of whether this is Bug 483163, Bug 494927, Bug 483094, some combination of them, or some new mutant thing triggered by Qt 6.8.

Thanks!

> 1. If you log in using the laptop screen rather than the external screen,
> does it work as expected?

I don't have a laptop screen, I have two 4k monitor, and only the right one works.

> 2. What GPU(s) are present on your system, and which one is used to show the
> SDDM login screen?

AMD Radeon RX 5700

> 3. Is SDDM set up in native Wayland mode, or X11 mode?

Not sure where to check.

> 4. When you hit Enter or click the arrow button, does it *never* log in? Or
> does it *eventually* log in after 30-60 seconds?

I don't know, never waited that long.

Currently I can't reproduce, since SDDM always crashes when using the breeze theme. Not sure if that's already reported somewhere..

(In reply to Nate Graham from comment #31)
> Can everyone affected answer these questions:
> 1. If you log in using the laptop screen rather than the external screen,
> does it work as expected?
> 2. What GPU(s) are present on your system, and which one is used to show the
> SDDM login screen?
> 3. Is SDDM set up in native Wayland mode, or X11 mode?
> 4. When you hit Enter or click the arrow button, does it *never* log in? Or
> does it *eventually* log in after 30-60 seconds?
> 
> Trying to get a sense of whether this is Bug 483163, Bug 494927, Bug 483094,
> some combination of them, or some new mutant thing triggered by Qt 6.8.
> 
> Thanks!

1. For me it only works on the external screen (which is DP-0, laptop screen DP-3)
2. Nvidia Quadro M1000
3. Afaik it's set to X11 mode, at least I don't use Wayland anywhere else
4. I waited like 5-10 minutes, it didn't log in or do anything at all until I used the login on my external screen

(In reply to Nate Graham from comment #31)
> Can everyone affected answer these questions:
> 1. If you log in using the laptop screen rather than the external screen,
> does it work as expected?
> 2. What GPU(s) are present on your system, and which one is used to show the
> SDDM login screen?
> 3. Is SDDM set up in native Wayland mode, or X11 mode?
> 4. When you hit Enter or click the arrow button, does it *never* log in? Or
> does it *eventually* log in after 30-60 seconds?

1. I am on a desktop, will only log in if i have 2 displays plugged in, the order of which is 1st does not seem to matter
2. RX 7900XTX
3. Wayland
4. Waited 10 minutes, and it was still broken, haven't bothered to wait for longer

(In reply to Nate Graham from comment #31)
> Can everyone affected answer these questions:
> 1. If you log in using the laptop screen rather than the external screen,
> does it work as expected?
It works only when unplugging any external display from the laptop, using only the laptop-screen.

> 2. What GPU(s) are present on your system, and which one is used to show the
> SDDM login screen?
* Intel integrated graphics (Core i7-12800H)
* NVidia RTX A2000 <- that one is used (with proprietary drivers)

> 3. Is SDDM set up in native Wayland mode, or X11 mode?
X11

> 4. When you hit Enter or click the arrow button, does it *never* log in? Or
> does it *eventually* log in after 30-60 seconds?
I also didn't bother to wait more than 10 minutes.

Thanks folks. Is anyone experiencing this with only an Intel GPU?

Also, Antonio, do you by any chance have a link to a Qt bug report about this?

(In reply to Nate Graham from comment #31)
> Can everyone affected answer these questions:
> 1. If you log in using the laptop screen rather than the external screen,
> does it work as expected?
> 2. What GPU(s) are present on your system, and which one is used to show the
> SDDM login screen?
> 3. Is SDDM set up in native Wayland mode, or X11 mode?
> 4. When you hit Enter or click the arrow button, does it *never* log in? Or
> does it *eventually* log in after 30-60 seconds?
> 
> Trying to get a sense of whether this is Bug 483163, Bug 494927, Bug 483094,
> some combination of them, or some new mutant thing triggered by Qt 6.8.
> 
> Thanks!

1. No, can only log in from external monitor.
2. GPU that runs SDDM (AMD Radeon Vega Series / Radeon Vega Mobile Series [Integrated] (Ryzen 7 4800H)), second GPU (NVIDIA GeForce GTX 1650 Mobile / Max-Q)
3. SDDM running X11, Plasma itself running Wayland
4. Never

(In reply to Nate Graham from comment #36)
> Thanks folks. Is anyone experiencing this with only an Intel GPU?

Yeah, I'm experiencing the issue and my computer has an Intel Corporation HD Graphics 620.

(In reply to Nate Graham from comment #36)
> Thanks folks. Is anyone experiencing this with only an Intel GPU?
> 
> Also, Antonio, do you by any chance have a link to a Qt bug report about
> this?

I am.
1. No
2. Intel Gpu with intel i5-1240
3. Sddm in native (need to confirm)
4. I didn't wait that much.

I can confirm that tomorrow

(In reply to Nate Graham from comment #31)
> Can everyone affected answer these questions:
> 1. If you log in using the laptop screen rather than the external screen,
> does it work as expected?
> 2. What GPU(s) are present on your system, and which one is used to show the
> SDDM login screen?
> 3. Is SDDM set up in native Wayland mode, or X11 mode?
> 4. When you hit Enter or click the arrow button, does it *never* log in? Or
> does it *eventually* log in after 30-60 seconds?
> 

1. In case of my setup, that's exactly what's happening.
2. Only Radeon 780m integrated graphics.
3. SDDM is set up in Wayland mode, however I can see (in logs) it reporting a failure to to start in Wayland mode and falling back to X11-user every time it tries to start on the external monitor.
4. On the external monitor it never logs in. The entire screen controls (buttons) seem to be "disabled" (grayed out), and hitting enter after typing in a password in that screen's input field makes it become "disabled" too.

(In reply to Nate Graham from comment #31)
> Can everyone affected answer these questions:
> 1. If you log in using the laptop screen rather than the external screen,
> does it work as expected?
> 2. What GPU(s) are present on your system, and which one is used to show the
> SDDM login screen?
> 3. Is SDDM set up in native Wayland mode, or X11 mode?
> 4. When you hit Enter or click the arrow button, does it *never* log in? Or
> does it *eventually* log in after 30-60 seconds?
> 
> Trying to get a sense of whether this is Bug 483163, Bug 494927, Bug 483094,
> some combination of them, or some new mutant thing triggered by Qt 6.8.
> 
> Thanks!

1. I don't have a laptop. It's a normal PC.
2. AMD GPU RX 6700XT (I also have a second Nvidia 4080SUPER in the PC but I only use it as a passthrough to a virtual machine)
3. Wayland
4. I've tried a few times for 2-3 minutes and then gave up. I've my monitor connected to a "Delock DisplayPort 2 - 1 Switch". Two different graphic cards are connected. One of them is the mentioned AMD GPU RX 6700XT which I use for my Linux PC. If the login doesn't work the first time after switching the monitor on, I switch to the second GPU of another PC, wait a few seconds and then switch back. After that I'm able to login as usual (so either hitting "enter" key works or clicking the ">" button on the right side of the password field).

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

(In reply to Nate Graham from comment #31)
> Can everyone affected answer these questions:
> 1. If you log in using the laptop screen rather than the external screen,
> does it work as expected?
> 2. What GPU(s) are present on your system, and which one is used to show the
> SDDM login screen?
> 3. Is SDDM set up in native Wayland mode, or X11 mode?
> 4. When you hit Enter or click the arrow button, does it *never* log in? Or
> does it *eventually* log in after 30-60 seconds?
> 
> Trying to get a sense of whether this is Bug 483163, Bug 494927, Bug 483094,
> some combination of them, or some new mutant thing triggered by Qt 6.8.
> 
> Thanks!

1. Not a laptop. I use three monitors on a desktop.
2. 6800 XT
3. Whatever is default when using wayland session. probably x11 since I've not created a conf file.
4. It never logs in and the password is greyed out. I believe the buttons will not work either but I haven't tried. Its like the step right before the password is accepted but the screen doesn't proceed.

I always have to use my third monitor. btw this problem exists on my primary monitor which seems arbitrary compared to the reports I've seen. My secondary monitor will never load a login screen (black/sleep it wakes on login). Maybe there was a point during plasma lifespan where all three monitors showed sddm but its almost always been that way.

Not sure how to edit my comment but if its useful primary monitor used DP port and the other two are HDMI. One of them using DP to HDMI cable.

(In reply to Nate Graham from comment #31)
> Can everyone affected answer these questions:
> 1. If you log in using the laptop screen rather than the external screen,
> does it work as expected?
> 2. What GPU(s) are present on your system, and which one is used to show the
> SDDM login screen?
> 3. Is SDDM set up in native Wayland mode, or X11 mode?
> 4. When you hit Enter or click the arrow button, does it *never* log in? Or
> does it *eventually* log in after 30-60 seconds?
> 
> Trying to get a sense of whether this is Bug 483163, Bug 494927, Bug 483094,
> some combination of them, or some new mutant thing triggered by Qt 6.8.
> 
> Thanks!

1. Desktop pc with 2 monitors. Primary is DP, the secondary is HDMI. Also my monitors are mirrored in SDDM so can't select the other one to login. 
2. 7900xtx
3. wayland
4. Doesn't login at all, waited a couple of minutes.

Hi Nate,

Here are the answers to your questions regarding the login issue with SDDM:

1) If you log in using the laptop screen rather than the external screen, does it work as expected?
1A) I can confirm that login attempts made on anything other than DP-0 doesn't work as expected when using the Breeze SDDM theme.

2) What GPU(s) are present on your system, and which one is used to show the SDDM login screen?
2A) The system has an AMD Radeon 680M. This is an integrated GPU, part of the Rembrandt architecture, and it is the one used for the SDDM login screen since there's no indication of any other GPU in use.

3) Is SDDM set up in native Wayland mode, or X11 mode?
3A) From the process list (ps aux | grep sddm), it appears that SDDM is running in X11 mode for the login screen, as evidenced by the /usr/lib/Xorg process. However, there's a command (/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland) that suggests after login, the system switches to a Wayland session after login:

>[nathanael@pangolin ~]$ ps aux | grep sddm
>root        1508  0.0  0.0 154016 21160 ?        Ssl  Oct25   0:00 /usr/bin/sddm
>root        1525  0.0  0.2 1111924 83836 tty2    Ssl+ Oct25   0:01 /usr/lib/Xorg -nolisten tcp -background none -seat seat0 vt2 -auth >/run/sddm/xauth_Oyyxra -noreset -displayfd 16
>root        1673  0.0  0.0  77476 21536 ?        S    Oct25   0:00 /usr/lib/sddm/sddm-helper --socket /tmp/sddm-auth-28e96db9-ae49-4cd7-93c4->69fca2a4ed00 --id 1 --start /usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland --user nathanael
>nathana+  988905  0.0  0.0   6392  3924 pts/1    S+   11:16   0:00 grep --color=auto sddm

>[nathanael@pangolin ~]$ echo $XDG_SESSION_TYPE
>wayland

4) When you hit Enter or click the arrow button, does it never log in? Or does it eventually log in after 30-60 seconds?
4A) The login screen on the external monitor (DP-1 connected as Primary) does not proceed to log in after entering the password; it simply freezes or remains as is, without logging in, even after waiting for an extended period. I can enter the password or interact with the login on the Screen 0 monitor (the laptop display).

Let me know if you need any more information!

This has started to happen on another laptop with KDE Neon User Edition installed after recent updates. Same behaviour: no way to log in from the external monitor' screen, but works from the laptop's one.

> 1. If you log in using the laptop screen rather than the external screen, does it work as expected?
Yes. I run a single monitor dock setup (with laptop display off/lid closed). If I take my laptop off the dock or open the laptop screen and login SDDM doesn't hang. Although, when I tried logging in today (taking my laptop off the dock *after* it entered S0 sleep before turning on), I wasn't able to login either.

> 2. What GPU(s) are present on your system, and which one is used to show the SDDM login screen?
I have an i5-1135g7 with an Iris XE G7 80 EU igpu only.

> 3. Is SDDM set up in native Wayland mode, or X11 mode?
X11

> 4. When you hit Enter or click the arrow button, does it *never* log in? Or does it *eventually* log in after 30-60 seconds?
I waited about ~10 minutes before giving up and switching TTYs to login. I presume not. It just hangs with the password input and button grayed out. The other display is unaffected.

(In reply to Miguel Rozsas from comment #28)
> Switching to Andromeda (another sddm theme) the login worked agian.
> It is, indeed, a bug on Breeze theme, not SDDM itself.

Problem is really in theme (or in UI components). There is theme based on Breeze, and it also has this problem: https://github.com/vinceliuice/Qogir-kde

But it can be partially fixed by removing this:
anchors {
    bottom: parent.bottom
    left: parent.left
    right: parent.right
    margins: Kirigami.Units.smallSpacing
}
in Main.qml (after id: footer line).

But the buttons ("Shutdown", "Restart", and "Sleep") still don't work.

By the way, I managed to brake Andromeda theme. Just replaced Input with PlasmaComponents.TextField in Login.qml (id: userNameInput) and buttons become unworkable.

Created attachment 175373 [details]
Logins, but buttons not work

Maybe it will be helpful. I really don't know what's going on here. I added font.pointSize and fontSize for some elements. Also removed anchors { ...
Now it works too (not buttons).

It's likely an issue with the QML garbage collector running in incremental mode. Using QV4_GC_TIMELIMIT=0 works around the issue. Credits for that go to fusionfuture.

I'll try debugging qtdeclarative a bit to gain further info for an upstream bug report.

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

Is there a reason why it currently uses X11 instead of Wayland?

(In reply to Nate Graham from comment #36)
> Thanks folks. Is anyone experiencing this with only an Intel GPU?
> 

Yes, I'm on a Lenovo Thinkpad with integrated Intel GPU:

Operating System: openSUSE Tumbleweed 20241028
KDE Plasma Version: 6.2.2
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
Kernel Version: 6.11.5-1-default (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz
Memory: 31.1 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics
Manufacturer: LENOVO
Product Name: 20XW0055GE
System Version: ThinkPad X1 Carbon Gen 9

I can enter my password on the second monitor, press enter and do not get logged in. I have to click on the monitor of the laptop, type the password there, press enter and then instantly get logged in. First time I encountered that bug I waited for some time (less than a minute) and somehow got the idea to try on the other screen.

(In reply to Fabian Vogt from comment #51)
> It's likely an issue with the QML garbage collector running in incremental
> mode. Using QV4_GC_TIMELIMIT=0 works around the issue. Credits for that go
> to fusionfuture.
> 
> I'll try debugging qtdeclarative a bit to gain further info for an upstream
> bug report.

Unfortunately I wasn't able to get enough info for a minimal reproducer. Upstream bug report: https://bugreports.qt.io/browse/QTBUG-130767

Maybe unrelated question, but is it still the plan to incubate SDDM into KDE as per https://invent.kde.org/plasma/plasma-desktop/-/issues/91?
Would that allow for quicker patches as this now seems to be an SDDM-specific Qt issue?

Anyways, hopefully it can be fixed soon!

Hello,

I have the same problem and my current workaround is just to switch to tty2, login, and unlock the graphical session with: 

      loginctl unlock-session c2


As explained here: https://bbs.archlinux.org/viewtopic.php?id=244007
I hope it can help others too.

(In reply to A. Kelly from comment #56)
> Maybe unrelated question, but is it still the plan to incubate SDDM into KDE
> as per https://invent.kde.org/plasma/plasma-desktop/-/issues/91?
> Would that allow for quicker patches as this now seems to be an
> SDDM-specific Qt issue?
> 
> Anyways, hopefully it can be fixed soon!

FWICT, this is an issue in Qt that needs to be fixed in Qt. While it is probably possible to work around it on the SDDM side, it's a change that might introduce other regressions instead. Whether SDDM is hosted on invent.kde.org or GitHub wouldn't make any difference in terms of developer speed or how quick distros pick up the patch.

I can confirm this bug on a multi monitor system with a machine using three monitors on which the central one is normally used for inputting the password. When doing it it gives a soft lock. When using the monitor to the right or to the left, the login proceeds. Haven't yet found any complaint from SDDM in the logs. 

Operating System: openSUSE Tumbleweed 20241102
KDE Plasma Version: 6.2.2
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
Kernel Version: 6.11.5-1-default (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics
Memory: 62.2 GiB of RAM
Graphics Processor: AMD Radeon Pro W5500
Product Name: X570 Phantom Gaming 4

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

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

Same here.

CPU: AMD Ryzen 7 5800H
Laptop: https://www.alza.cz/EN/lenovo-ideapad-5-pro-16ach6-storm-grey-metallic-d6801920.htm
OS: openSUSE Tumbleweed 20241104
KDE Plasma Version: 6.2.2
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
Kernel Version: 6.11.5-2-default (64-bit)

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

I'm affected as well. 

Operating System: openSUSE Tumbleweed 20241105
KDE Plasma Version: 6.2.2
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
Kernel Version: 6.11.6-2-default (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz
Memory: 7.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520

Same for me

Operating System: Manjaro Linux 
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
Kernel Version: 6.11.6-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 22 × Intel® Core™ Ultra 7 165H
Memory: 30.2 GiB of RAM
Graphics Processor: Mesa Intel® Arc

Fixed on :
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0

Yes, I can confirm it's fixed on those versions.

This is not fixed! I can confirm the bug still exists.

>[nathanael@pangolin ~]$ qmake6 -v
>QMake version 3.1
>Using Qt version 6.8.0 in /usr/lib
>[nathanael@pangolin ~]$ pacman -Q | grep kconfig
>kconfig 6.8.0-1
>kconfig5 5.116.0-1
>kconfigwidgets 6.8.0-1
>[nathanael@pangolin ~]$

From the output, I can see:

Qt Version: I am using Qt 6.8.0 as confirmed by qmake6 -v.
KDE Frameworks Versions:
kconfig: I have version 6.8.0-1 installed, which is part of the KDE Frameworks 6.
kconfig5: Alongside that, there's also kconfig5 at version 5.116.0-1, indicating that I have both KDE Frameworks 5 and 6 installed.
kconfigwidgets: This is at version 6.8.0-1, also from KDE Frameworks 6.

(In reply to Nathanael Ries from comment #68)
> This is not fixed! I can confirm the bug still exists.
> 
> >[nathanael@pangolin ~]$ qmake6 -v
> >QMake version 3.1
> >Using Qt version 6.8.0 in /usr/lib
> >[nathanael@pangolin ~]$ pacman -Q | grep kconfig
> >kconfig 6.8.0-1
> >kconfig5 5.116.0-1
> >kconfigwidgets 6.8.0-1
> >[nathanael@pangolin ~]$
> 
> From the output, I can see:
> 
> Qt Version: I am using Qt 6.8.0 as confirmed by qmake6 -v.
> KDE Frameworks Versions:
> kconfig: I have version 6.8.0-1 installed, which is part of the KDE
> Frameworks 6.
> kconfig5: Alongside that, there's also kconfig5 at version 5.116.0-1,
> indicating that I have both KDE Frameworks 5 and 6 installed.
> kconfigwidgets: This is at version 6.8.0-1, also from KDE Frameworks 6.


I am also running Plasma 6.2.3 and still have the same bug unresolved
>[nathanael@pangolin ~]$ plasmashell --version
>plasmashell 6.2.3

(In reply to Nathanael Ries from comment #69)
> (In reply to Nathanael Ries from comment #68)
> > This is not fixed! I can confirm the bug still exists.
> > 
> > >[nathanael@pangolin ~]$ qmake6 -v
> > >QMake version 3.1
> > >Using Qt version 6.8.0 in /usr/lib
> > >[nathanael@pangolin ~]$ pacman -Q | grep kconfig
> > >kconfig 6.8.0-1
> > >kconfig5 5.116.0-1
> > >kconfigwidgets 6.8.0-1
> > >[nathanael@pangolin ~]$
> > 
> > From the output, I can see:
> > 
> > Qt Version: I am using Qt 6.8.0 as confirmed by qmake6 -v.
> > KDE Frameworks Versions:
> > kconfig: I have version 6.8.0-1 installed, which is part of the KDE
> > Frameworks 6.
> > kconfig5: Alongside that, there's also kconfig5 at version 5.116.0-1,
> > indicating that I have both KDE Frameworks 5 and 6 installed.
> > kconfigwidgets: This is at version 6.8.0-1, also from KDE Frameworks 6.
> 
> 
> I am also running Plasma 6.2.3 and still have the same bug unresolved
> >[nathanael@pangolin ~]$ plasmashell --version
> >plasmashell 6.2.3

Heres my SDDM log of the error

Plasma 6.2.3
Qt 6.8.0
KDE Frameworks 6.8.0-1

[nathanael@pangolin ~]$ journalctl -b -2 -r | grep sddm
Nov 12 08:16:29 pangolin systemd[1]: sddm.service: Consumed 14.862s CPU time, 486.6M memory peak.
Nov 12 08:16:29 pangolin systemd[1]: sddm.service: Deactivated successfully.
Nov 12 08:16:29 pangolin sddm[1478]: Running display stop script  QList("/usr/share/sddm/scripts/Xstop")
Nov 12 08:16:29 pangolin sddm[1478]: Display server stopped.
Nov 12 08:16:29 pangolin systemd[1]: Removed slice Slice /system/dbus-:1.2-org.kde.kcontrol.kcmsddm.
Nov 12 08:16:29 pangolin systemd[1]: Stopped dbus-:1.2-org.kde.kcontrol.kcmsddm@0.service.
Nov 12 08:16:29 pangolin systemd[1]: dbus-:1.2-org.kde.kcontrol.kcmsddm@0.service: Deactivated successfully.
Nov 12 08:16:28 pangolin sddm[1478]: Display server stopping...
Nov 12 08:16:28 pangolin sddm[1478]: Socket server stopped.
Nov 12 08:16:28 pangolin sddm[1478]: Socket server stopping...
Nov 12 08:16:28 pangolin sddm[1478]: Signal received: SIGTERM
Nov 12 08:16:28 pangolin systemd[1]: Stopping dbus-:1.2-org.kde.kcontrol.kcmsddm@0.service...
Nov 12 08:16:28 pangolin sddm[1478]: Auth: sddm-helper exited with 1
Nov 12 08:16:28 pangolin sddm[1478]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
Nov 12 08:16:28 pangolin sddm[1478]: Auth: sddm-helper (--socket /tmp/sddm-auth-ca70063d-1fc5-49ab-bdb4-e64fa577fe39 --id 1 --start /usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland --user nathanael) crashed (exit code 1)
Nov 12 08:16:28 pangolin sddm[1478]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
Nov 12 08:16:28 pangolin sddm-helper[1610]: Signal received: SIGTERM
Nov 12 08:16:14 pangolin systemd[1]: Started dbus-:1.2-org.kde.kcontrol.kcmsddm@0.service.
Nov 12 08:16:14 pangolin systemd[1]: Created slice Slice /system/dbus-:1.2-org.kde.kcontrol.kcmsddm.
Nov 12 08:16:08 pangolin systemsettings[403262]: qrc:/kcm/kcm_sddm/main.qml:182:13: QML Image: Protocol "" is unknown

I suspect ultimately this issue has the same root cause as Bug 494927, in which a change to the garbage collection policy in Qt negatively affected code in the Breeze SDDM and lock screens.

(In reply to Nate Graham from comment #71)
> I suspect ultimately this issue has the same root cause as Bug 494927, in
> which a change to the garbage collection policy in Qt negatively affected
> code in the Breeze SDDM and lock screens.

Yes, that is already confirmed.

Looks like this is ultimately the same issue as Bug 494927. Both affect the Breeze lock or login theme; both manifest as controls being

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

Resolved under Tumbleweed for me.

Tumbleweed may have backported a prospective Qt patch mentioned in https://bugreports.qt.io/browse/QTBUG-130767. There's also https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/245 being worked on from the KDE side.

Also fixed for me on Tumbleweed.

(In reply to Nate Graham from comment #76)
> Tumbleweed may have backported a prospective Qt patch mentioned in
> https://bugreports.qt.io/browse/QTBUG-130767. There's also
> https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/245 being
> worked on from the KDE side.

Yep! Unfortunately the first Qt upstream patch caused an issue with spectacle, but the current version should work better. Once there are positive results I'll write to distros@ to recommend backports.

Positive result here, also tumbleweed. Thanks!

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

(In reply to Fabian Vogt from comment #78)
> positive results

Tests OK with the two new patches which just hit tumbleweed in the 13112024 image (qt6-declarative package rev 45)

Looks like this has been fixed with https://codereview.qt-project.org/c/qt/qtdeclarative/+/604180, phew. Thanks everyone for your diligent work to fix it and/or patience with the issue before that time!

Arch already landed the patch! Can confirm it is fixed for me now.

Confirmed resolved on my end as well in EndeavourOS

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

I'm on Qt 6.2.3 and I still see the issue happening: https://bugs.kde.org/show_bug.cgi?id=496461

(In reply to Marcos Junior from comment #86)
> I'm on Qt 6.2.3 and I still see the issue happening:
> https://bugs.kde.org/show_bug.cgi?id=496461

Edit: Qt Version: 6.8.0. Not sure when 6.8.2 is going to land on latest KDE Neon.