Announcement

Collapse
No announcement yet.

"LIBOUTPUT" Proposed As New Library For Helping To Bring Up New Compositors & More

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

  • #11
    Originally posted by tildearrow View Post

    Mir has MirAL, which is very similar to libweston and wlroots in the sense that it can be used to aid in the making of compositors.
    Okay, that clears things up a bit. So then what is the relationship between or how do we compare mirAL, libweston, wlroots, and liboutput?

    Comment


    • #12
      Originally posted by kpedersen View Post

      Yes, I suppose that is true

      And whats great about this "innovative design" is that when Wayland has become deprecated, we can have a simple XNextbestthing implemented to replace XWayland and all of the great libX11 software can still function
      There has never been anything great about X11. Virtually all modern software runs natively on Wayland now, the few exceptions that don't (GIMP...) are held back by their graphical toolkit and they will move to Wayland when they upgrade it. I'm not convinced that the "great", libx11-based software like xman, xload and xedit is worth preserving for the future.

      Comment


      • #13
        So this will help making Vulkan based Wayland compositors without dealing with EGL?

        Comment


        • #14
          Originally posted by kpedersen View Post
          Honestly, everyone is just waiting for a libX11 API layer to be built on top of Wayland. Then people can stop faffing around and get back to some real work XD.
          Not really going to happen xwayland is close.

          https://sourceforge.net/projects/libw11/
          This is a old project that attempt to bring X11 API layer to windows without an X11 server. There are many more examples like this. Problem is the old X11 API is a disaster zone of quirks that you end up needing a full X11 server to emulate.

          Originally posted by tildearrow View Post
          We already have libweston, wlroots and Mir.
          This is not the first time X11 has attempt to change is abstraction layer either remember we have xlib and xcb. Xlib by design presumes everything is single threaded. xcb introduces multi thread support. If you dig deeper in to X11 you will find over time 15 competing ways just to generate X11 protocol to the server. So multi competing standards using the same output predate wayland we have just kept up the trend with the move to Wayland.

          liboutput maybe will be able to make a unified API/ABI that can be shared between X11 and Wayland so different library can be output neutral. This would replicate the kind of the same kill off that xlib did in early X11. Lot of people don't know first draft of X11 there is no xlib instead your application was meant to do the X11 protocol raw. Then there was 8 different options before xlib was chosen in the end.

          Horribly we are still in the coding interface design debate stage with wayland.

          Comment


          • #15
            Originally posted by oiaohm View Post
            This is not the first time X11 has attempt to change is abstraction layer either remember we have xlib and xcb. Xlib by design presumes everything is single threaded. xcb introduces multi thread support. If you dig deeper in to X11 you will find over time 15 competing ways just to generate X11 protocol to the server. So multi competing standards using the same output predate wayland we have just kept up the trend with the move to Wayland.
            I know, but liboutput isn't supposed to replace Xlib or XCB...

            Originally posted by oiaohm View Post
            liboutput maybe will be able to make a unified API/ABI that can be shared between X11 and Wayland so different library can be output neutral. This would replicate the kind of the same kill off that xlib did in early X11. Lot of people don't know first draft of X11 there is no xlib instead your application was meant to do the X11 protocol raw. Then there was 8 different options before xlib was chosen in the end.
            See above.

            Oh wait never mind I realized who you are...

            Comment


            • #16
              I think this is different from wlroot and similar because this doesn't aim to provide things specific to (Wayland) compositors. Instead it limits itself to just general output things that could be used by applications too. I think libaries like wlroots could then build on this library.

              Comment


              • #17
                Originally posted by oiaohm View Post
                Horribly we are still in the coding interface design debate stage with wayland.
                This is kind of the problem I think. Wayland is still so immature, it might be nice to just opt for a simple clone of libx11 that everyone knows and loves for now and get on with our lives rather than having the GNU Hurd kind of effect where it will be great, but never actually gets completed

                Comment


                • #18
                  (apologies for the potential double post / edit. Phoronix is being weird)

                  Originally posted by jacob View Post

                  There has never been anything great about X11.
                  I absolutely agree. But often, great software rarely has anything great about it. It simply gets the job done.
                  Check out the tiny DWM source code and how it uses Xlib.h. Sure, single threaded and all that, but the code is elegant and maintainable. libx11 has provided the foundations for this and Wayland lacks this facility for the foreseeable future; leading to very heavy ad-hoc systems in the future. Of course if you only use Gnome or Sway, you wont care about that until they start to rot because they become a maintenance nightmare.

                  Originally posted by oiaohm View Post
                  Horribly we are still in the coding interface design debate stage with wayland.
                  This is kind of the problem I think. Wayland is still so immature, it might be nice to just opt for a simple clone of libx11 that everyone knows and loves for now and get on with our lives rather than having the GNU Hurd kind of effect where it will be great, but never actually gets completed .

                  It by no mean needs to clone libx11 though. Something equally simple (or simpler) is also a nice idea.

                  Comment


                  • #19
                    Originally posted by tildearrow View Post
                    I know, but liboutput isn't supposed to replace Xlib or XCB...
                    Except large blocks of code that will disappear due to liboutput out of compostitors will be code that uses either Xlib or XCB to handshake stuff up with X11 server.

                    It not design to replace all of Xlib or XCB but it will reduce the amount of xlib or xcb code required. It really stupid having DRM/DRI rendering handshake coding differently over and over again.

                    Originally posted by tildearrow View Post
                    See above.

                    Oh wait never mind I realized who you are...
                    Maybe you need to look a bit closer before doing this see above.

                    We are lacking a decent abstraction that when you are coding a light program that works be the backend wayland, X11 or something else.

                    Comment


                    • #20
                      Originally posted by miabrahams View Post
                      Okay, that clears things up a bit. So then what is the relationship between or how do we compare mirAL, libweston, wlroots, and liboutput?
                      Well, currently mirAL, libweston and wlroots all communicate with DRM/KMS just like liboutput, the difference is that liboutput does not interface with wayland.
                      So I guess that you could rewrite mirAL, libweston or wlroots to be based on liboutput instead of DRM/KMS to have a common interface to the kernel.
                      Whether it's worth it though I don't know.

                      Comment

                      Working...
                      X