Edit, 2011-01-01: I should probably apologize at this point, because a clean and default reinstall made this problem disappear. Apparently it was a problem with my system configuration, somewhere. Sorry for the false alarm. 😳
It took me long enough, but I finally ran aground on that quirk between screen, mplayer and the framebuffer in Arch Linux.
I’ve had people e-mail me or leave questions here asking how to get around screen’s stranglehold on the framebuffer.
For the uninitiated, you can duplicate this … behavior … by building an Arch system, forcing it into a non-default framebuffer dimension, starting screen, then starting mplayer.
Just be prepared to cut the power on your machine, because mine locks completely each time.
Outside of screen though, mplayer seems to be working fine. It will even seek out the framebuffer on its own, without the
-vo fbdev flag, and play a movie normally.
But as for fixing that lockup … ?
To be honest, I don’t know. I need to experiment a little more. Right now the only way I know to get both screen and mplayer working well together is to include Xorg.
I know what you’re thinking: You’re thinking, “What … ?” It’s nutty, but if I start screen in a terminal emulator from within X, then start mplayer from there, I can force mplayer to the tty1 on the framebuffer.
Which is so completely bizarre as to be absolutely unuseful. I’ve heard of some wacky solutions to weird problems, but that is not a solution. Heck, that’s not even an option. But what can I say: It works.
And when I think about it, it does lend itself to a few interesting permutations. … 😈 Stay tuned. … 😀