Tag: linux

Wayland, finally.

I’ve been watching the Wayland development from afar for a couple of years now, probably since 2014. But whenever I gave it a try, after less than 10 minutes something was so obviously broken that I immediately went back to X11.

Until yesterday, when I decided to give it another try. The trigger was, that KDE/Plasma felt sluggish on my machine. Even though it has decent specs (12 core Ryzen, Nvidia 4060 Ti, fast NVMe), opening a simple application like Konsole takes 1.5+ seconds. Even clicking the start menu button has a noticeable delay (~300-500ms). On X11 that is.

After rebuilding a bunch of packages (because I had to toggle the ‘wayland’ USE flag on, which had previously been off in my Gentoo installation), I chose the “Plasma (Wayland)” item in the SDDM dropdown and logged in. To my surprise KDE/Plasma instantly felt much better. No more delays, very smooth animations, etc.

IMO there must be serious bugs in Qt or KDE to have such bad performance on X11 nowadays. Using a simple Window Manager (Fluxbox) I didn’t feel any lags on X11. Even launching Konsole or other KDE apps from an xterm is snappy. But I don’t have the time and energy to do serious profiling, and I also really want to use KDE/Plasma.

So I’m happy that I didn’t find any issues with Wayland in the hours since. For a few minutes I thought screen recording was broken, but then it turned out that I just had to enable the ‘screencast’ USE flag and do a few rebuilds.

Will have to spend some time learning all the underlying concepts and new terms – but that doesn’t prevent me from using Wayland.

I’ll post updates here if / when I encounter issues.

Update (2025-01-05)

Today I wanted to write in German for the first time, and noticed that my .Xmodmap keyboard remapping for Umlauts no longer works. That was already problematic in X11 for a while, but it was a good solution that I’d been using for many years (and even “ported” to Windows – see here – when I had to use Windows at work).

So now I had to figure out something new. A guy in the always helpful German #gentoo-de@libera.chat IRC channel told me about the “EurKEY” keyboard layout – “The Layout for Europeans, Coders and Translators” – covers pretty much all European languages with one layout. Love it. And they took the exact same approach that I did: on an English keyboard, use a modifier key and when it’s pressed, “a” becomes “ä”, “o” becomes “ö” and so on. It comes out of the box in KDE, just had to choose it from the dropdown list!

The only issue with that is: they’re using the right ALT key as modifier, and I have nearly two decades worth of muscle memory using the Meta/Windows key as modifier. It would take a while to retrain myself, so I decided to instead remap the Meta/Windows key to the right ALT key. Works perfectly. Phew, problem solved.

Fix / workaround for non-linear volume control on Linux

Alright, it’s the time of the year where I find time to tinker a little. This time I wanted to find out why changing the volume didn’t feel “linear” for my beloved Teufel CONCEPT 8 2.1 sound system that’s connected to my PC via USB.

First of all I probably have to clarify what I mean by “didn’t feel linear”. I remember learning that human sound perception isn’t linear at all, so that’s probably not accurate. But what I mean here is that: When I slide the volume slider (or make discrete jumps via pactl set-sink-volume alsa_output.usb-NXP_SEMICONDUCTORS_Teufel_CONCEPT_8-00.analog-stereo 60%, for example), the loudest point is reached at already 40, maybe 45%, and after that it doesn’t get any louder. Or maybe it does? But if so, only marginally, and definitely not at the rate it does left of the 40% mark.

So I did some googling, but that turned up nothing specific to these speakers. And also nothing much helpful in general. I suspected some kind of quirk that nobody bothered adding a workaround for in the kernel so far. So I dove into the Linux kernel sources and tried a bunch of changes in sound/usb/mixer_quirks.c – e.g. setting cval->dbMin to different values for the USB ID of the Teufel CONCEPT 8, but also played around with cval->max as well as cval->res. It was rather tedious, because after every change I had to reboot, lacking the knowledge on how to test the changes “on the fly”. While I did observe changes to how the volume changed – e.g. the range where the volume changes fast shifted to the higher end – none of them yielded the results I wanted, i.e. “linear” volume change and no “dead zones” along the slider. So after a while I concluded that with my limited knowledge of the system’s inner workings, I could not understand how the numbers related to what I observed. So I wanted to learn more about the Linux USB audio subsystem, but gave up after a while because I figured that this would take up more time than I was willing to invest.

Just when I wanted to give up completely, I came across a bug report where someone recommended to choose the “Pro Audio” profile for the audio device instead of the “Analog Stereo Output” profile to get rid of this issue. And what can I say: works for me! The PipeWire FAQ states that using the “Pro Audio” profile “disables the hardware mixers, it only enables software volume/mute“. That’s probably what fixes the issue for me. I’d still love to understand why the issue exists in the first place though, and what the underlying layers are doing to mess up something seemingly simple as the volume slider. Maybe next Xmas holidays…?

See below a screenshot of the KDE System Settings / Sound. You can also use pavucontrol or its -qt variant to change the setting.