4:3 HDMI input is cropped to 16:9 instead of letterboxed

[MagnaCapax]

Problem

When the HDMI input is a 4:3 resolution (e.g. 1024x768 from a BIOS or Linux console), the NanoKVM crops the top and bottom of the frame instead of letterboxing or preserving full content.

Related but distinct from #727: that issue reports cropping on 1080p (16:9) input after updating to v1.4.0/2.3.1 — a regression in same-aspect-ratio handling. This issue is about non-16:9 input (4:3) being cropped during capture, which may have never been supported correctly.

Measured Crop

Wrote 48 numbered lines to a 25-row Linux console (1024x768 framebuffer, verified via stty -F /dev/tty1 size = 25 80). After scrolling, rows 25–48 should be visible.

	Expected	Actual
First visible row	ROW_25	ROW_28
Last visible row	ROW_48	ROW_46
Visible rows	25	19
Rows lost	0	~6 (24%)

Approximately 3 rows cropped from top, 2–3 rows from bottom. This is significantly more than the ~2 rows initially estimated visually.

Testing Performed

Test 1: Binary swap (kvm_system 2.2.5 vs 2.3.4)

Swapped the closed-source kvm_system binary between App 2.2.5 (372KB) and App 2.3.4 (325KB). Different binaries (different md5 hashes), different output behavior:

	kvm_system 2.2.5	kvm_system 2.3.4
MJPEG output resolution	1920x1080	1920x1080
Visible console rows	19 of 25	19 of 25
Crop	Identical	Identical

Conclusion: The crop is not in the kvm_system encoding pipeline. Both versions produce the same crop. The content is lost before encoding.

Test 2: Resolution parameter (/kvmapp/kvm/res)

Changed res from 720 to 1080 (controls H.264 stream encoding resolution).

	res=720	res=1080
H.264 output	1280x720	1920x1080
Visible console rows	19 of 25	19 of 25
Crop	Identical	Identical

Conclusion: Changing the encoding resolution does not recover cropped content. The crop occurs before encoding.

Test 3: MJPEG vs H.264

Both streams show the same 19 rows out of 25. The crop is present in both MJPEG and H.264, confirming it happens at the capture stage.

Pixel analysis (MJPEG, 1920x1080 frame)

• First text row: y=4
• Last text row: y=1079
• Text fills the full frame edge-to-edge — the 19 captured rows are scaled to fill the output resolution
• No black bars (no letterboxing) — content is scaled to fill 16:9 with the already-cropped source

Root Cause Analysis

The crop occurs at the HDMI capture level, before any software encoding in kvm_system. Either:

1. LT6911 capture chip is misconfiguring active area detection for 4:3 input — cropping overscan or miscalculating the active region
2. VGA-to-HDMI adapter (external, between source and NanoKVM) is outputting a signal with incorrect blanking intervals or active area metadata, causing the LT6911 to capture only a subset of the frame

Our setup uses a VGA-to-HDMI adapter (unknown model) between the source (ASRock DeskMini A300 VGA output) and the NanoKVM HDMI input. The adapter may be contributing to the issue, but we cannot currently test with direct HDMI (the DeskMini has an HDMI port, but hardware changes are not possible at this time).

The NanoKVM correctly detects the input as 1024x768 (/kvmapp/kvm/width = 1024, /kvmapp/kvm/height = 768), but the captured frame content represents only ~76% of the vertical resolution.

Environment

• Hardware: NanoKVM Beta (not Cube/Full)
• Image: v1.4.0
• Application: 2.3.4 (also tested with 2.2.5 kvm_system binary)
• HDMI chip: Lontium LT6911 (hdmi_version: ux)
• Source: ASRock DeskMini A300, VGA output → VGA-to-HDMI adapter → NanoKVM HDMI input
• Source resolution: 1024x768 (4:3)

What Doesn't Help

• Swapping kvm_system binary versions — crop is identical
• Changing /kvmapp/kvm/res — crop happens before encoding
• Web UI scale controls — operate on already-cropped stream
• Setting source to 1080p — makes web viewer unusable (excessive scrolling on small displays), and the NanoKVM should handle any input resolution

Requested Fix

The LT6911 capture initialization in kvm_system should preserve the full active area of non-16:9 inputs. Ideally:

1. Capture the full 1024x768 active area (all 768 vertical lines)
2. Output with letterboxing (black bars) or at native aspect ratio
3. At minimum, do not crop — even stretched 4:3-to-16:9 is better than losing 24% of content

[MagnaCapax]

Related: #727 reports the same symptom ("screen cutted") on a different setup (RX550, HDMI-to-HDMI, 1080p). Scale changes also did not solve it for that reporter.

This appears to be a general aspect ratio / scaling issue in kvm_system, not specific to 4:3 inputs.

[MagnaCapax]

Test Results: Crop is at Capture Level, Not Software

We performed three tests to isolate the crop source:

Test 1: kvm_system binary swap (2.2.5 vs 2.3.4)

Swapped the closed-source kvm_system binary between App 2.2.5 (372KB, md5 b7adbfb1) and App 2.3.4 (325KB, md5 d9904b15). Both produce identical cropping — 19 of 25 console rows visible.

Test 2: Resolution parameter

Changed /kvmapp/kvm/res from 720 to 1080. Identical crop — the content is already lost before encoding.

Test 3: MJPEG vs H.264

Both streams show the same 19 of 25 rows.

Measured crop (clean test)

Killed getty, cleared tty1, wrote 48 numbered test lines to a 25-row console (1024x768, stty size = 25 80):

• Expected visible: ROW_25 through ROW_48
• Actual visible: ROW_28 through ROW_46
• Lost: ~3 rows top, 2–3 rows bottom = 6 rows / 24% of content

Conclusion

The crop occurs at the HDMI capture level — either the LT6911 chip's active area detection or its ISP pipeline configuration. Software encoding (kvm_system version, res setting, stream type) has no effect.

Our setup uses a VGA-to-HDMI adapter (unknown model) between the source VGA output and NanoKVM HDMI input. The adapter may be signaling incorrect active area/blanking to the LT6911. We cannot currently test with direct HDMI to confirm.

The NanoKVM correctly reports input as 1024x768, but the captured frame only represents ~76% of the vertical content. The 19 captured rows are then scaled to fill the output frame (1920x1080 for MJPEG, 1280x720 for H.264 at res=720).

Related: #727 reports cropping on 1080p HDMI (no VGA adapter) after updating to v1.4.0/2.3.1, suggesting the LT6911 capture configuration may have regressed in newer firmware images.