aboutsummaryrefslogtreecommitdiff
path: root/ui
AgeCommit message (Collapse)AuthorFilesLines
2018-01-16Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell1-4/+4
* QemuMutex tracing improvements (Alex) * ram_addr_t optimization (David) * SCSI fixes (Fam, Stefan, me) * do {} while (0) fixes (Eric) * KVM fix for PMU (Jan) * memory leak fixes from ASAN (Marc-André) * migration fix for HPET, icount, loadvm (Maria, Pavel) * hflags fixes (me, Tao) * block/iscsi uninitialized variable (Peter L.) * full support for GMainContexts in character devices (Peter Xu) * more boot-serial-test (Thomas) * Memory leak fix (Zhecheng) # gpg: Signature made Tue 16 Jan 2018 14:15:45 GMT # gpg: using RSA key 0xBFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (51 commits) scripts/analyse-locks-simpletrace.py: script to analyse lock times util/qemu-thread-*: add qemu_lock, locked and unlock trace events cpu: flush TB cache when loading VMState block/iscsi: fix initialization of iTask in iscsi_co_get_block_status find_ram_offset: Align ram_addr_t allocation on long boundaries find_ram_offset: Add comments and tracing cpu_physical_memory_sync_dirty_bitmap: Another alignment fix checkpatch: Enforce proper do/while (0) style maint: Fix macros with broken 'do/while(0); ' usage tests: Avoid 'do/while(false); ' in vhost-user-bridge chardev: Clean up previous patch indentation chardev: Use goto/label instead of do/break/while(0) mips: Tweak location of ';' in macros net: Drop unusual use of do { } while (0); irq: fix memory leak cpus: unify qemu_*_wait_io_event icount: fixed saving/restoring of icount warp timers scripts/qemu-gdb/timers.py: new helper to dump timer state scripts/qemu-gdb: add simple tcg lock status helper target-i386: update hflags on Hypervisor.framework ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-01-16maint: Fix macros with broken 'do/while(0); ' usageEric Blake1-4/+4
The point of writing a macro embedded in a 'do { ... } while (0)' loop (particularly if the macro has multiple statements or would otherwise end with an 'if' statement) is so that the macro can be used as a drop-in statement with the caller supplying the trailing ';'. Although our coding style frowns on brace-less 'if': if (cond) statement; else something else; that is the classic case where failure to use do/while(0) wrapping would cause the 'else' to pair with any embedded 'if' in the macro rather than the intended outer 'if'. But conversely, if the macro includes an embedded ';', then the same brace-less coding style would now have two statements, making the 'else' a syntax error rather than pairing with the outer 'if'. Thus, even though our coding style with required braces is not impacted, ending a macro with ';' makes our code harder to port to projects that use brace-less styles. The change should have no semantic impact. I was not able to fully compile-test all of the changes (as some of them are examples of the ugly bit-rotting debug print statements that are completely elided by default, and I didn't want to recompile with the necessary -D witnesses - cleaning those up is left as a bite-sized task for another day); I did, however, audit that for all files touched, all callers of the changed macros DID supply a trailing ';' at the callsite, and did not appear to be used as part of a brace-less conditional. Found mechanically via: $ git grep -B1 'while (0);' | grep -A1 \\\\ Signed-off-by: Eric Blake <eblake@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20171201232433.25193-7-eblake@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-01-12Merge remote-tracking branch 'remotes/kraxel/tags/ui-20180112-pull-request' ↵Peter Maydell5-48/+54
into staging sdl2: bugfixes. spice: cleanups. input: mem leak fix. gtk: deprecate 2.x support. # gpg: Signature made Fri 12 Jan 2018 14:52:39 GMT # gpg: using RSA key 0x4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/ui-20180112-pull-request: sdl2: Ignore UI hotkeys after a focus change when GUI modifier is held sdl2 uses surface relative coordinates sdl2: Do not hide the cursor on auxilliary windows spice: remove unused timer list spice: remove only written event_mask field spice: remove unused watch list spice: remove QXLWorker interface field ui: deprecate use of GTK 2.x in favour of 3.x series input: fix memory leak Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-01-12sdl2: Ignore UI hotkeys after a focus change when GUI modifier is heldJindrich Makovicka1-8/+24
When SDL2 windows change focus while a key is held, the window that receives the focus also receives a new KeyDown event, without an autorepeat flag. This means that if a WM places the qemu console over the main window after Ctrl-Alt-2, the console closes immediately after opening. Then, the main window receives the KeyDown event again and the whole process repeats. This patch makes the SDL2 UI ignore the KeyDown events on a window that just received the focus, if the GUI modifier was held. The ignore flag is reset on a first KeyUp event. This effectively works around the issue above. Signed-off-by: Jindrich Makovicka <makovick@gmail.com> Message-Id: <20171117112258.5888-4-makovick@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12sdl2 uses surface relative coordinatesJindrich Makovicka1-26/+4
This patch fixes mouse positioning with -device usb-tablet and fullscreen or resized window. Fixes: 46522a82236ea0cf9011b89896d2d8f8ddaf2443 Signed-off-by: Jindrich Makovicka <makovick@gmail.com> Message-Id: <20171117112258.5888-3-makovick@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12sdl2: Do not hide the cursor on auxilliary windowsJindrich Makovicka1-0/+17
Signed-off-by: Jindrich Makovicka <makovick@gmail.com> Message-Id: <20171117112258.5888-2-makovick@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12spice: remove unused timer listFrediano Ziglio1-4/+0
Signed-off-by: Frediano Ziglio <fziglio@redhat.com> Message-id: 20171122135625.16625-4-fziglio@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12spice: remove only written event_mask fieldFrediano Ziglio1-4/+2
Signed-off-by: Frediano Ziglio <fziglio@redhat.com> Message-id: 20171122135625.16625-3-fziglio@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12spice: remove unused watch listFrediano Ziglio1-4/+0
Signed-off-by: Frediano Ziglio <fziglio@redhat.com> Message-id: 20171122135625.16625-2-fziglio@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12spice: remove QXLWorker interface fieldFrediano Ziglio1-2/+0
This fields points to an old interface that is no more used in the current code. Signed-off-by: Frediano Ziglio <fziglio@redhat.com> Message-id: 20171122135625.16625-1-fziglio@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: deprecate use of GTK 2.x in favour of 3.x seriesDaniel P. Berrange1-0/+5
The GTK 3.0 release was made in Feb, 2011: https://blog.gtk.org/2011/02/10/gtk-3-0-released/ That will soon be 7 years ago, which is enough time to consider the 3.x series widely supported. Thus we deprecate the GTK 2.x support, which will allow us to delete it in the last release of 2018. By this time, GTK 3.x will be almost 8 years old. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20171212113440.16483-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12input: fix memory leaklinzhecheng1-0/+2
If kbd_queue is not empty and queue_count >= queue_limit, we should free evt. Change-Id: Ieeacf90d5e7e370a40452ec79031912d8b864d83 Signed-off-by: linzhecheng <linzhecheng@huawei.com> Message-id: 20171225023730.5512-1-linzhecheng@huawei.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: mix misleading comments & return types of VNC I/O helper methodsDaniel P. Berrange4-23/+24
While the QIOChannel APIs for reading/writing data return ssize_t, with negative value indicating an error, the VNC code passes this return value through the vnc_client_io_error() method. This detects the error condition, disconnects the client and returns 0 to indicate error. Thus all the VNC helper methods should return size_t (unsigned), and misleading comments which refer to the possibility of negative return values need fixing. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-14-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: add trace events related to VNC client throttlingDaniel P. Berrange2-0/+30
The VNC client throttling is quite subtle so will benefit from having trace points available for live debugging. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-13-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: place a hard cap on VNC server output buffer sizeDaniel P. Berrange1-0/+29
The previous patches fix problems with throttling of forced framebuffer updates and audio data capture that would cause the QEMU output buffer size to grow without bound. Those fixes are graceful in that once the client catches up with reading data from the server, everything continues operating normally. There is some data which the server sends to the client that is impractical to throttle. Specifically there are various pseudo framebuffer update encodings to inform the client of things like desktop resizes, pointer changes, audio playback start/stop, LED state and so on. These generally only involve sending a very small amount of data to the client, but a malicious guest might be able to do things that trigger these changes at a very high rate. Throttling them is not practical as missed or delayed events would cause broken behaviour for the client. This patch thus takes a more forceful approach of setting an absolute upper bound on the amount of data we permit to be present in the output buffer at any time. The previous patch set a threshold for throttling the output buffer by allowing an amount of data equivalent to one complete framebuffer update and one seconds worth of audio data. On top of this it allowed for one further forced framebuffer update to be queued. To be conservative, we thus take that throttling threshold and multiply it by 5 to form an absolute upper bound. If this bound is hit during vnc_write() we forceably disconnect the client, refusing to queue further data. This limit is high enough that it should never be hit unless a malicious client is trying to exploit the sever, or the network is completely saturated preventing any sending of data on the socket. This completes the fix for CVE-2017-15124 started in the previous patches. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-12-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: fix VNC client throttling when forced update is requestedDaniel P. Berrange4-4/+41
The VNC server must throttle data sent to the client to prevent the 'output' buffer size growing without bound, if the client stops reading data off the socket (either maliciously or due to stalled/slow network connection). The current throttling is very crude because it simply checks whether the output buffer offset is zero. This check is disabled if the client has requested a forced update, because we want to send these as soon as possible. As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM. They can first start something in the guest that triggers lots of framebuffer updates eg play a youtube video. Then repeatedly send full framebuffer update requests, but never read data back from the server. This can easily make QEMU's VNC server send buffer consume 100MB of RAM per second, until the OOM killer starts reaping processes (hopefully the rogue QEMU process, but it might pick others...). To address this we make the throttling more intelligent, so we can throttle full updates. When we get a forced update request, we keep track of exactly how much data we put on the output buffer. We will not process a subsequent forced update request until this data has been fully sent on the wire. We always allow one forced update request to be in flight, regardless of what data is queued for incremental updates or audio data. The slight complication is that we do not initially know how much data an update will send, as this is done in the background by the VNC job thread. So we must track the fact that the job thread has an update pending, and not process any further updates until this job is has been completed & put data on the output buffer. This unbounded memory growth affects all VNC server configurations supported by QEMU, with no workaround possible. The mitigating factor is that it can only be triggered by a client that has authenticated with the VNC server, and who is able to trigger a large quantity of framebuffer updates or audio samples from the guest OS. Mostly they'll just succeed in getting the OOM killer to kill their own QEMU process, but its possible other processes can get taken out as collateral damage. This is a more general variant of the similar unbounded memory usage flaw in the websockets server, that was previously assigned CVE-2017-15268, and fixed in 2.11 by: commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493 Author: Daniel P. Berrange <berrange@redhat.com> Date: Mon Oct 9 14:43:42 2017 +0100 io: monitor encoutput buffer size from websocket GSource This new general memory usage flaw has been assigned CVE-2017-15124, and is partially fixed by this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-11-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: fix VNC client throttling when audio capture is activeDaniel P. Berrange2-8/+70
The VNC server must throttle data sent to the client to prevent the 'output' buffer size growing without bound, if the client stops reading data off the socket (either maliciously or due to stalled/slow network connection). The current throttling is very crude because it simply checks whether the output buffer offset is zero. This check must be disabled if audio capture is enabled, because when streaming audio the output buffer offset will rarely be zero due to queued audio data, and so this would starve framebuffer updates. As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM. They can first start something in the guest that triggers lots of framebuffer updates eg play a youtube video. Then enable audio capture, and simply never read data back from the server. This can easily make QEMU's VNC server send buffer consume 100MB of RAM per second, until the OOM killer starts reaping processes (hopefully the rogue QEMU process, but it might pick others...). To address this we make the throttling more intelligent, so we can throttle when audio capture is active too. To determine how to throttle incremental updates or audio data, we calculate a size threshold. Normally the threshold is the approximate number of bytes associated with a single complete framebuffer update. ie width * height * bytes per pixel. We'll send incremental updates until we hit this threshold, at which point we'll stop sending updates until data has been written to the wire, causing the output buffer offset to fall back below the threshold. If audio capture is enabled, we increase the size of the threshold to also allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes per sample * frequency. This allows the output buffer to have a mixture of incremental framebuffer updates and audio data queued, but once the threshold is exceeded, audio data will be dropped and incremental updates will be throttled. This unbounded memory growth affects all VNC server configurations supported by QEMU, with no workaround possible. The mitigating factor is that it can only be triggered by a client that has authenticated with the VNC server, and who is able to trigger a large quantity of framebuffer updates or audio samples from the guest OS. Mostly they'll just succeed in getting the OOM killer to kill their own QEMU process, but its possible other processes can get taken out as collateral damage. This is a more general variant of the similar unbounded memory usage flaw in the websockets server, that was previously assigned CVE-2017-15268, and fixed in 2.11 by: commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493 Author: Daniel P. Berrange <berrange@redhat.com> Date: Mon Oct 9 14:43:42 2017 +0100 io: monitor encoutput buffer size from websocket GSource This new general memory usage flaw has been assigned CVE-2017-15124, and is partially fixed by this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-10-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: refactor code for determining if an update should be sent to the clientDaniel P. Berrange1-7/+20
The logic for determining if it is possible to send an update to the client will become more complicated shortly, so pull it out into a separate method for easier extension later. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-9-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: correctly reset framebuffer update state after processing dirty regionsDaniel P. Berrange1-1/+1
According to the RFB protocol, a client sends one or more framebuffer update requests to the server. The server can reply with a single framebuffer update response, that covers all previously received requests. Once the client has read this update from the server, it may send further framebuffer update requests to monitor future changes. The client is free to delay sending the framebuffer update request if it needs to throttle the amount of data it is reading from the server. The QEMU VNC server, however, has never correctly handled the framebuffer update requests. Once QEMU has received an update request, it will continue to send client updates forever, even if the client hasn't asked for further updates. This prevents the client from throttling back data it gets from the server. This change fixes the flawed logic such that after a set of updates are sent out, QEMU waits for a further update request before sending more data. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-8-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: introduce enum to track VNC client framebuffer update request stateDaniel P. Berrange2-12/+18
Currently the VNC servers tracks whether a client has requested an incremental or forced update with two boolean flags. There are only really 3 distinct states to track, so create an enum to more accurately reflect permitted states. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-7-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: track how much decoded data we consumed when doing SASL encodingDaniel P. Berrange2-1/+3
When we encode data for writing with SASL, we encode the entire pending output buffer. The subsequent write, however, may not be able to send the full encoded data in one go though, particularly with a slow network. So we delay setting the output buffer offset back to zero until all the SASL encoded data is sent. Between encoding the data and completing sending of the SASL encoded data, however, more data might have been placed on the pending output buffer. So it is not valid to set offset back to zero. Instead we must keep track of how much data we consumed during encoding and subtract only that amount. With the current bug we would be throwing away some pending data without having sent it at all. By sheer luck this did not previously cause any serious problem because appending data to the send buffer is always an atomic action, so we only ever throw away complete RFB protocol messages. In the case of frame buffer updates we'd catch up fairly quickly, so no obvious problem was visible. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-6-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: avoid pointless VNC updates if framebuffer isn't dirtyDaniel P. Berrange1-1/+1
The vnc_update_client() method checks the 'has_dirty' flag to see if there are dirty regions that are pending to send to the client. Regardless of this flag, if a forced update is requested, updates must be sent. For unknown reasons though, the code also tries to sent updates if audio capture is enabled. This makes no sense as audio capture state does not impact framebuffer contents, so this check is removed. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-5-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: remove redundant indentation in vnc_client_updateDaniel P. Berrange1-55/+57
Now that previous dead / unreachable code has been removed, we can simplify the indentation in the vnc_client_update method. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-4-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: remove unreachable code in vnc_update_clientDaniel P. Berrange1-5/+1
A previous commit: commit 5a8be0f73d6f60ff08746377eb09ca459f39deab Author: Gerd Hoffmann <kraxel@redhat.com> Date: Wed Jul 13 12:21:20 2016 +0200 vnc: make sure we finish disconnect Added a check for vs->disconnecting at the very start of the vnc_update_client method. This means that the very next "if" statement check for !vs->disconnecting always evaluates true, and is thus redundant. This in turn means the vs->disconnecting check at the very end of the method never evaluates true, and is thus unreachable code. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-3-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12ui: remove 'sync' parameter from vnc_update_clientDaniel P. Berrange1-8/+3
There is only one caller of vnc_update_client and that always passes false for the 'sync' parameter. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-2-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-12vnc: fix debug spellingMarc-André Lureau1-1/+1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171220140618.12701-1-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-14ui: generate qcode to linux mappingsOwen Smith1-0/+1
Use keycodedb to generate a qcode to linux mapping Signed-off-by: Owen Smith <owen.smith@citrix.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
2017-11-16sdl2: Fix broken display updating after the window is hiddenJindrich Makovicka1-6/+2
With SDL 2.0.6, calling SDL_ShowWindow during SDL_WINDOWEVENT_HIDDEN blocks all subsequent display updates. Instead of trying to override the change, just update the scon->hidden flag. Signed-off-by: Jindrich Makovicka <makovick@gmail.com> Message-Id: <20171112193032.9724-2-makovick@gmail.com> This is a partial revert of d3f3a0f453ea590be529079ae214c200bb5ecc1a, which in turn is a workaround for a SDL bug. The bug is fixed in 2.0.6, see https://bugzilla.libsdl.org/show_bug.cgi?id=3410 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-11-16sdl2: Do not leave grab when fullscreenJindrich Makovicka1-2/+3
Prevents displaying of a doubled mouse pointer when moving the pointer to the screen edges when fullscreen. Signed-off-by: Jindrich Makovicka <makovick@gmail.com> Message-Id: <20171112193032.9724-8-makovick@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-11-16sdl2: Fix dead keyboard after fullsceenJindrich Makovicka1-0/+1
Signed-off-by: Jindrich Makovicka <makovick@gmail.com> Message-Id: <20171112193032.9724-7-makovick@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-11-16sdl2: Use the same pointer show/hide logic for absolute and relative modeJindrich Makovicka1-11/+13
Also use a proper enum parameter for SDL_ShowCursor Signed-off-by: Jindrich Makovicka <makovick@gmail.com> Message-Id: <20171112193032.9724-4-makovick@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-11-16sdl2: Do not quit the emulator when an auxilliary window is closedJindrich Makovicka1-3/+8
Signed-off-by: Jindrich Makovicka <makovick@gmail.com> Message-Id: <20171112193032.9724-3-makovick@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-11-10ui: use QEMU_IS_ALIGNED macroPhilippe Mathieu-Daudé1-1/+1
Applied using the Coccinelle semantic patch scripts/coccinelle/use_osdep.cocci Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20170718061005.29518-9-f4bug@amsat.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-11-10ui: fix dcl unregisterGerd Hoffmann1-0/+1
register checks for dcl->ds being NULL, to avoid registering the same dcl twice. Therefore dcl->ds must be cleared on unregister, otherwise un-registering and re-registering doesn't work. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1510809 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171109105154.29414-1-kraxel@redhat.com
2017-11-07ui/cocoa.m: Send ctrl-alt key combos to guest if QEMU isn't using themPeter Maydell1-4/+2
Send those ctrl-alt key combos that QEMU doesn't treat specially to the guest rather than ignoring them. All the case where we do special handling of ctrl-alt-X exit the event handling using a "return" statement, so we can simply allow the rest to fall through into the normal key handling by deleting the now-spurious "else". We take the opportunity to clean up some oddly-formatted and now rather uninformative comments by removing them. Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-07ui/cocoa.m: move ungrab to ctrl-alt-gJohn Arbuckle1-13/+18
Currently the cocoa user interface relis on the user pushing control-alt to ungrab the mouse. This is patch changes the key combination to control-alt-g to be in line with the GTK user interface. Signed-off-by: John Arbuckle <programmingkidx@gmail.com> Message-id: 20171102213907.11443-1-programmingkidx@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-07ui/cocoa.m: Make scrolling work again in GUI monitor windowsJohn Arbuckle1-32/+66
Make scrolling in the monitor work, by correctly passing through control+key combinations. Signed-off-by: John Arbuckle <programmingkidx@gmail.com> Message-id: 20171101154607.1582-1-programmingkidx@gmail.com [PMM: fixed coding style nits; cleaned up commit message] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-02ui/cocoa.m: Fix console selection keysJohn Arbuckle1-1/+1
Fix console selection keys so that the right console is selected. Signed-off-by: John Arbuckle <programmingkidx@gmail.com> Message-id: 20171005190449.15591-1-programmingkidx@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-10-23ui: pull in latest keycodemapdbDaniel P. Berrange1-0/+0
Latest keycodemapdb has a fix for Sun keyboard Pause mapping and backcompat fix for QEMU's treatment of 0xb7 as an alternative to 0x54 for triggering Print/SysRq Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20171019142848.572-10-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-10-23ui: normalize the 'sysrq' key into the 'print' keyDaniel P. Berrange1-0/+14
The 'sysrq' key was mistakenly added to QEMU to deal with incorrect handling of the 'print' key in the ps2 device: commit f2289cb6924afc97b2a75d21bfc9217024d11741 Author: balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162> Date: Wed Jun 4 10:14:16 2008 +0000 Add sysrq to key names known by "sendkey". Adding sysrq keycode to the table enabling running sysrq debugging in the guest via the monitor sendkey command, like: (qemu) sendkey alt-sysrq-t Tested on x86-64 target and Linux guest. Signed-off-by: Ryan Harper <ryanh@us.ibm.com> The ps2 device is now fixed wrt modifiers and the 'print' key. Further the handling of the 'sysrq' key has some problems of its own, documented in the previous commit. To cleanup this mess, we convert any use of 'sysrq' into 'print' prior to dispatching the event to device models. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20171019142848.572-9-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-10-23ui: use correct union field for key numberDaniel P. Berrange1-1/+1
The code converting key numbers to QKeyCode in the 'input-send-event' command mistakenly accessed the key->u.qcode union field instead of the key->u.number field. This is harmless because the fields use the same size datatype in both cases, but none the less it should be fixed to avoid confusion. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20171019142848.572-4-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-10-23ui: fix crash with sendkey and raw key numbersDaniel P. Berrange1-0/+5
Previously we enforced that all key events are using QKeyCodes at time they are sent: commit af07e5ff02ae6d4258fc5331007811d0b1c4d35a Author: Daniel P. Berrange <berrange@redhat.com> Date: Fri Sep 29 11:12:00 2017 +0100 ui: convert key events to QKeyCodes immediately This commit forget to fix the code for the legacy 'sendkey' command which still accepts key numbers from the user, which then need converting to QKeyCodes Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20171019142848.572-3-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-10-19Merge remote-tracking branch ↵Peter Maydell10-55/+232
'remotes/kraxel/tags/opengl-20171017-pull-request' into staging ui: opengl updates for dma-buf support. # gpg: Signature made Tue 17 Oct 2017 12:13:36 BST # gpg: using RSA key 0x4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/opengl-20171017-pull-request: egl-headless: add dmabuf support egl-helpers: add egl_texture_blit and egl_texture_blend egl-helpers: add dmabuf import support opengl: add flipping vertex shader opengl: move shader init from console-gl.c to shader.c console: add support for dmabufs Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-10-17egl-headless: add dmabuf supportGerd Hoffmann1-2/+57
Add support for the new dmabuf interface. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20171010135453.6704-7-kraxel@redhat.com
2017-10-17egl-helpers: add egl_texture_blit and egl_texture_blendGerd Hoffmann1-0/+27
egl_texture_blit() blits a texture, simliar to egl_fb_blit() but by rendering the texture to the screen instead of using a framebuffer blit. egl_texture_blend() renders a texture with alpha blending, will be used to render the cursor to the screen. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20171010135453.6704-6-kraxel@redhat.com
2017-10-17egl-helpers: add dmabuf import supportGerd Hoffmann1-0/+46
Add helper function to import a dma-buf as opengl texture. Also add a helper to release the texture again. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20171010135453.6704-5-kraxel@redhat.com
2017-10-17opengl: add flipping vertex shaderGerd Hoffmann3-4/+20
Add vertex shader which flips the texture upside down while blitting it. Add argument to qemu_gl_run_texture_blit() to enable flipping. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20171010135453.6704-4-kraxel@redhat.com
2017-10-17opengl: move shader init from console-gl.c to shader.cGerd Hoffmann6-53/+53
With the upcoming dmabuf support in qemu there will be more users of the shaders than just console-gl.c. So rename ConsoleGLState to QemuGLShader, rename some functions too, move code from console-gl.c to shaders.c. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20171010135453.6704-3-kraxel@redhat.com
2017-10-17console: add support for dmabufsGerd Hoffmann1-0/+33
This patch adds support for dma-bufs to the qemu console interfaces. It adds a new "struct QemuDmaBuf" to represent a dmabuf with accociated metatdata (size, format). It adds three functions (and DisplayChangeListenerOps operations) to set a dma-buf as display scanout, as cursor and to release a dmabuf. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20171010135453.6704-2-kraxel@redhat.com
2017-10-16gtk: fix wrong id between texture and framebufferAnthoine Bourgeois1-2/+1
The gd_gl_area_scanout_texture must destroy framebuffer if there is no texture id instead of no framebuffer id. The effect was a black screen with "-vga virtio -display gtk,gl=on" options. The bug was introduce by a4f113fd "gtk: use framebuffer helper functions." Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@blade-group.com> Message-id: 20171002124052.13829-1-anthoine.bourgeois@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
generated by cgit v1.1 at 2024-10-21 12:17:53 +0000