A TV to use as a computer monitor is one end of a display spectrum. The other end is no monitor at all.

Fine, with specifics. For a desk at 2 to 4 feet, 32 to 43 inches is the comfortable range. Beyond 55 inches you are wall-mounting and sitting at least 3 feet back, because a 65-inch 4K panel spreads the same pixel count across a much larger area and text anti-aliasing starts to matter at typical desk distance. Chroma 4:4:4 has to be on or text gets a colored fringe. You want PC or Game mode enabled to keep input lag below about 15 ms. Most modern OLEDs (LG C5, Samsung S95F) and mid-range QLEDs (TCL QM7K, Hisense QD6QF) check those boxes. The rest is preference.

Because automation runs on CI. Windows Server on EC2, a GitHub Actions runner, a Docker container on a self-hosted Hetzner box: none of these have an HDMI cable attached. Without a display, many UI Automation calls behave strangely, Win32 APIs that assume a primary display fail, and the DWM composition pipeline does not initialize. Terminator ships virtual_display.rs to patch that gap. When TERMINATOR_HEADLESS=1 is set, VirtualDisplayManager::initialize() at line 44 creates a virtual session so the rest of the engine can believe it is on a real desktop. On machines where the virtual display driver is installed (IddSampleDriver, MTT VDD), that session becomes a real 1920x1080 rendering surface that apps can draw into.

1920 pixels wide, 1080 tall, 32 bits of color depth, 60 Hz refresh rate, no driver path by default. The struct is VirtualDisplayConfig in crates/terminator/src/platforms/windows/virtual_display.rs at lines 7 through 24. You can override any of those fields by constructing VirtualDisplayConfig manually and passing it through HeadlessConfig into WindowsEngine::new_with_headless(). The default matches what most CI providers expose and what most Windows apps are tested against.

Not if you write them the Terminator way. Selector strings like role:Button && name:Save resolve against the Windows UIA tree and the macOS AX tree, not against pixel coordinates. The tree does not care whether the pixel grid is 1920x1080 or 3840x2160. A click_element call is monitor-agnostic. Where you can get in trouble: code that reads element.bounds() and does pixel math, scripts that take a screenshot and crop by absolute coordinates, and anything that hard-codes a position. If your code is selector-first, you are safe. If it is coordinate-first, you are essentially writing against a specific resolution and you will feel it the first time you switch.

Yes. The virtual_display.rs file is Windows-only because Windows is the trickier case (headless VMs, RDP sessions, service accounts). On macOS the Accessibility API works normally when any display is attached, so Terminator's macOS adapter just uses the system Monitor APIs directly. A 55-inch TV over USB-C or HDMI becomes a second display in System Settings and Terminator sees it like any other screen. The headless story on macOS is different and not as mature, because macOS is less commonly deployed in CI runners.

A string read by std::env::var in is_headless_environment() at virtual_display.rs line 167. If it is present and equals '1' or any casing of 'true', the function returns true and the rest of the engine wires in a VirtualDisplayManager at WindowsEngine::new (engine.rs line 281). Any other value, or the variable being unset, returns false. That means TERMINATOR_HEADLESS=yes does not work and will silently run in normal mode. Use TERMINATOR_HEADLESS=1 or TERMINATOR_HEADLESS=true.

Correct. Terminator does not bundle a display driver. What virtual_display.rs line 118 does is install a driver you supply: install_driver() shells out to pnputil /add-driver <driver_path> /install, using a path you passed in VirtualDisplayConfig.driver_path. If you do not pass one, the module creates a 'virtual session' which is a lightweight Window Station stand-in that lets UIA calls succeed without crashing, but nothing is actually being rendered to a framebuffer. For real rendering into a headless pixel surface, the typical pairing is IddSampleDriver (Microsoft sample) or the MTT Virtual Display Driver fork, both of which are permissively licensed.

Nothing if you stick to selectors. If you touch coordinates, you pick up 3 things at once: a 3840x2160 native resolution, a Windows display scale factor (usually 150 percent at typical TV viewing distance), and a single-monitor setup where (0, 0) is the top-left of the TV. None of that breaks Terminator. The one place it bites: if you have a second monitor (a laptop screen) and the TV is display 2 with a non-zero origin, every bounds() call returns coordinates in virtual screen space, and the two monitors may have different scale factors. Our separate guide on the element.monitor() routing rule covers the strict-less-than edge case that decides which display owns a click on the seam.

Terminator's headless support is currently Windows-only because virtual_display.rs lives under crates/terminator/src/platforms/windows. Linux does not need an equivalent in the same way because Xvfb already solves the headless display problem at the X server level, and Wayland has its own headless backends. The typical Linux pattern is to start Xvfb :99, export DISPLAY=:99, and run your automation; Terminator's Linux adapter works in that setup without any virtual_display.rs equivalent. macOS is the real gap, and it is an open question we are working through.