Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.)

share|improve this question
Can you change to another tty be pressing alt+F1-5? – Jivings Jun 13 '12 at 8:26
@Jivings, no, those key combinations have no effect. – finnw Jun 13 '12 at 8:48
Hmm.. Can you use SysRq and the REISUB commands? – Jivings Jun 13 '12 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 '12 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 '12 at 9:01

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.)

share|improve this answer
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 '12 at 23:52
The parachute will only catch SIGSEGV, not SIGKILL. – Alistair Buxton Jun 27 '12 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 '12 at 13:39

I can t say what is the problem with the SDL app, but just typing :


should make the console usable again

share|improve this answer
...How's he supposed to type that if the console is unusable? – Jivings Jun 14 '12 at 12:15
What Jivings said. The keyboard is unresponsive AFACT, it's not just the screen. – finnw Jun 14 '12 at 12:25
And issuing this command from ssh (redirecting to /dev/tty1) did not help either. – finnw Jun 14 '12 at 12:33
You should delete your answer so you don't get neg-repped into oblivion – Alex L Jun 22 '12 at 6:23
As a bonus you'll get the peer pressure badge – David Sykes Jun 24 '12 at 8:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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