Elementary OS 8.1 Switches Over To Wayland Session By Default
Thirteen months after the release of Elementary OS 8.0, Elementary OS 8.1 is now available for this Ubuntu 24.04 LTS based Linux distribution that focuses on ease of use and usability. With Elementary OS 8.1 they have transitioned to using the Wayland session by default… ⌘ Read more

Weston 15.0 Alpha Released With New Protocols, Experimental Vulkan Renderer
After being delayed by three months to allow additional time for new features to land, Weston 15.0 Alpha 1 is out today as a big feature release for this reference Wayland compositor… ⌘ Read more

MPV 0.41 Released With Wayland Improvements, Vulkan Hardware Decoding Preferred
MPV 0.41 is out today as the newest feature release for this MPlayer/mplayer2-derived open-source video player. With MPV 0.41 there is a big focus on improving Wayland support as well as now preferring Vulkan Video acceleration over alternative video decode APIs… ⌘ Read more

Darktable 5.4 RAW Photography Software Reaches Parity Between X11 & Wayland
Darktable 5.4 is out today as the newest feature release to this open-source RAW photography software. Besides improving camera support, UI enhancements, and more the Wayland support has been improved with Darktable. With today’s Darktable 5.4 release, the Wayland support should be on par with the X11 support… ⌘ Read more

Wayland Protocols 1.47 Released With Updated Color Management Protocol
Following the Color Management protocol introduced in Wayland Protocols 1.41, out today is Wayland Protocols 1.47 with various revisions to that color management and HDR support… ⌘ Read more

TrixiePup64 11.2 Released For Debian-Based Puppy Linux With Wayland & X11 Options
For those with fond memories of the original Puppy Linux as a lightweight Linux distribution that used to run well back in the day on systems with less than 1GB of RAM, TrixiePup64 is out with a new release of this Puppy Linux based distribution with Debian GNU/Linux components. The new TrixiePup64 11.2 release is based on the latest Debian Trixie sources while continuing to offer separate builds for either X11 or Wayland usage… ⌘ Read more

Budgie 10.10 Desktop Approved For Fedora 44 Packaging, Fedora Budgie Spin All-Wayland
In addition to approving Fedora Cloud switching /boot to a Btrfs subvolume, another change approved this week by the Fedora Engineering and Steering Committee (FESCo) is for shipping the Budgie 10.10 desktop packages in Fedora 44… ⌘ Read more

Firefox 147 Beta Released With XDG Base Directory Support
With Firefox 146 released, which is exciting for delivering fractional scaling on Wayland, Firefox 147 Beta is now available and it’s also quite exciting to Linux users for another reason… ⌘ Read more

Firefox 146 Now Available With Native Fractional Scaling On Wayland
Firefox 146 has been released with native fractional scaling support on Wayland – finally giving Linux users crisp UI rendering. Other new additions include GPU process improvements on macOS, developer-focused CSS features, and broader access to Firefox Labs. Phoronix reports: Firefox 146 also now makes Firefox Labs available to all users, … ⌘ Read more

Firefox 146 Now Available With Native Fractional Scaling On Wayland
The Mozilla Firefox 146.0 release binaries are now available with a very exciting improvement for Linux users relying on Wayland… ⌘ Read more

Rust-Written Redox OS Sees Initial Wayland Port
Developers behind Redox OS, the original open-source operating system written from scratch in the Rust programming language, have ported Wayland to it with initially getting the Smallvil Wayland compositor up and running along with the Smithay framework and the Wayland version of the GTK toolkit… ⌘ Read more

NVIDIA 590.44.01 Beta Linux Driver Released With Wayland Improvements
NVIDIA today released the 590.44.01 Linux driver build as the first beta of their R590 series driver branch for Linux customers… ⌘ Read more

Common Desktop Environment “CDE” 2.5.3 Released After Two Years
Two years and one week since the prior point release, Common Desktop Environment 2.5.3 is now available as the latest iteration of this Unix desktop environment built around the Motif toolkit. CDE has been open-source for more than a decade now but its development not exactly brisk. But for those resisting the likes of Wayland and other modern display tech – especially with KDE announcing today Plasma 6.8 will be Wayland-exclusive – CDE 2.5.3 is now avail … ⌘ Read more

KDE Plasma 6.8 Will Go Wayland-Exclusive In Dropping X11 Session Support
KDE developers announced they are going “all-in on a Wayland future” and with the Plasma 6.8 desktop it will become Wayland-exclusive. The Plasma X11 session is going away… ⌘ Read more

libinput 1.30 Released With Support For Writing Plug-Ins In Lua
Red Hat’s leading Linux input expert Peter Hutterer released libinput 1.30 today as the newest update to this input handling library used on both X.Org and Wayland desktops… ⌘ Read more

Raspberry Pi OS 2025-11-24 Brings HiDPI Improvements, Wayland Enhancements
In addition to debuting the Raspberry Pi OS Imager 2.0 app, Raspberry Pi today announced the latest version of their operating system… ⌘ Read more

Wayland Protocols 1.46 Released With New Experimental Additions
Wayland Protocols 1.46 released this evening with new experimental protocols for text improvements as well as refinements to the color management protocol for HDR… ⌘ Read more

Is pasting from clipboard broken on Wayland or smth? ⌘ Read more

Blender 5.0 Released
Blender 5.0 has been released with major upgrades including HDR and wide-gamut color support on Linux via Wayland/Vulkan, significant theme and UI improvements, new color-space tools, revamped curve and geometry features, and expanded hardware requirements. 9to5Linux reports: Blender 5.0 also introduces a working color space for Blend files, a new AgX HDR view, a new Convert to Display compositor node, new Rec.2100-PQ and Rec.2100-HL … ⌘ Read more

Blender 5.0 Released With Better Vulkan Support, HDR On Wayland
It’s the Blender 5.0 release day! Blender 5.0 is a big step forward for this open-source 3D modeling software with better Vulkan viewport support across different GPUs/drivers, HDR support when using Vulkan and Wayland on Linux, and other very nice refinements for this popular cross-platform software package… ⌘ Read more

Wayland-Only Budgie 10.10 Desktop Preview Released
At the start of the year developers behind the Budgie desktop environment hoped for shipping Budgie 10.10 in Q1-2025. We are now in Q4 without a stable release but at long last a preview version is at least available. Budgie 10.10 is the point at which Budgie is going all-in on Wayland in leaving behind the X11 desktop session support… ⌘ Read more

NVIDIA Highlights The Shortcomings With Wayland Screencasting
In addition to showing the need for unifying DRM driver-side APIs within the Linux kernel, NVIDIA’s Linux graphics driver team at XDC2025 also showcased the shortcomings of screencasting under Wayland… ⌘ Read more

The State Of The Vulkan Renderer For Wayland’s Weston 15.0 Compositor
With the upcoming release of Weston 15.0, this Wayland reference compositor will finally feature a Vulkan renderer. For those curious about its potential, a presentation recently outlined the current state of this Vulkan code path… ⌘ Read more

How System76 & Red Hat Hope To Finally Improve The Linux Multi-GPU Experience
System76 engineer Victoria Brekenfeld and Red Hat engineer Sebastian Wick presented at the recent XDC2025 developer conference with their hopes of finally fixing the multi-GPU experience on Linux. As part of this is getting the necessary Wayland protocols in order as well as a new gpu-daemon service for proper multi-GPU handling for the Linux desktop… ⌘ Read more

Qt Merges Wayland Color Management “color-management-v1”
The Qt toolkit has merged support for Wayland’s color-management-v1 protocol to replace the former xx-color-management-v4 protocol shipped by this open-source toolkit. The change was merged for Qt 6.11 development but also back-ported for the Qt 6.10 series… ⌘ Read more

LXQt 2.3.0 released
LXQt, the other Qt desktop environment, released version 2.3.0. This new version comes roughly six months after 2.2.0, and continues the project’s adoption of Wayland. The enhancement of Wayland support has been continued, especially in LXQt Panel, whose Desktop Switcher is now enabled for Labwc, Niri, …. It is also equipped with a backend specifically for Wayfire. In addition, the Custom Command plugin is made more flexible, regardless of Wayland and X11. ↫ LXQt 2.3.0 release announcement T … ⌘ Read more

GTK Adds “Reduced Motion” Accessibility Option To Follow macOS, Windows & Others
In addition to GNOME’s Mutter compositor removing its X11 back-end support to focus exclusively on Wayland while keeping around XWayland client support, another notable GNOME change this week was the GTK toolkit adding a “reduced motion” accessibility option… ⌘ Read more

LXQt 2.3 Released With Improved Wayland Support
LXQt 2.3 is out today as the newest release of this lightwight, Qt-based desktop environment… ⌘ Read more

Java’s Swing is allegedly in “maintenance mode”, so I doubt it’s a good idea to use it for new programs. For example, I very much doubt that it will ever support Wayland.

The replacement is supposed to be JavaFX, but that’s not included in JREs – anymore! It used to be, now it’s not, even though it’s well over 15 years old now.

This whole thing (“Java GUIs”) appears to have stagnated a lot. Probably because everything is web stuff these days …

https://www.oracle.com/java/technologies/javafx/faq-javafx.html#6

There are no really good GUI toolkits for Linux, are there?

They’re either slow (like GTK4, Qt6), don’t support Wayland (like Tk), and/or unmaintained (like GTK2 and many others).

Ariadne explains some of the reasons behind this “Wayback” thingy (rootful X11 on Wayland):

• https://social.treehouse.systems/@ariadne/115147291885663574
  
• https://social.treehouse.systems/@ariadne/115147331909980717
  

They should put this in a FAQ on their website or something. The whole endeavor makes more sense when you look at it like this.

Certainly explains why in some parts of the interwebs I’ve noticed RWNJs suddenly hating on anything Wayland and pushing XLibre.

Wild when display servers become political battlegrounds.

In 1996, they came up with the X11 “SECURITY” extension:

https://www.reddit.com/r/linux/comments/4w548u/what_is_up_with_the_x11_security_extension/

This is what could have (eventually) solved the security issues that we’re currently seeing with X11. Those issues are cited as one of the reasons for switching to Wayland.

That extension never took off. The person on reddit wonders why – I think it’s simple: Containers and sandboxes weren’t a thing in 1996. It hardly mattered if X11 was “insecure”. If you could run an X11 client, you probably already had access to the machine and could just do all kinds of other nasty things.

Today, sandboxing is a thing. Today, this matters.

I’ve heard so many times that “X11 is beyond fixable, it’s hopeless.” I don’t believe that. I believe that these problems are solveable with X11 and some devs have said “yeah, we could have kept working on it”. It’s that people don’t want to do it:

Why not extend the X server?

Because for the first time we have a realistic chance of not having to do that.

https://wayland.freedesktop.org/faq.html

I’m not in a position to judge the devs. Maybe the X.Org code really is so bad that you want to run away, screaming in horror. I don’t know.

But all this was a choice. I don’t buy the argument that we never would have gotten rid of things like core fonts.

All the toolkits and programs had to be ported to Wayland. A huge, still unfinished effort. If that was an acceptable thing to do, then it would have been acceptable to make an “X12” that keeps all the good things about X11, remains compatible where feasible, eliminates the problems, and requires some clients to be adjusted. (You could have still made “X11X12” like “XWayland” for actual legacy programs.)

I wasn’t really aware until recently that programs can’t choose their own window’s position on Wayland. This is very weird to me, because this was not an issue on X11 to begin with: X11 programs can request a certain position and size, but the X11 WM ultimately decides if that request is being honored or not. And users can configure that.

But apparently, this whole thing is a heated debate in the Wayland world. 🤔

“Wayland Will Never Be Ready For Every X.Org User”

https://youtu.be/yURfsJDOw1E

@lyse@lyse.isobeef.org Oh, huh, maybe it was just my GNOME 2 themes back then that didn’t show the icon. 🤔

I like the looks of your window manager. That’s using Wayland, right?

Oh, no. It’s still X11. All my recent Wayland comments resulted from me trying to switch, but I think it’s still too early. Being unable to use QEMU (because it can’t capture the mouse pointer) is a pretty big blocker for me. This is completely broken, it just happens to be unnoticeable with modern guest OSes, so it’s probably not a priority for devs.

(Not to mention that I would have to fork and substantially extend dwl in order to “replicate” my X11 WM. And then, after having done that, I’d have to follow upstream Wayland development, for which I don’t have the resources. Things would need to slow down before I can do that.)

all that wasted space of the windows not making use of the full screen!!!1

Heh. I’ve been using tiling WMs for ~15 years now, so it’s actually kind of refreshing to see something different for a change. 😅

Probably close to the older Windowses.

That particular theme is a ripoff of OS/2 Warp 3: https://movq.de/v/6c2a948882/s.png 😅

We ran some similar brownish color scheme (don’t recall its name) on Win95 or Win98

Oh god. Yeah, I wasn’t a fan of those, either. 🥴

@movq@www.uninformativ.de According to this screenshot, KDE still shows good old application icons: https://upload.wikimedia.org/wikipedia/commons/9/94/KDE_Plasma_5.21_Breeze_Twilight_screenshot.png

And GNOME used to have them, too: https://upload.wikimedia.org/wikipedia/commons/9/9f/Gnome-2-22_%284%29.png

I like the looks of your window manager. That’s using Wayland, right? The only thing on this screenshot to critique is all that wasted space of the windows not making use of the full screen!!!1 At least the file browser. 8-)

This drives me nuts when my workmates share their screens. I really don’t get it how people can work like that. You can’t even read the whole line in the IDE or log viewer with all the expanded side bars. And then there’s 200 pixels on the left and another 300 pixels on the right where the desktop wallpaper shows. Gnaa! There’s the other extreme end when somebody shares their ultra wide screen and I just have a “regularish” 16:10 monitor and don’t see shit, because it’s resized way too tiny to fit my width. Good times. :-D

Sorry for going off on a tangent here. :-) Back to your WM: It has the right mix of being subtle and still similar to motif. Probably close to the older Windowses. My memory doesn’t serve me well, but I think they actually got it fairly good in my opinion. Your purple active window title looks killer. It just fits so well. This brown one (https://www.uninformativ.de/blog/postings/2025-07-22/0/leafpads.png) gives me also classic vibes. Awww. We ran some similar brownish color scheme (don’t recall its name) on Win95 or Win98 for some time on the family computer. I remember other people visting us not liking these colors. :-D

@movq@www.uninformativ.de Following all your Wayland endeavors, it doesn’t sound like a mature and usable thing to me yet.

Only figured this out yesterday:

pinentry, which is used to safely enter a password on Linux, has several frontends. There’s a GTK one, a Qt one, even an ncurses one, and so on.

GnuPG also uses pinentry. And you can configure your frontend of choice here in gpg-agent.conf.

But what happens when you don’t configure it? What’s the default?

Turns out, pinentry is a shellscript wrapper and it’s not even that long. Here it is in full:

#!/bin/bash

# Run user-defined and site-defined pre-exec hooks.
[[ -r "${XDG_CONFIG_HOME:-$HOME/.config}"/pinentry/preexec ]] && \
        . "${XDG_CONFIG_HOME:-$HOME/.config}"/pinentry/preexec
[[ -r /etc/pinentry/preexec ]] && . /etc/pinentry/preexec

# Guess preferred backend based on environment.
backends=(curses tty)
if [[ -n "$DISPLAY" || -n "$WAYLAND_DISPLAY" ]]; then
        case "$XDG_CURRENT_DESKTOP" in
        KDE|LXQT|LXQt)
                backends=(qt qt5 gnome3 gtk curses tty)
                ;;
        *)
                backends=(gnome3 gtk qt qt5 curses tty)
                ;;
        esac
fi

for backend in "${backends[@]}"
do
        lddout=$(ldd "/usr/bin/pinentry-$backend" 2>/dev/null) || continue
        [[ "$lddout" == *'not found'* ]] && continue
        exec "/usr/bin/pinentry-$backend" "$@"
done

exit 1

Preexec, okay, then some auto-detection to use a toolkit matching your desktop environment …

… and then it invokes ldd? To find out if all the required libraries are installed for the auto-detected frontend?

Oof. I was sitting here wondering why it would use pinentry-gtk on one machine and pinentry-gnome3 on another, when both machines had the exact same configs. Yeah, but different libraries were installed. One machine was missing gcr, which is needed for pinentry-gnome3, so that machine (and that one alone) spawned pinentry-gtk …

@movq@www.uninformativ.de LOL! No, I mean Wayland.

Since Wayland compositors handle input devices on a lower level than X11 window managers, every compositor has to figure out on their own what a “mouse wheel click” is:

• https://github.com/labwc/labwc/issues/1068
  
• https://github.com/labwc/labwc/pull/2933
  

(I think “Wayland compositor” is a misnomer. They are full-blown display servers that also do compositing, plus Wayland window management, plus X11 window management.)

One can only hope that all this eventually gets moved into the wlroots library. (I’m not sure if that’s possible, nor if people would want that.)

I give up.

Let’s try again next year. I don’t have the stamina. Death by a thousand paper cuts.

Can’t set up a meaningful taskbar: https://github.com/labwc/labwc/discussions/2924 (This is not a labwc issue, it’s a generic issue in the broader Wayland ecosystem.)

Thinking about doing “Wayland Wednesday”. Only use Wayland every Wednesday. Collect bugs, report bugs, fix bugs.

Something happened with the frame rate of terminal emulators lately. It looks like there’s a trend to run at a high framerate now? I’m not sure exactly. This can be seen in VTE-based terminals like my xiate or XTerm on Wayland. foot and st, on the other hand, are fine.

My shell prompt and cursor look like this:

$ █

When I keep Enter pressed, I expect to see several lines like so:

$
$
$
$
$
$
$ █

With the affected terminal emulators, the lines actually show up in the following sequence. First, we have the original line:

$ █

Pressing Enter yields this as the next frame:

$
█

And then eventually this:

$
$ █

In other words, you can see the cursor jumping around very quickly, all the time.

Another example: Vim actually shows which key you just pressed in the bottom right corner. Keeping j pressed to scroll through a file means I get to see a j flashing rapidly now.

(I have no idea yet, why exactly XTerm in X11 is fine but flickering in Wayland.)

The WM_CLASS Property is used on X11 to assign rules to certain windows, e.g. “this is a GIMP window, it should appear on workspace number 16.” It consists of two fields, name and class.

Wayland (or rather, the XDG shell protocol – core Wayland knows nothing about this) only has a single field called app_id.

When you run X11 programs under Wayland, you use XWayland, which is baked into most compositors. Then you have to deal with all three fields.

Some compositors map name to app_id, others map class to app_id, and even others directly expose the original name and class.

Apparently, there is no consensus.

… but you can’t set SDL_VIDEODRIVER=wayland globally, because that breaks Wine again …

… okay, the SDL backend works if you also set SDL_VIDEODRIVER=wayland.

@lyse@lyse.isobeef.org dmenu is a great example.

There have been several attempts at porting dmenu from X11 to Wayland. Well, not exactly “porting” it, more like rewriting it from scratch. Turns out: It’s not that easy.

dmenu is super fast and reliable. None of the Wayland rewrites are (at least none of the popular ones that I know of). They are either bloated and/or slow.

It takes a lot of discipline and restraint to write simple software and not blow up the codebase. This is much harder than people think. It’s a form of art, really.

QEMU on Wayland unusable, because it can’t grab the mouse … I’ll add it to my TODO list and investigate/report it eventually.

Someone did a thing:

https://social.treehouse.systems/@ariadne/114763322251054485

I’ve been silently wondering all the time if this was possible, but never investigated: Keep doing X11 but use Wayland as a backend.

This uses XWayland’s “rootful” mode, which basically just gives you a normal Wayland window with all the X11 stuff happening inside of it:

https://www.phoronix.com/news/XWayland-Rootful-Useful

In other words, put such a window in fullscreen and you (more or less) have good old X11 running in a Wayland window.

(For me, personally, this won’t be the way forward. But it’s a very interesting project.)