Dev-Thoughts: Not quite in line - part 2 - TUXEDO Computers

  ATTENTION: To use our store you have to activate JavaScript and deactivate script blockers!  
Thank you for your understanding!

Dev-Thoughts: Not quite in line
part 2

Or: If you don't like moth holes: - the patched TUXEDO kernel

... because moths are "bugs" and patches are spots, so ... uh yes, the joke works only so so. The TUXEDO Linux kernel installed on all devices through the WebFAI works all the better though ! (What a transition…. I want a fanfare!).

In the first part of this article I described what mainline is and why we deviate from it. But I had not yet described the how, because the text was already quite long. That's where I want to pick up now, starting with the heart of a Linux installation: the namesake Linux kernel. First of all: Ubuntu itself does not use the 1-to-1 mainline kernel by Linus Torvalds, but its own fork, into which, however, updates of the mainline kernel are patched in again and again. Since TUXEDO OS is based on Ubuntu, the TUXEDO Linux kernel is also based on the Ubuntu Linux kernel fork. In this case, that means we adopt all updates to the Ubuntu kernel and generally try to stay as close to the template as possible. Accordingly, I can list all the changes here in relatively short order.

1) Fix non-functional Thunderbolt ports on the XUX7 - Gen 13 (x86/resource: Do not exclude regions that are marked as MMIO in EFI memmap - Mika Westerberg).

The mainline and Ubuntu kernels have a bug that prevents the Thunderbolt controller from properly initializing the XUX7 - Gen 13. The good news is that we were able to find a patch that fixes this bug (not written by us). However, this has been stuck in testing on Mainline for quite some time. On TUXEDO devices we tested it ourselves and found no problems.

2) Reduce the boot time of the XUX7 - Gen13 (thunderbolt/icm: Make driver ready timeout configurable).

Again the XUX7 Gen - 13, and the Thunderbolt controller. The downside of bleeding edge hardware (in this case, an early Thunderbolt 4 device) is one or two teething problems. This time, the kernel initializes the controller's firmware and then waits for it to report when it's ready. Unfortunately, it doesn't do that. Nevertheless, it is ready after a short time. After 80 seconds, the kernel finally gives up asking for a response and moves on. Of course, that's way too much time to waste. So our solution was to make those 80 seconds adjustable. In the end, we settled for a still very conservative 20 seconds, set by Tomte's boot parameter, but more on that in the next part.

3) Make Panel Self Refresh (PSR) version explicitly selectable (drm/i915/display: Add parameter to disable PSR 2).

When reading a web page or editing a text document, what is displayed often does not change for seconds or even minutes. So why should the graphics card consume power to send the exact same image to the screen again 60 times a second or even more? The PSR is responsible for the graphics card going to sleep until something really happens. But it is available in two versions. And the newer of the two is unfortunately still very bug-heavy in the Linux kernel. Nevertheless, the newer version is automatically selected on the InfinityBook Pro 14 - Gen 6. By default, the mainline and Ubuntu kernel only allow PSR to be turned off entirely, but that also includes PSR 1, which works flawlessly though. So until PSR 2 had time to mature in the mainline kernel, we built in the ability to fall back to the old version. Backup net, so to speak.

4) Fix flickering on devices with Intel XE GPU and external display (drm/i915: program wm blocks to at least blocks required per line - Ville Syrjälä).

A bugfix of devices with Intel XE GPU only affects devices that have single-channel RAM. When an external screen is connected, it and/or the internal screen starts flickering because a timeout is calculated incorrectly. This patch is not from us either, but the original author submitted it to Mainline. Again, it's only a matter of time until the patch arrives in the mainline kernel as well. So far it is already present in the TUXEDO Linux kernel.

5) Prevent "pop" noise when using headphones with Stellaris/Polaris series (ALSA: hda/realtek: Add quirk for TongFang devices with pop noise).

Realtek audio chips are very freely configurable and can be flexibly installed on a motherboard. In a perfect world, the correct configuration would be in the UEFI and loaded and applied by the kernel. Unfortunately, the de facto standard is that this configuration is hard-coded in the Realtek driver for most devices and so we have to resort to this method as well. Most of the time it's just small things that need to be adjusted. Until recently we had the tuxedo-micfix1 package for this, but with our own kernel we can include it directly until it arrives in mainline. This patch in particular prevents an annoying "popping" sound when using headphones that occurs after a few seconds after finishing audio or video playback.
 

This list is of course only a snapshot, but hopefully gives a good overview of the types of driver adjustments we make in the Linux kernel in the future. Of course, these adjustments are only temporary until the problem is also fixed in mainline in one way or another. If anyone wants to look up a daily updated change list, it can be found in the commit history on github. Everything between the "UBUNTU: Ubuntu-..." and the "TUXEDO: Ubuntu-..." titled commits are the patches that differ from the normal Ubuntu kernel. In this repository, new changes that are not from us are added with a git rebase. In plain language, this means that our changes are always at the top, so you can easily find them.

I hope I could satisfy a bit of your curiosity.

 

Many greetings from the Tux-Tower
Werner from the Dev-Team