This file is intended primarily as context for an AI/LLM helping a user reproduce Anbernic Companion on different hardware. To see a document that's intendend for humans to be read jump to this file To see how I personally did it with AYN Thor and Anbernic RG353v, look at this file It is not a standalone installation guide.
The goal is to help the model understand which parts of the reference implementation are essential, which parts are device-specific, and what must be discovered before adapting the setup.
Anbernic Companion turns a Linux-based gaming handheld into a wireless second screen and physical controller for an Android host device.
The essential architecture is:
ANDROID HOST
│
│ ADB over network
▼
SCRCPY
│
├── video → Linux handheld display
│
└── controls → Android as virtual gamepad
The Android device:
- runs the actual game or application;
- runs the scrcpy server automatically deployed through ADB;
- receives the Linux handheld's controls as a virtual gamepad.
The Linux handheld:
- runs the ADB client;
- runs the native scrcpy client;
- displays the Android video stream;
- provides its built-in physical controls;
- optionally automates the entire session with a launcher script.
This ADB + scrcpy architecture is the core of the project.
It should not be replaced with Moonlight, VNC, Steam Remote Play, WebRTC, or another streaming system when helping someone reproduce Anbernic Companion.
Those would be different projects.
An Android device capable of:
- enabling ADB debugging;
- accepting an authorized ADB connection;
- running a sufficiently recent Android version for the desired scrcpy version;
- connecting to the Linux handheld over some usable network.
Examples:
- Android gaming handheld;
- Android phone;
- Android tablet.
Root is not normally required.
A Linux-based handheld capable of running:
adb
scrcpy
It should also provide:
- a usable Linux graphics backend;
- access to its physical controller input;
- network connectivity;
- enough hardware video-decoding performance for scrcpy.
Examples may include Anbernic, PowKiddy, Retroid or other handhelds running a suitable Linux distribution.
Do not assume that a handheld is compatible merely because it has physical controls.
Compatibility depends on its operating system and available Linux software stack.
Android-only firmware is outside the intended scope of this setup.
The general session always looks approximately like this:
1. Android and Linux handheld establish network connectivity.
2. Linux handheld reaches Android's adbd.
3. Linux handheld runs scrcpy against that ADB device.
4. scrcpy:
- receives Android video;
- displays it fullscreen;
- forwards handheld controls as a virtual gamepad.
5. A launcher script optionally hides the normal handheld UI.
6. An exit action terminates scrcpy.
7. The handheld's normal frontend is restored.
The following must NOT be assumed from the reference implementation:
Linux distribution
package manager
scrcpy package availability
ADB package availability
display backend
SDL configuration
GPU renderer
screen resolution
screen aspect ratio
controller device name
controller event codes
frontend name
frontend service name
SSH username
filesystem paths
network interface
hotspot topology
IP addresses
startup and shutdown mechanism
These should be detected or adapted for each device.
The original tested setup is:
ANDROID HOST:
AYN Thor
LINUX COMPANION:
Anbernic RG353V
COMPANION OS:
dArkOS
NETWORK:
AYN Thor creates Wi-Fi hotspot
RG353V joins hotspot
ADB:
TCP port 5555
DISPLAY:
scrcpy
SDL KMSDRM backend
OpenGL ES renderer
INPUT:
scrcpy UHID gamepad forwarding
FRONTEND:
EmulationStation
EXIT:
Start + Select
REMOTE LAUNCH:
Termux on Thor
→ SSH into RG353V
→ launch companion script
This is a reference implementation, not a list of universal requirements.
The original working configuration is conceptually:
scrcpy \
--serial ANDROID_IP:ADB_PORT \
--fullscreen \
--max-size=640 \
--max-fps=60 \
--video-codec=h264 \
--video-bit-rate=2M \
--no-audio \
--mouse=disabled \
--keyboard=disabled \
--gamepad=uhidAdditional environment variables or renderer arguments may be required by the Linux handheld.
For example, the RG353V/dArkOS reference implementation required a KMSDRM-compatible SDL setup.
Do not copy graphics-related arguments blindly to another handheld.
scrcpy communicates with the Android host through ADB.
The physical network transport may vary.
Possible configurations include:
both devices on normal Wi-Fi
Android hotspot
↓
Linux handheld joins hotspot
Linux handheld hotspot
↓
Android joins hotspot
USB networking
The requirement is simply:
Linux handheld
↓
can establish an ADB connection
↓
Android host
The original setup uses:
adb tcpip 5555
This gives the Linux handheld a predictable ADB endpoint.
Example:
192.168.x.x:5555
On the tested unrooted Android host, Termux cannot directly reconfigure adbd.
The reference bootstrap is:
Android connected to ordinary Wi-Fi
↓
Wireless Debugging enabled
↓
Termux ADB connects to Android's Wireless Debugging TLS port
↓
adb tcpip 5555
↓
Android can leave ordinary Wi-Fi
↓
Android hotspot enabled
↓
Linux handheld connects to Android:5555
Important distinction:
PAIRING PORT
≠
WIRELESS DEBUGGING TLS PORT
≠
FIXED ADB TCP PORT
Do not confuse these when troubleshooting.
The exact ADB bootstrap may differ on another Android device.
The intended behavior is:
Linux handheld physical controls
↓
scrcpy
↓
UHID virtual gamepad
↓
Android
↓
game sees an additional controller
The Linux handheld's controls should remain available to scrcpy while the session is active.
The method used to locate those controls is device-specific.
The RG353V reference device exposes a controller named approximately:
retrogame_joypad
Do not assume that name on another handheld.
Useful discovery methods may include inspecting:
/dev/input/event*
/sys/class/input/
evtest
The companion's native resolution matters.
Reference RG353V:
640×480
4:3
The Android host may use a very different aspect ratio.
scrcpy normally preserves the source aspect ratio.
Therefore a widescreen Android display may appear letterboxed on a 4:3 handheld.
Possible options include:
keep original Android aspect ratio
change Android's logical display resolution
use a different Android display
crop the stream
Do not stretch the image unless the user explicitly wants that.
Automation is optional but strongly recommended.
The reference design uses two scripts.
Runs on Linux and approximately:
start
↓
detach from launcher/frontend
↓
find Android host
↓
ADB connect
↓
find physical controller
↓
stop EmulationStation
↓
launch scrcpy
↓
watch exit button combination
↓
terminate scrcpy
↓
restore EmulationStation
Runs on Android/Termux and approximately:
user taps shortcut
↓
discover Linux handheld
↓
SSH into handheld
↓
launch companion-side script
SSH is used only for convenience and automation.
SSH is not required by the core ADB + scrcpy architecture.
Before writing a final script, determine:
DEVICE_MODEL=
LINUX_DISTRIBUTION=
CPU_ARCHITECTURE=
SCREEN_RESOLUTION=
ADB_AVAILABLE=
SCRCPY_AVAILABLE=
SCRCPY_VERSION=
GRAPHICS_BACKEND=
CONTROLLER_DEVICE=
FRONTEND=
FRONTEND_STOP_COMMAND=
FRONTEND_START_COMMAND=
NETWORK_METHOD=
ANDROID_IP_DISCOVERY_METHOD=
EXIT_BUTTONS=
Prefer discovery commands over asking the user to guess.
From the Linux handheld:
adb connect ...
adb devices
Do not continue until Android appears as:
device
Run the simplest possible scrcpy command.
Confirm:
video appears
video is stable
fullscreen works
Do not add controller forwarding or automation yet.
Determine the appropriate:
SDL video backend
renderer
codec
resolution
bitrate
Prefer hardware-accelerated rendering.
Enable scrcpy gamepad forwarding.
Confirm that Android sees the handheld as a separate controller.
Test outside a game first when possible.
Run the setup for several minutes.
Check for:
disconnects
frame stalls
thermal problems
power problems
USB instability
Wi-Fi instability
Do not automate an unstable configuration.
Only after the manual setup works reliably:
stop frontend
launch scrcpy
implement exit shortcut
restore frontend
Optionally use:
SSH
Termux shortcut
desktop shortcut
other remote execution mechanism
to make startup a one-action process.
Always debug in this order:
1. NETWORK
Can the devices reach each other?
↓
2. ADB
Does `adb devices` show Android as `device`?
↓
3. SCRCPY VIDEO
Can scrcpy display Android?
↓
4. GRAPHICS / PERFORMANCE
Is rendering stable and accelerated?
↓
5. GAMEPAD
Does Android receive the controls correctly?
↓
6. AUTOMATION
Do launcher scripts start and restore everything correctly?
Do not debug all layers simultaneously.
When this file is provided as context:
- preserve ADB + scrcpy as the core architecture;
- adapt the setup to different Linux handhelds;
- identify device-specific assumptions;
- verify commands against the user's actual Linux distribution;
- use discovery commands where possible;
- test manually before creating automation;
- keep changes incremental;
- preserve a recovery method such as SSH;
- distinguish confirmed behavior from hypotheses.
- redesign the project around Moonlight, Steam Remote Play, VNC or another protocol unless the user explicitly asks for alternatives;
- assume dArkOS;
- assume RG353V;
- assume
retrogame_joypad; - assume KMSDRM;
- assume EmulationStation;
- assume the SSH user is
ark; - assume port
5555is already enabled; - assume a particular network topology;
- generate a large final script before verifying the individual components.
When adapting Anbernic Companion, preserve this:
ANDROID
│
ADB
│
scrcpy
│
▼
LINUX HANDHELD
screen + physical controls
Everything around that core may be adapted to the hardware.