Greetings terminal dwellers!
Scrcpy lets you display and control Android devices from your desktop over USB or TCP/IP. No root required, minimal latency, works over adb.
Debian ships it, but packages lag behind releases. I build from source and manage with Stow.
Getting the prebuilt server
Scrcpy has two parts: desktop client (what you build) and Android server (prebuilt APK). Download the server binary first:
wget https://github.com/Genymobile/scrcpy/releases/download/v2.2.1/scrcpy-server-v2.2.1
Building with Meson
Extract source, then configure with Meson. Key detail: --prefix=/ not --prefix=/usr/local. Stow handles the prefix via DESTDIR:
meson setup build --buildtype release --strip -Db_lto=true \
-Dprebuilt_server=scrcpy-server-v2.2.1 --prefix=/
Build flags: release mode, stripped binaries, LTO for smaller size. Point to downloaded server binary.
Compile:
ninja -C build
Installing to Stow directory
Install to version-specific Stow directory instead of system paths:
DESTDIR=/usr/local/stow/scrcpy-2.2.1 ninja -C build install
This creates /usr/local/stow/scrcpy-2.2.1/bin/scrcpy, /usr/local/stow/scrcpy-2.2.1/share/scrcpy/*, etc.
Activate with Stow:
cd /usr/local/stow
sudo stow scrcpy-2.2.1
Symlinks created in /usr/local/bin, /usr/local/share, pointing to Stow directory.
Uninstalling
Remove symlinks:
cd /usr/local/stow
sudo stow -D scrcpy-2.2.1
Delete directory when done:
sudo rm -rf /usr/local/stow/scrcpy-2.2.1
If server path isn't found
Sometimes scrcpy can't locate the server binary. Set the path manually:
export SCRCPY_SERVER_PATH=/usr/local/share/scrcpy/scrcpy-server
scrcpy
Or add to shell rc file for persistence.
Why bother
Distro packages work fine. But building from source means latest features and bug fixes. Stow keeps /usr/local clean—multiple versions coexist peacefully. Upgrades are symmetric: build new version, stow it, stow -D the old one.
Is it necessary? No. Is compiling software more satisfying than apt install? Absolutely. Even when it doesn't matter.
Welcome Interweb traveler.
In the last few weeks I decided to tackle the lack of options in Wayland/Weston1 to configure a keyboard's keys as "dual role".
Probably I should do a quick recap to explain why I need this kind of machinery. In the last few years I grew annoyed with standard staggered keyboards based on an ancient design that has no right to exist in this day and age.
What I can't stand is the horizontal stagger itself, as if they were still using mechanical levers from the steam age, but also the lack of easily reachable modifiers, as Ctrl and Alt keys in a default layout are probably in the most inconvenient place, at the side of the uselessly humongous space bar.
When in the past I've been stuck with a non replaceable keyboard I settled on using a little utility called Xcape to configure the space bar to act as a space when tapped and as a Ctrl modifier when pressed with another key, what's called a "dual role" or "tap and hold" key. Pressing two keys at the same time is called chording, like in music.
Well, I also added left paren to left Shift, right paren to right Shift, and Escape to Capslock, as in Emacs complex combinations like Meta-Ctrl-somethingelse could be simplified by tapping Escape and then doing a plain Ctrl chord instead of doing a more awkward three-key chord2.
Anywho, Xcape is a little cumbersome to configure and to use as there's a little delay that's used to discriminate between one of the two roles, also it's more evident when one types fast enough, but the biggest showstopper lies in its underlying operations as it taps directly into X11 and that's a big no-no under Wayland.
So doing a documentation survey on evdev to tackle the problem myself, I stumbled on a little and relatively unknown utility called evdoublebind that allegedly already did what I was looking for.
Well, it needs a proper reading of the documentation and because Gnome lacks support for customized XKB rules it also requires modifying the system XKB file directly — /usr/share/X11/xkb/rules/evdev. On Debian I suggest using dpkg-divert to preserve it in case of upgrade — but at least now I've learned how to build a keyboard description file using XKB.
After a few weeks of usage I could say I'm a happy camper, it's extremely reliable as I've never found the keyboard unable to type space characters after resuming the notebook from sleep — as it sometimes happened previously with Xcape — and I have to say that I haven't mistyped a single space, nor have I changed the way I type like when I was using Xcape.
In conclusion, to the reader with my same requirements who followed along this far, I can give my two thumbs up to evdoublebind wholeheartedly.
Greetings Interweb neighbors,
Emacs 28 dropped, but I'm not building it. I'm building tomorrow's Emacs on someone else's power bill.
Native compilation via libgccjit made the stable cut, what was left out is pure GTK support for Wayland. Since I'm on Wayland, I'm tracking the dev branch where it lives, which means frequent rebuilds of bleeding-edge snapshots. PGTK gives native Wayland support without the XWayland compatibility layer overhead.
GitHub offers 2000 minutes monthly of free CI/CD compute. Time to automate Debian package builds for Bullseye.
The beauty of delegation
My desktop is faster to build it, but where's the satisfaction in that? Instead, GitHub Actions spins up a fresh container, installs dependencies, compiles libgccjit support, builds native .eln files, packages to .deb, uploads artifacts.
Build takes 45 minutes on their infrastructure, zero noise from my machine. Ephemeral compute: servers spin up, do work, vanish.
The setup
Dockerfile does the usual: builds on Bullseye, installs a mountain of dev dependencies (libgccjit-10-dev, libgtk-3-dev, libwebkit2gtk-4.0-dev, etc.), copies in the Emacs source tree, then:
RUN cd emacs && ./configure \
--prefix "/usr" \
--with-native-compilation \
--with-pgtk \
--with-xwidgets \
--with-json \
--with-modules \
CFLAGS="-O2 -pipe -fomit-frame-pointer" && \
make NATIVE_FULL_AOT=1 -j $(nproc)
GitHub Actions workflow:
name: Build package
on:
workflow_dispatch:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Build package
run: ./build.sh
- name: Store package
uses: actions/upload-artifact@v3
with:
name: emacs-pgtk
path: ./packages/emacs-pgtk_*.deb
For the curious reader, all the gory details at github.com/ndrvtl/emacs-pgtk.
After build, manually construct .deb package structure: create DEBIAN/control, strip binaries, pack with dpkg-deb. More control, more tedium.
Smoketest runs apt-get install on built package, verifies emacs --version works. If it fails, workflow goes red. GitHub's problem to tell me.
The real win
Automated builds mean latest dev snapshots always packaged, ready to install. Push to branch, wait 45 minutes, download .deb. No local toolchain noise. No fan spin. No interrupted workflow.
Native compilation is sensibly fast. Pure GTK support works well. But the satisfaction isn't the software — it's having someone else's infrastructure do the work while I drink tea.
Long live free compute, never mind the warming planet. They get metrics, I get watts. Everyone loses.