Skip to content

diagnosis.md

Latest commit

 

History

History
80 lines (59 loc) · 3.26 KB

diagnosis.md

File metadata and controls

80 lines (59 loc) · 3.26 KB
Raw

Diagnosis and evidence

Protocol symptom

The failing connection used Miracast over Infrastructure rather than Wi-Fi Direct. The Windows source opened the MICE control connection, completed the initial RTSP OPTIONS exchange, requested the receiver capabilities in M3, and received a successful response. It then closed the session before M4 without a protocol error.

The receiver had advertised video/audio capabilities correctly. The remaining field that changed between working and failing display configurations was wfd_display_edid.

Cross-tests

The following controls localized the problem to the Pocket 4 receiver's internal-display path:

  • two independent Windows source PCs failed against the Pocket 4 receiver;
  • both source PCs worked against another Windows Wireless Display receiver;
  • the same Pocket 4 worked as a Miracast source;
  • the Pocket 4 worked as a receiver when an external Samsung display was active;
  • the Pocket 4 failed again when only the internal panel was active.

Network, source encoder, Wi-Fi Direct, VPN, firewall, and source graphics-driver hypotheses were therefore rejected.

Original internal-panel EDID

The affected HSX0324 / YHB03P24 panel exposed 384 bytes:

  • the base block declared one extension;
  • block 1 was a DisplayID extension;
  • block 2 was an all-zero padding page;
  • Windows Wireless Display advertised all three physical pages.

Additional offline decoding showed that merely repairing the padding/count mismatch was insufficient. The genuine blocks also contained:

  • a base detailed timing with a 10 kHz pixel clock and zero horizontal/vertical blanking;
  • an invalid manufacture-week value;
  • range limits that contradicted the genuine high-resolution timings;
  • a DisplayID container declared as an extension section but missing the product-identification, display-parameters, and interface-feature blocks required to describe the panel independently.

The genuine DisplayID timing records themselves were retained:

  • 1600x2560 at approximately 144 Hz;
  • 1600x2560 at approximately 60 Hz.

Windows rotates the portrait-native panel to a 2560x1600 desktop.

Experiments

  1. A three-block override corrected the extension count and replaced the zero page with a valid empty CTA block. Packet capture proved that Wireless Display advertised the override byte-for-byte, but the source still stopped before M4.
  2. A two-block override attempted to expose only the base and DisplayID blocks. Windows rematerialized the physical 384-byte buffer after restart, so the verification gate stopped the experiment before casting.
  3. A conformant compatibility EDID replaced the invalid base timing, removed contradictory metadata, completed the DisplayID/CTA descriptions, and kept both real panel timings byte-for-byte. edid-decode reported conformity PASS with no structural failures.

Confirmed result

After installing the compatibility override and restarting:

  • Windows materialized the exact expected fixed SHA-256;
  • the internal desktop remained visible;
  • 2560x1600 at both 60 Hz and 144 Hz remained available;
  • the previously failing source connected and stayed connected.

This same-machine before/after result confirms malformed/incomplete internal panel EDID metadata as the session-setup interoperability failure.