Amiberry activity leds (DF0: etc.) not working

[DJP75]

Creating a bug report/issue

Additional Information (if applicable)

• Software title | Amiberry on rpi4
• Was the software title installed freshly or updated/migrated? No matter,never worked
• Can this issue be replicated on a fresh installation of DietPi? Yes

Steps to reproduce

1. Assign a function (power , DF0: DF1: etc) to keyboard LEDs (numlock,caps,scroll) in Amiberry

Expected behaviour

• LED blinking as disk activity in emulator

Actual behaviour

• LED stays off

Extra details

• pressing numlock key and using setleds +num command,LED turn on and off as expected

[MichaIng]

Many thanks for your report.

Did this work with the version we provided before DietPi v8.5?

Are there probably some related error logs, either:

journalctl -u amiberry

or when you hit ALT+F3 to switch to TTY3 console where Amiberry runs on?

I see now there is a new optional build option USE_GPIOD, which we do not set, but it is for GPIO controlled LEDs.

@midwan
May I ask you quickly, I guess this is managed via SDL2, probably you know some library/headers/flag that is required to make keyboard LEDs functional?

[midwan]

@MichaIng
This is handled by calls to ioctl directly, not through SDL2. From what I remember, this might be related to the user permissiosn on the system, but I don't recall which group exactly might be responsible for it. I remember that I saw different results when logging in as a normal user vs root for example.

[MichaIng]

Hmm, on DietPi, Amiberry (still) runs as root, though I actually want to change this when I find time. So at least there shouldn't be permission issues.

[midwan]

I think it was when running as root that it didn't work actually. Perhaps root is not a member of some groups that are required?

[midwan]

Alternatively, perhaps the console it's running under has something to do with it.
Do you still launch Amiberry under X? That might also be related.

[MichaIng]

Usually root has simply full permissions for everything, at least when it's about file permissions, it doesn't need to be member of any group and can even edit 000 mode files etc. But I'm not 100% sure how it is with system calls.

We use KMS/DRM, on RPi with DispmanX, so no X server involved. It's started as systemd service with ExecStartPre=/bin/chvt 3 as at least with previous versions every keyboard input was printed to the console, and we don't want to have all this output on TTY1 😉.

[midwan]

Hm, could it be that starting it as a service is related then?
It should be possible to test this scenario, if it is launched manually after logging in, and seeing if the behavior is different.

[MichaIng]

@DJP75
Could you try this:

usermod -aG tty,input root

And if it doesn't help, following midwan's idea:

export LD_LIBRARY_PATH=/mnt/dietpi_userdata/amiberry/lib
cd /mnt/dietpi_userdata/amiberry
/mnt/dietpi_userdata/amiberry/amiberry

[DJP75]

Wow! The second solution works!! If i understood,it doesnt work using amiberry as a service. I'm using amiberry fast boot,how can i apply the fix? Thanks

[MichaIng]

Interesting, so it is related to the systemd service environment somehow. The service does basically the same, but only switches to a different TTY to keep the main TTY free from keyboard input spam and avoid interference with Amiberry and ongoing boot messages. Could be actually tested if this is still required with latest SDL2:

[Unit]
Description=Amiberry Amiga Emulator (DietPi)
Documentation=https://github.com/midwan/amiberry/wiki

[Service]
WorkingDirectory=/mnt/dietpi_userdata/amiberry
Environment=LD_LIBRARY_PATH=/mnt/dietpi_userdata/amiberry/lib
ExecStartPre=/bin/chvt 3
ExecStart=/mnt/dietpi_userdata/amiberry/amiberry
ExecStopPost=/bin/chvt 1

[Install]
WantedBy=local-fs.target

Is it probably required to set StandardInput=tty or even StandardOutput=tty so that the console device is occupied by the service? Not sure how that would be related to ioctl but lacking of deeper understanding I have no other idea 😅.

[DJP75]

I've fiddled a bit with the config but my knownledge of linux is very limited. No LED running as a service 😔Maybe it needs to be fixed by the developer of amiberry?

[MichaIng]

Since it depends on the environment, it's not a bug of Amiberry but we need to test/figure out what is missing in the systemd units environment 🙂.

[MichaIng]

It can be replicate quite easily:

setleds +num # numlock enabled
setleds -num # numlock disabled
systemd-run setleds +num # nothing changes

This is since setleds sets flags for its STDIN TTY, and within a systemd service environment, there is not STDIN by default. Good that one can assign a STDIN TTY and that we do already move to /dev/tty3 to assure the local console is not polluted. For some reason, doing so with Amiberry also resolves an issue where systemctl stop amibery, respectively SIGTERM and even SIGKILLing it didn't really work. Looks like a STDIN VT is for some reason helpful in general. So this is how to do it:

cat << '_EOF_' > lib/systemd/system/amiberry.service
[Unit]
Description=Amiberry Amiga Emulator (DietPi)
Documentation=https://github.com/BlitterStudio/amiberry/wiki

[Service]
WorkingDirectory=/mnt/dietpi_userdata/amiberry
Environment=LD_LIBRARY_PATH=/mnt/dietpi_userdata/amiberry/lib
StandardInput=tty
TTYPath=/dev/tty3
ExecStartPre=/bin/chvt 3
ExecStart=/mnt/dietpi_userdata/amiberry/amiberry
ExecStopPost=/bin/chvt 1

[Install]
WantedBy=local-fs.target
_EOF_
systemctl daemon-reload
systemctl start amiberry

[MichaIng]

Fixed with: f2684fb

Builds are currently running: https://github.com/MichaIng/DietPi/actions/runs/4028173471
Also without updating DietPi, by reinstalling Amiberry, once the new builds have been moved in place, the issue can be fixed. But it won't change anything else than the systemd service, so running the above commands has the same result.

[DJP75]

It works!! Thanks a lot!!
Edit: sorry,clicked the wrong button (close with comnent)

[MichaIng]

Great, many thanks for testing. I moved the builds to stable downloads as well, so issue can be indeed closed.

[EMPI-PL]

Hi. I'm facing the same problem on ARM and x86 boards. You may want to take a look at @midwan's linked issue.
It would seem the solution here would also resolve mine but I don't quite understand this part in #5536 (comment) by @MichaIng:

export LD_LIBRARY_PATH=/mnt/dietpi_userdata/amiberry/lib

There's no /lib directory under amiberry code. Is this something available only for DietPi? I guess not but still...
What would be then a solution for x86 boards using Amiberry?
Or did something change since the resolution in amiberry's directory structure?

thanks