This set of patches rearranges how we handle events on the OSX Cocoa UI so that we use the main thread to run the OSX event loop, and we don't do a long blocking operation from the applicationDidFinishLaunching callback. Instead we create a second thread which runs qemu_main() and becomes the QEMU main-loop thread. The callbacks from QEMU into the cocoa code asynchronously dispatch their work to the main thread, and the main thread takes the iothread lock before calling into QEMU code.
NB: the code to asynchronously run code blocks on the main thread uses dispatch_get_main_queue(), which is a 10.10-or-later function. I think the benefit in clarity-of-code is a worthwhile gain for dropping support for ancient OSX versions. The change from v1 is that we actually wire up input events from OSX to the handleEvent method. There are a couple of plausible ways we could do this: * most OSX apps do this by implementing event handling methods on their NSView. This won't work for us, because these only get called after OSX has dealt with some events like menu bar accelerator keystrokes, and we would like to send those to the guest instead in some situations. * we could use addLocalMonitorForEventsMatchingMask to add a "local event monitor", which gets to examine/filter events before the usual OSX event processing. I think this would work, but it's not what I chose * we can subclass NSApplication and implement a custom sendEvent method in our subclass. This gets all events first and can either handle them or call the superclass sendEvent to hand them to OSX as usual. This is what I ended up going for. * It is also possible to implement sendEvent on NSWindow, but I think this has the "only called after OSX has done menu keystroke processing" issue. I've tested this a bit better than the v1 RFC, and it seems to work OK for me. Patchset structure: * patch 1 does the "make sure we have the iothread lock for calls into QEMU" (which is effectively a no-op initially since we'll already be holding that lock when our refresh etc callbacks are called) * patch 2 makes switchSurface directly take the pixman image (which is refcounted) rather than the DisplaySurface (which is not), so we can make the calls to it asynchronous later * patches 3 and 4 are just trivial code motion * patch 5 (new in v2) restructures handleEvent so it doesn't directly call sendEvent but instead returns a flag indicating whether it consumed the event or not * patch 6 (new in v2) subclasses NSApplication * patch 7 (the old patch 5) does the bulk of the work (and can't really be split further without the UI being broken at the intermediate point) thanks -- PMM Peter Maydell (7): ui/cocoa: Ensure we have the iothread lock when calling into QEMU ui/cocoa: Use the pixman image directly in switchSurface ui/cocoa: Factor out initial menu creation ui/cocoa: Move console/device menu creation code up in file ui/cocoa: Don't call NSApp sendEvent directly from handleEvent ui/cocoa: Subclass NSApplication so we can implement sendEvent ui/cocoa: Perform UI operations only on the main thread ui/cocoa.m | 483 ++++++++++++++++++++++++++++++++--------------------- 1 file changed, 294 insertions(+), 189 deletions(-) -- 2.17.2 (Apple Git-113)
