Konsola nie nadaje się do użytku po uruchomieniu aplikacji SDL

Kiedy niektóre programy oparte na SDL (np. Prboom , dosbox ) są uruchamiane z konsoli (nie X) i nagle kończą się z jakiegoś powodu (np. Zabity lub segfault), ekran się blokuje; Po prostu robi się czarny i pozostaje czarny, dopóki nie uruchomisz się ponownie.

Jest to w przeciwieństwie do wersji demonstracyjnych hello_video i hello_triangle, które przywracają konsolę do pierwotnego stanu, nawet jeśli zostaną nagle przerwane.

Co dokładnie dzieje się tutaj źle i czy istnieje sposób na odzyskanie go bez ponownego uruchamiania?

Zauważyłem to w Debian Squeeze . Nie wiem, czy dotyczy to innych systemów operacyjnych.

Edycja : Powinienem wyjaśnić, że dotyczy to tylko konsoli (wyjście HDMI / RCA, klawiatura USB), a nie połączeń ssh (które nadal działają dobrze).

terminal sdl debian

— finnw
źródło

Czy możesz przejść na inny naciskający przycisk alt+F1-5?

— Jivings

@ Jivings, nie, te kombinacje klawiszy nie działają.

— finnw

Hmm .. Czy możesz używać poleceń SysRq i REISUB ?

— Jivings

@ Jivings nie, ale (1) Problemem nie jest możliwość ponownego uruchomienia: mogę wydać polecenie zamknięcia z połączenia ssh i (2) szukam rozwiązania, które nie wymaga ponownego uruchomienia.

— finnw

Oh ssh. W twoim poleceniu ssh możesz zabić serwer X i uruchomić ponownie. Lub uruchom ponownie poziom działania.

— Jivings

Odpowiedzi:

To prawie na pewno błąd w sterowniku graficznym. Wygląda na to, że SDL inicjuje graficzny interfejs API, w którym momencie sterownik graficzny przejmuje wyświetlanie. Ponieważ zabiłeś SDL, nigdy nie uruchomił kodu w celu deinicjalizacji interfejsu API grafiki, więc czeka tylko na polecenia graficzne, które nigdy nie nadejdą.

Wskazuje to na źle zaprojektowany graficzny interfejs API, ale ponieważ cała sprawa jest zastrzeżona, nie ma sposobu, aby to wiedzieć i jak to naprawić.

(Zauważyłem podobne zachowanie na komputerze, na którym SDL „chwyta” wskaźnik myszy i nie chwyta go, jeśli się zawiesi lub zostanie zabity, ale nigdy z wyświetlaczem.)

— Alistair Buxton
źródło

SDL ma „spadochron”, który rozkłada się normalnie, aby wyczyścić nawet w przypadku awarii, więc coś jest nie tak.

— Flexo

Spadochron złapie tylko SIGSEGV, a nie SIGKILL.

— Alistair Buxton

To ciekawe, będę musiał spróbować wysłać SIGKILLjeden z pokazów GLES2 i zobaczyć, co się stanie.

— finnw

Tworzę aplikację SDL w 2017 roku i nadal wydaje się, że może występować błąd w używaniu CTRL-C do zamykania aplikacji SDL. Miałem problem polegający na tym, że SDL i dane wejściowe terminala stopniowo przestały odpowiadać, gdy testowałem aplikację, wielokrotnie ją uruchamiając i wychodząc z CTRL-C. Przekonałem się, że jeśli poprawnie zamknę aplikację z poziomu aplikacji SDL, nigdy nie będę mieć problemu.

— Paul Slocum

Wiem, że to bardzo stare pytanie, ale miałem problem podobny do tego, kiedy działałem Mupen64Plus przez EmulationStation. Moja konsola pokazałaby się dobrze, ale klawiatura nie reagowałaby do momentu ponownego uruchomienia.

Problem polegał na tym, że klawiatura pozostawała w trybie RAW po zakończeniu programu. Rozwiązaniem było dodać następującą linię do końca skrypt powłoki, który go prowadził: kbd_mode -a. Spowoduje to zresetowanie klawiatury do trybu XLATE i ponowne jej uruchomienie.

Chociaż nie rozwiązuje to problemu „czarnego ekranu”, domyślam się, że musi istnieć analogiczny sposób zresetowania bufora ramki konsoli, aby odzyskać wideo.

— glindsey1979
źródło

-5

Nie mogę powiedzieć, na czym polega problem z aplikacją SDL, ale po prostu wpisuję:

reset

powinien sprawić, że konsola będzie znów użyteczna

— neofutur
źródło

... Jak powinien to napisać, jeśli konsola jest bezużyteczna?

— Jivings

Co powiedział Jivings. Klawiatura nie reaguje AFACT, to nie tylko ekran.

— finnw

Wydanie tego polecenia z ssh (przekierowanie do / dev / tty1) również nie pomogło.

— finnw

Powinieneś usunąć swoją odpowiedź, abyś nie został odrzucony w zapomnienie

— Alex L

Jako bonus otrzymasz odznakę presji rówieśniczej

— David Sykes,