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

  • #31
    Originally posted by skeevy420 View Post
    ...

    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.

    ....
    Your whole comment was very good. The more I wrap my head around this Linux graphics stuff, the more everything you said in it makes sense. Much appreciated.

    Comment


    • #32
      Am I the only one who notices that the pointer feels different in SDDM than when already logged in? In SDDM, the pointer feels throttled and less precise.

      Comment


      • #33
        Correct me if I am wrong but shouldn't this be called a login manager instead of a display manager?

        Comment


        • #34
          Just one year. Imagine to get the the 1.0 release how many centuries will pass.

          Comment


          • #35
            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.
            What about h266 support and 4d scene graphs? Many people expect these.

            Comment


            • #36
              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.

              Comment


              • #37
                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.

                Comment


                • #38
                  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​


                  Comment


                  • #39
                    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.

                    Comment


                    • #40
                      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.

                      Comment

                      Working...
                      X