alt.hn

3/22/2026 at 3:06:29 PM

I hate: Programming Wayland applications

 https://www.p4m.dev/posts/29/index.html

by dwdz

3/22/2026 at 4:06:08 PM

Wayland was designed from the point of view of theoretical purists. It's basically "how would a display server work in an ideal world", unfortunately, that design turns out to also be impractical and straight up developer/user hostile.

by diath

3/22/2026 at 5:12:32 PM

I would at least like to understand the idea of 'pureness' this API tries to aspire to.

It's definitely not Unix-like, since file handles and writes and epoll, and mmap for IPC are nowhere to be found. Instead you have 'objects' with these lifecycle methods that create/release resources (probably committing the design sin of having these for things which should be pure data, like descriptors).

What's with these XML headers? It's UNIX standard stuff, to have a C API for your code, that declares an API for a library, and then a makefile can just consume it. There's a standard way of supplying, finding and consuming them. Even binding generators are probably more comfortable with C headers, than this XML thing

And what's with the callbacks for everything, like screen resolution queries? In Win32, you can do it with a single synchronous API call that returns a struct that has all the info. It's not like you have to touch the disk or network to get this. In cases where you do, you usually have a call that dispatches a message to another window (which you can also dispatch yourself), and you have to listen to the response.

I did some X11 programming as part of work, and its entirely reasonable and conventional compared to this, much more like Win32 (even maybe a bit more pleasant, but I'm no expert on it).

The API sounds awful (and I've had ChatGPT generate me some example programs, and it's somehow even worse than the author describes), and not only that, the requirement of 'everything be an object', with chains and trees of objects being created introduces a huge source of bugs and bookeeping performance overhead on the application side.

Yes, you do have to do something like this with some things under Windows, but the reason for this is that these objects have duplicates in the Windows kernel.

But here it looks like this is just to satisfy the sensibilities of the designer.

Honestly this sounds like the most epic case of NIH syndrome. Like these guys wanted to write their own OS and userland and break with existing conventions.

by torginus

3/22/2026 at 4:20:03 PM

It is a damn shame that tools like xdotool (automation) and sxhkd (global keybinds) are impossible to recreate under Wayland.

by dzogchen

3/22/2026 at 4:37:01 PM

Not impossible, it just needs to be implemented at a different layer. The compositor needs to expose some API for global hotkeys. For example, I found this with ~2 minutes of Googling: https://wayland.app/protocols/hyprland-global-shortcuts-v1

by craftkiller

3/22/2026 at 4:46:44 PM

> Not impossible, it just needs to be implemented at a different layer. The compositor needs to expose some API for global hotkeys.

That's a big problem. When things become an optional extension for a compositor, that means you cannot reliably deploy something that depends on it to Wayland.

At this moment, things in the wild are coupling themselves to libwayland-client and in practice ossifying its ABI as a standard no matter what the wayland orgs say about it.

by Blackthorn

3/22/2026 at 5:30:47 PM

xdg-shell is an optional extension for a compositor and yet you can reliably deploy things that depend on it. You're barking at the wrong tree.

by seba_dos1

3/22/2026 at 6:12:11 PM

OK so why wasn't this implemented in the first place? For that matter, why does our reinvented wheel have fundamental limitations?

by MarsIronPI

3/22/2026 at 6:20:46 PM

It's not a core protocol's concern and the fact that it's being successfully implemented proves that there are no fundamental limitations there.

I'm not happy with how the collaboration and planning between various parties involved went over years and I do believe that a lot of these adoption pains are fully self-inflicted, but that has absolutely nothing to do with Wayland's technical design.

by seba_dos1

3/22/2026 at 4:40:11 PM

And that's a problem, now instead of knowing that something just works in the WM you're using, you have to cross-reference a matrix of features for basic tasks across different WMs because the bare minimum features are not found in the core protocols. Nothing is standardized, it's just a pile of different WMs developing their own sets of custom protocols.

by diath

3/22/2026 at 6:10:01 PM

> Not impossible, it just needs to be implemented at a different layer.

Do you mean the Window Manager layer?

That sounds like a different way of saying "impossible".

In X11 I can create an automation tool that works regardless of the underlying WM, or even if there isn't an underlying WM.

Can't do that with Wayland.

by lelanthran

3/22/2026 at 4:53:00 PM

Not only that. A11y is also quite hard. Tools that are simple to implement thanks to good a11y apis - for example on macos, the tool rcmd or homerow - are super hard to do in Wayland.

by zwarag

3/22/2026 at 4:27:26 PM

Not literally impossible. You just need to write your own composer!

by j16sdiz

3/22/2026 at 4:40:57 PM

wdotool exists, and global hotkeys are a thing under wayland, but is desktop dependent. KDE allows it by default, Gnome can be made to do it as well with an extension.

by Krutonium

3/22/2026 at 4:44:03 PM

I'm using Sway right now and I have key binds. Not sure why you think that's impossible.

by James_K

3/22/2026 at 4:51:43 PM

Th point is the decoupling. sxkhd runs irrespective of wm and means your en can optionally choose not to handle key bindings at all. With Wayland you end up depending on whether or not and how your compositor supports it.

by vidarh

3/22/2026 at 4:59:38 PM

How many keybings do you have and how often do you try new window managers? Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.

by James_K

3/22/2026 at 6:59:02 PM

There's no need to compromise the security of the whole system. A trivially safe option would have been to restrict the ability to acquire global keybindings to specific clients, and require the user to confirm either once or every time (or any other policy you'd prefer). An X server could do that without breaking anything.

This issue is typical of the thinking that went into Wayland: No consideration was made when Wayland was announced of the fact that there were far simpler ways of achieving the same level of security.

by vidarh

3/22/2026 at 6:12:50 PM

> Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.

Those aren't the only two options. There's no need to compromise the entire system for everybody if the Wayland devs would agree to configuration that controls these things.

Then those of us who need stuff to work rgardless of WM would get stuff to work and the rest of the Wayland users can simply go with a WM that suits them.

by lelanthran

3/22/2026 at 4:40:46 PM

ydotool exists

https://github.com/ReimuNotMoe/ydotool

by flexagoon

3/22/2026 at 4:45:13 PM

The name is pretty similar, but looks like there is where the similarities end.

by dzogchen

3/22/2026 at 4:26:29 PM

What make it worse: there are multiple implementation of composer, with small different in behaviour.

The extra security meant many automation tasks need to be done as extensions on composer level making this even worse

by j16sdiz

3/22/2026 at 4:49:52 PM

They looked at caniuse.com and thought "I want that!"

by IshKebab

3/22/2026 at 4:44:35 PM

> how would a display server work in an ideal world

When designed by committee.

With conflicting interests.

And Veto Powers.

by zer00eyz

3/22/2026 at 4:35:14 PM

I agree that the lack of standardization around the "insecure" things is a bad idea. Insecure operations don't have to be available by default, or even universally supported, but a central registry of interfaces for e.g. retrieving all windows on a desktop would certainly help preventing fragmentation.

At the same time, most of this post really is just a rant essentially saying that a low-level library is so flexible that using it directly results in code so verbose it can hardly be read. Yes, that's how good low-level designs always are.

You can turn a generic portable asynchronous ANSI C interface into a simple, blocking and platform-specific one with an abstraction layer. You can integrate it with all sorts of existing event loops and programming frameworks. You can customize it all you like but using it directly in an application will cost you a lot of patience. At the same time, you can't go in the opposite direction; from a "simple" blocking black-box interface to something that can reasonably host a complex GUI toolkit. If you're after simplicity, go higher-level.

by m132

3/22/2026 at 5:14:29 PM

There is really no excuse for a low-level API to be hard to use. It's just poor API design, plain and simple.

At the very least there should be a standardized (and centralized) client library on top of Wayland but below widget frameworks like GTK or Qt which implements the missing "desktop window system features": opening, moving, sizing windows (with decorations please), mouse and keyboard input events, clipboard, drag-and-drop. Non-GTK/Qt applications should never have to talk directly to the asynchronous Wayland APIs, only to this wrapper library.

Such a library should be designed to make programmers want to move on from X11 (because writing code against Xlib is horrible, but somehow Wayland managed to be even worse) - and tbh, this new window system client library (at first on top of X11) should have been the top priority of the Wayland project before starting to work on the actual X11 replacement, and it should have shipped on all desktop Linux distros at least a decade ago so that application programmers could have been won over (and for collecting feedback) even before Wayland shipped its first version.

by flohofwoe

3/22/2026 at 5:52:54 PM

I might be mistaken, but isn't this what libraries like winit exist for? It might not be just for wayland, but it seems like it supports everything you mentioned other than drag and drop.

by vimredo

3/22/2026 at 6:10:49 PM

Generally yes (or GLFW, or SDL), but the Wayland project shouldn't delegate the job to burned out hobbyists (who will think twice before wasting their time with bad APIs). This client library should really be a mandatory part of each Wayland install as a system library, not part of the application. And most importantly, the Wayland project needs to start eating their own dogfood, or things will never improve.

by flohofwoe

3/22/2026 at 5:15:26 PM

Whenever people complain about Wayland being hard to program in, I think about how Xlib was largely replaced by XCB, and OpenGL is increasingly marginalized in comparison to Vulkan.

Not to draw any specific analogy, but sometimes a fussy low-level interface is just important to have.

by i80and

3/22/2026 at 5:34:27 PM

> and OpenGL is increasingly marginalized in comparison to Vulkan

Vulkan's "API design deficits" (to put it mildly) have been recognized by Khronos though, and turning that mess around and making the API a "joy to use" is one of Khronos' main priorities at the moment (kudos to them for doing that).

https://www.phoronix.com/news/Vulkan-Joy-To-Use-2025

by flohofwoe

3/22/2026 at 6:04:22 PM

That's good to hear!

by i80and

3/22/2026 at 5:45:19 PM

XCB did not largely replace Xlib. In fact, some (all?) implementations of Xlib are built on top of XCB.

by aninteger

3/22/2026 at 6:03:04 PM

Maybe the technical politics have changed, but I feel like I remember there was some push in the late 2000s to rewrite libraries that were using Xlib to instead use XCB.

Regardless, that's sort of my point: having a lower level fiddly layer is a desirable quality, and Xlib being rebased on top of it isn't exactly a counterexample.

by i80and

3/22/2026 at 6:04:07 PM

Turns out you want to build higher-level interfaces on top of lower-level interfaces, not the other way around.

by seba_dos1

3/22/2026 at 5:32:07 PM

The API design has nothing to do with security. The Posix API is completely secure. MS has been able to bolt on exactly this kind of security to Win32.

by torginus

3/22/2026 at 4:13:43 PM

Seems like complaining about how difficult to use Win32 and COM are. And they are if you use them directly! You don't do that - you use libraries that others have sweated over, as you did with raylib.

by zabzonk

3/22/2026 at 4:18:43 PM

Exactly my impression. And honestly, X11 isn't exactly beautiful like the author is implying. A lot of the same wayland complaints they are putting here apply to X11. The main difference is that wayland is apparently handling the event loop for you while X11 expects you to set that up yourself.

Win32 has exactly the same setup of problems here as wayland does. Moreso because Win32 just gives you back opaque handles which you are expected to keep track of and use the Win32 API to do any meaningful interactions.

The only understandable complaint is that wayland makes it hard for different windows to interact with one another for security. IMO, that's a silly goal to chase after, but that's just me.

by cogman10

3/22/2026 at 4:58:18 PM

A big complaint in TFA is that Win32 is much much easier to use than Wayland is:

>Getting any example application to work is so incredibly ridiculous, that every second I program on Wayland, I yarn for the times I did Win32 programming.

And that comes from the core of how Wayland is designed.

In Win32, the stable interface / ABI is the set of C functions provided by the operating system through DLLs. These are always dynamically loaded, so Microsoft is free to change the internal interface used for controlling windows at any time. Because of this, decades-old .exes still run fine on Windows 11.

In Wayland, the stable interface is the binary protocol to the compositor, in addition to the libwayland-client library plus extensions. Instead of that socket being an "implementation detail", it's now something that all programs that just want to make a window have to deal with. You also can't just use the socket and ignore the libwayland libraries, because mesa uses libwayland-client and you probably want hardware acceleration.

The other big issue is the core Wayland protocol is useless; you have to use a bunch of protocol extensions to do anything, and different compositors may implement different versions of them. On Win32, Microsoft can just add another C function to user32.dll and you don't have to think about protocol how that gets transformed into messages on the socket layer, or compatibility issues with different sets of extensions being supported by different compositors.

by 201984

3/22/2026 at 5:32:18 PM

I was going to point out that wayland is a protocol & surely there must be other ways to do this. But your point about mesa expecting wayland-client is a very tight binding here.

Anyone know of exceptions? People who get mesa working anyhow, some way?

It also doesn't preclude people from making nicer experiences on top of libwayland. Again I'd be curious to see what material is out there. It feels like a library that materializes the current state of things into a local view would go a long way to dispel the rage of people such as the author here, who seem to detest callbacks with firey rage.

The idea of the wayland registry seem unifying & grand to me. Ok yes it's async & doesn't hide it? Lot of ink spilled to be upset about that, and doesn't feel like an immutable fact that must govern life, if that for some reason makes you as mad as this dude.

by jauntywundrkind

3/22/2026 at 6:11:17 PM

> But your point about mesa expecting wayland-client is a very tight binding here.

You don't have to use Mesa's wayland-egl to make EGL work with Wayland, you can easily pass dmabufs by yourself - though this will theoretically be less portable as dmabufs are Linux specific (but practically they're also implemented by various BSDs).

by seba_dos1

3/22/2026 at 4:39:29 PM

Having done some mobile development where app sandboxes have been prevalent for years, it's annoying to deal with but necessary. Given the bad behavior some devs attempt, often ad SDKs trying to perma-cookie users, stealing clipboards, etc, having a platform that can support app isolation seems necessary for normal desktop usage.

by hedgehog

3/22/2026 at 4:47:55 PM

How often has that been a problem for desktop OSes?

by graemep

3/22/2026 at 4:58:23 PM

Constantly. Phishing, tech support scams, supply chain attacks on e.g. NPM, problems have been rampant since we connected desktops to the internet.

by hedgehog

3/22/2026 at 5:27:16 PM

I mean specifically things that using using Wayland will improve.

by graemep

3/22/2026 at 5:34:19 PM

The commenter above appeared to reference Wayland preventing apps from having unrestricted access to screen contents and clipboard, so those.

by hedgehog

3/22/2026 at 6:01:55 PM

Having some kind of access control list or other method of enforcing access rights for windows and clipboards is definitely a good thing.

However, such a thing could be relatively easily added to X11 without changing the X protocol, so this does not appear as a sufficient motivation for the existence of Wayland.

I have not tried Wayland yet, because I have never heard anyone describing an important enough advantage of Wayland, while it definitely has disadvantages, like not being network transparent, which is an X11 feature that I use.

Therefore, I do not know which is the truth, but from the complaints that I have heard the problem seems to be that in Wayland it is not simple to control the access rights to windows and clipboards.

Yes, access to those must be restricted, but it must be very easy for users to specify when to share windows with someone else or between their own applications. The complaints about Wayland indicate that this mechanism of how to allow sharing has not been thought well. It should have been something as easy as clicking a set of windows to specify something like the first being allowed to access the others, or like each of them being able to access all the others.

This should have been a major consideration when designing access control and it appears that a lot of such essential requirements have been overlooked when Wayland was designed and they had to be patched somehow later, which does not inspire confidence in the quality of the design.

by adrian_b

3/22/2026 at 7:25:48 PM

Having a medium understanding of graphics hardware and software stack, and being an everyday desktop Linux user recently, it's hard to square these kinds of complaints with the actual technical situation. Like, people say X11 is network transparent but that's not in practice true. People argue the same problems could be solved in X11, but in practice despite a decade + of complaining about Wayland nobody did the work make the improvements to X. Unlike say the systemd situation Wayland just seems like a better and necessary design?

At a higher level, I've never found someone who is deeply familiar with the Linux GUI software stack who also thinks Wayland is the wrong path, while subjectively as a user most or all of my Linux GUI machines are using Wayland and there's no noticeable difference.

From an app dev perspective, I have a small app I maintain that runs on Mac and Linux with GPU acceleration and at no point did I need to a make any choices related to Wayland vs X.

So, overall, the case that Wayland has some grave technical or strategic flaws just don't pass the smell test. Maybe I'm missing something?

by hedgehog

3/22/2026 at 4:24:48 PM

I used to program pure Xlib when I was 13 or so. I don't think the then-13-year-old me would manage pure Wayland.

by mato

3/22/2026 at 4:32:34 PM

The point of wayland, though, is that back then 13-year-old you would get an application that "works" but to support myriad things (like HiDPI) you'd have to DIY it. Whereas now, sure a 13 year old perhaps won't write directly to wayland's APIs, but you'll use a library and have a much more globally usable result. And honestly probably have a better time - less effort for the same result, and with a more maintainable project in the long run.

by atomicnumber3

3/22/2026 at 5:24:18 PM

HiDPI has always been perfectly supported by X11.

The only problem that has existed is that originally there was a single DPI value, not a different DPI value for each monitor.

This has never created any problem for the people using multiple monitors with the same resolution, but only for the people who have used multiple monitors having different resolutions and who might have not liked the changes in windows size when moving a window from a monitor to another monitor.

That was indeed a problem, but it really affected a rather niche use case and it was also trivial to solve without any change in the X11 design, by just making DPI a per monitor variable, which was done long ago.

So criticizing X11 about a supposed problem with HiDPI is incorrect. I have used only multiple 4k monitors with my PCs, with X11, for more than a dozen years and I never had any problem with HiDPI, with the exception of many Java programs written by morons, which ignore the system settings and which also do not allow the user to change the font used by them. I do not know which is the problem with the Java programmers, but I never encountered programs with such a behavior, except those written in Java. Moreover, the Java programs are also the only that had problems with monitors using 10-bit per color component.

While X11 itself never had problems with supporting HiDPI, at least not in the XFCE that I am using, I heard that other desktop environments have created problems with HiDPI that have nothing to do with X11, by not exposing the X11 DPI settings but providing instead some "window scaling" settings, which is something that I do not know how it is implemented, but there are good chances that it is implemented in a wrong way, judging from the complaints that I have seen. I cannot imagine how one could use correctly a "window scaling" factor, because the font rendering program must know the true DPI value when rendering for instance a 12-point font. If rendering is done at a wrong DPI and then the image is scaled, the result is garbage, so in that case it would not be surprising that people claimed that HiDPI works badly in X11, when in fact it was Gnome or whatever desktop environment was used who was guilty for bad support, not X11. I never had to fight with those desktop environments, but I assume that even those would have worked correctly with HiDPI, when using xrandr to configure X11, instead of using the settings of the desktop environment.

by adrian_b

3/22/2026 at 5:54:49 PM

There is nothing "niche" about plugging in a modern (e.g. made within last 5 years) laptop into an external display.

These kind of posts just show how disconnected from reality some of y'all are from what most Linux desktop users nowadays actually need from the desktop platform.

by izacus

3/22/2026 at 6:17:40 PM

I always plug my laptop into one or two external displays.

Even without configuring distinct DPIs per monitor that was not a problem for me, because on the small screen of the laptop I kept only some less important application, like the e-mail program, while working on the bigger external displays, so I had no reason to move windows between the small screen of the laptop and the bigger external displays.

But like I said, setting a different DPI value for each monitor has been added to X11 many years ago, I do not remember how many.

I do not see why one would want to move windows between the external displays and the laptop, when you have connected external displays, so I consider this a niche use case, i.e. moving windows between small screens and big screens. I agree with you that having simultaneously big screens and small screens is not niche, so I was not referring to this.

Without a per-screen DPI value you cannot control the ratio between the sizes of a window when is moved between the big screen and the small screen, but even when you control the ratio, moving windows between screens of different sizes does not work well because you must choose some compromise, e.g. if you keep the same physical size some windows from the big screen will not fit on the small screen and if you make the windows occupy the same fraction of the screen size they will change their sizes during moving and they will be more difficult to use on the small screen.

But like I have said, this no longer matters as the problem has been solved even for this niche use case. I do not even remember if this problem still existed by the time when Wayland became usable.

by adrian_b

3/22/2026 at 5:07:53 PM

You underestimate youself as a 13 year old... if you had to, you'd do it (given time).

by silon42

3/22/2026 at 4:37:11 PM

Win32 isn't that hard actually.

by modeless

3/22/2026 at 4:39:51 PM

To create a simple window, no it isn't. To create a rather complex application, then yes it is, compared with using a higher-level framework.

by zabzonk

3/22/2026 at 4:44:49 PM

This article is complaining about the complexity of creating a simple window in Wayland, which is much easier in Win32. Wayland doesn't make creating "a rather complex application" any easier either. In both cases you would use a framework. Even more so in Wayland, which doesn't provide widgets or standard dialogs at all, while Win32 does.

by modeless

3/22/2026 at 5:36:19 PM

Creating a simple window in Wayland isn't much harder than in Win32. You get a wl_surface, attach a wl_buffer to it, wrap it with xdg_toplevel and handle some callbacks for resizing etc. There's some boilerplate that allows all this to be extensible in backwards-compatible ways, but nothing complex, really. simple-touch example in Weston repository has about 400 lines.

Some compositor's insistence on CSD can make it a bit more complex since you get that in Win32 for free, but on the sane ones you just add xdg-decoration and you're done.

Also, this is all apples-to-oranges anyway, as Win32 is a toolkit, while wayland-client is just a protocol (de)serializer.

by seba_dos1

3/22/2026 at 6:47:04 PM

> Creating a simple window in Wayland isn't much harder than in Win32. You get a wl_surface, attach a wl_buffer to it, wrap it with xdg_toplevel and handle some callbacks for resizing etc. There's some boilerplate that allows all this to be extensible in backwards-compatible ways, but nothing complex, really. simple-touch example in Weston repository has about 400 lines.

I believe the youth nowadays calls what you wrote "copium". Because creating a simple window in Win32 (a whole program, in fact) looks like this:

    #ifndef UNICODE
    #define UNICODE
    #endif 
    
    #include <windows.h>
    
    LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
    
    int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PWSTR pCmdLine, int nCmdShow)
    {
        const wchar_t CLASS_NAME[]  = L"Sample Window Class";
        
        WNDCLASS wc = { };
    
        wc.lpfnWndProc   = WindowProc;
        wc.hInstance     = hInstance;
        wc.lpszClassName = CLASS_NAME;
    
        RegisterClass(&wc);
    
        HWND hwnd = CreateWindowEx(0, CLASS_NAME, L"Hello World! Program",
            WS_OVERLAPPEDWINDOW,
            CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
            NULL, NULL, hInstance, NULL);
    
        if (hwnd == NULL)
        {
            return 0;
        }
    
        ShowWindow(hwnd, nCmdShow);
    
        MSG msg = { };
        while (GetMessage(&msg, NULL, 0, 0) > 0)
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    
        return 0;
    }
    
    LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
    {
        switch (uMsg)
        {
        case WM_DESTROY:
            PostQuitMessage(0);
            return 0;
        default:
            return DefWindowProc(hwnd, uMsg, wParam, lParam);
        }
    }
That's significantly less than 400 lines, and requires essentially just two function calls, RegisterClass and CreateWindowEx, the rest is the message loop and its callback.

by Joker_vD

3/22/2026 at 8:03:52 PM

Yes, this isn't much easier than doing it yourself with libwayland-client, even despite of it being a whole layer of abstraction higher (which is obviously why it's shorter). Other toolkits that provide similar (or even simpler) APIs on top of Wayland exist too.

by seba_dos1

3/22/2026 at 4:53:38 PM

Here is how to get Win32 up and running: https://learn.microsoft.com/en-us/windows/win32/learnwin32/y...

It's absolutely trivial in comparison. Same thing with Xlib; < 100 lines of C code is enough for a simple app.

by bjourne

3/22/2026 at 6:50:40 PM

I have written some OpenGL applications in X11, so they did not use much of X11 besides setting up windows for the OpenGL contexts, after which the rest of the programs were written using the OpenGL API.

Those applications seemed quite simple to write in comparison with what is described in the parent article, despite doing animation in real time based on the mouse and keyboard inputs.

by adrian_b

3/22/2026 at 7:16:46 PM

>and I still don't know what's the difference between them (wl_display_roundtrip() & wl_display_dispatch()) and in what order to call them on

I've been struggling with this initially as well, it's pretty poorly explained in docs. Short explanation:

Wayland-client library implements a queues over the socket. So to get it, you have to think about when is the socket read from and written to, and when are the queues pulled from or pushed to. There is always a default queue, but for example EGL+OpenGL creates it's own queue, which further makes it more confusing.

- `wl_display_dispatch_pending()` only pulls messages from default queue to callbacks

- `wl_display_dispatch()` also tries to do blocking read on the socket if no messages are in queue

- quite recently `wl_display_dispatch_queue_timeout()` was finally added, so you can do non-blocking read from the socket. earlier you had to hack the function yourself

- `wl_display_flush()` writes enqueued messages in queue to socket

- `wl_display_roundtrip()` sends a ping message and does blocking wait for response. the purpose is that you also send all enqueued requests and receive and process all responses. for example during init you call it to create registry and enumerate the objects, and you call it for second time to enumerate further protocol objects that got registered in registry callback, such as seat

- `eglSwapBuffers()` operates on its own queue, but reading from socket also enqueues to default queue, so you should always call `wl_display_dispatch_pending()` (on default queue) afterwards

There is also a way to get around being stuck in `eglSwapBuffers()` during window inhibition: disable the blocking with `eglSwapInterval(0)` and use `wl_surface_frame()` callback, and you get notified in callback when you can redraw and swap again. But you can't do blocking reads with `wl_display_dispatch()` anymore, have to use the timeout variant. After using it this way, you can also easily manage multiple vsynced windows independently on the same thread, and even use wayland socket in epoll event loop. None of this is documented of course.

The clipboard interface is definitely compromised a bit by being shared with drag-and-drop events, but it's not that complicated. Also there is a pitfall when you copy-paste to your own application and don't use any async event loop, you can get deadlocked by being expected to write and read on the same file descriptor at the same time.

by mizmar

3/22/2026 at 4:28:56 PM

The separate process for clipboard: yep... I'm having to do this to be able to get the cursor position myself in Wayland... (This is for a screen recorder app)

by firtoz

3/22/2026 at 4:15:23 PM

As a user, I like wayland. X11 was a security disaster. Wayland is much better about tearing.

What scares me though are all the responsibilities passed to compositors, because what ends up happening is that each compositor may reimplement what should be common functionality in annoying ways. This is especially true for input things, like key remapping. This ultimately fragments linux desktop experiences even harder than it was before.

by 65a

3/22/2026 at 4:20:29 PM

Huh. The "security" preventing me from doing things I want to do is a major reason I dislike Wayland :/. (e.g. automation & scripting / input events, clipboard, ...)

It also has noticeable mouse lag for me, I really hope this isn't due to avoiding tearing.

by eqvinox

3/22/2026 at 4:27:47 PM

With great power comes great responsibility :)

by ranger_danger

3/22/2026 at 5:34:38 PM

That's a nice quip, but what does it mean in this case? If you remove "insecure" or "dangerous" features that people actually need from software, what you achieve is people using other software, and thus you have failed your responsibility?

by eqvinox

3/22/2026 at 5:27:40 PM

Win32 has managed to do this without any API change, all the existing APIs work. The same approach would've worked for X11.

What it does is simple - all the functions that deal with windows/handles or events simply do not work on ones that you don't have access to, for example, the EnumWindows function allows you to wall through the tree of windows simply do not see the ones the process has no access to. SetWindowsHookEx which allows you to intercept and modify messages meant for other windows simply doesnt fire for messages you're not supposed to access.

Granted, outside of UWP apps, the application of security is rather lax (this is for legacy purposes, the security's there, just not enforced), but for apps running as admin, or UWP apps, the sandboxing is rather solid.

by torginus

3/22/2026 at 6:58:06 PM

Indeed, this is the right approach.

Moreover, it is possible to choose as the default policy that no program may access a window that it did not open, but then there must exist a very simple method for the user to specify when access is permitted, e.g. by clicking a set of windows to grant access to them.

by adrian_b

3/22/2026 at 5:57:28 PM

IMHO the security advantage of Wayland is mostly a myth and probably the same is true regarding tearing. The later is probably more an issue with respect to drivers and defaults.

by uecker

3/22/2026 at 7:12:40 PM

On my desktop computers and on most of my laptops I have never experienced tearing in X11, at least during the last 25 years, using mostly NVIDIA GPUs, but also Intel GPUs and AMD GPUs.

I have experienced tearing only once, on a laptop about 10 years ago, which used NVIDIA Optimus, i.e. an NVIDIA GPU without direct video output, which used the Intel GPU to provide outputs. NVIDIA Optimus was a known source of problems in Linux and unlike with any separate NVIDIA GPU, which always worked out-of-the-box without any problems for me, with that NVIDIA Optimus I had to fiddle with the settings for a couple of days until I solved all problems, including the tearing problem.

Perhaps Wayland never had tearing problems, but I have used X11 for several decades on a variety of desktops and laptops and tearing has almost never been a problem.

However, most of the time I have used only NVIDIA or Intel GPUs for display and it seems that most complaints about tearing have been about AMD. I have always used and I am still using AMD GPUs too, but I use those for computations, not connected to monitors, so I do not know if they could have tearing problems.

by adrian_b

3/22/2026 at 5:05:42 PM

> X11 was a security disaster.

This only matters if you compare properly sandboxed apps, otherwise an app that runs with your uid can still do harm and practically indirectly completely compromise the system..

Are most flatpaks _properly_ sandboxed? Of course not.

by zb3

3/22/2026 at 5:31:08 PM

And X11 always had a mechanism for isolating clients as well, i.e. trusted and untrusted clients. Nobody used it because it was irrelevant before sandboxing.

by uecker

3/22/2026 at 4:33:59 PM

A security disaster? Howso?

by calvinmorrison

3/22/2026 at 4:41:40 PM

Well, it allowed local users to actually use their computers for computing instead of just safely consuming "apps" -- obviously that needed to go.

by AshamedCaptain

3/22/2026 at 4:40:32 PM

Letting any GUI application capture all input and take full control of the desktop completely defeats the point of sandboxing and X11 does exactly that.

by m132

3/22/2026 at 4:54:08 PM

> Defeats the point of sandboxing

Sandboxing defeats the point of said applications. If you want your computer to have no functionality, check out Figma. A clickable prototype sounds like precisely the security the world needs right now.

by ceayo

3/22/2026 at 5:15:55 PM

So accordingly, ActiveX was a brilliant idea and any web page should be able to execute code in the kernel context, otherwise no meaningful functionality can be provided

by m132

3/22/2026 at 7:29:30 PM

The whole problem with wayland is this mistaken absurd belief that the security standards of a desktop are equivalent to those of a website.

by FeepingCreature

3/22/2026 at 4:57:52 PM

Yawn, X11 (and similar "unsecure" desktop environments) existed for half a century and the sky hasn't fallen. I'm tired of that "will somebody think of the children/grandparents" scare mongering.

by flohofwoe

3/22/2026 at 6:14:35 PM

It hasn't, but Windows has had its fair share of keyloggers, RATs, and so on, and I think we can all agree that anti-virus software is an inherently flawed concept.

The only thing keeping those away from Linux was its market share. With npm malware on the rise, this is no longer enough of a protection.

by m132

3/22/2026 at 5:42:44 PM

Keyloggers for example.

Linux always has been a system were the existence of malware was ignored, specially Desktop, contrary to other OSes (tooling included). But since a couple of years ago can be observed (I observe) slooow movements trying to correct this colossal mistake.

If this is the best way to do it or not, I do not enter. I particularly just welcome most of the advancements about this matter in Linux due such absence of worrying, keeping my fingers crossed that the needed tooling arrives on time (ten years behind Windows, I think).

by drtgh

3/22/2026 at 7:25:50 PM

so the security um, hack here is that someone has unauthorized access to your machine. its not related to x11. If you run untrusted code, thats it... who cares about x11?

by calvinmorrison

3/22/2026 at 4:58:37 PM

I have no love lost for Wayland, but this:

> Make easy things easy. Make hard things doable.

is generally unachievable. Instead, pick one:

- easy things easy, hard things impossible

- easy things tedious, hard things possible

(Unless you want to maintain two sets of interfaces in parallel.)

by fonheponho

3/22/2026 at 7:33:20 PM

Wayland makes it unnecessarily difficult to make simple clients. Gnome still doesn't support server-side window decoration and libdecor is an absolute nightmare and wayland-cursor doesn't even detect the system theme properly.

by mizmar

3/22/2026 at 8:04:42 PM

[dead]

by tempaccountabcd

3/22/2026 at 5:03:29 PM

This is quite easy and very widespread to accomplish by having helper functions for common operations.

by jampekka

3/22/2026 at 4:29:42 PM

I have used quite a bit of Gtk and QT, and have had to touch X11 or Wayland very little directly, EXCEPT for one case where I wanted to provide a global hotkey...

by javier2

3/22/2026 at 4:35:10 PM

Which is kind of understandable as Wayland tries to be more secure: and thus in Wayland not all keyboard events are propagated to all applications (that's what X11 does). I think it's a good idea to put security first in this iteration of FLOSS desktop technology.

by cies

3/22/2026 at 6:17:36 PM

Phoenix[0] has some good ideas about how X11 could be made more secure without breaking backwards compatibility. I don't understand what was so fundamentally broken about X11 as a protocol that it required a replacement protocol.

We can argue about limitations of X.org's implementation of the X server, but, as demonstrated by Phoenix, X.org doesn't have to be the only X server implementation.

[0]: https://git.dec05eba.com/phoenix

by MarsIronPI

3/22/2026 at 6:34:46 PM

I have no idea, but my impression was that basically nobody wanted to put in work on X11 anymore.

by javier2

3/22/2026 at 4:53:46 PM

Well kind of. It'll be several decades before we see any practical benefits - at the moment once you have local execution you can do anything you want - accessing other apps or even root is trivial.

by IshKebab

3/22/2026 at 4:32:14 PM

He complained there is no way to do the easy thing in Wayland - there is a way: Gtk and QT

by ape4

3/22/2026 at 4:51:03 PM

How do you make a global hotkey in all compositors with Gtk or Qt?

by 201984

3/22/2026 at 4:51:11 PM

...which is overkill when you only need a Vulkan or GL canvas which spans the windows client area... and even with GTK or Qt your app still stands out like a sore thumb on the "other" desktop environment because the window chrome doesn't match the rest of the system.

by flohofwoe

3/22/2026 at 4:40:30 PM

Writing 1300 lines of non-cross-platform windowing code sounds like masochism. GLFW is right there.

by motorpixel

3/22/2026 at 4:46:16 PM

That just moves the problem to the GLFW maintainers. The point is that the Wayland designers should have learned from the mistakes of 40 year old APIs, but they are not only repeating the same problems, they made it even worse. That's quite an achievement tbh.

by flohofwoe

3/22/2026 at 4:15:07 PM

I sidestep by using neovim as my environment for pretty much everything and you can bridge the SPICE virtio clipboard channel to Wayland. You can get clipboard sharing to work natively on wlroots compositors.

by Avicebron

3/22/2026 at 4:56:02 PM

Probably best off using a UI library like Avalonia: https://avaloniaui.net/

It satisfies the requirement to "make easy things easy, make hard things doable" and it also gets you cross platform support.

by breve

3/22/2026 at 5:22:30 PM

Sure puts the Wayland in Weyland-Yutani

by bleudeballe

3/22/2026 at 4:29:14 PM

The constant loud bile spewing over Wayland and systemd just won't stop here, will it?

It's getting a bit boring, especially since none really does more than complain.

by izacus

3/22/2026 at 5:03:28 PM

Tbh, 1300 lines of extremely cursed code to open a frigging window and GL context deserves that bile. Such a fundamental problem is also nothing that can be fixed through contributions except discarding the whole clusterfuck and starting over from scratch.

by flohofwoe

3/22/2026 at 5:45:25 PM

No, nothing deserves this constant whining and crying day in and day out.

Especially coming from people who don't put in the work to build something else.

It's really bizarre how the opensource community degraded into this space of constant aggresive, insulting screeching over every single project thats actually moving something in the Linux world. Coming from people who don't put any code behind it or do anything but attack any change since 1990s.

To hell with that, Linux developers deserve better than this constant barrage of hate.

by izacus

3/22/2026 at 7:59:33 PM

There are plenty of projects that move something in the Linux world.

The problem with systemd and Wayland is that they are not like any other projects which the users may choose depending on how useful they are for their needs.

Wayland and systemd are forced by a few distribution maintainers upon a great number of Linux users, regardless of what those users may want.

Many users may not be directly impacted by these changes, so they may trust that the maintainers know what they are doing.

There are also many users for which this replacements would require a lot of work so such users would expect a better justification of why systemd or Wayland are an improvement over alternatives.

I agree than it would be very desirable for X11 to be replaced by something better.

But I have never seen any piece of information that would indicate that Wayland is better. On the contrary, almost every detail that I learn about Wayland shows a bad design decision.

by adrian_b

3/22/2026 at 6:21:45 PM

Tbh, it's quite delusional to think that a better alternative solution would win that's not backed by Redhat and GNOME. In a purely competitive environment, a design like Wayland could never have "won" as an X11 replacement, it was pushed long enough until it was "too big to fail".

by flohofwoe

3/22/2026 at 7:30:07 PM

If the alternative really was better, why wouldn't they back it?

They backed systemd. I think you need to stop with conspiracy thinking and admit to yourself that maybe the solution was actually better than before. And as such, if you build something even better, they'll switch too.

But it has to BE better, not just a pile of yelling.

by izacus

3/22/2026 at 7:33:24 PM

The whining about Wayland an systemd is perfectly justified because unlike other open-source applications they are not chosen freely by the user.

For other open-source applications, if you do not like them you do not install them and you choose something else. There is no reason for any complaint.

On the other hand, you may have used some Linux distribution for a decade and then someone forces upon you systemd and/or Wayland, regardless whether you want them or not.

In such cases it is very reasonable to complain about this, because whoever has chosen systemd and Wayland now forces you to do a lot of unnecessary work, either by changing your workflow to accommodate them or by switching to another distribution, which also requires a new workflow.

I have not switched to either systemd or Wayland, because I have never seen anyone capable to explain even a single advantage of them over what I am using.

I have tested once systemd, by installing Arch and using it for a month, but I have found a bug so ugly that my opinion about the technical competence of the systemd designers has dropped so low that I have never tried it again.

I am using Gentoo, which unlike other distributions does not yet force the choices of the maintainers upon the users, so I can still choose to not use either systemd or Wayland. However, I am worried about the future because both of them continue to invade other software packages, so even without using the complete systemd you may need to use some parts extracted from it, because other traditional packages have been substituted with packages that depend somehow on systemd.

Eventually, it is likely that I would have to write myself replacements for those packages, to expel completely systemd, but I hate to do such unnecessary work when I was happy with the older packages, which worked perfectly fine and they needed no replacement.

by adrian_b

3/22/2026 at 5:28:55 PM

You should know that the constant criticism is basically what stabilized systemd - the core - and stopped systemd - the project - from stretching its arms over every component in the ecosystem, which obviously could create a single-point-of-failure. The upstream has made and still makes stupid assumptions that are totally denied by distros. You’re basically missing a lot of details here.

by esjeon

3/22/2026 at 5:44:32 PM

I seriously doubt spewing constant toxic bile did any of the sort.

by izacus

3/22/2026 at 4:35:22 PM

Especially systemd. Declarative management of services is a bad thing?

Some people just wanna complain

by vatsachak

3/22/2026 at 4:49:10 PM

I'd argue the Wayland hate is much worse. Not that it might be bigger than the hate on systemd, but contrary on the case of the systemd, there are no other real alternatives to wayland nor x. Wayland is attempting to improve over x but some (really noisy) people just suffer from fear of the new.

by Gualdrapo

3/22/2026 at 4:57:35 PM

There are ~three groups in the systemd debate.

People who grew up on sysvinit based service management and can't handle change (the partially straw man group you are complaining about).

People who only know about sysvinit based service management and systemd and formed their opinions of systemd based on "sysvinit == terrible confusing shell scripts; systemd == config files" (you - as a first impression).

And people who actually know the advantages, disadvantages, and functional details of sysvinit based service management, systemd, and the plethora of other attempts/approaches at solving these issues and can support their arguments in favour of or against systemd with actually reasoned arguments.

The first group is easy to ignore, and a minority. The third group produces the biggest chunk of well informed content on systemd. And the second group seems to think that anyone in the third group who is in favour of systemd, must be one of them, and anyone who is against systemd, must be in the first group (note also: the false dichotomy).

Rather than straw manning your opponents in this discussion while pretending this is a discussion of the pros and cons of "declarative service management", could you instead contribute something useful? Lacking that, maybe just stop trying to contribute?

By saying stuff like this, you aren't going to convert sysvinit users to anything and you aren't going to convince anyone who has genuine criticism of systemd of anything.

by Arch-TK

3/22/2026 at 6:08:13 PM

You're right I do fall into category 1

by vatsachak

3/22/2026 at 4:56:24 PM

Yeah Wayland I get. It's still kind of janky even after almost 20 years. Complaining about Systemd makes no sense though. It works very reliably, switching to it caused no issues, and it has fixed a number of problems with the Linux desktop.

Some people just want to live in the 80s forever.

by IshKebab

3/22/2026 at 5:33:24 PM

"Some people just want to live in the 80s forever."

I think this shaming of free software users that want to make other choices is rather terrible.

by uecker

3/22/2026 at 4:43:21 PM

But haven't you heard that systemd is an evil project made by Microsoft to somehow destroy Linux and make everyone use Windows? It must be true because I saw it on Reddit.

by flexagoon

3/22/2026 at 4:50:35 PM

That is a strawman. That is not the aspect of systemd people object to.

by graemep

3/22/2026 at 6:07:51 PM

That's fair. I have not interacted with it beyond using journalctl to debug various services and I found it easy to work with

by vatsachak

3/22/2026 at 4:52:19 PM

Systemd sucks though for good reasons.

by righthand

3/22/2026 at 4:40:57 PM

Reminds me somewhat of Vulkan. I think the trend of making the actual specification of something lower level and less convenient is rather logical. Why burden implements with a load of convenience functions when that could be left up to libraries?

by James_K

3/22/2026 at 4:55:30 PM

> when that could be left up to libraries?

Because those libraries will not materialize in time, and more importantly the hobbyists who are supposed to write those libraries don't have the testing capabilities of large organizations (e.g. testing across hundreds of hardware configurations).

by flohofwoe

3/22/2026 at 5:18:34 PM

...or worse, the libraries do get written, but multiple times in mutually-incompatible forms that are tightly coupled to specific compositors / desktop environments. (Screengrabbing, anyone?)

by robinsonb5

3/22/2026 at 4:29:51 PM

unreadable font

by toinewx

3/22/2026 at 4:56:00 PM

Whole website is unreadable on mobile

by jqbd

3/22/2026 at 7:18:27 PM

Firefox Reader mode. As long as that works, as was the case on this site, I don't care how bad pages people make.

by 1313ed01

3/22/2026 at 3:58:15 PM

I can say I hate all GUI programming! Luckily, all my professional programming deals with back-end processing, so I was able to avoid GUIs :)

So I feel your pain. I did hear programming for Wayland is harder than X11, but I never did either so I have no idea if that is true.

by jmclnx

3/22/2026 at 4:38:00 PM

Poor soul — they missed `wlroots` in their googling! You’re not supposed to be solving these issues yourself.

by bbor

3/22/2026 at 4:52:10 PM

He's writing a client, and wlroots is a library for writing servers. It would not have helped at all.

by 201984

3/22/2026 at 4:58:23 PM

Poor sould -- they should have googled `wlroots` before their commenting.

by ceayo