WinUAE joypad does not work after upgrade

[Zak]

No, when it stopped working in fullscreen, it still didn´t work when switching to windowed mode.

1) Had never a problem with mouse or keyboard.

2) No other gamepad available, sorry.

3) Window mode

run in terminal:
C:\Program Files (x86)\WinUAE>winuae -log -inputlog 4

Yes, I can confirm the previous post.

Xbox 360 gamepads keep working in windowed mode. Tried several setting changes, no problems.

Then changed to fullscreen. One gamepad stops working. Switched back to windowed mode, it works again.

Logs atached.

run in terminal:
C:\Program Files (x86)\WinUAE>winuae -log -inputlog 4

Case A)
Starting WinUAE in *windowed* mode.
Gamepads work perfectly.
Switch to fullscreen.
After changing settings, one gamepad stops working.
Switch to window mode.
Gamepad starts working again.

Case B)
Starting WinUAE in *fullscreen* mode.
Gamepads work perfectly.
After changing settings, one gamepad stops working.
Switch to window mode.
Gamepad does *not* work in window mode, neither back in fullscreen mode.

configs are attached

[Zak]

I played a little around and it seems, when I choose 50 Hz Pal as refresh rate in the display folder (instead of default refresh rate), everything seems to work in fullscreen. At least on my machine.

Do you mean Display->Screen->"Default refresh rate"?

At my computer/monitor there is no 50 Hz Pal option available. Only 60 Hz NTSC, 100 Hz PAL, 120 Hz NTSC, 140 Hz.

Using the 100 Hz PAL option does not prevent the error (at least here).

Nethertheless since it is a Gsync Monitor I get real 50 Hz in fullscreen with "Default refresh rate".

Is there really a correlation between screen refresh rate and Gamepad input? Would we strange...

[Zak]

That´s correct. Display->Screen->50Hz Pal
as I said on my machine. I don´t have 100Hz to choose.
Maybe try around what you got there, and maybe something works for your machine?

[Toni Wilen]

Fullscreen or refresh rate makes no sense.

Preview versions of Windows 10 had some weird bugs in RawInput (for example single event was received from joystick, then nothing until program was restarted..) but this was fixed in final version.

Do you have original Windows 10 release? (build 10240) or recently released November update ("1511", build 10586)

[Toni Wilen]

Test version: http://www.winuae.net/files/b/winuae.7z

Use same command line parameters, when pad stops working, keep pressing pad buttons next 10 seconds and then immediately press ALT-F4 to quit emulator. Then attach winuaelog.txt (no need for other log).

ALT-F4 quit guarantees that there is no extra logging and I can clearly see when pad stopped working.

[Zak]

Uploaded winuaelog-zak to the zone.
I upgraded to Windows 10 on tuesday, so I guess I got the bad version.
I tested the 50 Hz thing several times and it works.

[Toni Wilen]

Originally Posted by Zak

Uploaded winuaelog-zak to the zone.
I upgraded to Windows 10 on tuesday, so I guess I got the bad version.
I tested the 50 Hz thing several times and it works.

Above test version logs also Windows build number, you have november update.

Interestingly your log shows continuous button presses, there is only about 1s gap between last press and WinUAE quit.

So it seems that there is nothing wrong with reading pad but something goes wrong when pad events get routed to emulated port or something like that.

[Toni Wilen]

winuae.7z updated again. Now even more logging, same logging session again, thanks.

[Zak]

uploaded winuaelog-zak2 to the zone
I still used -log -inputlog 4 parameters

Windows 1511 (build 10586.17)

WinUAE beta used from post #31

Please find winuaelog.txt attached.

[Toni Wilen]

Thanks. Both logs show same problem which explains it perfectly. Handle value of input device can change when rawinput is temporarily unregistered, apparently only under Windows 10 and only in some specific circumstances.

Fix coming later..

[Zak]

Great! Thanks for your support.

[Toni Wilen]

winuae.7z updated. There is no guarantee this fixes it, hopefully it does.. Include new log, even if it works.

I still don't have any idea why it happens (device handle gets changed without removing/inserting the device, handle that application is supposed to use as a device identifer..), it is also handle that is not "owned" by application, it can't be locked (or similar) and there is nothing mentioned in API documentation.. It is either undocumented feature or a bug (It could be a bug if it didn't exist until Windows 10 build 10586. I can't duplicate it but these kinds of odd things usually have multiple dependencies.. HID RawInput is still very rarely used)

Latest beta works fine (5 min tested). Changed several settings via F12, both gamepads kept working. Great Job, thanks a lot!

Please find logs attached.

[Toni Wilen]

Thanks. Log shows what I assumed, handle value changes but workaround code correctly fixes it. Hopefully this is fully fixed now

[Zak]

Yes, new update works fine. In windowed mode and fullscreen. Thanks!