Hi team,
Reporting two related video issues on the GL-RM10 running V1.8.2 release1. Both are triggered by HDMI link re-negotiation events (e.g., source PC display sleep/wake), and both require a device reboot to recover when self-recovery fails. I have kernel logs captured directly from the device.
Bug #1 — LT6911C driver rejects 2562x1440 misread, declares "no signal"
The LT6911C occasionally measures the incoming 2560x1440 signal as 2562x1440 — a 2-pixel horizontal active count drift, with htotal/vtotal unchanged at 2720/1481. The driver's divisibility check rejects this and declares no signal, terminating the stream.
Kernel log evidence:
[31571.419584] lt6911c 1-002b: Resolution: 2562x1440@60 fps (htotal=2720, vtotal=1481) audio: 0 realaudio: 1
[31571.419653] lt6911c 1-002b: lt6911c_rcv_supported_res: width and height must be divisible by 4
[31571.419671] m00_f_lt6911c 1-002b: lt6911c_get_timing: rcv err res, return no signal!
In this particular instance the chip self-recovered ~1.7 seconds later (re-detected as 2560x1440 cleanly), but in other instances it has gotten stuck and required a full device reboot to recover. End-user impact: HDMI output to local display goes black, remote stream drops.
Suggested fix: Rather than rejecting the entire signal when width/height isn't divisible by 4, round down to the nearest multiple of 4 and continue. A 2-pixel discrepancy is well within normal HDMI timing jitter during link re-negotiation and shouldn't cause a complete stream termination.
Bug #2 — Color space corruption (negative/scrambled palette) after re-negotiation, no self-recovery
More common symptom: after an HDMI re-negotiation event, the remote stream comes back with completely wrong colors — appears as a corrupted/inverted palette, like a photographic negative or scrambled RGB-vs-YCbCr mapping. Text is readable, signal is present, but colors are unusable. Local HDMI output to the connected monitor appears to go black during this state (per end-user reports). Always requires a device reboot to recover; never self-recovers in observed instances.
Kernel logs show repeated occurrences of:
lt6911c 1-002b: 0xD211 is ff
...correlated with the re-negotiation events. The LT6911C register dump at the time of one such event showed:
- AVI PB1 = 0x00 (source reporting RGB, correct)
- CSC mode = 0x00
- RGB→YCbCr register (0xA055) = 0xfc
- TMDS clock reading = 0x000000
- Read State = 0x5d
My suspicion is that the AVI InfoFrame is being read incorrectly after re-lock, causing the wrong color space conversion to be applied. Would appreciate the team taking a look at the LT6911C re-init / AVI InfoFrame parsing path post-link-drop.
Hardware setup:
- Source: Lenovo ThinkCentre M920q, Intel UHD Graphics 630, output: 2560x1440 @ 59Hz
- Display (KVM HDMI out): KTC H32T13 32" monitor
- EDID: was using Customize (2560x1440); custom EDID values are unfortunately cleared as soon as the Edit dialog is opened, which is a separate minor UX issue worth flagging
Frequency: Several occurrences per week, correlating with source PC display sleep/wake cycles.
Firmware: V1.8.2 release1 (RK_MODEL=RM10)
Happy to share full kernel logs, lt6911c register dumps, and the logread file with timestamps if useful — they were all exported via the device's diagnostic export function. Just let me know where to upload.
Thanks for looking at this.