Console inutilizável após a execução do aplicativo SDL

Quando certos programas baseados em SDL (por exemplo , prboom , dosbox ) são executados no console (não o X) e terminam abruptamente por algum motivo (por exemplo, interrupções ou falhas), a tela é bloqueada; Ele fica preto e permanece preto até você reiniciar.

Isso contrasta com as demos hello_video e hello_triangle, que retornam o console ao seu estado original, mesmo que sejam encerradas abruptamente.

O que exatamente está errado aqui e existe uma maneira de recuperá-lo sem reiniciar?

Eu observei isso no Debian Squeeze . Não sei se outros sistemas operacionais são afetados.

Editar : devo esclarecer apenas o console (saída HDMI / RCA, teclado USB) é afetado, não as conexões ssh (que continuam funcionando bem).

terminal sdl debian

— finnw
fonte

Você pode mudar para outro tty pressionando alt+F1-5?

— Jivings

@Jivings, não, essas combinações de teclas não têm efeito.

— finnw

Hmm .. Você pode usar o SysRq e os comandos REISUB ?

— Jivings

@Jivings não, mas (1) a capacidade de reiniciar não é o problema: posso emitir um comando de desligamento de uma conexão ssh e (2) estou procurando uma solução que não exija reinicialização.

— finnw

Oh ssh. Bem, no seu prompt ssh, você pode matar o servidor X e reiniciar. Ou reinicie o nível de execução.

— Jivings

Respostas:

Este é quase certamente um bug no driver gráfico. Parece que o SDL está inicializando a API gráfica, momento em que o driver gráfico assume a exibição. Como você matou o SDL, ele nunca executou o código para desinicializar a API de gráficos e, portanto, fica esperando os comandos gráficos que nunca virão.

Isso indica uma API gráfica mal projetada, mas como a coisa toda é proprietária, não há como saber e nem como corrigi-lo.

(Observei um comportamento semelhante em um PC em que o SDL "agarra" o ponteiro do mouse e não o desmarca se ele travar ou for morto, mas nunca com a tela.)

— Alistair Buxton
fonte

O SDL possui um "pára-quedas" que ele implementa normalmente para limpar, mesmo no caso de segfaults, para que algo não esteja certo ainda.

— Flexo

O paraquedas só pega SIGSEGV, não SIGKILL.

— Alistair Buxton

Isso é interessante, vou tentar enviar SIGKILLpara uma das demos do GLES2 e ver o que acontece.

— finnw

Estou desenvolvendo um aplicativo SDL em 2017 e ainda parece haver um erro ao usar o CTRL-C para sair de um aplicativo SDL. Eu tive o problema de que a entrada SDL e terminal gradualmente deixaria de responder quando eu estava testando o aplicativo, executando-o repetidamente e saindo com o CTRL-C. Descobri que, se eu sair do aplicativo corretamente de dentro do aplicativo SDL, nunca mais terei o problema.

— Paul Slocum

Sei que essa é uma pergunta muito antiga, mas estava com um problema semelhante ao executar o Mupen64Plus via EmulationStation. Meu console aparecia bem, mas o teclado não respondia totalmente até eu executar uma reinicialização.

O problema era que o teclado permanecia no modo RAW após o término do programa. A solução foi adicionar a seguinte linha ao final do shell script que ele correu: kbd_mode -a. Isso redefine o teclado para o modo XLATE e permite que ele funcione novamente.

Embora isso não resolva a parte "tela preta" do problema, acho que deve haver uma maneira análoga de redefinir o buffer de quadros do console para recuperar o vídeo.

— glindsey1979
fonte

-5

Não posso dizer qual é o problema com o aplicativo SDL, mas apenas digitando:

reset

deve tornar o console utilizável novamente

— neofutur
fonte

... Como ele deve digitar isso se o console for inutilizável?

— Jivings

O que Jivings disse. O teclado não responde, não é apenas a tela.

— finnw

E emitir este comando do ssh (redirecionando para / dev / tty1) também não ajudou.

— finnw

Você deve excluir a sua resposta para que você não se neg-repped no esquecimento

— Alex L

Como um bônus você obterá o emblema pressão dos colegas

— David Sykes