search

BlitterStudio / amiberry

Optimized Amiga emulator for Linux/macOS
https://amiberry.com
GNU General Public License v3.0
637 stars 86 forks source link

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

Closed midwan closed 7 years ago

midwan commented 8 years ago

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:

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

midwan commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

Fourdee commented 7 years ago

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

:+1:

Fourdee commented 7 years ago

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 commented 7 years ago

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

:u5408: No effect

Checking logs:

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

:u5408: No errors found

Trying Raspbian config.txt on DietPi:

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

:u5408: Reboot, No effect

Fourdee commented 7 years ago

Most likely an undocumented configuration on the Raspbian image.

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

midwan commented 7 years ago

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 https://github.com/midwan/uae4arm-rpi/issues/3#issuecomment-246665222, or mute the thread https://github.com/notifications/unsubscribe-auth/ADsp9UyW5JjbI-F2x39pfUo9itAyVi_oks5qppbJgaJpZM4J2SnT .

midwan commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

setled-noscr.zip

midwan commented 7 years ago

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

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 commented 7 years ago

@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 commented 7 years ago

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:

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 commented 7 years ago

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:

midwan commented 7 years ago

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 commented 7 years ago

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:

midwan commented 7 years ago

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

I followed these steps, and these steps only:

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 commented 7 years ago

@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. :+1: 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

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 commented 7 years ago

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

midwan commented 7 years ago
midwan commented 7 years ago

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?

Fourdee commented 7 years ago

@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 :+1: I'll run some tests with those binaries today and see if we can find the cause.

Fourdee commented 7 years ago

@midwan

Using Rasbian Lite:

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?

midwan commented 7 years ago

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

Fourdee commented 7 years ago

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

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.

midwan commented 7 years ago

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

Fourdee commented 7 years ago

@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
midwan commented 7 years ago

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

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

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:

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

Results: Worked Note: No mouse pointer is visible.

midwan commented 7 years ago

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

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 commented 7 years ago

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 commented 7 years ago

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

Fourdee commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

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 commented 7 years ago

@midwan

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

Fresh Raspbian lite installation:

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:

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:

Root:

Shouldnt have any effect, root > all

Fourdee commented 7 years ago

@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 commented 7 years ago

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 https://github.com/midwan/uae4arm-rpi/issues/3#issuecomment-249217746, or mute the thread https://github.com/notifications/unsubscribe-auth/ADsp9auYSmreSxRX51tBmKoG1EG6U1hUks5qs-rpgaJpZM4J2SnT .

Fourdee commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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