VT switching is broken

[AlanGriffiths]

On Bionic and Artful using ppa:mir-team/dev, or ppa:mir-team/release

1. run miral-desktop
2. Ctrl-Alt-F2 switches back to VT2
3. Ctrl-Alt-F4

Expect: switch back to VT4
Actual: nothing, and now input doesn't work at all

[AlanGriffiths]

Actually, using Mir 0.28 from the Artful archive I still see this.

I don't think this can be simply a Mir issue, we'd have seen it long ago.

[gerboland]

I can repro on 18.04 and Mir 0.31.1

Watching logs as I VT switch: https://pastebin.ubuntu.com/p/P9gCGnZPRN/
GDB after hang: https://pastebin.ubuntu.com/p/25n6J9RGFw/

[wmww]

Fun fact: If you go [normal desktop -> Miral Desktop -> normal desktop -> another VT -> Miral Desktop] there is no problem. It doesn't if you're logged in on "another VT" or not.

[AlanGriffiths]

@RAOF I guess you are the best person to investigate this?

[RAOF]

Yup! Sign me up for some two-machine debugging sessions next week!

…

-------- Original Message --------

On 18 May 2018, 18:14, Alan Griffiths wrote: ***@***.***(https://github.com/RAOF) I guess you are the best person to investigate this? — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#373 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AAxF82EKs5Ezz6FsRjOC_9Net0eszHBKks5tzoLngaJpZM4UCyIy).

[RAOF]

Harumph.

Conveniently, this is a race somewhere in VT handling; if gdb stops the server upon receiving the SIGUSR1 signal everything works fine.

Presumably this means that we're trying to use something before it's been fully released by the thing we're switching from. This might actually be a bug in Xorg or logind; the switchee is meant to have released all resources from their VT switch signal already…

[RAOF]

Oh, huh.

So, the problem here is that our drmSetMaster() call is falling.

Additional problems:

• It seems that the VT subsystem doesn't properly handle failing to resume
• There's no mechanism to refuse a switch-to, so we should be retrying for a while and then dying hard
• We print absolutely nothing in this situation.

[AlanGriffiths]

Yes, this seems to be a race. I hacked mgm::Display::resume() with a std::this_thread::sleep_for(std::chrono::milliseconds{100}) at the top and the problem was nicely hidden. I'll try to get a PR (with production code) together later.