WinUAE under Wine

[gilgamesh]

WinUAE 1.6.1 works great under Wine 1.1.26 but for one thing:

The buttons don't work properly. Only 'reset' works wll. The other buttons (restart, quit, ok, cancel) just make the main menu close and instantly open up again.

Is there a chance that this could be amended?

[tero]

I think that's a problem of wine, did you try cedega?
Cedega runs much better when progs need DirectX

[hit]

thats a known problem, dont Press F12, but use middle-mouse-button and then click on [power] - so you get the working menu.
Edit: this works in window-mode, not sure about fullscreen.

[mark_k]

There is a workaround to the F12 problem, see http://bugs.winehq.org/show_bug.cgi?id=10643

[hit]

thnx for the workaround, it really works:

I have found a workaround to at least allow WinUAE to be used under Wine.
Before dismissing the settings window, click in the main window to activate it,
then press and release F12. You can then dismiss the settings window and it
will not reappear.

[gilgamesh]

Yeah, thanks for the help. That solves the problem for me.

Maybe WinUAE should still do something about it, since more and more people will change from E-UAE to WinUAE+Wine as long as the first stays unmaintained?

[TCD]

Originally Posted by gilgamesh

Maybe WinUAE should still do something about it, since more and more people will change from E-UAE to WinUAE+Wine as long as the first stays unmaintained?

I would rather say that the Wine authors should do something about it, since that Problem doesn't appear with Windows 2000, XP, Vista or 7.

[Toni Wilen]

Implementing workarounds for any kind of emulation (yes, I know wine isn't an emulator) is not a good idea. Developers won't get any bug reports and bugs won't get fixed. ("oh, it was apparently application bug, version x.y works fine, never mind")

I guess it is "acceptable" if fixing the bug would cause other problems or it can't be easily fixed (like JIT being too fast).

[mark_k]

There is a better workaround for the keyboard problem with Wine. It seems that using the -rawkeyboard command-line argument lets it work correctly. Start WinUAE like this:

wine winuae.exe -rawkeyboard

[mark_k]

Hi,

Today I tested WinUAE 2.3.2 under Wine 1.3.15. Using the -rawkeyboard option didn't solve the reappearing settings window problem. Can anyone else confirm that, and maybe also try under Wine 1.3.21? I'll update the bug entry on the Wine site with that info.

I tested several WinUAE versions. The -rawkeyboard option does solve the problem with WinUAE up to and including version 2.1.0. It doesn't work with WinUAE 2.2.0 and later.

Was the -rawkeyboard command-line option removed in WinUAE 2.2.0? Or was there some change to the keyboard handing code which could explain the different behaviour in 2.2.0 and later?

[gilgamesh]

wine 1.3.16 + WinUAE 2.3.4 beta 8 same problem

[Toni Wilen]

Rawinput has been default for some time now. Unless WinUAE detects misbehaving rawinput and disables it. (I remember there being some paranoid security software that disables rawinput without application knowing it which can't be detected without some extra tests!)

Check winuaebootlog. Always.

[mark_k]

Hi,

So the -rawkeyboard command-line option is a no-op now then. The relevant part of the bootlog (attached) is this:

RawInput enumeration..
RAWINPUT: found 0 devices
DirectInput enumeration.. Keyboards..
I=6F1D2B61-D5A0-11CF-BFC7444553540000 P=0AB8648A-7735-11D2-8C7371DF54A96441
'Wine Keyboard' 'Keyboard' 00000013 [Keyboard]

That was running WineUAE 2.3.2 under Wine 1.3.21 setting it to "emulate" Windows XP.

[Toni Wilen]

Originally Posted by mark_k

Hi,

So the -rawkeyboard command-line option is a no-op now then. The relevant part of the bootlog (attached) is this:

RawInput enumeration..
RAWINPUT: found 0 devices
DirectInput enumeration.. Keyboards..
I=6F1D2B61-D5A0-11CF-BFC7444553540000 P=0AB8648A-7735-11D2-8C7371DF54A96441
'Wine Keyboard' 'Keyboard' 00000013 [Keyboard]

That was running WineUAE 2.3.2 under Wine 1.3.21 setting it to "emulate" Windows XP.

What does "working" WinUAE version say? I don't see how it can work if it can't find any rawinput devices. (enumeration code is still the same)

[mark_k]

Originally Posted by Toni Wilen

What does "working" WinUAE version say? I don't see how it can work if it can't find any rawinput devices. (enumeration code is still the same)

This is strange. WinUAE 2.1.0 (the last version for which -rawkeyboard works around the Wine bug) also shows 0 rawinput devices!

Also, I noticed when testing WinUAE 2.3.2 under Wine, if I tap F12 very briefly, the settings window does not reappear when dismissed. If I press F12 normally the settings window does reappear. Perhaps that behaviour depends on the PC speed? If F12 is pressed for a very short time on a slower PC, the key might be released before the settings window is opened, which could avoid the problem.

In the attached archive are WinUAE 2.1.0 boot logs with and without the -rawkeyboard option. (The file is a Tar archive compressed with bzip2. The EAB forum doesn't accept attachments ending in .bz2, so I added .zip to the end of the filename. Remove the .zip extension before unpacking.)

There are also some Wine logs. I created those using a command like this:
WINEDEBUG=+key,+keyboard wine winuae.exe
then starting emulation, pressing F12 to bring up the settings window (if necessary clicking in the main window and pressing F12 again), then quitting.

The Wine logs probably won't make much sense if you're not a Wine developer but may provide some insight into what Wine does differently when -rawkeyboard is specified. Try "diff"ing the files winuae2100_key_keyboard_log.txt and winuae2100_-rawkeyboard_key_keyboard_log.txt