Known Good

Vertical Japanese (tategaki) OCR benchmark: dots.ocr-1.5 vs LightOnOCR-3 vs chandra-ocr-2

2026-10-09T00:00:00Z

Symptoms #

The question was which local OCR model to use for vertical Japanese (縦書き, tategaki): novels, newspapers, old books. Two things made it hard to answer:

Easy benchmarks are saturated. On clean English, tables and horizontal Japanese, every recent OCR VLM scores 0.0–0.6% character error rate (CER). A single vertical paragraph separated them by only 1–3 characters, which is noise.
The failures that matter are not visible in averages of short pages. On longer vertical pages some models loop (repeat a phrase until the token limit), transcribe bleed-through from the back of the page, or silently change the spelling system (っ → つ, 來 → 来). These only show up with enough text and enough page types.

So a dedicated vertical-Japanese test set was built, with exact ground truth, and five models were run on it.

Results (CER = edits ÷ ground-truth characters; lower is better):

Model	CER	Median page	Pages > 10% CER	Time, 33 pages
dots.ocr-1.5 (3B)	1.27%	0.96%	0	271 s
LightOnOCR-3-4B	2.59%	1.52%	0	222 s
LightOnOCR-3-0.8B	4.15%	3.48%	1	154 s
LightOnOCR-3-1B	9.00%	4.41%	7	194 s
chandra-ocr-2	10.96% (90.6% uncapped)	1.74%	3	629 s

Each page's edits are capped at its own length, so one runaway loop costs at most one page of error. Without the cap, chandra's single 18,500-character loop dominates everything (90.6%).

By page type (same metric):

Category	Pages	LO3-4B	LO3-0.8B	LO3-1B	chandra	dots
clean block, 6 fonts	6	1.51	3.02	8.63	1.51	0.88
paperback page	5	1.16	2.39	7.36	1.76	0.92
furigana (ruby)	4	3.40	3.78	30.46	9.24	1.29
old orthography 旧字旧仮名	4	3.68	6.27	6.75	0.70	1.71
numbers / Latin	3	2.85	0.57	33.67	3.71	0.14
2–3 tier newspaper 段組	4	2.99	4.72	2.93	22.08	1.49
brush / pen fonts	2	1.47	2.94	3.67	0.92	1.28
simulated scans	5	2.28	4.82	8.80	8.58	1.18

Root cause #

The differences come from model behaviour, not from reading order.

Reading order is fine for all of them. The score was also computed order-free (a multiset comparison of characters). The gap between ordered and order-free error is only 0.25–1.2 points for every model. All five read right-to-left columns and multi-tier newspaper pages in the right sequence.

chandra-ocr-2 normalizes modern text to pre-war spelling. It enlarges small kana in modern text: っ → つ, ゃ → や, ょ → よ (123 times across the set), and sometimes writes old kanji forms (気 → 氣). Example from a paperback page:

textground truth: 糊代りに使った飯粒の / 貼らさってあった / な筈がなかった
chandra:      糊代りに使つた飯粒の / 貼らさつてあつた / な筈がなかつた

The same bias makes it the best model on genuinely old-orthography pages (0.70%). It also produced three blowups: a repetition loop on a 2-tier page (…だっただっただった… for 18,546 characters, 233 s), mirrored bleed-through transcribed as text on a thin-paper scan, and furigana emitted inline as <sup>reading</sup>, sometimes attached to the wrong kanji.

LightOnOCR-3 does the opposite: it modernizes old orthography. On 旧字旧仮名 pages the 4B writes 來 → 来, 樂 → 楽, 雜 → 雑, あつた → あった, and even rewrites classical grammar (かへらば → かへれば). It also sometimes reformats prose into Markdown (a recipe's 、-separated ingredient list became - bullets, plus an invented 「作り方」 heading). The 0.8B drops dakuten (ござ → ごさ) and leaks simplified Chinese (済 → 济). The 1B is not usable for vertical text, even after the checkpoint repair described below.

dots.ocr-1.5 has the least spelling bias. Its errors are isolated misreadings (檸檬 → 檜櫟 in one font, ゐ → る on old text). It had no page above 2.7% CER.

Furigana: if transcribed readings are forgiven, the ruby category is dots 0.91%, LightOnOCR-3-4B 1.87%, chandra 2.54%. dots and the 4B mostly drop the ruby, as wanted; the 4B occasionally writes it inline as 扇（あお）.

Fix #

Use dots.ocr-1.5 for vertical Japanese. It was the most accurate in 6 of 8 categories and never failed badly. LightOnOCR-3-4B is the next choice: zero blowups and a bit faster, but expect modernized spelling on pre-war text. It also needs about 9 GB of VRAM in bf16, versus about 6 GB for dots. Avoid chandra-ocr-2 for tategaki, or at least guard it with a max-length check for loops.

If you run LightOnOCR-3 with Hugging Face transformers, three problems in the 2026-10-08 release need workarounds.

1. LightOnOCR-3-1B outputs garbage (pk pk pk pk …, 是很是很是很…) and the load log shows a LOAD REPORT with every language_model.model.layers.* key UNEXPECTED and every model.language_model.layers.* key MISSING. The checkpoint stores the language model weights under the wrong prefix, so they are dropped and the model runs with random weights. Older transformers versions behave the same. Rename the keys once:

pythonfrom safetensors.torch import load_file, save_file
sd = load_file("LightOnOCR-3-1B/model.safetensors")
sd = {("model.language_model." + k[len("language_model.model."):]
       if k.startswith("language_model.model.") else k): v for k, v in sd.items()}
save_file(sd, "LightOnOCR-3-1B-fixed/model.safetensors", metadata={"format": "pt"})
# copy the other files (config, tokenizer, processor) next to it; 310 keys are renamed

Load it with LightOnOcrForConditionalGeneration / LightOnOcrProcessor. Its config says model_type: mistral3, so AutoModelForImageTextToText picks the wrong class.

2. LightOnOCR-3-0.8B is about 10× slower than the 4B. Its config.json and generation_config.json ship with "use_cache": false, so every generated token recomputes the whole sequence. One page went from 208 s to 14.7 s with identical output:

pythonmodel.generate(**inputs, max_new_tokens=6144, do_sample=False, use_cache=True)

3. The 4B and 0.8B (Qwen3.5 architecture) fall back to slow PyTorch kernels:

text`causal_conv1d_fn` is falling back to its reference PyTorch implementation because `causal_conv1d` is not installed.
`chunk_gated_delta_rule` is falling back to its reference PyTorch implementation because `flash-linear-attention` is not installed.

Install both. flash-linear-attention is pure Triton. For causal-conv1d, use the prebuilt wheel matching your torch, so that it doesn't try to compile against a different system CUDA. Both worked on an RTX 5080 (sm_120):

bashpip install flash-linear-attention
pip install "https://github.com/Dao-AILab/causal-conv1d/releases/download/v1.7.0/causal_conv1d-1.7.0+cu12torch2.10cxx11abiTRUE-cp312-cp312-linux_x86_64.whl"

For plain transcription, call LightOnOCR-3 with the image only (empty prompt) and enable_thinking=False in apply_chat_template (4B/0.8B). Resize the longest edge to 2048 px.

How it was found #

Test set (33 pages, 20,937 ground-truth characters). Passages come from public-domain Aozora Bunko texts (Akutagawa, Dazai, Sōseki, Kenji, Edogawa Ranpo, Higuchi Ichiyō, Mori Ōgai, Okamoto Kidō, Terada Torahiko and others). Three pages were written by hand for numbers, acronyms and URLs. Pages were rendered writing-mode: vertical-rl by headless Chromium in 11 fonts: Noto Serif/Sans CJK, IPA Mincho, and Google Fonts' Shippori Mincho, Zen Old Mincho, BIZ UD Mincho and Gothic, Kaisei Tokumin, Zen Maru Gothic, Klee One and Yuji Syuku.

For each page the passage is binary-searched to the longest prefix that fits the page box with no overflow. Overflow is measured in the browser with --dump-dom and a script that compares scrollWidth/scrollHeight. The cut is then backed off to a clause boundary, so the ground truth is exactly the visible text.
Furigana come from Aozora's own ruby markup (｜漢字《かんじ》). Paragraphs with gaiji (※［＃…］), layout annotations or ／＼ repeat marks are skipped.
Multi-tier pages use CSS multi-column inside vertical-rl, which stacks the columns top-to-bottom like a newspaper.
Scans are rendered, then degraded with OpenCV: skew + noise + JPEG, 150 dpi binarized, phone-photo perspective with uneven light and a gutter shadow, mirrored bleed-through, and a worn photocopy.

Scoring. Model markup (HTML, Markdown, LaTeX, grounding tokens) is stripped. Then NFKC (which folds vertical presentation forms such as ︒ ﹁﹂ and full-width digits), dash variants are unified, and all whitespace is removed. Variant kanji (旧/舊) and historical kana (ゐ/ゑ) are not folded: writing 旧字 as 新字 counts as an error. The metrics are strict CER, CER without punctuation, order-free error, and a ruby-tolerant CER that forgives readings written in <rt>, <sup>, brackets or inline. Every model ran in plain full-page OCR mode with greedy decoding.

Caveats. These are rendered pages, not physical scans; the scan category only simulates degradation. Aozora texts are public and probably in every model's training data. The test set is 33 pages, so differences under about 0.5 points within one category are not meaningful.

References #

dots.ocr-1.5: https://huggingface.co/rednote-hilab/dots.ocr-1.5
LightOnOCR-3: https://huggingface.co/lightonai/LightOnOCR-3-4B (also -1B, -0.8B)
chandra-ocr-2: https://huggingface.co/datalab-to/chandra-ocr-2
Aozora Bunko: https://www.aozora.gr.jp/
causal-conv1d prebuilt wheels: https://github.com/Dao-AILab/causal-conv1d/releases

SP Flash Tool on Linux (MT6592): S_COM_PORT_OPEN_FAIL (1013) in BROM, then "PMT changed for the ROM"

2026-10-03T00:00:00Z

Symptoms #

Goal: replace one file (/system/media/bootanimation.zip) on an unrooted MediaTek MT6592 Android 5.1 device by writing a modified system image over USB from Linux. Every tool failed in a different way.

mtkclient reads the eMMC fine, but every write hangs forever right after the command header:

DaHandler - Writing offset 0x5000000 with length 0x100000
DeviceClass - [LIB]: TX:62
...
DeviceClass - [LIB]: TX:00100000

In BROM mode with --preloader, it got stuck one step earlier instead:

DALegacy - M_EXT_RAM_SIZE : 0xc000000
DALegacy - Uploading stage 2...
DALegacy - Waiting for response ...

SP Flash Tool (Linux, console mode flash_tool -i config.xml):

v5.2228: its MTK_AllInOne_DA.bin has no MT6592 entry.
v5.1916: Failed to Connect DA: S_FT_DA_NO_RESPONSE(4001) right after 100% of DA has been sent, in both BROM and Preloader mode.
BROM mode (0e8d:0003, vol-up held), even when run as root:

USB port detected: /dev/ttyACM0
Connect BROM failed: S_COM_PORT_OPEN_FAIL(1013)
[COM] Failed to open COM port.

Preloader mode (0e8d:2000) with v5.1648, "Download Only" of just the system partition:

DA Connected
Uncaught BaseException in main(): PMT changed for the ROM; it must be downloaded.
Please select "Format All + Download" scene and try again

Do not follow that hint. "Format All + Download" erases the whole device, userdata and NVRAM included.

Root cause #

Four independent problems:

S_COM_PORT_OPEN_FAIL is not a permissions problem. strace shows the open() of /dev/ttyACM0 succeeds. SP Flash Tool then calls ioctl(fd, TIOCCBRK), which returns -1 EOPNOTSUPP, and the tool gives up. Recent kernels' cdc_acm refuses break requests when the device does not advertise break support in its CDC descriptors. The MediaTek BROM does not advertise it, while the Preloader does. That is why only BROM mode fails. Older kernels silently accepted the request, and this 2016–2019 tool assumes that.
```
openat(AT_FDCWD, "/dev/ttyACM0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 10
ioctl(10, TCSETS2, {c_cflag=B115200|CS8|CREAD, ...}) = 0
ioctl(10, TIOCCBRK) = -1 EOPNOTSUPP (Operation not supported)
close(10)
```
The DA version matters. The download agent (DA) in SP Flash Tool v5.1916 (MTK_AllInOne_DA_v3.3001.2019-04-24) never answers on this board. The one in v5.1648 (v3.3001.00.00) works. It is byte-identical to the MTK_AllInOne_DA_mt6590.bin that mtkclient ships, which is why mtkclient could always connect and read.
mtkclient can read but not write here. With the legacy DA it sends SDMMC_WRITE_DATA (0x62) and waits for an ACK that never comes, and it has no timeout. Separately, in BROM mode it sends the first DRAM (EMI) entry from the preloader rather than the one matching the eMMC ID. This preloader holds four entries; the matching one was number 3 (LPDDR3, 1 GB). The first one is LPDDR2, so stage 2 crashes (note the M_EXT_RAM_SIZE : 0xc000000). Reordering the entries in a host-side copy of the preloader fixes the DRAM setup, but the write still hangs.
"PMT changed" is SP Flash Tool's own arithmetic. Its detailed log (/tmp/SP_FT_Logs/.../QT_FLASH_TOOL.log) names the partition:
```
CheckPMTLayoutChange(): PMT changed for <USRDATA>: addr<0x7f800000>-->addr<0x7f800000>,
len<0x151300000>-->len<0x151b80000>
```
The tool auto-sizes the last partition (userdata) to fill the eMMC, but counts boot1 + boot2 + RPMB (4 + 4 + 0.5 MB = 0x880000) into the total. The device's real table, written at the factory, does not. The scatter file can't override this, because the tool recomputes the size.

Fix #

Use the raw write-memory command instead of "Download". It writes a file to an explicit physical eMMC address and skips the partition-table comparison. It is also unforgiving: you own the address, so take a full dump first and verify placement.

1. Dump everything and find the real layout. Use mtkclient (reads work). MT65xx devices keep a "PMT" table near the end of the user area, with magic 1vTP1.1, 96-byte entries (name[64], size u64, region u64 (1 = boot1, 8 = user), offset u64, mask u64), and a mirror 4 KB later. Here ANDROID (system) was at physical 0x5000000, size 0x60000000.

2. Shim the break ioctl so BROM mode works too (Preloader mode does not need it, but it does no harm):

c// brkshim.c — gcc -shared -fPIC -O2 -o brkshim.so brkshim.c -ldl
#define _GNU_SOURCE
#include <dlfcn.h>
#include <errno.h>
#include <stdarg.h>
#include <sys/ioctl.h>
#include <termios.h>

int ioctl(int fd, unsigned long req, ...) {
    static int (*real)(int, unsigned long, ...);
    if (!real) real = dlsym(RTLD_NEXT, "ioctl");
    va_list ap; va_start(ap, req); void *arg = va_arg(ap, void *); va_end(ap);
    int r = real(fd, req, arg);
    if (r < 0 && errno == EOPNOTSUPP && (req == TIOCSBRK || req == TIOCCBRK)) { errno = 0; return 0; }
    return r;
}

3. Run SP Flash Tool v5.1648 in console mode with the shim. It also needs libpng12.so.0, which ships in the lib/ of later SP Flash Tool zips:

shT=/path/to/SP_Flash_Tool_v5.1648_Linux
cd "$T"
sudo env LD_PRELOAD=/path/to/brkshim.so LD_LIBRARY_PATH="$T:$T/lib" \
     QT_QPA_PLATFORM=offscreen ./flash_tool -r -i /path/to/writemem.xml

Then plug the device in powered off, with no buttons held (Preloader mode, 0e8d:2000). In this mode the preloader has already initialised DRAM, so no EMI settings are needed.

4. The write-memory config. A scatter file is still required. Generate it from the PMT (all partitions, linear_start_addr = physical_start_addr) and add skip_pmt_operate: true to its general → info block so the tool never rewrites the table. If the scatter marks nothing is_download: true, the tool aborts during "auto load all roms" (DL_AutoLoad failed). So mark exactly one partition downloadable and give it a harmless, disabled rom (here: the original, unmodified system image):

xml<flashtool-config version="2.0">
  <general>
    <chip-name>MT6592</chip-name>
    <storage-type>EMMC</storage-type>
    <download-agent>/path/to/SP_Flash_Tool_v5.1648_Linux/MTK_AllInOne_DA.bin</download-agent>
    <scatter>/path/to/MT6592_writemem_scatter.txt</scatter>
    <rom-list>
      <rom index="17" enable="false" partition="ANDROID">/path/to/system_original.img</rom>
    </rom-list>
    <connection type="BromUSB" high-speed="false" power="AutoDetect" timeout-count="3600000" com-port="" />
  </general>
  <commands>
    <write-memory>
      <write-memory-item input-mode="FromFile" program-mode="PageOnly"
          addr-mode="PhysicalAddress" address="0x5000000" input-length="0x60000000"
          part-id="8">/path/to/system_new.img</write-memory-item>
    </write-memory>
  </commands>
</flashtool-config>

part-id="8" is the eMMC user area. Only one write-memory-item is allowed per config.

Result: 100% of data write to memory, (1610612736 /1610612736) in about 2.5 minutes (about 10 MB/s), and the device booted with the new boot animation.

Caveats

Prove placement first. Before the real write, I wrote 1 MiB of random bytes into the middle of the CACHE partition (disposable), read an 18 MB window back with mtkclient, and confirmed it landed at exactly the requested address with nothing else changed.
Always read back. The first full 1.5 GB attempt stalled after one 1 MiB packet (no CPU, no progress for 30+ minutes). It did not happen again on retries (2 MiB, 94 MiB, then 1.5 GB all completed), so I have no explanation for it. A read-back showed exactly one new 1 MiB chunk had been written.
The image must be valid for Android: e2fsck -fn clean, and the replaced files must keep their owner, mode and security.selinux xattr (u:object_r:system_file:s0). Check with debugfs -R 'ea_list /media/bootanimation.zip' system.img.
A hung DA leaves the device unresponsive. It keeps running on battery and ignores buttons, and the host logs device descriptor read/64, error -71. Hold power for 15–20 seconds to reset it.
BROM mode needs vol-up held at the moment the chip powers up. Unplug everything, hold vol-up, then connect the data cable. With external power attached it tends to land in Preloader mode instead.

How it was found #

strace -f -e trace=openat,ioctl,read,write on flash_tool showed the TIOCCBRK failure and, later, the per-packet protocol: Z, 1 MiB data, 2-byte checksum, then the device replies i.
The kernel log showed BROM enumerating cleanly (cdc_acm …: ttyACM0: USB ACM device), so the cable and port were fine.
Comparing sha256 sums of the MTK_AllInOne_DA.bin files showed mtkclient's working DA is the one from v5.1648. Parsing the DA header (0xDADA entries with hw code) showed which tool versions still list MT6592.
SP Flash Tool's detailed logs in /tmp/SP_FT_Logs/ give the exact reason behind generic errors such as "PMT changed".

References #

mtkclient: https://github.com/bkerler/mtkclient
SP Flash Tool Linux builds (older versions are still on the CDN): https://cdn.spflashtools.com/wp-content/uploads/SP_Flash_Tool_v5.1648_Linux.zip

Chromium window drag warps the window (xfwm4) or the cursor (KWin) on X11

2026-10-03T00:00:00Z

Symptoms #

On an X11 desktop, Chromium windows "get lost":

You start dragging a Chromium window by its tab strip or title area and the window jumps by several hundred pixels, often mostly off-screen (only a thin strip left visible, sometimes behind the panel).
Clicks land in the wrong place for a while, as if the window were somewhere other than where it is drawn.
It looks random: a given window does it once, then behaves until some later point.
After switching the window manager from xfwm4 to KWin, the window stops jumping, but now the mouse cursor jumps 10–350 px at the start of a drag.

Other applications that use the window manager's own title bar are not affected.

Root cause #

Chromium draws its own title bar (client-side decorations, the default). When you drag that title bar, Chromium does not move the window itself. It asks the window manager to start an interactive move by sending an EWMH _NET_WM_MOVERESIZE client message. That message contains x_root, y_root: the pointer position in root (screen) coordinates, as the client believes it to be.

Chromium sometimes sends wrong root coordinates. Our capture under KWin:

textSendEvent  sender=Chromium  type=_NET_WM_MOVERESIZE  data=(1413, 203, 8, 0, 0)
WarpPointer  sender=KWin  dst=(1413, 203)
pointer motion  (1606,52) -> (1413,203)   344 px in 1 ms

Direction 8 is _NET_WM_MOVERESIZE_MOVE. The real pointer was at (1606, 52). Chromium claimed (1413, 203), an error of (193, 151) px. The most likely explanation is that Chromium works out the root position from its cached window bounds plus the pointer's offset inside the window, and the cache is stale (for example after the window manager has moved or placed the window). That fits the "each window does it once" pattern: after the jump, the cache matches reality again.

The two window managers handle the bad coordinates differently:

Window manager	What it does with `x_root, y_root`	What you see
xfwm4 4.20	Uses them as the grab origin for the move: window x = start x + (pointer x − press x), with a wrong start	The window jumps by the error (we measured −316, −332 and −649 px)
KWin 6.7 (X11)	Warps the pointer to the given position before starting the move (`X11Window::NETMoveResize`: "move cursor to the provided position to prevent the window jumping there on first movement")	The cursor jumps by the error; the window stays put

So the bug is in the client's request, and each window manager shows it in its own way. KWin's behaviour is documented in its source. The xfwm4 part was measured from window geometry before and after each jump. Our early request tracer under xfwm4 did not log SendEvent, so the bad payload was only captured directly under KWin.

Fix #

Turn off Chromium's client-side title bar so that moves are started by the window manager from the real pointer event:

Chromium → Settings → Appearance → "Use system title bar and borders" → On

This is a per-profile setting, so turn it on in every profile you use. After the change, the window manager draws the title bar (xprop _NET_FRAME_EXTENTS on the window shows a non-zero top extent), no _NET_WM_MOVERESIZE is sent for ordinary drags, and the jumps stop. This was confirmed working on the affected machine.

The same reasoning applies to other client-side-decorated (GTK/libadwaita) apps that show the same symptom: anything that makes the window manager draw the title bar avoids the client-supplied coordinates.

Changing the window manager alone is not a fix. It only changes which thing jumps.

Recovering a window that is already off-screen #

bashxdotool search --name 'Chromium' | while read w; do
  xdotool getwindowname "$w"; xdotool getwindowgeometry "$w"
done
xdotool windowmove <window-id> 100 100

How it was found #

The jumps were rare, so it took permanent watchers, run as systemd user units on both X displays, until one was caught with numbers:

Window geometry watcher: logs every move of top-level windows and flags any window that ends up mostly off-screen.
Pointer watcher: logs button presses and motion during drags (no keys).
Request watcher: uses the XRecord extension to log every SendEvent ClientMessage any client sends, with the sender's resource-ID base, so you can see who asked for a move and with what coordinates.
A short-lived probe logging every XWarpPointer request and its sender, which is what showed KWin moving the cursor ~150 ms after button press (Chromium's drag threshold).

The request watcher is the useful one. It is short and needs only python-xlib:

python#!/usr/bin/env python3
"""Log SendEvent ClientMessages (e.g. _NET_WM_MOVERESIZE) via XRecord.
Usage: xreqlog.py DISPLAY OUTFILE"""
import struct, sys
from datetime import datetime
from Xlib import display
from Xlib.ext import record

SEND_EVENT, CLIENT_MESSAGE = 25, 33

def main():
    d, d2 = display.Display(sys.argv[1]), display.Display(sys.argv[1])
    f = open(sys.argv[2], "a", buffering=1)
    names = {}
    def aname(a):
        if a not in names:
            try: names[a] = d2.get_atom_name(a)
            except Exception: names[a] = hex(a)
        return names[a]

    def callback(reply):
        if reply.category != record.FromClient or reply.client_swapped:
            return
        data = reply.data
        while len(data) >= 4:
            n = int.from_bytes(data[2:4], "little") * 4
            if n < 4 or n > len(data):
                break
            req, data = data[:n], data[n:]
            if req[0] != SEND_EVENT or len(req) < 44:
                continue
            ev = req[12:]
            if ev[0] != CLIENT_MESSAGE:
                continue
            win = int.from_bytes(ev[4:8], "little")
            msg = int.from_bytes(ev[8:12], "little")
            vals = struct.unpack("<5i", ev[12:32]) if ev[1] == 32 else tuple(ev[12:17])
            t = datetime.now().isoformat(timespec="milliseconds")
            f.write(f"{t} id_base={hex(reply.id_base)} win={hex(win)} "
                    f"type={aname(msg)} data={vals}\n")

    ctx = d.record_create_context(0, [record.AllClients], [{
        "core_requests": (0, 127), "core_replies": (0, 0),
        "ext_requests": (0, 0, 0, 0), "ext_replies": (0, 0, 0, 0),
        "delivered_events": (0, 0), "device_events": (0, 0), "errors": (0, 0),
        "client_started": False, "client_died": False}])
    try:
        d.record_enable_context(ctx, callback)
    finally:
        d.record_free_context(ctx)

main()

Compare the data=(x, y, 8, …) of a _NET_WM_MOVERESIZE line with where the pointer actually was at that moment (xdotool getmouselocation, or a pointer logger). If they differ, you have this bug.

Things that were checked and ruled out along the way: X Shape input regions (none on the Chromium windows), compositor drawing offsets (screenshots matched the X window tree), and Chromium's saved window state (it never contained the off-screen positions).

References #

EWMH spec, _NET_WM_MOVERESIZE.
KDE bug 449105, "Dragging a window that was opened maximized moves the mouse cursor to the top left corner of the window" (Wayland; fixed in Plasma 6.1). A related cursor-jump issue, different trigger.
KWin merge requests 5399 ("Make Window::interactiveMoveOffset() proportional") and 5421 ("x11: Fix interactive move offset").
Unrelated noise you may see at the same time with xfwm4 4.20 + picom: a flood of GLib-CRITICAL: g_hash_table_lookup in ~/.xsession-errors (xfwm4 issue #855, cosmetic).

No audio in Chrome Remote Desktop session on PipeWire: "ALSA: Couldn't open audio device: Host is down"

2026-09-11T00:00:00Z

Symptoms #

Connected to a Linux desktop with Chrome Remote Desktop (CRD), no sound reached the CRD client. In a terminal inside the CRD session:

text$ mpg123 beep.mp3
Couldn't open SDL audio: ALSA: Couldn't open audio device: Host is down

A GUI media player (Parole) "played" an MP3 in silence, and no sink-input for it ever appeared in pactl list sink-inputs.
Command-line PipeWire tools (pw-cli, pw-dump) run in the session quietly talked to the wrong PipeWire instance.
After a first attempt at a fix, some apps started over D-Bus failed in libpulse with:

textFailed to create secure directory ()

Root cause #

Three separate problems were stacked. Each one alone is enough to leave the CRD client silent.

1. CRD's audio variables leak into the whole session #

CRD starts the remote session with three variables that point at a PipeWire instance of its own, which is supposed to write audio into a FIFO that the CRD host reads:

Variable	Value set by CRD
`PULSE_RUNTIME_PATH`	`/tmp/pyxdg-runtime-dir-fallback-<user>/crd_audio#<id>`
`PULSE_SINK`	`chrome_remote_desktop_session`
`PIPEWIRE_REMOTE`	`crd_audio#<id>/pipewire`

On this machine CRD's own PipeWire never came up: it failed, CRD retried it five times, then started the host without it. (Our reading of why: the CRD session had no XDG_RUNTIME_DIR and no systemd user bus, so that PipeWire found no runtime directory.) The variables were still set, and everything started from the session script inherits them: the desktop session, panel, file manager, terminals, shells, and the dbus-launch session bus.

ALSA clients going through the PipeWire ALSA plugin (mpg123's default output, GStreamer apps) follow PIPEWIRE_REMOTE to the dead instance and fail with Host is down. Setting PULSE_SERVER in .bashrc does not help them: it only affects libpulse clients, and only in interactive shells.

2. Empty values pushed into the D-Bus activation environment #

dbus-launch copies its own environment into the activation environment of the session bus, so D-Bus-activated services (for example xdg-desktop-portal*) got the bad variables too. dbus-update-activation-environment can set variables but cannot unset them, and the first attempt "cleared" them by setting them to empty strings. An empty PULSE_RUNTIME_PATH makes libpulse fail with Failed to create secure directory (). We confirmed this by reproducing it.

3. The CRD sink came back at 19 % volume #

The working setup routes the system PipeWire into CRD's FIFO through a pipe-sink (see Fix). WirePlumber restores the last stored volume of a re-created sink; for this sink that was 19 % (-43 dB). So even when routing was correct, the audio was nearly silent.

Fix #

Strip the variables before `dbus-launch` #

In ~/.chrome-remote-desktop-session, put this at the very top, before dbus-launch and before the desktop session starts:

bashunset PULSE_RUNTIME_PATH PULSE_SINK PIPEWIRE_REMOTE
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export $(dbus-launch)
exec startlxqt          # or your session

Because the session bus is started after the unset, its activation environment is clean too. Apps now use the normal per-user PipeWire.

For shells that still inherit the variables (for example in a session started before this change), unset them in your shell startup file as well:

bashunset PULSE_RUNTIME_PATH PULSE_SINK PIPEWIRE_REMOTE

Bridge the system PipeWire into CRD's FIFO #

With CRD's own PipeWire not running, nothing writes to the FIFO the host reads. Load a pipe sink into the system PipeWire (through pipewire-pulse) pointing at that FIFO, and make it the default:

bashCRD_DIR=$(find /tmp/pyxdg-runtime-dir-fallback-$USER "${XDG_RUNTIME_DIR:-/run/user/$UID}" \
          -maxdepth 1 -type d -name 'crd_audio*' 2>/dev/null | head -1)
CRD_FIFO="$CRD_DIR/fifo_output"
[ -p "$CRD_FIFO" ] || mkfifo "$CRD_FIFO"

pactl load-module module-pipe-sink sink_name=crd_sink file="$CRD_FIFO" \
      rate=48000 channels=2 format=s16le
pactl set-default-sink crd_sink
pactl set-sink-volume crd_sink 100%      # WirePlumber may restore an old low level
pactl set-sink-mute crd_sink 0

This has to run after the CRD host is up, because the FIFO directory belongs to the host's session. Running it late is fine: the host picks up data from the FIFO whenever it arrives. We start it from the session script after a fixed sleep 20. That delay is a guess at the host's start-up time, not a measured value.

If something must update the D-Bus activation environment, set real values #

If you have a switcher script (or anything else) that fixes the activation environment of an already-running session bus, set working defaults instead of empty strings:

bashdbus-update-activation-environment \
    PIPEWIRE_REMOTE=pipewire-0 \
    PULSE_RUNTIME_PATH="${XDG_RUNTIME_DIR:-/run/user/$UID}/pulse"

(The script on the affected machine also passes PULSE_SINK=. Only an empty PULSE_RUNTIME_PATH was shown to break libpulse. The repaired session ran with an empty PULSE_SINK and played audio, but that was not tested separately.)

Repairing a session that is already running #

Processes that are already running keep the variables they started with. Without logging out, restart each launcher (panel, desktop/file manager, app runner, hotkey daemon, window manager, notification daemon, xdg-desktop-portal*) with a clean environment so its children inherit it. The CRD session bus is the dbus-launch one, not /run/user/<uid>/bus, so take its address from a session process:

bashDBUS=$(tr '\0' '\n' < /proc/$(pgrep -x lxqt-session)/environ \
       | grep '^DBUS_SESSION_BUS_ADDRESS=' | cut -d= -f2-)
env -u PULSE_RUNTIME_PATH -u PULSE_SINK -u PIPEWIRE_REMOTE -u PULSE_SERVER \
    DISPLAY="$DISPLAY" XDG_RUNTIME_DIR=/run/user/$(id -u) \
    DBUS_SESSION_BUS_ADDRESS="$DBUS" setsid -f lxqt-panel

D-Bus-activated services such as xdg-desktop-portal* can simply be killed after the activation environment is fixed; they restart on demand with the new environment. Kill them by PID (pgrep -f '^/usr/lib/xdg-desktop-portal'): pkill -f xdg-desktop-portal- also matched the command line of the shell running it and killed that shell.

What was verified #

A beep played with mpg123 in a CRD terminal was heard in the CRD client.
The media player, relaunched with a clean environment, had a sink-input on crd_sink, uncorked, at 100 %.
Freshly D-Bus-activated xdg-desktop-portal* processes got PIPEWIRE_REMOTE=pipewire-0 and a valid PULSE_RUNTIME_PATH.

Not yet verified: a complete new CRD session using the updated session script. The session in this write-up was repaired in place.

How it was found #

Look for leaked variables in any process:

bashtr '\0' '\n' < /proc/<pid>/environ | grep -E 'PULSE|PIPEWIRE'

PipeWire tools inside a CRD shell need the variable removed, or they talk to the dead instance: env -u PIPEWIRE_REMOTE pw-cli ....
busctl --user and systemctl --user show-environment look at the systemd user bus, which is the wrong bus for a CRD session started with dbus-launch.
Check that the CRD host is reading the FIFO. lsof should show the host with it open for reading and pipewire-pulse with it open read/write:
```
bashlsof /tmp/pyxdg-runtime-dir-fallback-$USER/crd_audio*/fifo_output
timeout 8 dd if=/dev/zero of=/tmp/pyxdg-runtime-dir-fallback-$USER/crd_audio*/fifo_output bs=4096 count=100
```
The dd (400 KiB) finished in about 1.8 s, which matches 48 kHz 16-bit stereo (192 kB/s). If it hangs, the host is not reading.
pactl get-sink-volume crd_sink showed the 19 % level.

systemd unit restarted 2 million times unnoticed: "Failed to load environment files: No such file or directory"

2026-09-10T00:00:00Z

Symptoms #

Nothing visible: no alerts, no CPU load, no stray processes. A sweep for restart loops found three instances of a template unit, left enabled after the application they belonged to had been removed (its user, home directory and files were gone):

ini[Unit]
Description=Old agent bridge (%i)
After=network-online.target

[Service]
User=olduser
WorkingDirectory=/home/olduser/runtime
EnvironmentFile=/home/olduser/agents/%i/agent.env
ExecStart=/usr/bin/python3 /home/olduser/runtime/bridge.py
Restart=always
RestartSec=3

The journal had this every 3 seconds per instance, for 73 days:

textmyapp@a.service: Scheduled restart job, restart counter is at 1958017.
myapp@a.service: Failed to load environment files: No such file or directory
myapp@a.service: Failed to spawn 'start' task: No such file or directory
myapp@a.service: Failed with result 'resources'.

Each of the three instances had restarted 1,958,017 times (about 5.9 million in total). A related daemon those units had depended on had been in failed state for the same 73 days.

The journal had grown to 4 G, almost all of it from this loop.

Root cause #

Two things combined to keep it invisible:

No process is ever started. EnvironmentFile= points to a file that no longer exists, so systemd fails the start before ExecStart= runs (Failed with result 'resources'). The unit status showed Mem peak: 0B, CPU: 0. CPU or memory monitoring, ps and the load average all see nothing.
RestartSec=3 stays under the start rate limit. With the defaults (StartLimitBurst=5 starts within StartLimitIntervalSec=10s), a fast loop is stopped and left in failed state. One start every 3 seconds is about 3 to 4 starts per 10 seconds, which never reaches 5, so Restart=always keeps going forever.

The units were orphans: the application was removed, but its unit files stayed enabled.

Fix #

Stop and disable the units, then clear the failed state:

bashsystemctl disable --now myapp@a.service myapp@b.service myapp@c.service
systemctl reset-failed

Then remove the leftover unit file (and any drop-in directories for related units) and reload:

bashrm -f /etc/systemd/system/myapp@.service
systemctl daemon-reload

Afterwards: no unit files left for the old application, and no units in failed or activating state.

Journal cleanup: size, not time #

bashjournalctl --vacuum-size=500M      # 4G -> 467.8M, freed about 3.5G

journalctl --vacuum-time=30d freed 0 B here. Time-based vacuuming only removes archived journal files whose newest entry is older than the cutoff. The loop rotated a new 80 MB file about every 24 minutes, so every retained file was recent. Vacuuming by size works.

Check journal size as root. As an ordinary user, journalctl --disk-usage reported only that user's own journal (8M), while the system total was 467.8 M after cleanup.

Removing the orphaned package #

The related daemon's package was removed with pacman -Rns. Preview the cascade first: pacman -Rs --print <pkg> (pacman rejects -Rns --print, because --nosave and --print cannot be combined). The preview listed a password-hashing library among the dependencies to be removed; pacman -Qi <lib> showed Required By: only the package being removed, so it was safe.

How it was found #

List every service with a non-trivial restart counter:

bashsystemctl list-units --type=service --all --no-legend --plain | awk '{print $1}' | while read u; do
    n=$(systemctl show "$u" -p NRestarts --value 2>/dev/null)
    case "$n" in ""|0|1|2|3) ;; *) echo "$u NRestarts=$n";; esac
done

Also useful:

bashsystemctl list-units --state=failed,activating --all

A unit that keeps showing activating (auto-restart) is in a restart loop.

The same sweep on the same day found a different crash loop that used 2.24 CPU cores. That one was easy to see once CPU per cgroup was measured, but it would not stand out in restart counts. A sweep needs both: CPU per cgroup and NRestarts.

References #

systemd.unit(5): StartLimitIntervalSec=, StartLimitBurst=.
systemd.exec(5): EnvironmentFile= (a missing file fails the start unless the path is prefixed with -).
journalctl(1): --vacuum-size=, --vacuum-time=.

faster-whisper: Library libcublas.so.12 is not found or cannot be loaded (system has CUDA 13)

2026-09-10T00:00:00Z

Symptoms #

faster-whisper with device="cuda" dies at the first GPU computation with:

textLibrary libcublas.so.12 is not found or cannot be loaded

The system CUDA is version 13 and only has libcublas.so.13 (on Arch, in /opt/cuda/lib64).

A quick smoke test can hide the problem. A test on silence or a synthetic sine wave passes even with cuBLAS missing: voice activity detection (VAD) finds no speech, so the GPU encoder never runs. Always smoke-test speech-to-text on real speech.

Root cause #

The ctranslate2 4.7.1 wheel from PyPI is linked against CUDA 12. It loads libcublas.so.12 (and cuDNN for CUDA 12) at run time. A CUDA 13 system does not provide those libraries, and the loader will not substitute libcublas.so.13 for a .so.12 dependency.

Fix #

Put the CUDA 12 runtime libraries inside the venv, so it does not depend on what the system or another application happens to ship:

bash<venv>/bin/pip install nvidia-cublas-cu12 nvidia-cudnn-cu12

These wheels put the libraries under site-packages/nvidia/cublas/lib and site-packages/nvidia/cudnn/lib. The dynamic loader still has to find them, so start Python through a wrapper that sets LD_LIBRARY_PATH:

bash#!/usr/bin/env bash
VENV=<venv>
SP="$VENV/lib/python3.11/site-packages"
export LD_LIBRARY_PATH="$SP/nvidia/cublas/lib:$SP/nvidia/cudnn/lib:${LD_LIBRARY_PATH:-}"
exec "$VENV/bin/python" transcribe.py "$@"

Setting os.environ["LD_LIBRARY_PATH"] inside the Python script does not work: the dynamic loader reads LD_LIBRARY_PATH when the process starts, so it has to be exported before exec. Adjust python3.11 in the path to your venv's Python version.

An earlier workaround pointed LD_LIBRARY_PATH at the CUDA 12 libraries bundled with another application (ollama's cuda_v12 directory). That works, but it breaks if that application is removed or its bundled CUDA moves to version 13. The venv-local wheels avoid that.

With this in place, sequential transcription with large-v3 ran at about 31x realtime on an RTX 5080 (5.35 hours of audio in about 11 minutes of GPU time).

In the same bulk job, BatchedInferencePipeline crashed on a file that was music only:

textRuntimeError: No clip timestamps found. Set 'vad_filter' to True or provide 'clip_timestamps'.

The batched pipeline needs VAD to return at least one speech clip and raises when it returns none. One music-only or silent file stops a whole batch. The sequential WhisperModel.transcribe() handles such files without raising, and at ~31x realtime it was fast enough that the batched path was not worth it for bulk work:

pythonfrom faster_whisper import WhisperModel

model = WhisperModel("large-v3", device="cuda", compute_type="float16")
segments, info = model.transcribe(path, language="ja", vad_filter=True,
                                  beam_size=5, condition_on_previous_text=False)
segments = list(segments)   # it is a generator; consume it before writing output

condition_on_previous_text=False stops one hallucinated line from seeding the next.

On music-only audio, large-v3 may still "transcribe" a stock filler phrase (in Japanese, ご視聴ありがとうございました, "thank you for watching") once or twice and nothing else. It looks like a transcript but is hallucination. A cheap check that worked for flagging such files:

pythonuniq  = {s.text.strip() for s in segments if s.text.strip()}
chars = sum(len(s.text.strip()) for s in segments)
no_speech = len(uniq) <= 2 and chars < max(40, duration / 20)

For checking a whole batch without reading every file, characters per second of audio was a useful health metric: conversational Japanese interviews landed in a tight 5.1–5.8 chars/s band, and the outliers were real silence or music, not failures.

Claude Code: auth login succeeds in the browser, then "not logged in" (~/.claude owned by root)

2026-06-28T00:00:00Z

Symptoms #

Running claude auth login as a normal user:

The browser OAuth flow completes and says the app is authorized.
Claude Code then reports that it is not logged in, retries about three times, and gives up.
claude auth status shows:

json{"loggedIn": false, "authMethod": "none"}

No ~/.claude/.credentials.json is ever created.

Root cause #

~/.claude/ (and ~/.claude/skills/) were owned by root, mode 755:

bashls -ld ~/.claude ~/.claude/skills     # owner shows as root instead of the user

Claude Code saves the OAuth token to ~/.claude/.credentials.json. The user cannot create files in a root-owned directory, so the token is never written and every check reads "logged out". The login itself works; only saving it fails.

The directory had been created by a single run of claude as root with the user's HOME during setup (a sudo claude, or a skills install run as root). Nothing kept re-breaking it; it was a one-off. The exact command that did it was not identified, only the time window from the directory timestamps.

Fix #

Give the directory back to the user, then log in again:

bashsudo chown -R user:user ~/.claude
claude auth login
claude auth status        # should now report "loggedIn": true

After the chown, claude auth login saved the credentials normally. The same latent problem was found and fixed on two other machines set up the same way.

To avoid it: do not run claude as root with a normal user's HOME (sudo claude, or root with HOME pointing at a user's home). It leaves ~/.claude owned by root and silently breaks that user's login and skill sync.

Unrelated: "claude: command not found" in some shells #

On one machine there was a second, unrelated symptom: typing claude in an interactive shell gave command not found. Claude Code was installed with npm into ~/.npm-global, and ~/.npm-global/bin was added to PATH only in ~/.bash_profile, not in ~/.bashrc. Login shells found claude; non-login interactive shells did not. Fix: add it in ~/.bashrc too:

bashexport PATH="$HOME/bin:$HOME/.npm-global/bin:$PATH"

Default ACL shows #effective:--- on files an app rewrites with mode 0600 (certbot keys, Home Assistant auth)

2026-06-25T00:00:00Z

Symptoms #

A nightly backup runs as an unprivileged backup user. Root-owned files were made readable to that user with a default ACL on their directories, and the backup worked for a few days. Then it started reporting one error each night.

On the Home Assistant machine (restic):

texterror: open /var/lib/homeassistant/.storage/auth: permission denied
Warning: at least one source file could not be read

On the certbot machine (rsync), right after a new certificate was issued:

textrsync: [sender] send_files failed to open "/etc/letsencrypt/archive/example.com/privkey1.pem": Permission denied (13)
rsync: [sender] send_files failed to open "/etc/letsencrypt/keys/0062_key-certbot.pem": Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23)

getfacl on the failing file shows the named-user entry is still there, but masked out:

textuser:backupuser:r-x	#effective:---
mask::---

Only the newly written files were affected. Older files in the same directories (for example Home Assistant's auth_provider.homeassistant, mode 0640) stayed readable.

Root cause #

When a file has named-user or named-group ACL entries, it also has a mask entry. The effective permission of every named entry (and of the owning group entry) is its own permission AND the mask. getfacl prints #effective: when the mask removes something.

When a file is created in a directory that has a default ACL, acl(5) ("Object creation and default ACLs") says:

the new file inherits the directory's default ACL as its access ACL, and
the entries that correspond to the file permission bits are then reduced to what the mode argument of open()/creat() allows.

When the ACL has a mask, the group permission bits correspond to the mask entry, not to the owning-group entry (acl(5), "Correspondence between ACL entries and file permission bits"). So the group bits of the create mode cap the mask. An application that creates its secrets with mode 0600 has group bits ---, so the new file gets mask::---, and the inherited user:backupuser:r-x becomes #effective:---.

The same correspondence works in the other direction, so a later chmod 600 on a file with an ACL also sets the mask to ---. (General ACL behaviour from the man page; in these two cases the files were created or rewritten by the application at 0600.)

That is why the default ACL looked like a fix and then stopped working:

Home Assistant rewrites .storage/auth (mode 0600) whenever auth or refresh tokens change. The default ACL lasted until the next token rotation.
certbot writes new private keys under /etc/letsencrypt/archive/<name>/ and /etc/letsencrypt/keys/ at mode 0600. Issuing a certificate for a new name produced two unreadable files.

A default ACL alone can never give a durable grant on files an application (re)writes at mode 0600.

Fix #

setfacl -m recalculates the mask by default. setfacl(1): the mask is set to "the union of all permissions of the owning group, and all named user and group entries", unless you give a mask entry explicitly or use -n. So re-applying the grant restores mask::r-x.

Immediate fix, as root:

bashsetfacl -R -m u:backupuser:rX /var/lib/homeassistant/.storage
setfacl -R -m u:backupuser:rX /etc/letsencrypt

(X gives execute only to directories and to files that already have execute for someone.)

Durable fix: re-apply it from root's cron a few minutes before the backup runs, for example /etc/cron.d/backup-acl-refresh:

text55 2 * * * root setfacl -R -m u:backupuser:rX /var/lib/homeassistant/.storage 2>/dev/null

with the backup at 03:00, and the same pattern with /etc/letsencrypt on the certbot machine.

Verified: on the Home Assistant machine a manual backup re-run then finished with no errors; on the certbot machine all *.pem files were readable by the backup user and an rsync dry-run was clean.

Caveats:

If the application rewrites the file between the cron job and the backup, that night still fails. Home Assistant is idle overnight, so this was accepted as rare.
The recalculated mask also re-enables whatever the owning-group entry grants (the mask is the union of that entry and the named entries). Check getfacl on a key file after the fix if the owning group should not read your private keys. This follows from setfacl(1); it was not checked separately in these cases.
The alternative is to not need the ACL at all: read the files as root (or have a root job copy them) for the backup.

References #

acl(5): "Correspondence between ACL entries and file permission bits" and "Object creation and default ACLs".
setfacl(1): -n, --no-mask and --mask.

Black screen after restarting X: NVIDIA: Failed to initialize the NVIDIA kernel module (kernel upgraded, not rebooted)

2026-06-19T00:00:00Z

Symptoms #

A GPU application crashed X on the desktop. Restarting X then gave a permanent black screen. The display manager log showed X dying straight away:

textFailed to read display number from pipe

The real error was in the Xorg log (/var/log/Xorg.0.log):

text(EE) NVIDIA: Failed to initialize the NVIDIA kernel module

dmesg had an API mismatch message: the client (the Xorg driver) was 610.43.02 and the kernel module was 590.48.01.

Root cause #

The kernel and the NVIDIA driver had been upgraded with pacman, but the machine had not been rebooted:

bashuname -r                          # 6.18.13-arch1-1   (running)
pacman -Q linux                   # linux 7.0.12.arch1-1  (installed)
cat /proc/driver/nvidia/version   # 590.48.01  (module in memory)
dkms status                       # nvidia 610.43.02 built for 7.0.12 only

DKMS built nvidia-open-dkms 610.43.02 only for the new kernel, 7.0.12. There was no 610 module for the running kernel, 6.18.13.
The old 590.48.01 module was still loaded. The new 610.43.02 Xorg driver cannot talk to it, so X fails at startup.
The old module could not simply be unloaded: a second Xorg server (Chrome Remote Desktop runs its own, here on display :20) still had it open. fuser /dev/nvidia* /dev/dri/* showed that process.
Even after that server was stopped, nvidia_drm still had kernel-internal DRM references (cat /sys/module/nvidia_drm/refcnt showed 9), so a normal rmmod failed.

The simple fix is to reboot into the new kernel. The steps below got a working display back on the old kernel without a reboot, then prepared a clean reboot.

Fix #

Live recovery (no reboot) #

Run as root. Replace the versions with yours.

Install the headers for the running kernel (they were still in the pacman cache):

bashpacman -U /var/cache/pacman/pkg/linux-headers-<running-kernel-version>-x86_64.pkg.tar.zst

Rebuild the module database for the running kernel (the upgrade had removed its kernel/ module tree):
```
bashdepmod -a <running-kernel-version>
```
Build the new driver for the running kernel. The DKMS source is named nvidia, even when the installed package is nvidia-open-dkms:
```
bashdkms install nvidia/<driver-version> -k <running-kernel-version>
```
Stop everything that holds the module open (here, Chrome Remote Desktop's Xorg):
```
bashsystemctl stop chrome-remote-desktop@<user>.service
```
Unload the old modules. nvidia_drm needed a forced removal because of the stuck references:
```
bashrmmod -f nvidia_drm
rmmod nvidia_modeset nvidia
```

Load the new modules and check the version:

bashmodprobe -a nvidia nvidia_modeset nvidia_drm nvidia_uvm
cat /proc/driver/nvidia/version     # must show the new version

The forced rmmod deleted /dev/dri/. Re-add the GPU's PCI device so udev recreates it (find the address with lspci -D | grep -i nvidia, e.g. 0000:02:00.0):
```
bashudevadm trigger --action=add /sys/bus/pci/devices/<gpu-pci-address>
udevadm settle
```

Start the display manager, then Chrome Remote Desktop:

bashsystemctl start lightdm             # or sddm
systemctl start chrome-remote-desktop@<user>.service

Notes:

modprobe does nothing if a module of that name is already loaded, even an old version. Always check /proc/driver/nvidia/version after loading.
modprobe with several module names needs -a. Without it, the names after the first are passed as parameters to the first module. (Our original notes left out -a; the version check in step 6 is what showed the right module was loaded.)
rmmod -f is a last resort. It was used here only because X was already dead and nothing else would release nvidia_drm.
Start the main display manager before restarting Chrome Remote Desktop. Its Xorg holds the module and, if it comes up first, can take over the user session.

This recovery was only partly clean. X came back, but the desktop session started on the remote desktop's display instead of the physical one. Two settings caused that:

~/.dmrc still had Session=xfce from an old desktop switch, so LightDM started a session that exited at once, leaving only a cursor on the physical screen.
ReuseSession=true in the SDDM config (SDDM was used during the recovery) made it attach to the existing remote session instead of starting a new one.

As a stopgap on the physical console: startx /usr/bin/startlxqt -- :0 vt2.

Before rebooting into the new kernel #

Step 1 installs the old kernel's headers, which replaces the new kernel's headers. DKMS then had the driver for the new kernel only "added", not "installed". Put the new headers back and check before rebooting:

bashpacman -U /var/cache/pacman/pkg/linux-headers-<new-kernel-version>-x86_64.pkg.tar.zst
dkms status -k <new-kernel-version>

The DKMS pacman hook rebuilt the module when the headers were installed. dkms status should then show nvidia/<driver-version>, <new-kernel-version>, x86_64: installed.

Also fix the default session in ~/.dmrc (here Session=xfce → Session=lxqt).

After the reboot into the new kernel, the journal had no NVIDIA errors and systemctl --failed listed no units.

How it was found #

journalctl -u lightdm -u sddm showed X exiting at once; /var/log/Xorg.0.log gave the real error.
uname -r against pacman -Q linux showed the pending reboot.
/proc/driver/nvidia/version and dkms status showed the loaded module was older than the userspace driver, with no matching build for the running kernel.
fuser /dev/nvidia* /dev/dri/* found the second Xorg holding the module; /sys/module/nvidia_drm/refcnt showed the leftover references after it stopped.
ls /tmp/.X*-lock and ss -xl | grep X11 listed the running X displays (:0 and :20).

The lesson: after a pacman upgrade that touches the kernel or the NVIDIA driver, reboot before restarting X.

M5Stack Cardputer-ADV plays a loud constant whine over all audio (ES8311, Arduino M5Unified)

2026-06-14T00:00:00Z

Symptoms #

Custom Arduino firmware on an M5Stack Cardputer-ADV (an MP3 player sketch built on M5Cardputer / M5Unified and ESP8266Audio) produced a loud, constant whine over all audio:

the same with a generated test tone and with MP3 playback,
also when running on battery,
at every sample rate tried.

The pitch of the actual audio was correct; only the added tone was wrong. The stock UIFlow firmware plays through the same ES8311 codec cleanly, which showed it was a configuration problem, not hardware.

Root cause #

A clock mismatch between the I2S frame and the codec's clock divider:

The speaker was configured mono, so the I2S frame was 16 bits per sample period: BCLK = fs × 16 = 768 kHz at 48 kHz.
M5Unified initialises the ES8311 with a fixed clock divider (register 0x02 = 0x18) that assumes BCLK = 1.536 MHz (a 32-bit stereo frame).
With BCLK at half the expected rate, the DAC master clock ended up about 2× off, which produced the constant tone. The audio pitch stayed right because LRCK still locked the sample rate.

The fix below confirms the mechanism. Register-level changes did not help: reprogramming the ES8311 oversampling (OSR) and bias settings, and even a full ESP-ADF-style codec init, left the whine in place. It took about a dozen reflashes to find.

Fix #

Configure the speaker as stereo before starting it. That gives a 32-bit frame and BCLK = 1.536 MHz, which matches the divider:

cppauto spk_cfg = M5Cardputer.Speaker.config();
spk_cfg.stereo = true;          // 32-bit I2S frame -> BCLK 1.536 MHz at 48 kHz
M5Cardputer.Speaker.config(spk_cfg);
M5Cardputer.Speaker.begin();

spk_cfg.stereo = true was the whole fix; no codec registers needed changing. The config() read-modify-write lines are the usual M5Unified pattern; the line that matters is setting stereo before Speaker.begin().

ESP32-S3 without PSRAM: HTTPS fetch returns 0 bytes or connect() fails "connection refused" (TLS out of memory)

2026-06-14T00:00:00Z

Symptoms #

An Arduino MP3 player sketch on an M5Stack Cardputer-ADV fetches a JSON feed over HTTPS, then downloads several files over HTTPS to the microSD card. On this board:

the feed fetch returned 0 bytes, and
once the feed had been parsed, the per-file downloads failed because client.connect() reported "connection refused", although the server was fine.

Nothing was wrong with the network or the server. Both were memory failures that do not look like memory failures. (The "connection refused" text is what the sketch's connect failure reported; the exact log line was not recorded.)

Root cause #

The Cardputer-ADV's ESP32-S3 has no PSRAM, only about 320 KB of internal SRAM, and a TLS handshake needs large contiguous heap blocks. With the audio decoder, the audio output object, a parsed JSON document and a 64 KB display sprite all allocated, only about 10 KB contiguous was left after the mbedTLS handshake, and new TLS connections could not get the buffers they needed.

The number that settled it was the largest free heap block before connecting: about 33 KB → TLS fails, about 64 KB → TLS works. To watch it yourself, log heap_caps_get_largest_free_block(MALLOC_CAP_8BIT) (or ESP.getMaxAllocHeap()) just before client.connect(); total free heap is misleading here because fragmentation is the problem.

Fix #

Free the big allocations before any TLS work, and keep large data out of RAM:

Free the MP3 decoder and the audio output object before starting TLS.
Stream the response to a temporary file on SD, then parse the JSON from the file, instead of reading the whole body into RAM.
Free the JSON document before the per-file downloads. Without this step, client.connect() fails with "connection refused".
Delete the 64 KB display sprite for the duration of Wi-Fi/TLS. It turned out to be the single largest allocation: once the app grew a little (more globals), steps 1–3 alone were no longer enough. While the sprite is gone, draw status text straight to the display.

cppsprite.deleteSprite();   // M5Canvas back buffer, ~64 KB
// ... connect, download, write to SD; draw progress directly on the display ...
ESP.restart();           // come back up clean and recreate the sprite

Restarting at the end of the sync is a simple way to get every freed object (decoder, sprite) back in a known state. With all four steps, the largest free block went from about 33 KB to about 64 KB and the HTTPS fetches and downloads worked.

ESP32-S3 Arduino Wi-Fi HTTP downloads crawl at about 1 KB/s

2026-06-14T00:00:00Z

Symptoms #

An Arduino MP3 player sketch on an M5Stack Cardputer-ADV downloads MP3 files over Wi-Fi and writes them to the microSD card. Throughput was about 1 KB/s.

Root cause #

Wi-Fi modem power-save. Turning it off was the only change needed, which is how it was identified.

Background (general ESP32 behaviour, not separately measured here): in station mode the ESP32 Wi-Fi driver uses modem sleep by default, so the radio dozes between access-point beacons. That is fine for occasional small requests but throttles a long bulk download.

Fix #

Turn modem sleep off once the station is up:

cpp#include <WiFi.h>

WiFi.mode(WIFI_STA);
WiFi.begin("your-ssid", "your-wifi-password");
while (WiFi.status() != WL_CONNECTED) delay(100);
WiFi.setSleep(false);   // disable modem power-save

With this one change, downloads went from about 1 KB/s to about 85 KB/s, and the files were verified byte for byte.

Caveat (not measured here): with sleep off the radio stays awake, so expect higher current draw while Wi-Fi is on. On a battery device, turn Wi-Fi off when the transfer is done.

ESPHome device reboots every 15 minutes: "[E][api] No clients; rebooting"

2026-06-06T00:00:00Z

Symptoms #

An ESP8266 running ESPHome rebooted roughly every 15 minutes. It joined Wi-Fi normally, then restarted. This happened while it was being developed on the bench, before any Home Assistant instance was connecting to it.

The log line just before each restart:

text[E][api:127]: No clients; rebooting

Because the device was on a test network at the time, the first suspect was Wi-Fi. It was not Wi-Fi.

Root cause #

The native api: component has its own reboot_timeout, separate from the one in wifi:. If no API client (normally Home Assistant) connects within that time, the node reboots on purpose. The ESPHome docs describe it as:

The amount of time to wait before rebooting when no client connects to the API. This is needed because sometimes the low level ESP functions report that the ESP is connected to the network, when in fact it is not - only a full reboot fixes it. Can be disabled by setting this to 0s. Defaults to 15min.

So any ESPHome node that includes api: but that no Home Assistant ever talks to (bench testing, a device you control only through web_server:, a network Home Assistant can't reach) will restart every 15 minutes, and the log says so in plain words.

Fix #

Set the API reboot timeout to 0s (disabled):

yamlapi:
  encryption:
    key: !secret api_encryption_key
  reboot_timeout: 0s

After reflashing, the node stayed up (no further reboots on the bench).

On this device reboot_timeout: 0s was also set under wifi:, so it keeps retrying Wi-Fi forever instead of rebooting:

yamlwifi:
  ssid: "your-ssid"
  password: "your-wifi-password"
  reboot_timeout: 0s

That second setting was a deliberate choice for this device, not part of the 15-minute fix: the reboot loop was caused by api: alone.

Caveat: the API timeout exists for a reason. Once Home Assistant is connecting reliably, you may want to put a non-zero reboot_timeout back under api: so a node whose network stack has silently wedged recovers on its own.

References #

ESPHome docs, Native API Component, reboot_timeout.

CUPS "Unable to locate printer *.local" even though avahi-resolve finds the printer

2026-05-16T00:00:00Z

Symptoms #

A network printer had been set up in CUPS using its mDNS hostname. The queue accepted jobs, but nothing printed and jobs piled up. lpstat -t showed:

textdevice for Office_Printer: ipp://printer.local:631/ipp/print
Unable to locate printer "printer.local".

At the same time, Avahi had no trouble finding the printer:

bashavahi-resolve -n printer.local     # returns the printer's address

But ordinary name resolution did not:

bashgetent hosts printer.local         # prints nothing
ping printer.local                 # Name or service not known

Root cause #

CUPS resolves the queue's hostname through the normal glibc resolver (NSS), not by asking Avahi directly. Whether NSS knows about .local names is decided by the hosts: line in /etc/nsswitch.conf, which here was:

texthosts: files dns myhostname

There is no mdns module in that list, so .local lookups went to files and dns, both of which fail. The nss-mdns package (which provides the mdns* NSS modules) was already installed; it just was not enabled in nsswitch.conf. On Arch it is only an optional dependency of avahi, so on another machine you may need pacman -S nss-mdns first.

The difference between avahi-resolve (works) and getent hosts (fails) is the tell: avahi-resolve talks to avahi-daemon directly, getent goes through NSS the way CUPS does.

Fix #

Add mdns4_minimal [NOTFOUND=return] to the hosts: line, before dns:

bashsudo sed -i.bak 's|^hosts:.*|hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname|' /etc/nsswitch.conf

If your hosts: line has other entries (for example resolve or mymachines), edit it by hand instead of replacing the whole line; the point is to insert mdns4_minimal [NOTFOUND=return] before dns.

Check:

bashgetent hosts printer.local         # now prints the printer's address

No service restart is needed: NSS reads nsswitch.conf on each lookup, and CUPS picked up the change on the next job.

[NOTFOUND=return] stops the lookup when mDNS says a .local name does not exist, instead of falling through to DNS. That avoids slow upstream DNS queries for names that will never resolve there.

The same fix applies to any .local device on the machine (AirPlay receivers, other Bonjour/mDNS hosts), not only printers.

Do not cancel the stuck jobs #

Jobs stuck on a name-resolution failure are real prints. Once the hostname resolves, CUPS retries them and they print. If you cancel them while diagnosing (cancel -a), they have to be printed again. We made this mistake once; leave the queue alone and let it flush.

How it was found #

bashlpstat -t                          # queues and the last error per queue
avahi-resolve -n printer.local     # what Avahi sees
getent hosts printer.local         # what NSS (and CUPS) sees: the gap
avahi-browse -art                  # list mDNS services on the network
grep ^hosts /etc/nsswitch.conf     # look for mdns4_minimal
pacman -Q nss-mdns                 # confirm the NSS module is installed

References #

Arch Wiki, Avahi: Hostname resolution.

systemd user service not started at boot: "Found ordering cycle ... Job deleted to break ordering cycle"

2026-04-24T00:00:00Z

Symptoms #

A web front end, run as a systemd user service, was down after a reboot. The reverse proxy in front of it returned 502 and logged connection refused to the local port. The unit was inactive (dead) since boot, and nothing had tried to start it. The user journal from boot had this (unit names made generic):

textdefault.target: Found ordering cycle: myapp-web.service/start
  after myappd.service/start after default.target/start
  - after myapp-web.service
default.target: Job myapp-web.service/start deleted to break ordering cycle

Root cause #

Two user units:

myappd.service: the daemon. WantedBy=default.target, and After=default.target.
myapp-web.service: the web front end. WantedBy=default.target, Requires= and After=myappd.service.

WantedBy=default.target makes the target want the unit. A target unit also automatically adds After= for everything it Wants= or Requires= (systemd.target(5)), so default.target is ordered after myapp-web.service. With the explicit lines that gives:

textdefault.target  after  myapp-web.service  after  myappd.service  after  default.target

That is a loop. systemd breaks ordering cycles at boot by deleting one of the jobs in it, here the start job for myapp-web.service, so the web front end never started.

A unit that is WantedBy= a target must not also be After= that same target: the target only counts as reached once the units it wants are up.

Fix #

Remove After=default.target from the daemon's unit (~/.config/systemd/user/myappd.service):

ini[Unit]
Description=myapp daemon

[Service]
Type=simple
ExecStart=/path/to/myappd
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

Then:

bashsystemctl --user daemon-reload
systemctl --user start myapp-web.service   # pulls in myappd via Requires=

Both units came up, the local port answered, and the proxy stopped returning 502.

If a user service really needs ordering, order it after a more specific unit, not after the target that wants it. Note that services with default dependencies are already ordered After=basic.target (systemd.service(5)), so you do not need to add that yourself.

How it was found #

The proxy logged connection refused to the local port, so the back end was down rather than slow. systemctl --user status myapp-web.service showed inactive (dead) since boot, and the user journal for that boot showed the ordering-cycle message above.

References #

systemd.target(5): automatic After= dependencies for units a target wants.
systemd.service(5): implicit dependencies of service units.

Chromium "Show in folder" fails with '"." is not a valid folder' (opens Baobab)

2026-04-14T00:00:00Z

Symptoms #

In Chromium's downloads panel, clicking the folder icon next to a downloaded file ("Show in folder") did not open a file manager. Instead this error appeared:

text"." is not a valid folder

Root cause #

On Linux, Chromium hands "show in folder" to xdg-open, which picks the default application for the MIME type inode/directory.

Baobab (GNOME Disk Usage Analyzer) declares that MIME type in its desktop file, /usr/share/applications/org.gnome.baobab.desktop:

iniMimeType=inode/directory;

With no user-level default set, Baobab won:

text$ xdg-mime query default inode/directory
org.gnome.baobab.desktop

So xdg-open launched Baobab, which expects a folder to scan, not to browse, and rejected the "." argument with the error above.

This happened in an LXQt session. Our guess (not tested elsewhere) is that it is most likely on non-GNOME desktops, where nothing else sets a user default for directories, so Baobab's system-wide claim is the one that gets picked.

Fix #

Make your file manager the user-level default for inode/directory in ~/.config/mimeapps.list. With pcmanfm-qt (LXQt's file manager):

ini[Default Applications]
inode/directory=pcmanfm-qt.desktop;

[Added Associations]
inode/directory=pcmanfm-qt.desktop;

Or with xdg-mime, which writes the [Default Applications] entry for you:

bashxdg-mime default pcmanfm-qt.desktop inode/directory

Use the desktop file of whatever file manager you have (thunar.desktop, org.gnome.Nautilus.desktop, pcmanfm.desktop, …).

Verify:

text$ xdg-mime query default inode/directory
pcmanfm-qt.desktop

No restart was needed; the next "Show in folder" click opened the file manager.

The fix used on the affected machine was the mimeapps.list edit; the xdg-mime default one-liner is the standard equivalent but was not the command actually run.

Chromium over ssh -X: Connection rejected because of wrong authentification

2022-09-02T00:00:00Z

Symptoms #

Between two Ubuntu 20.04 machines, ssh -X forwarding worked for xterm and friends, but Chromium refused to open:

textConnection rejected because of wrong authentification

Cause #

Chromium on Ubuntu is a snap. Snaps get their own $HOME under ~/snap/<name>/current, so Chromium looks for .Xauthority there and never finds the cookie that sshd wrote to ~/.Xauthority.

Fix #

Link the real file into the snap's home:

bashln -s ~/.Xauthority ~/snap/chromium/current/.Xauthority

Alternatively run it with XAUTHORITY=$HOME/.Xauthority chromium.

FreeDOS 1.3 under QEMU on Windows 10: networking and mTCP FTP

2022-02-23T00:00:00Z

Symptoms #

Networking did not come up at boot. FreeDOS printed:

textQEMU network detected.
Physical hardware networking is not supported at this time.

Later, mTCP's FTP.EXE could log in to an FTP server on the Windows host but then failed with 530 User cannot log in, home directory inaccessible.

Cause #

FreeDOS 1.3's network startup script (FDNET.BAT) skips driver loading when it detects QEMU. The 530 error came from the Windows FTP server: the anonymous user could not read the shared folder.

Fix #

Launch QEMU with an emulated AMD PCnet NIC and user-mode networking:

batqemu-system-x86_64 -m 150 -cpu 486 -rtc base=localtime ^
  -drive file=freedos.img,format=raw -net nic,model=pcnet -net user

In C:\FREEDOS\BIN\FDNET.BAT, comment out (or delete) the line that jumps past QEMU:

batREM if /i "%1" == "start" goto NoStartQEM

Check C:\FREEDOS\MTCP.CFG for sane settings (DHCP works with -net user). After a reboot the interface comes up.

For the FTP error, open the shared folder's Properties → Security on the Windows host and add the group Everyone with read/write access (or whatever account the FTP site maps anonymous users to).

ESPHome ESP8266 nodes stop joining Wi-Fi: reason='Association Leave'

2021-04-12T00:00:00Z

Symptoms #

ESPHome nodes that had worked for months stopped joining the network. The logs repeated:

text[I][wifi:194]: WiFi Connecting to 'xyz'...
[W][wifi_esp8266:191]: wifi_apply_hostname_(somehostname): lwIP error -16 on interface st (index 0)
[W][wifi_esp8266:395]: Event: Disconnected ssid='xyz' bssid=C8:0E:15:xx:xx:xx reason='Association Leave'

Cause #

The router's DHCP address pool was exhausted. The node associates, fails to get an address, and the connection is torn down with Association Leave, which looks like a Wi-Fi problem but is really an IP-addressing one.

Fix #

Either enlarge the DHCP pool or remove stale leases on the router, or give each node a static address outside the pool in its wifi: block:

yamlwifi:
  ssid: "xyz"
  password: "your-wifi-password"
  manual_ip:
    static_ip: 192.168.1.150
    gateway: 192.168.1.1
    subnet: 255.255.255.0

Pick an address outside the router's DHCP range so it can never be handed out twice.

VcXsrv: Authorization required, but no authorization protocol specified

2021-04-11T00:00:00Z

Symptoms #

Starting an X11 program from WSL2 against a VcXsrv X server on the Windows side failed with:

textAuthorization required, but no authorization protocol specified

Cause #

VcXsrv's access control rejects the connection, because WSL2 connects over a virtual network and does not have a matching Xauthority cookie.

Fix #

Quit VcXsrv and start it again with XLaunch. On the Extra settings page tick Disable access control. Programs then connect normally.

This lets anything that can reach the port open windows on your display. Keep the Windows firewall rule for VcXsrv limited to private networks.

DHT22 temperature/humidity sensor on a NodeMCU 0.9 with ESPHome and Home Assistant

2021-04-11T00:00:00Z

Setup #

In Home Assistant's ESPHome tab create a new node. For the device type pick Other ESP8266s → NodeMCU 0.9, add Wi-Fi credentials, then edit the YAML. The DHT sensor docs list the options.

yamlesphome:
  name: node-mcu-09

esp8266:
  board: nodemcu

wifi:
  ssid: "your-ssid"
  password: "your-wifi-password"
  ap:                              # fallback hotspot if Wi-Fi fails
    ssid: "Node Mcu 09 Fallback Hotspot"
    password: "fallback-password"

captive_portal:
logger:
api:
ota:
  - platform: esphome

sensor:
  - platform: dht
    model: DHT22
    pin: D2
    temperature:
      name: "Temperature 1"
    humidity:
      name: "Humidity 1"
    update_interval: 60s

(Written in 2021 with platform: ESP8266 under esphome:; current ESPHome wants the separate esp8266: block shown above.)

Wiring:

text3.3V -> DHT22 VCC
D2   -> DHT22 DATA
GND  -> DHT22 GND

The DHT22 datasheet recommends a 4.7 kΩ pull-up between VCC and DATA. Bare sensors need one; most breakout boards already have it.

Symptoms: upload over USB fails #

Re-flashing over USB later failed every time with:

textUpload with baud rate 460800 failed. Trying again with baud rate 115200.

The same happened with other NodeMCU boards.

Fix #

Disconnect the sensor wires from the board's pins while flashing, then reconnect them. Something on the attached pins was getting in the way of the boot/flash sequence (D2 itself is not a strapping pin, so the exact cause is unproven). Once the first image is on the board, OTA updates over Wi-Fi avoid the problem.

Testing SD cards for fake capacity with f3 under WSL2

2020-04-27T00:00:00Z

Symptoms #

You want to check whether an SD card really has the capacity it claims (fakes report a large size but silently lose data past the real capacity), and the only Linux you have is WSL2.

Fix #

Mount the card's drive letter (here E:) with drvfs, then run f3:

bashsudo apt install f3
sudo mkdir -p /mnt/e
sudo mount -t drvfs E: /mnt/e
f3write /mnt/e
f3read  /mnt/e

f3write fills the free space with test files; f3read reads them back and reports corrupt or overwritten sectors. A genuine card shows no losses. See the LinuxReviews guide for more background.

Cause #

Not a bug, just the missing step: WSL2 does not auto-mount removable drives, so you have to mount the letter yourself with -t drvfs.

Using a Toshiba FlashAir W-02 Wi-Fi SD card after support ended

2020-04-12T00:00:00Z

Symptoms #

KIOXIA (formerly Toshiba Memory) ended support and removed setup software for the FlashAir™ W-02 and Class 6 cards:

technical support for and some software for wireless SD card FlashAir™ W-02 Class10 and FlashAir™ Class6 … will no longer be available after 31 January 2020.

So there is no official way to configure or use the card.

Fix #

The card's built-in web server still works without the app:

Insert the card in a camera (or reader) and power it so the card starts its access point.
Join the card's Wi-Fi network from a phone or laptop.
The network properties show the DNS server / gateway as 192.168.0.1. Open http://192.168.0.1/ in a browser.

You get a file listing of the card and can download files. There is no drag-and-drop upload, but for pulling photos off a camera it is enough.

Panasonic Lumix GF1 (Japan model) — enable English menus with PTool

2020-04-12T00:00:00Z

Symptoms #

Japan-market GF1 bodies only offer Japanese menus. Earlier attempts to flash a PTool-patched firmware failed: the camera did not accept the update.

Cause #

The patched file must look like a newer firmware. With the default version increment the camera refused it. The clue came from JMF on personal-view.com.

Fix #

Download PTool (originally http://www.gh1-hack.info/ptool3d.zip; the site is gone, look for a mirror), unzip and run it.
Load Firmware: load the official GF1 firmware from Panasonic's site (here GF1__122.bin).
Apply the patch: Patches for end users → Interface → All interface languages.
Tick version increment, prevent version compare and new body.
Set the increment to 10, not 1.
Save Firmware with the same name pattern but a higher version, here GF1__123.bin.
Copy it to the root of an SD card formatted in the camera. Make sure it is the only firmware file on the card.
Fully charge the battery. Camera off, insert card, camera on, press the green Playback button.
Choose Yes on the Version Up screen and press OK.

Afterwards the language menu lists English (and the other languages).

Flashing modified firmware can brick a camera. Do it at your own risk.

HP Officejet Pro 8600 "Scan to Network Folder" always fails on Windows 10

2020-04-10T00:00:00Z

Symptoms #

The Scan to Network Folder setup wizard on an HP Officejet Pro 8600 always ended with a generic error when pointed at a share on a Windows 10 PC.

Cause #

The 8600's firmware only supports SMB 1.0 for network folders. Windows 10 ships with the SMB1 server disabled.

Fix #

Found in this HP community thread: enable the SMB1 server and reboot.

Control Panel → Programs and Features → Turn Windows features on or off → SMB 1.0/CIFS File Sharing Support → tick SMB 1.0/CIFS Server → OK, then reboot.

Caution (2026): SMB1 is obsolete and was the vector for WannaCry. Only enable it on a trusted network, ideally on a machine whose only job is receiving scans. Scan-to-email or HP's own scanning software avoid SMB entirely.

Inkscape: Path → Trace Bitmap does nothing (no preview, no error)

2020-02-13T00:00:00Z

Symptoms #

Selecting a simple black-on-transparent bitmap that was already embedded in a document and running Path → Trace Bitmap… did nothing: no preview, no error message, no outline. Plenty of people online reported the same, without a fix.

Cause #

Unknown. It seems to depend on how the image got into the document; a freshly opened copy traces fine.

Fix #

Trace the image in a separate document and paste the result back:

Delete the embedded copy of the image.
File → Open… the image file in a new window. In the import dialog choose Image DPI: From file and Image rendering mode: None (auto), then OK.
Select the image.
Path → Trace Bitmap…, tick Brightness cutoff, press Update (the preview now appears), then OK.
Ctrl+C the new path, switch to the original document, Ctrl+V.
Resize with Ctrl + a corner handle to keep proportions.

Known Good

Vertical Japanese (tategaki) OCR benchmark: dots.ocr-1.5 vs LightOnOCR-3 vs chandra-ocr-2

Symptoms #

Root cause #

Fix #

How it was found #

References #

SP Flash Tool on Linux (MT6592): S_COM_PORT_OPEN_FAIL (1013) in BROM, then "PMT changed for the ROM"

Symptoms #

Root cause #

Fix #

How it was found #

References #

Chromium window drag warps the window (xfwm4) or the cursor (KWin) on X11

Symptoms #

Root cause #

Fix #

Recovering a window that is already off-screen #

How it was found #

References #

No audio in Chrome Remote Desktop session on PipeWire: "ALSA: Couldn't open audio device: Host is down"

Symptoms #

Root cause #

1. CRD's audio variables leak into the whole session #

2. Empty values pushed into the D-Bus activation environment #

3. The CRD sink came back at 19 % volume #

Fix #

Strip the variables before dbus-launch #

Bridge the system PipeWire into CRD's FIFO #

If something must update the D-Bus activation environment, set real values #

Repairing a session that is already running #

What was verified #

How it was found #

systemd unit restarted 2 million times unnoticed: "Failed to load environment files: No such file or directory"

Symptoms #

Root cause #

Fix #

Journal cleanup: size, not time #

Removing the orphaned package #

How it was found #

References #

faster-whisper: Library libcublas.so.12 is not found or cannot be loaded (system has CUDA 13)

Symptoms #

Root cause #

Fix #

Related crash: "No clip timestamps found" with BatchedInferencePipeline #

Claude Code: auth login succeeds in the browser, then "not logged in" (~/.claude owned by root)

Symptoms #

Root cause #

Fix #

Unrelated: "claude: command not found" in some shells #

Default ACL shows #effective:--- on files an app rewrites with mode 0600 (certbot keys, Home Assistant auth)

Symptoms #

Root cause #

Fix #

References #

Black screen after restarting X: NVIDIA: Failed to initialize the NVIDIA kernel module (kernel upgraded, not rebooted)

Symptoms #

Root cause #

Fix #

Live recovery (no reboot) #

Before rebooting into the new kernel #

How it was found #

M5Stack Cardputer-ADV plays a loud constant whine over all audio (ES8311, Arduino M5Unified)

Symptoms #

Root cause #

Fix #

ESP32-S3 without PSRAM: HTTPS fetch returns 0 bytes or connect() fails "connection refused" (TLS out of memory)

Symptoms #

Root cause #

Fix #

ESP32-S3 Arduino Wi-Fi HTTP downloads crawl at about 1 KB/s

Symptoms #

Root cause #

Fix #

ESPHome device reboots every 15 minutes: "[E][api] No clients; rebooting"

Symptoms #

Root cause #

Fix #

References #

Strip the variables before `dbus-launch` #