Auf vt mit nvidia-driver & nvidia-modeset.ko und wieder zurück auf X-Server läuft

Nvidia hat es leider auch geschafft, das Anpissen der Opensource-Community zu perfektionieren. Es gibt etliche Beispiele. Spontan fällt mir zum Beispiel das Versprechen Dokumentation zu veröffentlichen und sich an Nouveau zu beteiligen ein. Das tat Nvidia dann auch, allerdings nur für die GPU des Tegra K1. Natürlich ganz uneigennützig, schließlich wollte man einen Stück vom Kuchen der Bastel-Boards auf ARM-Basis haben. Oder das man 2014 begann die zwingend notwendige Firmware zu signieren und damit freie Treiber von einer Reihe höherer Funktionen der GPU auszuschließen. Auch da versprach man signierte Images zu veröffentlichen. Das tut man sogar, nur leider hat es bei den Maxwell-GPUs etwas über 18 Monate nach Marktstart gedauert... Die Retourkutsche kommt dann natürlich auch regelmäßig. So darf Nvidia dieses System für geteilte Framebuffer im Linuxkernel nicht nutzen, weshalb unter Linux Optimus nur per X.org-Neustart oder dreckigere Hacks wie VirtualGL funktioniert.

Ich hatte einige Zeit die vage Hoffnung, dass Nvidia einen ähnlichen Weg wie AMD mit amdgpu-pro gehen könnte. Also einen relativ schlanken, freien Treiber im Kernel mit dem normalen DRM-Interface. Darauf können freie Treiber einsetzen und der eigene, proprietäre Renderstack. Nur das man den Nvidia-Treiber nun mit vermutlich recht viel Aufwand in Richtung KMS umbaut, spricht wohl deutlich dagegen.
 
Gibt es eigentlich einen Trick, wie man mit dem nvidia-modeset.ko von X.org auf die virtuellen Konsolen zurück kann. Wenn ich das versuche, sehe ich nur einen komischen bunt-gecheckten Bildschirm. Ich kann zurück zum X-Desktop, aber die Konsolen kann ich erst wieder benutzen, wenn X.org beendet ist.
 
Yamagi schrieb:
Die Retourkutsche kommt dann natürlich auch regelmäßig. So darf Nvidia dieses System für geteilte Framebuffer im Linuxkernel nicht nutzen, weshalb unter Linux Optimus nur per X.org-Neustart oder dreckigere Hacks wie VirtualGL funktioniert.
Zum Vergrößern anklicken....
Damit tun teh Masters of Universe Tux aber ihrem Nachwuchs weh. Denn nehmen wir mal den durchschnittlichen Ubuntu Nutzer, dem ist das warum und wieso nicht so ganz klar. Der Ubuntu Normalnutzer, gerne Frischling in der Linux Welt, kann dann aber seinen Laptop mit Optimus nicht so nutzen, wie es im besten Fall laufen sollte, mit dem umschalten im laufenden Desktopbetrieb auf die starke Grafiklösung. Oft ist ja auch die Hardware bei Linux Frischlingen schon da, bevor der Wunsch nach Linux entsteht. Überhaupt frage ich mich, was diese Hybrid-Grafik noch bringt, außer Problemen, denn die GPUs von Nvidia und AMD sind ja auch immer energieeffizienter geworden. Wäre es da nicht einfacher Laptops entweder mit Intel, AMD oder Nvidia Grafik, aber ohne Hybrid-Grafik? Die vielen Probleme mit dem Grafik-Hybridbetrieb wären dann aus der Welt. Das Tearing soll übrigens auf Hybrid-Grafik noch eine ganz andere Hausnummer sein, dort soll es auch nicht mit der CompositionPipeline lösbar sein, hat mir ein Ubuntu Supporter berichtet.
 
Fusselbär schrieb:
Damit tun teh Masters of Universe Tux aber ihrem Nachwuchs weh.
Zum Vergrößern anklicken....
Das wird nun leider etwas Offtopic:

In meinen Augen ist das Entwicklungsmodell des Linux-Kernels schon seit mindestens 10 Jahren für ein Projekt der Größe nicht mehr angemessen. Dadurch, dass Linux sowohl den Kernel selbst, als auch die Treiber enthält, handelt man sich zumindest zwei große Probleme ein:

  • Einmal zwingt man jeden Anbieter, der einen Treiber in den Distributionen sehen will, den komplexen Aufnahmeprozess in den Kernel zu durchlaufen und Entwicklerkapazitäten abzustellen, um dem Kernel zu folgen. Viele Anbieter, gerade kleinere, sagen deshalb ganz klar, dass es ihnen zu viel Aufwand ist. Sie unterstützen Linux nur in Form fischiger 3rd Party Module oder gleich gar nicht.
  • Dazu kommt, dass Hardwareunterstützung an Kernelversionen gebunden ist. In die LTS-Kernel werden nur wenige Treiber zurückportiert, wenn überhaupt machen es Distributoren für den Eigenbedarf. Dadurch wird in zyklisch releasten Distros aktuelle Hardware meist gar nicht unterstützt. Zum Beispiel erschien Intels Skylake-CPU mit zugehöriger Plattform im August 2015. Das da aktuelle Linux 4.1 hatte nur sehr rudimentäre Unterstützung, selbst das im November erschiene Linus 4.4 war bestenfalls so lala. Über Monate durfte man sich Kernel-Updates reinfrickeln, bei einigen Distros muss man es sogar immer noch... genauso die Radeon RX 480. Unterstützung durch den Linux-Kernel am Release-Tag ist wunderschön, nur hatte kaum eine große Distro den entsprechenden Kernel.
Würde man Linux spalten, könnte man diese Probleme umgehen. Auf der einen Seite steht der "Linux Kernel", der wirklich nur der Kernel selbst. Er bietet grundlegende Services an, hat stabile Schnittstellen. Dazu kommen die "Linux Driver", die Treiber auf Basis der stabilen Schnittstellen. Wenn ich Hardware unterstützen will, füge ich einen Treiber in die "Linux Driver" ein. Gerne mit einem Zwang, dass die dort veröffentlichten Treiber unter einer freien Lizenz stehen müssen. Damit ist man als Anbieter aus dem Entwicklungsprozess des Kernel raus, der Treiber hat nichts mehr mit Allüren der Kernelentwickler zu tun. Ändern sie die Schnittstellen und wird der Treiber nicht während der Übergangsfrist angepasst, ist er halt nicht mehr kompatibel. Nutzer könnten sich für ihre Hardware unabhängig des Kernels ihrer Distro den Treiber aus den "Linux Drivers" ziehen.

Ja, es gibt Gegenargumente. Ältere, vor allem wenig verbreitete Hardware würde wahrscheinlich schon nach einigen Jahren nicht mehr unterstützt werden. Je nach dem, wie oft man die Schnittstellen des "Linux Kernel" ändern muss. Es würden minderqualitative Treiber Einzug halten. Wogegen man mit Bewertungen oder ähnlichem vorgehen könnte. Man würde Blobs entgegen kommen. Aber Windows und eingeschränkt auch MacOS fahren mit diesem Modell seit vielen Jahren sehr gut, bieten gerade bei neuerer und spezieller Hardware nach wie vor eine bedeutend bessere Unterstützung als Linux.
 
Auch wenn ich das OT nun auch weiterführe (ist das Thema nicht schon geklärt? :D)... im Linux Kernel geht's auch nicht darum, es besonders toll für die Treiber-Entwickler zu machen, sondern eben genau möglichst alles in den Kernel-Tree zu bekommen unter einer freien Lizenz.

Gerade die Vergangenheit zeigt auch: Je weniger der Entwickler für seinen Treiber tun muss, desto schlechter wird dessen Qualität (siehe all die Android SoC Treiber). Nicht umsonst reißt auch unter macOS jeder Treiberschluckauf den ganzen Kernel mit runter.

Und das Problem mit den Linux-Distributionen ist auch hausgemacht. Wenn ich schon lese, dass ein neues Debian oder ein neues CentOS rauskommt und dann wird dort ein Kernel aus dem 3.x Branch genommen... *seufz*
 
Weil wir gerade bei dem Thema Kernel sind. Es gibt bei Linux-Distributionen immer wieder Kernel-Updates. Die dazugehörigen Changelogs sind meistens gut gefüllt. Wie ist das bei FreeBSD? Ich habe bisher mein 10.3 immer mit pkg upgrade auf dem neuesten Stand gebracht. Ich weiß, dass ich damit nur Ports aktualisiert habe.
Ansonsten bin ich sehr zufrieden. Bisher konnte ich fast alle Probleme dank Internet (Foren+Wikis) selbst lösen. Die Ports-Sammlung beschert mir immer wieder neue Versionen von Programmen. VirtualBox 5.1.6, Firefox 50, Dolphin, CentOS 6.8 im Linuxulator, Nvidia-Treiber 367.44 usw usw. FreeBSD 10.3 funktioniert genauso gut wie ubuntu MATE 16.04.1 auf meinem Rechner. OK, man muss sich mehr damit beschäftigen aber es ist auch sehr gut dokumentiert. Großes Lob an die Leute die zu Hause an den Ports basteln. Es ist bestimmt nicht einfach, z.B. einen dauernd veränderten Firefox-Source-Code anzupassen und zu kompilieren. Nochmal kurz zum Kernel. Ich sehe im Linux Git Log immer mehr Mitarbeiter von Firmen und kaum Privat-Personen. Wie ist das beim FreeBSD-Kernel+Userland? Die Firmen gehen natürlich im Linux-Kernel mehr ihren Interessen nach und manchmal wird dahingehend unvorteilhaft der Kernel Source-Code verändert. Einfaches Beispiel. Firma XYZ verändert ein paar Dateien damit ihre Produkte unterstützt werden und dadurch funktioniert eine andere Hardware nicht mehr richtig. Die Firma fixt aber das Problem nicht weil sie keine Schuld bei sich sieht und das Problem bleibt dann einfach weiterhin bestehen oder manchmal wird gut funktionierender Code komplett durch fehlerbehafteten neuen Code ausgetauscht. Es wird gemeldet aber der Programmierer sieht keine Schuld bei seinem Code also bleibt der Fehler einfach bestehen. Neuer Code gelangt sehr schnell in den Linux-Kernel. Wenn dieser aber nicht richtig funktioniert, dann dauert es eine Ewigkeit bis dieser gefixt wird. Am besten der Anwender bringt Beweise und gleich noch den Fix dazu. OK, genug geschrieben.
 
Ich sehe das alles relativ nüchtern. Nichts ist perfekt und egal wo man sucht, man findet scheiße. :D Linux 4.0 und 4.1 starten auf meinem iMac nicht, weil irgend ein Bug einen Kernel Oops Loop im Bluetooth Treiber auslöste... gut, war kein Problem, bleibe ich halt bei 3.9. Macht ja nichts. 4.2 lief dann wieder.

FreeBSD... ich glaube es war 9. Nach dem Upgrade starben mir reihenweise und regelmäßig Java Dienste aufgrund irgend eines Bugs im Kernel. Ich glaube gefixt wurde das nie richtig, nur umgangen. Aber von einem FreeBSD 9 Userland den FreeBSD 8 Kernel nehmen ist ja nun so nicht unbedingt möglich.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben