When certain SDL-based programs (e.g. prboom, dosbox) are run from the console (not X) and terminate abruptly for some reason (e.g. killed or segfaults), the screen locks up; It just goes black, and remains black until you reboot.

This is in contrast with the hello_video and hello_triangle demos which return the console to its original state even if they are terminated abruptly.

What exactly is going wrong here, and is there a way to recover it without rebooting?

I have observed this in Debian Squeeze. I do not know if other OSes are affected.

Edit: I should clarify only the console (HDMI/RCA output, USB keyboard) is affected, not ssh connections (which continue to work fine.)

  • Can you change to another tty be pressing alt+F1-5?
    – Jivings
    Jun 13, 2012 at 8:26
  • @Jivings, no, those key combinations have no effect.
    – finnw
    Jun 13, 2012 at 8:48
  • Hmm.. Can you use SysRq and the REISUB commands?
    – Jivings
    Jun 13, 2012 at 8:55
  • @Jivings no, but (1) Ability to reboot is not the problem: I can issue a shutdown command from a ssh connection and (2) I am looking for a solution that does not require rebooting.
    – finnw
    Jun 13, 2012 at 9:00
  • Oh ssh. Well in your ssh prompt you could kill the X server and restart. Or restart the runlevel.
    – Jivings
    Jun 13, 2012 at 9:01

2 Answers 2


This is almost certainly a bug in the graphics driver. It sounds as though SDL is initializing the graphics API, at which point the graphics driver takes over the display. Because you killed SDL it never ran the code to deinitialize the graphics API, and so it is just sitting waiting for graphics commands which will never come.

This indicates a badly designed graphics API, but because the entire thing is proprietary there is no way to know and no way to fix it.

(I have observed similar behaviour on a PC where SDL "grabs" the mouse pointer and does not ungrab it if it crashes or is killed, but never with the display.)

  • 1
    SDL has a "parachute" that it deploys normally to clean up even in the case of segfaults so something's not right still.
    – Flexo
    Jun 23, 2012 at 23:52
  • The parachute will only catch SIGSEGV, not SIGKILL. Jun 27, 2012 at 9:36
  • That's interesting, I'll have to try sending SIGKILL to one of the GLES2 demos and see what happens.
    – finnw
    Jun 27, 2012 at 13:39
  • I'm developing an SDL app in 2017 and there still seems to potentially be a bug with using CTRL-C to quit an SDL app. I had the problem that SDL and terminal input would gradually become unresponsive when I was testing the app, repeatedly running it and quitting with CTRL-C. I've found that if I quit the app properly from within the SDL app then I don't ever have the problem. Jun 1, 2017 at 4:23

I know this is a very old question, but I was running into a similar problem to this when running Mupen64Plus via EmulationStation. My console would show up fine, but the keyboard would be totally unresponsive until I performed a reboot.

The problem was that the keyboard was remaining in RAW mode after the program terminated. The solution was to add the following line to the end of the shell script that ran it: kbd_mode -a. This resets the keyboard to XLATE mode and enables it to work again.

While this doesn't resolve the "black screen" portion of the problem, I'm guessing there must be an analogous way to reset the console framebuffer to get video back.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.