DietPi - Mouse not visible on configuration screen

[dlasher]

The mouse pointer doesn't appear on the initial configuration screen, or upon bringing the config screen back up. The mouse is active, IE you can click and see random screen items highlight/select/change depending on where you're clicking. And if you start an emulation, the mouse then becomes visible within the AmigaOS.

HW: rpi3 model 3b+ / odroid N2+
OS: dietpi 8.25 / dietpi 9.02
Versions:

ii  amiberry                             5.6.4-dietpi2                    armhf        Optimized Amiga emulator for the Raspberry Pi and other ARM boards

or git clone current [5.6.6 as of 02/02/24] and compile as "make -j4 all PLATFORM=rpi3" with all libraries as recommended

apt install cmake libsdl2-2.0-0 libsdl2-ttf-2.0-0 libsdl2-image-2.0-0 flac mpg123 libmpeg2-4 libserialport0 libportmidi0 libsdl2-dev libsdl2-ttf-dev libsdl2-image-dev libflac-dev libmpg123-dev libpng-dev libmpeg2-4-dev libserialport-dev libportmidi-dev

FWIW, grabbing from ZIP (https://github.com/BlitterStudio/amiberry/releases/download/v5.6.6/amiberry-v5.6.6-debian-bullseye-armhf-rpi3.zip) the onscreen mouse works correctly.

[midwan]

I think this is an issue with the platform, not Amiberry itself. It uses the system cursor for the GUI.
It's interesting that the pre-compiled binary behaves differently however. Those are compiled on Debian with the same requirements installed.

@MichaIng - Maybe you have any ideas?

[MichaIng]

I can replicate the issue on Odroid N2, also with Amiberry 5.6.5 and 5.6.6.

@dlasher
Do I understand correctly that you face the same issue when you compile against the SDL2 libraries shipped by Debian, i.e. SDL2 v2.26.5?

We compile against latest upstream SDL2. However, the last release was just 3 days ago, and the one before, v2.28.5, was on November 2nd, where I am pretty sure it worked in between. And v2.30.0 does not fix it either. Hence it really seems to be related to a change in Amiberry, not in SDL2, in combination with some DietPi-specifics, it seems.

Starting systemd-logind does not make a difference, just in case. Also starting Amiberry directly from console, instead of via systemd service, does not make a difference.

What is strange is that I definitely tested the current RPi build on RPi Zero W, since we switched form DispmanX to SDL2 video backend, and I tested this as major change. Will do so again.

EDIT: And indeed, here on RPi Zero W it works, cursor is visible. This is with Amiberry v5.6.5 linked against SDL2 v2.28.5, one of the combinations which did not work on Odroid N2 (meaning no visible cursor there).

Tested with Amiberry v5.6.6 linked against SDL2 v2.30.0, and it works well likewise, and did not on Odroid N2. Both systems should be pretty similar, regarding userland setup. Of course RPi Zero W uses Raspbian Bookworm and a different kernel, Odroid N2 Debian Bookworm with 64-bit kernel and userland.

I am open for ideas how to debug, as I am not sure where to start. More tests could be done with a Raspbian image on RPi 3: https://dietpi.com/downloads/images/DietPi_RPi-ARMv6-Bookworm_Amiberry.img.xz
If this works well, another test would be 32-bit Debian, to check whether Raspbian vs Debian, or 32-bit vs 64-bit makes the difference: https://dietpi.com/downloads/images/DietPi_RPi-ARMv7-Bookworm_Amiberry.img.xz

[midwan]

@MichaIng
Could you also recreate what was mentioned above, that the pre-compiled binary seems to work as expected?
That's what I found most surprising.

[MichaIng]

On the Raspberry Pi 5 with 64-bit userland, the mouse is visible with our build 🤔. So it works on Rasberry Pi Zero W (32-bit, Raspbian) as well as on Raspberry Pi 5 (64-bit Debian), but not on Odroid N2 (64-bit Debian). Strange. @midwan you have no Odroid N2 builds, do you? As otherwise I have no system where it does not work and where I could test your builds 🤔.

[midwan]

@MichaIng
I don't have an Odroid N2 to test with either, so I don't have pre-compiled binaries for it I'm afraid.
But from what I remember, this issue with the mouse pointer only happened on Odroids in the past, and only if running from the console - you obviously had a mouse pointer if you run things under X.

But I don't know the reason behind it. I'm guessing it has something to do with the platform drivers, considering SDL2 is the same across all of these?

For a while there was a work around that I used: I created a custom cursor with SDL2, and that was visible in these cases also. But custom cursors were not supported in all platforms either, leading to similar problems elsewhere, so I eventually removed that. Perhaps it would help if I bring it back as an option, enabled for the cases this happens (I don't have a full list of those).

[MichaIng]

First of all, we switched our RPi Amiberry builds from DispmanX to SDL2 targets with the same commit where I added Amiberry 5.6.5 dependencies cmake and libportmidi, so the 5.6.4-dietpi2 build form OP is still using DispmanX. @dlasher could you try updating Amiberry on your RPi 3, and see whether this resolves the issue?

dietpi-software reinstall 108

The make -j4 all PLATFORM=rpi3 build you did is using DispmanX as well, so for the RPis, this could be the relevant difference. But the Odroid builds of course always use SD2, no there is more about it.

But I don't know the reason behind it. I'm guessing it has something to do with the platform drivers, considering SDL2 is the same across all of these?

Yes, after the move from DispmanX to SDL2 graphics backend, all our builds for ARM systems use the same SDL2 KMS/DRM GLES2 stack. All other SDL2 backends are actively disabled, so it is not possible that e.g. the Odroid uses a different one due to different hardware capabilities.

[midwan]

@dlasher
Any updates on this, regarding @MichaIng suggestion above?

[midwan]

@MichaIng does this happen to all Odroids? I still have an old XU4 around here somewhere, wondering if it's worth setting it up to test this...

[MichaIng]

Indeed, same issue on my Odroid XU4. I'll rebuild with latest Amiberry (and SDL2 libs), just to be sure.

[dlasher]

@dlasher Any updates on this, regarding @MichaIng suggestion above?

Apologies - haven't had time to circle back - will try this weekend.