Dev-Thoughts: Nicht ganz auf Linie - Teil 2 - TUXEDO Computers

  ACHTUNG: Zur Nutzung unseres Shops müssen Sie zwingend JavaScript aktivieren und Script-Blocker deaktivieren!  
Vielen Dank für Ihr Verständnis!

Dev-Thoughts: Nicht ganz auf Linie
Teil 2

Oder: Gegen Mottenlöcher - der gepatchte TUXEDO-Kernel

... weil Motten sind ja „Bugs“ und Patches sind Flecken, also ... äh ja, der Witz funktioniert nur so semi. Um so besser funktioniert der durch die WebFAI auf allen Geräten installierte TUXEDO-Linux-Kernel! (Was für eine Überleitung. Ich will einen Tusch!)

Im ersten Teil habe ich beschrieben, was Mainline ist und warum wir davon abweichen. Aber das Wie hatte ich noch nicht beschrieben, weil der Text schon recht lang war. Genau da möchte ich jetzt anknüpfen, angefangen mit dem Herzstück einer Linux Installation: dem namensgebenden Linux-Kernel. Vorneweg: Ubuntu benutzt selbst nicht den 1-zu-1 Mainline-Kernel von Linus Torvalds, sondern einen eigenen Fork, in den aber immer wieder auch Updates des Mainline-Kernels übernommen werden. Da TUXEDO OS auf Ubuntu aufbaut, baut auch der TUXEDO-Linux-Kernel auf dem Ubuntu-Linux-Kernel-Fork auf. In diesem Fall heißt das, dass wir alle Updates des Ubuntu-Kernels übernehmen und allgemein versuchen, so nah wie möglich an der Vorlage zu bleiben. Dementsprechend kann ich hier auch in relativ kurz alle Änderungen auflisten.

1.) Repariere nicht-funktionale Thunderbolt-Ports auf dem XUX7 - Gen 13 (x86/resource: Do not exclude regions that are marked as MMIO in EFI memmap - Mika Westerberg)

Der Mainline- und der Ubuntu-Kernel haben einen Bug, der verhindert, dass der Thunderbolt-Controller das XUX7 - Gen 13 richtig initialisiert wird. Die gute Nachricht ist, dass wir einen Patch finden konnten, der diesen Bug behebt (nicht von uns geschrieben). Dieser hängt auf Mainline aber seit längerer Zeit im Testing fest. Auf TUXEDO-Geräten haben wir ihn deshalb kurzerhand selber getestet und keine Probleme festgestellt.

2.) Reduziere die Bootzeit des XUX7 - Gen13 (thunderbolt/icm: Make driver ready timeout configurable)

Direkt noch mal das XUX7 Gen - 13, und der Thunderbolt-Controller. Der Nachteil von Bleeding-Edge-Hardware (in diesem Fall ein frühes Thunderbolt 4 Gerät) ist die eine oder andere Kinderkrankheit. Diesmal initialisiert der Kernel die Firmware des Controllers und wartet dann darauf, dass dieser sich meldet, wenn er bereit ist. Nur leider tut er das nicht. Bereit ist er dennoch nach kurzer Zeit. Nach 80 Sekunden gibt der Kernel schließlich auf eine Antwort zu erfragen und macht weiter. Das ist natürlich viel zu viel Zeit, die verstreicht. Also war unsere Lösung, diese 80 Sekunden einstellbar zu machen. Am Ende haben wir uns für immer noch sehr konservative 20 Sekunden entschieden, die per Boot-Parameter von Tomte gesetzt werden, aber dazu im nächsten Teil mehr.

3.) Mache Panel Self Refresh (PSR) Version explizit wählbar (drm/i915/display: Add parameter to disable PSR 2)

Wenn man eine Internetseite liest oder ein Textdokument bearbeitet, verändert sich das Angezeigte oft sekunden- oder sogar minutenlang nicht. Also warum sollte die Grafikkarte Strom verbrauchen, um erneut das exakt gleiche Bild 60 Mal oder noch häufiger in der Sekunde zum Bildschirm zu schicken? Dass sich die Grafikkarte schlafen legt, bis wirklich etwas passiert – dafür ist der PSR zuständig. Den gibt es aber in zwei Versionen. Und die neuere von beiden im Linux-Kernel ist noch recht fehleranfällig. Trotzdem wird die neuere Version beim InfinityBook Pro 14 - Gen 6 automatisch ausgewählt. Standardmäßig erlauben der Mainline und der Ubuntu-Kernel nur die PSR ganz abzuschalten, aber das schließt auch PSR 1 ein, welcher aber tadellos funktioniert. Also bis PSR 2 im Mainline-Kernel Zeit hatte zu reifen, haben wir uns die Möglichkeit eingebaut, auf die alte Version zurückzufallen. Sicherungsnetz sozusagen.

4.) Repariere Flackern bei Geräten mit Intel XE GPU und externem Bildschirm (drm/i915: program wm blocks to at least blocks required per line - Ville Syrjälä)

Ein Bugfix der Geräte mit Intel XE GPU betrifft nur die Geräte, die Single-Channel-RAM haben. Wenn ein externer Bildschirm angeschlossen wird, fängt dieser und/oder der interne Bildschirm zu flackern an, weil ein Timeout falsch berechnet wird. Dieser Patch stammt auch nicht von uns, aber der ursprüngliche Autor hat ihn zu Mainline eingereicht. Es ist wieder nur eine Frage der Zeit, bis der Patch auch im Mainline-Kernel ankommt. Bis dato ist er bereits im TUXEDO-Linux-Kernel vorhanden.

5.) Verhindere Plopp-Geräusch, wenn Kopfhörer mit der Stellaris-/Pollaris-Serie verwendet werden (ALSA: hda/realtek: Add quirk for TongFang devices with pop noise)

Realtek-Audio-Chips sind sehr frei konfigurierbar und flexibel auf einem Mainboard einbaubar. In einer perfekten Welt würde im UEFI die korrekte Konfiguration stehen und vom Kernel geladen sowie angewandt werden. Leider ist der De-facto-Standard aber, dass diese Konfiguration im Realtek-Treiber für die meisten Geräte hartkodiert ist und so müssen auch wir auf diese Methode ausweichen. Meistens sind es nur Kleinigkeiten, die angepasst werden müssen. Bis vor Kurzen hatten wir dafür das Paket tuxedo-micfix1, aber mit dem eigenen Kernel können wir das auch direkt inkludieren, bis es im Mainline angekommen ist. Dieser Patch im Speziellen verhindert ein störendes Plopp-Geräusch, wenn man Kopfhörer verwendet, das nach ein paar Sekunden auftritt, nachdem man eine Audio- oder Videowiedergabe beendet hat.


Diese Liste ist natürlich nur eine Momentaufnahme, aber gibt hoffentlich auch in Zukunft einen guten Überblick über die Arten von Treiberanpassungen, die wir im Linux-Kernel vornehmen. Diese Anpassungen sind natürlich nur temporär, bis das Problem auch im Mainline auf die eine oder andere Art behoben ist. Wenn jemand eine tagesaktuelle Änderungsliste nachschlagen will, kann man diese in der Commit-History auf github finden. Alles, was zwischen den "UBUNTU: Ubuntu-..." und den "TUXEDO: Ubuntu-..." betitelten Commits steht, sind die von dem normalen Ubuntu-Kernel abweichenden Patches. In diesem Repository werden neue Änderungen, die nicht von uns stammen, mit einem git rebase eingefügt. Im Klartext heißt das, dass unsere Änderungen immer ganz oben sind, damit man sie leicht finden kann.

Ich hoffe, ich konnte ein wenig die Neugier befriedigen.

Viele Grüße aus dem Tux-Tower
euer Werner aus dem Dev-Team