fds-os/docs/dasung.md

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.

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, official Pi display guidance, and DASUNG's power guidance.

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.

Inspect the controller

The controller's socket is restricted to root. Use the local RECOVERY# console described in Enter recovery; the ordinary FDS> account cannot access it. On FDS recovery:

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:

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:

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#:

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. 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:

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:

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:

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.