WinUAE forgets pressed keys on display mode change

[mark_k]

On real hardware, when you have several custom screens open you can press and hold the left Amiga key, then tap M repeatedly to cycle the screen order.

On WinUAE there's a small problem when the display mode changes. It happens when the display changes from a native mode to RTG or vice versa. It also happens when VGA resolution autoswitch is enabled and the display changes from (for example) PAL to HIGHGFX:1024×768 (both native modes).

When the display mode changes, WinUAE forgets which keys are pressed. So even though you continue to hold down the left Amiga key, WinUAE thinks it isn't pressed. You have to release and press lAmiga again to continue cycling between screens.

[Toni Wilen]

It is by design. If WinUAE needs to close/open the window/screen, it can miss key releases.

It is far more annoying to get stuck keys than keys that are force-released before mode switch.

[mark_k]

While older versions of WinUAE did close and reopen the emulation window on mode change, the current version doesn't. And the key-forgetting also happens with native-to-native screen changes if resolution autoswitch or VGA mode resolution autoswitch is enabled. Log shows something like
window already open (829x353 1088x800)
on mode change, then WinUAE seems to reallocate D3D-related things for the new mode.

Could you use GetRawInputBuffer after a mode change to (hopefully) pick up any key events you might have missed?

[Toni Wilen]

When it is safe to "release" all keys, it is too early to know if window needs to be reopened (in worst case it could be fullscreen mode change). Amiga key input handling is core emulation code that does not know (and must not know) anything about what happens in host specific code.

It is not trivial problem to solve.

There is no guaranteed way to know current state of keyboard in rawinput.

[mark_k]

Have you considered using an invisible window to receive raw input? That could stay open, so shouldn't lose any events. Googling for raw input invisible window showed Minimal Key Logger Using RAWINPUT though I guess that example won't tell you much you're not already familiar with.

[Toni Wilen]

I did some adjusting, perhaps it works but I'll blame you if stuck keys happen

(It may have been old-style non-rawinput mode that required more careful special handling)

[mark_k]

Thanks, very quick testing of lAmiga held plus tapping (or holding) M didn't seem to lose key state with native->native mode switching. Key state is lost when switching between RTG and native, where native is windowed, RTG full-screen. But that was testing on Wine, need to check actual Windows yet.

[mark_k]

Testing on Windows 10...

With both native and RTG set to full-screen, keyboard state is lost on switching between native and RTG screenmodes. I see the desktop flash briefly when that happens, so maybe you're re-initialising more than is necessary then?

The same happens with native and RTG both full-window.

[mark_k]

Related to this issue, probably not worth its own thread...

The mouse becomes uncaptured on a full-screen to windowed change, e.g. when pressing lAmiga-M would change between RTG and native modes. That can be kind of annoying if you use the pause when mouse uncaptured option.

[Toni Wilen]

Only windowed to windowed mode keeps keyboard state. Any other change will still lose keyboard state. (Fixing this would be really painful)