@Fourdee sure, we can try it this way. I'll let you know as soon as I test it.

from amiberry.

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. :)

from amiberry.

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.

from amiberry.

@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

from amiberry.

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.

from amiberry.

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

setled-noscr.zip

from amiberry.

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.

from amiberry.

I installed a bunch of extra packages that were in Raspbian Lite and not in DietPi, but no change in the behavior. The issue seems to occur only when a screen with DispmanX + SDL is opened, so I created a small tool to replicate the problem.

@Fourdee could you please help with this?

The tool runs from the command line (i.e. no xinit required) and it will open a blank (black) full screen using DispmanX and SDL. It will start a loop of flashing the keyboard LEDs, much like the "setled" previous program did. It will continue doing so, until you press "ESC" or "q" on the keyboard, at which point it will quit to the desktop again.

Essentially I'm recreating the same method that UAE opens the screen, and trying to flash the LEDs after that.

This program works normally in Raspbian, but not in DietPi. I thought it might help you find out what is causing this, if you have the possibility to prepare a DietPi installation step by step, based on a Raspbian / Raspbian Lite one? Or if you have a better method, do that of course!

In case you need the "no scroll lock" version of this, I'm attaching that as well.
testleds.zip
testleds-noscroll.zip

Dependencies: SDL1.2debian, same as UAE.

Let me know if this helps, or if we should use something else?

from amiberry.

@midwan

I've created a new DietPi image based on the current Raspbian Lite. Please can you check if your LED binary works on this image?
http://dietpi.com/downloads/testing/DietPi_RPi-armv6-(Jessie).7z

If it doesn't, please remove the scrolllock fix, reboot then try 1 last time:

rm /etc/udev/rules.d/50-leds.rules

from amiberry.

@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.

from amiberry.

@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 :)

from amiberry.

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.

from amiberry.

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.

from amiberry.

@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.

from amiberry.

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

from amiberry.

@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.

👍

from amiberry.

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.

from amiberry.

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

from amiberry.

Most likely an undocumented configuration on the Raspbian image.

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

from amiberry.

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

On Sep 13, 2016 14:27, "Dan" [email protected] 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
.

from amiberry.

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... :-/

from amiberry.

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.

from amiberry.

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.

from amiberry.

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.

from amiberry.

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.

from amiberry.

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 :)

from amiberry.

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...

from amiberry.

@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.

from amiberry.

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.

from amiberry.

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... :)

from amiberry.

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.

from amiberry.

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.

from amiberry.

@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.

from amiberry.

@Fourdee the binary will go in an infinite loop, flashing the LEDs continuously until you hit Ctrl-C to exit.

I'm working on exactly what you mentioned: a method to reliably test the results on a system as untouched as possible. I've just flashed a stock DietPi image, verified that the Scroll Lock LED is working out of the box (the fix is there, I checked) and am now copying over the emulation environment I use for testing.

After this step, which I expect to fail (in the sense that the LEDs won't work inside UAE), the plan is to start comparing the two default distros: Raspbian Lite vs DietPi stock.

Eventually I should run into something that changes the behavior in the emulator. :)

Edit: a binary that tests the LEDs from the console does not help, as the "setled" program showed. It worked fine, but UAE did not in the previous test cycle. We'll see again shortly.

from amiberry.

• Installed DietPi stock (v130)
• Tested Scroll LED (worked)
• Tested "setled", all LEDs flashed normally
• Copied UAE environment.
• Installed UAE dependencies (libsdl1.2debian libsdl-image1.2 libsdl-gfx1.2-5 libsdl-ttf2.0-0 libmpg123-0 libguichan-sdl-0.8.1-1 libxml2 pulseaudio)
• Enabled sound card and changed Memory split to 128MB using dietpi-config
• Rebooted
• Tested UAE: LEDs do not work

from amiberry.

@midwan

The tool runs from the command line (i.e. no xinit required) and it will open a blank (black) full screen using DispmanX and SDL. It will start a loop of flashing the keyboard LEDs, much like the "setled" previous program did. It will continue doing so, until you press "ESC" or "q" on the keyboard, at which point it will quit to the desktop again.

Excellent 👍 I'll run some tests with those binaries today and see if we can find the cause.

from amiberry.

@midwan

Using Rasbian Lite:

• pre-reqs: apt-get install xcompmgr xterm xinit xauth xserver-xorg dbus-x11 xfonts-base x11-xserver-utils x11-common x11-utils alsa-base alsa-oss joystick libsdl-image1.2 libsdl-ttf2.0-0 libsdl-gfx1.2-5 libguichan-0.8.1-1 libguichan-allegro-0.8.1-1 libguichan-sdl-0.8.1-1 libguichan-opengl-0.8.1-1 libjpgalleg4.4 libxml2 libmpg123-0
• Main screen ./testleds-noscroll
  • Black screen appears with mouse cursor in top left corner
  • No LED's are flashing.
  • Exited with q
  • Tested Num lock at prompt, working fine.
• Main screen ./testleds
  • Same results as above

Did you test these on Raspbian (not lite)? Let me try Raspbian (not lite) and see if I get the same results.

Edit:

Same results with Raspbian (not lite)

@midwan
If this is working for you, maybe my china-town keyboard is to blame?

from amiberry.

@Fourdee sorry for the late reply, I've been a little busy. :)

It works for me with both "testleds" and "testleds-noscroll", in both Raspbian and Raspbian Lite - but not in DietPi.
I have tried it with two different keyboards, one Microsoft Comfort Curve 2000, one HP Desktop. Both worked normally, flashing their LEDs when told to do so... :)

Strange that it didn't work for you... One thing to notice though, I did not install all those pre-reqs you listed above, as the X-environment is not needed for this test. Though the full Raspbian already has X pre-installed of course.

Could you try with a fresh Raspbian Lite, installing only the absolute minimum extras (it only needs libsdl actually) to see if any of those packages is causing this? That might actually help us find out what is going on.

Note: you mentioned a mouse cursor visible? That's not possible from the console, unless you run this test in a Window manager environment?

from amiberry.

@midwan

Could you try with a fresh Raspbian Lite, installing only the absolute minimum extras (it only needs libsdl actually) to see if any of those packages is causing this?

Raspbian Lite:

• apt-get update
• apt-get install libsdl1.2debian libsdl-image1.2 libsdl-ttf2.0-0 libsdl-gfx1.2-5
• ./testleds-noscroll and ./testleds
  • No mouse cursor this time :)
  • No change in Numlock LED on keyboard.

I believe my (misses) keyboard isn't giving expected results: https://www.amazon.co.uk/gp/product/B00JAE915C/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1

Unfortunately, dont have another keyboard to try.

Note: you mentioned a mouse cursor visible? That's not possible from the console, unless you run this test in a Window manager environment?

Could of been on the full Raspbian, cant remember.

We could try debugging on your Raspbian Lite installation?

Simply by going through the process of stripping the packages and setting up image for DietPi.

• Run these commands: https://github.com/Fourdee/DietPi/blob/master/PREP_SYSTEM_FOR_DIETPI.sh#L75-L108
• reinstall libsdl apt-get install libsdl1.2debian libsdl-image1.2 libsdl-ttf2.0-0 libsdl-gfx1.2-5
• try ./testleds-noscroll
  If it still works at this stage, let me know, will look for next step.

from amiberry.

@Fourdee
I run a fresh test using the image you provided above:

• Flashed the image and booted.
• Installed OpenSSH server
• Installed libsdl1.2debian, libsdl-image1.2, libsdl-ttf2.0-0
• Enabled the default sound card
• Run the "testleds" and "testleds-noscroll" binaries to test

Results: Black image, mouse pointer showing, LEDs NOT working.

• Tested the older "setled" binary from the console
  Results: Worked, LEDs flash normally.

This means that there's something going on when opening a DispmanX display and using SDL surfaces on it (that's what the testleds is doing, that's what UAE is also doing).

To ensure there is a difference from Raspbian Lite, I followed these steps right after:

• Flashed a fresh Raspbian Lite
• Run an upgrade for all packages (apt-get update && apt-get upgrade) to ensure they are in sync with those of the DietPi installation
• Installed the same packages as above (libsdl1.2debian, libsdl-image1.2, libsdl-ttf2.0-0)
• OpenSSH is already installed by default, so I didn't have to install it
• The sound card is enabled by default, so I didn't change it
• Tested "testleds"

Results: Worked normally (except Scroll Lock LED because I didn't install the fix for that).
Note: No mouse pointer is visible.

• Run a firmware update (rpi-update) just in case
• Rebooted
• Tested "testleds"

Results: Worked
Note: No mouse pointer is visible.

from amiberry.

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...

from amiberry.

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.

from amiberry.

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.

from amiberry.

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.

from amiberry.

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.

from amiberry.

@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

from amiberry.

@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.

from amiberry.

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

On Sep 23, 2016 17:06, "Dan" [email protected] 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
.

from amiberry.

@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?

from amiberry.

@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.

from amiberry.

@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.

from amiberry.

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

from amiberry.

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" [email protected] 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
.

from amiberry.

@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 }

from amiberry.

@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.

from amiberry.

@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

from amiberry.

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

from amiberry.

@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 👍

from amiberry.

@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?

from amiberry.

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

from amiberry.