Post by @jamey@toot.cat

Years ago I wrote https://xcb.freedesktop.org/ for X Window System clients, and yesterday I wrote my first Wayland client. My goodness, I can see the impact of every lesson the Wayland designers learned from X, and for that matter from XCB. I'm honestly really impressed by the design of the Wayland protocol!

I saw somebody complaining the other day about how much code you have to write just to open a window in a Wayland client. I think it's important to understand going in that this is a protocol designed to make hard things possible, not to make easy things easy; if you want to do easy things, use a toolkit like Gtk or Qt or SDL. So my program may seem like a lot of code for what it does: it just opens a window, periodically flashes between white and black, and measures some timing statistics, and I wrote over 300 lines of Rust for that. (I chose not to use the wayland-client crate's helpers for binding globals, so it could have been shorter, but I wanted to see what working with the raw protocol felt like.) But I know from experience that if you cut out any of the steps I had to do, you cut off the ability to handle more complicated scenarios.

I believe Wayland made the right complexity tradeoff here: the low-level protocol is very flexible, and ease of use belongs in higher-level abstractions that can pick which aspects of that flexibility to discard for simplicity.

xcb

1 Boost

0 Likes

ermine

@ermine@social.treehouse.systems 1 hr. ago

@jamey I had that complaint too when I was young and inexpireinced and tried Wayland after xcb.

But I had a similar complaint on xcb vs XLib: xcb is harder because of asynchrony and because it lacks some stuff like XLookupString etc.

Something makes me think that such differences are not only because Wayland corrects X's mistakes, but also because of target audiences. In X case that's application developers (I believe people were using XLib directly back in the day), while libwayland is made for toolkit developers.

Jamey Sharp

@jamey@toot.cat 50 min. ago

@ermine Yeah, I think that's true, and I think it's the right choice. Certainly people did write pure Xlib clients, and while I have written pure XCB clients, you're right, that's not the intended audience.

I did feel a little bad replacing single Xlib function calls with pairs of XCB function calls (when you need to get a reply or error), and considered offering convenience functions that would call the request function and then immediately call the reply function too.

But we were trying to encourage people to recognize that round-trips have a cost, and I think making that "easier" would have just encouraged people to write worse X clients.

The many non-protocol helpers that Xlib offered are another matter. I definitely didn't want XCB's scope to creep like Xlib's did. But it was legitimately painful not to have some of that extra functionality on hand. I tried to fix it with the various xcb-util libraries but I'm not sure those ever got enough development to really be useful.

herz (🥕){🐇}

@herzenschein@furry.engineer 4 hr. ago

@jamey I'd be interested to see a blog post on how you made your Wayland client.

I've played with libwayland before but there's not enough examples/docs online of people doing that unfortunately.

Jamey Sharp

@jamey@toot.cat 3 hr. ago

@herzenschein I may not have a blog post in me about it, but I can tell you what sources I used!

First off, I was writing this in Rust, so I used the wayland-client crate, which doesn't necessarily use libwayland at all, because it also has a pure-Rust implementation of the protocol available.

There's a convention in Rust projects of having an "examples" directory, and conveniently, wayland-client has a simple_window example, so I studied that pretty carefully.

That was tricky, though, because there have been some recent breaking API changes in the wayland-client crate, and it took me a little while to notice that the example I was reading was written against current git, not against the last release, which is what I was using.

Eventually I got it to display a window but after displaying the initial contents it wouldn't redraw, so I looked for a different example. At that point I found https://wayland-book.com, which I think might be exactly what you want since it is a tutorial using libwayland. (I hadn't realized I needed to tell the compositor that the whole window was damaged to get it to repaint anything; that was a one-line fix.)

The other source that I used a lot was the Wayland Explorer, https://wayland.app/protocols/, which just makes it easy to browse the documentation for the core protocol and many extensions. It also reports which compositors support which extensions, and that's super helpful.

I got from empty source file to working demo in a 12 hour period yesterday, counting breaks and all, and I made a number of choices that were probably harder than necessary so I could learn more. I did mostly know what I was looking for beforehand though, so whether you find it easier or harder than I did could go either way. I think especially the book and the explorer might help though!

Wayland Protocol Documentation | Wayland Explorer

A better way to read Wayland documentation

Introduction - The Wayland Protocol

GitHub

wayland-rs/wayland-client/examples/simple_window.rs at master · Smithay/wayland-rs

Rust implementation of the wayland protocol (client and server). - Smithay/wayland-rs

💙🩷💜 Brett [he/him/any]

@brettm@swarm.coiloptic.org 9 hr. ago

@jamey@toot.cat use a toolkit sure but please no more qt or gtk!

Jamey Sharp

@jamey@toot.cat 9 hr. ago

@brettm what do you prefer instead?

Ian Douglas Scott

@ids1024@mathstodon.xyz 14 hr. ago

@jamey Anyone who works with something like Wayland can nitpick about a huge number of specific design decisions. But overall it's a simple wire format with some clean core protocols.

The part about not focusing on making easy things easy (in a low level protocol) is something I see even more with people complaining about Vulkan. OpenGL 1.0 is a way better API for "ease of displaying one triangle", but that's not exactly the point.

(Meanwhile the loudest voices complaining about Wayland often don't really seem to be familiar with what exactly it is, or how developing a client for it compares to developing for X...)

Josh Simmons

@dotstdy@mastodon.social 13 hr. ago

@ids1024 @jamey the problem with taking this view of e.g. vulkan is that while it's a pretty good execution of its chosen design space, it's still valid to criticize that design space as being a poor fit for the vast majority of the *users* of vulkan. "Your API is in a different castle" is a bit of a cop-out response when significant aspects of vulkan 1.0 (e.g. all pipeline state specified statically upfront) have been broadly rejected.

Jamey Sharp

@jamey@toot.cat 11 hr. ago

@dotstdy @ids1024 Comparing with Vulkan is particularly relevant to me right now: I actually wrote this Wayland test app because I think I'm getting incorrect data from the VK_EXT_present_timing extension as implemented by Mesa on Wayland, and I'm getting some layers of abstraction out of the way of my tests before filing any bug reports. And while I think the API that I actually wanted to use, WGPU, is a relatively nice abstraction, I've needed to bypass it in multiple places to use this Vulkan extension that it doesn't support yet, so I've been learning how Vulkan works. It does feel to me very much like another "make difficult things possible" design, and I sympathize with people who are frustrated trying to use it just as a cross-platform abstraction; it doesn't seem to me like that's where its strengths are going to be.

Josh Simmons

@dotstdy@mastodon.social 5 hr. ago

@jamey @ids1024 another way of looking at it is that you're forced to deal with an api design issue with vulkan (wsi in general is nightmarish, and present timing is even more nightmarish than the rest) combined with another API design issue (frame pacing in Wayland is extremely underdeveloped and over complicated). The idea that a higher level API like wgpu insulates you from these design issues is unfortunately very optimistic in practice, which is broadly my issue with the original argument.

1 more reply