Kicked out to SDDM Login Screen some time after logging in

[SeraphFive]

Describe the bug

Hello everyone, and thank you in advance for taking the time to look at this.

About two out of three boots, after entering my password, there is an unusually long delay before I can access the desktop (black screen). Once I get there, after about a minute, I am taken back to the login screen.
Trying to log in again causes the SDDM greeter to freeze. I can access the other TTYs, TTY1 shows the SDDM greeter, TTY2 shows my DE session (marked as "closing" in loginctl).
Most of the time, after a reboot, it works fine on the first try.

What did you expect to happen?

The session should start opening immediately after entering the password (with the loading animation), and there should be no sudden return to the SDDM greeter.

Session Logs

https://paste.centos.org/view/245ce9ac
EDIT: The pastebin seems to expire after 24h. I still have the journalctl log saved so if someone reading this actually wants to take a look, tell me in this thread and I'll update this link with a new pastebin as soon as possible.

Hardware

Desktop PC
AMD Ryzen 9 9950X3D
AMD Radeon RX 9070 XT
Bazzite Stable (43.20251029)
ujust device-info result : https://paste.centos.org/view/cb083b90
EDIT: Same as above :(

Extra information or context

The journalctl log might be a bit lengthy as I used the TTY2 "closing" session to file this bug report and took a bit of time doing so. Logs marked to be after 14:25 or so are probably unrelated.

This problem looks similar to me in many ways to what has been reported and discussed in issue #1704. However I don't have an NVIDIA GPU. There is also a mention of disabling SELinux as a solution but, for obvious reasons, I'm not a big fan of this option.

Let me know if I can add more info that could be of any help, and thank you very much for your time.

[tsilvs]

May be related to #3325

[SeraphFive]

Yup, it may be! Quite interesting how across the few declared issues that are reporting such behaviour, it looks like it's related to monitors.
I'll try to look into this as I know for a fact I've been playing with virtual displays for usage with Sunshine/Moonlight. The issue started appearing way after doing this so I didn't think it'd be related.

I'll give an update when I'll be able to give it a bit of testing!
Also the pastebins in my original post have expired, I'll try to update it asap to a permanent one at least for the system logs.

[Dark-Thoughts]

If you used Wallpaper Engine, change the background to something static. The plugin was very broken before, and is completely busted now.

#3423

[SeraphFive]

Thank you very much for your suggestion. Sadly, I've not been using Wallpaper Engine at all on this computer, only a good old static background. I doubt it could have caused that issue in my case, at least I think.

However it's very good to know! I'll keep this in mind before attempting to use that plugin, at least for now "^^

[Dark-Thoughts]

I don't think you can even select it anymore. If you had it selected previously you'd have an invalid / empty selection as wallpaper, which caused the issue for me.

[SeraphFive]

Quick update.
My system got the 43.20251102 Stable update and since then, the issue hasn't happened again yet. This versions' commits listed in the changelog shows that there has been some work on SDDM, especially commit 4bcbc00 (and subsequent commits on this matter) aiming to fix what looks like timing issues between SDDM and graphics drivers. This checks out with my issue behaving randomly and differently with reboots, and previous appearances of it relating to monitors, etc.

I'm going to give it just a bit of time to make sure it isn't a coincidence, and if everything is back to normal, my issue could be closed!

[SeraphFive]

No more issues since last time! I think it was fixed! Thank you all :)