64 bit build doesn't allow control of mouse pointer for Arm platform

[christianhaitian]

Describe I was able to successfully build a 64 bit (aarch64 for rk3326 devices such as the Odroid Go Advance) version of devilutionX. While it worked, the mouse point could not be controlled whether using the right analog stick or select+dpad.

To Reproduce Build in a 64 bit aarch64 environment with necessary dependencies in place as per compile instructions.

Expected behavior Allow mouse control in aarch64 environment as is possible with armhf.

Screenshots

Additional context What I noticed is that when attempting to move the mouse pointer, it constantly stayed in the very top left corner of the screen. So the game recognizes an attempt to move the mouse but doesn't.

[AJenbo]

Sounds a bit odd, especially considering that 64bit PC builds do not exhibit this issue. what kind of game controller are you using? Does 32bit builds on the same device work?

[christianhaitian]

Agreed. The game controller on this particular device (Anbernic RG351P) is a USB based controller that is built into the unit. I built a 32bit version of devilutionX (Armhf) it works just fine including being able to control the mouse pointer. I tried looking at the code to see if there was something somewhat obvious I could find but I couldn't find anything.

[glebm]

Use the master version. There are some controller issues in the latest release that are now fixed on master (#932 #934 #935).

I've recently submitted a batocera.linux package for devilutionx and the mouse control works just fine on RG351P.

For reference:

1. Buildroot package (trivial): https://github.com/batocera-linux/batocera.linux/blob/master/package/batocera/emulators/devilutionx/devilutionx.mk
2. Launcher script (batocera-specific): https://github.com/batocera-linux/batocera.linux/blob/master/package/batocera/core/batocera-configgen/configgen/configgen/generators/devilutionx/devilutionxGenerator.py

[christianhaitian]

As an update, using hardkernel's latest kernel update for the rk3326 platform that brought support for the Odroid Go Super, both the 32bit and 64bit builds no longer have working mouse. @glebm I tried the latest master and the specific git version that you linked to in your Batocera link above and I still have no mouse. Have some disappointed users on the Odroid Go Super and RG351P. ¯_(ツ)_/¯

[shantigilbert]

I have the same issue with the 64bit version (although 32bit still works for me using latest HardKernel kernel) no matter what I do (tried switching from 3 different SDL versions as well) same behavior, the mouse pointer just stays on the top left corner

I am building with -DBINARY_RELEASE=1 -DCMAKE_BUILD_TYPE="Release" -DDEBUG=OFF -DPREFILL_PLAYER_NAME=ON

EDIT: I have to add that same binary works fine on an Odroid N2+ on 64bit... so there must be something else either on the kernel or the libs that is making this not work.

I used SDL2.0.10, 2.0.11 and 2.0.12, while on my N2 I use SDL2.0.9

[AJenbo]

closing this as it a device issue and not related to the game

[shantigilbert]

Well after a few hours investigating this, I landed on trying the aarch64 version of Batocera, but to my surprise, this is also 32bit

file devilutionx 
devilutionx: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 4.4.0, stripped

Which is why @glebm says it works in Batocera, the issue is on 64bit, I cannot test the 64bit version in Batocera since the whole image is 32bit.

file libsodium.so.23.3.0 
libsodium.so.23.3.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped

for reference:

file devilutionx 
devilutionx: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, with debug_info, not stripped

So I think this issue is still related to DevilutionX (probably mixed with something else on the system)

just something to keep in mind.

[AJenbo]

Show me another 64bit SDL application on that system where it works.

[shantigilbert]

I wish I had one, sorry

Edit: To clarify, not saying that the issue is solely on DevilutionX (or that you should provide a fix), but I am sure the Batocera version will also not work on 64bit.

[AJenbo]

You should probably try to talk to the maintainers of the given system, they have the option to debug this.

[glebm]

The current batocera master is aarch64. I couldn't reproduce the issue there (if you try to repro this yourself, note that in the current master it's only possible to start games from ssh).

DevilutionX uses mouse events but not a hardware cursor. This is an uncommon set up but it's not a bug in DevilutionX. It's almost certainly an issue with the OS/SDL patches/etc.

Video: https://imgur.com/a/wLhc1FB

[shantigilbert]

The current batocera master is aarch64. I couldn't reproduce the issue there (if you try to repro this yourself, note that in the current master it's only possible to start games from ssh).

can you point me to where I could download it? the only one on the official site is 32bit which is where I downloaded it (v30) batocera-odroidgoa-30-20210302.img.gz

anyways, I will message you on discord if that is OK with you.

[glebm]

You'd have to build it from source

[shantigilbert]

Thanks, I rather wait for an official release :)

[Rh0gii]

Do we have any movement on this issue? I know that folks are busy. And I also want to recognize that there is a lot of awesome work that people have given us to enjoy in the OSes and RetroArch builds. This issue is understandably very likely a low tier issue...

Just wondering if there are any soft dates or assurance that this will be dealt with in a next update or patch...? Maybe an idea of when an update on this might occur... Sorry if my question is extremely noobish...

[AJenbo]

@Rh0gii this is a problem with Odroid, not DevilutionX, you need to speak to them about it.

[glebm]

It's not even a problem with Odroid, because it works just fine on Batocera master, which is aarch64 for odroid. It's a problem with the OS / distribution.

[shantigilbert]

@Rh0gii sorry, after many hours debugging, updating all the libraries I could think of and recompiling I stopped looking for a solution. As far as OGS distributions go, it only seems to work with Batocera (I have personally not tested it, since the 64bit is not public yet, and I do not have the space to compile it) no other OGS distribution I've tested works and I am lost on finding a solution, I have changed everything I could possibly think of and nothing seems to work. The only solution for me is using the 32bit version in a multi-arch environment, which is what I unfortunately will have to end up doing. I am sure this is not a Devilutionx issue, but someone with more knowledge will have to tackle this one as it makes absolutely no sense to me.

[Rh0gii]

what do you mean by "32bit" version? Do you mean running this off of 32bit "aarch"? Is this something like "retroarch"? And FWIW, I can't get this to run on RG351P as well. (running ArkOS nor 351ELEC).

[AJenbo]

32bit devilutionx running on a 64bit Odroid.

Retroarch is just a branding name of a game collection menu, it has nothing to do with 32bit/64bit/aarch or anything like that..

[shantigilbert]

@Rh0gii in 64bit mouse emulation does not work on, ArkOS, TheRA, 351ELEC, EmuELEC, it only works on Batocera. On 32 bit it works fine at least on EmuELEC. By 32 bit I mean the interpreter and libraries, devilutionX has nothing to do with retroarch.

Anyway I don't think we need to keep posting here as we have already determined it is not a devilutionX issue. (64 bit works fine on EmuELEC in Amlogic devices) But if I go back to trying to find the solution and If I find out the cause I will post it here just as information.

[shantigilbert]

@glebm I really don't mean to be a pain with this... but I just downloaded a fresh Batocera image, copied my Diablo data, nothing else is on this image, started the game and.... no mouse. I am using an OGS with https://updates.batocera.org/odroidgoa/stable/last/images/batocera-odroidgoa-30-20210302.img.gz

Can you point me to an image that has Diablo working on Batocera on the OGS? also, can you MD5sum your diablo data file? this is mine 68f049866b44688a7af65ba766bef75a diabdat.mpq

EDIT: I also updated to v31-dev, this seems to be 64bit but now there is not even an image when I run Diablo just sound :/

[AJenbo]

this is mine 68f049866b44688a7af65ba766bef75a diabdat.mpq

That's the original release, there is only one other known and the only difference is that the intro logo video had some bad frames.

[shantigilbert]

this is mine 68f049866b44688a7af65ba766bef75a diabdat.mpq

That's the original release, there is only one other known and the only difference is that the intro logo video had some bad frames.

Cool! thanks, I copied it from my original CD so I am sure then it is not the mpq file :)

[Rh0gii]

I have to say, I did the same thing that shantigilbert did and got the same result. still no mouse support running the game on Batocera 30 (3/2/2021 release) I used the diabdat.mpq (made sure it was all lower case) that I pulled from my GOG copy of the game.

[AJenbo]

Game controller support is not related to the MPQ file...

Can you point me to an image that has Diablo working on Batocera on the OGS?

He mentioned you need to build it from source as the fix is not in any of there releases yet.

[shantigilbert]

Yeah that might be it, but the version I am using right now is from 2021/03/20 so I assume his changes would already be there since his comment was 12 days ago and this version is from 11 days ago :P, I wanted to make a comparison between my setup and Batocera so I could debug it further

[AJenbo]

Releases are not produced same day directly from master. That version is actually 21 days behind master at this point.

[shantigilbert]

Stable release might be 21 days ago, but the Dev (beta) version I am using is from 11 days ago (2021/03/20) (https://batocera.org/upgrades/odroidgoa/beta/last/)... and his comment is 12 days ago, I assume they would be already implemented, anyways I will keep waiting :)

[AJenbo]

It could also be down to how releases are done that actually causes it to break...

I suggest filing the issue with them or you might be waiting for ever if they aren't aware: https://github.com/batocera-linux/batocera.linux/issues

[glebm]

@shantigilbert v31-dev is the one where it works but launching SDL2 apps from the menu doesn't work at all currently. SSH into the device, killall emulationstation, and run the command to start devilutionx from the terminal. You can see the command in logs/es*.

Batocera developers are aware that SDL2 apps currently do not start from the menu on master, no need to report.

Today's build of v31-dev: https://batocera.org/users/rtissera/batocera-31-dev/odroidgoa/

[shantigilbert]

Thank you, got it running and now I can compare :)

[shantigilbert]

FYI: As @glebm mentioned, I am now 99.9% certain the issue is related to the KMSDRM back-end on SDL, it seems SDL uses 2 KMS back-ends depending on how you compile it? One is a KMSDRM legacy which seems to be default on "cmake" and its the way I was compiling SDL (this one does not work) and the other one uses "configure" and it seems to need a proper GBM library as well as libdrm, this is the one used in Batocera and (I cannot confirm as I was not able to compile it yet) this is the one that seems to work.

How I tested it? Mouse emulation works on Amlogic using FBDEV backend, once I switch to KMSDRM (legacy) it does not work, with the exact same issue as the OGA.

After a few hours under a debugger, the biggest (and only difference it seems) between the other distros and Batocera is the KMSDRM back-end used (legacy vs new) and SDL2.0.9 up to 2.0.14 do not work on KMSDRM (legacy), All distros use the same kernel, same, u-boot, same mali blobs (as there are the only ones available)

Since to my understanding on Mali, GBM seems to be used in a wrapper and its not a "real" library per-se, so to be able to use this type of mouse emulation SDL needs to be compiled using the "new" KMSDRM alongside the GBM wrapper, I am not 100% sure if its an SDL2 bug (although it seems like it) or how to fix it other than compiling the GBM wrapper and SDL2 using "configure".

On another note, mouse emulation works fine on Scummvm, and on our own mouse emulation program (https://github.com/EmuELEC/EmuELEC/pull/551 video here: https://youtu.be/KeNqEbVDR40) both using SDL2 on both FBDEV and KMSDRM (legacy) in 32 and 64bit. EDIT: This type of mouse emulation also works with DevilutonX if ran on top.

Please note that I am NOT an SDL expert (or any other type of expert), maybe my "investigation" is wrong and I am totally off, but from all the hours working on this, this is the only cause I could find that made any sort of sense, also note that KMSDRM (legacy) is only broken on 64bit, 32bit works fine, so this might be a clue on what is wrong.

So with all that said, time for me to move on as my knowledge is not up to far to fix this, and the only solution I can think of is using the "new" KMSDRM back-end with the GBM wrapper (which again I have not been able to properly test as I have not compiled the GBM wrapper).

Thanks for the help and the patience!

[christianhaitian]

What I hope is final update on this, another developer by the name of southoz found a solution to this issue.
He states the following:

The only time the mouse location values were updated was when an SDL_MOUSEMOTION event was being triggered and the right stick movement was definitely not triggering that event.

Update Mouse location within the HandleRightStickMotion routine has fixed the issue on the OGS.

https://github.com/southoz/devilutionX/commit/6a82fdee333bfd68105344914a629caae6e90f8e

I've confirmed that this indeed resolved the issue for ArkOS. @shantigilbert will be patching this for EmuElec as well.

[glebm]

SetCursorPos calls SDL_WarpMouseInWindow so the bug is ArkOS's SDL or lower level (but I think @shantigilbert already figured out as much)

It'd be better to fix the underlying issue than to patch individual apps.

[christianhaitian]

The issue hasn't presented itself in any other SDL apps so not sure.

[shantigilbert]

Confirmed working with the patch. Not sure if its an SDL issue or something else, but considering all my other SDL apps work fine, and this patch fixes DevilutionX for me, I am good with using this patch even if it does not get merged, its just good to have a solution finally :D

[shantigilbert]

Just for completion sake, based on the patch posted before I modified the function directly and now this patch also fixes the mouse snapping.

https://raw.githubusercontent.com/EmuELEC/EmuELEC/6a0d96e76a3e9ed934f93f2199111155e9a79e11/packages/sx05re/emuelec-ports/devilutionX/patches/DevilutionX-fix-mouse.patch