This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• fbcon-nonblocking-switch.diff (fbcon-nonblocking-switch.diff, text/plain, 2006-03-23 03:33:47 +0000, 9607 bytes)

Reported in version: HG 1.2
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-19 04:05:37 +0000, Ryan C. Gordon wrote:

Originally mentioned in Bug # 37 ...

"By the way, does anyone know why SDL freezes the application when switched away using fbcon? It could catch a signal for flipping back, and provide a fake frame buffer at a fixed position so that the application can work in the background."

I like the idea, and would be inclined to also post SDL_ACTIVEEVENT events to the SDL app when switching to/from the SDL-controlled virtual terminal.

--ryan.

On 2006-01-27 11:23:16 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-03-22 02:53:17 +0000, Sam Lantinga wrote:

Out of curiousity, how would we handle the application setting a new video mode while switched away?

On 2006-03-22 03:53:30 +0000, Ryan C. Gordon wrote:

This is why I changed this back from ASSIGNED to NEW. :)

We could spend a lot of time emulating the surface and switching as appropriate, including rebuilding a shadow surface behind the scenes if the vidmode changes.

I think it's possible, but after thinking about it, I'm wondering if it's worth the effort.

--ryan.

On 2006-03-22 04:44:58 +0000, Sam Lantinga wrote:

(In reply to comment # 3)

I think it's possible, but after thinking about it, I'm wondering if it's worth
the effort.

Doesn't seem like it to me.

It would be relatively easy to support switching away as long as the video mode isn't changed, but a completely bulletproof system would be really hard to do.

Here are some notes in case anybody is interested:

• At video mode set, we'd need to lock the video mode switch.
• In switch_vt(), we'd just need to keep the saved memory around, set a global variable inside the hw_lock, unlock the vt switch, send an APPACTIVE event, and return.
• In all code that accesses video memory, we need to check that variable (inside the lock) and return if the switched away variable was true.
• If the video mode is resized while switched away, I think maybe failing the mode switch is the best way to go.
• In the event handling code, if we're switched away, lock hw_lock, check to see if we've switched back. If so, relock the vt switch, restore the saved memory, send an APPACTIVE event, clear the global variable, and return.

All in all, pretty easy if we can say that setting a video mode fails. :)

On 2006-03-22 04:48:48 +0000, Sam Lantinga wrote:

Actually, nevermind, we already block in the video mode setting code, until we can set the current vt.

Heheh, it sounds like this would be fairly easy to do... I just hope everybody is checking their return codes. :)

On 2006-03-22 04:53:51 +0000, Ryan C. Gordon wrote:

Dereferencing a NULL pointer is the ultimate return code check. :)

If you think it's trivial and worth doing, feel free to reassign this one to yourself. I'm busy fighting with Xrandr at the moment.

--ryan.

On 2006-03-22 04:56:21 +0000, Sam Lantinga wrote:

You got it. Thanks for tangling with XRandR, btw. :)

On 2006-03-23 03:33:47 +0000, Sam Lantinga wrote:

Created attachment 93
fbcon-nonblocking-switch.diff

Here's a patch to add non-blocking VT switch support. I don't have a working fb at the moment, so could you check it out and apply it if it's good?

On 2006-03-23 03:39:21 +0000, Sam Lantinga wrote:

Whoops, forgot the APPACTIVE stuff. Can you add that while you're at it?

On 2006-03-23 04:11:17 +0000, Ryan C. Gordon wrote:

In switch_vt_done(), should we call SDL_UpdateRect() in all cases? Right now we don't update the display on the return to the SDL VT, so testsprite.c is rendering over the contents of the VT that I switched away to, once I return.

--ryan.

On 2006-03-23 04:25:22 +0000, Ryan C. Gordon wrote:

Also, we'll need to clear the border if the logical resolution is smaller than the physical resolution.

--ryan.

On 2006-05-08 01:32:54 +0000, Sam Lantinga wrote:

This patch, with the addition of always saving/restoring the video memory and the addition of appactive events, is now in Subversion.

On 2006-05-08 01:33:51 +0000, Sam Lantinga wrote:

Just for the record, we should also probably save and restore the entire hardware surface memory pool... Maybe that should be a separate bug?

On 2006-05-10 00:46:32 +0000, Ryan C. Gordon wrote:

If we're going to do that, shouldn't we do it for DirectX, too, and remove the notes about BlitSurface() returning -2 from the docs? If you want to do that, yeah, seperate bug, but I don't know that it's worth it, honestly.

--ryan.

On 2006-05-10 01:06:56 +0000, Sam Lantinga wrote:

(In reply to comment # 14)

If we're going to do that, shouldn't we do it for DirectX, too, and remove the
notes about BlitSurface() returning -2 from the docs? If you want to do that,
yeah, seperate bug, but I don't know that it's worth it, honestly.

DirectX doesn't give you a warning - you can lose surfaces at any time. With the framebuffer console, we're in control, and can do any saving/restoring necessary behind the scenes. Anyway, punting for now.