News Snapdragon X2: Qualcomm unterstützt Linux erstmals offiziell

[Tsu]

verständlich dass Qualcomm erst einmal auf das weit verbreitete ubuntu

Ich dachte eben dass es in einem Updatezyklus (z.b. im AUR) schneller gehen würde Fehlerbehebungen einzuspielen.

Distro hat erstmal mit Kernelentwicklung nicht viel zu tun, die sind „downstream“. Kernelentwickler nutzen irgendetwas und kompilieren sich den Kernel ab Quellen zur Qualitätssicherung und Tests selbst.

Qualcomm setzt bei Dokumentation für die „Community“ Ubuntu (bzw. Debian) voraus, intern läuft Ubuntu bei den (meisten) Entwicklern. DevBoards kommen zu Kunden mit Debian oder Ubuntu. So wichtig ist der Aspekt Distro aber nicht.

… allerdings steht hinter Ubuntu auch ein Unternehmen, mit denen QC bei Bedarf sprechen kann.

Scannertreiber 404, Druckertreiber 404

Du argumentierst ab einem doch sehr alten Stand. Unter Linux schafft sogar nun auch CUPS die Unterstützung für individuelle Druckertreiber ab → https://github.com/OpenPrinting/cups-sharing/issues/4 , weil das mittlerweile alles über standardisierte Protokolle läuft. Salopp gesagt – ich will in die Erklärung nicht mehr Mühe stecken, als du für das „Argument“.

 

[Tenferenzu]

doofe" Frage:

Würde ja bedeuten, dass Qualcomm alles opensource machen müsste, sämtliche Treiber und microcodes müssten offen gelegt werden, oder?

Wie machen das Intel und AMD?

Das ist keine doofe Frage.

Bin kein Programmierer oder Ähnliches, also wenn's nicht ganz 100%ig richtig ist, kann ich nichts machen aber ich hab' das bisher immer so verstanden: AMD bietet Treiber mit reduziertem Funktionsumfang quelloffen an und wenn man die rechtlich geschützten Teile (x265 encoding und so Sachen) verwenden will, benötigt man spezielle Treiber. Bei AMD wäre das dann der AMD Pro Treiber bzw. bei nVidia der nVidia Treiber. Die gibt's dann wieder nur als binärblob.
Man kann jetzt auch Funktionen in die Firmware integrieren und der Open source Treiber sagt dann der Firmware bzw. dem Binärblob nur noch: Encodier das mal in x265 ohne, dass die eigentliche Encoderfunktion open source sein muss.

So stells ich mir zumindest vor. Keine Ahnung wie weit ich da von der Realität entfernt bin ^^

 

[Piktogramm]

Noch besser wäre es den Kram zu fwupd zu schieben.

Was hat Firmware Support mit dem OS Support zu tun?

Firmware für alle Geräte lässt sich nicht sinnvoll mit fwupd verbreiten. Es ist mittlerweile üblich, dass viele Hardwarekomponenten keinen eigenen Festspeicher ausreichender Größe mitbringen um ihre eigene Firmware vollumfänglich bereit zu halten. Entsprechend wird bei diesen Geräten zu jeder Initialisierung die Firmware von Betriebssystem ins Gerät geladen.
fwupd ist für Geräte, die ihre Firmwäre selber, dauerhaft halten. Oftmals sind das jene Geräte, die vor dem Start des Betriebssystems verfügbar sein müssen (Uefi, Festspeicher, Eingabegeräte. Schon Grafiklösung, Netzwerk sind oftmals nur in Grundkonfiguraton nutzbar und erweiterte Fähigkeiten benötigen extern eingespielte Firmware für die volle Funktion).

Würde ja bedeuten, dass Qualcomm alles opensource machen müsste, sämtliche Treiber und microcodes müssten offen gelegt werden, oder?

Wie machen das Intel und AMD?

Müssen muss Qualcomm garnichts .
Es wäre sicher ganz witzig, wenn alles an Informationen und Code frei verfügbar wäre. Konsequent müsste dann aber wirklich alles bis zur Definition der Chips alles verfügbar sein, damit auch nachvollzogen werden kann, was der Microcode genau macht.
Für kommerzielle Anbieter ist das unwahscheinlich und unüblich.
Intel, AMD haben Firmware Binärblobs im Kernel: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/
(Intel Wifi, Atheros, Realtek etc. haben glaub noch weitere git repos)

Bin kein Programmierer oder Ähnliches, also wenn's nicht ganz 100%ig richtig ist, kann ich nichts machen aber ich hab' das bisher immer so verstanden: AMD bietet Treiber mit reduziertem Funktionsumfang quelloffen an und wenn man die rechtlich geschützten Teile (x265 encoding und so Sachen) verwenden will, benötigt man spezielle Treiber. Bei AMD wäre das dann der AMD Pro Treiber bzw. bei nVidia der nVidia Treiber. Die gibt's dann wieder nur als binärblob.
Man kann jetzt auch Funktionen in die Firmware integrieren und der Open source Treiber sagt dann der Firmware bzw. dem Binärblob nur noch: Encodier das mal in x265 ohne, dass die eigentliche Encoderfunktion open source sein muss.

So stells ich mir zumindest vor. Keine Ahnung wie weit ich da von der Realität entfernt bin ^^

Ähhh jain?!
Die Quelloffenen Treiber bei AMD können die De-/Encoder komplett nutzen. Da gibt es keine rechtlichen Hürden[1]. Zudem auch propritäre Treiber "nur" in Richtung GPU und deren Firmware kommunizieren, dass ein Datenblock mit bestimmten Parametern zu bearbeiten ist. Die Treiber selbst würden die Codecs nie selbst implementieren.


[1] Das HDMI-Forum pisst sich bei einer quelloffenen HDMI-Implementierung ein, verbietet es AMD, Valve implementiert es dennoch mit freien Treibern... Das ist aber eine andere Geschichte.

 

[Piktogramm]

Jetzt habe ich nur auf andere Posts reagiert, eigentlich wollte ich rumnörgeln, dass das alles so klingt wie schon bei den vorhergehenden Chipgenerationen. Qualcomm liefert Treiber für Mainline, ein paar Patches für Mesa. Am Schluss bleibt ACPI weiter kaputt, es braucht Devicetrees für alle realen Implementierungen der Plattform und weil es keine entsprechenden Auflagen seitens Qualcomm gibt, werden entsprechende Geräte in Sachen Qualität für DTs und Firmware für zusätzliche Hardware stark schwanken.

:/

Ergänzung (Donnerstag um 15:12)

Da Linux schon lange vergesellschaftet ist gibt es da keine Kunden.
Möglicherweise kommen einige einfach nicht damit klar das dort keine kapitalistische Logik vorherrscht.

Die Linuxfoundation agiert durchaus im Sinne ihrer wirtschaftlich motivierten Geldgeber/Boardmember. Vergesellschaftet ist da nix, außer das Linus da vor vielen Jahren die GPLv2 fociert hat.

Also wie früher in der Zone?

Du bist über fast schon zynische Ironie gestolpert? Edit: Typo

 

[Lora]

Ich glaube Qualcomm hat langsam gemerkt dass Hardware alleine halt doch noch keine Plattform ist ^^

Dass sie jetzt endlich mehr upstream machen, Freedreno und Turnip ordentlich nutzen wollen und Linux nicht mehr wie irgendein Nebenprojekt behandeln ist ja gut. Nur kommt das alles schon ziemlich spät.

Beim X1 schaut man beim offiziellen Linux Support anscheinend direkt wieder in die Röhre und beim X2 wird jetzt groß angekündigt was eigentlich von Anfang an hätte da sein müssen. Debian als großes Ziel finde ich bei so frischer Hardware auch etwas lustig. Bis Kernel, Mesa, GPU, NPU und Power Management dort wirklich rund laufen steht wahrscheinlich schon X3 vor der Tür.

Nvidia macht das mittlerweile einfach deutlich konsequenter. Da wird nicht nur Hardware hingestellt sondern gleich der ganze Stack mitgedacht. Treiber, Kernel, CUDA, Container, Tools, Doku, Updates. Genau so baut man Vertrauen auf. Bei Qualcomm wirkt es dagegen manchmal fast so als hätten sie gerade festgestellt dass Nvidia ungefähr 18 Jahre Vorsprung beim Aufbau eines brauchbaren Compute und Entwickler Ökosystems hat und jetzt versuchen sie das mit ein paar Linux Slides auf dem nächsten Summit aufzuholen ^^

ARM selbst ist dabei gar nicht das Problem. Die Hardware kann durchaus spannend sein. Aber wenn Qualcomm wirklich ernst genommen werden will müssen sie X2 auch noch sauber pflegen wenn X3 und X4 schon draußen sind.

Sonst ist es wieder nur... neue Hardware, neue Versprechen, alte Generation vergessen. ^^

 

[aid0nex]

Weiteres Beispiel das mir gerade eingefallen ist: Spiele auf Steam.

 

[Piktogramm]

Beim X1 schaut man beim offiziellen Linux Support anscheinend direkt wieder in die Röhre und beim X2 wird jetzt groß angekündigt was eigentlich von Anfang an hätte da sein müssen

Beim X1 sind alle Treiber im Kernel, Mesa. Die einzelnen Geräte mit den Chips funktionieren mit starken Schwankungen, wegen dem DeviceTree-Scheiß und kaputtem ACPI. Qualcomm hat für X2 nichts angekündigt in Richtung ACPI/strengeren Auflagen für DTs. Es wird also weiter halbgar bleiben.

 

[Lora]

Beim X1 sind alle Treiber...

Ja, genau das meinte ich mit dem Gesamtbild ^^

Wenn beim X1 Kernel und Mesa schon vorhanden sind, aber ACPI und DeviceTree je nach Gerät wieder unterschiedlich gut umgesetzt werden, dann liegt das Problem eben eher bei der Plattformintegration als bei den Treibern selbst. Und wenn Qualcomm beim X2 genau da keine strengeren Vorgaben macht, bestätigt das die Skepsis eigentlich nur. Dann sieht der Linux Support auf dem Papier besser aus, aber beim konkreten Gerät hängt wieder viel davon ab was der jeweilige OEM daraus macht.

In dem Sinn passt „halbgar“ leider ziemlich gut 👌

 

[flaphoschi]

Würde ja bedeuten, dass Qualcomm alles opensource machen müsste, sämtliche Treiber und microcodes müssten offen gelegt werden, oder?

Ja. Nein?
Treiber müssen quelloffen - und vor allem eingepflegt sein in Linux und zugehöriges GNU-Userland. Microcodes bzw. Firmware werden zur Verfügung gestellt, sind aber in der Regel nicht quelloffen.

Wie machen das Intel und AMD?

Wie oben beschrieben. Und oft mit Dokumentation zum Befehlssatz. Der Rest wird wohl eher im Linux-Kernel selbst dokumentiert, als im Quellcode.


Wenn es los geht mit „nur Debian, nur mit dem Kernel, aber nur wenn Neptun um Zeichen des Widers steht…aber nur mit X11!!!“ ist das eher ein quellgeschlossener, externer Treiber. Was bei Nvidia leider gelebte Tradition ist. Deswegen machen auch alle um Nvidia einen Bogen. Spart Geld und die paar vermeintliche FPS sind niemals den Ärger wert.


Qualcomm ist jetzt aber keine blutige Anfängertruppe. Atheros gehört zu Qualcomm, und deren WiFi/Bluetooth gilt speziell unter Linux als Goldstandard. Schon 2008 war Atheros die Antwort
Qualcomm hätte nur früher…auf die eigenen Leute hören sollen.

 

[foofoobar]

Und findest du das wirklich besser als eine Einheitsdistro welche du einfach für die Aufgabe parametrisieren kannst und die dynamisch anhand der verfügbaren Ressourcen die Leistungsparameter auswählt?

Schnelle Platten, mehr RAM und mehr CPUs werden von Linux nicht genutzt?

Qualcomm ist jetzt aber meine blutige Anfängertruppe. Atheros gehört zu Qualcomm, und deren WiFi/Bluetooth gilt speziell unter Linux als Goldstandard. Schon 2008 war Atheros die Antwort

Atheros wurde erst 2011 gekauft.

Die Linuxfoundation agiert durchaus im Sinne ihrer wirtschaftlich motivierten Geldgeber/Boardmember. Vergesellschaftet ist da nix, außer das Linus da vor vielen Jahren die GPLv2 fociert hat.

Gehört der Linuxfoundation hinterher das Ergebnis?

 

[flaphoschi]

Atheros wurde erst 2011 gekauft.

Sie ist waren schon 2008 die Guten. Das Zauberwort hieß „Prism“. Vielleicht sogar noch früher.

Broadcom dagegen war 2008 schlecht. Und 2011. Mir hat es dann gereicht, Bluetoothmodul im ThinkPad ersetzt

 

[andy_m4]

Was bei Nvidia leider gelebte Tradition ist.

Naja. Du kriegst auch bei nvidia inzwischen offzielle (also abseits von nouveau) Open-Source-Treiber:
https://github.com/NVIDIA/open-gpu-kernel-modules

Auf der anderen Seite hast Du bei AMD - trotz deren Offenheit - immer noch Closed-Source-Bestandteile wie z.B. die Firmware.
Und es ist schon irgendwie ein merkwürdiger Move viele Treiberbestandteile in eine geschlossene Firmware zu schieben und sich dann dafür feiern zu lassen, das man ja sooo quelloffen ist.

Nicht falsch verstehen. Ich würde AMD auch bevorzugen. Aber das so einseitig darzustellen a-la "nvidia sind die Bösen mit den geschlossenen Treibern während AMD da ganz anders ist", wird der Realität dann doch nicht zu 100% gerecht.

 

[Piktogramm]

Gehört der Linuxfoundation hinterher das Ergebnis?

Jain, es ist schwierig.
Bedingt hält die Foundation als Arbeitgeber div. Maintainer und Contributoren die Verwertungsrechte und bedingt Urheberrechte[1]. Die Nutzungs- und Verwertungsrechte werden nur bedingt über die GPLv2 Dritten gewährt.

Und mit etwas Realismus, es ist eher ein theoretisches Konstrukt, dass Linux geforkt werden und in gleicher Intensität weiter zu entwickeln wäre, außerhalb der zentralistischen Steuerung mit der Linux Foundation.

 

[flaphoschi]

Voran:
Unfassend Logik in quellgeschlossene Firmware auszulagern, ist schlecht.

Naja. Du kriegst auch bei nvidia inzwischen offzielle (also abseits von nouveau) Open-Source-Treiber:
https://github.com/NVIDIA/open-gpu-kernel-modules

Und in gelebter Tradition nicht in Linux. Nicht in Mesa. Stattdessen bei Khronos die Bugs als Feature definiert:

https://registry.khronos.org/OpenGL/extensions/NV/NV_robustness_video_memory_purge.txt

This extension will have a limited lifespan…

Ja. Haben die bei GNOME wohl gehofft?

https://www.phoronix.com/news/NVIDIA-Ubuntu-2025-SnR

War wohl nicht so limited (bis heute). Videospeicher weg nach VT-Switch oder Suspend. Also 08/15 Standardoperationen.

Firmware?
https://archlinux.org/packages/core/any/linux-firmware-nvidia/

Ich denke der Vorwurf gegen Intel, AMD oder Qualcomm bezüglich Firmware erübrigt sich. Ich befürchte große Teile der Branche müssen Fehler bei Nvidia umgehen, weil Nvidia halt sagt „Nö. Macht ihr mal für uns.“.

// edit: Danke für den Daumen.

 

[eastcoast_pete]

F!ck dich Qualcomm! Erst einen auf Support machen und nun EOL oder wie?

Ja, die Hardware für andere Betriebsysteme (als Windows-on-ARM) zu öffnen sieht anders aus! Dabei hat Microsoft sich bei Windows-on-ARM wirklich kein Bein rausgerissen. Qualcomm scheint trotzdem nicht kapieren zu wollen, daß Goodwill durchaus bares Geld wert sein kann.

 

[BxBender]

ARM Produkte haben echt den Support verschlafen wie andere den Klimawandel.
Bei Windows hatte man nie eine wirkliche Chance direkt mit einzusteigen.
Der Fokus musste daher von Anfang an klar Linux sein.
Mit Linux sind auch sehr günstige Geräte machbar, wo das ganze Konzept dann auf kostenlose Software basiert.
Wenn man mit solchen Geräten die Big Tec überflüssig macht, hat das durchaus Potential vor allem in ärmeren Ländern, und bei den Menschen die generell autoritäre Systeme wie das Trump Regime und ihre Mitläufer meiden und abstrafen.
Apple, NVidia und Intel haben sich an Trump verkauft, dazu die ganze KI Industrie, das darf man nicht unterstützen.

 

[Marcel Klappert]

Was ist denn eigentlich der Unterschied zwischen Framework als Laptop Hersteller, der zum Teil Geräte bereits ab Werk mit Linux und Intel Chips ausliefert und der Tatsache, dass zukünftig andere Notebookfirmen entsprechende mobile Computer 💻 mit Snapdragon Prozessoren auf den Markt bringen, inklusive offizieller Treiberunterstützung durch Qualcomm.

Ist bei Linux on ARM die Programmkompatibilität leichter realisierbar als bei Windows on Arm, also müssen weniger für die x64 Architektur geschriebene Programme emuliert werden?

Außerdem behauptet Qualcomm, daß Linux nur auf den neueren X2 Prozessoren funktionieren wird, wohingegen die neuen Googlebooks doch noch die ältere Chipgeneration verbaut haben, aber Entwickler an den Geräten problemlos Linux parallel zum Googlebook OS laufen lassen können.

Also entweder arbeitet Qualcomm hier mit Google eng zusammen oder aber die Entwickler aus dem kalifornischen Mountain View haben endlich geschafft woran andere zuvor gescheitert sind.
Immerhin hätte man bei Google die Personalstärke für sowas und damit auch ein Argument, warum überhaupt jemand so ein überteuertes Produkt mit einem Betriebssystem kaufen sollte, daß deutlich weniger bietet als die Konkurrenz von Microsoft und Apple.

 

[Habicht]

Linux ist Debian bzw. Ubuntu.

Falsch - Linux ist der Kernel, nicht mehr und nicht weniger.

Bei Smartphones und Tablets ergibt Linux endlich mal Sinn.
Hier könnte ich mir ein solches Produkt mit Linux durchaus vorstellen.

Die Aussage verstehe ich nicht - "Linux" ist doch gerade auf Smartphones und Tablets weit verbreitet.

 

[Alexander2]

Ich habe bis jetzt noch keinen Open Source Treiber für die dedizierten Nvidia GPUs gesehen.

Die vertreiben zwar ein Pakete Nvidia Open oder wie die das nennen, aber der Offene Teil ist ja nur ein kernel Modul, das den eigentlichen weiterhin unverändert Proprietären nvidia Treiber verlinkt mit dem Kernel. Und das zu dem Zweck, damit Updates für alle einfacher werden, das ist ja soweit als ein Feature auch schonmal gut.

Das was dann irgendwann mal kommen soll ist ein funktionierender Open source Vulkan Treiber NVK, wo Nvidia am unterstützen ist, damit der Entwickelt werden kann. Fertig/Nutzbar ist das dingen NOCH nicht.

NVK wäre das was dem bei Intel/AMD zum Teil entspricht. immerhin bietet es dann schon Vulkan, man könnte sogar mit einem weitren übersetzer OpenGL bewerkstelligen, einen seperaten OpenGL Treiebr in Entwicklung gibts soweit ich weiß gerade nicht. Da mag ja vielleicht auch das Ziel den OpenGL zu Vulkan übersetzer zu nutzen wenns mal so weit ist.

(Nuveau kann man nicht zählen, das ist nichts performance Seitig funktionales mit irgendeiner Nvidia GPU, die nicht ins Museum gehört, das Projekt hat Nvidia erfolgreich gestoppt durch Firmware Blob verschlüsselungsmaßnahmen etc.)

 

[Helpmaster5000]

Falsch - Linux ist der Kernel, nicht mehr und nicht weniger.

Ja! Trotzdem ist ohne Ubuntu und Debian nichts mehr los.