Clocks

Using gamescope headless to run steam on a non-logged in system.

Background to Remote Gaming

Remote gaming is something everyone with a beefy desktop wants to do.

The problem is, the current state of Remote Gaming for Linux & Windows is kinda cruddy.

You need to be, first, logged in, second, steam running, thirdly, this all occurring in a secure area so no one can just plop down on your desktop while you are away.

No more, No longer.

Personal Motive

As I approach my big move out of my parents home, I have to leave my chunky desktop behind until I am more settled in my new location.

But I am an addict to playing War Thunder, I admit, It is my relaxation game.

I already know how to run my IDEs remotely, and there is few issues for me in regards to using a remote development system.

But gaming is something I cannot do remotely.

Alternatives

Sunshine

As much as I adore the project, it is kinda janky in my opinion.

Also, it violates the requirement to not be logged-in in person.

Another cloud gaming service

They still exist?

Solution

gamescope headless!

Here is the script that will make it work for you.

headless-steam.sh

#!/bin/bash

# Below is an extensive explanation of the commands below.

# Launch the given program with dbus, since steam and other programs need it.

# The given program, is gamescope.

# Explanation for the arguments to gamescope
# --backend headless : Headless! This allows `gamescope` to work without a display
# -e : enables steam integration, Needed for steam to work well as expected.
# -o 1 : Sets the minimum FPS to 1 when unfocused. Though may be useless since gamescope is headless
# -r 60 : Sets the maximum FPS to 60, We are streaming, no need to waste power here.
# -f : Sets to "full screen", may be useless for headless.
# -W 1920 : Sets the output width to 1920 pixels, Required for the headless screen to work well.
# -H 1080 : Sets the output height to 1080 pixels, Required the same as for width.
# --prefer-vk-device /dev/dri/renderD129 : This is important for modern systems with multiple GPUs, simply tells vulkan clients to use the correct GPU.
## Use `ls -l /dev/dri/by-path/` and `lshw -c display` to figure out which path is which GPU. (lshw (bus number) should look like the `by-path` identifier).
# --force-grab-cursor : Since some games are funky with the cursor, though may not be needed when headless

# Explanation for the arguments to steam
# -gamepadui : Enables the "gamepad ui", since this will work far better then the clunky desktop UI for remote play. (Also something gamescope something something).
# "$@" : Passes any script arguments onto steam

dbus-launch \
	gamescope --backend headless -e -o 1 -r 60 -f -W 1920 -H 1080 --prefer-vk-device /dev/dri/renderD129 --force-grab-cursor -- \
	steam -gamepadui  "$@"

Usage

Setup

1. Install Steam Link on your devices
2. Run Steam normally on your desktop.
3. Pair your devices together.

Script time

1. Save the script above to a file (preferably with the same name) and give it execution permissions.
2. Log off the system.
3. SSH into your system.
4. Run the script.
5. See the console go “brr”.
6. Open Steam Link, and connect
7. Notice you now have a steam deck UI on your other device, and your system is not logged in!
8. Happy time!

Notes

• I do not know how this will work for flatpak steam. Sorry!
• You may be able to use this with systemd.
• I wonder if this can be used with systemd to have multiple games running at once on a system.
• I do not know how to perform sound isolation for steam from your desktop, so if you do log in with this script working, you will hear steam.
• I am not responsible for you pressing the steam “power off” button in client (not the steam link app), this will turn your PC off.
• I suggest figuring out how to setup wake-on-lan to turn your PC on remotely.
• Steam Remote Play requires port forwarding
• Use the screen command to allow steam to run in the background if you are using SSH, this way if your terminal disconnects, steam keeps running.

Edits

• Gamescope v3.15 introduced --backend as an argument, which means the old --headless argument no longer works. Please use --backend headless from now on.

Inspired by Apple OCR for photos.

Goals

• Users can “double click” to select text from an image.

Requirements

1. Perform OCR accurately and quickly
2. Provide Points & Bounding boxes
3. Enable users to “hold click” to select text

Guidelines

1. Not too many new dependencies
2. Should not impact build process
3. Careful with large dependencies
4. No Google Services

UX

User double taps an image to possibly select text. If a model is not present, the user is prompted to install a model. If a model is present, OCR is performed on the image. If OCR is successful, the view enters “ocr select mode”, darkening out the image. Text sequence near where the user double tapped is highlighted. User can drag their finger across the screen to select more text. User can than press either the close button to exit select mode, or press the check mark button to confirm their selection which than copies the text to their keyboard.

UI

Libraries

Proprietary

Google ML Kit

https://developers.google.com/ml-kit/vision/text-recognition/v2/android

Capable of getting points, boxes, and more for rendering.

https://developers.google.com/android/reference/com/google/mlkit/vision/text/Text.TextBlock

Pros

1. Google Services devices can just use MLKit
2. Minimal app size increase.

Cons

1. Google Services.

Open Source

Tesseract4Android

https://github.com/adaptech-cz/Tesseract4Android

Pros

1. Android
2. Not too large library size
3. Performant (sub 1 second in emulator on single thread)

Cons

1. Somewhat clunky codebase
2. Developers are not active, only maintaining
3. Have to download models separately

Aspire

https://asprise.com/royalty-free-library/java-ocr-source-code-examples-demos.html

tess4j

https://github.com/nguyenq/tess4j

Today I installed Fedora Silverblue on my friends Intel laptop.

Previously, it was running Windows 11 on 4GB of ram, which is totally unacceptable.

During the install, I rebooted into “Safe Graphics” because the installer blacked out when selecting options prior.

Afterwards, the installation finished without a hitch. Until we noticed the GNOME Shell lagging in animations. Checking Settings, we found that the Graphics was rendering via “Software Renderer”.

Running sudo rpm-ostree kargs we find that nomodeset is in the Kernel Arguments.

The Kernel documentation states that nomodeset:

Disable kernel modesetting. DRM drivers will not perform display-mode changes or accelerated rendering. Only the system framebuffer will be available for use if this was set-up by the firmware or boot loader.

This means that the GPU would not be used.

To solve this issue, I had my friend run: sudo rpm-ostree kargs --delete nomodeset Which removes the offending Kernel Argument.

After a reboot, the System was now using “Intel UHD” and was butter smooth!

I would have appreciated it if the Fedora Installer warned the user that the installed system would also inherit nomodeset.

Hope this helps you!

Look at you friend, you now have IPv6 in your location and have enabled it on your router! Yippie!

Note one small detail though. IPv6 by default is dynamic. Make sure that you disable DHCP-PD in your router settings!

Why do I know this now? Because my IPv6 changed and borked my Tor relay!

MariaDB stores data in /var/lib/mysql, not /var/lib/mysql/data.

So my container data was all lost.

Honestly no clue how I came to believing the wrong directory was the data directory.