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.

[midwan]

This ideally should be part of one fix which includes the Caps Lock detection when running from the console, so that we eliminate the need to start it with xinit (or from within X11).
The emulator should detect key events the same way, regardless of where it's started from.

[Fourdee]

@midwan
If we can remove the need for xinit, it would also reduce the installation size and package count (xserver packages):+1:

Note to self:
current launch script. If no xinit, this can be removed and revert back to service only.
https://github.com/Fourdee/DietPi/blob/a29279f443c5d4562358ba390d2f3004a1ac4071/dietpi/dietpi-software#L5667-L5680

[midwan]

Yes, I believe that should be the target eventually. I've already started working in this direction, we'll see how it goes in the following days.

[midwan]

There is a known issue with the Caps Lock LED/flag in Raspbian, as shown here:
https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=70385&p=985457

A temporary workaround is to run
echo keycode 58 = Caps_Lock |sudo loadkeys -

which restores the "normal" behavior for the key (both LED and flag are turned on/off when pressing the key after that). But this does not survive reboots of course.

I also tested it under UAE, and it works correctly when started from the console. The LED does not turn on in DietPi, but the flag does change.

Will test the same in Raspbian also to compare.

[midwan]

Confirmed working in Raspbian, including turning the Caps Lock LED on under emulation (when started from the console).

This brings us to the difference between DietPi vs Raspbian:
the command ioctl() does not seem to run the keyboard LED on (as expected) in DietPi, but it works in Raspbian. Perhaps some package is missing?

The below is a simple program I used to test this. The result should be that all keyboard LEDs should start flashing in a loop, until you hit Ctrl-C to cancel. It runs from the console:

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <signal.h>
#include <sys/stat.h>
#include <linux/kd.h>
#include <sys/types.h>
#include <sys/ioctl.h>

using namespace std;
#define ERROR -1

int fd; /* File descriptor for console (/dev/tty/) */

void sighandler(int signum);

int main(int argc, char *argv[])
{
    int i;

    /* To be used as the fd in ioctl(). */
    if ((fd = open("/dev/console", O_NOCTTY)) == ERROR) {
        perror("open");
        return ERROR;
    }

    signal(SIGINT, sighandler);
    signal(SIGTERM, sighandler);
    signal(SIGQUIT, sighandler);
    signal(SIGTSTP, sighandler);

    printf("w00w00!\n\n");
    printf("To exit hit Control-C.\n");

    while (1) {
        for (i = 0x01; i <= 0x04; i++) {
            /* We do this because there is no LED for 0x03. */
            if (i == 0x03) continue; 

            usleep(50000);

            if ((ioctl(fd, KDSETLED, i)) == ERROR) {
                perror("ioctl");
                close(fd);
                return ERROR;
            }
        }
    }
    close(fd);
    return 0;
}

void sighandler(int signum)
{
  /* Turn off all leds. No LED == 0x0. */
    if ((ioctl(fd, KDSETLED, 0x0)) == ERROR) { 
        perror("ioctl");
        close(fd);

    }

    printf("\nw00w00!\n");
    close(fd);

}

Binary also attached below.
@Fourdee can you take a look at this please? Do you have any idea what might be needed to get the LEDs to work in DietPi in the same way as Raspbian?

Edit: I actually found out what's causing this. :) In the code sample above, I'm using /dev/console as the console to apply LED changes. But in Amiberry we have switched the console to tty3, so of course it doesn't work! If I change the code to use /dev/tty1 then the LEDs work as expected.

[midwan]

@Fourdee this means that we can get rid of xinit during startup, once I test that everything works correctly. I'll change the UAE code a bit, since it's now hardcoded to use 0 (zero) as the console, instead it should fetch /dev/tty1 from the system.

Once I test that everything works, I'll post new binaries in Dropbox.

I still didn't get it to turn on the "POWER" led, but we can fix that later.

[midwan]

Hmm, nope. It works in Raspbian, but still doesn't work in DietPi for some reason. :-/

[Fourdee]

@midwan

Perhaps some package is missing?

Yep, very likely, leave it with me i'll take a look today.

this means that we can get rid of xinit during startup, once I test that everything works correctly.

👍

[Fourdee]

Strange, as far as I can tell, all the includes use libc6-dev: https://packages.debian.org/search?suite=jessie&section=all&arch=any&searchon=contents&keywords=sys%2Ftypes.h

root@DietPi:~# apt-cache search libc6
...
libc6 - GNU C Library: Shared libraries

Binaries are already installed:

root@DietPi:~# apt-get install libc6 libc-bin
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc-bin is already the newest version.
libc6 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I was going to compile and test, but the only keyboard I have with Num/scroll/caps LED is a ps/2, and no converter lol.

[Fourdee]

Notes

Borrowing my misses keyboard, has a num lock LED !!!

Checking kernel versions

Raspbian:

root@raspberrypi:~# uname -a
Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux

DietPi:

root@DietPi:~# uname -a
Linux DietPi 4.4.19-v7+ #907 SMP Tue Sep 6 14:03:56 BST 2016 armv7l GNU/Linux

Revert back to 4.4.11

rpi-update 48cfa89779408ecd69db4eb793b846fb7fe40c4b
reboot

🈴 No effect

Checking logs:

/var/log/kern.log
/var/log/syslog
dmesg

🈴 No errors found

Trying Raspbian config.txt on DietPi:

🈴 No effect

Compare packages:

dpkg --get-selections | awk '{print $1}' > dpkg_XX

https://www.diffchecker.com/o8zdyBFN
DietPi AmiBerry = Left
Raspbian = Right

Match Raspbian packages on DietPi system by installing missing:

string=$(cat dpkg_raspbian | tr '\r\n' ' '); apt-get install -y $(echo -e "$string")

Result packages:

The following extra packages will be installed:
  aptitude-doc-en attr keyutils laptop-detect libaio1 libasn1-8-heimdal libavahi-client3 libclass-accessor-perl libcups2
  libfile-copy-recursive-perl libhcrypto4-heimdal libhdb9-heimdal libheimbase1-heimdal libhx509-5-heimdal libio-string-perl libkrb5-26-heimdal
  libldb1 libntdb1 libparse-debianchangelog-perl libroken18-heimdal libsub-name-perl libtdb1 libtevent0 libwind0-heimdal python-crypto
  python-dnspython python-ldb python-ntdb python-samba python-talloc python-tdb samba samba-common-bin samba-dsdb-modules samba-libs
  samba-vfs-modules tdb-tools update-inetd winbind
Suggested packages:
  www-browser python-glade2 python-gtk2 debtags apt-xapian-index avahi-autoipd smbclient dhcpcd-gtk gdb-doc isoquery cups-common geoip-bin
  libident-dev libhtml-parser-perl libhtml-template-perl libxml-simple-perl xapian-tools lsb groff open-iscsi watchdog desktop-base
  plymouth-themes python-doc python-tk python-apt-dbg python-vte python-apt-doc python-crypto-dbg python-crypto-doc python2.7-doc
  binfmt-support bind9 bind9utils ctdb ldb-tools smbldap-tools heimdal-clients comgt wvdial indent libnss-winbind libpam-winbind
Recommended packages:
  libc-dbg
The following packages will be REMOVED:
  console-common resolvconf
The following NEW packages will be installed:
  apt-listchanges aptitude aptitude-common aptitude-doc-en attr avahi-daemon bind9-host cifs-utils dhcpcd5 file gcc-4.6-base gcc-4.7-base
  gcc-4.8-base gdb gdbserver geoip-database iso-codes keyutils laptop-detect libaio1 libasn1-8-heimdal libavahi-client3 libavahi-common-data
  libavahi-common3 libavahi-core7 libbind9-90 libboost-iostreams1.49.0 libboost-iostreams1.50.0 libboost-iostreams1.53.0
  libboost-iostreams1.54.0 libboost-iostreams1.55.0 libc6-dbg libclass-accessor-perl libcups2 libdaemon0 libdns100 libevent-2.0-5
  libfile-copy-recursive-perl libfreetype6-dev libgeoip1 libhcrypto4-heimdal libhdb9-heimdal libheimbase1-heimdal libhx509-5-heimdal libident
  libio-string-perl libisc95 libisccc90 libisccfg90 libjim0.75 libkrb5-26-heimdal libldb1 liblog-message-perl liblog-message-simple-perl
  libluajit-5.1-common liblwres90 libmagic1 libnfsidmap2 libnss-mdns libntdb1 libparse-debianchangelog-perl libpng12-dev libpython-stdlib
  libpython2.7 libpython2.7-minimal libpython2.7-stdlib libraspberrypi-dev libroken18-heimdal libsqlite3-0 libsub-name-perl libtalloc2 libtdb1
  libterm-ui-perl libtevent0 libtirpc1 libv4l-0 libv4l2rds0 libv4lconvert0 libwbclient0 libwind0-heimdal libxapian22 lsb-release lua5.1 luajit
  makedev man-db mime-support mountall ncdu ncurses-term netcat-openbsd netcat-traditional nfs-common openresolv plymouth python python-apt
  python-apt-common python-crypto python-dnspython python-ldb python-minimal python-ntdb python-rpi.gpio python-samba python-support
  python-talloc python-tdb python2.7 python2.7-minimal raspi-config rpcbind samba samba-common samba-common-bin samba-dsdb-modules samba-libs
  samba-vfs-modules shared-mime-info ssh strace tasksel tasksel-data tcpd tdb-tools traceroute triggerhappy update-inetd usb-modeswitch
  usb-modeswitch-data v4l-utils vim-common vim-tiny winbind xdg-user-dirs zlib1g-dev
0 upgraded, 136 newly installed, 2 to remove and 0 not upgraded.
Need to get 38.2 MB of archives.
After this operation, 164 MB of additional disk space will be used.

🈴 Reboot, No effect

[Fourdee]

Most likely an undocumented configuration on the Raspbian image.

I'll recreate the DietPi image from latest Raspbian, then test LED.

[midwan]

Thanks for your efforts!
I can also resume testing later today.

On Sep 13, 2016 14:27, "Dan" notifications@github.com wrote:

Most likely an undocumented configuration on the Raspbian image.

I'll recreate the DietPi image from latest Raspbian, then test LED.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADsp9UyW5JjbI-F2x39pfUo9itAyVi_oks5qppbJgaJpZM4J2SnT
.

[midwan]

To clarify, if you change the source code line above:
if ((fd = open("/dev/console", O_NOCTTY)) == ERROR) {

to this:
if ((fd = open("/dev/tty", O_NOCTTY)) == ERROR) {

and compile, the tool works correctly in both Raspbian and DietPi from the console. Binary version is attached below.

setled.zip

It's within UAE that things break down. It works in Raspbian but not in DietPi, even when using the same code... :-/

[Fourdee]

It's within UAE that things break down. It works in Raspbian but not in DietPi, even when using the same code... :-/

Bizzare. Are you running the setled binary over SSH? I get:

root@raspberrypi:~# ./setled
Got /dev/tty as 3

To exit hit Control-C.
ioctl: Inappropriate ioctl for device

EDIT:

Works on main screen, let me do some more tests.

[midwan]

I run it on the actual device (not over SSH).
I got the same message, /dev/tty as 3.

Did you see the LEDs blinking while it's running? that's what it's supposed to do.

[Fourdee]

Did you see the LEDs blinking while it's running? that's what it's supposed to do.

Only when I press Numlock, then capslock comes on, press capslock, numlock goes off lol. Keyboard lacks scroll lock.

[midwan]

Hm, it should flash all the LEDs constantly and repeatedly, until you cancel it with Ctrl-C. At least that's how it behaves here in both my environments.

Edit: maybe the lack of a Scroll Lock causes the error you get, and that may be why it doesn't loop. If that key does not exist, then the code that tries to enable/disable it with ioctl() would probably give an error. Give me a minute to compile a version without Scroll Lock so we can verify this.

I just flashed over a fresh AmiBerry image to try #3 again, so I'll test it there as well to see.

[Fourdee]

Hm, it should flash all the LEDs constantly and repeatedly, until you cancel it with Ctrl-C. At least that's how it behaves here in both my environments.

Its a cheap china-town USB wifi keyboard, probably to blame :)

[midwan]

Try with this version, it skips over the Scroll Lock key:

setled-noscr.zip

[midwan]

Haven't managed to find a solution yet, but some more details that might help us:

• I tried different approaches (all of them failed), including the ugly one of calling system("setleds +num") when I wanted the Num lock LED to turn on. It didn't. The setleds +num command works from the console as expected.
• The leds appear to respond as expected up until the GUI screen (or emulation screen if you've disabled the GUI) opens up. In other words, if I put some code to flash the leds (using the same method) before the GUI appears, they work. Once the GUI appears, they stay blank even during emulation when there are calls to turn them on/off. Note: the same binary does work as expected in Raspbian.
• I tried different tty approaches: a) opening /dev/tty and using that file descriptor in ioctl(), b) not opening any tty and using 0 (zero). Both of them do not work in DietPi. But they do work in Raspbian (both of them).
• I tried upgrading the firmware to the latest version, in both DietPi and Raspbian. Raspbian still worked, DietPi still did not. :-(

Note: It's not only DietPi that doesn't work with this, Minibian has the same problem from what users reported.

I'll keep looking...

[midwan]

@Fourdee I've updated the emulator binaries, to fix a bug that caused it not to load the assigned LED functions from the config file correctly (the first entry was always ignored). I was waiting to fix the LED issue here before I push this, but since I see it will take some time, maybe it's better to have it out.

[midwan]

I may have discovered something.

Out of curiosity, I flashed a fresh Raspbian Lite to a new card and tried from scratch. I followed these steps:

• installed Raspbian Jessie Lite
• upgraded system
• installed sdl (libsdl1.2debian libsdl-image1.2 libsdl-gfx1.2-5 libsdl-ttf2.0-0)
• installed libmpg (libmpg123-0)
• installed libguichan (libguichan-sdl-0.8.1-1)

then tried UAE. The LEDs did not work - same as in DietPi.

That means that there is a difference between my developer environment/full Raspbian image and this one. At least we know it's not as isolated to other distros as we thought.

[midwan]

I tried a fresh full Raspbian image yesterday also, and in a real WTF moment I discovered that it didn't work there as well. I did a quick check for differences in the installed packages, and even installed some of the dev packages that I had as extra on my "dev Raspbian" (where the LEDs work), but it didn't make a difference.

I'm beginning to suspect that it's not a package but rather some configuration, but I'll need more time/tests to narrow this down. I don't remember doing much customization in the Raspbian installation that I use as a development environment.

Next steps:

• Re-test the current binary in my "Raspbian dev" environment, to ensure that it still works (and that I haven't lost my sanity).
• Assuming the above is true, start comparing the two environments for differences, testing after each change. Yeap, I'm taking the brute force approach on this one... :)

[midwan]

Confirmed that it still works with the latest binary in my dev-Raspbian image, but not in a stock Raspbian.

Will now try to incrementally bring this image up to the same level as my Dev, to find out what the difference that makes it work is.

[midwan]

Update: It seems that the thing that doesn't work in the default Raspbian, is the Scroll Lock LED. The Num Lock one does work, when assigned a function through UAE.

I tested this in both Raspbian Lite and Raspbian, with the same results.
I did try applying the udev fix we used for the Scroll Lock key, but for some reason it didn't seem to work. The Scroll Lock LED remained off.

With this new information, I believe we can move the investigation to the next level:

• Compare a Raspbian Lite installation to the DietPi/Amiberry one for differences that might be causing this.

[midwan]

Trying to make some sense before we lose it completely... :)

I followed these steps, and these steps only:

• Fresh installation of Raspbian Lite: Scroll Lock LED does not turn on, not even manually (using the setleds +scroll) or with my "setled" test application. The Caps and Num lock LEDs work.
• Applying the 50-leds.rules file, then udevadm control --reload-rules, then reboot: The scroll Lock led works as normal. My "setled" test app now flashes it, as well as the rest of them.
• Installed UAE dependencies.
  Testing current binary of UAE from console, with my existing config (same one I've been testing all platforms). It's configured to use NUM lock for DF* activity, Scroll Lock for HD activity:
• LEDs flash as expected on the assigned activity.

So we know that a stock Raspbian (Lite) has the LEDs working, with the exception of the Scroll Lock one which needs the extra fix (which we have in DietPi already).

This gives us a relatively minimal system to compare against a normal DietPi installation for differences.
I'll try to find out any differences in configuration, since we saw that package-wise we are (almost?) identical.

[Fourdee]

@midwan

with the exception of the Scroll Lock one which needs the extra fix (which we have in DietPi already).

Ah yes, forgot about this one. 👍 Correct, applied by default to all DietPi RPi systems as per your suggestion.

package-wise we are (almost?) identical.

Nearly, on a base system, DietPi has less installed packages. Not sure of the exact figure currently, but a while back we had 140~ less installed packages: https://docs.google.com/spreadsheets/d/1mDHGZC-H6tU6_O8kuLTG8d4A8Nt7lV1Q7MXTR_6qw30/edit#gid=0

Heres the package difference when AmiBerry is installed on DietPi:

https://www.diffchecker.com/o8zdyBFN

• DietPi AmiBerry = Left
• Raspbian = Right

If we can isolate a single test I can run to get a definite result, I'll be able to re-do all my tests and hopefully provide some assistance.
What does this binary do exactly, flash Num and caps locks?: https://github.com/midwan/uae4arm-rpi/files/470227/setled-noscr.zip

Ideally, if we can have a single binary that turns of Num lock, then exits? Would this test cover the current issue?
Should make testing and debugging this easier, although I really should invest in a proper USB keyboard lol.
I did try and compile this myself, but, couldn't get a stable result. I will take another look hopefully tomorrow.

[midwan]

I tried starting with Raspbian Lite and following the steps you provided above also:

• Run the commands indicated
• Rebooted
• Tried to install the SDL packages, but apt-get could no longer resolve the jessie mirrors:

Err http://mirrordirector.raspbian.org jessie Release.gpg
Could not resolve 'mirrordirector.raspbian.org'
Err http://archive.raspberry.org jessie Release.gpg
Could not resolve 'archive.raspberry.org'

So I couldn't test it further...

[midwan]

sdl2_test.zip
Interestingly, if I try to run a new binary using SDL2 that I made, I get an error right away:
XDG_RUNTIME_DIR not set in the environment
And it doesn't work (returns to the prompt immediately after).

This binary also uses DispmanX and SDL2 on top, and works fine on a normal Raspbian (Lite) distro, I get the same message in Lite, but then it opens up a display and does it's job without problems. On DietPi, it just returns to the prompt.

Edit: I'm attaching the binary here in case you want to test it. The packages it needs are:
libsdl2-2.0-0, libsdl2-image-2.0-0, libsdl-ttf-2.0-0

What this binary is supposed to do is open a display, show a rainbow box test image first, then change the color of the screen a few times before exiting to the prompt again.

[midwan]

@Fourdee
I managed to test it also after running the steps in Raspbian Lite, by not rebooting in between.
I installed the SDL packages right after they were removed, in order to keep testing between each step.

Notes:

• The step echo -e "CONF_SWAPSIZE=0" > /etc/dphys-swapfile failed with "Permission denied". I did run it as sudo.
• when installing the console-data package, there is a prompt to Configure the keymap. I left that at the default option of "Don't touch keymap".
  In all the steps in-between, as well as after all of them, the testledsapplication kept working normally.
• I rebooted, and run testledsagain. It work normally.

[Fourdee]

@midwan

Excellent testing and details 👍

Going to focus on getting v131 released today, however, I've ordered a USB keyboard with LEDs on it: https://www.amazon.co.uk/Microsoft-Wired-Keyboard-200-Layout/dp/B0041SKBGK/ref=sr_1_1?s=computers&rps=1&ie=UTF8&qid=1474380457&sr=1-1&keywords=usb+keyboard
Will be here tomorrow.

Once I've got it, i'll go through your results and see if I can replicate. Hopefully, this keyboard will give me a viable way to testing the LED's are working, then the debugging can begin :)

[midwan]

Great, let's hope we'll find out what's going on. :)
So far, I've got the impression that DispmanX does not quite work in DietPi, and it opens an X display instead under SDL1.2. That does not happen with SDL2, hence the complete failure to start up.

That theory explains the mouse pointer shown, and the LEDs not working - since if you go in an X environment the ioctl() calls to the keyboard no longer change the LED status.

I'm not sure why it doesn't work though. Are you removing anything from /opt/vc where the files normally reside in? Maybe DispManX cannot initialize because it's missing something for example...

Either that, or it's a configuration issue in the system somewhere.

[midwan]

One more thing to test:
We can restore the traditional Caps Lock functionality so that the LED turns on when pressed from the console, using the command documented here:
https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=70385&p=985457

echo keycode 58 = Caps_Lock |sudo loadkeys -

Of course, this is temporary (it will go away on the next reboot), so if we implement it it should be part of the startup. Unless you know a way to make it more "permanent" that is.

If using the above allows the Caps Lock to work normally within UAE (i.e. press it and the LED turns on, letters are capitals), from a console startup, then we can get rid of xinit.

This approach works in Raspbian, I didn't test it in DietPi yet.

[midwan]

I tested it in a fresh installation of DietPi v131, unfortunately it's still the same regarding the LEDs.

I did notice a different behavior compared to my earlier tests, regarding the SDL2 stuff. My test program worked this time, after following these steps:

• Flashed v131 and booted.
• Changed settings to 1080p display, 128MB GPU memory
• Updated firmware
• Reboot
• Installed required packages for SDL2
• Test!

Although the display worked, and testing the "testleds" program does not show a mouse pointer anymore, the LEDs unfortunately remained turned off during the test.

At least this proves that whatever is causing the LED problem is probably unrelated to the earlier display issues I had noticed.

The Caps Lock fix does work from the console (the LED turns on when you press Caps Lock), but not in UAE, I guess for the same reason as the other LEDs. However, the key does work in UAE when started from the console, so I believe we can get rid of xinitfrom the startup alltogether. We still have to fix the LED problem, but there's no need to keep the whole X-stuff around for UAE.

[Fourdee]

@midwan

Using: https://www.amazon.co.uk/gp/product/B00JAE915C/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1

Fresh Raspbian lite installation:

• Login as root
• apt-get update
• apt-get upgrade
• apt-get install libsdl1.2debian libsdl-image1.2 libsdl-ttf2.0-0 libsdl-gfx1.2-5
• reboot
• ./testleds-noscroll and ./testleds
  • No mouse cursor
  • No change in any LED's on keyboard.
• kill testled , manually test keys:
  • Numlock = 1
  • Scrolllock = 0
  • Capslock = 0
• reboot
• echo keycode 58 = Caps_Lock |sudo loadkeys -
  • Capslock = 1
  • ./testleds-noscroll = no effect

so I believe we can get rid of xinitfrom the startup alltogether. We still have to fix the LED problem, but there's no need to keep the whole X-stuff around for UAE.

Removal of Xserver package deps would be awesome 👍 Looking forward to seeing this in SDL2.

EDIT:

Binary tests work under user Pi, not root. So there must be some additional configs specific to the Pi user, i'll have a look.

Create user bob:

• add to sudoers
• sudo ./testleds = fails
• ./testleds = failed to open_vchiq instance
  • Add user to input group usermod -a -G input bob
  • Add user to audio group usermod -a -G audio bob
  • Add user to audio group usermod -a -G video bob
  • ./testleds = works

root@raspberrypi:~# cat /etc/udev/rules.d/99-com.rules
SUBSYSTEM=="input", GROUP="input", MODE="0660"
SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660"
SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
        chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
        chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
        chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
'"

KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
        ALIASES=/proc/device-tree/aliases; \
        if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \
                echo 0;\
        elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \
                echo 1; \
        else \
                exit 1; \
        fi\
'", SYMLINK+="serial%c"

KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\
        ALIASES=/proc/device-tree/aliases; \
        if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \
                echo 0; \
        elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \
                echo 1; \
        else \
                exit 1; \
        fi \
'", SYMLINK+="serial%c"

Login as user pi:

• sudo ./testleds = fails
• ./testleds = works

Root:

Shouldnt have any effect, root > all

• usermod -a -G input root
• usermod -a -G video root
• usermod -a -G audio root
  • ./testleds-noscroll = no effect

[Fourdee]

@midwan

Ok, so LED's work as standard users, but not under sudo or with root user. Weird lol
Let me run same tests on dietpi image.

edit

Yep, works fine on DietPi image, same results.

[midwan]

Interesting, that explains the behavior at least. I wonder why...

On Sep 23, 2016 17:06, "Dan" notifications@github.com wrote:

@midwan https://github.com/midwan

Ok, so LED's work as standard users, but not under sudo or with root
user. Weird lol

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADsp9auYSmreSxRX51tBmKoG1EG6U1hUks5qs-rpgaJpZM4J2SnT
.

[Fourdee]

@midwan

Not sure.
From a permissions standpoint, root has access to everything and running sudo grants the same permissions. So in theory, it should work under root and sudo.
Its not specific to the pi user as I confirmed same results with bob.

I suppose we could test if this is a SDL specific issue, by creating another binary that tests the LEDS without SDL library (bare bones main.cpp with LED flashing). Any chance you can make one of those binaries and i'll continue testing?

[midwan]

@Fourdee
Sure, that was the first binary I had made actually. I don't think it's SDL related, as the call to change the LED status on/off is a system call (ioctl()) and not part of SDL.

The "setled" binary will start from main, go in a loop and flash the LEDs until you cancel it with Ctrl-C.
The "testleds" binary will open up an SDL screen first, but otherwise do the same loop with the same calls to flash the LEDs.

Both of these worked in Raspbian Lite (and full), but of course I only tested them under the "pi" default account.

[Fourdee]

@midwan

Still puzzles me this one. Doesn't make sense why LEDs fail with root, if anything, should be the other way round.

I suppose, as a possible fix, we could create a user specifically for AmiBerry. This would resolve the LED issues.
Permissions shouldn't be an issue, we can apply ownership to /mnt/dietpi_userdata/uae4arm-rpi directory aswell during patch and install.

But either way, I'll try the method above and run some tests.

[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
#3 (comment),
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