rpm do link de exibição
v6.0.0-2
Esta é a receita para construir o driver DisplayLink em um pacote RPM para Fedora, CentOS Stream, Rocky Linux e AlmaLinux OS. Este driver oferece suporte às seguintes famílias de dispositivos:
O pacote inclui a biblioteca evdi de código aberto.
Os pacotes são criados automaticamente pelo GitHub Actions e carregados nas versões do GitHub.
NOTA: Agora pode ser construído de forma limpa por meio do arquivo .spec (em mock fe). Baixe arquivos via
make srpm.
Para criar o pacote rpm do driver, você pode executar o comando make no diretório com check-out. O Makefile deve baixar os arquivos necessários para você e criar um RPM.
Uma make padrão usará o driver evdi que acompanha o pacote de driver Displaylink. Se você precisar usar uma versão mais recente do repositório evdi Github e ela não estiver presente no pacote do driver Displaylink, você pode fazer isso executando:
make github-releasePara usar o displaylink-rpm e o módulo do kernel evdi com inicialização segura habilitada no Fedora, você precisa assinar o módulo com uma Chave do Proprietário da Máquina (MOK) registrada.
Antes de continuar, verifique se a inicialização segura está habilitada em seu sistema: mokutil --sb-state
Se a resposta for sim, continue com o guia abaixo, caso contrário, a inscrição no MOK não é necessária e você pode ignorar esta instrução.
A partir da versão 3.0.4 do DKMS não há necessidade de criar o MOK manualmente, o DKMS durante a instalação gera sua própria chave que precisa ser cadastrada apenas uma vez pelo usuário.
Para registrar a chave, siga estas instruções:
sudo dnf install mokutil dkms .mokutil --import /var/lib/dkms/mok.pub e siga as instruções de inscrição disponíveis na página do github do DKMS (será necessária a reinicialização do sistema).sudo dkms autoinstall para construir e assinar o módulo evdi pelo MOK.sudo dkms status ou sudo systemctl status displaylink-driver.service . Quando usado com a dock station Dell D6000, o DisplayLink 5.1.26 perde regularmente a comunicação com os monitores conectados, fazendo com que eles fiquem em branco e entrem no modo de economia de energia. No momento em que os monitores ficam em branco, o kernel registra duas mensagens de erro:
kernel: usb < xxx > : Disable of device-initiated U1 failed.
kernel: usb < xxx > : Disable of device-initiated U2 failed. Para contornar esse problema, desative o gerenciamento de energia do dispositivo de áudio comentando uma linha em /etc/pulse/default.pa :
# ## Automatically suspend sinks/sources that become idle for too long
# load-module module-suspend-on-idle Geralmente queremos rastrear a versão estável atual da biblioteca evdi. No entanto, os kernels do Fedora são muitas vezes muito mais recentes do que aqueles suportados oficialmente por essa versão e não é incomum que um novo kernel interrompa completamente a compilação. Isso pode deixá-lo em uma situação em que você não poderá atualizar seu kernel sem sacrificar seus dispositivos displaylink. Isso não é ótimo se o novo kernel tiver correções importantes de segurança ou desempenho.
Os desenvolvedores do evdi usam o branch main como branch principal para todas as alterações.
Para extrair o código mais recente do branch main e usá-lo para compilar, faça o seguinte:
make main
make github-release É claro que este ramo main também incluirá algumas mudanças experimentais e menos testadas que podem quebrar as coisas de outras maneiras inesperadas. Portanto, você deve preferir a compilação principal se funcionar, mas se quebrar, você terá a opção de fazer uma compilação main .
Se você estiver usando o Fedora Rawhide, você pode criar uma compilação que será baixada automaticamente do branch main e construída executando:
make rawhideNo passado, o código na ramificação
mainseria marcado e essa versão seria incluída no pacote do driver Displaylink.Recentemente, vimos alterações mais recentes aparecerem no pacote do driver Displaylink sem que a versão da biblioteca evdi fosse alterada. Isso criou alguma confusão e dificuldade quando se trata de atualizações de manutenção.
O pessoal da evdi reconheceu esse problema e está trabalhando para tornar o processo mais transparente.
A maneira mais fácil de contribuir com o pacote é bifurcá-lo e enviar uma solicitação pull no GitHub.
Existem dois tipos principais de contribuições: ou é lançada uma nova versão upstream ou é proposta uma modificação na embalagem.
Existe uma variável chamada RELEASE para fins de empacotamento. Essa variável deve ser definida como 1 ao contribuir com um novo lançamento de versão upstream e incrementada em um ao adicionar qualquer outra funcionalidade ao arquivo específico para a mesma versão upstream.
De tempos em tempos, o DisplayLink atualizará seu driver. Tentamos fazer isso, mas para isso normalmente contamos com pull requests.
Gerenciamos três números upstream diferentes para controle de versão:
Essas variáveis precisam ser alteradas nos seguintes locais:
DAEMON_VERSION é a versão do DisplayLinkManagerVERSION é atualmente a versão do driver evdiDOWNLOAD_ID é o parâmetro de consulta ?download_id= no site DisplayLink para baixar o zipAlém disso, atualize o changelog na parte inferior do arquivo displaylink.spec.
Ao alterar uma regra de empacotamento, aumente a variável RELEASE em um em displaylink.spec
