No announcement yet.

X.Org Looks To Drop DMX After Being Rather Broken For ~14 Years

  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by blacknova View Post
    I'm hearing a lot about Wayland compositors but I do not get why compositor have to be bundled with WM and cannot be separate service.
    Don't worry. In future it will once Wayland technology matures the fsck up. People can't possibly maintain all these fragmented compositors and there is no way people are just happy with Mutter, Kwin and Sway. Back in X11 world Mutter, Kwin and i3 are just a small proportion of users so Wayland users are no different, they just put up with crap because they have little alternative currently.

    wl_roots might evolve into it or some sort of libX11-style API will crop up (not to be confused with Xwayland) so developers can be remotely standard rather than Gtk, Qt, SDL2 all writing their own fragmented Wayland glue.

    Just got to wait 20+ years (and by then I am sure something else better will have come along anyway, so probably don't bother)

    Also this cliche mention of Wayland being a protocol is because many guys are a bit too new to it all to realise there were many different implementations of Xservers. X11 is just a protocol. Xorg is just the most popular currently. But it is fine to refer to X11 to cover them all even though you can't use X11 directly.
    Last edited by kpedersen; 04 September 2021, 05:43 AM.


    • #12
      I'd heard of DMX but I didn't even realise what it did. I use xpra for this kind of thing.


      • #13
        Back in 2017, Red Hat's Adam Jackson posted a patch to fix the support. However, that patch was never merged. That 2017 patch stemmed from a 2011 bug report over GLX/OpenGL applications yielding segmentation faults.

        Now in 2021, it's proposed to just drop the DMX DDX code outright from the source tree and the imminent X.Org Server 21.1 release. It looks like there are no active users left to this code given its brokenness.
        Not fixing a bug, leaving users for a decade with broken software, then use the broken state as an argument for saying nobody would actively use it, because nobody can actively use it, is demented bull shit by a bunch of people who embrace decay over reason. Please first fix the bug when you obviously have a fix for it. Then make it public and get people back to using it who may have abandoned it, and only then talk about who is able to use it but does not want to use it.


        • #14
          Originally posted by sdack View Post
          Then make it public and get people back to using it who may have abandoned it, and only then talk about who is able to use it but does not want to use it.
          I do agree that often this kind of move feels a little insincere and I believe the same has kind of happened with indirect rendering for Mesa. I do not believe this to be the case here but I have seen in the past, this is a fairly popular tactic when a project has been taken over by a corporate entity and they are too scared to tell the community that they only want to focus on monetizable features.

          Xdmx really is quite niche in terms of what you can achieve with it and any company wanting to do this (users probably don't) can just fix it up or (in our case) implement something similar but simpler.

          So I do understand there is a limit to what the developers can achieve. No-one has stepped up to do it because it was so niche. It probably shouldn't have been in the Xorg distribution in the first place (it is effectively a separate X server).
          Last edited by kpedersen; 04 September 2021, 06:04 AM.


          • #15
            Since the breakage only comes up when using opengl, it's possible there's still active users running it in a multiseat setup. I doubt it... But it's possible.


            • #16
              aha... broke since 14 years

              it seems natural for xorg issues or bugs to be fixed or remove code


              • #17
                I think something like intel-virtual-output would make more sense. It proxies some stuff like xrandr between two X servers (or more) and gets/draws a screen using XSHM or whatever most effective way is supported by the X servers involved. Basically it creates a "virtual monitor" on the main X server, then copies the contents to a secondary X server. Works well, supports OpenGL AND dynamically adding/removing monitors (unlike DMX) and works well in general. Only downside is no vsync/terrible tearing no matter what you do. That certainty could be fixed, but it's basically abandoned at this point.

                That said, if a fix is available and it doesn't cause unreasonable maintenance costs that's the way to go.


                • #18
                  No, no, no: Xorg isn't going to drop anything because noone is working on Xorg anymore, right (Wayland) people?


                  • #19
                    Originally posted by Myownfriend View Post
                    Why is Wayland such an ambiguous thing to so many people?
                    I'm guessing you're from the “if you use Ubuntu/Manjaro/whatever, you're not using Linux because Linux is only a kernel” camp?


                    • #20
                      Originally posted by mazumoto View Post
                      Because it's not at feature parity with X (meaning not every application got ported over) and therefore breaks stuff that used to work - while giving no percievable benefits for many people. Probably most of the problems can be solved via Xwayland - but why should I bother if there's no real benefit but just potential problems there for me? (examples: wine, steam, firefox)
                      Describing things as if X11 or Wayland support certain applications as opposed to the other way around is the most backward way that someone can look at that.

                      Applications aren't "ported" to Wayland. It's not the kind of change that requires a different version of the app. Many applications that use GTK3, Qt5, or newer already support or mostly support running natively in Wayland by just setting the an environmental variable to make it run in Wayland. Of the three applications you mentioned, Firefox, has been able to run in Wayland for awhile.

                      As for the benefits of Wayland, the most obvious ones are the ability to have great DPI scaling and for multi-monitor setups to run at different refresh rates. You know, basic features that people use in 2021. In my setup, I have two 27" monitors, one UHD, one QHD. With Wayland I can have the UHD one set to use 150% scaling so now that monitor still uses it's full resolution but it feels like I have matching monitors. Trying to do the same in an X11 session is awful. The mouse gets scaled down and feels sluggish, some applications scale alright while others scale down and are unreadable, and any monitor that doesn't match the primary monitors refresh rate will just show black.