1. 43

  2. 8

    Looking at this, it’s kind of interesting how many unstable protocols there are compared to core/stable ones, especially for stuff like layer shells that are important for things people take for granted in modern desktops (in layer-shell’s case, notifications that appear above your other windows and the like).

    1. 9

      It is the endless cycle of open source: you declare the old thing bloated and obsolete, throw it away and rewrite it, then eventually copy and/or reinvent the whole old thing eventually since it turns out the original authors actually had their reasons. Then the next generation calls your thing bloated and obsolete…

      1. 3

        I expect it’s due to a fairly small number of people working on the protocols and implementing them personally. Based on my experience with Sway/wlroots, most of the protocols appear to be defacto Stable Enough.

        Plus, having made some minimal attempts to read these docs directly, it’s difficult to get a handle on them and understand how they fit together. This site is honestly pretty great.

        1. 8

          Based on my experience writing a compositor, protocols are unstable and applications break compatibility frequently

      2. 5

        It would be nice to combine this with Are we Wayland yet? to create something like mesamatrix but for Wayland.

        Yes there are Wayland protocols to do this and that. Yes, there applications that work with Wayland and provide certain X11 features when used with the right composer. But what I want to know is: how far is Wayland from feature parity with X11 + EWMH?

        The existence of a protocol alone is not enough. The fact that a compositor supports a protocol is not enough. Only the combination of application/toolkit + compositor + protocol is what is relevant to the users.

        1. 5

          The existence of a protocol alone is not enough. The fact that a compositor supports a protocol is not enough. Only the combination of application/toolkit + compositor + protocol is what is relevant to the users.

          On top of that, there is no working way of testing conformance projected over protocol version (Mir team got closest, AFAIR no-one else actually used the suite as it was quite imposing). To this day, as a compositor, you need to check “oh does this client require version 3 of the wl_seat protocol? – otherwise I should not send mouse wheel events or the clients just … crashes with a friendly “NULL” message to the user. To figure out the cause? oh well, enjoy WAYLAND_DEBUG=1 and staring into traces that make xwininfo -root feel like a day at the spa.

          A fun “exercise”:

          1. Take xdg-wm-base popup and its “positioners”, read the text (do note that the wayland half-assed-manpages-marketed-as-book skipped over that entirely - enough to be convincing, far from useful). Write down how you’d do the calculations.
          2. Check say - weston, efl, kwin, wlroots - did they reach the same formula. If not? and that is something as pedestrian as positioning a popup – a single ConfigureWindow elsewhere.

          The page referenced reeks of swayland doing their influops schtick again (as is the arewewayland) - a lot of those “protocols” (really, object remote-method interfaces; flow is implicit here which is kindof a big deal in actual protocol design) will remain as their own namespace as they make >no< sense to other stakeholders. This is textbook cognitive dissonance.

          Fur fun (and profit, I held trainings on Wayland exploitation..) , here is the most deployed and used wayland object interface. Notice how that isn’t mentioned here or elsewhere – there is a lot of that going on.

          1. 2

            I’ve just added the linked Tizen protocol to the site: https://wayland.app/protocols/tizen-extension

            As I’ve mentioned in this issue the reason some protocols are missing is that they are automatically picked up from the two main repositories of Wayland protocols that I was aware of. So it’s definitely not some nefarious plan to hide or obscure other protocols. Pull-requests are always welcome to extend the supported protocols list.

            1. 4

              just as I commented to you on GH ;)

              Here is another one: https://github.com/KDE/plasma-wayland-protocols/tree/master/src/protocols

              What chrome is doing: https://chromium.googlesource.com/chromium/src.git/+/master/components/exo/wayland/protocol/aura-shell.xml

              You can find this one here, and in Xorg. https://code.qt.io/cgit/qt/qtwayland.git/tree/src/3rdparty/protocol/wl-eglstream-controller.xml

              I thought I had a list here somewhere, but I also gave up and wrote a few fuzzers..

              1. 2

                That’s awesome, thanks! It’s a bit late now so I won’t be able to add them now but I’ll definitely add them to the list in the next few days (as long as their licensing doesn’t prevent it, of course).

                1. 2

                  All those protocols have been added now. A few examples:

            2. 1

              As an armchair reader of your post I would like to see less catty comments on Drew’s Wayland book and more contributions to make it better. You seem to know what you’re talking about.

              1. 1

                “catty comment”? that one line specifically referenced a stable part of the standard that is absolutely essential for the raw basics that was left untouched and abandoned, and to his own admission, he got compensated for it. The subsequent sections on drag and drop, clipboard management (“data device”) suffered the same faith. Given that lack of even basic polite effort, I think that comment was absolutely fair and justified.

          2. 3

            Ohhhh, this is good! One of the biggest obstacles I’ve found when trying to understand the Wayland ecosystem (and why it’s taking so long for things to get ported). This is a good start.