Dev-Thoughts: Hintergrundinformationen zur neuen Tastaturbeleuchtungssteuerung - TUXEDO Computers

Hi, Werner hier.

Letztes Jahr hab ich hier in unserem TUXEDO-Blog über Mainlining und den Tuxedo-Kernel geschrieben, bin dann aber nie zum dritten Teil der Artikelserie gekommen: Ubuntu-Installation via WebFAI vs. einer ISO von ubuntu.com. Also mit Tusch für alle, die darauf gewartet haben… Sorry, auch heute nicht xD. Aber mit guten Gründen, es gab viel zu tun und einer davon war der komplette Rewrite unserer Tastaturbeleuchtungstreiber.

Viele APIs, viele Standards

Ich will ein wenig auf den technischen Hintergrund eingehen, warum der Treiber sich verhält wie er sich verhält und fange mit den Gegebenheiten an: Über die Geräte hinweg, die wir über die letzten Jahre verkauft haben, haben wir es mit insgesamt sieben unterschiedlichen Tastaturbeleuchtungs-Firmware-APIs in unterschiedlichen Versionen zu tun, die sich über vier von uns geschriebene Linux-Kernel-Module verteilen.

Neben den offensichtlichen Unterschieden, von zum Beispiel einfarbigen, mehrzonigen oder gar pro Taste individuell einstellbaren RGB-Beleuchtungen, gibt es bei bestimmten Tastaturmodellen auch weniger offensichtliche Unterschiede, wie etwa eine in 3, 5, 10 oder 256 Schritten regelbare Helligkeit.

In der Vergangenheit hatten diese vier Module “historisch bedingt” gar kein oder jeweils ein komplett eigenes Sysfs-Interface, um die Beleuchtung von Linux aus zu steuern. Daraus ergab sich der Grund für das Rewrite: Wenn wir ein einheitliches GUI haben, sollte auch die Backend-API an irgendeinem Punkt einheitlich sein.

Einheitliche Interfaces nötig

Um diese komplexe Situation aufzulösen, haben wir uns entschieden, das zu verwenden, was bereits im Kernel bereits standardisiert ist: /sys/class/leds. Bei den alten Sysfs-Einträgen galt es einen radikalen Schnitt zu machen und sie aus dem Treiber zu löschen.

Das Wichtigste in Kürze

Für unsere Tastaturen gibt es unter /sys/class/leds jetzt einen Eintrag white:kbd_backlight beziehungsweise ein oder mehrere rgb:kbd_backlight Einträge. Jeder davon besitzt die Attribute brightness (les- und schreibbar) für die aktuelle und max_brightness (nur lesbar) für die maximale Helligkeitsstufe.

Falls mehrere rgb:kbd_backlight-Einträge vorhanden sind (etwa für die Per-key-RGB-Tastaturen), wird das brightness-Attribut aktuell noch über alle Einträge hinweg synchron gehalten. Das ist nicht ganz in Spezifikation für das Interface, aber ein Workaround für KDE Plasma – Wenn man über die Plasma Energieeinstellungen die Tastaturbeleuchtung umstellt, wird aktuell noch nur ein Wert umgeschrieben.

Bei rgb:kbd_backlight-Einträgen haben wir zusätzlich das multi_intensity-Attribut eingeführt, das drei mit Leerzeichen getrennte Integer zwischen 0 und 255 annimmt, um den RGB-Wert der jeweiligen Tastaturzone/-taste einzustellen. Auf dem TUXEDO Aura 15 Gen2 zum Beispiel führt das Kommando…

echo 255 0 0 | sudo tee /sys/class/leds/rgb:kbd_backlight/multi_intensity

…zu einer rot beleuchteten Tastatur, ein…

echo 0 255 0 | sudo tee /sys/class/leds/rgb:kbd_backlight/multi_intensity

…zu einer grün beleuchteten Tastatur und ein…

echo 0 0 255 | sudo tee /sys/class/leds/rgb:kbd_backlight/multi_intensity

…zu einem blau beleuchteten Keyboard.

Bei den Per-Key-Tastaturen geht die Nummerierung der rgb:kbd_backlight-Einträge je nach Modell von oben links nach unten rechts oder von unten links nach oben rechts und es gibt mehr Einträge als tatsächlich Tasten vorhanden sind.

Das liegt zum einem daran, dass manche Tasten mehrere LEDs besitzen (etwa die Eingabetaste), zum anderen, dass der LED-Controller ein paar Platzhalter für andere aktuelle oder zukünftige Keyboard-Layouts freihält, die bei unseren Modellen mit gar keiner LED verbunden sind.

Da der Treiber aber nicht wissen kann, welche das sind, kann er diese auch nicht herausfiltern. In der Zukunft wird dieses Mapping vermutlich modellspezifisch auf Ebene des TUXEDO Control Centers passieren.

Fragen an die Entwickler

Vor dem Update konnte ich mit FN+Leertaste durch drei Helligkeitsstufen schalten, jetzt nur noch durch zwei?

Das liegt daran, dass vor dem Update das Verhalten der Tastenkombination FN+Leertaste direkt von der Firmware oder vom Treiber implementiert war. Jetzt wird das Verhalten des “Tastaturbeleuchtung umschalten”-Shortcuts von der jeweiligen Desktopumgebung implementiert. KDE Plasma und Gnome zum Beispiel schalten diese nur noch an und aus, deshalb gibt es jetzt nur noch zwei Stufen.

Die Tastenkombinationen FN+Leertaste oder FN +× (das Multiplikationszeichen auf dem Nummernblock) gehen gar nicht mehr?

Manche Desktopumgebungen implementieren den “Tastaturbeleuchtung umschalten”-Shortcut gar nicht. Hier ist eventuell eine extra Konfiguration oder ein extra Skript notwendig.

Mein Script oder Tool, das ich bis jetzt zum Umstellen der Tastaturbeleuchtung verwendet habe, funktioniert nicht mehr?

Zu erwarten, da wir – wie oben beschrieben – ein komplett neues Interface implementiert und das alte herausgenommen haben. Das Skript beziehungsweise Tool muss auf das neue Interface umgeschrieben werden.

Das TUXEDO Control Center sagt, dass meine Tastatur (noch) nicht unterstützt wird

Das kann zwei Ursachen haben: Das Gerät läuft noch auf Basis eines Ubuntu 20.04 und hat somit noch den tuxedo-keyboard-Treiber in Version 3.1.x anstelle des benötigten 3.2.0 (oder neuer) installiert. Wir haben den 3.2.0-Treiber bewusst nicht in die Paketquellen von 20.04 aufgenommen, da diese Systeme theoretisch noch auf dem Linux-Kernel 5.4 laufen könnten, der nicht kompatibel zum neuen Treiber ist.

Wenn man nur den Linux-Kernel 5.15 installiert hat, kann man händisch das neuere Paket aus unserem Repository installieren. Für jeden, der aber allgemein Wert auf die neusten Funktionen legt, empfehle ich aber auf ein 22.04 basiertes Ubuntu beziehungsweise das aktuelle 22.04-basierte Tuxedo OS upzugraden. Die auf 20.04 basierten Systeme erhalten noch bis 2025 Sicherheitsupdates, aber zunehmend keine neuen Funktionen mehr.

Die zweite Ursache könnte sein, dass die Firmware des Geräts keine Möglichkeit bietet, die Beleuchtung durch das Betriebssystem zu steuern oder es hat eine API, die nur bei diesem einen älteren Model vorkommt. Ich kann in diesem Fall leider nicht versprechen, dass die GUI-Steuerung (zeitnah) nachgeliefert wird, aber die Keyboard-Shortcuts werden weiterhin wie gewohnt funktionieren.

Das Windows Control Center hat mehr Einstellungsmöglichkeiten als das das TUXEDO Control Center für mein Gerät?

Wir arbeiten daran nach und nach alle Funktionen und ein paar mehr einzubauen. Wir sind ja gerade erst am Anfang vom TUXEDO Control Center 2.

Mir ist Bug XY aufgefallen.

Im Rahmen unserer Entwicklung testen wir viel, aber bei so einem Rewrite übersieht man immer irgendwas. Keine Sorge, wir sammeln alle Bugs, die uns auf Github berichtet werden und schauen, dass wir sie zeitnah beheben.

• tuxedo-keyboard auf Github
• tuxedo-control-center auf Github

Wichtig dabei ist: Um welches Gerät in welcher Konfiguration handelt es sich? Welche Distribution in welcher Version? Welcher Kernel in welcher Version? Welche Desktopumgebung in welcher Version? Welche Version der Kernelmodule tuxedo-control-center, tuxedo-keyboard und tuxedo-keyboard-ite ist installiert? Welche Versionen von BIOS und EC-Firmware?

Mit diesen Informationen können wir das entsprechende Gerät aus dem Archivregal nehmen und versuchen den Bug nachzustellen, was in der Regel der erste Schritt beim Bugfixen ist.

Viele Grüße aus dem TUXEDO-Tower in Augsburg!