When it stalls

Three failures cover most of it: no picture, nothing typed, or a key stuck down. Each has a different place to look.

No picture

• Check the frame is recent rather than merely present. A capture that has stopped still serves its last frame, and a stale frame looks exactly like a screen that has not changed.
• Confirm the target is actually outputting video. A machine asleep, or switched to another input, produces the same black frame as a broken cable.
• On the networked path, check the device's own web interface before suspecting the daemon. They are separate services on the same board.

Nothing typed

• Check what has focus. Keystrokes go wherever the target is pointing them, and a dialog that took focus silently absorbs everything sent since.
• Check the request was accepted rather than merely sent. A fire and forget channel reports success for a line the far end refused.
• If characters arrive doubled, or one character repeats, the hold is wrong for that target rather than the link being broken. See the timing section in Driving it.

A key is stuck down

Send a release. It puts every key and button up without moving the pointer. If a target is auto-repeating a character, that is a lost release rather than a repeated press, and no amount of re-sending the character will clear it.

The device is there but silent

• Address the board by a stable identity rather than a port number. Port numbering moves when a cable is replugged, and the next device to enumerate inherits the name.
• Ask the board for its status. Counters that increment prove it is playing what it was sent; they say nothing about what the target received.
• A healthy device is not a running target. The daemon can be entirely well while the machine in front of it is off.

Counters attest to transmission, not receipt. When the device says it sent everything and the screen disagrees, believe the screen.