[MPlayer-users] Does this seem like an mplayer bug?

[Reimar Döffinger]

On 25.08.2013, at 14:48, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> On Sun, Aug 25, 2013 at 02:26:43PM +0200, Reimar Döffinger wrote:
>> On Mon, Aug 19, 2013 at 08:41:51AM -0400, Tom Horsley wrote:
>>> I finally tracked down a mysterious bug this weekend, which turns
>>> out to be triggered by mplayer when run with no $DISPLAY like
>>> so:
>>> 
>>> unset DISPLAY
>>> mplayer -identify -frames 0 trunc.mpg
>>> 
>>> My GUI display disappears and is replaced with the contents
>>> of the VT1 terminal leftover from before X started. This
>>> happened when it opened /dev/fb0 and did some ioctl operations.
>> 
>> I think that is kind of intended.
>> But could you provide a full MPlayer log?
>> So I at least know if it's the fbdev, fbdev2 etc.
>> Using ATI fglrx drivers I cannot reproduce such an issue with either
>> of them, but it might be specific to Intel driver or so.
> 
> Also, I suspect that nothing actually went wrong at the point where your
> screen went black.
> Maybe you could try actually playing a video.
> I suspect the real issue happens at the very end, when MPlayer does:
> ioctl(fb_tty_fd, KDSETMODE, KD_TEXT)
> in order to switch "back" to text mode.
> You could try commenting out all of those.
> In case this is the cause, I suspect we should actually call KDGETMODE and not
> do those ioctls when the mode is already graphics.
> Also I wonder, why can MPlayer even do this? /dev/tty should not be
> available to ordinary users. Are you running it as root from cron?
> That is a really, really, bad idea.

Actually, this also happens with fbdev2 which does not do any of these questionable things.
It seems to me, that on KMS systems /dev/fb0 is connected to VT0.
Changing its video seems to result in the VT0 frame buffer to be displayed, even though VT0 is not active (which is why you cannot just switch back to the X11 VT, you first need to switch away from it and back again).
This already seems like a bug to me.
Even if it wasn't, when the mode is reset and the file is closed, it should at least restore things again.
I don't think MPlayer destroys any state that it forgets to reset, it rather looks to me like the driver just messes up and confuses its virtual terminals when an application tries to use /dev/fb0.