Pcsx2: TAS recording functionality not working on Linux

[thegamingrestoration]

PCSX2 version:
PCSX2 1.5.0-20190517234655 - compiled on May 18 2019

PCSX2 options:
Preset: Safe (Default)

Relevant: https://github.com/PCSX2/pcsx2/pull/2412

Description of the issue:
I've been testing the new TAS recording options on Windows, and I was pleasantly surprised by how good they work; but when I tried them on Linux, the emulator couldn't start the game. It just froze before even initializing the BIOS:

PCSX2 1.5.0-20190517234655 - compiled on May 18 2019
Savestate version: 0x9a0e0000

Host Machine Init:
    Operating System =  Linux 5.0.11-24-tkg-pds x86_64
    Physical RAM     =  5864 MB
    CPU name         =  Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
    Vendor/Model     =  GenuineIntel (stepping 07)
    CPU speed        =  3.389 ghz (8 logical threads)
    x86PType         =  Standard OEM
    x86Flags         =  bfebfbff 1fbae3ff
    x86EFlags        =  28100000

x86 Features Detected:
    SSE2.. SSE3.. SSSE3.. SSE4.1.. SSE4.2.. AVX

Installing POSIX SIGSEGV handler...
Reserving memory for recompilers...

Loading plugins from /usr/lib32/pcsx2...
(GameDB) 9771 games on record (loaded in 143ms)
    Bound   GS: libGSdx.so [GSdx (GCC 8.3.0 AVX/AVX) 1.1.0]
    Bound  PAD: libonepad-legacy.so [OnePAD 20190517234655 1.3.0]
    Bound SPU2: libspu2x-2.0.0.so [SPU2-X 2.0.0]
    Bound CDVD: libCDVDnull.so [CDVDnull Driver 20190517234655 0.6.0]
    Bound  USB: libUSBnull-0.7.0.so [USBnull Driver 20190517234655 0.7.0]
    Bound   FW: libFWnull-0.7.0.so [FWnull Driver 20190517234655 0.7.0]
    Bound DEV9: libdev9null-0.5.0.so [DEV9null Driver 20190517234655 0.5.0]
Plugins loaded successfully.


** (PCSX2:15431): WARNING **: 19:45:20.098: Invalid borders specified for theme pixmap:
        /usr/share/themes/Breeze-Dark/gtk-2.0/../assets/line-h.png,
borders don't fit within the image
[REC]: Started new recording - [/home/xxx/Desktop/sh3.p2m2]
Initializing plugins...
    Init GS
    Init PAD
    Init SPU2
    Init CDVD
    Init USB
    Init FW
    Init DEV9
Plugins initialized successfully.

Patches: No CRC found, using 00000000 instead.
Opening plugins...
    Opening GS
Overriding 'Framelimiter_SlomoToggle': assigning l (instead of Shift+Tab)
Overriding 'GSwindow_OffsetReset': assigning Alt+Ctrl+5 (instead of Alt+Ctrl+Num /)
Overriding 'Sys_RecordingToggle': assigning r (instead of F12)
OpenGL information. GPU: GeForce GT 1030/PCIe/SSE2. Vendor: NVIDIA Corporation. Driver: NVIDIA 430.14
INFO: GL_ARB_sparse_texture is NOT SUPPORTED
Override GL_ARB_sparse_texture detection (Disabled)
INFO: GL_ARB_sparse_texture2 is available
INFO: GL_ARB_gpu_shader5 is available
INFO: GL_ARB_shader_image_load_store is available
INFO: GL_ARB_compute_shader is available
INFO: GL_ARB_shader_storage_buffer_object is available
INFO: GL_ARB_texture_view is available
INFO: GL_ARB_vertex_attrib_binding is available
INFO: GL_ARB_clear_texture is available
INFO: GL_ARB_multi_bind is available
INFO: GL_ARB_direct_state_access is available
INFO: GL_ARB_texture_barrier is available
INFO: GL_ARB_get_texture_sub_image is available

Current Renderer: OpenGL (Software renderer)
Available VRAM/RAM:3318MB for textures
    Opening PAD
GSdx Lookup CRC:0
    Opening SPU2
Request SDL audio driver: pulseaudio
Opened SDL audio driver:    Opening CDVD
pulseaudio
isoFile open ok: /run/media/xxx/BAK_LINUX/SH3.iso
    Image type  = DVD
 * CDVD Disk Open: DVD, Single layer or unknown:
 * * Track 1: Data (Mode 1) (1750112 sectors)
    Opening USB
    Opening FW
    Opening DEV9
McdSlot 0 [File]: /home/xxx/.config/PCSX2/memcards/Mcd001.ps2
McdSlot 1 [File]: [disabled]
Plugins opened successfully.
EE/iR5900-32 Recompiler Reset
    Bios Found: USA     v02.30(20/02/2008)  Console
# Initialize memory (rev:4.00, ctm:196Mhz, cpuclk:147Mhz detected)

How to reproduce the issue:
-System --> Enable Recording Tools
-Recording --> New
-Record From --> Power-On

PC specifications:
CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
GPU: GeForce GT 1030/PCIe/SSE2. Vendor: NVIDIA Corporation. Driver: NVIDIA 430.14
OS: Linux 5.0.11-24-tkg-pds x86_64

[tadanokojin]

@xTVaser could you perhaps take a look at this? I look into it briefly and it appears linux is getting hung up on HandleFrameAdvanceAndStop for some reason. Not really familiar with this code so perhaps you can provide some insight.

[xTVaser]

👍 Bit late to seeing this issue, thanks for the ping. Things have been busy but I plan to get back into fixing up some of the open issues with the TAS tools soon (early 2020 hopefully) of which this sounds like the top priority. The original contribution was done on Windows so I'm not really surprised, I'll setup a linux environment and try to figure it out.

[xTVaser]

Update / Repro notes

I finally got around to setting up a linux environment to attempt to debug this issue and I'm able to reproduce the hang. The hang/freeze description isn't very detailed, but for me the emulator gets stuck on the <Paused> state, and it cannot be resumed (a similar situation happens when starting from power on as mentioned originally). PCSX2 is still in-general running and responsive, it's just the game that is paused.

This _appears_ to be because the recording keybindings are unreliable on linux _even before starting a recording_. For example, without starting a recording (but with the tools enabled), it's difficult to even trigger the pause-command (Shift-P by default) and then subsequent toggle-pauses are ignored almost as if the keybinding has been unbound. Even the save-state commands bound to the num-pad (gated behind turning on recording tools) do not work once paused (yet i can trigger a save-state from the System menu still) https://github.com/PCSX2/pcsx2/blob/9788f6db2cc3cf4c1561e1f894d94b495358779f/pcsx2/gui/GlobalCommands.cpp#L508-L511

Findings

It's expected that a new recording is always supposed to start paused. So this is definitely the first problem that has to be identified and solved, why do the keybindings have such different behaviour on linux compared to windows? I see different implementation on key handling events for linux, as well as I seem to only be able to use onepad, where as on windows I use LilyPad, but the save-state commands not working seems to rule that out.

I've verified that pcsx2 is getting the correct key-combination (via the > Key: .... logs). But when adding additional logs on the recording commands or the general PCSX2 event handling functions, nothing gets hit. This is puzzling because they are declared in the exact same way as other commands that work fine (Turbo Mode, etc). When emulation is paused, the following code was implemented to commands to their handlers, and I've verified this in Windows (when un-pausing, it passes through this code, then to DirectKeyCommand:
https://github.com/PCSX2/pcsx2/blob/9788f6db2cc3cf4c1561e1f894d94b495358779f/pcsx2/gui/AppMain.cpp#L623-L635

I'll try to keep digging into this, but I might need some recommendations for how to effectively debug pcsx2 on linux. I tried to just attach gdb to the process, but that doesn't work very well once a game is launched: after continuing on seg faults in IR5900.cpp, it basically hangs and the game doesn't continue to launch (works fine without gdb though).

[lightningterror]

Hangs can also happen on Windows, they are less frequent tho.

[xTVaser]

@lightningterror are there any details on how to reproduce those windows hangs? Or what the hang actually is? Is it similar to what I see (emulation paused, but console still logging / pcsx2 main window still responsive / ~default keybindings still working~) or does the entire application lock-up?

[lightningterror]

@tadanokojin can you give him the details how to reproduce it and such?

[xTVaser]

Alright so I did some more digging and I think I'm getting to the root of atleast some of the issues, unsure about the Windows issue but I'll wait for more information.

Number one, the unreliability of the key bindings. It looks like on linux there is a difference between, for example Shift+P and Shift+p. I noticed this because very rarely, Shift+p is output to the dev logs with a distinct code than the former, so adding bindings for the capitalized varient (despite the advice of the docstrings in these files) seems to resolve the unreliability.
https://github.com/PCSX2/pcsx2/blob/79db01d7ed01a4f3de06a8d8dc5c5e7099ef9d2e/pcsx2/gui/FrameForGS.cpp#L103-L104

Number two, the issue for why inputs aren't being sent when emulation is paused. I believe this is a bug in OnePad's implementation, I'll confirm this on windows (assuming Windows supports OnePad) soon. I was a bit wrong with my previous comment, _all_ key events are ignored when emulation is paused, which seems to make sense given the following:

So as mentioned previously, when emulation is paused, key events are sent through "manually" to PadKeyDispatch and ultimately to DirectKeyCommand _if it's a KEY_DOWN event_. This is done by non-recording related code as well (infact im probably going to simplify the recording code to something like this as well):
https://github.com/PCSX2/pcsx2/blob/79db01d7ed01a4f3de06a8d8dc5c5e7099ef9d2e/pcsx2/gui/AppMain.cpp#L579-L587
However, the keyEvent from OnePad's implementation of PADkeyEvent() always returns an object with no key information and with an event type of 0 (1 is key pressed, 2 is key released).
https://github.com/PCSX2/pcsx2/blob/79db01d7ed01a4f3de06a8d8dc5c5e7099ef9d2e/plugins/onepad/onepad.cpp#L336-L339
This means the key event is ignored (as it has no idea what key was pressed, etc) and commands do not propagate:
https://github.com/PCSX2/pcsx2/blob/79db01d7ed01a4f3de06a8d8dc5c5e7099ef9d2e/pcsx2/gui/AppMain.cpp#L305

Infact, one-pad's implementation seems to be directly taken from the PadNull plugin, I assume a template of some sort with stubs.
https://github.com/PCSX2/pcsx2/blob/79db01d7ed01a4f3de06a8d8dc5c5e7099ef9d2e/plugins/PadNull/Pad.cpp#L165-L169

So it looks like this issue _could_ effect that other portion of code I mentioned that wasn't recording related, but I don't have enough context to be concerned. To me, it looks like the passing along of events to plugins / PadKeyDispatch _never_ would occur because of:
https://github.com/PCSX2/pcsx2/blob/79db01d7ed01a4f3de06a8d8dc5c5e7099ef9d2e/pcsx2/gui/AppMain.cpp#L581

In contrast, LilyPad has a much more fleshed out implementation https://github.com/PCSX2/pcsx2/blob/master/plugins/LilyPad/LilyPad.cpp#L1566 which is why I assume I havn't seen the issue on Windows. Though, LilyPad has a huge swathe of windows-only code in that function, so I expect that my mileage may vary.

Questions

I'd like to try using LilyPad on linux, it builds fine but I can't open the plugin-settings. I presume there was an error of some sort because not only will the settings not open, but i can't interact with the game at all (I don't really see an obvious error though, it picks up my controllers and such). Is LilyPad expected to be broken on linux?

Also, it would be a nice coincidence if these Windows hangs occurred for OnePad users.

[arcum42]

It wouldn't particularly surprise me if OnePad was doing it wrong.

PADnull and GSnull were actually created later than the other null plugins, and were largely based on ZZOgl/ZeroGS and OnePad/ZeroPad.

LilyPad was originally Windows-only, and still mostly is. A start was made on porting it by greg, but the configuration dialog box was never implemented, though I believe the ini code is in there.

OnePad still has a fair amount of catching up to do with LilyPad, and LilyPad could still use to be properly ported...