Can I use a TV as a computer monitor? Yes, and the piece every SERP result skips is what happens to your scripts.

Almost any modern TV works as a display, but the SERP gives the consumer answer and stops there. The software-side answer is that once you plug in a TV, your OS treats it as a second monitor with its own width, height, x and y offset, and scale_factor. On Windows this information is enumerated through EnumDisplayMonitors; on macOS through NSScreen and CGGetActiveDisplayList. Terminator wraps both behind a single Monitor struct defined at crates/terminator/src/lib.rs line 274. Any automation script that has to work on the TV-as-monitor configuration needs to read those values, not assume them.

A 4K TV at 100% scale reports scale_factor 1.0; a modern laptop panel typically reports 1.5 or 2.0 because it is a HiDPI display. If your script clicks at logical (100, 100), that is a physical (150, 150) on a laptop at 1.5x and a physical (100, 100) on the TV at 1.0x. Terminator exposes scale_factor per monitor (lib.rs:288), so the click-coordinate helper knows which scale to apply depending on which monitor the target element reports via element.monitor(). Without per-monitor scale tracking, drag-and-drop between displays lands in the wrong pixel.

Terminator has Desktop::get_monitor_by_name at crates/terminator/src/lib.rs line 712. Pass the exact display name the OS reports for your TV: on Windows this is usually something like 'LG TV SSCR2' or 'SAMSUNG' pulled from EDID; on macOS it is the product name surfaced by CGDisplayCopyDisplayProductName. If you do not know the name, call desktop.list_monitors() first, print every Monitor.name, and pick yours. Index-based addressing (monitor 1 vs monitor 2) breaks when the user unplugs and re-plugs the TV in a different order; name-based addressing survives that.

Terminator's Monitor struct carries exactly nine fields: id, name, is_primary, width, height, x, y, scale_factor, and an optional work_area. You can verify this by reading crates/terminator/src/lib.rs lines 274 through 292 in the open-source repo. Every UIElement in the tree also has a .monitor() method (element.rs:1583) that returns which display it sits on. The combination means that once you have a Locator pointing at, say, a Chrome window, one call tells you whether that window is on your laptop panel or your TV and what the TV's scale_factor is. None of the TV-as-monitor articles on the first page of Google mention per-element monitor attribution, because the cable/refresh-rate framing does not invite it.

No, and this is a clean separation that is easy to miss. Input lag on a TV is the delay between the HDMI input signal and the pixels lighting up on the panel. Accessibility-API automation, which Terminator is built on, operates on the OS accessibility tree before pixels are rendered. So the TV's 30ms or 50ms input lag adds to what a human sees but adds nothing to how fast the script finds a button or sends a click. The script and the accessibility tree agree about the button's position the moment Windows UIA or macOS AX exposes it, regardless of when the panel finally shows it. Screenshot-based agents are the ones that pay the lag tax, because they wait for pixels.

Windows and macOS both allow negative coordinates for displays placed left, above, or off-primary of the primary display. If you arrange your TV above the laptop in Display Settings, the TV might report x=0, y=-2160 while the laptop reports x=0, y=0. Monitor.x and Monitor.y are typed as i32 in crates/terminator/src/lib.rs lines 285-286 precisely so they can represent negative offsets. A script that assumes (0, 0) is the top-left of the combined desktop will miss every click on the TV in that configuration. Reading the Monitor's origin before computing target coordinates is the fix.

Yes. crates/terminator/src/platforms/mod.rs line 164 defines capture_monitor_by_id, which takes a single monitor's id and returns only that display's pixels. This is different from a full-desktop screenshot cropped after the fact. The per-monitor capture path avoids one compositing pass and returns at the TV's native resolution (e.g. 3840x2160 for a 4K panel). For vision-model input where resolution and cost both matter, that distinction cuts the image size roughly in half compared to a combined-desktop snapshot.

Many living-room PCs run that way, and some CI machines connect a TV to a mini-PC as a stand-in for a real monitor. In that case the TV is Monitor.is_primary = true, the scale_factor is whatever Windows or macOS applies by default (1.0 for a 4K TV at 100%, 1.5 for 125%), and the taskbar ends up on the TV so Monitor.work_area becomes meaningful. Terminator also ships crates/terminator/src/platforms/windows/virtual_display.rs, a VirtualDisplayManager that lets you run UI automation on a Windows machine with no physical display at all. If the TV is off or disconnected, the headless path is still there.

The public API is identical. crates/terminator/src/platforms/mod.rs lines 149-165 declare the engine trait: list_monitors, get_primary_monitor, get_active_monitor, get_monitor_by_id, get_monitor_by_name, capture_monitor_by_id. Windows implements it against EnumDisplayMonitors and the xcap crate; macOS implements it against NSScreen and CGDirectDisplayID. The Monitor struct your code receives has the same shape on both. So a script that decides 'if the Chrome window is on a monitor named something containing TV, resize it to the TV's work_area' runs unchanged on a MacBook Pro and a Windows 11 desktop.