[vbezhenar]

Powerful permissions are needed for powerful apps.

I don't know about this particular issue, but for example, KiCAD has multiple issues with wayland being overly protective: [0]. For example KiCAD needs the ability to move cursor to provide good user experience. KiCAD needs the ability to move and place windows wherever it likes. KiCAD needs to control focus. KiCAD needs to prevent OpenGL throttling on inactive windows. These issues led KiCAD developers to reduce support for Wayland configurations to a bare minimum.

So it's a delicate balance for operating systems to both allow powerful apps to implement complicated UI and to prevent badly written apps to do inconvenient things.

[0]: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support...

[arghwhat]

s/KiCAD needs/KiCAD wants/

As a user of KiCAD, I have not found any need for it to automatically move cursors or windows around (nor do I even remember such behaviour pre-wayland, so it can't have been important), but note that the cursor-warp protocol is coming to allow the former, and window tags are coming to allow things like window placement restoration, which should help where this may benefit UX.

Technical note, OpenGL is for rendering, which is unrelated to presentation. Window managers and display servers have no part in that process. It's the Window System Integration (WSI) if used, such as EGL or Vulkan WSI, and in the old days GLX, that talk to the display server.

Wayland only provides an optional suggestion for when it is a good time for a window to render for good frame pacing, latency and performance without the app having a full proper frame scheduling implementation itself. The issue that tends to crop up is that EGL, a WSI often used with OpenGL in apps not using a toolkit, when specifically told to block and wait for next frame, has been internally implemented to use the optional suggestion which is not provided for invisible windows.

Stuff is being done to solve this, and it doesn't affect applications that do not ask to block on updates (say, firefox), nor applications leaving this up to a toolkit (say, Gtk or Qt) or just a different window system integration than EGL (which is extremely limited on its own anyway).

[vbezhenar]

> As a user of KiCAD, I have not found any need for it to automatically move cursors

Well, the first thing you do with KiCAD is scrolling to zoom in and out, and KiCAD scroll works in a way to jump cursor to the center, so you basically can pan and scroll at the same time. That's default behaviour unless you changed it in the settings, and, obviously, it needs to warp cursor to the center of the window.

[arghwhat]

The way pan-and-scroll works in every other CAD program has been that zooming with the cursor off-center is a panning zoom (zoom centering on the cursor position), without the cursor warping anywhere, so that seems like a reasonable behavior. I do see that the described behaviour can be convenient, but definitely not a deal-breaker in the space.

Maybe I changed the config, can't remember and I must admit that it's been a little while since I had to fire it up.

[ruszki]

I think, you can solve that with keyboard/mouse shortcuts without moving the cursor at all. What’s the reason why they don’t do that?

[jdiff]

You cannot get the level of control out of keyboard shortcuts that you can with fine grained mouse movements. It'd be like trying to play a videogame while controlling camera movement with a controller DPAD/arrow keys.

[ruszki]

I didn’t talk about using keyboard alone…

[jdiff]

You didn't, but if we're introducing the mouse, we haven't dismissed the issues stemming from the lack of pointer warping.

[jchw]

Unfortunately the KiCAD messaging has been a bit messy. They list a spectrum of issues, some of which are very vague and also clearly issues with KiCAD (like "Application freezes and crashes: Instability issues specific to the Wayland environment" - unless the compositor is crashing I fail to see why you would assume KiCAD crashing is an issue with Wayland or your compositor.) On the other hand I don't really blame application developers for being frustrated in general, because a lot of us have been waiting a really long time to see Wayland issues get resolved, and the pace was so slow until recently that it basically felt like it would take an eternity for anything to get resolved. These days though, the pace is very fast, to the point where almost anything written about Wayland will be out of date in a couple of months, mostly for good reasons.

> KiCAD needs the ability to move cursor to provide good user experience.

Most applications are implementing pointer warping using pointer-constraints-unstable-v1. This lets you confine the pointer to a region, at which point you can use relative events to get movement, render the cursor yourself and do whatever you want. There is the locked_pointer_v1::set_cursor_position_hint function to allow one to set the location where the cursor should be released at when the constraint is lifted, which should make everything seamless.

And sure, it might actually be that pointer-constraints-unstable-v1 isn't enough for KiCAD's particular UX somehow, maybe they need pointer-warp-v1 or something even more advanced. However, applications generally don't need to set the mouse position to arbitrary locations on-screen at any time... That is a useful capability for something doing automation, but it should really not be needed for general application development.

> KiCAD needs the ability to move and place windows wherever it likes.

KiCAD isn't a window manager, it's a damn EDA tool. I do agree that Wayland needs to provide multi-window applications with better tools to hint to the compositor what to do with window placement and especially to save and restore window positions, but this doesn't translate to "applications need to be able to decide where exactly windows go." There is basically no behavior which literally requires this, and certainly no sane behavior that requires this.

Having every application perform its own sort of logic to decide where windows go is a mess everywhere it exists. It would be cleaner and better for users if we could just figure out what sorts of higher level tools applications need for good UX and try to build around that. In most cases merely being able to position windows relative to each-other is enough. (You can obviously do this in Wayland already to some extent, though I'm sure there are missing tools that are needed.)

On Wayland today, applications can't absolutely control window placement, or even know where they are on screen. There really isn't even a global window coordinate space to even leak to applications. It's a pretty radical departure from almost everything else, so yeah, application developers are obviously not thrilled about having to deal with it. But on the other hand, it's probably the right way to go. Just because ability to control absolute positions is convenient does not mean it is necessarily the right way to go, especially if you can provide higher level tools that encode intent better and let the user decide how your application's intent should be interpreted.

> KiCAD needs to control focus.

Honestly I have no clue what they're complaining about with focus. It's too vague.

If your application is in the foreground, you can grab an activation token and use it, so even with "extreme" focus protection, there should not be any issues with KiCAD being able to focus its own windows.

As for other software being able to focus itself from KiCAD, well, this article describes how you do it. It's pretty straight-forward and it's not obvious how you would misuse it. Pretty sure the same protocol exists in X11 as well.

They're also talking about modals, which might be related to their complaints. The xdg-dialog-v1 protocol (supported in KDE 6.4, GNOME 48, and used by Qt 6.8+) gives applications the ability to mark dialogs as modals. It is a bit crazy that it took as long as it did for this to become supported by everything, but it did cross the finish line. On Ubuntu 25.04, for example, you should get GNOME 48 and Qt 6.8.

> KiCAD needs to prevent OpenGL throttling on inactive windows

OpenGL isn't throttled, it is stalled if the window is entirely occluded. You can now resolve this issue with the fifo-v1 protocol and Mesa 25.0 or newer. For example, Ubuntu 25.04 ships Mesa 25.x and GNOME 48 which has fifo-v1. fifo-v1 is also available in KDE as of 6.4.

This should give applications the frame pacing behavior that they want. It is possible to work around the issue to some degree, it's just annoying.

If KiCAD developers don't want to support Wayland because it's effort they'd rather spend on other shit then fine, XWayland should mostly continue to work as-expected anyways. Best option for now is to force KiCAD to use X11, like Krita does. I'm sure that's not a 100% panacea but it should be good enough especially if KiCAD is so buggy on Wayland that it actively crashes.

[magicalhippo]

As I understand it, a big issue for KiCAD is that it's old, so they went with WxWidgets as Qt wasn't a viable option[1].

It's also a conglomerate of executables, so focus transfer often won't be between windows in the same process, but windows in different processes.

[1]: https://forum.kicad.info/t/what-is-the-future-of-wxwidgets/2...

[jchw]

I don't think it's absolutely necessary to move off of wxWidgets for Wayland support to be in decent shape in the long run. There is definitely a path forward that wxWidgets can improve its Wayland support, or KiCAD can add its own specific Wayland support bits to work around what wxWidgets can't do, if they want. It might take time, but that's OK...

There's different ways to approach it that are equally pragmatic. Any of these approaches, possibly a combination of them, seem totally reasonable to me:

- Force X11, or at least prefer it when DISPLAY is non-empty. Probably also display a warning when loading on Wayland, since the experience is known to be sub-optimal. Let things sit for a while until Wayland looks mature and well-supported enough to basically rip off the bandage. This is a good option for most programs. Krita is doing this. Users understand this, other developers understand this, etc.

- Make specific efforts to support existing Wayland compositors even in spite of its limitations. Godot has been doing borderline heroic things to make Wayland first-class (check out how they're working around the lack of something like XEmbed - it's pretty intense.)

- Participate in the process of proposing Wayland protocols or new versions of existing protocols to fill in holes gradually. It's not a fun process anymore than any other standards process, but it's a way you can help the entire ecosystem out and impart some of your knowledge/experience into the protocol design in the process.

And ultimately, I don't really think there's anything wrong specifically with listing the problems that a program has when running under Wayland, it's very helpful to have a list that people can keep track of over time (like KDE's old "Wayland showstoppers"[1] page.) I do think that KiCAD's current list is overly opinionated on what the true root issue is even when it's subjective. I think it's better to frame things more in line with what doesn't work and a first-order "why" - i.e. "Pointer wrapping does not work because the current implementation in KiCAD relies on being able to set the absolute position of the cursor which is not available on Wayland." "There are currently stability issues on Wayland that don't occur on X11." etc. whereas now it feels like it's just a list of complaints, sometimes without enough information to know what the actual issues might even be.

I personally don't like wxWidgets very much, but it does have its advantages, and I'm sure a future can be built to be able to update wxWidgets applications to run smoothly on Wayland and maybe other future window systems, possibly by adding some new abstractions and tools.

> It's also a conglomerate of executables, so focus transfer often won't be between windows in the same process, but windows in different processes.

While that does complicate things, it's pretty tractable with some IPC. If you only need to change focus when `exec`ing (consider: this might be the case even when there's already a window open, if you're using something to do single-instancing) then it's even simpler as you can use the "standard" approach of passing the token via en environment variable on exec (then IPC'ing it to the instance in a single-instance situation.) I think this is what you want to do anyway on Linux right now, not just on Wayland.

[1]: https://community.kde.org/Plasma/Wayland_Known_Significant_I...

[magicalhippo]

> There is definitely a path forward that wxWidgets can improve its Wayland support

Seems there's some willingness[1] to do just that.

> or KiCAD can add its own specific Wayland support bits to work around what wxWidgets can't do, if they want

From what I gather the KiCAD devs are very much against that, as it would detract manpower from the core product, ie KiCAD itself, which is understandable.

> whereas now it feels like it's just a list of complaints, sometimes without enough information to know what the actual issues might even be

Then again, I can understand their frustration. Wayland makes Python 2 to Python 3 seem like a well-executed transition. Wayland is soon older than X11 was when Wayland got started, and it's still a mess.

Though as you say, it feels (as a user) like it's improving a lot more lately. So I think the strategy of the KiCAD devs to essentially ignore Wayland for a bit longer is a good one. In a few more years support all around is likely a lot better, and then it might make sense to spend a bit of time adding bespoke Wayland code to KiCAD.

[1]: https://gitlab.com/kicad/code/kicad/-/issues/7207#note_14094...

[senko]

> Wayland is soon older than X11 was when Wayland got started

Wayland was started in 2008, X11 in 1984 (according to Wikipedia). That makes X11 41 and Wayland 17 years old, respectively. X11 was 24 when Wayland was started.

That's without considering X11 was not a fresh start (it's 11th version of an existing protocol, so it did have some baggage), and that there was an explosion in complexity in hardware, software, security and networking for the past 30 or so years.

The functionality surface area that's "table stakes" for Wayland is a lot larger than it was for X11.

[magicalhippo]

I was considering X11 first release vs Wayland start. Sure not completely apples to apples. My primary point was more that Wayland is a very old project at this point, yet in many key areas it is quite immature. Primarily on the implementation side.

[jchw]

> Seems there's some willingness[1] to do just that.

I'm glad the wxWidgets developers are being helpful here.

> Wayland is soon older than X11 was when Wayland got started, and it's still a mess.

To me the Wayland transition is less about Wayland and more about finally breaking the dependency on X.org. It was a long, long, long time coming, and there were a lot of prerequisites to get there. KMS, DRM, EGL, GBM, dmabufs, libinput, etc.

I believe the immutable aspects of Wayland are perfectly serviceable and it should have a good shelf-life. I hope to see more advantage taken of the fact that Wayland is capabilities-based, more edge-cases of protocols nailed down, and I also hope the Newton accessibility bus sees more development as it seemed very promising.

I realize people are upset at how long things take. In my opinion, community-driven open source is pretty good at long-term things and bad at short-term things. The Wayland color-management MR took five years, but paging through the threads it's easy to appreciate the amount of thought that went into it and feel like it really lays a solid foundation for the future. With desktop systems evolving about as slowly as ever, I think this a tractable situation, and being a daily driver of Wayland on several devices I feel like it's been a long time since I felt the free software desktop was this close to parity with the competition in terms of features and to some extent, even productivity, dare I say. (I really like what KDE Plasma has done.) I honestly think the most major blocker for Wayland remains full parity for NVIDIA devices, and from that point forward the real main challenge for the Linux desktop will go back to being software and hardware support as it arguably once was.

[lelanthran]

> it should really not be needed for general application development.

That attitude is the problem, I think.

The functionality in question is irrelevant. What is relevant is that, presumably, Windows and Mac and X11 users of Kicad use this functionality.

The onus is on the Wayland team to justify the decision to take away a feature currently in use, not on the user base to justify switching to another system.

[jchw]

> What is relevant is that, presumably, Windows and Mac and X11 users of Kicad use this functionality.

Windows and Mac and X11 users do not praise KiCAD for its ability to absolutely position the cursor. Windows and Mac and X11 users praise KiCAD for having a nice UX. You can definitely implement features like infinite panning in today's Wayland compositors, you just can't do it by absolutely setting the cursor position.

> The onus is on the Wayland team to justify the decision to take away a feature currently in use, not on the user base to justify switching to another system.

This is a genuinely cancerous mentality. When you design a new API, "the old API had a function that does this" is not a valid justification. If you can't find another justification for why the function should exist, it means that it shouldn't. That's what designing from first principle looks like. I have actual reasons why the old functionality (getting/setting the absolute cursor position) is not an API that I want, too, but that's not even the point. API functionality should be able to stand on its own and justify itself. If you can't start on a completely clean slate, why even bother trying to design a new API in the first place?

It doesn't matter if Windows, macOS, X11, Haiku, BeOS, SkyOS and TempleOS all provide this functionality, that's not a good justification, that is just argumentum ad populum. It is a useful API primitive, because it can be used to implement other useful things, and a ubiquitous API primitive, but that doesn't mean it's a good API primitive. On the contrary, most of these desktop systems were designed a long time ago, and now modern OSes are actually having to come up with ways to carefully limit a lot of these sorts of very powerful legacy APIs because they can lead to security and privacy issues. As an end user and computer owner, I don't want random applications running on my desktop to be able to get or set the absolute cursor position on screen, especially when the window is not focused. And if I don't want that, then the next obvious question is, does something like KiCAD truly need that? Of course not. Applications need primitives that can implement the controls and UI that they want, but you don't just get to decide what those primitives are, as an application. As an application, you get to deal with the primitives that you're given, because by definition, that's literally the job of an application developer. And when those primitives prove insufficient to implement some UI, then we can discuss how to fix it, but the answer isn't "this old API just let me get/set the global cursor position so can I have that?" And if you don't like some system you don't have to support it. But Apple is a complete and utter dickhole to application developers, requiring all kinds of dumb signing bullshit and pushing users to huge proprietary APIs like Metal, and yet open source projects are happy to sink plenty of developer hours (and often money) into it anyways, even though its desktop marketshare is only somewhat more impressive than Linux anyway. So forgive me if I don't shed a tear because it required a bit more work to do something in Wayland than it did elsewhere.

And yes, I know: you can come up with an application that really truly actually does need this. There are a handful, like automation software, or a remote desktop server. Actually though, pretty much all of the modern Wayland desktops support being able to get or set the absolute cursor position for that use case, it's just that it will usually require a permission prompt, at least the first time you use it. (There are some exceptions. wlroots/SwayWM doesn't require a permission prompt for this, the functionality is exposed as long as applications are not sandboxed.)

Application developers have developed this sense of ownership over the desktop that has become very annoying. No. I want my desktop environment to act as the owner of my desktop, the same way I want my window manager to control the management and positioning of my windows. Your applications just get to live in that world, the way that web pages get to live in a web browser.

Love it or don't, Wayland exposing higher level APIs for things that used to be implemented by application developers using lower level APIs is a step in the right direction for higher quality desktops and for user's control over their own desktops.

[lelanthran]

> Windows and Mac and X11 users do not praise KiCAD for its ability to absolutely position the cursor.

What does praising have to do with it? After all, I use my television remote mainly to control the volume, but I have never praised the ability to control the volume.

> When you design a new API, "the old API had a function that does this" is not a valid justification.

That is not the justification I, and others, gave; it's essentially a strawman that pops up in every single Wayland conversation.

The justification is "Windows, Mac and X11 allow this feature."

At that point, the onus is on the Wayland devs to justify why they are removing a feature found in every mainstream desktop OS.

> It doesn't matter if Windows, macOS, X11, Haiku, BeOS, SkyOS and TempleOS all provide this functionality, that's not a good justification, that is just argumentum ad populum.

Well ... yes? What's wrong with that? What's wrong with the argument "All the competitors provide this"?

[jchw]

> At that point, the onus is on the Wayland devs to justify why they are removing a feature found in every mainstream desktop OS.

You actually haven't come up with any good reason to justify this, you've just repeated it as fact for some reason. And what's weird is, there's no point in doing this. Like, I can understand doing this maybe earlier, when there was possibly a question if Wayland would succeed; at that point, the proponents, designeds and developers of Wayland and Wayland software had something to prove.

But guess what? It's over. There's no more fight for Wayland to prove itself. Wayland is, for now, here to stay. We are done with that part of things. Nothing will literally stop someone from using X.Org, anymore than you are stopped from doing anything with your own computer, but the Linux world is largely moving on. Application developers are largely moving on. Toolkit developers are largely moving on. Desktop environments are largely moving on. Distributions are largely moving on. And nobody in this process is losing immense sleep over wxWidgets or KiCAD not having complete parity because it's not a big deal. We genuinely have more important things to worry about.

So framing this fight with whatever basis you personally feel appropriate is a waste of my time and a waste of your time. If your best justification is 'everyone else was doing it in 1999', you can pipe it to /dev/null and save us all some time. We don't care.

So no, the onus is absolutely on you to justify this. You can't decide where the onus belongs because you're literally not in a position to do so, the Wayland project, for all of its faults, has largely succeeded and doesn't need to justify itself in this fashion anymore.

All modern desktop systems supported silently querying and setting the absolute position of the cursor... Before Wayland. Wayland became a modern desktop system that doesn't, so now not all modern desktop systems support that. And if a commercial vendor ever decides to design a new desktop system from scratch, you can bet all of the hairs on your ass it will have nearly the exact same limitations.

[lelanthran]

> You can't decide where the onus belongs because you're literally not in a position to do so, the Wayland project, for all of its faults, has largely succeeded and doesn't need to justify itself in this fashion anymore.

TBH, "need" doesn't come into it. It can't. There's no justification for not maintaining feature parity with current competitors.

Further, users don't care about your purity tests, they care about being able to run applications, like KiCAD.

There is no justification in the world for "It's a feature to have applications that break only on our system". After all, with this specific feature, there's lots of ways to allow it without compromising security.

You want security on your desktop? You get it. I want KiCAD on mine? I get it.

What, specifically, is the reason that you feel so strongly that only one option must be enforced?

I'm not being facetious, I'm genuinely curious here: how does enforcing "no pointer warping" for you and relaxing it for me, hurt you?

[throwaway2037]

    > "applications need to be able to decide where exactly windows go." There is basically no behavior which literally requires this, and certainly no sane behavior that requires this.

I just had a thought. Whenever I pop-up a child dialog (incl. message boxes) in a desktop UI app, I normally (1) center it over the parent window, or (2) place to the right of the parent window so that many layers of blocking child dialogs common in complex config settings build a "UI train" from left to right. In both cases, I am using "pixel perfect" placement of these windows. I never had any users complain about it. Is this not a valid use case?

[jchw]

That can be done using relative window placement. It's not about pixel-perfect placement, but absolute vs relative.

[nottorp]

> KiCAD needs to control focus.

I don't know what KiCAD is, but it certainly does not need to control focus OS wide. Only between its own windows.

It's probably not KiCAD's fault that the windowing system doesn't work like that, but still...

[suspended_state]

The page states:

> Unpredictable window focus behavior that can interrupt workflows

Which isn't exactly the same issue, so indeed it doesn't need to control focus.

[nottorp]

That sounds like my problem with focus being stolen by random apps while i work :)

[gf000]

They are free to create new protocols (or use existing ones) that allow these higher privileged functionality. Then the server implementation will hopefully figure out a decent way to request that permission and the app can then have it.

(Though this permission may be display server-dependent, as it may not make sense in case of each).