Support

Automated tests run headless against fakes, so a set of situations can only be checked by hand on real hardware. Several of them have not been checked yet.

Verified so far: activating a group, switching straight from one group to another, and deactivating, all on real hardware, with the displays appearing at the requested resolution and position.

Not yet verified: sleep and wake, logout and login, connecting or disconnecting a physical monitor while a group is active, a cold boot with activate-on-launch set, deleting the active group, a shortcut another app already owns, and a crash while virtual displays exist.

None of it stops the app launching or leaves you without a screen: a failed switch rolls back, and a failed rollback releases every virtual display and puts a physical one back as main. But a display utility that has not been through a wake cycle is not one to trust on a Mac in another building until you have tried that cycle yourself.

Writing a gamma table to change apparent brightness returns success and produces no visible change on some Apple silicon Macs under recent macOS. The call does not fail, so there is no error to report and nothing in the log.

A slider that moves and changes nothing is worse than no slider, so where this is detected the control is disabled and carries the reason.

Displays with a real DDC channel are unaffected: that path changes the panel’s own backlight and works.

Jump Desktop and Parsec both request a display resolution when they connect, and again when the link changes. The display then no longer matches the group you activated.

Marking that display protected in the group makes the app put the arrangement back. It gives up after five restores in twenty seconds, though, because two programs taking turns rewriting the framebuffer is worse than either outcome, so protection wins the argument a few times and then concedes until the group is activated again.

The real fix is in the client: turn its automatic or dynamic resolution off, and let the group own the display. Protection is the belt to that pair of braces, not a substitute for it.

Sharing the group library over iCloud needs three things: a restricted entitlement, a signed build, and a user signed in to iCloud. An entitlement counts only when the bundle embeds a provisioning profile granting it, so a build made without one reports sharing as unavailable in Settings, in the same sentence someone with no iCloud account sees.

Settings names which of the three is missing rather than saying only that it did not work.

Nothing else is affected. Groups, activation, the CLI and backups all work against the local file.

MoreDisplays runs in your user session, so its displays exist from the moment the app launches after you log in, and not before. Nothing it does affects what the login window looks like or which display it appears on.

Covering that window needs a privileged service running as root from boot. The app now ships one: it installs from Settings, registers through SMAppService, runs from the moment the Mac starts, stays resident and reports its state in mdctl status. The last step is the one that is missing. It does not present a display at the login window yet, so in this version enabling it buys nothing.

Until it does, this is the first thing to weigh if you are thinking of putting a Mac somewhere you cannot reach. A hardware dummy plug covers the login window; the app covers everything after it.

A virtual display in the hierarchy can interfere with how the window server tracks focus across Spaces. Switching Spaces occasionally leaves focus on a display other than the one that received the switch.

This is macOS behaviour rather than a MoreDisplays bug, and a workaround inside the app would mean fighting the window server for control of focus, which produces a worse and less predictable result than the original problem.