We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

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.

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

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.

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

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

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.

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

Created attachment 93 [details]
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?

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

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.

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

--ryan.

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

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

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.

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