Help needed with 6.9" 280x1424 bar display settings

[nerd]

Hey @z8man,

Good result. Picture and the corrected log together change the picture significantly. I owe you some corrections first.

What I got wrong in my previous reply:

• I told you to change 600x2440 to 600x1424. That was wrong. Your 600x2440 is the timing this bridge actually accepts, confirmed by your test.
• I attributed the 1280-pixel limit to firmware mapping inside the LT6911C. The earlier log showed bcm2708_fb at 1280x600, which is a legacy non-KMS framebuffer artefact, not a bridge limit. The new log no longer shows it.

What we now know (verified):

• The fix that actually mattered was enabling vc4-kms-v3d. The new log shows proper KMS active (vc4hdmi cards, card1-crtc kthreads, 512 MiB CMA pool). Without KMS the Pi was rendering through the legacy framebuffer path, which is what produced the 1280-wide image, not the bridge.
• 600x2440 at 60 Hz is, empirically, a mode this LT6911C firmware accepts and drives onto the full 1424 panel axis.
• userconfig.txt is now clean. Custom HDMI lines are commented out. Good.

What is theory (not verified):

• Why specifically 600x2440 maps to 280x1424 on this bridge is unknown. The H and V ratios do not match, so it is not a simple uniform scaler. The LT6911C firmware on this board is a closed binary loaded at the factory and I have no way to inspect what input modes it accepts or how it maps them. Treat 600x2440 as a known-working magic number for this specific board, not a derived value.

One cleanup still needed:

You enabled vc4-kms-v3d by editing /boot/volumioconfig.txt. That file is system-managed and will be reverted at the next Volumio update, which will break your display again. Move that change to /boot/userconfig.txt instead so it survives OTA. Add this single line to userconfig.txt:

dtoverlay=vc4-kms-v3d

Then revert volumioconfig.txt to stock.

The 90-degree-off boot splash is a Plymouth versus KMS rotation issue, and it is solvable. The video=…,rotate= parameter only rotates the kernel framebuffer and console; Plymouth uses its own pre-rendered image sequence and needs to be told the matching rotation separately. The fix is the volumio-plymouth-adaptive theme plus a plymouth= parameter on cmdline.txt. Background and full instructions are here:

Portrait Display Rotation Issues: Why It's Broken (Kernel + Plymouth)

Dear Volumionauts, I’ve completed extensive research into portrait display rotation problems many Volumio users experience, particularly during boot and with Plymouth splash screens. This isn’t a Volumio bug - it’s a fundamental Linux kernel limitation. The Core Problem Linux DRM (Direct Rendering Manager) assumes all displays are landscape-oriented by default. When you have a portrait-native panel (like many touch displays with 320x1480, 720x1280, or 1080x1920 resolution), the kernel’s rotati…

For your case, the cmdline.txt video= line uses rotate=90, so the matching Plymouth value is plymouth=270 (formula: plymouth = (360 - rotate) % 360). Append it to your existing cmdline.txt so the line ends with:

video=HDMI-A-1:600x2440M@60,rotate=90 plymouth=270

Make sure cmdline.txt remains a single line. The plymouth= parameter is in effect since the volumio-plymouth-adaptive theme is shipped with your build version.

For the small centring offset, try adding to userconfig.txt:

overscan_left=20

Reboot, observe, adjust the number up or down. If it has no visible effect, the bridge is accepting the timing rigidly and centring is not adjustable from the Pi side.

Kind Regards,