Esta es la receta para construir el controlador DisplayLink en un paquete RPM para Fedora, CentOS Stream, Rocky Linux y AlmaLinux OS. Este controlador admite las siguientes familias de dispositivos:
El paquete incluye la biblioteca evdi de código abierto.
Los paquetes se crean automáticamente mediante GitHub Actions y se cargan en las versiones de GitHub.
NOTA: Ahora se puede construir limpiamente mediante un archivo .spec (en formato simulado). Descargue archivos a través de
make srpm
.
Para crear el paquete rpm del controlador, puede ejecutar el comando make
desde el directorio extraído. El Makefile debería descargar los archivos que necesita y crear un RPM.
Una make
predeterminada utilizará el controlador evdi que se incluye con el paquete del controlador Displaylink. Si necesita utilizar una versión más reciente del repositorio evdi Github y actualmente no está presente en el paquete del controlador Displaylink, puede hacerlo ejecutando:
make github-release
Para usar displaylink-rpm y el módulo del kernel evdi con el arranque seguro habilitado en Fedora, debe firmar el módulo con una clave de propietario de máquina (MOK) registrada.
Antes de continuar, verifique si el arranque seguro está habilitado en su sistema: mokutil --sb-state
Si la respuesta es sí, continúe con la guía a continuación; de lo contrario, no es necesario inscribirse en MOK y puede ignorar esta instrucción.
A partir de la versión 3.0.4 de DKMS, no es necesario crear MOK manualmente; durante la instalación, DKMS genera su propia clave que el usuario debe registrar solo una vez.
Para registrar la clave, siga estas instrucciones:
sudo dnf install mokutil dkms
.mokutil --import /var/lib/dkms/mok.pub
y siga las instrucciones de inscripción disponibles en la página de DKMS github (será necesario reiniciar el sistema).sudo dkms autoinstall
para construir y firmar el módulo evdi mediante MOK.sudo dkms status
o sudo systemctl status displaylink-driver.service
. Cuando se utiliza con la estación de acoplamiento Dell D6000, DisplayLink 5.1.26 pierde periódicamente la comunicación con los monitores conectados, lo que hace que se queden en blanco y entren en modo de ahorro de energía. En el momento en que los monitores quedan en blanco, el kernel registra dos mensajes de error:
kernel: usb < xxx > : Disable of device-initiated U1 failed.
kernel: usb < xxx > : Disable of device-initiated U2 failed.
Para solucionar este problema, deshabilite la administración de energía para el dispositivo de audio comentando una línea en /etc/pulse/default.pa
:
# ## Automatically suspend sinks/sources that become idle for too long
# load-module module-suspend-on-idle
Generalmente queremos realizar un seguimiento de la versión estable actual de la biblioteca evdi. Sin embargo, los kernels de Fedora suelen ser mucho más nuevos que los admitidos oficialmente en esa versión y no es raro que un kernel nuevo rompa por completo la compilación. Esto puede dejarlo en una situación en la que no pueda actualizar su kernel sin sacrificar sus dispositivos DisplayLink. Esto no es bueno si el nuevo kernel tiene correcciones importantes de seguridad o rendimiento.
Los desarrolladores de evdi utilizan la rama main
como rama principal para todos los cambios.
Para extraer el código más reciente de la rama main
y usarlo para compilar, haga lo siguiente:
make main
make github-release
Por supuesto, esta rama main
también incluirá algunos cambios experimentales y menos probados que pueden alterar las cosas de otras formas inesperadas. Por lo tanto, deberías preferir la compilación principal si funciona, pero si se estropea, tienes la opción de crear una compilación main
.
Si está utilizando Fedora Rawhide, puede crear una compilación que se descargará automáticamente desde la rama main
y se compilará ejecutando:
make rawhide
En el pasado, el código de la rama
main
se etiquetaba y esa versión es la que se incluía en el paquete del controlador Displaylink.Recientemente, estamos viendo que aparecen nuevos cambios en el paquete del controlador Displaylink sin que se cambie la versión de la biblioteca evdi. Esto ha creado cierta confusión y dificultad cuando se trata de actualizaciones de mantenimiento.
La gente de evdi ha reconocido este problema y está trabajando para que el proceso sea más transparente.
La forma más sencilla de contribuir con el paquete es bifurcarlo y enviar una solicitud de extracción en GitHub.
Hay dos tipos principales de contribuciones: o se lanza una nueva versión original o se propone una modificación en el paquete.
Existe una variable llamada RELEASE
para fines de empaquetado. Esa variable debe establecerse en 1 cuando se contribuye con una nueva versión ascendente y aumentarse en uno al agregar cualquier otra funcionalidad al archivo de especificaciones para la misma versión ascendente.
De vez en cuando, DisplayLink actualizará su controlador. Intentamos hacerlo, pero para ello normalmente confiamos en solicitudes de extracción.
Gestionamos tres números ascendentes diferentes para el versionado:
Estas variables deben cambiarse en los siguientes lugares:
DAEMON_VERSION
es la versión de DisplayLinkManagerVERSION
es actualmente la versión del controlador evdiDOWNLOAD_ID
es el parámetro de consulta ?download_id=
en el sitio web de DisplayLink para descargar el zipAdemás, actualice el registro de cambios en la parte inferior del archivo displaylink.spec.
Al cambiar una regla de empaquetado, incremente la variable RELEASE
en uno en displaylink.spec