Jivelite on Joggler

[Chill]

Thanks for the example file - I'll have a look at that. And thanks for checking re the shebang - yes, it was there, and the script was executable, and I was able to start Jivelite successfully by running that script from the command line. I suspect the autostart issue may have something to do with X. Even if it doesn't, I think it's going to be necessary to run it without X for the internal version, due to space, so I think I'll have another crack at running the current Jivelite build without X - it may be that the autostart problem then goes away by itself!

If we can get Jivelite working properly without X, with a properly calibrated touchscreen, then I think the next steps on the path would be:
1) compile it without X support, to minimise the binary size (Ralphy's offered to help with this, thankfully!)
2) transfer the binary, and any runtime SDL libraries that it needs (as detailed by Ralphy in the Squeezebox forum thread), over to the internal version.
3) sort out the autostart stuff

I'm halfway through rebuilding the development environment from the raw 8GB USB Bionic image, so as to be sure which steps are needed and to document the steps.

[Man in a van]

It's possible to autostart using crontab-e and also via a .desktop file.

The problem I had before was the mouse arrow.

There is lots of info about starting a .sh (its getting the most up to date that's the problem )

FYI I just had to install xinit

[Man in a van]

Followed your startjivelite.sh

and did

Code: Select all

 sudo crontab -e

Code: Select all

@reboot /home/joggler/startjivelite.sh

https://www.kompulsa.com/run-a-program- ... ntu-18-04/

It works but the volume on the selected player is very low. I have no idea about that at the mo, everything is set to 100% where it should be. There must be a setting in the joggler but alsamixer produced no information.

EDIT: Thought about the software side and could find any immediate answers.
Then a lightbulb KISS moment
On my desktop computer I use a passive pre-amp (with two controls) as a switch-box into a small amplifier that has only one input.
Yes!...... I had turned down the volume whilst messing around.


That's me finished for today.

I feel like i have lost a whole week of my life

ronnie

[Man in a van]

Might also try with a .desktop calling the jivelitestart.sh


Just had a look here

Code: Select all

joggler@openframe:/etc/xdg$ cd autostart
joggler@openframe:/etc/xdg/autostart$ ls

at-spi-dbus-bus.desktop xdg-user-dirs.desktop

[Chill]

This site seems to have the answer to the autostart thing. I made a script file in /etc/profile.d/ with the contents:

Code: Select all

if [ "$(tty)" = "/dev/tty1" ]; then
    TSLIB_FBDEVICE=/dev/fb0 TSLIB_TSDEVICE=/dev/input/event2 TSLIB_CALIBFILE=/etc/pointercal TSLIB_CONFFILE=/etc/ts.conf TSLIB_PLUGINDIR=/usr/local/lib/ts /home/joggler/jivelite/bin/jivelite
fi

And that does attempt to start Jivelite at boot, without a login prompt.

I also tinkered with the other bit of advice on that page, to change the default login user from 'root' to 'joggler'. That also works nicely, but I haven't been able to combine both steps yet because if the default user is 'joggler' then Jivelite wants joggler's password to run at boot. I think that's easily fixed though.

The very long command string to start Jivelite is just a way to supply all the environment variables. I've compiled it the normal way, and I've also compiled tslib with these instructions. I can run ts_calibrate to create /etc/pointercal, but Jivelite only shows the splash screen then quickly drops back to a command prompt without any sort of error message.

This basic setup, of compiling Jivelite the same way and running it with the same command, worked with the Trusty base/server image, so there's something wrong with the way I'm compiling or running running JiveLite for Bionic.

[Chill]

I also tinkered with the other bit of advice on that page, to change the default login user from 'root' to 'joggler'. That also works nicely, but I haven't been able to combine both steps yet because if the default user is 'joggler' then Jivelite wants joggler's password to run at boot. I think that's easily fixed though.

I changed the command by inserting 'echo <password> | sudo -S ' before the jivelite command, so that the password is provided on the command line (obviously replace <password> with the real password). So the whole command becomes:

Code: Select all

TSLIB_FBDEVICE=/dev/fb0 TSLIB_TSDEVICE=/dev/input/event2 TSLIB_CALIBFILE=/etc/pointercal TSLIB_CONFFILE=/etc/ts.conf TSLIB_PLUGINDIR=/usr/local/lib/ts echo <password> | sudo -S /home/joggler/jivelite/bin/jivelite

This enables me to have joggler as the default user for tty1, and for JiveLite to autostart without asking for a password.

[roobarb!]

I feel like i have lost a whole week of my life

Haha, that's a common feeling!

Sounds like you've been making great progress.

[Man in a van]

because if the default user is 'joggler' then Jivelite wants joggler's password to run at boot. I think that's easily fixed though.

I use crontab to autostart Jivelite and it just starts into the full jivelite screen

[Chill]

I use crontab to autostart Jivelite and it just starts into the full jivelite screen

Does it get beyond the splash screen? Is that under X?

I've got the autostart thing working with the /etc/profile.d/ approach, and I've compiled SDL with tslib support, with the aim of eventually building JiveLite without X support, to minimise the binary size. So without running it under X, JiveLite currently crashes out after the splash screen, with an error relating to screen resolution. My post on the Squeezebox forum explains where I've got to.

Ronnie - are you saying you've got it to work without X? How did you get to that point?

[Man in a van]

I have had to install xinit.

Without it, if I just do (whilst connected to the jogger via a hub)

Code: Select all

sudo /home/joggler/jivelite/bin/jivelite

then I get the same thing, a quick flash of the splash screen and that's it .

The trusty image used to start without adding anything, but the xorg (or just xinit) kept it stable, especially with your disable the mouse trick .

This morning I tried the

Code: Select all

sudo apt-get install  matchbox-window-manager 

instead of xinit, but that just borked everything.

I have decided that its best to do the two builds first, then add on the bits required, as I sometimes get an error in the jivelite build.

ronnie

[Man in a van]

@ roobarb!

I have tried using the Openframe 2 (Cisco) to build on but keep getting an error In the Jivelite build. I'll try again sometime soon.

I have used a completed build from the O2 joggler and that works on the Cisco one, so I must be doing something wrong in the build process.

The wireless does not work on the Cisco model, I did ifconfig and it shows bond0 instead of wlan0.

I changed this in the network.yaml file but it just defaulted to wlan0.

I have googled bond0 and it seems I am just confused

Any thoughts?

ronnie

[Chill]

@Roobarb

When you created the Squeezeplay installations, did you use just SDL/TSLIB, or do you run it under X somehow? If you used SDL/TSLIB only, can you divulge which environment variables you specified for all the TSLIB and SDL configuration? I'm currently using

Code: Select all

export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event3
export TSLIB_CALIBFILE=/usr/local//etc/pointercal
export TSLIB_CONFFILE=/usr/local/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/lib/ts
export SDL_MOUSEDRV=TSLIB
export SDL_MOUSEDEV=$TSLIB_TSDEVICE

and whilst I can run ts_calibrate to generate a pointercal file, and ts_print works correctly, the pointer location in JiveLite is all over the place. I've narrowed it down to an issue with the SDL_MOUSEDEV variable. What did you use for this variable in Squeezeplay OS?

If you used X, how did you fit that into the 1GB flash storage?

[Chill]

Progress of sorts. If I remove the SDL_MOUSEDEV environment variable altogether, then the mouse behaves less erratically, and in fact seems to be scaled down by half (e.g. if I touch the bottom right corner the mouse pointer moves to the middle of the screen).

Here's the odd bit though - if I touch the top left of the screen it seems to self-calibrate! After that the cursor follows my finger quite nicely.

Any thoughts on what could cause this?

[Chill]

Got there in the end. Despite building libSDL with TSLIB support, Jivelite was building with an old version of SDL. Fixed that with Ralphy's help, and now Jivelite is working properly with TSLIB and without X. I've set it to run at boot, and it seems to work properly. Instructions posted on the Squeezebox forum here.

Just need to see about transferring it over to the internal flash storage, and then work on getting the right applets, splash screens etc.

[Chill]

A couple of questions for Andy.

I've got to the stage where everything runs, and I've added an applet to control a local instance of Squeezelite. In the Jivelite on a Joggler thread on the Squeezebox forum I've posted links to images for an internal version and an external USB version. They're just initial releases, which I'm hoping people can use to uncover issues with the build. A couple of issues have already been highlighted.

1) On your Squeezeplay build, the soft power button turns the backlight off completely, whereas it doesn't on my Jivelite build. I've traced that to the 'xset' command, which doesn't run on my Jivelite build, presumably because I'm not running X windows. With Ralphy's help I've built Jivelite to use just the SDL libraries to control the touchscreen/mousepointer etc. So am I right that you run Squeezeplay under X?

2) Do your latest Bionic images make use of the feature mentioned in the wiki page on this site?

It will run a read-only root fs with a volatile rw-system overlaid allowing most apps to function normally whilst preventing ware on the flash memory and allowing the system to be powered off at any time without risk of filesystem corruption. This is ideal for systems which will just run a simple GUI that either does't need to save any data - or saves all their data remotely.

[roobarb!]

1) On your Squeezeplay build, the soft power button turns the backlight off completely, whereas it doesn't on my Jivelite build. I've traced that to the 'xset' command, which doesn't run on my Jivelite build, presumably because I'm not running X windows. With Ralphy's help I've built Jivelite to use just the SDL libraries to control the touchscreen/mousepointer etc. So am I right that you run Squeezeplay under X?

IIRC, yes. In fact, yes, it must do if I was using xset. That shouldn't be the only way to power down that backlight though... surely.

2) Do your latest Bionic images make use of the feature mentioned in the wiki page on this site?

It will run a read-only root fs with a volatile rw-system overlaid allowing most apps to function normally whilst preventing ware on the flash memory and allowing the system to be powered off at any time without risk of filesystem corruption. This is ideal for systems which will just run a simple GUI that either does't need to save any data - or saves all their data remotely.

In a roundabout way. It doesn't set the root to read-only, but it does shove as much temporary file generation as possible into RAM; anything volatile is redirected to RAM through tmpfs. If you do a

Code: Select all

mount

on the Joggler you should see which mount points have been reconfigured in /etc/fstab. I am pretty sure that you could set the root to read-only at this point and still have the thing boot and work perfectly well. The 'zombie' 3.18 kernel has overlayfs support compiled-in too, so you could look to using that.

I wish I could find a bit more time to help out with this stuff - even catching up with people's progress is tricky at the moment! It's very cool to see what people are up to, though.

[Chill]

IIRC, yes. In fact, yes, it must do if I was using xset. That shouldn't be the only way to power down that backlight though... surely.

You're probably right. I've not managed to make vbetool do anything on the Joggler, but setterm looks promising. I can blank the screen from the command line if I attach a keyboard to the Joggler (not from an SSH shell yet, as it's a different terminal), so I will experiment with triggering it from within Jivelite.

In a roundabout way. It doesn't set the root to read-only, but it does shove as much temporary file generation as possible into RAM; anything volatile is redirected to RAM through tmpfs. If you do a

Code: Select all

mount

on the Joggler you should see which mount points have been reconfigured in /etc/fstab. I am pretty sure that you could set the root to read-only at this point and still have the thing boot and work perfectly well. The 'zombie' 3.18 kernel has overlayfs support compiled-in too, so you could look to using that.

Daunting stuff for this novice. Would having root as read only prevent all writing to root, or is there a way to bypass that so as to write e.g. settings files permanently to disk?

I wish I could find a bit more time to help out with this stuff - even catching up with people's progress is tricky at the moment! It's very cool to see what people are up to, though.

Entirely understandable - your initial creation of the Bionic images was a huge help.

[roobarb!]

Daunting stuff for this novice. Would having root as read only prevent all writing to root, or is there a way to bypass that so as to write e.g. settings files permanently to disk?

For my money, if you need to write to root you're probably better off using it in read-write mode with the majority of things offloading to tmpfs, as it's configured at the moment. The likelihood of a power-down corruption is probably not notably higher than if you'd gone to the trouble of mounting the area you needed write access to separately. But that's just my conjecture.