display / touch / bonding solutions
Use Linux xrandr with a calculated modeline: xrandr --newmode "1920x360_60.00" 56.25 1920 1968 2000 2080 360 363 373 380 -HSync +Vsync, then --addmode and --output. For permanent fixes, inject a custom EDID binary via kernel parameter drm.edid_firmware=edid/custom.bin. This bypasses host GPU limitations that reject non-standard resolutions like 1920x360.
bar screen EDID tuning and resolution recognition
EDID (Extended Display Identification Data) is a 128–256 byte data block that tells the host GPU the display's supported resolutions, timings, and physical size. Standard EDIDs only include VESA DMT modes (e.g., 1920x1080), so 1920x360 bar screens are often rejected or downscaled.
Bar displays—common in retail signage, automotive dashboards, and medical monitors—use ultra-wide aspect ratios (5.33:1 for 1920x360) that don't exist in VESA tables. Industrial PCs default to 1920x1080 or 1280x720, causing black borders or distorted images. At CDTech, we've seen 40% of field returns traced to EDID mismatches, not hardware faults. Reprogramming the EDID or overriding it at the OS level is the only reliable fix.
Use VESA CVT-RB (Reduced Blanking) formula: Pixel Clock = H_total × V_total × refresh. For 1920x360@60Hz: H_total = 1920 + 48 (blanking) = 1968, V_total = 360 + 20 = 380, yielding ~56.25 MHz. Front/back porch and sync widths follow CVT-RB v2 defaults.
The full modeline: "1920x360_60.00" 56.25 1920 1968 2000 2080 360 363 373 380 -HSync +Vsync. In our testing with Intel UHD 630 GPUs, this timing produces stable 60Hz with<1% pixel clock deviation. Always verify with xrandr --verbose to confirm the mode is active.
Place the EDID binary (e.g., custom.bin) in /usr/lib/firmware/edid/, then add drm.edid_firmware=edid/custom.bin to the kernel command line in /etc/default/grub. Rebuild initramfs and reboot. This forces the DRM driver to use your EDID instead of the display's default.
For persistent multi-display setups, name the file by connector (e.g., HDMI-A-1.bin) and use drm.edid_firmware=HDMI-A-1:edid/HDMI-A-1.bin. In automotive projects, we've deployed this across 500+ units with 100% success—no more "unsupported resolution" errors at boot. Always backup the original EDID (cat /sys/class/drm/card0-HDMI-A-1/edid > original.bin) before overwriting.
Run three commands: (1) xrandr --newmode "1920x360_60.00" 56.25 1920 1968 2000 2080 360 363 373 380 -HSync +Vsync, (2) xrandr --addmode HDMI-1 1920x360_60.00, (3) xrandr --output HDMI-1 --mode 1920x360_60.00. This activates the mode immediately without reboot.
For scripting, wrap in a shell script added to ~/.xprofile:
bashxrandr --newmode "1920x360_60.00" 56.25 1920 1968 2000 2080 360 363 373 380 -HSync +Vsyncxrandr --addmode HDMI-1 1920x360_60.00xrandr --output HDMI-1 --mode 1920x360_60.00
In smart home kiosks, we've used this to support 1920x360, 1920x480, and 2560x720 bar modes on the same hardware. Note: xrandr changes are session-only; use EDID override for permanence.
GPU drivers (Intel, NVIDIA, AMD) validate resolutions against EDID's "Detailed Timing Descriptors." If 1920x360 isn't listed, the driver blocks it to prevent out-of-spec signals. Embedded GPUs (e.g., Intel Celeron J4125) are especially strict, lacking custom resolution UIs.
We've debugged this on 20+ industrial PC models: Advantech, Beckhoff, and Siemens all fail with 1920x360 unless EDID is overridden. One medical display project required 1920x360@60Hz for a patient monitor; the host PC defaulted to 1280x720, causing UI scaling issues. After injecting a custom EDID, all 100 units deployed flawlessly. Never rely on "auto-detect" for bar screens.
Yes, CVT-RB v2 is ideal for bar screens: it reduces horizontal blanking to 80 pixels (vs. 160 in v1), lowering pixel clock and bandwidth. For 1920x360@60Hz, CVT-RB v2 yields 56.25 MHz vs. 62.5 MHz for standard CVT—critical for HDMI 1.4 bandwidth limits.
CVT-RB v2 parameters: H blanking = 80, V blanking = 20, sync widths = 24H/10V. The formula: Pixel Clock = (1920 + 80) × (360 + 20) × 60 = 56.25 MHz. In our HDMI display solutions, we've used CVT-RB v2 for 1920x480, 2560x720, and 3840x720 bar modes, all stable at 60Hz. Avoid CVT-RB v1 for ultra-wide aspect ratios—it wastes bandwidth.
Use xrandr for quick testing or single-user setups; use EDID override for production deployments, multi-user systems, or headless boot scenarios. EDID override persists across reboots and works before Xorg starts—critical for embedded Linux.
For kiosks or medical devices that boot directly to an app, EDID override is mandatory. We've seen xrandr scripts fail when display managers (GDM, LightDM) reset modes during login. In one automotive dashboard project, xrandr worked in dev but failed in production due to Wayland's restricted mode-setting. EDID override solved it. Always test both methods in your target environment.
Use edid-decode and edid-generator tools, or modify an existing EDID hex dump. Replace the "Detailed Timing Descriptor" block with your 1920x360 modeline, recalculate checksum (byte 127 = 256 - sum(bytes 0–126) mod 256), and save as binary.
Step-by-step:
Extract original EDID: cat /sys/class/drm/card0-HDMI-A-1/edid > original.bin
Decode: edid-decode original.bin
Edit the hex file (use hexedit), updating bytes 54–125 with new timing
Recalculate checksum: printf '%02x' $((256 - (0x$(xxd -p -l 127 original.bin | tr -d '\n' | fold -w2 | paste -sd+ | bc) % 256)))
Append checksum to byte 127
At CDTech, we automate this with a Python script that generates EDID for any resolution. One client needed 1920x360, 1920x480, and 2560x720 variants—all generated in<1 hour. Never skip checksum validation; a bad checksum causes EDID rejection.
Top errors: (1) wrong pixel clock (causes no signal), (2) missing sync polarity (screen flickers), (3) bad EDID checksum (display shows "no input"), (4) ignoring GPU bandwidth limits (HDMI 1.4 max 165 MHz). These lead to black screens or unstable images.
A frequent mistake: using standard CVT (160-pixel blanking) for 1920x360, which pushes pixel clock to 62.5 MHz—too high for some embedded GPUs. Another: forgetting to set video=HDMI-1:e in GRUB to enable the connector. In one retail signage project, 30% of units failed due to a 1-byte EDID checksum error. Always validate with edid-decode before deployment.
"In 15 years of LCD production, bar screen EDID issues are the #1 cause of 'no display' complaints. Customers ship 1920x360 panels to integrators, who plug them into standard PCs—only to get 1280x720 or black screens. Our fix: pre-program EDID with 1920x360@60Hz CVT-RB v2 timing at the factory. For Linux, we provide a kernel-ready EDID binary and a one-line GRUB edit. For Windows, we use CRU (Custom Resolution Utility) to inject the mode. We've deployed this across 10,000+ units in automotive, medical, and retail—zero field failures. Never rely on host GPU auto-detection for bar screens; always override EDID or use a controller with custom timing support."
Custom EDID configuration is essential for 1920x360 bar screens. Calculate modeline with CVT-RB v2 (56.25 MHz pixel clock), apply via xrandr for testing, and inject EDID binary for production. Validate checksums, respect GPU bandwidth limits, and test on target hardware. Partner with experienced suppliers like CDTech for pre-programmed EDID solutions that guarantee compatibility across industrial PCs.
Why does my 1920x360 bar screen show 1280x720 instead?
The host GPU doesn't recognize 1920x360 in the EDID. Override with a custom EDID binary or use xrandr to force the correct modeline.
What is the pixel clock for 1920x360 at 60Hz?
Using CVT-RB v2: 56.25 MHz. Standard CVT would be 62.5 MHz, which may exceed HDMI 1.4 bandwidth on embedded GPUs.
How do I make xrandr changes permanent in Linux?
Add the xrandr commands to ~/.xprofile for session persistence, or inject a custom EDID via drm.edid_firmware for system-wide permanence.
Can I use EDID override on Windows for bar screens?
Yes, use CRU (Custom Resolution Utility) to import a custom EDID file, then run restart64.exe to apply. Alternatively, use NVIDIA/AMD control panels for custom resolutions.
What EDID checksum ensures valid bar screen timing?
Byte 127 must be 256 minus the sum of bytes 0–126 modulo 256. A bad checksum causes the display to reject the EDID entirely.
Controllers, Boards and Firmware
By continuing to use the site you agree to our privacy policy Terms and Conditions.
