Workaround found for running WinUAE under Wine/Linux

[mark_k]

Hi,

Here's some good news for people who want to run WinUAE under the Wine Windows emulation.

For some time now, WinUAE has run mostly fine under Wine, except for one thing. When you press F12 to open the settings window, dismissing it by clicking OK, Cancel etc. causes the window to close then re-open. That repeats again and again, making typical use of WinUAE impossible.

The cause seems to be that Wine still thinks F12 is held down when the settings window is dismissed, so WinUAE immediately re-opens it. [Possibly because the main window never receives an F12 key-up event; the settings window is active when the user releases F12.]

The workaround: Once the settings window appears, click the main window to activate it, then press and release F12. When you dismiss the settings window, it will close and not re-open. Yay!

(Alternatively you can press and hold F12 to open the settings window, click in the main window, then release F12.)

Slightly related to this -- but of course the main issue is the bug in Wine -- there appears to be a bug in WinUAE's keyboard handling even under Windows. Try this in WinUAE running under Windows (Vista):

• Run WinUAE, select a disk image etc. and start the emulation.
• When the emulation is running, press F12 and keep holding it down.
• The settings window appears, taking focus from the main window.
• Still keeping F12 pressed down, click in the main window to activate it, then release F12.
• Click in the settings window and press the OK or Cancel buttons.
• The settings window closes and re-appears! It only re-appears once however, so clicking Cancel a second time goes back to the emulation as normal.

I wonder whether a workaround for the Wine problem could be put into WinUAE. Maybe WinUAE checks the current F12 key state, rather than checking for an F12 key-down or key-up event? If it checked for F12 key-down (or F12 key-up instead), that would hopefully eliminate the Wine problem, and possibly fix the actual bug described above.

I hope that helps someone.


-- M

[Anubis]

Can't you just in WinUAE program another button to open emulators properties??

[mark_k]

Originally Posted by Anubis

Can't you just in WinUAE program another button to open emulators properties??

I think the bug in Wine is not related to the F12 key specifically, so the same thing would happen if any other key were used to bring up the settings window.

[OddbOd]

If you're not using fullscreen a simpler way of avoiding the WINE stuck key problem is to open the config window by clicking Power on the status bar. I don't know if your suggestion would permanently eliminate the problem but it's worth a try

[Toni Wilen]

Too late for 1.5.2 but maybe there really is something wrong.. (both in wine and winuae..)

[mark_k]

Another workaround is needed for the main window graphics, since Wine DirectDraw support is broken. Enable the Direct3D filter to fix the problem.

[With the default DirectDraw output, the graphics initially seem to be fine. But if you move or resize another window in front of the WinUAE main window, the WinUAE display shows through. And if you minimise the WinUAE window, the whole screen turns black.]

[andreas]

Originally Posted by Anubis

Can't you just in WinUAE program another button to open emulators properties??

Why program one if there's already one "button"?

On windowed mode, click on POWER LED ... it's magic huh

[Toni Wilen]

Originally Posted by mark_k

I wonder whether a workaround for the Wine problem could be put into WinUAE. Maybe WinUAE checks the current F12 key state, rather than checking for an F12 key-down or key-up event? If it checked for F12 key-down (or F12 key-up instead), that would hopefully eliminate the Wine problem, and possibly fix the actual bug described above.

WinUAE reads keyboard using DirectInput in buffered mode = it gets key up/down messages.

GUI keydown message is lost probably because DirectInput devices are released when WinUAE loses focus. (or other applications wouldn't be able to use it, WinUAE uses DirectInput keyboard in exclusive mode because it is the only way to read Windows keys and other keys without side-effects)

I can post keyboard debug logging versions if someone is interested in running it under Wine.

[mark_k]

Originally Posted by Toni Wilen

I can post keyboard debug logging versions if someone is interested in running it under Wine.

Yes, please do!

[Toni Wilen]

Keyboard test version attached.

Every key press and release outputs following message to log: (use -log to see it in realtime)

"x: yy z" where x = number of event if multiple events in buffer (normally zero), yy = keycode, z = press(1)/release(0)

[mark_k]

I ran the test version under Wine.

Pressing F12 while the emulation is running, get:

Press and release F12]
0: 58 1
winuae_inactive(0)
[Settings window opens, click Cancel]
winuae_active(0)
58 -> 1
winuae_inactive(0)
[Settings window opens, click Cancel]
winuae_active(0)
58 -> 1
winuae_inactive(0)
[Settings window opens, click Cancel]
winuae_active(0)
58 -> 1
winuae_inactive(0)
[Click in main window]
winuae_active(0)
[Press and release F12. Click in settings window.]
winuae_inactive(0)
[Click Cancel]
winuae_active(0)

There are some other keyboard issues in Wine, specifically the left Amiga key (left Windows key), right Amiga (menu key) and Pause keys do not function. Hopefully I can fix that by changing the key mapping, but if it's of any interest the output when those keys are pressed and released is:

[Left Windows key]
0: 61 1
0: 61 0
[Menu key]
0: 63 0
0: 63 1
[Pause key]
0: 45 1
0: 45 0

There is another keyboard issue under Windows (Vista). Pressing Alt-Tab then releasing both keys works okay. But holding down Alt, and pressing & releasing Tab several times to switch between different applications doesn't. Windows seems to forget that Alt is being pressed, so the second press of Tab results in input to the selected application (Notepad or whatever), as if the user pressed Tab alone.

[Toni Wilen]

Originally Posted by mark_k

I ran the test version under Wine.

Pressing F12 while the emulation is running, get:[code]Press and release F12]
0: 58 1
winuae_inactive(0)
[Settings window opens, click Cancel]
winuae_active(0)
58 -> 1
winuae_inactive(0)
[Settings window opens, click Cancel]
winuae_active(0)
58 -> 1

Ok, Wine bug seems to be something like this:

- IDirectInputDevice8_GetDeviceData() returns F12 pressed (0x58, state=press)
- WinUAE unacquires all DirectInput devices
- open GUI
- user releases the key
- exit GUI
- acquire DirectInput devices
- IDirectInputDevice8_GetDeviceState() returns keyboard state array with F12 still pressed.

(EDITED, was wrong previously)

[mark_k]

Great, thanks a lot for that! I'll update the Wine bug report with that info and hopefully one of the Wine devs will fix it.

[Fackamato]

Originally Posted by mark_k

Great, thanks a lot for that! I'll update the Wine bug report with that info and hopefully one of the Wine devs will fix it.

Any update on this? Where's the wine bug report?

Is WinUAE usable with wine, or is it too slow?

[mark_k]

Originally Posted by Fackamato

Any update on this? Where's the wine bug report?

Is WinUAE usable with wine, or is it too slow?

The Wine bug report is here. The problem still affects Wine 1.1.9.

As for is it usable, just try it!

Apart from the reappearing settings window (which does get a bit annoying after a while) the emulation is perfectly usable. Make sure you use the OpenGL filter though. DirectDraw is broken in Wine (but maybe it works with CrossOver by Codeweavers; I need to test that some time), and the Direct3D output, while it works okay, seems to run at a reduced frame rate for me. That is, it looks like every other frame is skipped with Direct3D output, so scrolling is not silky-smooth like it should be.