[OS] Arch Linux

GameShell Firmware and Apps
22

thanks <3

  • Is there a way to set up an autostart script so that retroarch launches on boot?

sure, the launcher is run using the same way, check file ~/.xinitrc
here is end of file :

~/.fehbg &
fantasti &
exec monsterwm

in fact it’s just an sh script, called at each x server start

~/.fehbg & set the background picture
fantasti & launch the launcher as a background program
last line call the Window Manager who’s a need to handle sound / backlight && windows transition
you could add retroarch & just before the monsterwm call

I made the mistake of attempting to edit the mimekey.list to change default apps for gb and gbc (would really want to use gambatte for those, and possibly gpsp for gba if it is working). This ended up breaking it. Is there a way to get it working again?

what i pasted few post upper is my personal current setup, it was cleaned before i release the image,
be sure each desktop file you specified exist
safe way to make association is calling mimeopen -d *your file* it will show you a menu with current association & an entry to create your own association,
currently you may try give it retroarch -L /usr/lib/libretro/gambatte_libretro.so for gb roms

gbsp libretro core is in the aur,
you could install & compile it using pikaur -S libretro-gpsp-git, or just write pikaur gpsp who will search all packages related & ask you install it
in a second time use mimeopen to associate roms with it

i will create dedicated packages for some core with precompiled binary & desktop files

i currently work on packages listing & direct install from launcher

edit > tryed gambatte work fine, also compiled gpsp, it work nice, i’ll create PKGBUILD this night for an easy setup

1 Like
23

Thanks for the quick reply!

I attempted to edit the .xinitrc file, but unfortunately, now I’m stuck in a bootloop, even after reverting the edit.

24

loop could append in two cases,

  • the .xinitrc file has terminated, so xserver reach end and just restart
  • the xserver cannot start and retry infinitely

last line, exec monsterwm does not have a & so it does not run in background
all you launch before it must have the & to run in background and give real hand to the wm

thing you can check :

  • make sure you have chmod +x the .xinitrc file
  • make sure file is in /home/gs/
  • check log file of Xserver to be sure it’s not crash, it could be found at /var/log/Xorg.0.log

here is initial .xinitrc script :

[gs@gs ~]$ ls -lha ~/.xinitrc 
-rwxr-xr-x 1 gs gs 622 Dec 21 01:07 /home/gs/.xinitrc
[gs@gs ~]$ cat ~/.xinitrc 
#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then
    xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then
    xrdb -merge "$userresources"
fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

~/.fehbg &
fantasti &
exec monsterwm
2 Likes
25

just created a dedicated package for .xinitrc file,
as gs user :

sudo pacman -Sy
sudo pacman -S xinitrc-gameshell
cp /usr/local/share/gameshell/.xinitrc ~

you could also do sudo pacman -Syu for a full system upgrade, i upgraded kernel few days ago to 5.4.7 and there is a mainline xorg server upgrade

for your init script you could also create a sh file into /etc/X11/xinit/xinitrc.d/
but if you want retroarch gain focus at boot you must edit real ~/.xinitrc file and call retroarch & after fantasti &

2 Likes
26

just compiled & packaged latest gpsp

sudo pacman -Sy
sudo pacman -S libretro-gpsp-gameshell

this emulator will need the gba bios to run, here is the right path :

/home/gs/.config/retroarch/bios/gba_bios.bin

you could try it with :

export DISPLAY=:0
retroarch -L /usr/lib/libretro/libretro-gpsp.so *your gba file*

for set it as default gba handler, exec :
mimeopen -d *a gba file*

and give it :
retroarch -L /usr/lib/libretro/libretro-gpsp.so

2 Likes
27

What are the changes on 0.4.j and 0.4.k?

28

fantasti 0.4.j include listing / install / uninstall / update packages of dedicated repository directly from launcher

0.4.k was a bug fix release, fixing a parsing problem on “update all package” command

i currently thinking about possibility of define file association from launcher

i also think about allowing full system update from launcher, i initially include it but removed from release due to it’s a bit “risky”, maybe allow it only if batterie > 90% with power plugged and/or include it on a “secret” menu entry

for future i also want redirect & display all process messages from stdout/err

still yet in alpha state

i also need create a full package cross compile system onto the server, for now all packages are regularly compiled by hand on my own gameshell.

1 Like
29

Awesome. Thank you for your work!

RetroArch just updated to 1.8.4 on Arch ARM some minutes ago! I’ve downloaded it already.

2 Likes
30

you’re welcome :slight_smile: thanks for using it !

retroarch update is a great news ! latest mainline build was from november
i compiled latest git multiple times without real success, i must miss anything :confused:

1 Like
31

just released fantasti source code, https://github.com/r043v/fantasti

for more easy update & help mutualise work, i’ll soon release as git repo the collection of PKGBUILD who compose the dedicated repository

2 Likes
32

FYI, I found the 5.4.18 kernel here: https://github.com/asypost/clockwork-pi3-kernel/commits/master

I think that this is now the official kernel for the gameshell, but sadly the patches are not maintained independently as in your repo

33

How do you generate the uboot partition? are you using a variation of https://github.com/JeremyGrosser/u-boot/tree/clockworkpi_cpi3 ?

34

thanks for the link i will take a look, the maintainer seem to apply all mainline linux commits to his already patched source tree, i prefer keep using official linux source code and maintain aside our dedicated patchs

using @Joao_Manoel hacked patch for backlight i’ve got a 5.5.2 running fine, i need release it
also 5.6 branch just get his first release candidate so it need a try

i also started write a real port of the backlight driver using new api, without success for now

yes have patch separated is much better but my pkgbuild file still need some cleans

i was get a fast look at the uboot port you link but current arch image still use clockwork one, actually what is custom is the boot.scr file who use official arch linux arm “mainline” method instead of old legacy one used on the debian image

i must have a look at recompile uboot

2 Likes
35

Isn’t that @shell repo?

36

It is, yes. Is more up-to-date that the one from https://github.com/clockworkpi/Kernel, that do not contain the sources for v0.5

38

I think we could make a standard version of the kernel merging what we could optimize, and trying to get it updated with mainline kernel

2 Likes
39

Do we really need another driver? I haven’t tried to look carefully enough, but our backlight cannot be so different from what we already have in the mainline kernel.

The ocp8178_bl.c code uses as it bases the gpio_backlight.c from mainline:

If we cannot use only the gpio_backlight driver with some changes in our dts, we can at least use it to update our code.

The ocp8178 only need a PWM input, like many others led driver.

I would try to avoid making big changes to the kernel by adding new drivers (or trying to fix ours) because it would require a constant update from our side in the future.

1 Like
40

that’s what i do, porting mainline changes, not rewrite another one ^^

I think we could make a standard version of the kernel merging what we could optimize, and trying to get it updated with mainline kernel

+1!

It is, yes. Is more up-to-date that the one from https://github.com/clockworkpi/Kernel , that do not contain the sources for v0.5

isn’t they use @shell kernel for 0.5 ?

1 Like
41

Congrats @r043v for this awesome break through. More of a debian user myself, but diversity is key for this type of project. :star_struck: when users will be able to choose their favorite distro for the game-shell and their custom menus, etc. Anyone figured out a way to multiboot yet ? :question:

42

there are projects to multiboot for uboot but is this really a need ?

all games & others things could run with all different possible OS,

belong the work to port a multiboot solution it will also take the boot time longer, and will need a bit of work to make the different OS compatible too (patch auto mount partition id etc …)

… – …

launch a different menu interface is as easy as edit the .xinitrc file (if xserver used), sure in the long run things could be automated

also launchers are dedicated to the system, there is tiny difference who could breaks things, major one’s are package system and the wifi management lib

in arch netctl is used, fantasti can create config for it but cannot config others for now, same thing for clockwork launcher who cannot config netctl

fantasti also manage pacman to directly install 3rd packages, and for now cannot install from apt, apt code is included (from pingu apt manager) but need some work to use it properly.

also for this way we need clean packages for launchers, clockwork one have some deps so it need more work
for fantasti it’s pretty easy to package as it’s binary and for retroarch it must be ok as all OS use it.

1 Like