Screen types, and what a screen can do

What hardware can act as a Mirra screen, what each display reports about itself, and exactly what the capability record does and does not cover.

Save as PDF This did not answer it

A Mirra screen is a browser

There is nothing to install on a display. The screen half of Mirra is a web page, and any device that can run a browser full screen and stay awake is a Mirra screen. That is what makes a spare laptop a legitimate first screen, and it is why a smart TV can be one at all.

It also sets where the differences between screens come from. What a display can do is decided by the browser on it, not by the badge on the box. A Raspberry Pi and an Intel mini PC both report themselves as Linux machines and are not remotely alike; two Pis running different browsers are not alike either. Mirra therefore asks each screen about itself rather than inferring anything from what it appears to be.

The six kinds Mirra asks about

When you click Pair a screen, Mirra asks what you are putting it on before it asks for a code. Each card carries what is good about it and what to know first, both lists the same size — the second one is the cheaper of the two to read.

The picker, before the code box. The last two can be opened and read, but not paired.

A browser on a computer, tagged Free — start here. Costs nothing, takes a minute, and the camera and microphone work. It ties up a computer, and nothing restarts it if the browser closes.
A Raspberry Pi, tagged Recommended. Boots straight to Mirra with no desktop and no keyboard, restarts the browser if it dies, and is the only route that supports wired buttons. You are assembling it, and a Pi 4 or newer is worth it — older boards struggle with the animated faces.
A mini PC, tagged Most capable. Live video from your cameras where a Pi manages a still every second or two, several cameras and the face and presence at once, and music playing out of the mirror itself. Two to four times the price, bigger and hungrier, no pins for buttons, and you install Ubuntu Desktop first.
A smart TV, tagged Works on many. No extra hardware and usually already on a wall. TV browsers are often slow, most have no camera or microphone, and many sleep on a timer. Try it before you rely on it.
Mirra Compute Device, coming soon. A module that plugs into any HDMI screen, joins Wi-Fi from your phone and pairs itself.
Mirra Mirror Display, coming soon. Mirror glass, display and computer in one frame.

Choosing between a Pi and a mini PC

These are the two permanent routes, and the difference between them is not really speed. It is two specific things a Pi usually cannot do.

The first is live camera video. A Pi manages a still every second or two where a mini PC shows moving pictures. The second is protected music. Spotify's web player needs a browser that can decrypt protected media, and Chromium on a Pi frequently cannot, so the music plays from your phone rather than from the mirror. On Ubuntu the installer fits Google Chrome rather than Chromium for exactly this reason — it is not a preference, it is the piece that decides whether a mirror can play music itself.

What the Pi has and the mini PC does not is a GPIO header, and therefore wired buttons: a physical panic button or reboot button next to the screen, which is what a corridor or a care home wants instead of a phone somebody has to find and unlock.

The Pi's own route is writing the Mirra image to an SD card with Raspberry Pi Imager; the mini PC is set up with a single command from the screen app's own address. It is the same installer script either way, and it works out which machine it is on — so a Pi that already runs Raspberry Pi OS can use the command instead of the image.
On a Pi it installs Chromium, opens it full screen at boot, hides the cursor, stops the screen blanking and restarts the browser if it ever stops.
Wired buttons are configured per screen under Broadcast, on the Buttons tab, using BCM pin numbers — not on the screen's own page.
A mini PC needs Ubuntu Desktop rather than Server; the screen needs a desktop session to draw into.

What a screen reports about itself

Two different things arrive from every screen, and they are worth keeping apart because one of them is a guess.

The first is a label. The screen sniffs its own user agent and reports pi, macos, windows, linux or browser, along with the app build it is running. This is fine for a fleet list and a bad basis for any decision — an Intel mini PC reports linux, which says nothing at all about what it can do.

The second is a measurement. Once, after it has finished booting, the screen asks its browser a short list of questions about itself and posts the answers. It runs once rather than on every poll because the checks are slow to fail on a machine that lacks the thing being asked about, and the answers only change when somebody installs a different browser.

Alongside both, the configuration fetch every minute doubles as a heartbeat, which is what the online and offline labels on the Screens list are reading.

How the capability record is made. Once per boot, and never on the poll.

The capability keys

Five measurements and a timestamp. This is the whole list — there is nothing else in the record.

drm: Whether this browser can decrypt protected media. Widevine specifically, because that is what Spotify's web player requires, and asked using the real check the media stack uses with the codec Spotify actually streams. A browser can have Widevine and still refuse a particular codec, and being told yes and then failing at playback is worse than being told no.Default: Absent until the screen has reported
audioOut: Whether the browser can see any audio output at all. A mirror with no speaker should not be offered as somewhere to play music. A browser that refuses to list its devices is recorded as unknown rather than as no — refusing to answer is not the same as answering no.Default: Absent until the screen has reported
cores: How many processor cores the browser admits to. Descriptive: it is part of the explanation when the animated face is smooth on one screen and not on another.
memoryGb: Memory in gigabytes as the browser reports it. Chrome-only and coarse, and absent everywhere else.
renderer: The graphics renderer string, trimmed to 120 characters. For reading, never for deciding: it is a vendor string, and deciding on one is the same mistake as sniffing a user agent. Software rendering showing up here is the difference between a smooth face and an unusable one.
measuredAt: When the measurement was taken. Stamped by Mirra as the report arrives rather than taken from the screen, because a display with a wrong clock would make a fresh measurement look years old. It is held in the record rather than printed on the page.Default: The moment the screen last reported

Absent is meaningful, and it is not the same as no. "This browser told us it cannot decrypt protected media" and "this browser never said" are different facts. Anything that needs certainty requires an explicit yes, so an older screen that has never reported is not offered what it never claimed. The record is also rebuilt field by field as it arrives: anything unrecognised is dropped and anything of the wrong type becomes absent rather than being converted into a number that looks true.

What the capability record does not cover

There is no camera capability, no microphone capability and no gesture capability. Mirra does not ask a browser whether a camera exists, and there is no field in which the answer could be kept. This surprises people, so it is worth being direct about how those actually work.

The camera is a per-screen setting you turn on yourself — Camera on this screen, on the screen's own page — and the browser then asks the person standing in front of the display for permission. Mirra has no way to know in advance whether there is a camera to ask about.
Gestures hang off that same switch. Mirra refuses to enable them while the camera is off, and says so, rather than leaving a switch that appears to be on and does nothing.
The microphone is the assistant's requirement rather than a recorded capability. A screen with no microphone can still be given a typed question at the display itself — press T — but it cannot be spoken to.
Browsers only permit a camera or a microphone on a secure address. A screen opened over plain http, or at a bare IP address, will have neither no matter what hardware is attached — use the hosted https address.
Wired buttons are not a capability either. They are a Raspberry Pi's GPIO header, configured per screen under Broadcast → Buttons. A mini PC has no pins, so the panic button stays Pi-only.

Find out what a screen can do

Open Screens and click the screen
The capability record belongs to one display, so there is no fleet-wide view of it.
Find Screen commands in the right-hand column
Below the presence panel, above the assistant face test.
Click Run diagnostics
The screen is asked directly, so it has to be online. If it does not answer you get the reason printed in its place rather than a stale record.
Read the two blocks
What this screen can do is the measurement: protected audio yes or no, then cores, memory and the renderer string. Below it is the live report — the app build, uptime in minutes, the round trip to Mirra or unreachable, and the last forty warnings and errors the screen has logged.

The screen keeps only warnings and errors, capped so that a display that has been up for weeks still has the useful lines. Nothing in the report reads the page, the photographs, or anything your household put on the screen — the line is drawn in what is collected rather than argued about afterwards.

What the answers change in practice

The capability record is reported so that you can tell in advance rather than discovering something at the moment you try to use it. Nothing is hidden from you on the strength of these numbers today; where a feature is missing from the widget palette, that is your plan or a switched-off integration, not a capability.

Protected audio decides whether music can come out of the mirror itself rather than from a phone. Where it says no, that is a fact about the browser, and installing a different one changes it — which is precisely why the mini PC installer fits Chrome.
Cores, memory and the renderer between them explain the animated assistant face. A Pi 4 drops to a lighter quality tier on its own — four cores or fewer is the test — and software rendering shown in the renderer string is why a face runs at a few frames a second.
A camera and a microphone decide whether the assistant, presence, greetings and gestures are possible at all. Most smart TVs have neither, which is the single biggest thing to know before mounting one.
A screen that has never reported is not broken. It has simply not been asked yet, or it is running a build that predates the measurement — reload it and the record appears.

Pairing a screenHow a display joins your household: the six-character code it shows, what to type into Mirra, what pairing creates, and what happens when you unpair.
Screen settingsEvery setting on a screen's own page that belongs to the screen rather than to a scene — its shape, which way up it is, its camera and gestures, the commands you can send it, and unpairing.
SpotifyConnect a Spotify account so a mirror can show what is playing, skip a track with a wave, and start music when you ask for it out loud.
The assistant: how a conversation worksHow you summon Mirra, what happens between hearing you and answering you, which tools it can reach, where the transcript goes, and what a conversation costs against your monthly allowance.
People and presenceHow to add a household member, enrol their face on a screen, and understand what Mirra stores about them and where recognition actually happens.
A screen is blank or showing old informationHow to tell a screen that has lost its connection from one that is doing exactly what its schedule and scenes tell it to, and what to check in which order.