SDDM 0.21 Display Manager Released With Better Wayland Support, Qt6 Fixes

[phoronix]

Phoronix: SDDM 0.21 Display Manager Released With Better Wayland Support, Qt6 Fixes

Released last June was the SDDM 0.20 display manager with experimental Wayland support and other enhancements after being in development for three years. Out this morning is SDDM 0.21 as another step toward SDDM 1.0 with improved Wayland support and other enhancements to this Qt-tooled display manager...

https://www.phoronix.com/news/SDDM-0.21-Display-Manager

[avis]

You wouldn't believe it but in order for the display (actually "graphical login") manager to support Wayland it needs to implement ... a Wayland server. That sounds almost comical in its brutal complexity and senselessness. Please ignore this comment. I'm rending the air. No one cares.

[hedonist]

You wouldn't believe it but in order for the display (actually "graphical login") manager to support Wayland it needs to implement ... a Wayland server. That sounds almost comical in its brutal complexity and senselessness. Please ignore this comment. I'm rending the air. No one cares.

It actually doesnt need to run itself on wayland to boot a wayland session. The reason why sddm and other display managers are working on running themselves on wayland is futureproofing for when xorg eventually gets deprecated. (they still want to be able to actually function when xorg goes ka-put.)

Also, a display manager running itself on wayland is not very complex at all, think before you speak, thank you!

[hedonist]

Glad to see the better wayland support on sddm, great to see the linux desktop improving and progressing as always.

[r_a_trip]

You wouldn't believe it but in order for the display (actually "graphical login") manager to support Wayland it needs to implement ... a Wayland server. That sounds almost comical in its brutal complexity and senselessness. Please ignore this comment. I'm rending the air. No one cares.

A Graphical Login Manager running as a Wayland client needs to have a Wayland compositor to display. That's how the system works. Since a login manager isn't as complex as a full blown Desktop Environment, I assume they can get away with a compositor that just offers what the manager needs and no more.

[avis]

A Graphical Login Manager running as a Wayland client needs to have a Wayland compositor to display. That's how the system works. Since a login manager isn't as complex as a full blown Desktop Environment, I assume they can get away with a compositor that just offers what the manager needs and no more.

Only imagine we had a Wayland you know ... [common] display server which could simplify everything tremendously and offer the rich complexity to all its clients no matter the funding or resources behind them. Ah, no one needs that or cares about that. Again, it's KWin FTW! Mutter has massively been lagging and don't get me started on all other barebones Wayland compositors. What I strive towards is clearly not needed except when it is. Except when people get a subpar experience or limited features.

[varikonniemi]

When SDDM loads Qt libraries at startup, will Plasma and other Qt DE:s be able to use those libraries or will they load them again? It seems they should already be in memory so no loading time...

[user1]

Why don't they just make SDDM run on kwin_wayland instead of developing its own Wayland display server implementation? I've read somewhere that on Fedora KDE, SDDM runs on Wayland by default using kwin_wayland.

[nerdopolis]

They aren't writing their own whole Wayland compositor, they are using Weston

https://github.com/sddm/sddm/commit/dfc3bdb6510a12a6435e8cdb0bf151aa83aa51d5

[skeevy420]

Only imagine we had a Wayland you know ... [common] display server which could simplify everything tremendously and offer the rich complexity to all its clients no matter the funding or resources behind them. Ah, no one needs that or cares about that. Again, it's KWin FTW! Mutter has massively been lagging and don't get me started on all other barebones Wayland compositors. What I strive towards is clearly not needed except when it is. Except when people get a subpar experience or limited features.

As much as I'd like to agree with you about a common display server, all you have to do is look at GNOME to understand why Common isn't always the best idea. How many GNOME MRs sit in pending for years on end because they don't align with the RHEL or GNOME vision? How many GNOME shell alternatives have completely forked away from GNOME because GNOME didn't want to play ball? The RHEL backed Common Desktop Environment didn't work out so well for Budgie and COSMIC due to all the politics involved in open source.

As optimistic as I am, I know that those same politics combined with capital will come into play with a Common Display Server and that in and of itself will stop smaller projects in their tracks. Wayland being a protocol means that devs only have to write code to the specs nor are they beholden to The Common Display Server Committee when it comes to adding new parts to the CDS. Wayland being a protocol means a single unfunded dev can code to their heart's content and not worry about the Committee wondering if they're going to be still doing it a year from now; money and bus factor concerns.

Protocols and Stable APIs means an abrasive guy like Kent can just do their own thing and not worry about pissing off the Committee over something as dumb as not using Git correctly. As nice as common can be when it's done right, going common assumes that everyone can play nicely. It also assumes that common will accept everyone's MRs for whatever reason which is kind of what made X.org become such a clusterfuck and a security hazard. Wayland being a protocol only assumes that people will follow some basic instructions while allowing them to do it their way.

While that seems antithesis to the UNIX philosophy of "Do one thing well.", it really isn't. Now we have a display server that only handles logging in and doing that well. We have one that handles remote connections and does that well. We have one that handles games, graphics, and scaling and does that well. We have ones to manage our floating windows. We have ones to manage our tiling windows. Multiple Wayland Servers allows people to work on a smaller project, to figure out how to do a new thing well, and then it allows them to write up how they did the new thing so well, make a new Wayland protocol, so that others can now do that one new thing well, too, if they so happen to have the need to do that one new thing well.