Field report from an unattended kiosk deployment: 1 minor mouse bug, 3 requests, and 5 things that weren't Snow

[ibmmac]

Not a bug report so much as a field report. I have been running Snow as the
core of an unattended VM appliance and hit a handful of edges worth writing
down: one minor bug, three requests, and — deliberately included — five things
that looked like Snow problems and were not.

Happy to split any of this into separate issues if you would prefer.

Context

I built an unattended VM appliance around Snow: a Debian guest that boots
straight into fullscreen snowemu running a Macintosh Plus with System 6.0.8,
with SCC channel A bridged out so the Mac can dial telnet BBSes through a
tcpser Hayes modem. It works, and it dials real boards.

Snow was chosen over Mini vMac specifically because of the SCC emulation, and
the whole project rests on it. The notes below come from getting it running
headless and unattended — a use case Snow clearly wasn't primarily designed for,
so please read the requests as "here is where the edges are", not complaints.

Environment for everything below:

• Snow 1.5.0-317c188, upstream Snow.Linux.x86_64.zip
• Debian 13 (trixie), kernel 6.12.94, glibc 2.41
• Mesa 25.0.7 llvmpipe — VirtualBox guest, no 3D acceleration
• Macintosh Plus, 4 MB, System 6.0.8, one SCSI disk, one 400K floppy

---

1. Bug — already filed as #356

Workspace passed as a bare filename fails to load silently:
Path::parent() returns Some(""), canonicalize_at does
set_current_dir(""), that fails, and the load aborts with no log line. The
result is a fullscreen window with no machine in it at ~75% CPU.

Filed at #356 — not repeated here.

---

2. Bug (minor) — absolute mouse mode does not follow a warped pointer

In the default MouseMode::Absolute, moving the host pointer to a target in a
single jump moves the X pointer but does not move the emulated Mac's cursor.
Moving to the same coordinates in a series of small steps tracks exactly.

# no effect on the Mac cursor
xdotool mousemove 1145 105

# same destination, tracked precisely
for i in $(seq 1 12); do
  xdotool mousemove $((640 + i*42)) $((400 - i*25)); sleep 0.15
done

xdotool getmouselocation reports x:1144 y:103 in both cases, so the X
pointer really is at the target either way — only the stepped version reaches
the Mac.

Impact is limited to synthetic input (test harnesses, automation, remote
kiosks); a human moving a real mouse always produces a stream of small motions
and would never notice. Guessing, this may be motion being derived from
successive positions rather than taken from the event's absolute coordinates,
but I have not read the code.

---

3. Feature request — ip232 framing on the serial bridge

--serial-bridge-a tcp:PORT exposes a raw byte stream. The natural companion
for a BBS setup is tcpser, which cannot consume it directly:

• tcpser -d <device> needs a serial device, not a socket. Bridging with
  socat PTY,link=… TCP:127.0.0.1:1984 gets you a device, but tcpser then
  polls modem control lines with TIOCMGET/TIOCMSET, which a PTY does not
  implement, and exits 255 with
  FATAL:Could not obtain serial port status (Inappropriate ioctl for device).
  I patched tcpser locally to tolerate the missing ioctls.
• tcpser -v <port> is a listener and speaks ip232, with in-band escaping
  for the control lines. Snow's bridge is raw, so the two cannot be paired, and
  in any case both sides would be listening.

VICE solves this with -rsdev1ip232, which is why the equivalent Commodore
project needs no patching or socat at all. An --serial-bridge-a ip232:PORT
mode — or an outbound tcp-connect:HOST:PORT variant — would let Snow talk to
tcpser and the rest of the retro-modem ecosystem directly.

Not urgent: the socat + patch combination works and is in production here.

---

4. Feature request — serial bridges in the workspace

Workspaces persist the machine, ROMs and SCSI targets, but not serial bridge
state (documented, and consistent with what I see). For an appliance that means
the bridge must be re-specified on the command line at every launch, separately
from the workspace that defines everything else about the machine:

snowemu --fullscreen --serial-bridge-a tcp:1984 --floppy … /path/macplus.snoww

Persisting bridges in the workspace — or accepting them in init_args — would
make a workspace a complete machine description.

---

5. Feature request — headless/kiosk-friendly prompts

Two modal prompts block an unattended boot until a human answers:

1. "Save MOOF copy?" — raised for any read-only raw floppy image passed with
   --floppy, on every launch, in front of the emulated desktop.
2. (Not hit here, but the same shape) other PromptChoice settings.

These are settable — convert_to_moof_mode and writeback_mode in
~/.config/snowemu/Snow/settings.json — and I now seed that file at provision
time, which solves it. Two smaller asks:

• Document settings.json, at least the keys that matter for unattended
  use. I found them by reading frontend_egui/src/settings.rs.
• A CLI equivalent, e.g. --no-prompts or --writeback never, so a kiosk
  does not depend on seeding a config file that Snow rewrites in full on exit
  (editing it while Snow is running silently loses the change).

---

6. Considered and excluded

Recording these so the report is not mistaken for a list of Snow defects.

Symptom	Actually
Pointer and keyboard input mostly ignored over a remote console	VirtualBox VRDE, not Snow. It delivers roughly the first input event after a client connects, then stops, while serving video perfectly. Reading the guest's /dev/input/eventN during RDP clicks returned 0 bytes. Injecting into the guest's own X server works perfectly
--mouse usbtablet on the VM did not help	VirtualBox again — the guest enumerates the tablet and libinput binds it, but VRDE delivers no events to it
Clicks needed a ~400 ms hold to register	Faithful emulation. An instantaneous press/release is shorter than the VIA's sampling interval. A real mouse cannot produce one
MouseMode::RelativeHw unusable for automation	Working as designed — it only signals relative movement, which is the point. Correct for games; wrong for synthetic input
Cmd+W never closed a Finder window	My error. System 6's Finder has no ⌘W — Close is menu-only; ⌘W arrived in System 7. Snow was correct. Verified by opening the File menu on the emulated machine

---

7. Things that went right, unprompted

Worth saying, since bug reports are a biased sample:

• The prebuilt Linux binary just worked on a distro it was not built on.
  glibc 2.39 requirement against trixie's 2.41, everything dlopen'd resolved
  cleanly once the X11/GL/xkbcommon/dbus packages were present.
• ROM validation by sha256 against the table in core/src/mac/mod.rs is
  exactly right, and let me assert the same value at build time so a bad ROM
  fails the ISO build instead of producing a dialog box on a headless VM.
• Rendering through llvmpipe at 512×342 is completely fine — no 3D
  acceleration needed for a compact Mac, which makes Snow unusually easy to
  deploy in a VM.
• The workspace format being plain JSON with #[serde(default)] meant I
  could generate one from a provisioning script rather than baking it by hand in
  the GUI. That is a genuinely nice property and I would not want it to change.
• The SCC emulation is accurate enough that a 1986 copy of MacTerminal dialled
  out through it at 19200 and got a clean carrier.