Some time ago I needed a virtual #ARM machine and while I’m not entirely sure any more why that was I did seem to have an inspirational moment and made a template of this. Here is what the #qemu config for #Proxmox _may_ look like:
It makes sense to install the package cloud-init to some stuff can be set from outside of the machine.
…and yes, it’s just as slow as expected from an ARM 🤓
I’m also not entirely sure if this is really officially featured by Proxmox (just like btrfs 🤷) but the machine was doing it’s job without an issue for years and I did just replay the template on VE 7.4 so I guess it’s fine 🤷
This is a project I kept postponing for years but when I eventually got my hands on all the required parts I had no longer an excuse and eventually built the first. It’s a portable music player for children that does not require internet access. It features selections of pre-installed music or audio books via RFID cards, that may come in all shapes and may even be integrated in toys. There are also 3 to 5 playback controls in the form of huge arcade buttons. Ideal especially for our middle one, who has to endure stationary stay for most of the week in a hospital.
And while this box is still missing proper decorations and button decals it’s full functional and portable. Also hey, kids ain’t stupid – they find the proper button without decal too. Even the baby found out where to put the RFID cards for the music to change 😉
The leg work for this was done by @xfjx@chaos.social and the project is described in great detail at https://www.voss.earth/tonuino/ – I did however not order the offered PCB and just soldered everything to a generic maker board to keep the costs down. Just like the arcade buttons, that I had left over from another project, I also have a bunch of such boards. The speaker was salvaged from an old entertainment system that broke down long ago and the box… ah well I guess it speaks for itself. Can’t say I was happy with the drill but the box was just perfect for our purpose.
First we built a test setup after salvaging all the needed hardware. The Ardunio parts are off the shelf, nothing special here. I had to improvise a little on the wiring due to missing wires. I opted for the older branch that just needs Arduino Studio, to install the software itself. There is a more modern version using platformIO but something with that does not like my vscode and I never managed to successfully compile it.
I eventually got the idea how the RFID cards worked and could be trained to the system and also did some tests like it’s maximum power usage. It has a passive speaker and cranked up to max it would consume 0.09A max – and on regular volume it was sitting at comfortable ~0.06A. Which is pretty fine. This would run for days with a decent power bank that could be dropped right into the box later if no external PSU is used.
Next was preparing the box. Luckily I had just the right drill for the buttons but making the holes was a pain in the neck. This had to be done very slow because the hard plastic would easily rip and splinter. I opted for a very massive USB connector in the end because the microUSB one used first broke on the 3rd use already. That was probably a little bit too cheap. The replacement is way more sturdy, which is kinda what I want for the children anyway. Everything the box needs to operate, like an old phone charger, a very long USB cable, and the RFID cards do fit inside the box for transport.
So one of the questions left was what to put on it’s internal SD card. Some of their favourite music, of course. What else though? Easy. We have a public audio centre at https://www.ardaudiothek.de/ offering a lot of stories and podcasts even for children. Downloading them one by one manually was cumbersome though. Luckily @1337core@chaos.social was just releasing his first version of Audiothek Downloader at https://github.com/Leetcore/audiothek-downloader so I had more gigabytes than the SD card could manage in minutes. The only issue was that the SD card needs the audio files enumerated so I did some quick scripting to rename the downloaded files. I had also no use for the downloaded cover images. It’s not beautiful but it got the job done:
#!/bin/bash
folder=$1
oldpwd=`pwd`
if [[ -z $folder ]]; then
echo "Missig paramater id"
exit
fi
folder="output/${folder}"
if [[ ! -d ${folder} ]]; then
echo "Missig folder ${folder}"
exit
fi
cd $folder
shopt -s extglob
for filename in +([0-9])_*.*; do
[ -e "${filename}" ] || continue
oldfile=${filename}
# remove including the first underscore to get the index
index=${filename%%_*}
index=${index##+(0)}
# pad the number with zeros
newfile=`printf %03d ${index}`
# combine new index with old filename, remove up and including first underscore
newfile=${newfile}_${filename#*_}
if [[ ! -f ${newfile} ]]; then
mv -v "${oldfile}" "${newfile}"
fi
done
declare -i n=1
declare -i i=1
for filename in *.mp3; do
[ -e "$filename" ] || continue
target_dir=`printf %02d ${i}`
if [[ ! -d ${target_dir} ]]; then
mkdir ${target_dir}
fi
target_file=`printf %03d ${n}`
if [[ ! -f "${target_dir}/${target_file}" ]]; then
mv -v "${filename}" "${target_dir}/${target_file}.mp3"
fi
n+=1
if (( n > 255 )); then
n=1
i+=1
fi
done
cd $oldpwd
exit 0
This goes into e.g. to-tonUINO.sh into the root folder of the Audiothek Downloader where it can be executed after downloading a category. Like this for example:
The resulting folder|s can be renamed, depending on what is already on the SD card, and moved to the SD card. It also makes sense to set the RFID card to audiobook mode so the TonUINO saves the position for the listener and does not start at the beginning again.
Now it’s up to the children to do some decorations. Our oldest wants her version built into a box that looks like a book. Hope we can get that one done soon too.
I usually play #FlyDangerous on Linux PC. I switched to Proton because I was eager to see some upcoming changes, like #headtracker support, on the public_beta branch. And while this works[1] I was once more flabbergasted how complicated it is to set my desired display resolution of 5760×1200. I’m using a multihead setup with several displays and as usual the game engine would not let me _simply_ set that. Even in windowed mode (I mean I get that this won’t work with fullscreen).
There are several ways to work around this, especially with Proton, but I was looking for the prefs file I know from Linux. I found it in the end in the file compatdata/1781750/pfx/user.reg (that’s like the Windows registry but as plain file read by Wine) where the values are stored as dword under [Software\\StarGoat\\FlyDangerous]. In hex.
"Screenmanager Resolution Height_h2627697771"=dword:000004b0
"Screenmanager Resolution Width_h182942802"=dword:00001680
"Screenmanager Resolution Use Native_h1405027254"=dword:00000000
So 0780 and 04b0 are in the end 5760 and 1200. And sure enough, on the next game start I get _my_ desired resolution:
Sadly when I change settings in the game this gets overwritten again – so keep a backup around and drop it in again. This may even be added to a script – let’s see how long until this gets on my nerves and I automate that.
For the interested: This is how the same thing looks on the native version in the file ~/.config/unity3d/StarGoat/FlyDangerous/prefs
Working on a #cog loosely based on NZ-43 (14C). It’s approximately 12m long 🙂
First time I’m trying my luck with a vessel and not a building. The curving is difficult to realise in #RisingWorld tho.
It started life in the old Java version of the game because the new Unity version has no posters yet. I had to segment the plan of the cog (carved in a very bad resolution from a PDF) into several in-game posters that had to be aligned in-game again to get the proper measurements.
After that I moved the blueprint of the frame over to the new version and started putting planks on it. A cumbersome process during which I learned a lot. I’ll probably make another and more improved hull based on the gathered know how.
I also fell straight into another “not yet implemented” trap. RisingWorld has a flip command to mirror an object and I kinda assumed this would work with blueprints too. It does not. And I was really not looking forward to put plank on both sides of the frame.
Luckily most of the leg work to read the binary blueprints was done by @paulevs before who released https://github.com/paulevsGitch/BlueLib under the MIT license. It has been a while that I touched Java but I could come up with some code of my own that would flip the planks only (I used rounded cubes for the planks exclusively) making use of this lib and the very first try at it looked promising already.
Here is the source I came up with in case you wonder:
I’m kinda happy with the result. This Lib also allows me to change the texture of the elements so I don’t have to worry how the used texture during the construction may look in the end.
Now onwards to improve the curves. I really wish for a bend mode where the beginning would snap on to an existing object and the opposite plane could be moved around individually.
Bagged #RebelGalaxyOutlaw on GoG today and had a blast. Needed some fiddling to get my X52 Pro up and running since the game only supports _one_ Gamepad but that’s nothing that would stop my #LinuxGaming 😂
Video: Flight tutorial snippets from Rebel Galaxy Outlaw played on Linux PC
Update: I found _way later_ that there is a switch in the launcher to enable joystick support (which brings up my X52 just fiine). What a strange design decision.
Fly Dangerous 5.0 was released and it is packed with new features like reflections on the ship, Steam leaderboards and ghosts! So you can basically race against yourself or others from the leaderboards!
As usual I gave it a spin and had a blast.
First things first though. The Linux version defaults to OpenGL and this resulted in like 25 FPS for me and the input of my X52 Pro (mapped as XBOX controller) was so laggy that I could sip coffee during each course correction. This was when I remembered the magic parameter -force-vulkan from other Unity games and from here it was smooth sailing. Eventually I ended up with the game start options obs-gamecapture for recording, mangohud for some FPS info and -force-vulkan for… well, FPS.
Anyway, I’m not doing too bad after some rounds. Only issue left is that I can not disable the flight assist for some reasons. Probably a bad binding but I was eager to play so I went with it.
Fly Dangerous (on Linux PC) – with Vulkan
Oh and did I mention that this little gem is still for free and even opensource?
I want more control over what my microphone picks up on screen share in video conferences or during streaming but I don’t want to buy a hardware mixer. I also want to be able to disable the microphone with a hotkey but it doesn’t have any physical switch. So achieve all this I utilise PipeWire to run a bunch of virtual devices that I can control via pavucontrol and obs later. Video conferences get this as “default device” so they don’t get a chance to mess up my audio setup (looking at you Teams). The steps are the same for PulseAudio if you don’t have PipeWire (yet).
#!/bin/sh
# setup virtual device intended for monitoring
pactl load-module module-null-sink sink_name="BekoBlaster" device.icon_name="audio-card-analog" node.nick="BekoBlaster" node.description="BekoBlaster-16" sink_properties=device.description="BekoBlaster-16"
# setup virtual MIC so intended monitoring device can be recorded from as MIC
pactl load-module module-remap-source master="BekoBlaster.monitor" node.nick="BekoMic" device.icon_name="audio-input-microphone" source_name="BekoMic-16" source_properties=device.description="BekoMic-16"
# IMPORTANT:
# RUN `pavucontrol` => Select Tab Record => Set BekoMic-16 input to "Monitor of BekoBlaster-16"
The 16 is not important. It’s just my kind of humour as my first Linux PC had a SoundBlaster16 😛 It also is a pattern sufficient enough so I don’t mix this up with the zoo of real microphones or audio sinks attached to my computer.
This is already sufficient enough so that everything played on the device BekoBlaster-16 can be recorded on the BekoMic-16 again, that I select as input microphone for Browser (video conferences) or Discord at this point. This can be done with pavucontrol – or later in obs.
This isn’t enough, of course. In case of e.g. playing music (or streaming a game) I’d also want to hear the sound myself too. For this I create an additional null sink and a combined sink. With this approach I can later fine tune in obs what gets recorded to which audio track (where audio track 1 is the one used for streaming) and what ends up on the BekoBlaster-16, that acts as my monitor and due to the remapped source also as virtual mic.
# setup virtual device for games (or whatever OBS should record)
pactl load-module module-null-sink sink_name="OBS-Blaster" device.icon_name="audio-card-analog" node.nick="OBS-Blaster" node.description="OBS-Blaster" sink_properties=device.description="OBS-Blaster"
# OPTIONAL setup a combined sink so I can enjoy game sound while OBS gets a copy
pactl load-module module-combine-sink slaves="OBS-Blaster,bluez_output.10_4F_A8_84_18_01.a2dp-sink" node.nick="OBS-Blaster-AND-Headphones" node.description="OBS-Blaster-AND-Headphones" sink_properties=device.description="OBS-Blaster-AND-Headphones"
# Important tools to manipulate: `pw-cli list-objects`, `pw-cli destroy $id`, `pactl list short | grep module`, `pactl unload-module $id`
With this (and my headset connected) it starts to get crowded in my device list.
As you can hear err… hopefully see: The sink OBS-Blaster-AND-Headphones is now selected for playing music which results in the music being played on the next virtual sink OBS-Blaster and my h.ear (MDR-100ABN) headphones. The same could be done with the BekoBlaster-16, of course, but bear with me. We still don’t have any real microphone added to the mix and while this can be done with PipeWire or PulseAudio alone too I need this usually with video included too so obs it is.
Here the most important setting is the monitoring device, which is the BekoBlaster-16 from the beginning, that can be used as microphone in e.g. Discord later again.
Next is the set-up of the mixer where I’m interested in 4 devices only:
The BekoMic-16 without monitor (it is the monitor so this would result in an echo chamber) and optional track 5 for recording (so I’ll know later how the mix sounded – but this is never used for video editing later).
The desktop audio without monitor, so random system sounds (or other Discord voices!) don’t make it to any stream. It can be recorded on it’s own track tho in case I fcked up or need a reference later on during editing.
The Mic/Aux, which represents the real microphone used. It is echoed on the monitor microphone and on track 1 (send to my streaming server) and on track 2 so I have a separate microphone track later to work with in post edit.
The OBS-Blaster, which usually represents the game I’m playing. It is echoed on the monitor microphone and on track 1 (send to my streaming server) and on track 4 so I have a separate game/music track later to work with in post edit.
This way I can control in great detail what ends up on the Discord / a video conference / game streaming, while I get the full power of obs scenes (where I also do my greenscreen mixing), mute microphones as I see fit and have some material to work with later when I decide to make a video on stuff. Here I did set up Discord to read from the virtual BekoMic-16 and output to my headphones only (where no recording in OBS is done) – so perfect for most Discord / video conference sessions.
Don’t mind the flipped video preview. That’s perfectly fine and will look right for the viewers later. This is by the way the virtual camera sink feature of obs and the v4l2loopback kernel driver that I also read from in video conferences instead of the real webcam. This way I can also control exactly what the webcam shows – zoom / crop included.
The whole mess looks like this visualised in helvum, a patchbay for PipeWire.
Most of this explains itself. The WEBRTC VoiceEngine is the recording of Discord. Other devices may float around but are not used at the moment of this snapshot.
You probably heard about this before: An Arduino can be made into an excellent DIY joystick. Most examples use a Leonardo or Micro for this for a very good reason. They one comes basically with a chip that is recognized as HID (Human Interface Device) hardware on any modern operating system.
This is not the case with a Mega. This one has other perks but HID it is not. It sure shows up as USB device and a ttyUSB is raised where serial communications with the Arduino can be initiated. I’m also aware that some flash the built in programmer of the Mega so it starts operating like the others (which obviously removed the built in programmer). I’m on Linux PC though so I thought it’s basically a job of tricking the system into recognizing it as joystick and call it a day and OMG was I wrong!
How it’s not done
My train of thoughts was like this: Linux still supports plenty of old serial joysticks so how complicated can it be to send some bits an existing driver recognizes. Old hardware like this is usually glued to the driver with the tool inputattach of the Linux Console Project. This does basically initialise a joystick on some serial connection and sends it off to a fitting kernel driver. This way even non-USB, or let’s better say non-HID hardware, is mapped to a kernel driver who in return will set-up the joystick subsystem and manage the communication with the stick via a serial connection.
Turns out I’m not the first one with that idea and apparently someone made it work by connecting old Playstation Controller and a Wii Classic Controller to an Ardunio and fake a Stinger device without the use of HID so Kudos to Jarno Lehtinen here and his Linux-Arduino-Serial-Joystick repo – you sure did sent me down a rabbit hole of horror and amazement. I couldn’t even get inputattach to wait for that magic string to be sent with anything else than 9600 baud and aligned stars! I also had to throw socat into this horrible mix because the Arduino would insist on rebooting on init so a timeout was guaranteed! In case you wonder how I did this:
socat -r left.raw -R right.raw pipe:/dev/ttyUSB0 PTY,link=/dev/ttyUSB1,rawer
# and xdd to show me the debug juice
tail -f left.raw | xxd -c4
# and on yet another terminal
inputattach --baud 9600 --stinger /dev/ttyUSB1
This also meant that I had to tear everything down for reprogramming the Arduino. Anyway, in the end I could finally get through that init phase where the stinger related code in inputattach is waiting for the magic key after sending “ E5E5” to finally load the Stinger kernel driver – communication for both ways confirmed!
At this point I had a pipe to prevent the timeout due to the resetting Arduino, the _only_ working baud rate 9600 I could figure out with the Mega, a loaded driver that was recognized as joystick and was sitting put and did… absolutely nothing. Null. Nada. Not a single bit made it to the driver and I could not figure out why. My guess is it needs a change in the baud rate to the original 1200 (?) of the Stinger but I have no idea if this is true. I could also not find any way how the stream is controlled and since the driver would fill up 2 bytes all the time and interpret them there is a fair chance that it would simply be one byte off all the time. Speculations tho, I simply didn’t grasp the stinger.c source so this is all just a theory. I do not want to admit how much time I sunk into this and I was pretty frustrated at this point. Reading some stupid serial? Not like this! Too many hoops!
So I threw it all in the bin 🚮
How it’s probably done
Say hi to /dev/uinput where you can basically raise virtual devices, like a joystick, without [much?] pain. I’m not the first one, of course, and funny enough the reason behind is very similar to mine. Read more on Virtual joystick on Linux by Gwilym Kuiper where this is all explained in great detail. The referred code at https://github.com/gwilymk/arduino-joystick sure did help me to get started and even without having touched Rust ever before I was able to quickly adjust this for my needs, doubling the possible buttons and get it up and running in just a few hours for my Linux PC. Cheers mate (also Jarno Lehtinen – you teached me a lot that day :D) 🕹️
So here it is: A Mega acting as joystick without HID over a serial connection driven by a userspace daemon (means no kernel driver required) written in Rust providing a virtual uinput device for a joystick on the “modern” event system. Heck it’s even recognized in Wine!
What a journey to begin with. Now I need a back-channel for my blinky lights so I get my Raspberry Pi back from simpit duty 🙃
Behind the scenes recording so you get the idea of the setup followed by some Star Citizen gameplay:
DIY headtracker and Simpit and Star Citizen gameplay (on Linux PC)
In use:
* A Linux PC * A DIY Headtracker * A DIY Joystick “Primary Buffer Panel“ * A X52 Pro HOTAS * 3 Cameras + Recording Software * An AMD RX5600XT in tears * …a Beko learning How To Fly in SC xD
Updated: This content is obsolete. Two years later I rebuilt the cardboard version with something more sturdy and raised a dedicated project website describing the builds: SimPit.dev