In neuen PCs zicken ausgerechnet Webcams herum, die im Kontext von Homeoffice massiv an Verbreitung gewonnen haben. Schuld ist die Linux-Ignoranz des Chipgiganten Intel.

Linux und Hardware, das war nicht unbedingt immer ein entspanntes Thema. Noch vor 20 Jahren ging man nicht mal eben zum Computerhändler des Vertrauens und kaufte ein beliebiges Gerät. Wer sicherstellen wollte, dass die Neuerwerbung mit dem freien Betriebssystem gut zusammenspielen würde, hatte oft Wochen sehr ausführlicher Recherchen vor sich: Welche Chipsätze wurden unterstützt? Funktionierten auf mobilen Geräten so elementare Funktionen wie Suspend-to-RAM? Wie stand es mit Modems oder Sound- und mit WLAN-Karten?

Wer nicht sorgfältig prüfte, bevor er sich lange band, stand im schlimmsten Fall mit Hardware da, die mit Linux praktisch nicht zum Laufen zu bekommen war. Erinnert sei an die berüchtigten Winmodems (Abbildung 1) oder an Drucker, die ohne binäre Treiber des Herstellers tatenlos blieben, die es für Linux aber nicht gab. Wer nach einem Beweis dafür sucht, dass früher eben nicht alles besser war, findet im Thema Linux und Hardware eine ergiebige Quelle.

Abbildung 1: Soft- oder Winmodems galten in den frühen Jahren der Linux-Entwicklung als Ärgernis, weil sie ohne die passenden Treiber nicht funktionierten. Über 20 Jahre später vollzieht Intel denselben Stunt mit Webcams. Quelle: Wikipedia, Douglas Whitaker, CC BY-SA 2.5

Zum Glück ändern sich die Zeiten. Nicht zuletzt dank Intels seinerzeitiger Centrino-Initiative verschmolzen die einzelnen Komponenten von Computern immer mehr zu einer logischen Einheit. Soundkarten waren irgendwann Standardbauteile und ließen sich mit entsprechenden Treibern unter Linux nutzen. Grafikchipsätze, ebenfalls ein ewiges Ärgernis, kommen heute mit Support von Nvidia oder AMD daher. Wer keine Games zockt, begnügt sich mit den integrierten Chipsätzen von AMDs und Intels CPUs, die unter Linux ebenfalls problemlos funktionieren.

Modems braucht heute kaum noch jemand, LTE- oder 5G-Modems lassen sich meist über eine emulierte serielle Schnittstelle direkt mit AT-Befehlen füttern. Drucker haben meist einen eigenen Netzwerkanschluss und bieten Unterstützung für KPL/PD oder Postscript. Selbst für via USB lokal angeschlossene Geräte existiert heute eine breite Treiberunterstützung. In Sachen Suspend-to-RAM hat die Linux-Gemeinde selbst ordentlich Hand angelegt und geliefert. Auf den meisten Geräten der großen Hersteller wie Dell oder Lenovo stellt auch die Nutzung solcher Funktionen mittlerweile kein Problem mehr dar. Alles gut, könnte man also im Kontext von Linux und moderner Hardware glauben.

Da wirkt es wie ein Anachronismus, dass Linux-Fans sich 2023 auf dem Desktop wieder mit kaputten Treibern, selbst zu kompilierenden Kernel-Modulen und eigenartigen, in Software gegossenen Brückenkonstruktionen befassen müssen. Auslöser dafür sind Hardwarekomponenten, die hinsichtlich mangelnder Unterstützung wohl kaum jemand auf dem Plan gehabt hätte: Webcams.

Die kleinen Internet-Kameras haben in den Corona-Jahren enorm an Relevanz gewonnen. Wer oft oder gar ausschließlich von zu Hause aus arbeitet, findet sich früher oder später in Online-Meetings wieder. Die lassen sich mit Webcams meist besser und angenehmer gestalten. Die dafür nötige Komponente allerdings lässt sich im Jahr 2023 unter Linux gerade auf neuerer Hardware nicht mehr problemlos nutzen. Was ist da los?

Der unbekannte Riese

Ihren Ursprung hat die ausgesprochen widrige Situation in einem Ereignis vor über 20 Jahren: der Gründung der Mobile Industry Processor Interface Alliance oder kurz MIPI. Das klassische Industriekonsortium wurde 2003 mit dem Ziel gegründet, Protokoll- und Schnittstellenstandards für das Zusammenspiel von Prozessoren und sogenannten Peripheriegeräten zu schaffen.

Was Prozessoren im engeren und datenverarbeitende Chipsätze im weiteren Sinne sind, dürfte jedem klar sein. Der Begriff der Peripheriegeräte ist da schon etwas weniger geläufig. Die meisten Anwender subsumieren darunter die klassische Computerperipherie, also Mäuse, Tastaturen, Drucker, Scanner und ähnliche Geräte. Das dürfte nicht zuletzt daran liegen, dass sich eben diese Geräte in den Prospekten und auf den Websites von Hardwarehändler stets in der Kategorie Peripheriegeräte finden.

Nach gängiger Definition zählen zur Peripherie aber auch Monitore und Anbauteile wie externe Soundkarten oder – und hier liegt der Hase im Pfeffer – Webcams. Eine ganze Weile hat MIPI nicht sonderlich viel Öffentlichkeits- und Medienwirksames zustande gebracht. Heute gehören dem Konsortium allerdings mehr als 300 Hersteller an, sodass MIPI definitiv zu einer Größe in der Industrie geworden ist.

Quasi zu den Hauptbetätigungsfeldern von MIPI gehört die Definition von Protokollen für den Austausch von Bildern und Tönen zwischen einem Host und dem Peripheriegerät, das die jeweiligen Daten aufzeichnet und anliefert. Die CSI-Protokolle gehören zu den am weitesten verbreiteten der MIPI Alliance. CSI steht für Camera Serial Interface und liegt aktuell in drei Versionen vor. Die meistgenutzte dürfte zweifellos die 2019 veröffentlichte letzte Revision von MIPI CSI-2 sein: Sie kommt in vielen MIPI-kompatiblen Kameras bis heute zum Einsatz.

Wodurch aber unterscheidet sich eine “normale” Webcam von einem MIPI-Gerät? Einfach ausgedrückt definiert CSI lediglich die Schnittstelle, die Kamera und Host nutzen, um Daten miteinander auszutauschen. Wie sämtliche Interface-Definitionen musste CSI im Lauf der Jahre dem Umstand Rechnung tragen, dass mehr Daten zu bewältigen waren – inzwischen sind oft 4k-Streams zu transportieren. Schon MIPI CSI-2 von 2019 unterstützt deutlich höhere Bandbreiten als das klassische USB 3.0 mit seinen realistischen 3,6 GByte/s Durchsatz. Doch in der nutzbaren Bandbreite liegt nicht der einzige Unterschied zwischen typischen Webcams alter Bauart und dem MIPI-System.

Der MIPI-Standard sieht explizit vor, die Sensoren der Kamera und die für die Bildauswertung zuständigen Komponenten nicht in derselben Baugruppe zu kombinieren. In MIPI-Setups fertigt die Kamera also mittels ihrer Sensoren rohe Ton- und Bilddaten an, die sie dann an den Host durchreicht. Der übernimmt die Hauptarbeit: Er errechnet daraus ein Bild samt Ton, das sich im Anschluss etwa für Videokonferenzen nutzen lässt.

Hier spielen gleich mehrere Faktoren eine wichtige Rolle. Einerseits ermöglicht das Entkoppeln von Sensor und Chip eine Vielzahl von Kombinationen, die sich an den jeweiligen Einsatzzweck anpassen lassen. In preiswerten Notebooks stecken ebenso kostengünstige Videoverarbeitungschips, Geräte der Mittelklasse verwenden billige Chips mit teuren Sensoren, und Edelhobel genießen das volle Programm – so die Theorie (Abbildung 2).

Abbildung 2: MIPI CSI-2 beschreibt ein Interface für die Kommunikation zwischen Peripheriegeräten und Host-Chips, sodass diese sich logisch voneinander trennen und beliebig kombinieren lassen. Quelle: NXP Semiconductors

Andererseits kann man in dieses Konstrukt auch spezielle Chips integrieren, die aus den eingehenden Videodaten nicht nur ein Bild für die Webcam zusammenbasteln, sondern es zum Beispiel KI-gestützt gleich auch verarbeiten. Die berühmten KI-Showcases, die die Zahl von Bienen in einem Bienenstock automatisch auf KI-Basis anhand einer Webcam errechnen, profitieren von der MIPI-Schnittstelle massiv: Hier bekommen sie die Daten in genau dem Rohformat, das sie unmittelbar weiterverarbeiten können, statt mit dem Pixelmatsch einer mittelklassigen Webcam herumzuhantieren.

Des Pudels Kern

So weit scheint im MIPI-Land also alles bestens zu laufen, doch der Schein trügt. Der Grund dafür, dass Linux-Anwender sich 2023 wieder mit Problemen bei der Unterstützung vermeintlicher Standardbauteile befassen müssen, sind die Bildverarbeitungschips der MIPI-Spezifikation. Das Protokoll CSI-2 selbst bereitet kaum Probleme: Der Linux-Kernel unterstützt es bereits seit geraumer Zeit und hat keinerlei Schwierigkeiten damit, den Datenaustausch zwischen Peripherie und MIPI-Chip zu gewährleisten (Abbildung 3).

Abbildung 3: Der Linux-Kernel kommt mit der CSI-2-Spezifikation durchaus zurecht und implementiert auch einen Transportpfad dafür. Der kommt sich aber mit den Intel-Treibern ins Gehege. Das Nachsehen hat der Anwender, der unfreiwillig zum Bastler wird.

Die Chips hingegen haben es in sich. Sie halten seit einiger Zeit Einzug in die aktuellen CPU-Spezifikationen von Intel und AMD. Exemplarisch herausgegriffen seien die CPU-Spezifikationen von Intels Serien “Tiger Lake” und “Alder Lake”: Hier ist der Chipsatz IPU6 ausdrücklich als mögliche Komponente der CPU vorgesehen, und zwar im Kontext einer MIPI-kompatiblen Kamera nach CSI-2-Standard. Die Krux dabei: Um den IPU6-Chip nutzen zu können, benötigt man proprietäre Firmware und obendrein einen speziellen Treiber.

Das Thema Firmware haut unter Linux heute eigentlich niemanden mehr aus den Schuhen; schließlich existieren etliche Treiber, die sich nur mit proprietärer Firmware nutzen lassen. Längst haben die Kernel-Entwickler wie auch die großen Distributoren Mittel und Wege gefunden, dieses Problem aus Anwendersicht mit sinnvollen Workarounds abzufedern. Bei IPU6 liegen die Dinge jedoch etwas anders.

Zwar stellt Intel einen Treiber für die Kameras bereit, doch der funktioniert mehr schlecht als recht. Für aktuelle Kernel kann man ihn nicht ohne Probleme bauen. Zudem ist er so verfasst, dass er sich auf absehbare Zeit nicht in den offiziellen Linux-Kernel integrieren lässt und mithin als Out-of-Tree-Entwicklung gelten muss. Kernel-Urgestein Greg Kroah-Hartman sah sich durch diesen Umstand sogar dazu veranlasst, Anwender explizit vor dem Kauf neuer Geräte mit Intels “Alder-Lake”-CPUs und MIPI-Webcams zu warnen [1]. Mit brauchbarem Support sei unter Linux in absehbarer Zeit kaum zu rechnen, betonte er.

Sieht man sich die Situation auf Lenovos aktuellem Flaggschiff X1 Carbon der zehnten Generation genauer an, wird das Ausmaß der Katastrophe schnell deutlich. Nach dem Booten eines aktuellen Desktop-Linux, etwa OpenSuse oder Fedora, steht die im Gerät verbaute Webcam schlicht nicht zur Verfügung. Sie taucht zwar in der Liste der integrierten Hardware auf, ein Treiber ist für sie jedoch nicht geladen. Entsprechend glänzt sie auch in Werkzeugen wie Google Meet durch Abwesenheit. Wer so eine Gurke vor sich stehen hat, kann an Videokonferenzen nur ohne Bild teilnehmen – im dritten Jahrzehnt des 21. Jahrhunderts eigentlich eine Farce.

Noch schlimmer: Ohne einen Compiler in die Hand zu nehmen, lässt sich das Debakel praktisch nicht bereinigen. Dabei gilt es gerade als eine der größten Errungenschaften der Linux-Community, in den letzten beiden Dekaden das Treibergebastel auch auf Consumer-Hardware praktisch überflüssig gemacht zu haben. Als der Autor dieses Artikels 1998 seine ersten Linux-Erkundungen unternahm, war es nichts Außergewöhnliches, wegen eines speziellen Treibers oder auch nur eines einzelnen wichtigen Patches einen eigenen Kernel zu kompilieren. Weil jedoch die Kernel der Distributionen in den letzten Jahren auch auf Desktops stetig zuverlässiger und vollständiger wurden, war das nur noch sehr seltenen nötig. Daher dürfte das Wissen um die Kunst des Kernel-Baus selbst bei vielen alten Hasen längst eingerostet sein.

Auswege

Insgesamt machen die im Netz spärlich dokumentierten Wege, einen IPU6-Chip unter Linux doch zum Laufen zu bringen, wenig Mut. Der bastelwillige Anwender hat einen wahren Marathon vor sich, will er die Webcam jemals irgendwie nutzen. Was ist zu tun?

Martin Sofaru, Mitglied der deutschen Linux-Community und eigentlich eher auf das Thema Netzwerke spezialisiert, besitzt einen Lenovo X1 Yoga der siebten Generation und hat die Mühsal aus eigenem Interesse auf sich genommen. In etlichen Bug Reports auf Github beschreibt er den Prozess, der letztlich bei ihm zum Erfolg führte. Der hat es mehr als in sich.

Das geht bereits beim Linux-Kernel los: Der vermag nicht in allen Fällen, aus den ACPI-Informationen des Systems die korrekte CSI-Pin-Belegung auszulesen, und braucht einen entsprechenden Patch [2] des Red-Hat-Mitarbeiters Hans de Goede (Abbildung 4). Hinzu kommt ein weiterer Codeflicken [3] für aktuelle Kernel, der dafür sorgt, dass Linux die IOMMU-Schnittstelle des IPU6-Chips nutzt, statt diesen erfolglos unter die Ägide der IOMMU-Verwaltung der CPU zu stellen. Ein dritter Patch [4] schließlich sorgt dafür, dass der Linux-Kernel das ACPI-Gerät LATT2021 erkennt, das in manchen Laptops mit IPU6-Chip verbaut ist und ohne das die Kamera sich nicht steuern lässt.

Abbildung 4: Falls der eigene Distributor die für IPU6 benötigten Patches nicht freundlicherweise bereits integriert hat, besteht der erste Schritt auf dem Weg zur Webcam-Nutzung daraus, den Kernel zurechtzuflicken.

Zunächst organisieren Sie sich also den Quelltext seines laufenden Kernels und prüfen, ob er die drei Codeergänzungen bereits enthält oder ob Sie sie noch anwenden müssen. Canonical hat zumindest die beiden erstgenannten Patches mittlerweile in den eigenen Kernel für Ubuntu 22.10 aufgenommen. Bei OpenSuse und Fedora war das zumindest zu Redaktionsschluss noch anders. Im Zweifelsfall bleibt Ihnen nur übrig, sich die Quellen des gerade laufenden Kernels zu beschaffen und die Codeflicken Stück für Stück abzugleichen.

Allerdings deckt ein entsprechend angepasster Kernel gerade einmal 10 Prozent des anstehenden Arbeitsaufwands ab. Sobald er läuft, steht das Kompilieren der benötigten Treiber mitsamt der Installation der notwendigen proprietären Firmware an. Letztere liefert Intel immerhin in einem eigenen Git-Verzeichnis aus [5]; eine Installationsanleitung verrät, was zu tun ist: Sie kopieren die Dateien aus den Ordnern include/ und /lib nach /usr/include/ respektive nach /usr/lib/.

Das verdeutlicht eine weitere Dimension des Schlamassels: Bei den proprietären Komponenten für IPU6 handelt es sich eben nicht nur um die Firmware selbst, sondern auch um einen Haufen von Userland-Bibliotheken für den Zugriff auf IPU6. Ubuntu und Arch Linux haben immerhin entsprechende Pakete im Angebot, bei Ubuntu allerdings extern von der OEM Solutions Group [6]. Bei OpenSuse und Fedora hingegen fällt deutlich mehr Handarbeit an. Hier müssen Sie die Daten direkt von Github beziehen und auf dem System entpacken.

Ähnlich verhält es sich mit den Treiberpaketen. Unter Ubuntu und Arch Linux stehen vorbereitete Pakete zur Verfügung, um die Module mit wenigen Befehlen für den eigenen Kernel zu kompilieren. Ubuntu setzt dafür wenig überraschend DKMS ein, wovon die Anwender gleich mehrfach profitieren: Komplementär zu den Modulquellen selbst hat die OEM Solutions Group auch einige Patches aus den Bug Reports zum Intel-Modulcode integriert, ohne die das Kernel-Modul schlicht nicht funktioniert.

Der Chipkonzern glänzt in seinem offiziellen Github-Repository erkennbar nicht mit Aktivität und dem Drang, den Einsatz seiner Hardware unter Linux so angenehm wie möglich zu gestalten. Gelackmeiert sind einmal mehr Fedora- und OpenSuse-Nutzer, denen deutlich mehr Arbeit ins Haus steht als den Anwendern anderer Distributionen.

Die Kernel-Module

Wer es bis hierhin geschafft hat, steht vor der nächsten Herausforderung: dem Bau der für den eigenen Kernel passenden IPU6-Module aus Intels Quellen. Auch hier hat Hans de Goede sich durch Patches und viele Anmerkungen ausgesprochen hilfreich hervorgetan, was letztlich zu halbfertigen To-go-Lösungen für einzelne Distributionen führt. Ubuntu hat für die aktuellen Treiber alle benötigten und verfügbaren Patches als DKMS-Pakete im Programm (wieder im OEM-Solutions-Repository), mittels derer sich das nötige Kernel-Modul wie gewohnt kompilieren lässt.

Bietet der eigene Distributor diesen Service nicht an, bleibt einmal mehr nur das Herunterladen der Quellen von Github mitsamt dem kompletten händischen Bauvorgang. Bitter: Gerade, weil Intel so wenig Liebe in die Pflege seiner IPU6-Treiber investiert, fehlen in deren Headern viele IDs von Chipsätzen für IPU6-Kameras, die in freier Wildbahn durchaus vorkommen. So verwenden etliche Modelle von Dell IPU6-Chips, die der Treiber eigentlich unterstützt, aber wegen veränderter IDs nicht erkennt.

Auch hier stehen Sie im Zweifelsfall im Regen und haben keine andere Wahl, als selbst Hand anzulegen. Das erfordert jedoch zusätzliches Wissen, denn dazu müssen Sie ja nicht nur den Kernel patchen, sondern den benötigten Patch auch noch selbst entwickeln. Gelangen Sie nach all diesen Widrigkeiten an den Punkt, dass der Treiber tatsächlich lädt, sind Sie bereits ein großes Stück weiter.

Krückenkonstruktion

Damit ist die Reise nach Absurdistan aber auch für Ubuntu- und Arch-Linux-Anwender längst noch nicht beendet. Selbst wenn ein vollständig gepatchter Kernel mit allen benötigten Bibliotheken, Firmware-Dateien und korrekt gepatchten Treibern vorliegt, zeigt der Kernel die neue Kamera zwar mit Dmesg erfolgreich an. Versuchen Sie aber beispielsweise, aus Firefox oder Chrome darauf zuzugreifen, sehen Sie nur einen schwarzen Bildschirm. Der Grund für das Debakel: Intel hat beschlossen, dass die hauseigenen IPU6-Treiber keine Kompatibilitätsschnittstelle für Video4Linux benötigen. Dieses Framework kommt im freien Betriebssystem aber fast exklusiv zum Einsatz, um externe Videokomponenten wie eben Webcams einzubinden.

Als hätte man noch nicht genug gebastelt, steht jetzt als nächster Schritt an, einen Relay-Daemon für Video4Linux zu installieren. Der greift auf der einen Seite das Signal des hoffentlich funktionierenden IPU6-Chips ab und übergibt es auf der anderen Seite an ein V4L-Pseudogerät, von wo die anderen Programme es dann wie gewohnt abgreifen können. Allein diese Krückenkonstruktion rechtfertigt eigentlich einen mittelschweren Tobsuchtsanfall, doch alle Aufregung nützt nichts: Wer die integrierte MIPI-Cam von aktuellen Laptops nutzen möchte, muss basteln.

Damit aus dem Gefrickel im Userspace überhaupt etwas wird, benötigen Sie zunächst aber noch eine andere Komponente: ipu6-HAL macht das IPU6-Interface für den Video4Linux-Relay-Daemon im Dateisystem des Hosts überhaupt erst sichtbar und mithin nutzbar. Wieder spielen Ubuntu und Arch Linux die Software als Paket über die jeweiligen Wege aus, während Fedora- und OpenSuse-Anwender erneut eine Bastelrunde einlegen müssen.

Besonders grotesk: In den Bug Reports rund um IPU6 kursieren Patches für das Video4Linux-2-Loopback-Pseudogerät, das letztlich herkömmlichen Tools den Zugriff auf die Kamera ermöglicht. Dasselbe gilt für den Relay-Daemon, eigentlich ein Ubuntu-Werkzeug, der jedoch selbst dort nicht ab Werk mit dem Rest der Komponenten zusammenspielt. In seiner Standardkonfiguration passen die Parameter in seiner Systemd-Unit nicht, sodass es zwar startet, die IPU6-Kamera jedoch nicht als potenziellen Kommunikationspartner erkennt.

Erst kurz vor Redaktionsschluss trudelten im schon erwähnten OEM-Solutions-PPA [6] von Ubuntu die passenden Pakete mit allen nötigen Patches ein, mit denen sich eine IPU6 auf einem Lenovo X1 Carbon der zehnten Generation tatsächlich in Betrieb nehmen lässt. Ein Blick auf dieses Repository samt der in den Quellen verlinkten Patches kann dabei helfen, das Setup auf einer anderen Distribution nachzubauen. Eine Erklärung im Detail würde den Rahmen dieses Artikels allerdings sprengen.

Auf wackeligen Beinen

Dass es im Test dann doch irgendwann gelang, die Kamera unter Linux in vollem Umfang zu nutzen, lässt sich letztlich aber nur als Pyrrhussieg werten: Das gesamte Konstrukt steht auf ausgesprochen tönernen Füßen. Beispielsweise müssen Sie den selbstgebauten Kernel über die Paketverwaltung für automatische Updates durch das System sperren. Sonst ersetzt die Distribution das mühsam zusammengeflickte Kunstwerk bei der nächsten gestopften Sicherheitslücke gleich wieder durch den Standard-Kernel.

Gerade auf Desktops und Laptops will man andererseits auch nicht mit einem alten Kernel unterwegs sein. Das Risiko, zum Opfer eines Angriffs durch ein ungestopftes Loch zu werden, steigt mit jeder bekannt gewordenen Lücke erheblich. Darüber hinaus gilt für die IPU6-Treiber dasselbe wie für alle Treiber, deren Hersteller sich nicht an die Gepflogenheiten der Linux-Welt hält: Anwender begeben sich hier in ein waschechtes Vabanquespiel. Schon die nächste Version des Kernels der verwendeten Distribution, auf die man aus welchen Gründen auch immer aktualisieren muss, macht dem Workaround mit externen Treibern im schlechtesten Fall durch Inkompatibilität den Garaus.

Dass der Kernel-Grande Greg Kroah-Hartman bereits den Daumen über den Treiber in seiner aktuellen Form gesenkt hat, macht keinen Mut für die Zukunft: Intel müsste hier wohl ein umfangreiches Redesign des Codes vornehmen, um den Treiber irgendwann in den Mainline-Kernel zu integrieren. Dass das in absehbarer Zeit geschieht, erscheint angesichts des aktuellen Zustands des Treibers jedoch gelinde gesagt unwahrscheinlich.

Fazit

Geräte mit IPU6-Chipsatz sollte man also als Linux-Anwender unbedingt meiden, auch wenn es sich falsch anfühlt, eine solche Behauptung im Jahr 2023 überhaupt noch aufzustellen. Intel wäre hier in der Pflicht, passende Treiber zu entwickeln, zu warten und in Linux zu integrieren, wenn der Konzern schon die entsprechende Hardware per Spezifikation mit aller Gewalt in den Markt drücken will.

Besitzen Sie bereits ein Gerät mit MIPI-Cam oder kommen um die Anschaffung nicht herum, weichen Sie am besten auf eine externe Webcam aus (Abbildung 5). Entsprechende Geräte gibt es schon für kleines Geld, und sie laufen unter Linux in aller Regel als Plug-and-Play-Lösung ohne spezielle Treiber außerhalb des Kernels.

Es bleibt zu hoffen, dass Intel sich zügig eines Besseren besinnt und die Situation in den Griff bekommt. Aktuell ist die Nutzung von IPU6-Kameras unter Linux nämlich vor allem eines: eine ungeheuerliche Zumutung seitens des Herstellers. (jcb/jlu)

Abbildung 5: Absurd, aber nicht zu ändern: Wer einen Laptop mit IPU6-MIPI-Chip von Intel hat, fährt mit einer externen Webcam deutlich besser als mit jeder Treiberbastelei am System. Quelle: Logitech