Hello GL.iNet team,
I am reporting a reproducible/intermittent black screen issue seen from the GLKVM desktop application on Windows (Desktop App v1.4.0 release 2).
Important point: at first I suspected the desktop application itself, but after reviewing the KVM logs, the device-side logs suggest that the KVM is actually losing video signal momentarily and then reinitializing the capture pipeline.
Device / environment
- Model: GL.iNet Comet Pro GL-RM10.
- Firmware: V1.8.0 release4.
- Kernel: Linux 6.1.118 aarch64.
- Main device log available at: /var/log/kvmd.log.
- The desktop client identifies itself in kvmd as: gl-kvm/1.4.0 Chrome/132.0.6834.210 Electron/34.5.8 Safari/537.36.
Symptom
- From the desktop app, the screen occasionally turns black.
- I am not the only one seeing this; another user I know is experiencing the same issue with the desktop app.
- The problem appears intermittent rather than a permanent failure.
Why I think this is not only a desktop-app rendering issue
At the exact time of the black-screen event, /var/log/kvmd.log shows the local video pipeline reporting signal loss and reinitializing itself:
2026-05-07 07:22:20,667 - kvmd.apps.kvmd.streamer - INFO - => -- ERROR [0.000 tid=3766] -- get VENC data failed 1 times a004800e
2026-05-07 07:22:20,677 - kvmd.apps.kvmd.streamer - INFO - => -- INFO [0.000 tid=3787] -- resolution: no signal, deinit rv1126 encoder
2026-05-07 07:22:20,678 - kvmd.apps.kvmd.streamer - INFO - => -- INFO [0.000 tid=3787] -- Stopping VO deal thread
2026-05-07 07:22:20,771 - kvmd.apps.kvmd.streamer - INFO - => -- INFO [0.000 tid=3787] -- Stopping MJPEG fetch thread
...
2026-05-07 07:22:21,946 - kvmd.apps.kvmd.streamer - INFO - => -- INFO [0.000 tid=3787] -- resolution: change to 1920x1080@60, reinit vi venc
So from the KVM side, this looks like:
- Encoder data retrieval starts failing.
- The device reports “no signal”.
- It tears down the video pipeline.
- It detects 1920x1080@60 again and reinitializes capture.
Additional relevant context
- When a new session starts, kvmd starts ustreamer normally on /dev/video0 and capture begins correctly.
- The logs show normal streamer startup, “CAP: Capturing started”, and repeated “Requesting key frame” messages before the signal-loss event.
- This does not look like a simple frontend-only black overlay, because the KVM itself reports a real signal drop/reset in the capture pipeline.
Why I think this should be investigated separately from previous app/cloud issues
I previously had a different issue where the Windows client could get stuck at 99%, which was traced to blocked STUN/signaling domains and not to the local video capture pipeline.
This new problem is different: the KVM log now explicitly reports “resolution: no signal” and encoder teardown/reinit.
So this seems to be a separate bug or instability path.
Questions for GL.iNet
- Is this a known issue in the GL-RM10 / current firmware / desktop app combination?
- Could this be caused by HDMI signal detection / EDID / hotplug handling / resolution renegotiation?
- Is there any newer firmware, beta build, or debug mode to capture more detailed HDMI/input-state logs?
- Can GL.iNet confirm what error code a004800e means in this VENC path?
- Is there any recommended workaround to make the input signal handling more stable?
Useful technical details
- Device model: GL-RM10.
- Firmware: V1.8.0 release4.
- Kernel: 6.1.118 aarch64.
- Log source: /var/log/kvmd.log.
- App user-agent seen in kvmd: gl-kvm/1.4.0 / Electron 34.5.8.
- Signal-loss event observed at: 2026-05-07 07:22:20–07:22:21.
- Stream recovered by itself after reinitializing to 1920x1080@60.
If needed, I can provide:
- A larger /var/log/kvmd.log excerpt around the event.
- Full reproduction steps.
- Information about the HDMI source, cable, adapter, and display path.