Unfortunately for right now, KDE has recently released major version 6, which is also about as stable as Windows (meaning, very not). This is reminiscent of the KDE 4 transition and much worse than the KDE 5 one.
For example, half the time I try to log in or unlock the screen, it just ignores my password. Fortunately, I have discovered that pressing Escape triggers a crash, and I have to deliberately trigger a segfault by pressing Escape, in hopes that next time the password will be accepted.
Plasma 6 is nearly two years old, and is totally fine in my experience. The transition was more like 5.x to 5.y. The biggest change is Wayland by default (X11 is currently still available, so might be worth a try).
It sounds like your problem may be with SDDM (the login screen program) rather than Plasma itself. You could try an alternative: https://alternativeto.net/software/sddm/
Changing the KDE theme into something other than the default Breeze breaks the whole Plasma: black screen with a cursor instead of the SDDM login screen. Hit this while setting up an Arch system for my wife, spent hours rebooting with recovery USB image and tweaking configuration until it all worked again.
Point of order: SDDM is entirely unrelated to the KDE project.
I've been using the Breeze Dark theme for approximately forever and I've never run into the problem you're describing. However, I've very rarely used SDDM... I find its default rainbow-colored background intolerable and use LightDM instead.
Do you happen to remember configuration that you ended up having to change, and is that computer running Nvidia graphics hardware with the closed-source drivers?
I went to System Settings > Themes > Login Screen (SDDM) in KDE settings and changed from the default Breeze to Maldives, and that broke SDDM login screen to black text mode with a cursor. Later searching for fixes I found that only Breeze was compatible with Qt 6.x, and any other choices there would break SDDM the same way (I did not try it though).
First, I had to figure out how to manually mount LUKS-encrypted laptop drive while booting from a USB stick, that took a while.
Trying to recover, I re-installed kde, sddm and sdd-kcm and qt5-declarative packages. Still broken. I made sure /etc/sddm.conf was the default configuration, still broken. Then finally I stumbled upon /etc/sddm.conf.d/kde_settings.conf, which was still overriding defaults to Maldives. Deleting it finally fixed the SDDM login.
My wife was thoroughly not impressed with Linux out-of-box experience!
No Nvidia graphics, this was a Lenovo Yoga laptop with AMD graphics.
SDDM is garbage and I've switched to using lemurs now (for whatever reason graphical display managers are terrible. GDM doesn't allow changing the mouse cursor theme, SDDM doesn't show battery percentage, LightDM doesn't do fonts properly,... the KDE people are apparently working on a new DM, but the info I got was vague as anything and may as well have been referring to the KDE LightDM greeter).
I wouldn't say that SDDM is garbage. Apparently, it sets the environment variables & etc. needed to enable automatic HiDPI scaling that a shockingly large number of Wayland proponents insist Xorg doesn't support. [0][1]
[1] Manual scaling (even non-integer scaling) works fine as long as you have a settings editor that will speak the XSETTINGS protocol, and a daemon running that can be queried. GNOME has both by default. KDE has the settings editor, and you might need to install xsettingsd or similar. The quirk I've found is that while GTK programs accept the display scaling changes immediately, QT programs must be restarted to adopt the changes.
> automatic HiDPI scaling that a shockingly large number of Wayland proponents insist Xorg doesn't support.
Assuming they know what they're talking about and not just parroting whatever they read others mention, usually when someone says that "Wayland does $THING that X11/Xorg doesn't do", this is really a shortcut for "X11/Xorg could technically do $THING, if enough developers and projects cared about it, but that would be a massive undertaking and it is easier to convince developers do $THING if we can control most of the stack to only do $THING in one particular way we want by working from a clean slate".
Since you mentioned environment variables, not sure what SDDM exactly is doing, but in the case of HiDPI scaling under Xorg the only method for HiDPI i'm aware of that uses environment variables is Qt's `QT_SCREEN_SCALE_FACTORS` which is a semicolon-separated list of per-screen scaling factors that Qt applications can use to automatically scale themselves depending on the screen the window/application is in. Considering SDDM is written in Qt, i'll guess that this is what it set.
But the thing is, this is far from enough if you want "robust" support under X11/Xorg. The reason is that a typical X application under a typical X desktop has multiple components: an X server (which i'm going to assume it is Xorg for now - other X servers are basically Xorg forks and sync with its features), a window manager, an optional desktop compositor and a widget toolkit on the application's side (not strictly needed as an app can use its own adhoc code for that but let's assume it uses one since this doesn't really matter in this case).
The behavior you need for robust HiDPI support is for the application to use the proper scaling for each of its toplevel windows depending on the connected output the window is in (note: this may or may not actually be relevant to DPI - someone may have bad eyesight and want their 27" 1440p monitor to be 150% scaled) and have that be done automatically - ideally, transparently from the user's perspective - as they move windows between outputs and/or add/remove outputs (e.g. connecting/disconnecting or turning on/off a graphics tablet with an embedded monitor would add/remove an output).
Now, technically, Xorg does provide the necessary core functionality to implement the above, however the issues begin when you start considering who is going to implement it and what part of the stack is responsible for which aspect of supporting window scaling.
Ideally, what you'd want is for applications should be able to scale each of their toplevel windows arbitrarily based on notifications from the underlying system as the user interacts with the application windows (note: this is not necessarily limited to just the user moving windows between outputs - a user could, for example, select an option from their window manager to scale a window at 200% or 300% - this could be useful when doing video streaming or recording videos for example).
So, in an ideal world, the following should happen under X11/Xorg:
1. Widget toolkits can scale their widgets arbitrarily (ideally not just at fractional level but also sub-100% level too - useful when using secondary screens with a low resolution).
2. Window managers can receive RandR events for output DPI changes and use that information to maintain a scaling factor for each output (the user could also specify custom per-output scaling too).
3. As the user interacts with the windows, the window manager sends notifications to the windows/applications whenever a window needs its scale changed. The widget toolkits use these notifications to scale their windows' contents.
Ignoring a few details, the above is basically what Wayland does since it started from a clean slate where they could dictate everything from scratch.
However X11/Xorg already has a lot of software already written for it and there are a few snags in the way:
1. Pretty much no toolkit supported arbitrary scaling, so they had to be extended for it. Since Wayland needed that, toolkits that need to support it added the functionality anyway (e.g. Qt and Gtk) though not without issues along the way (AFAIK Gtk didn't support fractional scaling for a long time). Though not all toolkits have support for this.
2. Window managers must be extended to monitor outputs via RandR and send appropriate notifications whenever windows move across outputs to those windows. This would also need some new notification protocol (most likely a new version of EWMH). However...
3. ...toolkits must also be extended to support these notifications - supporting scaling isn't enough if they do not know when to scale. This introduces a problem because...
4. ...window managers will have to deal with toolkits not supporting the notifications. One way would be to just ignore them, but another way is to do the scaling themselves. However, there is another issue here.
5. When using (and having enabled) a desktop compositor scaling can be easy (especially when dealing with edge cases like a window lying across the edge between two monitors :-P), but without one, the window manager needs to scale the window itself (there was a Xorg branch by Keith Packard that introduced server-side window scaling but AFAIK it was never merged) without affecting the rest of the desktop - and of course do the appropriate coordinate transformations for various events (e.g. mouse motion). Moreover since a desktop compositor can be a separate program than a window manager (many -if not most- X11 window managers are not desktop compositors), they both need to somehow coordinate with each other.
6. Since this requires all window managers (and desktop compositors) to be updated, the inevitable result is that there will be a lot of them that will not be updated for quite some time, so applications (or realistically, widget toolkits) will need to also handle HiDPI scaling themselves by doing the RandR queries and automatically sizing their own windows based on output. This is a subpar option because the application does not know the window manager's own state and you can end up with the two "fighting" with each other. Also the window manager cannot do desktop-wide configurations (it is actually blind to them).
7. Obviously whatever protocols in place (as i wrote above, probably a new EWMH version) are used, they'll also need to let the components (window manager, widget toolkit) provide information for when any of the above are in place so the proper action is taken (e.g. a toolkit should not try to do the output tracking itself if the window manager supports it and a window manager should not try to do scaling itself if the widget toolkit supports it - but both need to inform the other about this).
As you can hopefully imagine, the above require the developers of all window managers, all desktop compositors, all widget toolkits and applications not only to coordinate with each other but also handle various cases in case the user used something in the stack that did not support things.
With Wayland since everything was done from scratch, there were less people that needed to be convinced to cooperate - and in practice since Wayland originated from RedHat and the GNOME ecosystem, convincing the appropriate GNOME and Gtk developers to cooperate was probably a coffee break away :-P. Meanwhile Qt would already need to add (or already had, not sure when it was added) support for scaling/HiDPI anyway for Windows and macOS, so the infrastructure was there.
The current situation is that Qt, currently, supports the #6 i mentioned above since it can be implemented without needing support from window managers, desktop compositors or specifying new protocols (something that seems to be much harder than it should be - e.g. AFAIK Cinnamon implemented a very trivial X attribute for displaying a percentage for windows in a taskbar/icon overlay -think of download percentage- but despite the developers' attempt to have others adopt it, i do not think it saw much adoption). But this is really the "fallback solution" when everything else is just not there, it is not the ideal one.
That said, from a technical perspective there is nothing theoretically stopping Xorg desktop environments having top-notch robust HiDPI support. What blocks everything is convincing the developers of the various components of the desktop stack to cooperate, implement and support it.
> ...the above require the developers of all window managers, all desktop compositors, all widget toolkits and applications not only to coordinate with each other but also handle various cases...
/me wonders if OP has been paying attention to how "consensus building" actually ends up working in the Wayland world
> With Wayland since everything was done from scratch, there were less people that needed to be convinced to cooperate - and in practice since Wayland originated from RedHat and the GNOME ecosystem, convincing the appropriate GNOME and Gtk developers to cooperate was probably a coffee break away...
/me realizes that the answer is "No. Not really."
To be less droll:
1) Through xrandr, even windowmaker provides the data required for an application to know the properties of the monitor that > 50% of each of its windows are on. Given how much nicer xrandr was than xinerama, WMs that cared about multihead moved over to it fairly quickly.
2) I'm certain that not every WM provides the information required for screen-DPI- and screen-scaling-aware programs to scale as desired. But, the "Wayland is a lightweight protocol that makes few policy decisions" motto turns out to mean that for most decisions that users care about, each Wayland WM (or whatever the Wayland terminology for the Wayland equivalent is) needs to re-make and reimplement those decisions. Feature fragmentation has been bad. So, no, if you're not going to hold Wayland to the "Every WM must implement all the features" standard, then you're not going to demand that of Xorg WMs.
3) You happened to mention the two things that's needed for Xorg to support both HiDPI and non-integer scaling... GUI drawing library support and a common protocol for setting and retrieving user-driven adjustments to the "natural" rendering scale given the display DPI. XRandR [0] has either always, or has effectively always provided the information required for GUI toolkits to scale their widgets according to a screen's DPI. And the XSETTINGS protocol [1] is used to store the user-commanded scaling adjustment. Glancing at the release date for those two things, they either substantially predate or came out very, very shortly after Wayland's initial release.
Weird. It's almost as if we were waiting on the GUI toolkits to use what Xorg had been providing them for ages.
Anyway. Check footnote 1 in the comment you replied to for the on-the-ground details on GUI toolkit render scaling on Xorg from an end-user's perspective.
[0] adopted no later than 2007
[1] first proposed in 2001 and adopted no later than 2009 (though, if I cared to spend more than a few minutes on the search, I expect I'd find that it was adopted much earlier)
What i described was about Wayland, GNOME and Gtk specifically, not the entire "Wayland world". Wayland has been a mess that could have been completely avoided if people just tried to fix any issues with Xorg instead of falsely claiming that Xorg cannot be fixed and we'd had proper support for HiDPI, HDR, mixed refresh rate configurations with compositing and all sorts of other nice things at least a decade ago instead of creating a pointless schism in the already tiny Linux desktop ecosystem but ultimately you cannot control what other people spend their time on.
1) Window Maker does not provide anything to any application, if applications need such information they have to use the extension APIs themselves. IF there was an agreed upon protocol for window managers notifying applications to scale themselves, then Window Maker could implement it. But such a protocol does not exist.
2) Window managers do not provide any information there at all since there is no such support. And yes, all Wayland compositors do need to implement that stuff, but because it started from a clean slate and Wayland compositors had to be written from scratch anyway, it was easier to convince developers to do that because they self-selected to go through the effort of making a Wayland compositor in the first place. As i wrote in my original post, the issue here isn't if something would be written or not, but convincing the people who work on the projects. It is mainly a social issue, not a technical one.
3) Yes, without any other support in place, GUI toolkits and other applications can use the information exposed RandR to implement scaling themselves but, as i already wrote, this is a fallback solution because the rest of what i describe is not there. This is far from having robust support, ignores things like custom scaling options, handling moving windows between desktops and support for applications that do not do scaling themselves (which is many of them), among other things.
All of the above are things i already addressed in my original message BTW and again, the issue is not technical but social/political. It is about convincing people to cooperate, not if something is technically possible (and let's be honest, it isn't like Xorg's code is written in stone, if something is currently impossible, the code could be extended to make it possible).
Gotta be something specific to your machine - for me version 6 is way more stable than 5 was. That line would crash doing sillies things like resizing task bar or applying settings. Now I feel as good with CachyOS and Plasma 6.5.2 as I was with W2K or W7
As someone who's been bouncing back and forth between Arch and Tumbleweed for a while now I had a very different experience. The transition from KDE 4 to KDE Plasma 5 was terrible, plasmashell would crash all the time, tons of stuff would break between updates, and I had to switch to running awesome for a while (which is fine, awesome is pretty great). The transition from Plasma 5 to Plasma 6 was basically 'these 2 KWin scripts don't work any more' and everything else was fine.
The only issue I have on my Plasma 6 laptop is also lock-screen related: About 20% of the time keyboard input is ignored/blocked after coming back from sleep. Closing and reopening the lid usually sorts it. Haven't seen what you describe.
I did have some earlier snags which all went away after switching from Wayland session to X11 session.
For example, half the time I try to log in or unlock the screen, it just ignores my password. Fortunately, I have discovered that pressing Escape triggers a crash, and I have to deliberately trigger a segfault by pressing Escape, in hopes that next time the password will be accepted.