Fixing Missing or Incorrect Screen Resolutions on Haiku
Diagnose missing Haiku display modes through native versus fail-safe output, adapter and EDID evidence, connectors, VM hardware, and settings.
A missing native resolution can result from the graphics driver/accelerant, incomplete monitor EDID, cable or adapter, virtual GPU choice, or stale Screen preferences. Record the offered mode list before changing anything. Never force a refresh rate outside the monitor’s specification.
Compare native and fail-safe output
Enter Boot Loader Options—Shift on BIOS or Space on UEFI—and enable only fail-safe video. Keep the same boot volume/state. Once at the desktop, open Preferences → Screen and record the available modes.
If fail-safe and native paths offer different lists, the native accelerant or its monitor/mode discovery is involved. If both omit the mode, investigate EDID/connector/virtual hardware. Fail-safe output is a diagnostic baseline, not a permanent acceleration solution.
If the screen is unreadable even in fail-safe, enable textual boot output and verify the desktop reaches app_server. A boot failure and a missing resolution are different problems.
Identify every component
Save GPU vendor/device IDs from listdev, Haiku revision/architecture, graphics driver named in syslog, monitor model, connector, adapter/dock/KVM, and current mode. For laptops, include internal versus external panel and whether hybrid graphics is present.
Open Screen preferences and compare the preview/monitor information with the physical display. EDID can provide dimensions and modes, but an adapter, KVM, or bad cable may hide or alter it. Test a direct known cable and one monitor before multi-display work.
If the correct mode appears but fails when applied, record whether the monitor loses signal, the desktop corrupts, or Screen preferences reverts. Those outcomes distinguish timing rejection from rendering corruption.
Do not confuse resolution detection with UI scaling. A high native pixel mode can make controls physically small even when EDID and mode selection are correct. Compare the pixel dimensions and refresh reported by Screen preferences first; font/icon sizing is a separate interface-configuration question and should not be “fixed” by inventing a lower monitor mode.
Test virtual machines correctly
Record hypervisor and selected virtual display adapter. A “newer” virtual GPU is not automatically supported by Haiku. Choose a virtual adapter documented by Haiku/the hypervisor combination and install no foreign guest driver.
Change one VM display setting at a time: video memory, adapter model, EFI/BIOS, and monitor count. Snapshot the VM before package or driver experiments. Host scaling can make the guest look low-resolution even when Haiku’s mode is correct; compare the mode reported inside Screen preferences.
Reset only relevant settings
Back up the Screen settings under the user’s settings hierarchy, then rename only the relevant file/directory and reboot normally. Do not delete the entire user settings tree. If default settings restore the mode, reapply choices one at a time.
For an update regression, boot the previous package state and compare the same monitor/connector. Do not copy old accelerants or kernel drivers into the current packagefs view; matching components and architecture matter.
Use fail-safe or the loader’s Disable components feature to recover from a mode that leaves the screen unusable. Remove temporary blocking after the corrected driver is installed.
Report and verify
Attach adapter IDs, driver, syslog, Screen mode list, EDID/monitor details, connector topology, native versus fail-safe results, and VM settings if applicable. Search the tracker by PCI ID rather than only the GPU marketing name.
After a fix, test cold boot, the native mode, refresh changes, monitor sleep/wake, and the original dock or second display. Confirm the mode persists and acceleration-dependent operations do not corrupt output.
Related:
Sources: