Skip to content

**Title:** No video output on BIOS/UEFI POST screen; Linux console (no GUI) shows no image; resolution stuck at 1024x768 after OS boot #152

Open
Open
**Title:** No video output on BIOS/UEFI POST screen; Linux console (no GUI) shows no image; resolution stuck at 1024x768 after OS boot#152

Description

@miharoot
miharoot
opened on Sep 13, 2026

Description:

When using NanoKVM-Pro, video output is broken or severely limited at multiple stages of the host machine's boot/runtime:

  1. BIOS/UEFI POST screen: No image is displayed at all during POST/BIOS. The video feed only starts once something further along in the boot process loads.
  2. Linux text console (no GUI/X server running): When the host is running Linux without a graphical environment (plain TTY/console), no image is shown either. Video only appears once a graphical desktop environment is loaded.
  3. After OS boot (with GUI): Once a graphical session does load, the resolution is stuck at 1024x768, regardless of the host's actual display configuration or capabilities.

Taken together, this means NanoKVM-Pro only reliably shows video once a full graphical desktop is up and running — it fails during exactly the stages where remote KVM access is most needed: BIOS setup, boot menu, recovery/rescue console, headless server text consoles, etc.

Steps to reproduce:

  1. Connect NanoKVM-Pro to the target PC via HDMI
  2. Power on the target PC
  3. Observe the NanoKVM-Pro web interface during:
    • POST/BIOS screen → no image
    • Linux boot to text console/TTY (no GUI) → no image
    • Linux boot to graphical desktop → image appears, but capped at 1024x768

Expected behavior:

  • Video should be captured and displayed starting from BIOS/UEFI POST.
  • Video should be captured from a plain text console (no GUI required).
  • Resolution after boot should match (or allow configuring) the host's actual output resolution, not be hardcoded/limited to 1024x768.

Actual behavior:
As described above — no signal until a full GUI is running, and then resolution is capped at 1024x768. The core problem (no image during BIOS) is present regardless of OS or environment.

Environment:

  • NanoKVM-Pro firmware version: v1.0.15 (latest as of this report)
  • Host PC / motherboard: Gigabyte B550 (AMD Ryzen 5 5600 platform)
  • GPU: NVIDIA GeForce GT 730 (discrete)
  • Linux distro/kernel (for the console test): Debian 13 — but the main issue is that it doesn't work at the BIOS level, before any OS loads
  • HDMI cable/adapter used: tried both direct connection and through an HDMI splitter
  • Browser used for web UI: Chrome
  • Connection type: LAN

Additional notes:
No image at all during BIOS/POST, regardless of cabling (direct or via splitter). This is not GPU- or OS-specific — the failure occurs before any OS is even involved.

On project maintenance:

I want to flag this directly: these are fundamental issues that strike at the core use case of a KVM device — capturing video regardless of what's running on the host, including BIOS and plain text consoles. This isn't a new-feature request, it's basic functionality not working. Looking at the state of the issue tracker, the project seems effectively abandoned — not just in terms of new features, but even basic bug fixes for things that plainly don't work. Issues pile up without maintainer response, and problems like these undermine the entire premise of the product.

If the project is still actively maintained, some visibility into the status of these issues — or at least acknowledgment — would go a long way. If it isn't maintained anymore, it would help the community to say so clearly, so people can decide whether to keep relying on this device or look elsewhere.

Activity

  1. miharoot commented on Oct 2, 2026

    @miharoot
    miharoot
    on Oct 2, 2026
    Author

    Related: #93, #152

    Overview

    My server (NVIDIA GeForce 210 / GT218, HDMI output) shows no picture in the NanoKVM-Pro during POST/BIOS, GRUB and the Linux text console. To find out why, I recorded the capture chip state while the server booted, then repeated the test with a Windows laptop, different HDMI cables, an HDMI splitter and two EDID profiles.

    Result: the LT6911UXC can lock with correct timings (1920x1080@60, 1280x1024@60), but the lock is lost after 0.4 s to 109 s with every source and every setup. Re-locks very often report corrupted timings, e.g. 1920 x 57, VTotal 58, FPS 1163. Every lock tagged resolution type: 3 is corrupted. With the GT210 connected directly, the chip never locks at all.

    Environment
    Device NanoKVM-Pro ATX-A, powered separately from the server
    App / firmware 1.2.15 (kvmcomm 1.2.15, pikvm 1.2.15)
    KVM kernel 4.19.125 (Ubuntu 22.04.5)
    Capture chip LT6911UXC (lt6911_manage, ax_mipi_rx)
    Server NVIDIA GeForce 210 (GT218) 10de:0a65, HDMI out; legacy VGA text console (Console: colour VGA+ 80x25), no KMS driver loaded
    Laptop Lenovo T16 Windows, HDMI out (1080p60 to the KVM)
    Cables several different HDMI cables tried
    EDID profiles E54-1080P60FPS and E58-4K16-10

    How the logs were collected

    The logs come from a read-only shell script running on the KVM:

    • it never writes to /proc, never changes EDID or HDMI settings, and never restarts services;
    • it opens only the read-only files in /proc/lt6911_info plus the files the NanoKVM server itself reads;
    • every second it records changes of width, height, fps and hdmi_rx_status, plus every new kernel message.

    Line format: [wall clock | +seconds since start | KVM uptime] event. The KVM uptime equals the dmesg timestamps. In the excerpts below, static fields are trimmed and rx means hdmi_rx_status. Lock tables are built from the driver's dmesg lines: HDMI signal is stable → HDMI signal has disappeared. A lock counts as "correct" only if both resolution and HTotal/VTotal match the expected mode: 1920x1080 2200/1125, or 1280x1024 1688/1066.

    The full logs (8 runs) are attached. Personal data is redacted: hostname suffix, UTC offset, device-number field.

    Run 1 — 10:48 — server GT210, direct HDMI, EDID E58

    The server was powered on a few seconds after recording started and booted through POST, GRUB and the Linux console. This run used an older version of the script with no hdmi_rx_status and no live dmesg. width/height stayed 0x0 for all 240 s; the chip never reported a resolution.

    Log excerpt (run 1) 
    res=0x0 or res=?x? means the chip reports no signal / cannot read it.
Type a note + Enter at any time to add a timestamped MARKER (e.g. 'host powered on').
[10:48:04 +   0s] res=0x0 fps=0 capture=on hdmi_power=on loopout=off edid_byte12=58
[10:48:35 +  30s] (unchanged for 30s)
[10:49:04 +  60s] (unchanged for 30s)
[10:49:34 +  90s] (unchanged for 30s)
[10:50:05 + 121s] (unchanged for 30s)
[10:50:35 + 151s] (unchanged for 30s)
[10:51:05 + 181s] (unchanged for 30s)
[10:51:35 + 211s] (unchanged for 30s)


state changes seen:        0
first non-zero resolution: NEVER (chip never reported a resolution during the watch)
last state:                res=0x0 fps=0 capture=on hdmi_power=on loopout=off edid_byte12=58

    Run 2 — 12:18 — snapshot after switching EDID to E54

    This is a single snapshot taken after switching the EDID profile to E54; the chip reported 0x0 at that moment. It is useful for the side bug: dmesg shows a valid EDID written to the chip (00 ff ff ff ff ff ff 00 4e 04 ..., correct checksums), but /proc/lt6911_info/edid_snapshot starts with "unknown\n\0". Exactly bytes 0–8 are overwritten; the rest is identical.

    Log excerpt (run 2) 
    [ 4798.270651] Writing EDID: 00 ff ff ff ff ff ff 00 4e 04 01 33 36 00 00 00 28 23 01 03 80 00 00 00 0a e5 b5 a3 55 49 ...
[ 4798.272901] Writing EDID...
[ 4798.808249] EDID write completed
[ 4798.826464] Restarting LT6911UXC...

edid_snapshot (first 32 bytes):
 75 6e 6b 6e 6f 77 6e 0a 00 04 01 33 36 00 00 00
 28 23 01 03 80 00 00 00 0a e5 b5 a3 55 49 99 27
header valid:      no
checksum:          BAD (sum%256=210)

    Run 3 — 12:33 — server GT210, direct HDMI, EDID E54, server powered on at ~+10 s

    • While the server is off, rx is extract. At +11 s, when the server is switched on, rx becomes access.
    • From then on rx cycles access (~4.3 s) / extract (~2.1 s) for the whole 300 s: 92 changes through POST, GRUB and the Linux console.
    • There was no lock at all: 0x0 throughout, and not a single HDMI signal line in dmesg.
    Log excerpt (run 3) 
    [12:33:45 | +  0s |  7810.57] CHIP res=0x0 fps=0 rx=extract
[12:33:56 | + 11s |  7821.23] CHIP res=0x0 fps=0 rx=access
[12:34:00 | + 15s |  7825.24] CHIP res=0x0 fps=0 rx=extract
[12:34:01 | + 16s |  7826.56] CHIP res=0x0 fps=0 rx=access
[12:34:07 | + 22s |  7831.93] CHIP res=0x0 fps=0 rx=extract
[12:34:08 | + 23s |  7833.27] CHIP res=0x0 fps=0 rx=access
[12:34:14 | + 29s |  7838.65] CHIP res=0x0 fps=0 rx=extract
[12:34:15 | + 30s |  7839.96] CHIP res=0x0 fps=0 rx=access
[12:34:19 | + 34s |  7844.02] CHIP res=0x0 fps=0 rx=extract
[12:34:22 | + 37s |  7846.67] CHIP res=0x0 fps=0 rx=access
[12:34:26 | + 41s |  7850.67] CHIP res=0x0 fps=0 rx=extract
[12:34:28 | + 43s |  7853.34] CHIP res=0x0 fps=0 rx=access
[12:34:32 | + 47s |  7857.34] CHIP res=0x0 fps=0 rx=extract
[12:34:35 | + 50s |  7860.10] CHIP res=0x0 fps=0 rx=access
... (78 more state changes, same pattern)

run length:                 301 s (KVM uptime 7810.29 -> 8111.24)
chip state changes:         91
first non-zero resolution:  NEVER - chip reported no resolution during the whole run
resolutions seen:            none
hdmi_rx_status values seen (first time):
  +0s  extract
  +11s  access
kernel messages during run: 0

    Run 4 — 13:07 — Windows laptop, direct HDMI, EDID E58 (KVM freshly rebooted)

    • Shortly after the KVM booted, before recording started, the driver locked a correct 1080p60 (HTotal 2200, VTotal 1125, FPS 59).
    • The lock held for 7.5 s, then HDMI signal has disappeared.
    • Re-locks were short and partly corrupted: 6 locks in total, 3 of them with corrupted timings, e.g. 2116 x 1, HTotal 65534, VTotal 0, 1920 x 35, FPS 1730, and 1920 x 1080, HTotal 65534, FPS 3 (tagged type 0).
    • During recording rx cycled access (~13 s) / extract (~2 s) with no lock.
    • The laptop screen kept blinking, as if the display were being re-plugged.
    Log excerpt (run 4) 
    Raw dmesg of the first lock:
[   17.351671] HDMI signal state: 0x03
[   17.351677] HDMI signal is stable
[   17.352203] Detected HDMI resolution type: 1
[   17.352208] HDMI resolution: 1920 x 1080
[   17.352930] HDMI HTotal: 2200, VTotal: 1125
[   17.420253] HDMI FPS: 59
[   24.860046] HDMI signal state: 0x02
[   24.860057] HDMI signal has disappeared

All locks:
uptime(s)  held(s)  resolution   type  HTotal/VTotal  FPS   monitoring
---------  -------  -----------  ----  -------------  ----  ----------
     17.4      7.5  1920x1080       1  2200/1125      59    off
     44.6      3.3  1920x1080       0  2200/1125      59    off
     50.3      0.4  2116x1          3  65534/0        0     off
     52.2      2.7  1920x1080       0  2200/1125      59    off
     56.5      0.5  1920x35         3  2200/39        1730  off
     58.5      0.6  1920x1080       0  65534/1125     3     off

Recording:
[13:07:26 | +  0s |   149.02] CHIP res=0x0 fps=0 rx=extract
[13:07:46 | + 20s |   168.71] CHIP res=0x0 fps=0 rx=access
[13:07:59 | + 33s |   181.99] CHIP res=0x0 fps=0 rx=extract
[13:08:02 | + 36s |   184.62] CHIP res=0x0 fps=0 rx=access
[13:08:15 | + 49s |   197.65] CHIP res=0x0 fps=0 rx=extract
[13:08:16 | + 50s |   198.95] CHIP res=0x0 fps=0 rx=access
[13:08:30 | + 64s |   212.26] CHIP res=0x0 fps=0 rx=extract
[13:08:32 | + 66s |   214.87] CHIP res=0x0 fps=0 rx=access
... (11 more state changes, same pattern)

run length:                 301 s (KVM uptime 148.76 -> 449.70)
chip state changes:         18
first non-zero resolution:  NEVER - chip reported no resolution during the whole run
resolutions seen:            none
hdmi_rx_status values seen (first time):
  +0s  extract
  +20s  access
kernel messages during run: 0

    Run 5 — 13:21 — source not recorded, direct HDMI, EDID E54 (KVM freshly rebooted)

    • rx cycled access/extract for the whole run: first ~13 s / ~2 s, from about +245 s ~4 s / ~2 s.
    • There was no lock, and no HDMI signal lines since the KVM booted.
    Log excerpt (run 5) 
    [13:21:28 | +  0s |    71.51] CHIP res=0x0 fps=0 rx=extract
[13:21:30 | +  2s |    72.83] CHIP res=0x0 fps=0 rx=access
[13:21:34 | +  6s |    76.78] CHIP res=0x0 fps=0 rx=extract
[13:21:36 | +  8s |    79.36] CHIP res=0x0 fps=0 rx=access
[13:21:39 | + 11s |    82.11] CHIP res=0x0 fps=0 rx=extract
[13:22:02 | + 34s |   105.56] CHIP res=0x0 fps=0 rx=access
[13:22:14 | + 46s |   117.33] CHIP res=0x0 fps=0 rx=extract
[13:22:17 | + 49s |   119.94] CHIP res=0x0 fps=0 rx=access
[13:22:30 | + 62s |   133.17] CHIP res=0x0 fps=0 rx=extract
[13:22:33 | + 65s |   135.85] CHIP res=0x0 fps=0 rx=access
[13:22:44 | + 76s |   147.54] CHIP res=0x0 fps=0 rx=extract
[13:22:47 | + 79s |   150.13] CHIP res=0x0 fps=0 rx=access
... (39 more state changes, same pattern)

run length:                 301 s (KVM uptime 71.23 -> 372.54)
chip state changes:         50
first non-zero resolution:  NEVER - chip reported no resolution during the whole run
resolutions seen:            none
hdmi_rx_status values seen (first time):
  +0s  extract
  +1s  access
kernel messages during run: 0

    Run 6 — 13:42 — Windows laptop, direct HDMI, EDID E58; HDMI splitter + 1280x1024 monitor added at ~+233 s

    • The best result so far: the driver locked a correct 1080p60 13 s after KVM boot and held it for 109 s. At the start of recording /proc showed 1920x1080.
    • The lock dropped 7 s after recording started.
    • After that, re-locks lasted only 0.4–4.7 s, and between them came corrupted timings: 1920 x 232, VTotal 233, FPS 289; 1920 x 57; 1920 x 92, HTotal 65534; 1920 x 816.
    • After the splitter was added: a correct 1280 x 1024, HTotal 1688, VTotal 1066 held for 3.3 s, then 1280 x 22, FPS 2781.
    Log excerpt (run 6) 
    Chip state at start of recording:
  width:           1920
  height:          1080
  fps:             59
  hdmi_rx_status:  access

All locks:
uptime(s)  held(s)  resolution   type  HTotal/VTotal  FPS   monitoring
---------  -------  -----------  ----  -------------  ----  ----------
     13.2    109.3  1920x1080       1  2200/1125      59    off
    194.5      4.7  1920x1080       0  2200/1125      59    running
    203.4      0.4  1920x232        3  2200/233       289   running
    205.6      0.4  1920x57         3  2200/58        1163  running
    208.4      1.6  1920x1080       0  2200/1125      59    running
    211.6      0.4  1920x92         3  65534/133      17    running
    214.2      0.4  1920x48         3  65534/53       42    running
    217.0      0.4  1920x1080       0  2200/1125      59    running
    221.0      0.6  1920x1080       0  2200/1125      59    running
    223.9      0.4  1920x816        3  2200/819       82    running
    225.7      1.3  1920x1080       0  2200/1125      59    running
    347.2      3.3  1280x1024       1  1688/1066      60    running
    352.9      0.5  1280x22         3  1688/23        2781  running

run length:                 301 s (KVM uptime 115.18 -> 416.56)
chip state changes:         39
first non-zero resolution:  +0s (uptime 115.49): res=1920x1080
resolutions seen:            res=1920x1080 res=1920x232 res=1280x1024
hdmi_rx_status values seen (first time):
  +0s  access
  +12s  extract
kernel messages during run: 110

    Run 7 — 13:49 — Windows laptop via HDMI splitter (+1280x1024 monitor), EDID E58, same KVM session as run 6

    • Between runs 6 and 7 nothing was polling, and dmesg still shows the problem: a correct 1280x1024@60 lock held 53.5 s and then dropped, followed by more drops at 495, 501, 505 and 511 s.
      So the drops are not caused by the monitoring script.
    • During recording: 20 locks. The longest correct ones held 25.8 s and 14.4 s; 7 locks had corrupted timings, e.g. 4 x 1, 6 x 5, 1280 x 0, 1280 x 310.
    Log excerpt (run 7) 
    Locks from the end of run 6 onward ("monitoring off" = no script running):
uptime(s)  held(s)  resolution   type  HTotal/VTotal  FPS   monitoring
---------  -------  -----------  ----  -------------  ----  ----------
    427.8     53.5  1280x1024       0  1688/1066      60    off
    489.4      6.0  1280x1024       0  1688/1066      60    off
    497.9      3.7  1280x1024       0  1688/1066      60    off
    503.1      2.3  1280x1024       0  1688/1066      60    off
    506.9      4.1  1280x1024       0  1688/1066      60    off
    512.5     25.8  1280x1024       0  1688/1066      60    running
    539.9      0.5  1280x1024       0  1688/1066      60    running
    543.7      1.8  1280x1024       0  1688/1066      60    running
    549.5      0.4  1280x310        3  65534/351      4     running
    558.8      0.7  1280x1024       0  1688/1066      60    running
    561.8      0.4  1280x666        3  1688/667       95    running
    564.3      1.4  1280x1024       0  1688/1066      60    running
    568.4      1.7  1280x1024       0  1688/1066      60    running
    576.9      1.3  4x1             3  1570/0         0     running
    579.8      0.4  6x5             3  124/0          0     running
    582.5      1.2  1280x1024       0  1688/1066      60    running
    585.4      0.4  1280x1024       0  65534/1066     1     running
    588.2      0.6  1280x1024       0  1688/1066      60    running
    592.1      0.4  1280x211        3  65534/213      7     running
    594.9      0.4  1280x0          3  1688/1         63978  running
    598.9      2.9  1280x1024       0  1688/1066      60    running
    604.3     14.4  1280x1024       0  1688/1066      60    running
    620.3      3.1  1280x1024       0  1688/1066      60    running
    625.0      4.3  1280x1024       0  1688/1066      60    running
    631.7      2.3  1280x1024       0  1688/1066      60    running

run length:                 300 s (KVM uptime 512.32 -> 812.84)
chip state changes:         77
first non-zero resolution:  +1s (uptime 514.41): res=1280x1024
resolutions seen:            res=1280x1024 res=4x1
hdmi_rx_status values seen (first time):
  +0s  access
  +126s  extract
kernel messages during run: 187

    Run 8 — 14:06 — server GT210 via HDMI splitter (+1280x1024 monitor), EDID E54

    • The first time the GT210 signal was ever captured. A picture appeared in the web UI. The GT210 output 1280 x 1024, HTotal 1688, VTotal 1066, the monitor's mode via the splitter. The first lock came 16 s after KVM boot and held 19.6 s.
    • It is still unstable: 56 locks in ~350 s. 22 were correct (average 2.5 s, maximum 19.6 s); 34 had corrupted timings, e.g. 42180 x 197, 61512 x 4, 1280 x 28, HTotal 65534.
    • During the 300 s of recording, /proc showed 1280x1024 for only ~41 s.
    • Unlike the direct connections, rx stayed access the whole time with no access/extract cycling, yet the video lock was still lost repeatedly.
    Log excerpt (run 8) 
    All locks:
uptime(s)  held(s)  resolution   type  HTotal/VTotal  FPS   monitoring
---------  -------  -----------  ----  -------------  ----  ----------
     16.3     19.6  1280x1024       1  1688/1066      60    off
     41.8      0.8  1280x1024       0  1688/1066      60    off
     45.1      2.4  1280x1024       0  1688/1066      60    off
     49.0      1.0  1280x1024       0  1688/1066      60    off
     51.5      3.2  1280x1025       3  1688/1066      60    off
     61.3      0.7  1280x1024       0  1688/1066      60    off
     66.2      0.4  1280x254        3  1688/295       216   off
     68.2      1.2  42180x197       3  65534/197      0     running
     70.9      0.4  1280x1024       0  1688/1066      60    running
     73.7      0.5  1280x1024       0  1688/1066      60    running
     76.6      0.4  1280x59         3  65534/60       27    running
     92.6      0.4  1280x1026       3  65534/1066     1     running
     98.0      1.3  1280x657        3  1688/656       97    running
    100.9      0.4  1280x463        3  1688/464       137   running
    107.7      0.4  1280x363        3  1688/365       175   running
    111.5      0.5  1280x0          3  1688/1066      74    running
    117.1      1.3  3232x473        3  65534/474      3     running
    120.0      1.3  1280x342        3  1688/340       188   running
    122.8      4.1  1280x1024       0  1688/1066      60    running
    128.5      1.4  1280x1024       0  1688/1066      60    running
    134.0      1.3  1280x2          3  65534/1        1647  running
    136.9      1.5  1280x1024       0  1688/1066      60    running
    139.9      1.1  1280x1024       0  1688/1066      60    running
    142.6      1.2  1280x76         3  1688/75        853   running
    145.4      1.5  1280x1024       0  1688/1066      60    running
    147.4      1.0  0x0             3  0/0            0     running
    150.1      1.1  1280x1024       0  1688/1066      60    running
    154.9      0.4  1280x261        3  1688/263       243   running
    156.9      0.7  1278x1024       3  1688/1066      60    running
    162.3      4.1  1280x1024       0  1688/1066      60    running
    209.0      0.4  1280x569        3  65534/610      2     running
    224.6      0.4  1280x1024       0  1688/1066      60    running
    226.6      0.5  1280x965        3  1688/967       66    running
    237.1      1.6  1280x1024       0  1688/1066      60    running
    240.3      1.1  1280x742        3  1688/743       86    running
    254.9      0.4  1278x249        3  1688/290       220   running
    257.7      0.4  1280x1024       0  1688/1066      60    running
    260.5      1.1  4x1             3  20/0           0     running
    265.0      0.8  1280x0          3  1688/254       251   running
    267.3      1.3  1280x1024       0  1688/1066      60    running
    270.2      1.3  1280x9          3  1688/9         7108  running
    278.4      1.3  4x1             3  88/0           0     running
    285.1      2.8  3096x108        3  65534/109      15    running
    294.7      1.4  1280x6          3  1688/47        1361  running
    297.5      1.3  1280x1025       3  1688/1066      60    running
    301.6      1.5  1280x1024       0  1688/1066      60    running
    303.5      1.1  0x0             3  0/0            0     running
    316.7      1.7  1280x162        3  65534/203      8     running
    318.7      0.9  0x0             3  0/0            0     running
    323.2      0.5  1280x1024       0  1688/1066      60    running
    330.6      1.0  1280x109        3  1688/110       581   running
    333.3      1.4  1280x1024       0  1688/1066      60    running
    342.6      6.6  1280x1024       0  1688/1066      60    running
    357.3      0.4  1280x802        3  1688/804       79    running
    362.8      1.3  61512x4         3  65534/0        0     running
    365.7      1.2  1278x928        3  1688/930       68    running

run length:                 301 s (KVM uptime 67.52 -> 368.63)
chip state changes:         67
first non-zero resolution:  +1s (uptime 69.17): res=42180x197
resolutions seen:            res=42180x197 res=1280x657 res=3232x473 res=1280x342 res=1280x1024 res=1280x2 res=1280x76 res=1280x261 res=1280x28 res=1280x742 res=4x1 res=1280x0 res=1280x9 res=3096x108 res=1280x6 res=1280x1025 res=1280x162 res=1280x109 res=61512x4 res=1278x928
hdmi_rx_status values seen (first time):
  +0s  access
kernel messages during run: 464

    Side bug: edid_snapshot corrupts the first 9 bytes

    /proc/lt6911_info/edid_snapshot always starts with 75 6e 6b 6e 6f 77 6e 0a 00 ("unknown\n\0") instead of 00 ff ff ff ff ff ff 00 4e. This was seen in all runs with both E54 and E58. The rest of the 256 bytes matches the profile file and the Writing EDID: dmesg line, so the EDID sent to the chip is fine; only the snapshot output is wrong. The web UI is not affected, because it reads only byte 12.

    Summary

    1. The capture is unstable with every source and every setup.
      • It was reproduced with two different sources (GT210 server, Windows laptop), several HDMI cables, direct connection and splitter, EDID E54 and E58, and with and without monitoring.
      • The chip can lock with correct timings (1920x1080@60 2200/1125; 1280x1024@60 1688/1066), but every lock is lost after 0.4–109 s.
    2. Re-locks often report corrupted timings (e.g. HTotal 65534, VTotal 0, FPS 1163/2781), which suggests the receiver measures unstable or corrupted sync.
      • All 48 locks tagged resolution type: 3 were corrupted.
      • 2 of the 52 type 0/1 locks were corrupted as well.
    3. The GT210 is never captured when connected directly. In POST, GRUB and the Linux text console there is not a single HDMI signal is stable (runs 1 and 3). This is the original symptom from No video input from HDMI when in UEFI/BIOS #93/**Title:** No video output on BIOS/UEFI POST screen; Linux console (no GUI) shows no image; resolution stuck at 1024x768 after OS boot #152. Via a splitter the GT210 locks at 1280x1024 but drops the same way as the laptop (run 8).
    4. hdmi_rx_status behaves differently by connection. With a direct connection it cycles access/extract endlessly once the source is on, and a Windows laptop reacts by blinking its screen. Via the splitter it stays access, but the lock is still lost.
    5. The driver logs nothing during the access/extract cycling. In runs 3 and 5 there are no dmesg lines at all.
    6. Side bug: edid_snapshot overwrites its first 9 bytes with "unknown\n\0".

    Conclusion: everything outside the KVM was varied and ruled out, so the problem appears to be on the device side: the HDMI input / LT6911UXC, its firmware, or lt6911_manage.

    Questions:

    • Is this a known hardware issue? Should the unit be replaced?
    • How can I read or update the LT6911UXC firmware version?
    • Is there a debug or verbose mode for lt6911_manage that would help diagnose the lock loss?

  2. miharoot commented on Oct 2, 2026

    @miharoot
    miharoot
    on Oct 2, 2026
    Author

    Question: sources for the closed components involved in HDMI capture

    While debugging unstable HDMI capture (see the linked issue), I found that the parts responsible for capture are not in this repository:

    1. libkvm. server/build.sh builds dl_lib/libkvm.so from server/dl_lib/kvmimpl.cpp, which contains only stubs. They print "Please compile the implementation from support/libkvm directory", but support/libkvm does not exist in the repo.
    2. lt6911_manage kernel module, which provides /proc/lt6911_info/* and handles signal detection ("HDMI signal is stable/has disappeared"). It is only mentioned in support/tools/version_fix/version_fix.c.
    3. kvmcomm service, which reads /proc/lt6911_info/{status,hdmi_rx_status,fps}. It is referenced from the server code (/kvmcomm/...).
    4. Kernel sources of the shipped image (4.19.125, built May 29 2026).

    Questions:

    • Are there plans to publish the sources of libkvm, lt6911_manage and kvmcomm? If yes, where and when?
    • Where can I get the kernel sources / BSP for the current firmware image?
    • If the sources cannot be published, could you document the /proc/lt6911_info interface? In particular:
      • the meaning of hdmi_rx_status values (access/extract);
      • the meaning of status, hdmi_tx_status and asr;
      • whether reading these files triggers I2C transactions with the LT6911UXC.
    • Is there a debug/verbose mode in lt6911_manage (module parameter or /proc switch) for diagnosing lock loss?
    • How can I read the LT6911UXC firmware version, and is there an official way to update it?

    These would let me (and others ) debug the capture problem further instead of guessing from the outside.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions