display_utils_xrandr

The X11 display paths for a server that cannot give a display its own output.

display_utils lays an extended desktop out as real RandR outputs wherever the X server offers pluggable ones, and resizes through native RandR. This module is everything it falls back to where that is not available, and nothing here runs on a server where it is:

• An extended desktop as RandR 1.5 logical monitors over the one output a framebuffer server has (apply_monitor_layout, replace_selkies_monitors). The whole set is swapped under one server grab, every monitor asks for the physical output because GTK realizes a monitor only where one is listed, whether the server lets them share it is read back rather than assumed, and the swap is announced on an output property because RRSetMonitor emits no RandR event of its own. Qt matches a monitor to its screen by name and announces a new geometry only for a monitor that is exactly one CRTC, which no display of several sharing the output is, so a display whose rectangle changes takes a monitor named for the new rectangle (_monitor_names) and Qt replaces that one screen. A single display is shown whole by the output, its CRTC exactly the monitor rather than the framebuffer rounded up to the CVT cell (resize_display's output_size): Qt re-reads the monitors on the root's ConfigureNotify but announces a new geometry only for a monitor that is exactly its one CRTC, so a monitor narrower than its CRTC leaves a Qt desktop at the size it had until the work area happens to change, which a shrink that puts its panel off screen never does.
• The window-manager restart that layout needs (MultiMonitorWindowManager): a manager that reads the monitor set only as it starts has to be restarted once to tile against it. A display that arrives as an output is a hotplug, which every manager follows, so there is nothing to restart there.
• The xrandr/cvt/gtf subprocess fallbacks behind the native RandR calls (_resize_display_xrandr, _get_new_res_xrandr, generate_xrandr_gtf_modeline, _run_xrandr), taken only when the native call fails.

It shares display_utils' retained X connection and lock, so the same rules hold: blocking X work runs on executor threads under _x11_lock, and a mutation reads its result back before claiming success.