search

ridgekuhn / arklone-arkos

rclone cloud syncing utility for ArkOS
GNU General Public License v3.0
18 stars 1 forks source link

First run screen doesn't accept user input on RG353V #5

Open WinterSolstice8 opened 1 year ago

WinterSolstice8 commented 1 year ago

I am using "2.0" from this git tag for RG353V: https://github.com/christianhaitian/arkos/releases/tag/v2.0.05.24.2023

I get the screen that asks to automatically configure Retroarch with the recommended settings and no user input works. Left/right and no buttons actually do anything. Are there any logs I can pull to see if anything's gone awry behind the scenes?

ridgekuhn commented 1 year ago

Hello, the project was developed for an older version of ArkOS and relies on an equally old version of Christian's oga_controls, located at (arklone_dir)/vendor/oga_controls. I'm guessing it's not compatible w the RG353V since its development precedes that device. Unfortunately, I have no way to test/debug this for u since I only own an RG351P, which ArkOS stopped supporting long ago. I would suggest trying to edit (arklone_dir)/src/dialogs/scripts/input-listener.sh by removing the device check and forcing the anbernic setting, and if that doesn't work, you can always plug in a USB keyboard. Sorry I can't help more!

mdeguzis commented 4 months ago

Same issue, tried removing device check in script. rg353m.

ridgekuhn commented 4 months ago

Hello, I'm sorry, I can't help too much because ArkOS's GH repo is mostly opaque update scripts, so it's difficult to get a sense of what's changed in recent versions without owning a device compatible with newer versions of ArkOS to install to and examine. I'll try to help as much as I can.

I just checked oga_controls and it looks like it was never updated to support any Anbernic devices after the 351 series, so I guess Anbernic must have changed how their input drivers worked and oga_controls was no longer needed, or input is handled some other way?

Here is everything regarding Arklone and input in ArkOS. Apologies for the wall of text below, but only a handful of files are involved, and for the most part, only a single line of code in each file.

ArkOS:

Arklone:

joy2key (see below)

ES, Whiptail, stdio streams

Arklone relies on whiptail for all the dialogs. One of ArkOS's quirks is that when it runs EmulationStation, it's running detatched from a tty, which is an issue as it's unable to redirect the stdin stream to whiptail. EmulationStation is launched by a systemd service that lives at /etc/systemd/system/emulationstation.service, which in turn runs another script that actually launches EmulationStation. whiptail is a terminal program and must run attached to a tty, so the Arklone install script replaces the systemd module with one that attaches EmulationStation to tty1, and then rewrites the system settings section of /etc/emulationstation/es_systems.cfg to redirect stdio to the current tty instead of brute-forcing it to tty1, which whiptail previously did not have access to.

The reason I mention all of this is that ArkOS may have had configuration changes that prevent the patches in the install scripfrom getting applied. In retrospect, I probably should have created a new section in es_systems.cfg instead of overwriting ArkOS's settings section.

You can view the mentioned changes to ArkOS's configs in the install / uninstall scripts in my ArkOS fork. It's confusing that these live in a separate repo from Arklone, but they were meant to be merged into ArkOS's update script workflow so that's how it had to be.

Input listening

I'm not exactly sure how oga_controls works, but it runs as a background process, parses gamepad input, and apparently, forwards it to stdin. When Arklone runs, it's wrapped by input-listener.sh, which launches oga_controls in the background, and then kills it after whatever program you passed to input-listener.sh exits.

input-listener.sh is called from two places. The first is /opt/system/Cloud Settings.sh, launched by EmulationStation from the system settings menu. This file is created by the Arklone install script in the ArkOS fork. The other time input-listener.sh is called is by Arklone's systemd boot service.

If oga_controls has been replaced by some newer utility, I guess you could just replace all the business logic in input-listener.sh with that.

On that note, when I originally wrote Arklone, I ported the RetroPie Project's joy2key utility to do the job of oga_controls. It's possible that this may work on the RG353, etc. It needs to be installed to /opt/joy2key:

git clone https://github.com/ridgekuhn/joy2key-arkos.git /opt/joy2key
sudo chmod u+x /opt/joy2key/install.sh
/opt/joy2key/install.sh

The joy2key port comes with its own input listener wrapper script, so you'd just need to replace the two calls to input-listener.sh with a call to /opt/joy2key/listen.sh:

/opt/system/Cloud Settings.sh:

/opt/joy2key/listen.sh "/opt/arklone/src/dialogs/settings.sh"

/opt/arklone/systemd/units/arkloned-receive-saves-boot.service:

ExecStart=/opt/joy2key/listen.sh "/opt/arklone/dialogs/boot-sync.sh"

I think that should be it, but commit 579cde2 contains all the changes for the switch from joy2key to oga_controls.

Again, sorry for the wall of text and that I'm not able to test any of this for you, but hopefully that helps!

mdeguzis commented 4 months ago

mostly opaque update scripts

You're not wrong there :), I entered this issue in a vain attempt to address that: https://github.com/christianhaitian/arkos/issues/1075 (which was then closed). I plugged in a keyboard to do the initial setup. It's currently sitting at "Cleaning up old path units", so hopefully it's doing something :)

I can attempt to test those changes above on my rg353m later this week or soon.

Judging my some of the files seen in https://github.com/search?q=repo%3Achristianhaitian%2Farkos+tools&type=code, it seems the tools/ folder has an inittools setup that takes care of inputs. So if you instead write your tool to roms/tools instead of putting it in the main options folder, it may work. I'll have to test this out.

BUT

I found this to be the most interesting: https://github.com/christianhaitian/rk3326_core_builds/blob/d7cfdf922a863a4ad816660ec64dd6c1aafd8ca4/shell-scripts/buttonmon.sh#L16

It seems he loads that to give simple confirmation/cancel on scripts.

mdeguzis commented 4 months ago

The script has been sitting at 98% for generating retroarch path units hmmm. If anything, I may revert to my simple sync scripting I wrote https://github.com/mdeguzis/scripts/tree/master/backup. I can run the unit generation script manually though ok. Idk why it stops at 98%. I'll check it soon. Be nice to have a CLI option to run the install without dialogs.

mdeguzis commented 4 months ago

I couldn't get sourcing the inputmon script from arkos working. For now, I am going to make the Cloud settings bash script run the upload directly by calling the sync. That way I can run it whenever I want for upload at least. If I, you, or anyone can get input working, that would rock. I'm ok at least hitting the button to run the backup.

Though, if I enable timed sync via those systemd scripts, will it pop up and annoy me like the on-boot one? I just want it to run in the background.

mdeguzis commented 4 months ago

Ok, in getting the menu to actually display (which it does not right. now with the output redirects), I found I can just use stderr (normal for dialog/whiptail), with 2> /tmp/whiptailout and just read the number from there. Next up is trying to get the intput ArkOS uses (gpkeytob I think it's called), and see if I can make that work . Progress.

ridgekuhn commented 4 months ago

Yes, the auto timed and per-write syncs run in the background, and the systemd services watching the directories will not start unless the boot service exits successfully. I know the boot service is obnoxious, but it blocks multi-user.target to avoid data loss; ie, RetroArch puts a new timestamp on SRAM files as soon as u open a ROM, so if we didn't block EmulationStation (and RetroArch) to wait for the initial sync, your newer cloud saves would get clobbered.

Is your unit generation still stuck at 98%? Once they're all generated, you can issue the CLI command:

/opt/arklone/src/rclone/scripts/sync-all-dirs.sh ["send" | "receive"]

I've re-synced the dev branch with master so u can make PRs against it. Though honestly, I'm not sure about maintaining this project, there is also a RetroPie fork that needs to be kept somewhat inline with this repo, which is why the whole project is written in Bash per RetroPie's plugin style guide. That fork got denied as an official plugin, so a newer version could be written in Python or something and not need to rely on systemd path units, which have issues watching directories recursively (I didn't realize that until I was almost done w the project).

mdeguzis commented 4 months ago

Once I got done with completing the setup via ssh X11 forwarding and SSH, it's been uploading good. If the project is more low key now I won't make you jump through hoops. Curious what reteopie folks do then. I use decky cloud save on my deck. I think the easiest thing I can do is just update my simple systemd backup solution with reclone I linked before. It's not perfect and doesn't do lath watching , but it's something. Simple to maintain for me.

ridgekuhn commented 4 months ago

Good to hear u got it working! X11 forwarding was necessary for you to use from a desktop/laptop? You should be able to just open a terminal, ssh into the Anbernic, and run /opt/system/Cloud Settings.sh?

I've seen Syncthing get mentioned a lot. It looks very nice, but I haven't tried it because once I set up Arklone on all my Debian-based devices, it's "just worked" for years and I've never had to think about it (except for the rare GH issue, lol). Hopefully it will do the same for you now!

mdeguzis commented 4 months ago

Good to hear u got it working! X11 forwarding was necessary for you to use from a desktop/laptop? You should be able to just open a terminal, ssh into the Anbernic, and run /opt/system/Cloud Settings.sh?

I've seen Syncthing get mentioned a lot. It looks very nice, but I haven't tried it because once I set up Arklone on all my Debian-based devices, it's "just worked" for years and I've never had to think about it (except for the rare GH issue, lol). Hopefully it will do the same for you now!

Syncthing is just local machine / targets. I used SSH X11 forwarding for convenience vs the tiny screen on the device and a keyboard. Yea it works fine there. The env on the device has trouble with the redirection used to get the choice var. Like I said, you can just use stderr to file to get around that.

If you're interested, we can keep testing this or I can drop it for a simpler rclone sync I noted. Up to you ha.

ridgekuhn commented 4 months ago

Well, it would be nice to know that it works on newer devices, but I don't want to force the user to install X server. I think the next update should be moving the ArkOS-specific installation scripts from my ArkOS fork and into this repo, then change them to add their own section to es_systems.cfg as mentioned above, and also back up the stock EmulationStation systemd unit instead of overwriting it completely since hopes for this being merged upstream died long ago. After that, probably rewrite the input listener to use the new gpkeytobtool u mentioned, or putting my joy2key port back in, or both, or something. Only thing is, I think there's probably only a handful of ppl using this, and if both our versions work for each of us, there's not a lot of incentive to work on these updates, lol

mdeguzis commented 4 months ago

Ok let me know if you want rg353m tested if you make any updates. I'll do what I can tinkering with this fork.

mdeguzis commented 4 months ago

I got movement and buttons working by stealing some code from /usr/bin/osk

christian_haitian — Today at 9:40 AM
That will not support movement in the script.  Just monitoring for a particular button press.  For movement, you can use gptokeyb in /opt/inttools.  See /usr/bin/osk on how it can be used.
ProfessorKaos64 — Today at 10:34 AM
Cool I'll check that out. That repo uses whiptail  it doesn't display the menu if doing the redirect to a car in bash. Have to see how to fix that first. The dialog works just fine when invoked via ssh X11  forwarding

Updating my fork. Things seem to work (with the 2> /tmp/file to get input workaround vs all the redirects)

The screen is a big too big (cut off on the outside), but that should be fixable. (edit fixed))

I was able to configure syncing and do what I need using commit:

ridgekuhn commented 4 months ago 
elif [[ -e "/dev/input/by-path/platform-singleadc-joypad-event-joystick" ]]; then

I guess that answers the question about the input drivers. Would u mind sharing the output of:

cat /proc/bus/input/devices
mdeguzis commented 4 months ago

I still have to check why the "choosing the remote" menu doesn't launch. I see above what you said about starting on boot, shame you can't just let it sync every so often and use the sync option of rclone. That's what I always just used.

ark@rg353m:~$ cat /proc/bus/input/devices
I: Bus=0019 Vendor=0000 Product=0000 Version=0000
N: Name="rk805 pwrkey"
P: Phys=rk805_pwrkey/input0
S: Sysfs=/devices/platform/fdd40000.i2c/i2c-0/0-0020/rk805-pwrkey/input/input0
U: Uniq=
H: Handlers=kbd event0 dmcfreq 
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="Hynitron cst3xx Touchscreen"
P: Phys=input/ts
S: Sysfs=/devices/platform/fe5b0000.i2c/i2c-2/2-001a/input/input1
U: Uniq=
H: Handlers=event1 dmcfreq 
B: PROP=2
B: EV=b
B: KEY=400 0 0 0 0 0
B: ABS=261800000000003

I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="adc-keys"
P: Phys=adc-keys/input0
S: Sysfs=/devices/platform/adc-keys/input/input2
U: Uniq=
H: Handlers=kbd event2 dmcfreq 
B: PROP=0
B: EV=3
B: KEY=200000000

I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="gpio-keys"
P: Phys=gpio-keys/input0
S: Sysfs=/devices/platform/gpio-keys/input/input3
U: Uniq=
H: Handlers=kbd event3 dmcfreq 
B: PROP=0
B: EV=100003
B: KEY=c000000000000 0

I: Bus=0019 Vendor=484b Product=1101 Version=0100
N: Name="retrogame_joypad"
P: Phys=retrogame_joypad/input0
S: Sysfs=/devices/platform/singleadc-joypad/input/input4
U: Uniq=
H: Handlers=js0 event4 dmcfreq 
B: PROP=0
B: EV=b
B: KEY=f00000000 0 0 0 7fdb000000000000 0 0 0 0
B: ABS=1b

I: Bus=0000 Vendor=0001 Product=0001 Version=0100
N: Name="rk-headset"
P: Phys=
S: Sysfs=/devices/platform/rk-headset/input/input5
U: Uniq=
H: Handlers=event5 
B: PROP=0
B: EV=3
B: KEY=400000000 0 0 0
ridgekuhn commented 4 months ago

It's not so much that u can't use the sync cmd, it's the race condition between RetroArch timestamping the local filesystem while updates are still coming down from the cloud. Does that make sense?

Thx for the output. I originally dropped joy2key bc RetroPie rewrote it to use sdl instead of udev while I was working on this and I didn't want to figure out how to re-implement it (and I assumed oga_controls would be developed side-by-side with ArkOS and be futureproof). Looks like retrogame_joypad should be available at /dev/input/js0 though, so it should work with the old udev joy2key, it would just need the correct config file placed in /opt/joy2key/udev, which u should already have in ~/.config/retroarch/retroarch-joypads or ~/.config/retroarch/autoconfig. (Now that I think about it, I should change the joy2key fork to use those directories instead of /opt/joy2key/udev).

mdeguzis commented 4 months ago

Confirmed all menu items are functional in my fork. I can keep to using my fork. Feel free to compare or request a PR. Tested on RG353M.

Tested

./install.sh
./uninstall.sh
./install.sh

Made some tweaks as well

NOTE: If you every merge / PR, remove my extra files added to https://github.com/mdeguzis/arklone-arkos/blob/master/src/rclone/scripts/send-arkos-backup.sh. I like to also backup a few dotfiles in my homedir.

ridgekuhn commented 4 months ago

Hmm if this gptokeyb tool uses SDL, it should be backwards-compatible w older ArkOS devices, as long as there's an SDL config in gamecontrollerdb.txt; but both will need to be provided for older ArkOS systems or non-ArkOS Debian-based ones. If gptokeyb is Christian's project, I wonder if configs for the older devices have been omitted, and if these are possibly available in the Wummle fork if so?

mdeguzis commented 4 months ago

Could make a condition in input listener based on device type. The hostname is actually the model number, e.g. rg353m