Isso não responde exatamente à sua pergunta em si, mas é sem dúvida uma resposta tecnicamente correta, por isso estou aproveitando a formatação mais agradável oferecida às respostas, portanto, isso não é 30 comentários de parede de texto.
Você provavelmente não obterá uma resposta sobre SO / SE, porque simplesmente não há conhecimento suficiente sobre domínio específico. Você está muito melhor falando diretamente com os desenvolvedores do driver do kernel i915.
link contém muito instruções completas sobre como fazer isso em um maneira organizada.
A maneira como você redigiu o seu relatório de bug implica que /sys/class/drm/card0-DP-2/status existe quando você conecta um cabo DisplayPort após a inicialização, mas não quando um cabo e nenhuma tela estão conectados. Bem, qualquer coisa que envolva /sys/* definitivamente não é relacionada ao X11, e o drm no caminho confirma absolutamente que você quer seguir a seção 1.1 - DRM Kernel do link acima.
Eu dei uma olhada nos detalhes solicitados por aquela seção e estou razoavelmente confiante de que os bits impossíveis de entender não são realmente necessários. Dito isto, as informações do kernel e da distribuição, dmesg completo após a reinicialização com drm.debug=0xe , etc, são ideias muito boas.
Como é óbvio, dois dmesg s seriam logicamente apropriados aqui; um de uma bota sem o conector presente, e outro com. Pode ser muito útil anotar o ponto exato ou aproximado em que você realmente conectou o conector.
O pensamento de 5 minutos surgiu com uma maneira adequada e bem-sucedida de anotar:
script -c 'dmesg -w | cat' dmesg.txt
executará dmesg -w e também permitirá que você digite linhas de texto diretamente no terminal para adicionar anotações , e você poderá ^C quando terminar de coletar informações do dmesg. ( dmesg -w | cat é menor que dmesg -w --color=never .)
Uma coisa possivelmente improvável, apenas no caso: isso já funcionou? Se sim, você lembra que horas? Se sim, tente instalar versões antigas das distribuições usadas nesses pontos e, se elas funcionarem, colete as versões do kernel!
Além disso, você pode não querer ouvir isso, mas como sempre, não se pode ter 100% de certeza se, por má vontade, a versão mais recente do kernel não resolve tudo magicamente. :)
Felizmente, isso é muito menos assustador do que você pode temer: link é um clone inteiro do kernel do Linux com os adesivos de ponta de árvore já dobrados. Por melhor que eu possa dizer, apenas clone e construa isso e você deve estar pronto para ir.
... Dito isto, por uma questão de cautela, você pode querer baixar a versão mais recente do kernel e obter esse trabalho conhecido primeiro, e então copiar o .config para o drm-tip tree. Se você não fizer isso primeiro, e tudo explodir de lado, a verificação de que você pode criar e inicializar um kernel da linha principal pode ser uma boa primeira checagem de integridade.
Esta é a página do bugzilla que você deseja: link
Na verdade, isso quase certamente mostrará a você uma visualização de login; Nesse caso, você desejará primeiro este URL: link
Finalmente, se você quiser fazer perguntas, o link menciona # gfx-intel no freenode.
FWIW, o que descrevi acima é um conjunto ideal de etapas. Você pode abrir um bug provisório no freedesktop.org antes de, por exemplo, ir e fazer uma reconstrução do kernel para descobrir se não há outras etapas de depuração que você possa tentar. (A página de entrada de bugs lista apenas "drm git" na seção de versão, então, eles realmente querem você usando a versão git ... heh)
Na verdade, tenho uma boa pergunta para o canal do IRC - listei o drm-tip git repo porque é esse que a documentação menciona, mas há também um drm-intel repo e não sei qual é a relevância dele . Ele também se parece com uma árvore de kernel e está sendo atualizado a cada poucos minutos também.