Use a second screen in Jitsi Meet

Check availability first

Jitsi announced multi-screen support on 1 October 2026. The implementation reviewed here is in Jitsi Meet 11248 source commit f765042; it does not establish that every hosted Jitsi service enables it. [S1][S2]

The reviewed configuration defaults secondScreen.enabled to false and describes a Chromium-based managed-room use case. The capability gate checks for window.getScreenDetails, then combines that support with the enabled flag. Browser permissions, popup behavior and iframe delegation remain separate requirements. [S2]

Before planning a room installation:

• Identify the actual deployed release using the version guide.
• Confirm that the operator enables the feature and the client includes the reviewed implementation. [S2]
• Check the browser’s current Window Management API support and the organization’s permission policy. API availability is limited across browsers. [S3]
• Use an existing extended-display setup and test the physical screens you intend to use. A source-level capability check is not a display-placement test.

If the feature is unavailable, continue with your normal meeting window or ask the operator about support. Do not join a second copy of the call assuming it is the same feature. [S1]

Choose what the additional view should show

The source descriptor supports these roles: [S2]

A participant-specific descriptor can identify whose source to show. A requested role still needs an appropriate active source: an empty screenshare view does not establish a network fault when nobody is sharing. [S2]

For operators of your own deployment

Preserve existing configuration and policy. In Docker, merge the setting through the existing custom-config.js workflow; on Debian/Ubuntu packages, merge it into the installed web configuration. This is a configuration fragment, not a complete server setup: [S2]

config.secondScreen = {
    ...config.secondScreen,
    enabled: true
};

Verify the configuration actually received by a fresh client. Use custom configuration diagnostics if a local change has no effect.

For embeds, use the matching External API implementation. Its reviewed iframe permissions list delegates window-management when the browser exposes the API, and delegates fullscreen. Delegation does not grant the end user’s or managed device’s browser permission. Do not bypass organization policy or assume a popup will be allowed automatically. [S2][S3]

For integration developers

After initializing the API against a supported deployment, an application can request an additional stage view and later close that same named surface. Treat these as requests, not success acknowledgments: [S2]

api.executeCommand('setSecondScreen', {
    id: 'presentation-display',
    source: { role: 'stage' }
});

// Later, close the same surface by omitting its source.
api.executeCommand('setSecondScreen', {
    id: 'presentation-display'
});

Listen for secondScreenSourceChanged, secondScreenClosed and secondScreenError. Record the error category privately and handle unsupported or blocked operations in the application. The implementation can reject disabled features, blocked popups and unavailable window-management access. [S2]

The full integration still needs its normal authentication, HTTPS and meeting lifecycle. See the embedding guide; replacing that application with this snippet will not create a complete meeting.

Verify on the actual displays

Recommended acceptance checks:

1. Join a disposable meeting once and confirm the normal roster and audio/video.
2. Request one additional surface using the available UI or integration.
3. Verify which physical screen it occupies and what source it displays. Test changes of speaker, pin and screenshare where relevant.
4. Confirm the roster did not gain another participant and only the intended meeting audio plays.
5. Close the surface and confirm the primary meeting continues. Then leave the meeting and check cleanup of remaining surfaces.

The reviewed middleware also tears down second screens when leaving or failing the conference and attempts cleanup when the main page unloads. Browser/process termination can affect cleanup, so observe it rather than inferring it from a command. [S2]

Open questions and maintenance

This is a capability and integration guide based on pinned source. We have not completed a physical multi-monitor, kiosk permission, fullscreen or meeting-media test. The example is not a claim of verified compatibility for your browser/device combination. Recheck those prerequisites after browser, deployment or API-script changes. [S2][S3]

PiP has another purpose and another capability path. If you need an always-on-top compact meeting view, use PiP diagnostics. If other participants cannot see your shared content, use screen-sharing diagnostics.

Sources

• [S1] Official multi-screen announcement, 1 October 2026; feature context, not proof of deployment enablement.
• [S2] Pinned 11248 configuration, capability and window lifecycle, source types, middleware cleanup, and External API command/events/delegation.
• [S3] Window Management API support and permission model.