Kompatibilitätsprobleme beseitigen und Linux besser machen
Funktioniert Ihre Hardware unter Linux nur mit Tricks korrekt? Sagen Sie das den Kernel-Entwicklern, damit die das Problem aus der Welt schaffen. So verbessern Sie Linux und helfen anderen Anwendern.
![Hardware-Macken mit Linux ausbügeln](https://heise.cloudimg.io/width/610/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/2/7/1/0/3/9/4/image-149157022619991-ac09a2a1c736ffaa.jpeg)
(Bild: c't)
- Thorsten Leemhuis
Im Internet kursieren tausende Tipps, die Hardware- und Kompatibilitätsprobleme mit Linux beseitigen. Wer sich selbst und anderen einen Gefallen tun will, informiert die Kernel-Entwickler über die nötige Sonderbehandlung, damit Linux die Tricks automatisch anwendet. Dadurch laufen zukünftige Linux-Distributionen auf der problematischen Hardware einfach und ohne Hand anzulegen. Das macht es einfacher für alle und Linux attraktiver.
Dieses Ziel lässt sich auf verschiedenen Wegen erreichen. Mit etwas Geduld und Spucke kann man etwa selbst dafür sorgen, dass der Kernel fortan alles richtig macht. Das gelingt manchmal sogar ohne sonderliche Programmierkenntnisse, wie ein von c't getestetes Fujitsu-Notebook zeigt: Dessen Touchpad funktioniert dieser Tage unter allen gängigen Linux-Distributionen problemlos, weil wir vor zwei Jahren die richtigen Leute über einen Workaround informiert haben.
Überarbeiteter c't-Artikel
Der nebenstehende Text ist eine überarbeitete und erweiterte Fassung des in ct 9/2017 erschienenen Artikels Kratz dein Jucken.
Das Problem: Sonderbehandlung für die Marotte einiger Lifebooks
Auslöser war ein c't-Test im Frühjahr 2017, bei dem wir Linux auf einigen mit Windows ausgelieferten Business-Notebooks ausprobiert haben. Dabei fiel auf: Bei einem Fujitsu Lifebook E547 funktionierte das Touchpad nicht unter den damals aktuellen Linux-Distributionen Fedora 25 und Ubuntu 16.10.
(Bild: c't)
Bei näherer Untersuchung fanden wir in den per dmesg
abrufbaren Kernel-Meldungen allerlei Warnungen des Touchpad-Treibers, der sich über ein Kommunikationsproblem beklagte. Eine Internet-Suche mit diesen Fehlermeldungen zeigte schnell: Die Macke trat auch schon bei älteren Lifebooks von Fujitsu auf. In einigen Suchergebnissen fand sich der Hinweis, das Touchpad funktioniere nach dem Absetzen des folgenden Kommandos:
echo 1 > /sys/devices/platform/i8042/serio2/crc_enabled
Das veranlasst den Kernel-Treiber dazu, den Datenaustausch mit dem Touchpad per CRC gegen Übertragungsfehler abzusichern. Der Befehl soll auch das von Elantech gefertigte Touchpad unseres E547 zur Mitarbeit bewegen.
(Bild: c't/Thorsten Leemhuis)
Damit hätte man es bewenden lassen können: Als Anwender kann man den Befehl schließlich einfach in die /etc/rc.d/rc.local eintragen, damit er bei jedem Systemstart ausgeführt wird, sodass alles immer automatisch funktioniert. Der Rest der Welt wäre dann aber weiter in dieses Problem gerannt – und man selbst hätte sich bei der nächsten Linux-Installation oder beim Start eines Live-Linux wie Desinfec't auch wieder damit herumplagen müssen.
Änderung für den Linux-Kernel per Copy&Paste
Wir haben daher tiefer gebohrt und stolperten in den Suchergebnissen über Quellcodeänderungen für Linux, durch die der Kernel die Spezialbehandlung bei älteren Lifebooks automatisch aktiviert. Daraufhin entwickelten wir selbst einen solchen Kernel-"Patch", damit Linux das auch beim Elantech-Touchpad des E547 macht.
Dazu brauchten wir keinerlei Kenntnisse der Programmiersprache C, in der das Gros des Kernels geschrieben ist: Wir mussten lediglich sieben für das Lifebook E544 zuständige Zeilen im Elantech-Treiber duplizieren und anschließend die darin enthaltene Modellbezeichnung auf die Werte ändern, die das Kommando dmidecode
im Bereich "System Information" in den Zeilen "Manufacturer" und "Product Name" liefert. Mit dem Programm diff
erzeugten wir dann aus den Änderungen einen Patch.
Selbst bei einer so trivialen Änderung kann allerdings schnell etwas schief gehen. Wir haben daher aus dem modifizierten Quellcode einen Kernel kompiliert und gestartet, um sicherzustellen, dass er die CRC-Kommunikation beim E547 tatsächlich automatisch aktiviert. Da das der Fall war, schickten wir den Patch zusammen mit einer kurzen Beschreibung der Sachlage an die Mailingliste linux-input@vger.kernel.org, über die sich die Entwickler der Eingabegerätetreiber von Linux austauschen.
Träger Start und kleinere Abstimmungsprobleme
Unserem ersten Patch fehlte allerdings eine Angabe in einem Code-Kommentar, die bei späteren Umbauten oder einer Konsolidierung des Ganzen später wichtig werden könnte. Eine diesbezügliche Rückfrage unsererseits, die nur nötig war, weil der Autor die Augen nicht recht aufgemacht hatte, wurde erst zwei Wochen später auf Nachhaken beantwortet.
Mit diesen Informationen reichten wir dann einen verbesserten Patch ein. Der ging im hektischen Alltag der Kernel-Entwickler unter – drei Wochen später hakten wird daher freundlich nach, woraufhin die Anpassung dann zügig akzeptiert wurde. Weil es eine überschaubare Änderung mit geringem Risikopotenzial war, wurde der Patch schon wenige Tage später zur Integration in den offiziellen Linux-Kernel eingereicht und kurz darauf dort integriert. Die veränderten Zeilen wurde dadurch Bestandteil der achten Vorabversion von Linux 4.11 und sind auch im derzeit aktuellen Linux-Kernel 5.2 noch zu finden.
(Bild: git.kernel.org – c't/Thorsten Leemhuis)
Durch die Integration für Linux 4.11 wäre das Problem mittelfristig aus der Welt verschwunden. Um den Prozess noch etwas zu beschleunigen, hatten wir den Patch aber mit de Kennzeichnung "Cc: stable@vger.kernel.org" gekennzeichnet, damit er auch in ältere Versionen zurückportiert würde. Das passierte automatisch, sodass die Änderung dann kurz darauf Bestandteil der Stable- und Longterm-Kernel 4.10.13, 4.9.25, 4.4.64, 3.18.51, 3.16.46 und 3.12.74 wurde.
Einige Distributionen haben diese oder nachfolgende Kernel-Versionen integriert; einige haben den Patch auch manuell aufgegriffen. Kernel mit den Änderungen wurden dann als reguläres Update an Anwender ausgeliefert. Zirka acht Wochen nach Einreichen des ersten Kernel-Patches begann das Problem so aus der Welt zu verschwinden: Die Macke war bei der Installation vielleicht noch vorhanden, verschwand aber mit der ersten Systemaktualisierung.
Mit den Installationsmedien klassisch gewarteter Linux-Distributionen wie Ubuntu trat das Problem noch einige Monate später auf, denn die werden nur in seltenen Ausnahmefällen aktualisiert. Aber: Rund ein halbes Jahr später erschien die neue Ubuntu-Version 17.10, in der das Touchpad dank des Kernel-Patches gleich bei der Installation funktionierte. Auch alle anderen heute gängigen Linux-Distributionen haben die Sonderbehandlung aufgegriffen, sodass das Touchpad trotz der Marotte einfach überall nutzbar ist.
Nur eine von tausenden Änderungen dieser Art
Unser Vorgehen war kein Einzelfall, wie die Änderungshistorie des Elantech-Touchpad-Treibers zeigt: Zwischen 2016 und Mitte 2019 gab es dort nur 29 Änderungen, von denen 11 irgendwelche Marotten bei verschiedener Notebooks beseitigen; nicht nur bei Lifebooks, sondern auch bei zwei Fujitsu-Celsius-Geräten und einigen Thinkpads von Lenovo. Manche dieser Anpassungen stammen von bekannten Kernel-Entwicklern; andere haben Leute beigesteuert, die wie wir über ein Problem gestolpert sind und sich dann aufgemacht haben, es ein für alle Mal aus der Welt zu schaffen.
Der Elantech-Touchpad-Treiber dient hier nur als Beispiel für das Vorgehen, denn auch andere Hardware braucht solche Sonderbehandlungen. Einen guten Eindruck davon bekommt man bei einem Blick auf die Sound-Treiber von Linux: Bei Linux 5.2 sind dort über 1250 Systeme explizit genannt, bei denen eine von Dutzenden Sonderbehandlungen angewendet wird, mit denen der Kernel bekannte Marotten abfangen kann. Besonders viele solcher "Quirks" behebt etwa der Treiber für HD-Audio-Codecs von Realtek. Die meisten dieser Eigenheiten betreffen Notebooks, All-in-One-Geräte und PCs großer, bekannter Hersteller.
Die Workarounds für Audio-Chips lassen sich über Modul-Parameter auch manuell aktivieren. Für Sound-Hardware gibt es aber enorm viele solcher Parameter, wie die längere Kernel-Dokumentation zu Audio- und HD-Audio-Treibern zeigt. Daher ist es sehr aufwendig, alle durchzuprobieren, um genau den zu finden, mit dem alle Sound-Features bei der eigenen Hardware korrekt arbeiten. Wer sich die Arbeit für sein System macht, tut daher gut daran, den Kernel-Entwicklern den richtigen mitzuteilen.
Linux kann viele Marotten ausbügeln
Die Liste mit Geräten, die Workarounds brauchen, wird mit jeder Kernel-Version länger. Bei Linux 5.2 stießen etwa jüngst Einträge hinzu, um Probleme mit Kopfhörern des System76 Gazelle, dem Mikrofon des Lenovo B50-70 oder dem Frontmikrofonanschluss des Lenovo M710q aus der Welt zu schaffen. Das sind nur drei von vielen Beispielen. Darüber hinaus hat etwa noch ein Mitarbeiter des bei Augsburg ansässigen Unternehmens Tuxedo einen Patch beigesteuert, um Probleme mit einigen Notebook-Barebones von Clevo auszuräumen.
Auch in anderen Bereichen gab es Änderungen für Linux 5.2, um Sonderbehandlungen automatisch zu aktivieren; etwa für die Hintergrundbeleuchtung des Sony VPCEH3U1E, den per USB angebundenen Gigabit-Ethernet-Adapter des Microsoft Surface Dock, die Seagate-Festplatte ST1000LM024, die Logitech-Tastatur MX5500, die vom selben Hersteller vertriebene Fernbedienung S510 oder die VR-Brillen von Valve, Sensics und OSVR. Und das ist nur die Spitze des Eisbergs, denn es gab noch mehr derartige Änderungen für Linux 5.2. Das ist normal, daher wächst die Liste mit Sonderbehandlungen alle neun oder zehn Wochen mit jeder neuen Kernel-Version weiter an.
Außerdem steuern Entwickler alle naselang auch Code bei, durch die der Kernel weitere Sonderbehandlungen anwenden kann. Bei der Entwicklung von Linux 5.2 lernte der Kernel etwa, Marotten einiger Qualcomm-Modems, dem USB-Audio-Interface Focusrite Scarlett Solo oder dem Tablet Aegex 10 (RU2) zu handhaben. Auch das sind nur einige Beispiele von Änderungen, durch die Hardware trotz Macken mit der neuen Linux-Version einfach funktioniert.
Simplere Herangehensweise
Das oben exemplarisch beschriebene Vorgehen zur Lösung bekannter Marotten dürfte nicht jedem so leichtfallen wie dem Autor, der die Linux-Entwicklung seit langem für das Kernel-Log der c't beobachtet. Beim Ausarbeiten und Einsenden von Änderungen lauern nämlich viele Stolperfallen.
So ist es schon nicht leicht herauszufinden, wo und wie sich eine Änderung implementieren lässt, die für eine Sonderbehandlung sorgt. Oft erfordert das eine ausführliche Internet-Recherche, eine Suche im Linux-Quellcode und ordentlich Hirnschmalz.
Besonders schwierig ist es auch, nach dem Entwickeln eines Patches die richtigen Ansprechpartner auf Seiten des Linux-Kernels zu finden. Auf den ersten Blick scheint es, als wäre bugzilla.kernel.org der passende Weg zur Kontaktaufnahme. Allerdings nutzen die wenigsten Kernel-Entwickler das Bug-Tracking-System, denn die meisten bevorzugen Mailinglisten. Die Maintainers-Datei der Kernel-Quellen kann helfen, die richtigen Ansprechpartner zu finden. Eine gute Anlaufstelle ist auch das in den Linux-Quellen enthaltene Skript get_maintainer.pl
. Manchmal führt auch schon eine Internet-Suche zum Erfolg, bei der man den Namen des betroffenen Treibers mit den Stichworten wie "Mailinglist" und "Patch" kombiniert.
Die Arbeit delegieren
Wem das alles zu kompliziert scheint, der meldet sein Hardware-Problem im Bug-Tracking-System seiner Linux-Distribution – idealerweise gleich mit einem Hinweis, welcher Workaround hilft. Wie bei den anderen Wegen ist auch hier allerdings Englisch gefragt, denn das ist nun mal die Lingua Franca der Open-Source-Welt.
Im Idealfall schreibt ein Entwickler des Distributors daraufhin selbst eine Änderung und integriert diese in den offiziellen Linux-Kernel, um das Problem anzugehen. Oftmals passiert aber nichts: Die Kernel-Maintainer der großen Distributionen bekommen oft Unmengen an Fehlerberichten und sind vielfach stark überlastet. Manche konzentrieren sich daher auf Probleme, die eine größere Zahl von Anwendern betreffen.
Ohne solche Rückmeldungen oder Patches gewöhnlicher Linux-Anwender geht es bei der Informationsbeschaffung zu Sonderbehandlungen für Hardware-Marotten aber nicht, schließlich kümmern sich nur wenige Hersteller um die Linux-Kompatibilität ihrer Hardware. Erschwert wird die Situation durch die schiere Menge an Hardware; so viel, dass kein Distributor oder Testlabor der Welt diese auf Linux-Kompatibilität prüfen kann.
Beklagenswert ist allerdings, dass Fujitsu die Lifebook-Marotte bei seinen Notebooks nicht selbst in der Hardware oder mit einem Kernel-Patch korrigiert: Die Macke ist schließlich schon jahrelang bekannt und wurde mehrfach von einem Modell an dessen Nachfolger vererbt. Daher war es nicht sonderlich überraschend, dass auch das E547 eine Sonderbehandlung brauchte. (thl)