aboutsummaryrefslogtreecommitdiff
path: root/ui
AgeCommit message (Collapse)AuthorFilesLines
2018-02-09Drop superfluous includes of qapi/qmp/qerror.hMarkus Armbruster1-1/+0
Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-6-armbru@redhat.com>
2018-02-09Include qapi/error.h exactly where neededMarkus Armbruster6-0/+7
This cleanup makes the number of objects depending on qapi/error.h drop from 1910 (out of 4743) to 1612 in my "build everything" tree. While there, separate #include from file comment with a blank line, and drop a useless comment on why qemu/osdep.h is included first. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-5-armbru@redhat.com> [Semantic conflict with commit 34e304e975 resolved, OSX breakage fixed]
2018-02-09Drop superfluous includes of qapi-types.h and test-qapi-types.hMarkus Armbruster3-3/+0
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-4-armbru@redhat.com>
2018-02-09vnc: use stubs for CONFIG_VNC=n dummy functionsGerd Hoffmann2-0/+22
Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20180202064546.21746-1-kraxel@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-02-05ui: update keycodemapdb to get py3 fixesDaniel P. Berrange1-0/+0
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <20180116134217.8725-13-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-02-05input: add missing JIS keys to virtio inputMiika S1-0/+0
keycodemapdb updated to add the QKeyCodes muhenkan and katakanahiragana Signed-off-by: Miika S <miika9764@gmail.com> Message-Id: <20180116134217.8725-12-berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-02-02ui: correctly advance output buffer when writing SASL dataDaniel P. Berrangé1-1/+1
In this previous commit: commit 8f61f1c5a6bc06438a1172efa80bc7606594fa07 Author: Daniel P. Berrange <berrange@redhat.com> Date: Mon Dec 18 19:12:20 2017 +0000 ui: track how much decoded data we consumed when doing SASL encoding I attempted to fix a flaw with tracking how much data had actually been processed when encoding with SASL. With that flaw, the VNC server could mistakenly discard queued data that had not been sent. The fix was not quite right though, because it merely decremented the vs->output.offset value. This is effectively discarding data from the end of the pending output buffer. We actually need to discard data from the start of the pending output buffer. We also want to free memory that is no longer required. The correct way to handle this is to use the buffer_advance() helper method instead of directly manipulating the offset value. Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20180201155841.27509-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-02-02ui: convert VNC server to QIONetListenerDaniel P. Berrange2-146/+58
The VNC server already has the ability to listen on multiple sockets. Converting it to use the QIONetListener APIs though, will reduce the amount of code in the VNC server and improve the clarity of what is left. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180201164514.10330-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-02-02ui: fix mixup between qnum and qcode in SDL1 key handlingDaniel P. Berrangé1-1/+8
The previous commit: commit 2ec78706d188df7d3dab43d07b19b05ef7800a44 Author: Daniel P. Berrange <berrange@redhat.com> Date: Wed Jan 17 16:47:15 2018 +0000 ui: convert GTK and SDL1 frontends to keycodemapdb changed the x_keymap.c keymap so that its target was qcodes instead of qnums. It updated the GTK frontend to take account of this change, but forgot to update the SDL1 frontend. Thus the SDL frontend was getting qcodes but dispatching them as if they were qnums. IOW, keyboard input was completely hosed with SDL1. Since the keyboard layout tables are still all based on qnums, it is easier to just keep SDL1 using qnums as it will be deleted in a few releases time. Reported-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20180201180033.14255-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-29ui: fix alphabetical ordering of keymapsDaniel P. Berrange1-1/+1
The qcode-to-linux keymaps was accidentally added in the wrong place by commit de80d78594b4c3767a12d8d42debcf12cbf85a5b Author: Owen Smith <owen.smith@citrix.com> Date: Fri Nov 3 11:56:28 2017 +0000 ui: generate qcode to linux mappings breaking the alphabetical ordering of keymaps Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180117164118.8510-4-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-29hw: convert the escc device to keycodemapdbDaniel P. Berrange1-0/+1
Replace the qcode_to_keycode table with automatically generated tables. Missing entries in qcode_to_keycode now fixed: - Q_KEY_CODE_KP_COMMA -> 0x2d Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180117164118.8510-3-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-29hw: convert ps2 device to keycodemapdbDaniel P. Berrange1-0/+3
Replace the qcode_to_keycode_set1, qcode_to_keycode_set2, and qcode_to_keycode_set3 tables with automatically generated tables. Missing entries in qcode_to_keycode_set1 now fixed: - Q_KEY_CODE_SYSRQ -> 0x54 - Q_KEY_CODE_PRINT -> 0x54 (NB ignored due to special case) - Q_KEY_CODE_AGAIN -> 0xe005 - Q_KEY_CODE_PROPS -> 0xe006 - Q_KEY_CODE_UNDO -> 0xe007 - Q_KEY_CODE_FRONT -> 0xe00c - Q_KEY_CODE_COPY -> 0xe078 - Q_KEY_CODE_OPEN -> 0x64 - Q_KEY_CODE_PASTE -> 0x65 - Q_KEY_CODE_CUT -> 0xe03c - Q_KEY_CODE_LF -> 0x5b - Q_KEY_CODE_HELP -> 0xe075 - Q_KEY_CODE_COMPOSE -> 0xe05d - Q_KEY_CODE_PAUSE -> 0xe046 - Q_KEY_CODE_KP_EQUALS -> 0x59 And some mistakes corrected: - Q_KEY_CODE_HIRAGANA was mapped to 0x70 (Katakanahiragana) instead of of 0x77 (Hirigana) - Q_KEY_CODE_MENU was incorrectly mapped to the compose scancode (0xe05d) and is now mapped to 0xe01e - Q_KEY_CODE_FIND was mapped to 0xe065 (Search) instead of to 0xe041 (Find) - Q_KEY_CODE_POWER, SLEEP & WAKE had 0x0e instead of 0xe0 as the prefix Missing entries in qcode_to_keycode_set2 now fixed: - Q_KEY_CODE_PRINT -> 0x7f (NB ignored due to special case) - Q_KEY_CODE_COMPOSE -> 0xe02f - Q_KEY_CODE_PAUSE -> 0xe077 - Q_KEY_CODE_KP_EQUALS -> 0x0f And some mistakes corrected: - Q_KEY_CODE_HIRAGANA was mapped to 0x13 (Katakanahiragana) instead of of 0x62 (Hirigana) - Q_KEY_CODE_MENU was incorrectly mapped to the compose scancode (0xe02f) and is now not mapped - Q_KEY_CODE_FIND was mapped to 0xe010 (Search) and is now not mapped. - Q_KEY_CODE_POWER, SLEEP & WAKE had 0x0e instead of 0xe0 as the prefix Missing entries in qcode_to_keycode_set3 now fixed: - Q_KEY_CODE_ASTERISK -> 0x7e - Q_KEY_CODE_SYSRQ -> 0x57 - Q_KEY_CODE_LESS -> 0x13 - Q_KEY_CODE_STOP -> 0x0a - Q_KEY_CODE_AGAIN -> 0x0b - Q_KEY_CODE_PROPS -> 0x0c - Q_KEY_CODE_UNDO -> 0x10 - Q_KEY_CODE_COPY -> 0x18 - Q_KEY_CODE_OPEN -> 0x20 - Q_KEY_CODE_PASTE -> 0x28 - Q_KEY_CODE_FIND -> 0x30 - Q_KEY_CODE_CUT -> 0x38 - Q_KEY_CODE_HELP -> 0x09 - Q_KEY_CODE_COMPOSE -> 0x8d - Q_KEY_CODE_AUDIONEXT -> 0x93 - Q_KEY_CODE_AUDIOPREV -> 0x94 - Q_KEY_CODE_AUDIOSTOP -> 0x98 - Q_KEY_CODE_AUDIOMUTE -> 0x9c - Q_KEY_CODE_VOLUMEUP -> 0x95 - Q_KEY_CODE_VOLUMEDOWN -> 0x9d - Q_KEY_CODE_CALCULATOR -> 0xa3 - Q_KEY_CODE_AC_HOME -> 0x97 And some mistakes corrected: - Q_KEY_CODE_MENU was incorrectly mapped to the compose scancode (0x8d) and is now 0x91 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180117164118.8510-2-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-25sdl: reorganize -no-frame supportGerd Hoffmann2-12/+4
Drop no_frame flag from sdl_display_init argument list, use a global variable instead. This is temporary until -no-frame support is dropped altogether when we remove sdl1 support. Remove any traces of noframe from sdl2 code. It is just dead code as sdl2 doesn't support the SDL_NOFRAME window flag any more. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20180115154855.30850-3-kraxel@redhat.com
2018-01-25sdl: use ctrl-alt-g as grab hotkeyGerd Hoffmann2-33/+24
Be consistent with gtk and cocoa. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20180115154855.30850-2-kraxel@redhat.com
2018-01-25ui: deprecate use of SDL 1.2 in favour of 2.0 seriesDaniel P. Berrange1-0/+3
The SDL 2.0 release was made in Aug, 2013: https://www.libsdl.org/release/ That will soon be 4 + 1/2 years ago, which is enough time to consider the 2.0 series widely supported. Thus we deprecate the SDL 1.2 support, which will allow us to delete it in the last release of 2018. By this time, SDL 2.0 will be more than 5 years old. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20180115142533.24585-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-25ui: ignore hardware keycode 255 on win32Daniel P. Berrange1-0/+6
It is a reserved value and doesn't have a corresponding valid scancode. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180117164717.15855-5-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-25ui: add fix for GTK Pause key handling on Win32Daniel P. Berrange1-1/+8
Versions of GTK prior to 3.22 did not correctly set the keyval field when VK_PAUSE was received on Windows. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180117164717.15855-4-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-25ui: convert GTK and SDL1 frontends to keycodemapdbDaniel P. Berrange7-317/+272
The x_keycode_to_pc_keycode and evdev_keycode_to_pc_keycode tables are replaced with automatically generated tables. In addition the X11 heuristics are improved to detect running on XQuartz and XWin X11 servers, to activate the correct OS-X and Win32 keycode maps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180117164717.15855-3-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-25ui: convert the SDL2 frontend to keycodemapdbDaniel P. Berrange3-272/+12
The SDL2 scancodes are conveniently identical to the USB scancodes. Replace the sdl2_scancode_to_qcode table with an automatically generated table. Missing entries in sdl2_scancode_to_qcode now fixed: - 0x32 -> Q_KEY_CODE_BACKSLASH - 0x66 -> Q_KEY_CODE_POWER - 0x67 -> Q_KEY_CODE_KP_EQUALS - 0x74 -> Q_KEY_CODE_OPEN - 0x77 -> Q_KEY_CODE_FRONT - 0x7f -> Q_KEY_CODE_AUDIOMUTE - 0x80 -> Q_KEY_CODE_VOLUMEUP - 0x81 -> Q_KEY_CODE_VOLUMEDOWN - 0x85 -> Q_KEY_CODE_KP_COMMA - 0x87 -> Q_KEY_CODE_RO - 0x89 -> Q_KEY_CODE_YEN - 0x8a -> Q_KEY_CODE_HENKAN - 0x93 -> Q_KEY_CODE_HIRAGANA - 0xe8 -> Q_KEY_CODE_AUDIOPLAY - 0xe9 -> Q_KEY_CODE_AUDIOSTOP - 0xea -> Q_KEY_CODE_AUDIOPREV - 0xeb -> Q_KEY_CODE_AUDIONEXT - 0xed -> Q_KEY_CODE_VOLUMEUP - 0xee -> Q_KEY_CODE_VOLUMEDOWN - 0xef -> Q_KEY_CODE_AUDIOMUTE - 0xf1 -> Q_KEY_CODE_AC_BACK - 0xf2 -> Q_KEY_CODE_AC_FORWARD - 0xf3 -> Q_KEY_CODE_STOP - 0xf4 -> Q_KEY_CODE_FIND - 0xf8 -> Q_KEY_CODE_SLEEP - 0xfa -> Q_KEY_CODE_AC_REFRESH - 0xfb -> Q_KEY_CODE_CALCULATOR And some mistakes corrected: - 0x65 -> Q_KEY_CODE_COMPOSE, not duplicating Q_KEY_CODE_MENU Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180117164717.15855-2-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-25ui: avoid sign extension using client width/heightDaniel P. Berrange2-2/+11
Pixman returns a signed int for the image width/height, but the VNC protocol only permits a unsigned int16. Effective framebuffer size is determined by the guest, limited by the video RAM size, so the dimensions are unlikely to exceed the range of an unsigned int16, but this is not currently validated. With the current use of 'int' for client width/height, the calculation of offsets in vnc_update_throttle_offset() suffers from integer size promotion and sign extension, causing coverity warnings *** CID 1385147: Integer handling issues (SIGN_EXTENSION) /ui/vnc.c: 979 in vnc_update_throttle_offset() 973 * than that the client would already suffering awful audio 974 * glitches, so dropping samples is no worse really). 975 */ 976 static void vnc_update_throttle_offset(VncState *vs) 977 { 978 size_t offset = >>> CID 1385147: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "vs->client_pf.bytes_per_pixel" with type "unsigned char" (8 bits, unsigned) is promoted in "vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 979 vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel; Change client_width / client_height to be a size_t to avoid sign extension and integer promotion. Then validate that dimensions are in range wrt the RFB protocol u16 limits. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180118155254.17053-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-22Replace all occurances of __FUNCTION__ with __func__Alistair Francis2-5/+5
Replace all occurs of __FUNCTION__ except for the check in checkpatch with the non GCC specific __func__. One line in hcd-musb.c was manually tweaked to pass checkpatch. Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> [THH: Removed hunks related to pxa2xx_mmci.c (fixed already)] Signed-off-by: Thomas Huth <thuth@redhat.com>
2018-01-18cocoa.m: Fix scroll wheel supportJohn Arbuckle1-8/+19
When using a mouse's scroll wheel in a guest with the cocoa front-end, the mouse pointer moves up and down instead of scrolling the window. This patch fixes this problem. Signed-off-by: John Arbuckle <programmingkidx@gmail.com> Message-id: 20180108180707.7976-1-programmingkidx@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
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>
generated by cgit v1.1 at 2024-11-18 05:31:39 +0000