A while ago, Valve added a built-in system for creating and sharing your game play footage in the Steam Client. This makes it easy to record game videos "on the fly" and easily share clips without having to learn OBS Studio and video editing software. Game recording works quite well and was even ported to the Steam for Linux Client.

There is one glitch, however. On Linux, with a AMD GPU, and sometimes with an Nvidia GPU, trying to export a video or video clip from the 'Original' tab results in the error:

"Failed to export, try again"

Not very helpful. This occurs when trying to export in H.265 format - the default format Steam uses to record the video. Turns out this was reported a while back:

https://github.com/ValveSoftware/steam-for-linux/issues/11850

Steam lis looking for libcuda.so.1, even when running on a non-Nvidia GPU. You can export with transcoding to H.264 in the 'Custom' tab just fine. This works fine (you may need to install ffmpeg and the relevant codecs for your linux distro).

I found a workaround in a small blog post:

https://y.tsutsumi.io/reading-steam-game-recordings

To copy the original H.265 stream, look in you Steam directory:

.local/share/Steam/userdata/{id}/gamerecordings/clips

You will see one or more directories of the format:

clip_{game id}_{date_time in UTC}

Locate your game and open the directory. The original vidoe is the in

video/fg_{game id}_{date_time in UTC}

where you with find the video stream *.m4s files as well as the important session.mpd' XML file. Ffmpeg can read mpd file natively, so simply

ffmpeg -i session.mpd -c copy out.mp4

Other container formats compatible with H.265 and AAC audio will work as well. You now have the full original video to copy, upload, modify etc.

Have Fun!

A few months ago I picked up a GoPro Hero 13 cheap as another gadget to play with just for fun. You can review the specification details here. It's a decent enough portable camera for outdoors in the bright lights. Indoors...well not so much. You can read reviews elsewhere; just be a bit skeptical when the reviewer gushes about this camera's capabilities. It has some odd limitations.

For one, webcam mode is limited to 1080p 30fps. Also, you can't save a 4K copy on the sd card while in webcam mode. Nuts.

But this is not a review of the GoPro Hero 13.

I was interested in getting the GoPro to talk to my Linux based computers (Slackware, of course), without having to go through any of GoPro's bespoke apps. The first step to to simply plug in the USB-C cable. Linus recognizes the camera as a MTP device. You can easily upload and download files stored on the sd card.

Each video is stored as 3 files: low resolution video (LRV), high resolution video (MP4), and a thumbnail image (THM). You can even update the firmware manually by uploading it directly to the sd card if you don't like to update OTA via the phone Quik app.

By the way, the official Quik app is now the only official way to access and use the camera. All Windows or MacOS programs are deprecated. Gopro decided that editing and streaming is only for mobile devices. Sure you can operate the camera from the app, stream to Twitch, etc, but you got to do so on your phone, and you better have a fast and solid WIFI connection.

Nuts...but this is not a review.

Fortunately, GoPro has released the entire API to access the camera features programmatically. Unfortunately, access is via a web API. You can find the full API specification as well as tutorials and software examples on the Open GoPro Github repository. There are numerous examples and how-tos on the internet, especially written in Python, but, as I will show you below, some are needlessly complicated, or haven't been updated for the Hero 13 and newer firmware.

For the sake of this "proof of concept" discussion, I'll skip access via BLE and WIFI and concentrate on the USB connection. It turns out that the USB-C port does support standard ethernet TCP/IP networking. Once you plug the USB-C cable in and turn on the camera, a new wired network device will appear. With Network Manager this is automatic; if you are running Slackware without Network Manager, then simply restart the network:

In this example, we have a new device (eth1) and IP address. The camera runs its own DHCP server so that your computer is now 172.2X.1YZ.54 and the camera IP is fixed at 172.2X.1YZ.51. Each camera has a unique IP address. The values XYZ are the last three digits of the camera's serial number. In my case, I will send and receive data from address

http://172.25.148.54:8080

Nice. Now it gets complicated.

Now that we have access, we can start controlling the camera. Following the examples, we can send and receive camera information via an HTTP or curl GET request. For example, to get the camera information via the CLI with curl:

All the camera settings and function can be accessed in this way, including some settings not exposed to the camera settings UI.

So how do we extract a video stream over USB ethernet to use the camera as a webcam? This can get a bit tricky, if you want to use the GoPro camera in most webcam apps, since the software will be expecting the video over V4L2 and /dev/video0 (for example, a standard USB webcam). At this point, the camera behaves like a standard IP camera. To get the video routed to regular webcam apps, you will need to set up a V4L2 loopback device to simulate a USB webcam.

I'll leave that as an exercise for the reader. We will use the IP video stream directly.

Via the web API, we can send the GoPro camera video directly to applications such as OBS Studio, VLC, etc, or process the video directly with ffmpeg.

NOTE: You may need to install a few extra video codecs if these are not automatically included in your Linux distro. For example, you will need at least the codecs for H.264 and aac since this is the video format that the camera transmits.

In my case, I've added aac, x264, x265 and recompiled ffmpeg, VLC, and OBS.

Remember that I mentioned a few "odd limitations"? Streaming video over USB, and setting webcam mode limits the video to 1920x1080 30 fps and h.264 and all the most settings are unavailable. Why? Go ask GoPro.

Enough preamble. It's time to whip the llama's ass!

Once you now the HTTP get commands to use, the next step is find the stream URL. There are 2 ways. You can start a preview stream. This is the same stream as the preview on the Quik app. This stream comes to use as UDP on port 8554 (default). We'll use ffplay, from ffmpeg, to test.

The webcam mode can also stream via RTSP, and this can be handy if you want to grab the stream with several programs. Here is a basic work flow to start webcam mode, start the stream, view, and exit webcam mode. Resolution is set to 1920x1080, Linear aspect ratio, protocol RTSP and port 554:

Here is a simple bash script that puts all these concepts together.

To use OBS, we first start webcam mode. We'll use RTSP for this example, but UDP works as well. If you are going to stream to Twitch, webcam mode is already H.264.

We'll now need to set up OBS to to look at "rtsp://172.25.148.51:554/live". Add the Gopro Media Source to your scene and set the parameters:

If for some reason, the Media Source option is cranky, and you have VLC installed, you can instead create a new VLC Media Source:

Complete the OBS configuration as you require for your streaming pleasure. Webcam mode, if I am not mistaken, has a bitrate of ~2500-3000 Kbps, so keep this in mind when setting up your encoding parameters. If you set OBS to record the stream, be careful with the settings and the capabilities of your computer. Running both streaming and recording processes can overwhelm older CPUs and GPUs.

Although the HTTP API to control the GoPro camera seems a bit convoluted and overly complex to me, it does work well enough to operate the camera as a webcam. I guess this old timer is just not hip to all this web API nonsense. I just wish they would allow

• Higher resolutions, fps, and bitrates in webcam mode.
• Allow access to all the fancy image settings in webcam mode.
• Easier, direct access to WIFI without having to use BLE to enable it.
• Have both the USB and WIFI not use fixed IP addresses via the built-in DHCP server and use just a DHCP client. The camera should connect to your network as just another network device or computer.

Have fun!

Proton provides and officially recommends graphical desktop utility to access their VPN services. Unfortunately, these are supported on just a few "official" Linux distributions. Proton deprecated their bash command line (CLI) version. There is a community CLI version available, written in python, but both of these will be defunct after Proton upgrades their openvpn infrastructure on 31 March 2025.

Therefore, instead of trying get there official client to work (why no offline installer, or simple tar.gz etc archive?), we created our own simple, manual bash script targeting the freely available VPN servers. Thanks goes to a fellowPortland Linux User Group member for script improvements, suggestions and testing.

Proton provides instructions to manually configure both openvpn and wireguard for VPN access. This article will focus on openvpn.

Prerequisits

For this example, since for my Linux configuration, I will need to log in as 'root' user, I created directories under /root for the required files.

Log into your Proton account and download the .ovpn configurations. Also copy the openvpn user name and password you will require into a file, one per line, to 'protonvpn_auth.txt'.

Next, download the 'update-resolv-conf' script, copy to /etc/openvpn and set it to executable. This script will update your /etc/resolv.conf for the vpn tunnel.

If not already done, make sure that the lines

are placed in the .ovpn files so that this resolv script will be executed. Your /root folder should now contain the following tree, for example:

I've placed a copy of the script in the files section. It's functional but still a bit of a work in progress.

protonvpn.sh

Simply open a command shell and login in as root. Then provide the script with the .ovpn country:

Comments and suggestions are welcome: kingbeowulf@linuxgalaxy.org

A year ago, I refurbished a vintage 2007 iMac: 1TB SSD and new(-ish) power supply and it has been working pretty good for the most part.

Installing Slackware64-15.0 on an iMac 2007

Two issue still remain: Bluetooth (BT) and a tendency for the power supply over heat. I still haven't found a solution yet to the BT driver; this will wait for the next Slackware stable release "when it's ready; real soon now."

The mid 2007 iMac did have a tendency to overheat. Having poked around inside, there just isn't enough air flow to cool the power supply which can run extra hot under load. We can adjust the fan speed manually as root, once you figure out which fan cools both the CPU and the power supply. For example:

I was about to cobble something together when I stumbled across a great little daemon to do it all for me. So, why reinvent the wheel?

mbpfan: Adjust fan speed using the applesmc module

mbpfan is a great, simple program to tweak the fan curves when running Linux an a macbook or an iMac.

https://github.com/linux-on-mac/mbpfan

For Slackware (there are other distros?), you can build a nice installable package,

http://slackbuilds.org/repository/15.0/system/mbpfan/?search=mbpfan

For example, to run mbpfan at system boot, add it to /etc/rc.d/rc.local

Then edit /etc/mbpfan.conf as needed:

You may need to experiment a bit for your particular Mac.

Have fun!

Yesterday was the 30th Anniversary Meeting of Portland Linux/Unix Group - one of the oldest LUGs still in progress. Not only did we have cake,

We also had a special guest speaker: Linus Torvalds.

We had a lively discussion of the history and future, and development process, of the Linux kernel, as well as a few random topics.

A while ago, I had started beating on the ROCm build system to try to get a "simple" set of packages for those of us that only need basic OpenCL runtime support on Slackware64. AMD's ROCm includes that but also includes various tools to build HIP and OpenCL GPU compute programs. My prior efforts were the legacy OpenCL binary Ubuntu packages which wasn't very stable due to being compiled on Ubuntu. I had to take a pause due to a few health issues and only recently started looking into this again.

Recently, a post on the Slackbuilds.org mailing list completed what I could not: a set of slackbuild scripts for ROCm-5.5.1

https://github.com/414n/slackbuilds.org/blob/rocm-5.5.1

A big thanks to 414n to sift through and sort all the various ROCm bits and pieces. Much appreciated!

Now that I had a set of build scripts, and nice READMEs for which one does what and a workable build order, I dug up my notes to see which packages are needed to have OpenCL runtime support. AMD sure did not make this easy on package maintainers!

To start, grab a few packages from Slackbuilds.org that are external dependencies:

For rocminfo: numactl

For rocblas (optional package):
python3-wheel
msgpack-c
python3-virtualenv

For rocsolver (optional package):
fmt

Optional (utility):
clinfo
(or use the one provided with ROCm)

Before you build any of these packages, take note of the information and build order below. Rocblas and rocsolver are not required for the OpenCL runtime.

As I mentioned, I sifted through the packages to get a better idea of the build order for ROCm. What follows is the result.

B = build time dependency only
R = OpenCL runtime dependency
U = ROCm/OpenCL utility

The compile/build order in each Build stanza is optional.

Build 1st

rocm-llvm (B)
hsakmt-roct (R)
rocm-cmake (B)
python3-cppheaderparser (B) - included in 414n's git repository ROCm branch.

Build 2nd

rocm-device-libs (R)

Build 3rd

rocm-compiler-support (R)
hsa-roc (R)

build 4th

rocminfo (U)
rocm-smi-lib (U)
rocm-opencl-runtime (R)

The remaining packages are optional and are not required for basic OpenCL support. This includes the HIP runtime and various headers and libraries to build HIP and OpenCL programs.

Build 5th - Optional

rocm-clang-ocl [deprecated Dec 2023 for newer ROCm] (B)
hip-runtime-amd (B,R)

hsa-amd-aqlprofile-bin (optional, binary blob).
A code profiling/analysis binary blob library that is needed only for development and to suppress silly library missing errors.

Build 6th - Optional
in approximate build order

rocrand
rocblas
rocm-core
rocprim
hipcub
rocsparse
hipsparse
rocsolver
hipblas
composable-kernel
half - included in 414n's git repository ROCm branch.
miopengemm
miopen-hip
rocfft
hipfft
rocthrust
hipsolver
hipify-clang
rccl
roctracer

Once the the packages are built, which ones are necessary for just the OpenCL runtime? For basic ROCm OpenCL support:

numactl (for rocminfo)
hsa-rocr
hsakmt-roct
rocm-compiler-support
rocm-device-libs
rocm-opencl-runtime
rocm-smi-librocminfo

That's it!

The following utilities are provided in /opt/rocm/bin that provide

clinfo - OpenCL platform information
rocminfo - ROCm HSA agent information
rocm-smi - GPU status and control

The OpenCL ICD loader may have difficulty locating the correct OpenCL ICD and therefore the correct OpenCL library locations. If this happens (for example BOINC), either move or rename

etc/OpenCL/vendors/mesa.icd

So far, OpenCL works for BOINC and phoronix-test-suite with benchmarks hashcat and clpeak.

I ran across an article in Ars Technica [1] about nifty project DOS_Deck [2] - a cross platform implementation of old DOS in a web browser. DOS_Deck simplifies the process of getting an old DOS game running. No more fiddling; just click and play.

Personally, I've always enjoyed the hours tweaking my old MSDOS configurations, and later, DOSBox on Linux, to get my games running. Although, I do recognize that some may feel that is an exercise in frustration.

They plan to add more examples from the vintage era of gaming.

[1]

https://arstechnica.com/gaming/2023/11/dos_deck-offers-free-all-timer-dos-games-in-a-browser-with-controller-support/

[2]

https://dosdeck.com/

Now that Apple has moved on to their own "Apple silicon", all Intel CPU based Mac computers are on live support - and Apple ready to pull the plug. No more MacOS updates of any kind, even for recent models, as has already happened for the older Mac models. Recall that this is the same process as when Apple transitioned from PowerPC to Intel CPUs.

Granted, Apple does tend to support their hardware a bit longer than the Windows PC crowd, but it is still a shame to have to toss still perfectly good hardware. This post will describe how to breathe new life into a vintage 2007 iMac.

Apple long since pulled the plug on 2007 iMacs. After I replaced a dead power supply, I was perfectly happy with OS X El Capitan (10.11.6 2018) . This was the newest MacOS supported, but was also long past it's support date. Thus aluminum all-in-one is still a nice looking computing appliance, with a nice 24-inch 1920x1200 LCD screen. Full Specifications can be found here:

https://everymac.com/systems/apple/imac/specs/imac-core-2-duo-2.4-24-inch-aluminum-specs.html

This iMac already had been upgraded to 4GB DRAM, and after I replace the dead power supply, I swapped the old hard drive with a spare Samsung EVO 750 SSD.

A good place to start for instructions on how to crack open a Mac and for parts, check out ifixit. Recommended.

https://www.ifixit.com/

Both the standard Slackware installer DVD or USB drive will boot up. However, I recommend the Slackware Live Edition (currently version 1.70, "liveslak"). The install and setup is a bit easier.

https://download.liveslak.org/

Information and details about liveslak can be found here:

https://docs.slackware.com/slackware:liveslak

liveslak was developed by long time Slackware contributor Alien BOB. Recommended.

The liveslak I selected provides for KDE/Plasma and XFCE desktops. Editions with Cinnamon, Mate desktops, as well as a customized Digital Audio Workstation (DAW), are available. For the adventurous, the development branch, Slackware-Current, can be downloaded.

Please note: I am assuming you are familiar with the regular Slackware installation process. If you run into issues, I can provide some assistance. Post on Linuxquestions.org, email me, or see if I am active on IRC (#linuxgalaxy libera.chat)

Insert the live DVD or USB drive and power on the iMac. Hold the OPTION key (alt on non-Mac keyboards), until you here the boot chime. Eventually, a list of EFI boot devices will be available. You will see something similar to:

Select the EFI USB icon to boot the USB. The DVD version will be a DVD icon. Ignore the Windows icon if present - that is for hybrid media that can also boot via DOS/MBR.

After the boot process (and this may be a bit slow), log in with the "live" user with password "live". The root password is "root". To install, click the installation icon in the upper left corner and follow the instructions. if you logged in as "live", then provide sudo with the "live" password.

First, choose 'yes' to GPT partition your hard drive. I recommend something similar to the following (partition names are optional) with swap roughly twice the RAM:

Save the new partitions and continue with the installation. When you get to the lilo/elilo install section, skip both. Neither work with Macs. Will set up grub instead later.

Once done the installer will exit and you will still be in the liveslak environment. Do not reboot yet! Now we need to set up a grub as the boot loader. Open a terminal and "su -" change to root if needed. Verify your partitions:

Now wee need to chroot into the new Slackware installation. For details, refer to

https://docs.slackware.com/howtos:slackware_admin:how_to_chroot_from_media

Next, let's get this drive set up to but with grub. These instructions were adapted from

https://docs.slackware.com/howtos:slackware_admin:set_up_grub_as_boot_loader_on_uefi_based_hardware

If you receive a message similar to "UEFI variables not supported on this machine," you will need to exit the chroot and mount the EFI variables:

Then hop back into the chroot and re-run the grub-install command. Once grub-install completes successfully, continue with

Now, exit the chroot environment and reboot the iMac. Remember to remove the USB drive, etc.

Enjoy Slackware on your recycled iMac!

On the iMac 2007, everything worked out-of-the-box (so far!) except for wifi and bluetooth (BT). The wifi chipset is Broadcom BCM4321. The b43 kernel driver and needs the appropriate firmware which you can install via Slackbuilds.org

https://www.slackbuilds.org/repository/15.0/network/b43-firmware/

I haven't looked into what drivers are needed to get BT working yet. Stay tuned.

Older Macs may have a few issues booting due to corrupted SMC and PRAM.

1. iMac powers on, fans and DVD spin up, but screen stays blank/blank. Reset SMC: hold power button for 15 seconds. On some Macs, hold down the Shift+Control+Option keys and the Power button at the same time. If that does not work, unplug the power cable for 10-15 minutes.
2. iMac sound boot chime but screen stays gray. Try to reset SMC as above. If that does not work, reset PRAM: power off then on again. At the boot chime hold "Command+Option+P+R" keys until next boot chime (gray/chime - blank - gray/chime). If you get the flashing ? file folder icon after reboot or power cycle, boot into liveslak and repeat the grub-install/grub-mkconfig steps.

Given the size and weight of discreet GPU cards the past few years, GPU support brackets have become popular to prevent sag (tower cases with GPU mounted side-ways) and thus potential damage to the GPU and motherboard. Most current motherboards, say last 5 years os so, feature at least one reinforced PCI-express x16 slot for these heftier cards. GPU manufacturers also have balanced the card and trimmed the weight a bit as well. However, we often see recommendations to add a GPU support bracket to your new or existing build. Is this support required?

Generally, no. If you do see significant GPU sag, first check the end bracket connection and make sure the card is fully seated in the slot. Some larger cards can be a bit difficult to get snapped in correctly in a tight space.

Case in point: XFX Radeon RX 5700 XT THICC Ultra III

This is a massive card, heavy, and dwarfed my prior 900- and 1000-series Nvidia GPUs. It was a very tight fit in my large full tower Antec P100 case and seemed to wobble a bit. So I used a twist tie to provide a bit of lift.

No need to spend money on some silly piece of plastic or metal.

The new Sapphire Pulse Radeon RX 6800 XT Gaming OC is quite a bit lighter, but I strung it up just in case!

After a recent purchase a few months ago of a MSI Mech Radeon RX 6650 XT ($280 US, newegg.com, now $250), I noticed a peculiar behavior whenever the monitor powered down: The admgpu/drm crashed. The system had to be shutdown and power cycled to restore GPU function. Same issue on both motherboards:

Gigabyte X570 AORUS ELITE AMD Ryzen 9 3900X
Kernel 5.15.94 Mesa-22.2.5 libdrm-2.4.115
Gigabyte 27-in 2560x1440 170 Hz IPS

Gigabyte X570 I AORUS PRO WIFI AMD Ryzen 7 3800X
Kernel 5.15.94 Mesa-21.3.5 libdrm-2.4.109
Samsung 28-in 4K 60 Hz IPS

An example or the errors in /var/log/syslog:

At first I thought this was related to power management/dpm; however, turning all that off, and even resorting to appending "amdgpu.runpm=0 pcie_aspm=off" to the boot command, did not resolve the problem. The error occured when the monitors turn of or wake up via both Display port or HDMI, as well as a simple power off/on and hot-plugging the cable. The RX 6650 XT worked as expected on MS Windows 10 with the AMD Adrenalin Graphics Driver.

Searching the usually suspect provided some conflicting information and patches, supposedly resolved after kernel 5.14 or so.

And did I mention that although the GPU fan works, and could be controlled via /sys hwmon pwm, but that

/sys/class/drm/card0/device/hwmon/hwmon5/fan1_input

reads 0 (zero) no matter the fan speed (lm-sensors, gkrellm, corectrl)? This script can calculate an approximate fan rpm from the pwm1 value:

It is nice that the GPU prices are slowly getting back to a relatively normal baseline, so I last week picked up the Sapphire Pulse Radeon RX 6800 XT Gaming ($485 US, newgg.com) for the Ryzen 9 system. Weirdly enough, this GPU does not have the monitor hotplug issue and the GPU fan speed is displayed! At this point it looks like an issue with "Dimgrey Cavefish" (Navi 23, RX 6600/6650 XT) amdgpu or firmware, whereas "Sienna Cichlid" (Navi 21, RX 6800/6800XT) is better supported.

The next stable release of Slackware will no doubt resolve this Navi 23 display and fan issue.