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

[intelfx]

Perhaps I was not clear enough. Why does a DM need to implement a Wayland-anything in order to work? Why can't it handle painting stuff on its own? You know, the good, old, put a picture in the background, two input fields and some buttons on top and be done with it.

Same reason why you pick an existing OS (Linux) and an existing high-level programming language to write your own programs instead of doing it all in asm using BIOS APIs. You just need to print some strings, just do it with int 0x10, to hell with all the bloat!

Y'know, code reuse. Because something has to implement those "input fields and buttons", and that something is probably an existing graphics library like Qt, which probably speaks Wayland.

[tesfabpel]

Now we're getting warmer. What would those reasons be? I'm asking because 30 years ago I used to draw things more complicated than a login screen without talking to a display server. In Pascal.

You don't just need to paint things... You have to handle input from mouse, keyboards and support different keyboard layouts! What about touchscreens without keyboards? You may need to use a virtual keyboard if you want to support those... So, good luck if you try to do it all by yourself.

[pabloski]

Perhaps I was not clear enough. Why does a DM need to implement a Wayland-anything in order to work? Why can't it handle painting stuff on its own? You know, the good, old, put a picture in the background, two input fields and some buttons on top and be done with it.

Because it needs to write on the screen!!! And if you don't want to use Wayland you can write directly to the framebuffer ala DirectFB! The Wayland compositor being run after you will not complain at all. And you won't even need to reset the graphics mode ( like it happened with Xorg ).

But the main point is here that Wayland is a protocol, a mix of various specifications. SDDM doesn't implement ALL of Wayland, just the parts needed to write on the screen. And they do it using the most crappy Wayland piece of code, Weston!! This shows they use the bare minimum of Wayland functionality. Weston calls it kiosk mode, just a glorified framebuffer.

[pabloski]

Now we're getting warmer. What would those reasons be? I'm asking because 30 years ago I used to draw things more complicated than a login screen without talking to a display server. In Pascal.

This is the problem. You assume that Wayland is like Xorg. There is no display server at all. Just a set of rules on how to do some things. The rules about drawing on the screen are that you use DRM and Mesa for 3D acceleration. The fact they are using Weston is for code reuse and nothing more. I know it can be confusing when you see your display manager using libwayland-server. But these libs are just implementations of the data structured and the wire protocol. The interesting part is in weston ( there is even libweston, a nice try on decoupling the Wayland implementation from Weston the executable ).

I agree that SDDM choice to call the Weston executable is "strange". They just copied the qtwayland way of doing it. They could have used wlroots instead, statically linking only the necessary bits. But considering they use qml for a DM, I am sure they aren't particularly worried about bloating.

[mrg666]

Now we're getting warmer. What would those reasons be? I'm asking because 30 years ago I used to draw things more complicated than a login screen without talking to a display server. In Pascal.

You were using unit "graph" at least if it was DOS. You had to use "winapi" additionally on Windows.