[12:00] <mterry> RAOF: you there?  Did you ever dig into Mir and VT switching?
[12:01] <RAOF> mterry: Yes; we want you to enable a Mir report and reproduce the bug.
[12:01] <mterry> RAOF: can do
[12:01] <mterry> RAOF: which report?
[12:01] <mterry> RAOF: you think it's Mir's fault after all then?
[12:01] <RAOF> mterry: No.
[12:02] <RAOF> mterry: MIR_SERVER_DISPLAY_REPORT=log is your winner, I belive.
[12:02] <mterry> Dang it, it would have been easier if it was Mir's fault
[12:02] <mterry> RAOF: ok will do that
[12:02] <RAOF> mterry: The hypothesis is that Mir fails to drop master for whatever reason, which results in it (correctly) NAKing the VT switch.
[12:03] <RAOF> (We call drmDropMaster, but that can fail; if it does, we throw an exception, (silently) catch it, and NAK the VT switch)
[12:51] <mterry> RAOF: http://paste.ubuntu.com/23348320 -- I set the env, but don't see much about display output, doesn't seem like a useful log
[13:10] <mterry> RAOF: I assigned this bug to you (but just as a point of contact, please re-assign or unassign as you see fit): https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1634888
[13:10] <ubot5`> Ubuntu bug 1634888 in mir (Ubuntu) "Problems switching VTs" [Undecided,New]
[13:17] <RAOF> mterry: OK.
[13:17] <mterry> RAOF: if it is drmDropMaster mysteriously failing, is that a driver bug?
[13:18] <RAOF> mterry: So, that shows that Mir is successfully calling drmDropMaster(), which means that it's probably someone else's bug.
[13:19] <mterry> RAOF: you mean there's a lack of an error message?  :)
[13:19] <RAOF> Yes :)
[13:19] <RAOF> It would say failed to drop master :)
[13:22] <mterry> I guess I'll go back to robert and see if he thinks lightdm could be botching the hand off