Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mrg666
    replied
    Originally posted by bug77 View Post

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

    Leave a comment:


  • pabloski
    replied
    Originally posted by bug77 View Post

    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.

    Leave a comment:


  • pabloski
    replied
    Originally posted by bug77 View Post

    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.

    Leave a comment:


  • tesfabpel
    replied
    Originally posted by bug77 View Post

    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.

    Leave a comment:


  • intelfx
    replied
    Originally posted by bug77 View Post

    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.
    Last edited by intelfx; 27 February 2024, 03:41 AM.

    Leave a comment:


  • caligula
    replied
    Originally posted by Noitatsidem View Post
    3. Security considerations: Implementing rendering directly within the display manager could introduce potential security vulnerabilities. By relying on separate, well-tested systems like Xorg or Wayland, the attack surface is potentially reduced, as these dedicated systems are designed with security in mind.​
    Most display managers run as root. They have full access to everything running on the system. E.g. I don't think rootless X works for all. At least on my Nvidia system the proprietary drivers crash if I try to enable rootless X.

    5. Resource efficiency: Implementing advanced graphics functionalities within the display manager could potentially increase its resource requirements. Utilizing dedicated systems like Xorg or Wayland, which are optimized for these tasks, can help maintain a more lightweight and resource-efficient display manager.
    Did you know that most display managers stay active in the background, without freeing any resources? That's why using e.g. gdm most likely uses 300-500 MB more memory than by starting X directly with startx. There's a background X process active that won't free anything. Not really a problem these days as people can easily afford wasting 500 MB for this. On lower end systems it's a problem.

    Leave a comment:


  • Noitatsidem
    replied
    Originally posted by bug77 View Post

    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.
    According to gemini:


    There are several key reasons why a display manager typically doesn't handle rendering and other graphical tasks itself:

    1. Focus on core functionality: Display managers are primarily designed to manage the login process. Adding complex features like rendering and window management would significantly increase their complexity and potential for bugs. This focus allows them to be more efficient and reliable in their core function.

    2. Leverage existing technologies: Graphical rendering and window management are already well-established functionalities handled by dedicated systems like Xorg or Wayland. Utilizing these existing solutions allows display managers to benefit from their mature development, extensive testing, and established hardware compatibility.

    3. Security considerations: Implementing rendering directly within the display manager could introduce potential security vulnerabilities. By relying on separate, well-tested systems like Xorg or Wayland, the attack surface is potentially reduced, as these dedicated systems are designed with security in mind.

    4. Flexibility and modularity: By delegating rendering and window management to separate systems, display managers become more modular and adaptable. They can work with different desktop environments and graphics systems as long as they support the chosen protocol (Xorg or Wayland). This allows for a more flexible and customizable graphical experience for users.

    5. Resource efficiency: Implementing advanced graphics functionalities within the display manager could potentially increase its resource requirements. Utilizing dedicated systems like Xorg or Wayland, which are optimized for these tasks, can help maintain a more lightweight and resource-efficient display manager.

    In summary, while display managers could technically handle rendering and window management, it's generally considered inefficient and unnecessary due to existing, well-developed solutions like Xorg and Wayland. Focusing on core functionality, leveraging existing technologies, and maintaining security, flexibility, and efficiency are key factors in keeping display managers specialized and effective.

    Leave a comment:


  • Brittle2
    replied
    Originally posted by hedonist View Post

    Also, a display manager running itself on wayland is not very complex at all, think before you speak, thank you!
    don't waste your time, he's the guy that literally got banned from wayland protocols for spam being an a*hole​


    Leave a comment:


  • bug77
    replied
    Originally posted by Nocifer View Post
    If I had to venture a guess, I'd say it's for the same reason(s) that a DE or any other program can't (or shouldn't) handle painting stuff on its own.
    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.

    Leave a comment:


  • caligula
    replied
    Originally posted by hedonist View Post
    Glad to see the better wayland support on sddm, great to see the linux desktop improving and progressing as always.
    At least the previous version had issues with gnome. Screen locking didn't work. Neither did dpms energy saving.

    Leave a comment:

Working...
X