Announcement

Collapse
No announcement yet.

The Latest Wayland Work: Making Libweston

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

  • The Latest Wayland Work: Making Libweston

    Phoronix: The Latest Wayland Work: Making Libweston

    One of the latest patch-sets proposed in the Wayland world is forming libweston, which would allow more of the Weston reference compositor code to be used by other Wayland compositors...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Uhm... Michael, you seem a bit confused.

    While there's already libinput and other libraries in place for easing the process of writing new Wayland compositors, Giulio Camuffo has proposed forming libweston out of the reference Weston compositor code so that it can be potentially reused by other Wayland clients.
    This would be for compositors only, not for wayland clients. (Though a compositor can be a client too, but the client part wouldn't use libweston.)


    This libweston could allow potentially using Weston's X11 and DRM back-end APIs by other Wayland clients/compositors, making XWayland easier to adapt for other purposes, etc.
    Not sure what you mean with that XWayland part, XWayland has only one purpose, and this patchset doesn't change that.

    Comment


    • #3
      Originally posted by giucam View Post
      Uhm... Michael, you seem a bit confused.

      This would be for compositors only, not for wayland clients. (Though a compositor can be a client too, but the client part wouldn't use libweston.)

      Not sure what you mean with that XWayland part, XWayland has only one purpose, and this patchset doesn't change that.
      Whoops, one of the "clients" meant to write compositors. Typo.

      For XWayland, one of the changes was "libweston-ify XWayland", instead of "adopt for other purposes" should have been adopt for other compositors?
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #4
        Originally posted by Michael View Post
        For XWayland, one of the changes was "libweston-ify XWayland", instead of "adopt for other purposes" should have been adopt for other compositors?
        Yes, that change makes the xwayland module usable by other compositors.

        Comment


        • #5
          Wayland developers interested in learning more can check out the libweston patch series although the 15 patches have yet to receive widespread comment nor merged into mainline Weston.
          I wish I was, I would be really interested in writing my own compositor and developing a bit for libinput for example (For one I have a great idea for a compositor, and a desktop shell, and I'd like to assist with wacom tablet implementation to libinput and Logitech G-series keyboards for my own benefits), but I barely know the basics of C++ so I don't know how to get there learning OpenGL to write a compositor seems like an uncomfortably daunting task according to the rumors I hear and I just have no familiarity with driver programming but suspect they're a bit much for a novice like me.

          Comment


          • #6
            Minimize windows?

            Yes, but can it minimize windows?

            Comment


            • #7
              This is actually great idea to fairly obvious problem.
              Wayland (more or less bunch of protocols and interfaces) are 'stable' for quite some time while Weston (reference compositor, currently including most of the codebase) might not suite everyone.
              e.g. it would be way easier to create tilling window manager off existing weston code than from 'scratch' using wayland only.

              No idea how much would clients that currently depend on wayland+weston have to change, but I assume that changes required in other projects (gnome3..) would be minimal or none.

              Comment


              • #8
                Originally posted by tpruzina View Post
                This is actually great idea to fairly obvious problem.
                No idea how much would clients that currently depend on wayland+weston have to change, but I assume that changes required in other projects (gnome3..) would be minimal or none.
                Gnome wouldn't be affected at all, mutter is a standalone compositor.

                Comment


                • #9
                  Originally posted by uid313 View Post
                  Yes, but can it minimize windows?
                  If this is a library to make it easier to write Wayland compositors why should it have functions that handle behavior specific to the compositor? You would have to write that yourself anyways.

                  Comment


                  • #10
                    This seems like a great idea on the surface of things.. I can see certain errors being present in one compositor and not the other, things acting totally differently, etc - but isn't the compositor meant to be fairly simple anyway? Deciding which client gets the input, and pasting all the clients together for the graphical output..

                    Comment

                    Working...
                    X