restore_backup copied the backup's config.json over the local one wholesale,
display.hardware included. That block is not configuration in the portable
sense -- it describes the panel physically wired to this machine: cols, rows,
chain_length, hardware_mapping, panel_type, multiplexing, and the refresh-rate
cap.
So restoring a backup taken on a 512x64 rig onto a 128x32 one repointed the
smaller panel at the larger one's geometry. Nothing on screen explains that;
the display simply stops being right, and the setting that broke it is one the
user never touched.
display.hardware is now held back by default and the rest of config.json is
restored as before. RestoreOptions.restore_hardware opts into the old
behaviour for the case it actually suits -- restoring onto identical hardware,
or onto a replacement for the machine the backup came from. When the two
differ, the kept geometry and the discarded one are both logged, so the choice
is visible afterwards.
A device with no local display.hardware takes the backup's, since there is
nothing to preserve. An unparseable file on either side falls back to the
plain copy: a restore must not fail because of this merge.
Reverting the guard fails the test that the local panel survives. 40 backup
and restore tests pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01STMbQE4YctTacQXfbYqKuW
