Linux: ¿Visibilidad de los planes de desarrollo de SO específicos de RPi para la comunidad?

Mirando hacia atrás en los últimos años, ¿qué identificaría como desarrollos en los que la comunidad se habría beneficiado de un aviso anticipado?

Tan seguro como que la noche sigue al día, el número de versiones de Linux aumenta. Intentamos obtener versiones funcionales de cada versión candidata lo antes posible, aunque no todas llegan al código de producción. Al mismo tiempo, aunque a un ritmo mucho más lento, Debian está produciendo sus versiones principales y es probable que nos traslademos a Buster en algún momento en el futuro.

El desarrollo de software propio de Raspberry Pi generalmente está vinculado a las versiones de hardware, y si espera un aviso previo de ellas, se sentirá decepcionado.

Como dice Phil, muchas cosas están relacionadas con los lanzamientos de hardware.

Casi todas las cosas sobre las que Eric informa son cosas que han estado en progreso durante un tiempo, pero mientras estuvo aquí tuvimos la oportunidad de discutir e identificar las partes faltantes para acercar el KMS (falso) a la línea principal.
Tiene una experiencia muy limitada en códecs y cámaras, pero mucha en 3D y KMS. Tengo un conocimiento muy limitado de V3D, algo más sobre composición general y mucho sobre códecs y cámaras. Combine los dos y transmita algunos de los conocimientos, y obtenemos algunos avances :-)

Personalmente, me gustaría ver registros de cambios más detallados (por ejemplo, siempre dicen "nuevo kernel, nuevo firmware", pero sin ninguna explicación de lo que ha cambiado o se ha corregido).

Para el kernel y el firmware, por ejemplo, está muy abierto aquí en Github, para los lanzamientos de Raspbian no veo nada de eso, los lanzamientos de Raspbian simplemente parecen "aparecer de ahora en cualquier lugar";)

@pelwell justo en la parte superior de mi cabeza, el cambio de nombre de VC SONAME. Incluso se suponía que debía anunciarse con anticipación, pero hasta donde yo sé, eso nunca sucedió, y lo primero que supe fue después de que todas mis configuraciones se rompieron en el tramo. Y sí, me doy cuenta de que no tiene nada que ver con el kernel. :)

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

@pelwell @ 6by9 nos beneficiaríamos de una notificación avanzada sobre especiales de RPI como VC, firmware, escritorio.
Nuevo HW está explícitamente fuera de alcance.

Un ejemplo es el controlador VC4, donde la publicación del blog de Eric indicaba "algunos cabos sueltos" que se describen como "Alguien tiene que hacerlo".
Unir todas las actividades requeridas a través de un hito, podría potencialmente atraer a los contribuyentes para que las recojan y, como resultado, permitir la fusión de la mejora planeada de VC4 ' no necesita gpu_mem = más ' un poco antes.

Unir todas las actividades requeridas a través de un hito, podría potencialmente atraer a los contribuyentes para que las recojan y, como resultado, permitir la fusión de la mejora planeada de VC4 'no necesita gpu_mem = más' un poco antes.

Dado que eso requiere trabajos importantes dentro del firmware y el trabajo complementario en una nueva versión de vc-sm (con suerte con una pequeña posibilidad de actualización), no es algo que se pueda compartir.

Luego, se requieren importantes discusiones sobre cómo administramos la migración de gpu_mem a cma. La nueva asignación remota a través de vc-sm hará que la pila GLES de firmware heredado sea inviable, ya que la latencia de ida y vuelta para asignar memoria va a matar el rendimiento (la decodificación de video / cámara hace todas las asignaciones por adelantado, por lo que es una configuración relativamente menor aumento de tiempo). Por lo tanto, cambiar entre CMA y gpu_mem requerirá algo de magia en el firmware para observar los nodos del árbol de dispositivos con la esperanza de averiguar en qué modo se está ejecutando el usuario, lo que se complica aún más por el hecho de que todo el árbol de dispositivos actual se realiza después de gpu_mem ya está asignado.
Nada de eso se puede compartir tal como está en el firmware, por lo que nuevamente no se beneficia de que se establezca como un hito.

Puede resultar beneficioso establecer algunos detalles más de la corrección DispmanX propuesta para KMS, y posiblemente el conector de escritura diferida para la transposición. El primero de ellos depende principalmente de RPT como conocemos DispmanX, pero el principal obstáculo es tener que tener una solución diferente entre X11 y un sistema basado en consola. Este último Eric tiene algunas ideas, por lo que dependerá de él desarrollarlas.

Gracias @ 6by9.
Espero ver más sobre el plan sobre 'cómo administrar la migración de gpu_mem a cma' en algún momento en el futuro.

Esto no es realmente un problema del kernel, así que cierre. Sin embargo, siéntase libre de agregar comentarios al final del número.