#384 Another hanging Alt problem on Windows

[Manuel Bilderbeek]

Wolf reports:
[18:17] <WolfPC2_> als ik alt tab vanuit openmsx, en dan weer terug alt tab, dan blijft de alt hangen of zo
[18:17] <WolfPC2_> doe ik dan f4 voor 'list', dan sluit ik dus m'n window

Translation: if I Alt-Tab from openMSX and then back, the Alt seems to get stuck or something. If I then press F4 for LIST, the window closes.

Not good if you're in the middle of writing a program!

I couldn't reproduce this on my Linux box.

[Max Feingold]

Does this repro in windowed mode, or only full screen?

[Manuel Bilderbeek]

<WolfPC2_> it's window
<WolfPC2_> I never run full screen
<WolfPC2_> and I'm @ dev10613, so dunno...

[Patrick van Arkel]

I thought we went over this 2 weeks ago already. Anyway this is related to the ALT problem when going full screen. And ALT indeed 'hangs' when switching with ALT-TAB the same way it hangs when entering full screen.

alt-tab switching and pushing enter results in full screen so it's not related to F4 but any ALT-[KEY] combination.

https://sourceforge.net/tracker/index.php?func=detail&aid=1157373&group_id=38274&atid=421861

See link above, and please don't open a bug report for every key combination out there.

[Max Feingold]

I think this issue may be different than 1157373. The problem with full-screen to window transitions and vice-versa is that the window that is destroyed and re-created is also responsibile for posting events. When the window is gone, there's a time window (no pun intended) where key press events (up or down) may be lost.

In this case, there is no window destruction or recreation. I should take a look and see if there's something in SDL that might be fixable here.

[Patrick van Arkel]

Max,

Please take a look at your alt-space suppressor I have a feeling it might be related

Patrick.

[Max Feingold]

Should be fixed with revision 11302 (in VC++ builds, at least, as NO_GETKEYBOARDSTATE needs to be defined when building SDL).

In short, there were two places in SDL where the SDL_ModState was being set to KMOD_LALT, even when that key was no longer being pressed. I worked around both, and things seem to be working better now.

There is a small possibility of regression here; I'm not 100% confident that defining NO_GETKEYBOARDSTATE is safe - however, it disables what appears to be an entirely redundant key press detection mechanism inside SDL that doesn't appear to work at all reliably.

(Note that this does not address the ALT+ENTER problem, which is a different issue entirely. However, it does appear to make that problem much more deterministic: ALT is flipped on full screen, and unflips on the way out.)

[Patrick van Arkel]

Please re-open bug report, although Max fixed the alt-tab problem there are some problems with some other keys.

[Manuel Bilderbeek]

As requested by e-mail (see Wouter's mail on openmsx-devel), Max, please clarify the status of this issue, as the NO_GETKEYBOARDSTATE define got reverted.

[Max Feingold]

I took another look at the bug today, and isolated the problem a bit more. It's close to what I thought the problem was, but even simpler.

In short, when SDL sees a WM_ACTIVATE message grant focus to the SDL window (in SDL_sysevents.c :: WinMessage()), it calls the WIN_GetKeyboardState function. This function calls the Win32 API GetKeyboardState() to determine whether various modifiers keys were being pressed at the time the window event was generated. This includes the SHIFT and ALT keys.

Unfortunately, when ALT+TAB is used to switch to the SDL window, often VK_LMENU (aka left-ALT) is in fact being pressed. So SDL runs off and marks the ALT key as being down (by calling SDL_SetModState with a bitfield that includes KMOD_LALT).

Unfortunately, Windows doesn't bother to tell the window that ALT is no longer being pressed (since technically, it never told the window that it /was/ pressed). So SDL just keeps on thinking that ALT is down. This is a bug in SDL.

[Patrick van Arkel]

until recent I had Max's path in place on SDL and openMSX was a joy to work with... it did not have any unwanted side effects. Because of the imminent release I've converted back to all original 3rd party files and now openMSX is a pain to work with when trying to do speedruns and using any alt related windows operation that either focuses/defocuses the openMSX window.

As per our openMSX Devel list e-mails (March 7th 2010) we labeled the solution as unsafe. However my experience with the patch have been nothing but good/great/grand/wonderful (etc)

Maybe a good time to reconsider the 'unsafe' statement, I've been testing openMSX extensively and ran into no ill side effects. Removing the 'patch' leaves a painful to use openMSX with the hanging alt-key (which disrupts an playback that might be going on at that moment)

[sqweek]

Hey there. Forgive me if this is out of place as I have no idea what openmsx is and this bug is 5 years old. I came across it via google while investigating a similar issue and since I seem to have a workaround wanted to finish the story :).

Max's assessment is accurate regarding the WM_ACTIVATE/GetKeyboardState situation - Windows is essentially telling SDL that alt is pressed but never tells it that alt was released. It appears that Windows doesn't necessarily update the keyboard state before the WM_ACTIVATE message arrives.

If you defer the GetKeyboardState call until an input message arrives, however, then it seems to give you a consistent story. So the workaround appears to be to set a flag when receiving WM_ACTIVATE, and the next time you need to check whether a key is down give GetKeyboardState a call to make sure your internal state is consistent.

Source: http://referencesource.microsoft.com/#PresentationCore/Core/CSharp/System/Windows/Interop/HwndKeyboardInputProvider.cs

Specifically the OnSetFocus function, which says:

            // This is how we deal with the fact that Win32 sometimes sends
            // us a WM_SETFOCUS message BEFORE it has updated it's internal
            // internal keyboard state information. <snip>