Announcement

Collapse
No announcement yet.

Wayland Is Driving Fragmentation Around EDID Parsing - A Call To Fix That

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

  • #41
    Originally posted by bug77 View Post

    I'm not sure I agree about fragmentation when everything that's not X.org is either very niche or already dead.
    Now, sure. I think the point is X had a bunch of fragmentation earlier in it's life, when everyone had different ideas about how to do it best. Eventually people got tired of dealing with all the mess that is X and ended up consolidating under X.org.

    I fully expect the same thing to play out with Wayland. Right now it's new and people are experimenting with what they want out of it and the best way to accomplish things. In 10 years people will start consolidating code again. That's just the normal lifecycle for an open source project like this.

    Comment


    • #42
      Originally posted by curfew View Post
      Not complicated? There was a decade-old sample parser and it had about 1500 lines of C code. It was an example so probably didn't even cover everything, plus being very old. The implementation used by Linux TV seems to be multiple thousands of rows of code in C++.
      https://git.linuxtv.org/edid-decode.git/tree/
      A couple thousand lines of straightforward parsing code, compared to the rest of the code in a compositor or whatever else, is not that complicated, yeah. I mean, knowing what to put in there is an issue, but it seems to me that if somebody is going to go ahead and write their own, as appears to have happened several times, that is clearly not stopping anyone.

      Also if they want to centralize it, that's fine too, it just seems like it has been naturally duplicated over time, for better or worse.
      Last edited by microcode; 08 April 2021, 02:44 PM.

      Comment


      • #43
        Originally posted by oiaohm View Post

        Agree the correct answer would have been make it part of DRM that is in the Linux kernel and shared with the freebsd kernel and in time block of user-space interfacing directly so forcing usage of a common standard.
        While a few bits of information must be exposed for basic functionality... I would hesitate to suggest introducing a new parser into the kernel, especially one that may have to deal with arbitrary data.

        Folding it into the wayland umbrella makes some sense. Having an official preferred method could make a lot of sense. Not least of which is that may simplify co-ordination with Mesa regarding HDR.

        Comment


        • #44
          Originally posted by smitty3268 View Post

          Now, sure. I think the point is X had a bunch of fragmentation earlier in it's life, when everyone had different ideas about how to do it best. Eventually people got tired of dealing with all the mess that is X and ended up consolidating under X.org.

          I fully expect the same thing to play out with Wayland. Right now it's new and people are experimenting with what they want out of it and the best way to accomplish things. In 10 years people will start consolidating code again. That's just the normal lifecycle for an open source project like this.
          How do you see Gnome and KDE using a shared Wayland implementation?
          X has a server, that's the part everyone shares. Wayland doesn't have it replaces the server with (broadly speaking) the compositor. I think that's too tied into the DE to ever become a shared component. But I also don't have a crystal ball, so...

          Comment


          • #45
            Still able to run multiple displays, VRR in window and fs mode, adjust freesync ranges etc under windows. None of which I'm able to do under Linux without huge problems happening.

            Comment


            • #46
              Originally posted by WorBlux View Post
              While a few bits of information must be exposed for basic functionality... I would hesitate to suggest introducing a new parser into the kernel, especially one that may have to deal with arbitrary data.
              https://www.kernel.org/doc/html/late...uide/edid.html
              Since kernel mode setting exists EDID processing is required in the Linux and Freebsd kernel and any other kernel with kernel mode setting that attempts to deal with random screen changes. We do still have the problem of Nvidia being their own special form of different here not supporting kernel mode setting. I am not suggesting a new parser at all its more that we agree to use the EDID parser that has to be there for kernel mode setting.

              Remember to show the early text output of the Linux kernel on modern hardware you have to do a mode set or can be a black screen of nothing what is not useful if you have a error. Of course to-do that mode set you must proces the EDID data to know what modes can be set.

              Comment


              • #47
                Originally posted by bug77 View Post

                How do you see Gnome and KDE using a shared Wayland implementation?
                X has a server, that's the part everyone shares. Wayland doesn't have it replaces the server with (broadly speaking) the compositor. I think that's too tied into the DE to ever become a shared component. But I also don't have a crystal ball, so...
                The compositor can become a shared component if it is primarily a library, and covers the bases that the X server covered. I personally don't think it's necessary or a good idea, but it's not infeasible.

                Comment


                • #48
                  Originally posted by bug77 View Post

                  How do you see Gnome and KDE using a shared Wayland implementation?
                  X has a server, that's the part everyone shares. Wayland doesn't have it replaces the server with (broadly speaking) the compositor. I think that's too tied into the DE to ever become a shared component. But I also don't have a crystal ball, so...
                  All the interesting bits can be factored out into a common library. wlroots for example. Right now people in KDE and GNOME don't want to use a common library like that, because it's simpler for them to be able to prioritize their own needs the way they want to do things. I think they'll eventually get there once wayland support stabilizes, and everyone can review the different decisions the other projects have made and figure out how to create a library that adequately supports everyone.

                  They'll still have separate compositors, but that was already the case with X as well.
                  Last edited by smitty3268; 08 April 2021, 10:36 PM.

                  Comment


                  • #49
                    Originally posted by microcode View Post
                    A couple thousand lines of straightforward parsing code, compared to the rest of the code in a compositor or whatever else, is not that complicated, yeah. I mean, knowing what to put in there is an issue, but it seems to me that if somebody is going to go ahead and write their own, as appears to have happened several times, that is clearly not stopping anyone.
                    All window managers just display the same app windows as all others. So all of the code in a compositor ought to be straightforward. Why do we even use libraries at all, all code is logical, just rewrite everything every time. I don't think any competent developer would decide to write code from scratch if there was a competent common implementation available.

                    Comment


                    • #50
                      Originally posted by bug77 View Post
                      How do you see Gnome and KDE using a shared Wayland implementation?
                      X has a server, that's the part everyone shares. Wayland doesn't have it replaces the server with (broadly speaking) the compositor. I think that's too tied into the DE to ever become a shared component. But I also don't have a crystal ball, so...
                      Pluggable implementation should be the solution, although I don't see why a Xorg-like server-client architecture wouldn't fly even when built atop the Wayland protocol. It's just that people are now obsessed about building monolithic one-binary-does-everything solutions because they are simpler to write although shitty in terms of fragmentation.

                      Comment

                      Working...
                      X