Displays at the login window

MoreDisplays runs in your user session. It starts when you log in and dies when you log out, which means it cannot create a display before anybody has logged in.

For a Mac with a monitor in front of it, that costs nothing. For a Mac in a cupboard, reached over the network, it is the awkward part of the whole idea: the login window is the one screen you cannot get a virtual display for, because nobody is logged in yet to run the app that would make one.

A service running as root from boot is the only way out, and this build ships one.

What it is

A single small binary, moredisplaysd, living at Contents/MacOS inside the app, with its launchd description at Contents/Library/LaunchDaemons where SMAppService insists on finding it. It is registered by the app, not by an installer, and it is a second program rather than a mode of the first one.

It is deliberately tiny. It links four things: the types, the display code, the virtual display code, and nothing else. Nothing that needs a window server is in it, which is not a style rule but a fact about the process: a launchd daemon does not have one. That boundary is what keeps a program running as root small enough to be worth trusting.

Switching it on

The app asks once, in its own words, before the system asks in its own.

That order is the point. Saying yes causes macOS to put an approval request in front of you for something that runs as root from boot, and a request like that arriving unexplained is alarming, as it should be. The app’s dialog names it before it appears.

Settings carries the switch under Displays at the login window. Turning it on registers the service; turning it off unregisters whatever is there. That asymmetry is deliberate: a root process still running with the switch off is the worst state available, so the off position is the one that does the work.

A request already waiting for your approval is left waiting rather than sent again. Asking twice changes nothing except how often you are interrupted.

Reading its state from a shell

This service exists for a Mac you cannot walk up to, so “have a look in System Settings” is advice nobody at the far end can take. mdctl status ends with a service: line.

$ mdctl status
version: 1.6
state: active
active group: Office
groups: Home, Office
service: registered and allowed to run (macOS: enabled)

The sentence weighs the registration against the answer you gave, because neither half is the whole story.

Only the last one reads like a problem, and that is the whole reason the line is a sentence rather than a status word. macOS’s own word for the state is repeated in brackets, unchanged, so a support transcript carries what the system said rather than what the app made of it.

Removing it

Turning the switch off unregisters it. Because the binary lives inside the app rather than in /Library, there is nothing else to hunt for: dragging the app to the trash plus that one unregister is the whole removal.

When it will not install at all

A build that is not signed for distribution cannot register a LaunchDaemon, and macOS refuses before the question reaches you. If you built the app yourself, that is why. The disk image on this site is signed and notarised, and can.

Next

• Headless setup for everything that does work on a Mac with no monitor.
• Uninstall for removing the service and the app together.