6 ms·

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 t

by skirmish 11mo ago

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. Wouldn't call it stable.

simoncion 11mo ago
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?
- skirmish 11mo ago
  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.
tmtvl 11mo ago
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).
- simoncion 11mo ago
  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] [0] <https://wiki.archlinux.org/title/SDDM#Enable_HiDPI https://wiki.archlinux.org/title/SDDM#Enable_HiDPI> [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.
  - badsectoracula 11mo ago
    > 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.

simoncion 11mo ago

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?

skirmish 11mo ago
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.

tmtvl 11mo ago

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).

simoncion 11mo ago
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] [0] <https://wiki.archlinux.org/title/SDDM#Enable_HiDPI https://wiki.archlinux.org/title/SDDM#Enable_HiDPI> [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.
- badsectoracula 11mo ago
  > 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.