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(+)

-- 
2.40.0

> 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,

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.

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. I'll try to find the commit that caused 
this regression.

With best regards,
Volker

Am 13. April 2023 17:54:34 UTC schrieb "Volker Rümelin" <vr_qemu@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.

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.

Yes, this would be interesting.

Best regards,
Bernhard

>
>With best regards,
>Volker

Am 13.04.23 um 22:43 schrieb Bernhard Beschow:
>
> Am 13. April 2023 17:54:34 UTC schrieb "Volker Rümelin" <vr_qemu@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.

>
> 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

> Am 13.04.23 um 22:43 schrieb Bernhard Beschow:
>>
>> Am 13. April 2023 17:54:34 UTC schrieb "Volker Rümelin" 
>> <vr_qemu@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
>

Am 14. April 2023 19:09:47 UTC schrieb "Volker Rümelin" <vr_qemu@t-online.de>:
>> Am 13.04.23 um 22:43 schrieb Bernhard Beschow:
>>> 
>>> Am 13. April 2023 17:54:34 UTC schrieb "Volker Rümelin" <vr_qemu@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.

As you wrote below I'll let you take care of it. Thanks!

> 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.

[x] Done

v2 is out!

Best regards,
Bernhard

>
>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");

Am 14. April 2023 06:53:18 UTC schrieb "Volker Rümelin" <vr_qemu@t-online.de>:
>Am 13.04.23 um 22:43 schrieb Bernhard Beschow:
>> 
>> Am 13. April 2023 17:54:34 UTC schrieb "Volker Rümelin" <vr_qemu@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,

Hi Volker,

>
>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.

Interesting. The keyboard is grabbed automatically for some reason when the guest enters graphics mode. Together with what you describe this could explain the difference in behavior I'm seeing.

Best regards,
Bernhard
>
>> 
>> 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
>

On Fri, 14 Apr 2023, Bernhard Beschow wrote:
> Am 14. April 2023 06:53:18 UTC schrieb "Volker Rümelin" <vr_qemu@t-online.de>:
>> Am 13.04.23 um 22:43 schrieb Bernhard Beschow:
>>> Am 13. April 2023 17:54:34 UTC schrieb "Volker Rümelin" <vr_qemu@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,
>
> Hi Volker,
>
>>
>> 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.
>
> Interesting. The keyboard is grabbed automatically for some reason when 
> the guest enters graphics mode. Together with what you describe this 
> could explain the difference in behavior I'm seeing.

Not sure how it works on Windows but keyboard grab may depend on the 
drivers or devices in the guest. I think using a usb-tablet may auto-grab 
mouse while using a mouse needs to click in the window to grab. Also not 
sure how this relates to keyboard at all so maybe this is not relevant 
here in which case sorry for the noise. I guess what I wanted to say is 
also check what command line you use (what input devices you VM has) and 
what guest side drivers you use that may have an effect (such as some 
vmware drivers could or maybe some other drivers). In any case first you 
should sync to make sure you're on the same page and testing the same 
thing to avoid some confusion. Sorry if this is not really helpful.

Regrads,
BALATON Zoltan

Am 13.04.23 um 22:43 schrieb Bernhard Beschow:
>
> Am 13. April 2023 17:54:34 UTC schrieb "Volker Rümelin" <vr_qemu@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.
>
> 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.

Hi Bernhard,

the keyboard behavior on Windows and Linux is identical. With the QEMU 
window activated and keyboard not grabbed, those key combos like Alt-Tab 
or Alt-F4 are sent to the host. With the QEMU window activated and 
keyboard grabbed they are sent to the guest. I'm not so sure if this 
should be changed only for SDL on Windows.

With best regards,
Volker

>> 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.
> Yes, this would be interesting.
>
> Best regards,
> Bernhard
>
>> With best regards,
>> Volker

Am 13. April 2023 21:40:29 UTC schrieb "Volker Rümelin" <vr_qemu@t-online.de>:
>Am 13.04.23 um 22:43 schrieb Bernhard Beschow:
>> 
>> Am 13. April 2023 17:54:34 UTC schrieb "Volker Rümelin" <vr_qemu@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.
>> 
>> 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.
>
>Hi Bernhard,

Hi Volker,

>
>the keyboard behavior on Windows and Linux is identical. With the QEMU window activated and keyboard not grabbed, those key combos like Alt-Tab or Alt-F4 are sent to the host. With the QEMU window activated and keyboard grabbed they are sent to the guest.

That's the behavior I'd expect. I've confirmed today with 8.0rc4 that patches 1 and 2 are needed to achieve this. I'm using a Windows 11 host and I'm compiling under msys2 on the same Windows host.

Best regards,
Bernhard

>I'm not so sure if this should be changed only for SDL on Windows.
>
>With best regards,
>Volker
>
>>> 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.
>> Yes, this would be interesting.
>> 
>> Best regards,
>> Bernhard
>> 
>>> With best regards,
>>> Volker
>