Author Archives: pappp

I was having Vulkan/Wine interaction issues when I had a minute to play a game the other night and flipped my big laptop (which has Intel/AMD Polaris12 dual graphics, both running the Mesa stack since AMD dropped Polaris support in amdvlk in the 2023.Q4 release) into a Plasma Wayland session (v5.27) to see if it helped. It did – making it the very first thing I’ve encountered that worked in Wayland and not X – so I’m rolling with the Plasma Wayland session for a couple days to see how things are. I have a little machine I’ve been playing with Hyprland on to check out the Wayland situation, and it’s been closing from “Linux 20 years ago” to “Linux 5 years ago” in terms of brokenness, so it seems plausible that one of the big two would be tolerable now.

I’m totally onboard that xf86->xorg is an unmaintainable mess for both legacy-codebase and design from a different era reasons, and it would be nice to start with something built on assumptions that match modern reality, but uh… over a decade in, Wayland is just getting to be less of a “almost a tech demo” and more of an “almost there.” If the devs can shut up about some bikeshedding that obstructs common use cases now over concerns about theoretical security issues or compatibility with yet-unimagined future interface models and implement widely-accepted solutions to the last few basic-fucking-features, it might actually matter before it too starts to exhibit wrong ancient assumptions and gets replaced, but it looks like they’ve missed the bus on a couple of those necessary standardizations.

Things I use regularly that are currently broken in KDE’s Plasma Wayland session in Nov. 2023:

• The mere fact that I have to specify it’s a KDE Plasma session for all these details because every compositor is having to reinvent a bunch of wheels in differently-broken ways – input plumbing, session management, etc. They could have at least spun some reference libraries and treated anyone who didn’t use them when building desktop-like interfaces as a second class citizen to paper over the necessary parts to build a desktop they didn’t want in the core protocol (and for some of them someone else did it; see PipeWire). Wayland’s entire development process is built around former X devs being exceptionally gunshy about maintenance and attempting to avoid having any meaningful implementation under their auspices, and it’s causing a lot of goofy decisions. wlroots was too little too late.
• KeepassXC can’t do its autotype into last active window thing.
  • Relevant Bug
  • Because Wayland completely abdicated on input plumbing and programmatic window selection. It even sort-of works between xwayland windows because X is a feature-complete desktop protocol and Wayland isn’t.
  • I use this ALL THE TIME and it drives me CRAZY. Browser extensions are not a comparable solution, I auto-type credentials into all kinds of windows.
  • They finally accepted ext-foreign-toplevel-list so the plumbing for window selection is theoretically there… but I don’t think any compositors implement it yet.
  • The pipe-input-to-a-specifc-window shit is still being bikeshedded over mostly-irrelevant security concerns. Maybe maybe the ever-contended global hotkeys stuff in xdg-destop-portal will make it possible, but since every compositor has sprung a bespoke portal variant, even that may not comprise a global solution, and it’s not entirely clear it’ll work for piping arbitrary strings anyway.
• Everything restores to a random virtual desktop, if it restores at all.
  • KDE Bug for sessionrestore and also xwayland session restore
  • I think only the xwayland windows are restoring because, refrain, X11+extensions is actually a complete desktop protocol and Wayland still isn’t.
  • There’s no generic solution, and gnome spun their own internal bullshit which seems to be further sandbagging a general solution.
  • KDE is thus also spinning their own internal bullshit, so everything will be broken forever.
  • This is like basic 90s shit being fundamentally bobbled.
• Firefox PiP windows
  • The wayland devs are still busy insisting the use case supported on every major windowing system including the coercive prisons like iOS and Android for years is wrong
  • They might be right that it shouldn’t be a specific feature, there should probably be more layers exposed than there are in general. The interaction of always-on-top and things like trays and bars is also janky I just don’t run into it quite as often.
  • Ed: …and sometimes it now not only works but shows the control I was having trouble with in the next point when right clicked.
• The “Move to Screen” context menu item in the task switcher seems to have vanished? I can still do “Move” and scoot a program to the desired monitor and it seems to snap correctly, but sometimes fullscreen windows relocated that way jump back to the first display. Apparently it has never been available from the task manager, only the title bar right-click menu and my memory is faulty.
• I don’t know if it’s Wayland related, but baloo has started acting up again. I’m regularly seeing baloo_file_extractor eating a whole core when it hits things like openembedded trees. It’s possible I just disabled it in my saved X session and it’s being started again because the session management carryover between X and Wayland Plasma sessions is half-working.

The whole situation is silly. It’s a gigantic shell-game of trying to outsource the solutions to problems everyone already knew needed to be solved consistently because the ICCM and EWMH stuff for X represented decades of effort to do so, by the people best situated to actually solve the problems at the time when they could be solved in a general way.

I sometimes get the feeling reading the bug trackers that many of the Wayland people are building a display layer suitable for infotainment systems, kiosks, signage, and that sort of thing, and desktop functionality is an unfortunate extra thing some people are trying to force on them – which, financially, may be the case.