Am 13.04.23 um 22:43 schrieb Bernhard Beschow:
Am 13. April 2023 17:54:34 UTC schrieb "Volker Rümelin"
<vr_q...@t-online.de>:
I'm trying to use QEMU on Windows hosts for fun and for profit.
While the GTK
GUI doesn't seem to support OpenGL under Windows the SDL2 GUI does.
Hence I
used the SDL2 GUI where I ran into several issues of which three
are fixed in
this series, which are:
* Alt+Tab switches tasks on the host rather than in the guest in
fullscreen mode
* Alt+F4 closes QEMU rather than a graphical task in the guest
* AltGr keyboard modifier isn't recognized by a Linux guest
More information about each issue is provided in the patches.
Bernhard Beschow (3):
ui/sdl2: Grab Alt+Tab also in fullscreen mode
ui/sdl2: Grab Alt+F4 also under Windows
ui/sdl2-input: Fix AltGr modifier on Windows hosts
ui/sdl2-input.c | 13 +++++++++++++
ui/sdl2.c | 2 ++
2 files changed, 15 insertions(+)
Hi Bernhard,
Hi Volker,
I don't think these patches are necessary. The AltGr key and the
keyboard grab was fixed in 2020 with commit 830473455f ("ui/sdl2:
fix handling of AltGr key on Windows") and a few commits before.
Indeed, this patch addresses the AltGr issue. What I noticed in my
case is that the AltGr behavior is different, depending on whether
the *guest* is in graphics mode or not. Pressing AltGr in graphics
mode issues two key modifiers while only one is issued when the guest
is in text mode. I'll recheck tomorrow when I have access to a
Windows host.
Hi Bernhard,
the AltGr behavior depends on the keyboard grab. The AltGr key works
without keyboard grabbed and it doesn't with keyboard grabbed. That's
a bug.
Hi Bernhard,
this used to work before SDL2-2.0.16. There was no code for Windows in
SDL2 to handle keyboard grabs. Version 2.0.16 introduced a Windows low
level keyboard hook procedure to grab the keyboard. Windows calls this
callback before the QEMU keyboard hook procedure. This explains the
observed behavior.
The fix is to disable SDL_SetHint(SDL_HINT_GRAB_KEYBOARD, "1"); for
Windows. This restores the QEMU keyboard grab for all Windows SDL2
versions. Your first two patches are also necessary. But I think you
will need a #ifdef SDL_HINT_ALLOW_ALT_TAB_WHILE_GRABBED for older SDL2
versions.
I'll write a patch similar to this one after more tests.
diff --git a/ui/sdl2.c b/ui/sdl2.c
index b011e8d759..9f6b959464 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -855,7 +855,9 @@ static void sdl2_display_init(DisplayState *ds,
DisplayOptions *o)
#ifdef SDL_HINT_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR /* only available since SDL
2.0.8 */
SDL_SetHint(SDL_HINT_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR, "0");
#endif
+#ifndef CONFIG_WIN32
SDL_SetHint(SDL_HINT_GRAB_KEYBOARD, "1");
+#endif
#ifdef SDL_HINT_ALLOW_ALT_TAB_WHILE_GRABBED
/* available since SDL 2.0.16 */
SDL_SetHint(SDL_HINT_ALLOW_ALT_TAB_WHILE_GRABBED, "0");
--
2.35.3
With best regards,
Volker
What about the other two issues? My other two patches override SDL2
defaults which aren't addressed yet in QEMU AFAICS. The Alt+Tab one
isn't even Windows-specific.
Something broke in the last few weeks. At the moment my Linux guest
fails to start on Windows with -display sdl. QEMU locks up a short
time after the Linux kernel starts.
This doesn't happen for me with 8.0rc4 and latest msys2 environment.
I'm running with `-accel whpx -vga none -device virtio-vga-gl
-display sdl,gl=on` and I even get decent OpenGL accelleration when
the Linux guest is in graphics mode, with wobbly windows etc.
Sometimes QEMU aborts when it can't map some OpenGL stuff when the
guest enters graphics mode but once that succeeds it runs absolutely
stable.
I'll try to find the commit that caused this regression.
I tested with QEMU 7.1 and sometimes it also locks up. This indicates
that the QEMU code doesn't have an issue.
With best regards,
Volker
Yes, this would be interesting.
Best regards,
Bernhard
With best regards,
Volker