BookinglyTech News
Software

El kernel de Linux explora drivers de panel de pantalla escritos con BPF

Tras el éxito de los drivers HID basados en BPF, Linux estudia aplicar el mismo modelo a los paneles de pantalla: lógica cargable desde espacio de usuario para esquivar el ciclo del kernel.

2 min de lecturaPhoronix0 vistas

El kernel de Linux se plantea extender a los paneles de pantalla el enfoque que ya usa en los drivers HID: escribirlos como programas BPF que se cargan desde espacio de usuario en lugar de vivir dentro del árbol del kernel.

La comparación no es gratuita. Los drivers HID basados en BPF llevan tiempo demostrando que un quirk o un arreglo para un dispositivo concreto puede llegar al usuario sin esperar a que se abra la ventana de fusión del ciclo de kernel siguiente. El programa eBPF se carga desde espacio de usuario, pasa el verificador y se engancha donde corresponda; si hay que corregir algo, se corrige ahí, sin tocar el árbol completo ni arrastrar un parche durante meses.

Por qué el panel de pantalla es un candidato

El hardware de pantalla es un catálogo enorme y muy heterogéneo, con paneles que a menudo necesitan ajustes propios que no tienen nada que ver con el resto del sistema. Hoy eso se resuelve con parches en el driver correspondiente y, por tanto, al ritmo del kernel. Mover esa lógica a programas BPF cargables desde espacio de usuario permitiría iterar al margen de ese calendario, igual que ha pasado con HID.

Con HID ya está demostrado que el modelo funciona y que la gente lo usa. Con paneles, de momento, la noticia es que se está explorando, y poco más: no hay parches públicos, ni autor conocido, ni cifras de rendimiento, ni fecha para verlo en un kernel estable.

Queda por ver si el coste de meter un verificador y una capa de programas cargables en la ruta de un driver de pantalla compensa. Un panel no es un teclado: la ruta de vídeo es sensible a la latencia y a la frecuencia de refresco, y cualquier indirección se paga. Tampoco está claro qué se puede expresar en BPF sin bajar al C del kernel, que es donde viven los registros de hardware. Es un experimento, no un plan.