All the info is attached to this redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=958326 Turns out that running mplayer (at least on one particular video file) with no $DISPLAY tries (I think) to fallback on the low level frame buffer device. When it does a couple of ioctl calls on /dev/fb0, the X11 display gets hidden and replaced with the old contents of the VT1 console buffer (but I'm not actually switched to that console, typing has no effect). Doing Ctrl-Alt-F2 then Ctrl-Alt-F1 gets the X11 display back to normal and nothing except my eyeballs seems to be aware that anything unusual happened. No log entries are made of any kind. This is on a fedora 19 system with this version of the intel drivers from the fedora repos. I have no idea how to correlate this with the driver versions here at freedesktop :-). xorg-x11-drv-intel-2.21.12-2.fc19.x86_64 I also have a long description of finding this bug at: http://home.comcast.net/~tomhorsley/game/heisenbug.html This seems like a real bug to me. I wouldn't think this should happen (especially with all the mode setting code now residing in kernel drivers), but maybe you will disagree. It is simple to work around once found, just add the "-vo null" argument to the mplayer command like so it doesen't try to talk to any video device.
At a guess, fbdev is restoring the fbcon irrespective of the current VT.
Maybe this is really an mplayer bug? Now that I know how to reproduce it, I tried it on my system at work which has ATI drivers and the same thing happens. xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19.x86_64
It's certainly a core drm issue (or at least an issue with the fbdev emulation helpers all kms drivers are using). Generally the interaction between the kms apis (as used by X) and the legacy fbdev support (as used by mplayer) are a bit hazy ... Atm I don't have a good idea what's really going on and whether we should fix anything. But I guess keeping this report around can't really hurt.
I asked over on the mplayer mailing list if they think it is an mplayer bug (perhaps it isn't restoring things properly with the -frames 0 option). Be interesting to see the response: http://lists.mplayerhq.hu/pipermail/mplayer-users/2013-August/086515.html
mplayer performs a VT switch, you own the console at that point, so are allowed to do so. Then mplayer finds itself without permission to write to the fb0 or make further changes to the tty, and plays dead. So this doesn't seem like an accident.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.