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.)

@movq@www.uninformativ.de Holy crap, that’s really crazy!

Hahaha, you got me. When I read your first sentence I thought you were going to tell about your Wayland experience in comparison to X11. :-D

it’s been while since I’d stopped #window-manager hopping and just settled with #Herbstluftwm but I’m NGL, the River #Wayland compositor is starting to grow on me… I’m still not sure if it’s just me but something about it feels clean and snappy. The shortcuts in the vanilla/example configuration feel a bit clunky, but then again, it’s just me being used to the same old ones I keep adopting and replicating across WMs. I’ve got 0 energy for ricing so I’ll just roll with the vanilla config as is (maybe add in a short-cut for a launcher but that will be it).