From Copying a Screen to Creating a Workspace

scrcpy's architecture becomes more revealing when the Android producer or the host destination changes. Instead of mirroring the main screen, the server can create a temporary Android display for an app; instead of using a display as the video source, it can capture a camera; instead of showing decoded frames in its own window, the host can expose them as a Linux webcam. This chapter follows those practical extensions so a person can distinguish what the bridge reuses from what must change with each source and sink.

A virtual display is an Android workspace, not a larger window

Ordinary display mirroring captures a display that already exists on the device. A new-display session reverses the relationship: scrcpy asks Android to create another display, starts or places an application there, and captures that display for the host. The application is then running in an Android display context whose size and density can be chosen for the task. The host window is a view of that workspace, not merely a scaled copy of the physical phone screen.

This distinction matters in a concrete situation. Suppose a person wants to run a media player or a settings screen in a desktop-sized area without taking over the phone's main display. A new virtual display provides a separate destination for the app. The device's main screen can remain available for another activity, while scrcpy shows the created display. If no launcher or app is available in the new display, the display may be empty; scrcpy must start an application there to produce useful content. The workspace is not automatically a second copy of whatever the main display was showing.

The virtual display also has a lifecycle. By default, scrcpy destroys the new display when the session ends. The content running there is normally destroyed with it, although an option can move that content to the main display instead. System decorations can be kept or removed, which matters when the goal is a clean app surface rather than a full launcher-like environment. The input-method editor—the Android on-screen keyboard—has a policy that determines where it appears. These are not cosmetic details: they determine whether the app is usable and what state survives closing the bridge.

A fixed virtual display is useful when the target environment is known in advance, such as a 1920×1080 demonstration or a test surface with a chosen density. A flex display treats the host window size as an input to the Android workspace. When the person resizes the window, scrcpy requests a corresponding virtual-display resize. The server tracks display-property changes and debounces requests so Android does not reconfigure itself for every intermediate size while the mouse is still moving.

That resizing requires coordination across three geometries. The host window has a visible size. The virtual display has a logical size and density. The encoded video may be constrained by the available video encoder and may include orientation or other transforms. When the display changes, the capture session can reset with new dimensions, and the control path must map the next mouse or touch event to the new display. A flex display is therefore not just client-side stretching. It is a state change in Android followed by a new capture configuration and a new coordinate relationship.

The virtual-display implementation keeps two transformations conceptually separate. One describes how the workspace is rendered into the video frame.