Alhoewel het bijna altijd goed gaat, kan het soms gebeuren dat tijdens gebruik in Linux bepaalde toetsenborden en/of trackpads niet werken.  

Opvallen vaak gaat het om nieuwe(re) laptops. Dit is echter wel uitlegbaar:

Linux drivers vs. Windows drivers

Linux gebruikt open-source drivers in de kernel, terwijl veel hardwarefabrikanten primair drivers schrijven voor het Windows platform. Deze drivers worden automatisch naar het Windows platform gepushed d.m.v. Windows Updates, waardoor de drivers vaak al in Windows aanwezig zijn voor de hardware is uitgebracht.  Deze drivers worden automatisch geïnstalleerd zodra Windows de hardware detecteert.

Wat fabrikanten niet altijd lijken te beseffen; Er zijn meer platformen dan Windows waar hun hardware op wordt gebruikt. Een groot nadeel, of probleem, is dat fabrikanten niet altijd hun hardware specificaties publiceren of alleen gesloten firmwares leveren.

Gevolg: Linux-ontwikkelaars moeten hardware reverse-engineeren of moeten werken met onvolledige documentatie. Hierdoor is de benodigde ondersteuning niet altijd direct aanwezig. Dat wordt in het volgend stukje duidelijk gemaakt:

Nieuwe hardware?  Dan meestal nieuwere kernel nodig

Nieuwe laptops gebruiken vaak: nieuwe I²C / HID-over-I²C controllers, nieuwe touchpad/keyboard chipsets, nieuwe ACPI-methodes.

Dat betekent vaak dat oudere kernels of huidige kernels de hardware niet herkennen of zien het als “unknown/onbekend\ HID device.

In welke symptomen uit zich dat?

Trackpad werkt niet, Keyboard werkt pas na login, Extern toetsenbord en externe USB-muis werkt wel.

Wat is dan de oplossing?

Normaliter hebben de Linux developers gewoon wat tijd nodig om de drivers en firmware te implementeren. Dat betekent voor de eindgebruiker: Upgrade kernel als deze er is, gebruik HWE kernel (Ubuntu). (De BCLD maakt gebruik van HWE kernels)

Samengevat: In Linux loopt de open source ondersteuning  achter op de nieuwe hardware

Gesloten firmware

 Veel input-devices zoals toetsenborden en trackpads hebben weliswaar open-source Linux drivers, maar soms gesloten firmwares, voor touchpad microcontrollers, embedded keyboards., laptop EC (Embedded Controllers) etc. Linux mag deze gesloten firmwares niet meeleveren, of alleen als aparte linux-firmware blobs en dat heeft ook gevolgen.

Gevolg zonder juiste firmware 

Device initialiseert niet, blijft in boot-mode of werkt wel in de BIOS maar niet in Linux

ACPI en BIOS: Hier gaat het vaak mis

Dit is waar (grub)parameters in beeld komen. ACPI is vaak ‘kapot’, alhoewel dat niet het goede woord is: Veel laptopfabrikanten testen ACPI alleen met Windows, hardcoded Windows-specifieke checks, gebruiken vendor-specifieke ACPI calls. Dit heeft gevolgen voor Linux en andere besturingssystemen. 
Linux krijgt dan: verkeerde IRQ’s, devices of onderdelen in sleep state, verkeerde power management cycles worden toegepast.
acpi_osi= is een parameter die vaak toegepast kan worden. Niet alleen voor het toetsenbord/touchpad deel maar zeker ook voor andere devices waarbij BIOS kijkt of controleert welke Windows versie er wordt gebruikt

acpi_osi="Windows 2020" of acpi_osi=Windows

Met deze parameter lieg Linux liegt tegen de firmware: Ik ben Windows en geef me de instructies.

De volgende Grub parameters vertellen om de foutieve ACPI-informatie te negeren of om  legacy keyboard controllers te forceren. 

acpi=off

i8042.nomux

i8042.reset

i8042.nopnp

Dit is geen bug in Linux, maar slecht geoptimaliseerde firmware.

HID-over-I²C en speciale touchpads

Moderne laptops gebruiken I²C i.p.v. PS/2, HID-over-I²C protocollen, vendor-extensies zoals Elan, Synaptics, Goodix.

De problemen die hiermee kunnen ontstaan:

Dit zijn niet-standaard implementaties die vaak vendor quirks nodig hebben en timing issues hebben bij boot. Dit resulteert in toetsenborden/trackpads die meestal niets doen in Linux of soms spontaan (deels) werken en een volgend moment niets doen.

Pas na kernel patches, device-specifeke quirks en maanden testen werkt het (stabiel).

Wat open source only in de praktijk echt betekent

Er zijn drie niveaus die vaak door elkaar lopen:

1. Kernel driver

2. Firmware blobs

3. ACPI/UEFI gedrag

1: Kernel drivers leveren meestal geen probleem. Is er een driver nodig? Grote kans dat deze al in de kernel aanwezig is of anders met een kernel-update.

2: Firmware blobs? Kan een groot probleem zijn voor de werking. Vaak herkent de kernel (driver) het apparaat wel (dit zie je vaak in een logging; de driver herkent letterlijk welk type device het is) maar de firmware die noodzakelijk is om te praten (met bijvoorbeeld de , is (nog) niet aanwezig. Dit komt doordat firmware wel vaak als closed source deels in de hardware aanwezig is maar Linux deze closed source firmware niet zomaar mag leveren. Deze firmwares moeten vaak reverse-enegineered worden door de Linux ontwikkelaars en dat heeft tijd nodig. Zo kan het zijn dat er tussen de driver die het apparaat al wel herkent en de daadwerkelijke (open source) firmware blob ruim 6 maand verschil zit.

Het kan zijn dat de firmware in Linux alleen communiceert met de closed source firmware (dan is het geen exacte kopie) maar de firmware ‘weet’ dan dat als packet X gestuurd wordt naar de closed source firmware, de open source firmware Y uitstuurt als response. Daarmee kan er een werkende basis worden gemaakt.

Maar soms is het zelfs nodig om de closed source firmware te vervangen tijdens een cycle van het OS.
Dat is dan niet dat de op het ROM aanwezige closed source firmware wordt vervangen door de open source variant, dus dat deze in ROM wordt gezet, maar de closed source versie wordt tijdelijk overschreven. Met tijdelijk bedoelen we tijdens de cycle/sessie van het Linux OS. Wordt de machine uitgezet en wordt Windows gestart, dan is de open source variant weer verdwenen en maakt de hardware gewoon weer gebruik van de closed source versie. Dit wordt dan een reborn sessie genoemd.

3: ACPI/UEFI gedrag kan niet zomaar worden opgelost. Zoals al eerder genoemd: Veel laptopfabrikanten testen ACPI alleen met Windows, gebruiken hardcoded Windows-specifieke checks en gebruiken vendor-specifieke ACPI calls die wel in Windows worden gestopt.

Resultaat kan dus zijn dat in geval van ACPI/UEFI  gedrag sommige problemen alleen kunnen worden aangepast door middel van Grub parameters.

Conclusie:

Maakt u gebruik van zeer recente hardware waarvan het toetsenbord/trackpad het niet doet? Dan is de kans aanwezig dat de ondersteuning hiervan nog niet aanwezig is.
Soms is het een kwestie van een driver die toegevoegd wordt in een nieuwere kernel en kan er gebruikt gemaakt worden van een reeds aanwezig open source firmware.

Maakt de hardware echter gebruik van closed source firmware waarvan de specs niet zijn gedeeld, dan geldt dat hier tijd overheen gaat voor de firmware reverse-engineered is. Dit kan een half jaar of langer duren.

nb: Als er exotische hardware wordt gebruikt of hardware wat door een fabrikant is aangepast met dito firmware maar de hardware-oplage is laag, dan kan het zelfs voor de Linux ontwikkelaars niet interessant zijn.