Linux: Sichtbarkeit von RPi-spezifischen OS-Entwicklungsplänen für die Community?

Was würden Sie im Rückblick auf die letzten Jahre als Entwicklungen bezeichnen, bei denen die Community von einer Vorankündigung profitiert hätte?

So sicher, wie die Nacht dem Tag folgt, steigen die Linux-Versionsnummern. Wir versuchen, von jedem Release Candidate so schnell wie möglich funktionierende Versionen zu erhalten, auch wenn nicht alle es in den Produktionscode schaffen. Zur gleichen Zeit, wenn auch in einem viel langsameren Tempo, produziert Debian seine Hauptversionen, und wir werden wahrscheinlich irgendwann in der Zukunft zu Buster wechseln.

Die eigene Softwareentwicklung von Raspberry Pi ist normalerweise an Hardware-Releases gebunden, und wenn Sie eine Vorankündigung davon erwarten, werden Sie enttäuscht sein.

Wie Phil sagt, hängt vieles mit Hardware-Releases zusammen.

Fast alles, über das Eric berichtet, ist seit einiger Zeit in Arbeit, aber während er hier war, hatten wir die Gelegenheit, die fehlenden Teile zu diskutieren und zu identifizieren, um (gefälschtes) KMS näher an die Hauptlinie zu bringen.
Er hat nur sehr begrenzte Erfahrung mit Codecs und Kameras, aber viel mit 3D und KMS. Ich habe nur sehr begrenzte Kenntnisse in V3D, etwas mehr über die allgemeine Komposition und viel über Codecs und Kameras. Kombinieren Sie beides und geben Sie etwas von dem Wissen weiter, und wir kommen voran :-)

Persönlich würde ich gerne detailliertere Änderungsprotokolle sehen (zum Beispiel heißt es immer "neuer Kernel, neue Firmware", aber ohne Erklärung, was geändert oder behoben wurde).

Für den Kernel und die Firmware zum Beispiel ist es hier auf Github sehr offen, für die Raspbian-Releases sehe ich nichts davon, Raspbian-Releases scheinen einfach "aus dem Nichts aufzutauchen" ;)

@pelwell gerade aus dem Kopf, die Umbenennung von VC SONAME. Es sollte sogar im Voraus angekündigt werden, aber das ist meines Wissens einfach nie passiert, und das erste, was ich davon erfuhr, war, dass meine Builds in Dehnung brachen. Und ja, mir ist klar, dass das nichts mit dem Kernel zu tun hat. :)

Siehe: https://github.com/raspberrypi/firmware/issues/625#issuecomment -230356111

@pelwell @6by9 wir würden von einer erweiterten Benachrichtigung über RPI-Specials wie VC, Firmware, Desktop profitieren.
Neue HW ist explizit nicht im Umfang enthalten.

Ein Beispiel ist der VC4-Treiber, bei dem Erics Blog-Post auf ein paar lose Enden hinwies, die als 'Jemand muss' beschrieben wurden.
Die Zusammenführung aller erforderlichen Aktivitäten über einen Meilenstein könnte potenziell Mitwirkende anziehen, um sie aufzunehmen, und als Ergebnis die geplante VC4-Verbesserung ' gpu_mem= nicht mehr erforderlich ' etwas früher zusammenführen.

Die Zusammenführung aller erforderlichen Aktivitäten über einen Meilenstein könnte potenziell Mitwirkende anziehen, um sie aufzunehmen, und als Ergebnis die geplante VC4-Verbesserung „brauche gpu_mem= nicht mehr“ etwas früher zusammenführen.

Da dies erhebliche Arbeiten innerhalb der Firmware und begleitende Arbeiten an einer neuen Version von vc-sm (hoffentlich mit einer kleinen Möglichkeit des Upstreamings) erfordert, kann dies nicht weitergegeben werden.

Es sind dann große Diskussionen erforderlich, wie wir die Migration von gpu_mem zu cma verwalten. Die neue Remote-Zuweisung über vc-sm wird den GLES-Stack der Legacy-Firmware unbrauchbar machen, da die Round-Trip-Latenz für die Speicherzuweisung die Leistung beeinträchtigen wird (Videodecodierung / Kamera führen alle Zuweisungen im Voraus durch, daher handelt es sich um ein relativ kleines Setup Zeiterhöhung). Das Umschalten zwischen CMA und gpu_mem erfordert daher einige Magie in der Firmware, die sich die Gerätebaumknoten ansieht, in der Hoffnung, herauszufinden, in welchem ​​​​Modus der Benutzer läuft, was noch komplizierter wird durch die Tatsache, dass der aktuelle Gerätebaum alles nach gpu_mem erledigt wird ist bereits vergeben.
Nichts davon kann so wie in der Firmware verteilt werden, also profitiert es auch nicht davon, als Meilenstein festgelegt zu werden.

Es kann von Vorteil sein, einige weitere Details des vorgeschlagenen DispmanX-Shims für KMS und möglicherweise des Rückschreibkonnektors für die Transponierung anzugeben. Ersteres hängt hauptsächlich von RPT ab, wie wir DispmanX kennen, aber der größte Stolperstein ist, dass es eine andere Lösung zwischen X11 und einem konsolenbasierten System geben muss. Letzterer Eric hat einige Ideen, es liegt also an ihm, sie zu konkretisieren.

Danke @6by9.
Ich freue mich darauf, irgendwann in der Zukunft mehr über den Plan zur Verwaltung der Migration von gpu_mem zu cma zu erfahren.

Dies ist nicht wirklich ein Kernel-Problem, also schließen. Sie können jedoch gerne Kommentare am Ende der Ausgabe hinzufügen.