Keyboard LEDs assigned to drives don't work in DietPi (work in Raspbian)

[midwan]

The keyboard LEDs (Scroll Lock, Num Lock) do not work as expected when they are assigned functions like drive activity, from within the emulator.

This works if the emulator is running under Raspbian, but not in DietPi. However, the following scenario applies:

• Setting the Caps Lock when the key is pressed seems to work when running under xinit, but not when running in the console framebuffer. However, the functions assigned to the LEDs do not work when running under xinit.
• On the contrary, the functions assigned to them (e.g. HD/DF* activity) seem to work only when running from the console framebuffer and not under xinit.

Note: The code uses calls to ioctl() (#include <sys/ioctl.h>) to get and set the keyboard LED status.

[Fourdee]

@midwan Misc menu, keyboard LED assignments for DF0: work fine on Raspbian using v2 binary?

[midwan]

Not able to test right now, but the DF* setting definitely works. It will turn the led on fire any floppy drive access (e.g. DF0, DF1, DF2, etc).

Only the power led setting does not quite work yet.

On Sep 24, 2016 18:13, "Dan" notifications@github.com wrote:

@midwan https://github.com/midwan Misc menu, keyboard LED assignments for DF0: work fine on Raspbian?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/midwan/uae4arm-rpi/issues/3#issuecomment-249372861, or mute the thread https://github.com/notifications/unsubscribe-auth/ADsp9WNaA0wfPv1TvC_sXK2UsOfwOECXks5qtUwkgaJpZM4J2SnT .

[Fourdee]

@midwan

Not able to test right now, but the DF* setting definitely works. It will turn the led on fire any floppy drive access (e.g. DF0, DF1, DF2, etc).

Thanks. Will give me something to test against 👍

Notes:

        #-------------------------------------------------------------------------------
        #AmiBerry LED test, run as standard user:

        # useradd amiberry
        # usermod -a -G input amiberry
        # usermod -a -G video amiberry
        # usermod -a -G audio amiberry
        # usermod -a -G root amiberry

        # sed -i '/allowed_users=/c\allowed_users=anybody' /etc/X11/Xwrapper.config

        # cd /etc/uae4arm-rpi && sudo -u amiberry xinit /etc/uae4arm-rpi/uae4arm-rpi -f /etc/uae4arm-rpi/conf/autostart.uae  &> /dev/tty1
        # cd /etc/uae4arm-rpi && xinit /etc/uae4arm-rpi/uae4arm-rpi -f /etc/uae4arm-rpi/conf/autostart.uae  &> /dev/tty1

        # chown -R amiberry:amiberry /mnt/dietpi_userdata/uae4arm-rpi

LED: numlock set to df*

• game = indy 500

Raspbian:

• logged in as pi = yes
• root = no

DietPi:

• root = no
• sudo -u amiberry = no
  • without xinit = no
• logged in as amiberry = no
  • without xinit = yes

LED: testled

Raspbian:

• logged in as pi = yes
• root = no

DietPi:

• root = no
• sudo -u amiberry = no
• logged in as amiberry = yes

root@DietPi:~# su -c 'cd /etc/uae4arm-rpi; /etc/uae4arm-rpi/uae4arm-rpi -f /etc/uae4arm-rpi/conf/autostart.uae' amiberry
Amiberry v2.0 build 2016-09-19.1
Unknown keycode to use, will use keysym
starting sound thread..
IP: 0x2dd21c [e5953008] 0xa33e4008
bash: line 1:  1562 Segmentation fault      /etc/uae4arm-rpi/uae4arm-rpi -f /etc/uae4arm-rpi/conf/autostart.uae

root@DietPi:~# usermod -a -G tty amiberry
root@DietPi:~# su -c "cd /etc/uae4arm-rpi; /etc/uae4arm-rpi/uae4arm-rpi -f /etc/uae4arm-rpi/conf/autostart.uae &> /dev/tty1" amiberry
bash: line 1:  1628 Segmentation fault      /etc/uae4arm-rpi/uae4arm-rpi -f /etc/uae4arm-rpi/conf/autostart.uae &> /dev/tty1

root@DietPi:/etc/uae4arm-rpi#  cd /etc/uae4arm-rpi && sudo -u amiberry /etc/uae4arm-rpi/uae4arm-rpi -f /etc/uae4arm-rpi/conf/autostart.uae
Amiberry v2.0 build 2016-09-19.1
Unknown keycode to use, will use keysym
starting sound thread..
IP: 0x2dd21c [e5953008] 0xa3441008

#Works with xinit, but no LED's
 cd /etc/uae4arm-rpi && sudo -u amiberry xinit /etc/uae4arm-rpi/uae4arm-rpi -f /etc/uae4arm-rpi/conf/autostart.uae

So, as far as I can tell, to get LEDS working:

• 🈯 A non-root user (amiberry) must be logged in, and, launch the binary manually, without xinit.
• 🈴 Running the binary under user amiberry with su or sudo -u results in a seg fault or failure.
• 🈯 Running testleds when logged in as non-root user (amiberry) is fine
• 🈴 Running testleds under user amiberry with sudo -u amiberry ./testleds has no effect
• Results are the same with Raspbian and DietPi
• Results are same with:
• 🈯 setleds +num works as root and non-root
  • Test

cat << _EOF_ > /root/test.sh
#!/bin/bash

LEDSTATE=0

while true
do

    if (( \$LEDSTATE == 0 )); then

        setleds +num
        LEDSTATE=1

    else

        setleds -num
        LEDSTATE=0

    fi

    sleep 0.1

done

_EOF_
chmod +x /root/test.sh

Then run /root/test.sh from main term

Find sourcecode for setleds and see if they are using ioctl.h

https://fossies.org/dox/kbd-2.0.3/setleds_8c_source.html

Does indeed use ioctl:

static int
   94 setleds(char cur_leds) {
   95     if (ioctl(0, KDSETLED, cur_leds)) {
   96     kbd_warning(errno, "ioctl KDSETLED");
   97     return -1;
   98     }
   99     return 0;
  100 }

[Fourdee]

@midwan

Ok, Findings:

• 🈯 setleds +num works as root and non-root. The sourcecode for this also uses ioctl (https://fossies.org/dox/kbd-2.0.3/setleds_8c_source.html)
• 🈺 Running testleds only works when logged in as non-root user (eg: amiberry).
• 🈯 Issues are not specific to DietPi. Results are same on official Raspbian image.

Maybe this is a SDL issue? As far as I can tell, setleds +num does the same thing, yet works every time, regardless of user who launched it.

[midwan]

@Fourdee thanks for the detailed testing feedback! :)

Ok, to clarify if this is in any way related to either a) DispManX or b) SDL1.2, I've prepared the following tiny tool that will test the LEDs from the console. No DispmanX and SDL is initialized or used, just pure ioctl().

It works on Raspbian with both a normal user (pi) and when run with sudo. I'm also attaching the source, in case you want to poke around.

Edit: this works in DietPi as well. :) I will now create a test tool that uses SDL2 and one with SDL1, to check if either one is causing this.

setleds-console-src.zip setleds-console.zip

[midwan]

Update: I just tested a binary using SDL2, it works normally in DietPi.

I think we can finally close this then. It seems that it's related to DispmanX when used as a back-end for SDL1 screens. SDL2 does not need/use it, and it does not suffer from this problem.

Therefore, we can safely say that when the SDL2 port is complete, this issue should be resolved "for free" with it. :)

[midwan]

To test the binary, you can use the following package: guisan.zip

It has one requirement: SDL2 library

However, it may not work correctly with the default libsdl2 package delivered through apt-get, as I believe that requires X11 in order to open a screen. Instead, you can use the binary package from libsdl.org (attached below), to avoid compiling your own.

It's compressed with ZIP on top, to allow it to be attached here. It contains the whole dir structure with the files, though you only need the ones contained in "lib" for the binary. Careful to keep the symlinks contained there intact. ;)

sdl-raspberrypi-1403.tar.xz.zip

[Fourdee]

@midwan

Update: I just tested a binary using SDL2, it works normally in DietPi. I think we can finally close this then.

🏆 Awesome, great stuff👍

sdl-raspberrypi-1403.tar.xz.zip

Excellent, i'll give this a spin 👍

[midwan]

@Fourdee I've managed to fix this for the SDL1.2 branch also. The requirements are:

• the emulator needs to be started as a normal user, i.e. not root
• the emulator needs to have been started from the console (i.e. use fbcon)
• the scroll lock fix needs to be applied in the system, otherwise the Scroll Lock LED will not light up (but the rest still work)

Do you think we could plan for an update in the DietPi distribution, using the latest binaries with the fixes?

[midwan]

Closing issue as it has been resolved in both SDL1.x and SDL2 branches, as long as the requirements are ment:

• Launch emulator as a normal (non-root) user
• Launch the emulator from the console (not X11)
• The Scroll Lock fix needs to be applied to the system otherwise the Scroll Lock LED will not work