Monitors and virtual screens

What a context is

A context is the combination of three things: which screen, which virtual desktop, and which activity. Every layout assignment hangs off a context, which is why the same monitor can hold a three-zone layout on one desktop and scroll on the next.

The mode is part of the assignment too, not a separate setting. Assigning a scrolling template to a context puts that context in scrolling mode. Meta+Shift+T cycles the focused screen through the modes you have enabled, and each mode remembers its own layout for that context, so cycling away and back does not lose your arrangement.

How an assignment resolves

This is worth knowing because it is not a lookup table with a specificity ladder, which is the usual guess.

Assignments resolve through the same rule engine that powers window rules. A context assignment is a rule whose match pins the screen, desktop, or activity, and whose action sets the mode and layout. Resolution evaluates those rules with no window in hand and takes the highest-priority match for each slot.

There is no specificity formula. A rule pinning all three of screen, desktop, and activity does not automatically beat one pinning only the screen. Priority is the only precedence value, with ties broken by list order. If a narrow assignment is losing to a broad one, its priority is the thing to change. When nothing matches at all, the context falls back to the settings-gated default.

One consequence worth internalizing: because this is the same engine, a window rule and a layout assignment can be authored in the same file and can interact. The per-context overrides in the action list are exactly this mechanism pointed at one screen: locking a context, overriding the default assignment, and suppressing on-screen displays.

How a monitor is identified

An assignment is worthless if the monitor it names stops being recognizable after a reboot or a cable swap, so monitors are identified by EDID rather than by connector, with fallbacks:

• Manufacturer:Model:Serial The normal case. Survives being moved to a different port.
• Manufacturer:Model When the panel reports no serial.
• Manufacturer:Model:Serial/CONNECTOR To tell apart two identical monitors that report identical EDID.
• The connector name Such as DP-2, when the EDID is empty altogether.

Lookup also has a fallback chain, and it is a rewrite rather than a ranking: a miss on the stored id is retried against the connector-name-to-stable-id mapping, and then against a virtual screen's underlying physical id. An assignment made before a monitor was properly identified therefore keeps working rather than silently detaching.

Virtual screens

A virtual screen subdivides one physical monitor into regions that PlasmaZones treats as separate screens. On a 49-inch ultrawide this is what stops a single layout from having to span the whole panel: split it into two, and each half gets its own mode, its own layout, and its own window set.

Each physical monitor takes between 2 and 10 virtual screens, and they are named Screen 1, Screen 2, and so on until you rename them. Because each one is a screen as far as the rest of the system is concerned, everything context-scoped applies to it: assignments, per-screen setting overrides, and rules that pin a screenId.

Regions are expressed as fractions of the physical screen, so a subdivision survives a resolution change.

Moving between them

These mirror the window-scope shortcuts with an extra Shift: swapping a window is Meta+Ctrl+Alt+Arrow, so swapping a whole virtual screen adds Shift on top. All per-screen state follows the new geometry, so a swap takes the windows, the layout, and the mode with it.

The Alt in those chords is not decorative. KWin owns Meta+Ctrl+Shift+Arrow for its own "window one desktop over" actions, so a binding without the Alt gets grabbed by KWin and the PlasmaZones action never fires. Keep the Alt if you rebind these.

Per-screen setting overrides

Many settings can differ per monitor rather than only globally. In the settings app these carry a scope chip on the card, letting you set a value for one monitor while the rest follow the global default. Strip direction is the clearest example: a portrait side panel can run its strip top to bottom while the main screen stays side to side.

When a setting has both a global value and a per-screen override, the override wins for that screen only, and a rule action layers over both. The settings reference lists the global keys. Per-screen values are stored separately under a per-screen container rather than replacing the global key.

Next

• Window rules → The same engine that resolves these assignments, pointed at windows.
• Settings reference → The global defaults a per-screen override departs from.
• Keyboard shortcuts → The full virtual-screen family, with the rebinding caveat.
• D-Bus scripting → Reading and writing the virtual-screen configuration from a script.