Linux: Visibilité des plans de développement d'OS spécifiques à RPi pour la communauté ?

En regardant en arrière au cours des dernières années, quels développements identifiez-vous comme des développements où la communauté aurait bénéficié d'un préavis ?

Aussi sûr que la nuit succède au jour, le nombre de versions de Linux augmente. Nous essayons d'obtenir des versions fonctionnelles de chaque version candidate dès que possible, même si toutes ne parviennent pas au code de production. Dans le même temps, bien qu'à un rythme beaucoup plus lent, Debian produit ses versions majeures, et nous allons probablement passer à Buster à un moment donné dans le futur.

Le développement de logiciels propres à Raspberry Pi est généralement lié aux versions matérielles, et si vous vous attendez à un préavis de celles-ci, vous serez déçu.

Comme le dit Phil, beaucoup de choses sont liées aux versions matérielles.

Presque toutes les choses dont Eric fait rapport sont des choses qui sont en cours depuis un certain temps, mais pendant qu'il était ici, nous avons eu l'occasion de discuter et d'identifier les éléments manquants pour rapprocher le (faux) KMS de la ligne principale.
Il a une expérience très limitée des codecs et des caméras, mais beaucoup sur la 3D et le KMS. J'ai une connaissance très limitée de V3D, un peu plus sur la composition générale, et beaucoup sur les codecs et les caméras. Combinez les deux et transmettez une partie des connaissances, et nous obtenons des progrès :-)

Personnellement, j'aimerais voir des journaux des modifications plus détaillés (par exemple, ils disent toujours "nouveau noyau, nouveau firmware", mais sans aucune explication de ce qui a changé ou a été corrigé).

Pour le noyau et le firmware par exemple, c'est très ouvert ici sur Github, pour les versions Raspbian, je ne vois rien de tout cela, les versions Raspbian semblent juste "surgir de nulle part" ;)

@pelwell juste au-dessus de ma tête, le renommage VC SONAME. C'était même censé être annoncé à l'avance, mais pour autant que je sache, cela ne s'est tout simplement jamais produit, et la première fois que j'en ai entendu parler, c'était après que toutes mes constructions se soient cassées. Et oui je me rends compte que cela n'a rien à voir avec le noyau. :)

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

@pelwell @6by9, nous bénéficierions d'une notification avancée sur les offres spéciales RPI telles que VC, firmware, desktop.
Le nouveau matériel est explicitement hors de portée.

Un exemple est le pilote VC4 où le billet de blog d'Eric indiquait "quelques bouts en suspens" décrits comme "quelqu'un en a besoin".
Le fait de lier toutes les activités requises via un jalon pourrait potentiellement attirer des contributeurs pour les reprendre et, par conséquent, permettre de fusionner l'amélioration VC4 prévue « pas besoin de gpu_mem= plus » un peu plus tôt.

Le fait de lier toutes les activités requises via un jalon pourrait potentiellement attirer des contributeurs pour les reprendre et, par conséquent, permettre de fusionner l'amélioration VC4 prévue « plus besoin de gpu_mem= plus » un peu plus tôt.

Étant donné que cela nécessite des travaux importants au sein du firmware et un travail d'accompagnement sur une nouvelle version de vc-sm (avec une petite possibilité de mise en amont, espérons-le), ce n'est pas quelque chose qui peut être partagé.

Il y a ensuite des discussions importantes nécessaires sur la façon dont nous gérons la migration de gpu_mem vers cma. La nouvelle allocation à distance via vc-sm va rendre la pile GLES du firmware héritée inutilisable car la latence aller-retour pour allouer de la mémoire va tuer les performances (le décodage vidéo/la caméra effectue toutes les allocations en amont, c'est donc une configuration relativement mineure augmentation du temps). La commutation entre CMA et gpu_mem va donc nécessiter un peu de magie dans le firmware en regardant les nœuds de l'arborescence des périphériques dans l'espoir de déterminer dans quel mode l'utilisateur s'exécute, encore compliqué par le fait que l'arborescence actuelle des périphériques est entièrement terminée après gpu_mem est déjà alloué.
Rien de tout cela ne peut être partagé tel qu'il est dans le firmware, donc encore une fois, il ne bénéficie pas d'être défini comme un jalon.

Il peut être avantageux de présenter plus de détails sur le shim DispmanX proposé pour KMS, et éventuellement sur le connecteur de réécriture pour la transposition. Le premier d'entre eux dépend principalement de RPT comme nous le connaissons DispmanX, mais le principal point d'achoppement est de devoir avoir une solution différente entre X11 et un système basé sur une console. Ce dernier Eric a quelques idées, ce serait donc à lui de les étoffer.

Merci @6by9.
J'ai hâte d'en savoir plus sur le plan de « comment gérer la migration de gpu_mem vers cma » à un moment donné dans le futur.

Ce n'est pas vraiment un problème de noyau, donc je ferme. Cependant, n'hésitez pas à ajouter des commentaires à la fin du numéro.