# Dasung Paperlike display

FDS includes `dasungd` for the configured Dasung Paperlike 13K grayscale monitor.
The controller starts during early boot and remains supervised in the base system,
including console-only use. No GUI or ENVIRONMENT cartridge is required.

For installation, disk preparation and first power-on, start with
[Run FDS on a Raspberry Pi 5](hardware-setup.md).

The supplied profile uses the dedicated monitor's EDID and USB companion identity,
with raw mode 1 and contrast 4 as startup defaults. It is specific to that monitor;
do not use its identity as a blanket match for other CH340 USB devices.

## HDMI plus USB-C on the Pi

Use the Pi's **micro-HDMI output** for video to the monitor's HDMI input. Use a
separate **USB-A-to-USB-C data cable** from a Pi host port to the monitor for
controller access, and power the monitor with its supplied DC adapter. The
Pi's own USB-C connector is its power input; it does not output USB-C video.
See the [wiring table](hardware-setup.md#2-wire-hdmi-video-usb-control-and-power-separately),
[official Pi display guidance](https://www.raspberrypi.com/documentation/computers/getting-started.html#display),
and [DASUNG's power guidance](https://shop.dasung.com/pages/q-a).

HDMI video and USB controller access are separate checks. The daemon talks USB
regardless of the video cable, but the HDMI-plus-USB arrangement still needs to
expose the expected UART and companion bridge on this monitor. HDMI alone does
not carry the daemon's control protocol. A charge-only cable or a USB-C lead
connected only to a charger cannot provide host USB control.

The image currently supplies a firmware EDID override for 3200 × 2400 at about
37 Hz, recorded on the original workstation. DASUNG says some HDMI hosts need
27 Hz instead; that does not establish which mode the Pi and this cable will
accept. The forced profile can prevent using the monitor's native HDMI mode
list. Use the diagnostic procedure below if needed; neither Pi HDMI compatibility
nor physical power-cycle recovery is recorded as passed yet.
[Manufacturer HDMI note](https://shop.dasung.com/pages/dasung-paperlike-13k-the-worlds-first-13-3-inch-37hz-3k-e-ink-monitor).

## Inspect the controller

The controller's socket is restricted to root. Use the local `RECOVERY#` console
described in [Enter recovery](recovery.md#enter-recovery); the ordinary `FDS>`
account cannot access it. On FDS recovery:

```sh
dasungd status
dasungd query
```

`status` reports whether the monitor is connected and responsive, the age of its
last reply and cached parameters. `query` requests current values. To refresh
the display or adjust contrast:

```sh
dasungd refresh
dasungd set contrast 4
dasungd set mode 1 --save
dasungd forget mode
```

A successful set means the command was sent; use query/status to read back the
result. The grayscale model uses raw numeric modes. Saved overrides in
`/run/dasungd/settings.json` survive a daemon restart during the same boot, but
not power loss. Image configuration defaults are in `/etc/dasungd.toml`.

## Diagnose a connection problem

Inspect `/run/log/dasungd/current` and the reported status. Discovery requires
the configured DRM EDID and matching USB companion topology. An ambiguous match
is rejected. Set `usb_path` only after identifying the intended device topology.

At `RECOVERY#`, start with:

```sh
lsusb
lsusb -t
dasungd status
dasungd query
tail -80 /run/log/dasungd/current
```

The existing profile expects UART `1a86:7523` alongside SPI bridge `1a86:5512`
under the same hub. If neither appears, check monitor power, its USB data port,
the cable and the Pi host connection. If only one appears, preserve the USB tree
and log: the cable/input combination has not yet satisfied the current profile.
Do not disable companion checks or match every CH340 device to hide the failure.

`status` separates `connected` from `responsive` and includes `usb_error`,
`display_error`, `displays`, `rx_frames` and `last_rx_ms_ago`. `query` queues
requests; run `status` again after replies arrive. Keepalive packets being sent
are not themselves evidence that the monitor answered.

Capture the actual DRM connector names and EDID at `RECOVERY#`:

```sh
mkdir /tmp/dasung-hdmi
cat /proc/cmdline > /tmp/dasung-hdmi/cmdline.txt
for fds_connector in /sys/class/drm/card*-*; do
    [ -f "$fds_connector/status" ] || continue
    fds_connector_name=${fds_connector##*/}
    printf '%s: ' "$fds_connector_name"
    cat "$fds_connector/status"
    cat "$fds_connector/modes"
    cp "$fds_connector/status" "/tmp/dasung-hdmi/$fds_connector_name.status"
    cp "$fds_connector/modes" "/tmp/dasung-hdmi/$fds_connector_name.modes"
    cp "$fds_connector/edid" "/tmp/dasung-hdmi/$fds_connector_name.edid"
done
```

Use a new directory for each capture and save it before shutdown using
[machine diagnostics](internal-storage.md#save-and-retrieve-diagnostics).
An empty EDID on a disconnected connector is expected. The `modes` file lists
available resolution names, not proof of the active refresh rate or picture
quality. With `drm.edid_firmware` active, the EDID you read may be the supplied
override; capture again without it to learn what HDMI actually advertises.

The configured DRM serial is `L56051794302`. Native HDMI EDID might identify the
display differently from the recorded USB-C profile. With `require_display=true`,
an identity mismatch can leave USB control disconnected even when HDMI video
works. Retain the native EDID, USB topology and errors for a deliberate profile
update; do not silently remove identity checks. Config changes must ultimately
be rebuilt into both early boot and base/recovery images. The read-only
`/etc/dasungd.toml` is not a persistent settings editor.

## Try the monitor's own HDMI EDID

Use this when the stock forced timing gives a blank or unstable picture, or when
temporarily connecting a different HDMI display. The override currently applies
to connected DRM outputs without a connector qualifier, so attaching another
screen while retaining it is not an independent native-mode test.

Follow the offline edit procedure below. In the disk's **single-line**
`cmdline.txt`, remove only this token for the EDID experiment:

```text
drm.edid_firmware=edid/dasung-paperlike13k-37hz.bin
```

For verbose diagnosis with a USB keyboard and display console, a complete
command line based on the current production template is:

```text
console=tty1 rdinit=/init ro loglevel=7 vt.global_cursor_default=0 fds.boot=normal fds.debug=1
```

For the serial boot mode, retain `console=ttyAMA10,115200` after `console=tty1`
instead. Use `fds.boot=recovery` in place of `fds.boot=normal` when intentionally
booting recovery; never append a second conflicting `fds.boot` option. Do not add
`fds.emulator=1` on real hardware or replace stage0 with a Raspberry Pi OS
`root=…` command line.

Reboot and repeat the DRM/USB capture. Removing the override allows the monitor's
HDMI EDID to supply modes; it does **not** guarantee 27 Hz or fix missing USB
control. Record any change in picture and controller status. Restore the saved
command line to return to the shipped profile. Keep both captures so a future
HDMI profile change can be based on observed timings and identity.

### Edit the BOOT command line offline

Shut FDS down and disconnect Pi power. Connect NVMe to the Linux workstation, or
boot the separate maintenance SD and access the inactive NVMe there. Identify
the same disk by model/serial used when flashing it. Mount only its first
partition, labeled `FDS_BOOT`; FDS does not normally mount it at
`/boot/firmware` as Raspberry Pi OS does.

On that **workstation or maintenance OS**, replacing the partition path below:

```sh
lsblk -p -o NAME,MODEL,SERIAL,SIZE,TYPE,PARTLABEL,MOUNTPOINTS
sudo mkdir -p /mnt/fds-boot
sudo mount -o nosuid,nodev,noexec \
  /dev/disk/by-id/REPLACE_WITH_VERIFIED_NVME-part1 /mnt/fds-boot
sudo cp -n /mnt/fds-boot/cmdline.txt /mnt/fds-boot/cmdline.before-hardware.txt
sudoedit /mnt/fds-boot/cmdline.txt
cat /mnt/fds-boot/cmdline.txt
sudo umount /mnt/fds-boot
```

Check the identity before the mount and stop on any failed step. If the partition
was automounted, unmount that instance first. Keep `/mnt/fds-boot` dedicated to
this operation. The no-clobber copy retains an existing backup; if repeating the
experiment, inspect that backup and skip the copy step if it already exists.
Do not assume an older backup contains your latest settings. Keep `cmdline.txt`
on one line and record its final contents with the
test session. Safely disconnect the enclosure before moving NVMe back to the Pi.

To undo the edit, mount the same verified partition again, restore
`cmdline.before-hardware.txt` over `cmdline.txt`, and unmount before rebooting.
These edits change the flashed copy only; they do not change the source images
or their recorded hashes. Reflashing restores the image's original command line.

FDS uses the daemon for USB control. Its configuration disables the original
workstation-specific display hotplug procedure. Video mode and cabling are part
of the machine's boot/display configuration. The detailed protocol, build
rationale and physical display procedures are in the
[developer reference](developer/dasung.md).