This provides standard look and feel for the about panel and reduces
code.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-id: 20220227042241.1543-1-akihiko.odaki@gmail.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Services menu functionality of Cocoa is described at:
https://developer.apple.com/design/human-interface-guidelines/macos/extensions/services/
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220214091320.51750-1-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In commit 6e657e64cd in 2013 we added some autorelease pools to
deal with complaints from macOS when we made calls into Cocoa from
threads that didn't have automatically created autorelease pools.
Later on, macOS got stricter about forbidding cross-thread Cocoa
calls, and in commit 5588840ff7 we restructured the code to
avoid them. This left the autorelease pool creation in several
functions without any purpose; delete it.
We still need the pool in cocoa_refresh() for the clipboard related
code which is called directly there.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Tested-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-id: 20220224101330.967429-3-peter.maydell@linaro.org
The updateUIInfo method makes Cocoa API calls. It also calls back
into QEMU functions like dpy_set_ui_info(). To do this safely, we
need to follow two rules:
* Cocoa API calls are made on the Cocoa UI thread
* When calling back into QEMU we must hold the iothread lock
Fix the places where we got this wrong, by taking the iothread lock
while executing updateUIInfo, and moving the call in cocoa_switch()
inside the dispatch_async block.
Some of the Cocoa UI methods which call updateUIInfo are invoked as
part of the initial application startup, while we're still doing the
little cross-thread dance described in the comment just above
call_qemu_main(). This meant they were calling back into the QEMU UI
layer before we'd actually finished initializing our display and
registered the DisplayChangeListener, which isn't really valid. Once
updateUIInfo takes the iothread lock, we no longer get away with
this, because during this startup phase the iothread lock is held by
the QEMU main-loop thread which is waiting for us to finish our
display initialization. So we must suppress updateUIInfo until
applicationDidFinishLaunching allows the QEMU main-loop thread to
continue.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Tested-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-id: 20220224101330.967429-2-peter.maydell@linaro.org
setAllowedFileTypes is deprecated in macOS 12.
Per Akihiko Odaki [*]:
An image file, which is being chosen by the panel, can be a
raw file and have a variety of file extensions and many are not
covered by the provided list (e.g. "udf"). Other platforms like
GTK can provide an option to open a file with an extension not
listed, but Cocoa can't. It forces the user to rename the file
to give an extension in the list. Moreover, Cocoa does not tell
which extensions are in the list so the user needs to read the
source code, which is pretty bad.
Since this code is harming the usability rather than improving it,
simply remove the [NSSavePanel allowedFileTypes:] call, fixing:
[2789/6622] Compiling Objective-C object libcommon.fa.p/ui_cocoa.m.o
ui/cocoa.m:1411:16: error: 'setAllowedFileTypes:' is deprecated: first deprecated in macOS 12.0 - Use -allowedContentTypes instead [-Werror,-Wdeprecated-declarations]
[openPanel setAllowedFileTypes: supportedImageFileTypes];
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSavePanel.h:215:49: note: property 'allowedFileTypes' is declared deprecated here
@property (nullable, copy) NSArray<NSString *> *allowedFileTypes API_DEPRECATED("Use -allowedContentTypes instead", macos(10.3,12.0));
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSSavePanel.h:215:49: note: 'setAllowedFileTypes:' has been explicitly marked deprecated here
FAILED: libcommon.fa.p/ui_cocoa.m.o
[*] https://lore.kernel.org/qemu-devel/4dde2e66-63cb-4390-9538-c032310db3e3@gmail.com/
Suggested-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20220215080307.69550-11-f4bug@amsat.org
Reviewed by: Cameron Esfahani <dirty@apple.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Tested-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A remote client, such as Spice, will already avoid flooding the stream
by delaying the resize requests.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Use a QemuClipboardNotify union type for extendable clipboard events.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
ui/cocoa used to call exit immediately after calling
qemu_system_shutdown_request, which prevents QEMU from actually
perfoming system shutdown. Just sleep forever, and wait QEMU to call
exit and kill the Cocoa thread.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210219111652.20623-1-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ui/cocoa deassociates the mouse input and the mouse cursor
position only when relative movement inputs are expected. Such
inputs may let the mouse cursor leave the view and cause undesired
side effects if they are associated. On the other hand, the
problem does not occur when inputting absolute points, and the
association allows seamless cursor movement across views.
However, the synchronization of the association and the expected
input type was only done when grabbing the mouse. In reality, the
state whether the emulated input device expects absolute pointing
inputs or relative movement inputs can vary dynamically due to
USB device hot-plugging, for example.
This change adds association state updates according to input type
expectation changes. It also removes an internal flag representing
the association state because the state can now be determined with
the current input type expectation and it only adds the
complexity of the state tracking.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210222150714.21766-1-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ui/cocoa does not receive NSEventTypeFlagsChanged when it is not active,
and the modifier state can be desynchronized in such a situation.
[NSEvent -modifierFlags] tells whether a modifier is *not* pressed, so
check it whenever receiving an event and clear the modifier if it is not
pressed.
Note that [NSEvent -modifierFlags] does not tell if a certain modifier
*is* pressed because the documented mask for [NSEvent -modifierFlags]
generalizes left shift and right shift, for example. CapsLock is the
only exception. The pressed state is synchronized only with
NSEventTypeFlagsChanged.
This change also removes modifier keys from keycode map. If they
are input with NSEventTypeKeyDown or NSEventTypeKeyUp, it leads to
desynchronization. Although such a situation is not observed, they are
removed just in case.
Moreover, QKbdState is introduced for automatic key state tracking.
Thanks to Konstantin Nazarov for testing and finding a bug in this
change:
https://gist.github.com/akihikodaki/87df4149e7ca87f18dc56807ec5a1bc5#gistcomment-3659419
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210310144602.58528-1-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The first argument of the executable was used to get its path, but it is
not reliable because the executer can specify any arbitrary string. Use the
interfaces provided by QEMU and the platform to get those paths.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210309122226.23117-2-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
kCGColorSpaceGenericRGB | Apple Developer Documentation
https://developer.apple.com/documentation/coregraphics/kcgcolorspacegenericrgb
> Deprecated
> Use kCGColorSpaceSRGB instead.
This change also removes the legacy color space specification for
PowerPC.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210305121304.65096-1-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
A display can receive an image which its stride is greater than its
width. In fact, when a guest requests virtio-gpu to scan out a
smaller part of an image, virtio-gpu passes it to a display as an
image which its width represents the one of the part and its stride
equals to the one of the whole image.
This change makes ui/cocoa to cover such cases.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210222144012.21486-1-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The detections of [NSView -enterFullScreen:] and
[NSView -exitFullScreen:] were wrong. A detection is coded as:
[NSView respondsToSelector:@selector(exitFullScreenModeWithOptions:)]
but it should be:
[NSView instancesRespondToSelector:@selector(exitFullScreenModeWithOptions:)]
Because of those APIs were not detected, ui/cocoa always falled
back to a borderless window whose frame matches the screen to
implement fullscreen behavior.
The code using [NSView -enterFullScreen:] and
[NSView -exitFullScreen:] will be used if you fix the detections,
but its behavior is undesirable; the full screen view stretches
the video, changing the aspect ratio, even if zooming is disabled.
This change removes the code as it does nothing good.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210220013138.51437-1-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
There is no need of dynamic allocation as dcl is a small singleton.
Static allocation reduces code size and makes hacking with ui/cocoa a
bit easier.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210219084419.90181-1-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Old Macs were not equipped with mice with an ability to perform
"right clicks" and ui/cocoa interpreted left button down with
left command key pressed as right button down as a workaround.
The workaround has an obvious downside: you cannot tell the guest
that the left button is down while the left command key is
pressed.
Today, Macs has trackpads, Apple Mice, or Magic Mice. They are
capable to emulate right clicks with gestures, which also allows
to perform right clicks on "BootCamp" OSes like Windows.
By removing the workaround, we overcome its downside, and provide
a behavior consistent with BootCamp.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210212000706.28616-1-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The old CocoaView had an idea of synchronizing the host window
configuration and the guest screen configuration. Here, the guest screen
actually means pixman image given ui/cocoa display implementation.
However, [CocoaView -drawRect:] directly interacts with the pixman
image buffer in reality. There is no such distinction of "host" and
"guest." This change removes the "host" configuration and let drawRect
consistently have the direct reference to pixman image. It allows to
get rid of the error-prone "sync" and reduce code size a bit.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210212000629.28551-1-akihiko.odaki@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
QEMU documentation can't be opened if QEMU is run from build tree
because executables are placed in the top of build tree after conversion
to meson.
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20210108213815.64678-1-r.bolshakov@yadro.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Restricting system_wakeup/system_reset/system_powerdown to
machine.json pulls slightly less QAPI-generated code into
user-mode and tools.
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20201012121536.3381997-3-philmd@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
move the vcpu throttling functionality into its own module.
This functionality is not specific to any accelerator,
and it is used currently by migration to slow down guests to try to
have migrations converge, and by the cocoa MacOS UI to throttle speed.
cpu-throttle contains the controls to adjust and inspect throttle
settings, start (set) and stop vcpu throttling, and the throttling
function itself that is run periodically on vcpus to make them take a nap.
Execution of the throttling function on all vcpus is triggered by a timer,
registered at module initialization.
No functionality change.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Message-Id: <20200629093504.3228-3-cfontana@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We want to stop generating the old qemu-doc.html; first we
must update places that refer to it so they instead go to
our top level index.html documentation landing page.
The Cocoa UI has a menu option to bring up the documentation;
make it point to the new top level index.html instead.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20200228153619.9906-31-peter.maydell@linaro.org
Our official OSX support policy covers the last two released versions.
Currently that is 10.14 and 10.15. We also may work on older versions, but
don't guarantee it.
In commit 50290c002c in mid-2019 we introduced some uses of
CLOCK_MONOTONIC which incidentally broke compilation for pre-10.12 OSX
versions (see LP:1861551). We don't intend to fix that, so we might
as well drop the code in ui/cocoa.m which caters for pre-10.12
versions as well. (For reference, 10.11 fell out of Apple extended
security support in September 2018.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20200201170534.22123-1-peter.maydell@linaro.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Use DisplayOpts settings to set the new file-global cursor_hide
variable, stop using the qemu-global cursor_hide variable.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
macOS API documentation says that before applicationDidFinishLaunching
is called, any events will not be processed. However, some events are
fired before it is called in macOS Catalina. This causes deadlock of
iothread_lock in handleEvent while it will be released after the
app_started_sem is posted.
This patch avoids processing events before the app_started_sem is
posted to prevent this deadlock.
Buglink: https://bugs.launchpad.net/qemu/+bug/1847906
Signed-off-by: Hikaru Nishida <hikarupsp@gmail.com>
Message-id: 20191015010734.85229-1-hikarupsp@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190709152053.16670-2-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
[Rebased onto merge commit 95a9457fd44; missed instances of qom/cpu.h
in comments replaced]
sysemu/sysemu.h is a rather unfocused dumping ground for stuff related
to the system-emulator. Evidence:
* It's included widely: in my "build everything" tree, changing
sysemu/sysemu.h still triggers a recompile of some 1100 out of 6600
objects (not counting tests and objects that don't depend on
qemu/osdep.h, down from 5400 due to the previous two commits).
* It pulls in more than a dozen additional headers.
Split stuff related to run state management into its own header
sysemu/runstate.h.
Touching sysemu/sysemu.h now recompiles some 850 objects. qemu/uuid.h
also drops from 1100 to 850, and qapi/qapi-types-run-state.h from 4400
to 4200. Touching new sysemu/runstate.h recompiles some 500 objects.
Since I'm touching MAINTAINERS to add sysemu/runstate.h anyway, also
add qemu/main-loop.h.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190812052359.30071-30-armbru@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
[Unbreak OS-X build]
In my "build everything" tree, changing qemu/main-loop.h triggers a
recompile of some 5600 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h). It includes block/aio.h,
which in turn includes qemu/event_notifier.h, qemu/notify.h,
qemu/processor.h, qemu/qsp.h, qemu/queue.h, qemu/thread-posix.h,
qemu/thread.h, qemu/timer.h, and a few more.
Include qemu/main-loop.h only where it's needed. Touching it now
recompiles only some 1700 objects. For block/aio.h and
qemu/event_notifier.h, these numbers drop from 5600 to 2800. For the
others, they shrink only slightly.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190812052359.30071-21-armbru@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
In fullscreen mode, the window property of cocoaView may not be the key
window, and the current implementation would not re-grab cursor by left click
in fullscreen mode after ungrabbed in fullscreen mode with hot-key ctrl-opt-g.
This patch used value of isFullscreen as a short-cirtuit condition for
relative input device grabbing.
Signed-off-by: Chen Zhang <tgfbeta@me.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 2D2F1191-E82F-4B54-A6E7-73FFB953DE93@me.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
On Mojave, absolute input device, i.e. tablet, had trouble re-grabbing
the cursor in re-entry into the virtual screen area. In some cases,
the `window` property of NSEvent object was nil after cursor exiting from
window, hinting that the `-locationInWindow` method would return value in
screen coordinates. The current implementation used raw locations from
NSEvent without considering whether the value was for the window coordinates
or the macOS screen coordinates, nor the zooming factor for Zoom-to-Fit in
fullscreen mode.
In fullscreen mode, the fullscreen cocoa window might not be the key
window, therefore the location of event in virtual coordinates should
suffice.
This patches fixed boundary check methods for cursor in normal
and fullscreen with/without Zoom-to-Fit in Mojave.
Note: CGRect, -convertRectToScreen: and -convertRectFromScreen: were
used in coordinates conversion for compatibility reason.
Signed-off-by: Chen Zhang <tgfbeta@me.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: FA3FBC4F-5379-4118-B997-58FE05CC58F9@me.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The OSX Mojave release is more picky about enforcing the Cocoa API
restriction that only the main thread may perform UI calls. To
accommodate this we need to restructure the Cocoa code:
* the special OSX main() creates a second thread and uses
that to call the vl.c qemu_main(); the original main
thread goes into the OSX event loop
* the refresh, switch and update callbacks asynchronously
tell the main thread to do the necessary work
* the refresh callback no longer does the "get events from the
UI event queue and handle them" loop, since we now use
the stock OSX event loop. Instead our NSApplication sendEvent
method will either deal with them or pass them on to OSX
All these things have to be changed in one commit, to avoid
breaking bisection.
Note that since we use dispatch_get_main_queue(), this bumps
our minimum version requirement to OSX 10.10 Yosemite (released
in 2014, unsupported by Apple since 2017).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-id: 20190225102433.22401-8-peter.maydell@linaro.org
Message-id: 20190214102816.3393-8-peter.maydell@linaro.org
When we switch away from our custom event handling, we still want to
be able to have first go at any events our application receives,
because in full-screen mode we want to send key events to the guest,
even if they would be menu item activation events. There are several
ways we could do that, but one simple approach is to subclass
NSApplication so we can implement a custom sendEvent method.
Do that, but for the moment have our sendEvent just invoke the
superclass method.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-id: 20190225102433.22401-7-peter.maydell@linaro.org
Message-id: 20190214102816.3393-7-peter.maydell@linaro.org
Currently the handleEvent method will directly call the NSApp
sendEvent method for any events that we want to let OSX deal
with. When we rearrange the event handling code, the way that
we say "let OSX have this event" is going to change. Prepare
for that by refactoring so that handleEvent returns a flag
indicating whether it consumed the event.
Suggested-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-id: 20190225102433.22401-6-peter.maydell@linaro.org
Message-id: 20190214102816.3393-6-peter.maydell@linaro.org
Move the console/device menu creation code functions
further up in the source file, next to the code which
creates the initial menus. We're going to want to
change the location we call these functions from in
the next patch.
This commit is a pure code move with no other changes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-id: 20190225102433.22401-5-peter.maydell@linaro.org
Message-id: 20190214102816.3393-5-peter.maydell@linaro.org
Factor out the long code sequence in main() which creates
the initial set of menus. This will make later patches
which move initialization code around a bit clearer.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-id: 20190225102433.22401-4-peter.maydell@linaro.org
Message-id: 20190214102816.3393-4-peter.maydell@linaro.org
Currently the switchSurface method takes a DisplaySurface. We want
to change our DisplayChangeListener's dpy_gfx_switch callback
to do this work asynchronously on a different thread. The caller
of the switch callback will free the old DisplaySurface
immediately the callback returns, so to ensure that the
other thread doesn't access freed data we need to switch
to using the underlying pixman image instead. The pixman
image is reference counted, so we will be able to take
a reference to it to avoid it vanishing too early.
In this commit we only change the switchSurface method
to take a pixman image, and keep the flow of control
synchronous for now.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-id: 20190225102433.22401-3-peter.maydell@linaro.org
Message-id: 20190214102816.3393-3-peter.maydell@linaro.org
The Cocoa UI should run on the main thread; this is enforced
in OSX Mojave. In order to be able to run on the main thread,
we need to make sure we hold the iothread lock whenever we
call into various QEMU UI midlayer functions.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-id: 20190225102433.22401-2-peter.maydell@linaro.org
Message-id: 20190214102816.3393-2-peter.maydell@linaro.org
Akihiko Odaki
Peter Maydell
Philippe Mathieu-Daudé
Dmitry Petrov
Marc-André Lureau
Roman Bolshakov
Philippe Mathieu-Daudé
Claudio Fontana
Gerd Hoffmann
Hikaru Nishida
Markus Armbruster
Chen Zhang