Console inutilizzabile dopo aver eseguito l'app SDL

Quando alcuni programmi basati su SDL (ad esempio prboom , dosbox ) vengono eseguiti dalla console (non X) e terminano bruscamente per qualche motivo (ad esempio, uccisi o segfault), lo schermo si blocca; Diventa solo nero e rimane nero fino al riavvio.

Ciò è in contrasto con le demo hello_video e hello_triangle che riportano la console al suo stato originale anche se vengono interrotte bruscamente.

Cosa non va esattamente qui e c'è un modo per recuperarlo senza riavviare?

L'ho osservato in Debian Squeeze . Non so se altri sistemi operativi sono interessati.

Modifica : dovrei chiarire che solo la console (uscita HDMI / RCA, tastiera USB) è interessata, non le connessioni ssh (che continuano a funzionare correttamente).

terminal sdl debian

— finnw
fonte

Puoi passare ad un altro tty premendo alt+F1-5?

— Jivings,

@Jivings, no, quelle combinazioni di tasti non hanno alcun effetto.

— Finnw,

Hmm .. Puoi usare SysRq e i comandi REISUB ?

— Jivings,

@Jivings no, ma (1) La possibilità di riavviare non è il problema: posso emettere un comando di spegnimento da una connessione ssh e (2) sto cercando una soluzione che non richiede il riavvio.

— fin

Oh ssh. Bene, nel tuo prompt ssh potresti uccidere il server X e riavviare. O riavviare il runlevel.

— Jivings,

Risposte:

Questo è quasi certamente un bug nel driver grafico. Sembra che SDL stia inizializzando l'API grafica, a quel punto il driver grafico prende il controllo del display. Poiché hai eliminato SDL, non ha mai eseguito il codice per deinizializzare l'API grafica, quindi rimane semplicemente in attesa di comandi grafici che non arriveranno mai.

Ciò indica un'API grafica mal progettata, ma poiché l'intera cosa è proprietaria non c'è modo di saperlo e di non risolverlo.

(Ho osservato un comportamento simile su un PC in cui SDL "afferra" il puntatore del mouse e non lo strappa se si blocca o viene ucciso, ma mai con il display.)

— Alistair Buxton
fonte

SDL ha un "paracadute" che schiera normalmente per ripulire anche in caso di segfault, quindi qualcosa non va ancora bene.

— Flexo,

Il paracadute cattura solo SIGSEGV, non SIGKILL.

— Alistair Buxton,

È interessante, dovrò provare a inviare SIGKILLa una delle demo GLES2 e vedere cosa succede.

— finnw,

Sto sviluppando un'app SDL nel 2017 e sembra che ci sia ancora potenzialmente un bug con l'utilizzo di CTRL-C per uscire da un'app SDL. Ho avuto il problema che SDL e l'input del terminale diventavano gradualmente non rispondenti mentre stavo testando l'app, eseguendola ripetutamente e chiudendo con CTRL-C. Ho scoperto che se ho chiuso l'app correttamente dall'app SDL, non avrei mai avuto il problema.

— Paul Slocum,

So che questa è una domanda molto vecchia, ma stavo riscontrando un problema simile a questo durante l'esecuzione di Mupen64Plus tramite EmulationStation. La mia console si presenterebbe bene, ma la tastiera non risponderebbe completamente fino a quando non eseguirò un riavvio.

Il problema era che la tastiera rimaneva in modalità RAW dopo la fine del programma. La soluzione era quella di aggiungere la seguente riga alla fine dello script di shell che lo gestisce: kbd_mode -a. Ciò reimposta la tastiera in modalità XLATE e le consente di funzionare nuovamente.

Anche se questo non risolve la parte "problema dello schermo nero", suppongo che ci debba essere un modo analogo per ripristinare il framebuffer della console per ripristinare il video.

— glindsey1979
fonte

-5

Non posso dire quale sia il problema con l'app SDL, ma semplicemente digitando:

reset

dovrebbe rendere la console nuovamente utilizzabile

— neofutur
fonte

... Come dovrebbe digitarlo se la console è inutilizzabile?

— Jivings,

Quello che ha detto Jivings. La tastiera non risponde AFACT, non è solo lo schermo.

— finnw,

E nemmeno emettere questo comando da ssh (reindirizzamento a / dev / tty1) non ha aiutato.

— finnw,

Devi eliminare la tua risposta in modo da non farti trascinare nell'oblio

— Alex L

Come bonus otterrai il badge della pressione dei pari

— David Sykes,