The Game Opened on the Wrong Monitor

The ultrawide was where I wanted to play. The game disagreed.

A display problem that was not a performance problem

After moving my gaming desktop to EndeavourOS and Hyprland, I had a very ordinary annoyance: games sometimes opened on a secondary monitor instead of the ultrawide I intended to use. Minimizing a game sometimes gave me a way to move it, but that was a workaround, not a repeatable launch plan.

The hardware and desktop layout matter here. A multi-monitor session can have several plausible meanings for “primary”: the monitor physically centered on the desk, the output a compositor considers preferred, the workspace currently focused, and the display the game itself selects. Those are not interchangeable concepts.

I had also been testing Proton, MangoHud, and game-specific graphics settings. None of those experiments establishes that a display-placement issue is a rendering-performance problem. It is worth isolating placement before changing compatibility tools.

Observe before editing

Start with read-only Hyprland inspection:

hyprctl monitors
hyprctl activeworkspace
hyprctl clients

Record the exact output names and the focused workspace, then launch one affected game and inspect the client again. Output names must come from the running machine, not an example copied from somebody else’s configuration.

Ask three separate questions:

Which monitor owns the workspace where the new window appeared?
Did Hyprland assign the game to that workspace, or did the game switch display modes after launch?
Does the issue reproduce with a normal application window, or only with a particular game’s fullscreen mode?

If only one game behaves differently, investigate that game’s video settings and launcher options before rewriting the entire compositor layout.

A reversible change beats a global rule

For an initial test, use Hyprland’s existing window-move controls to move the affected window to the intended workspace. Confirm that the game remains usable and that its fullscreen behavior is acceptable. Only then consider a narrow window rule tied to a verified window class.

A rule that matches every fullscreen window can surprise you later. So can a hard-coded monitor name that changes when cables, docks, or GPU ports change. Preserve a copy of the working Hyprland configuration and make one targeted edit at a time.

Do not assume that moving a window is the same as changing the application’s selected display. Some games maintain their own monitor selection, especially when changing between windowed, borderless, and exclusive fullscreen modes.

Verification checklist

Check	Evidence to capture	What it proves
Outputs	`hyprctl monitors`	Current compositor output names and geometry
Workspace	`hyprctl activeworkspace`	Current focused workspace
Window	`hyprctl clients` after launch	Where the compositor sees the client
Game settings	In-game display and fullscreen selection	Whether the application overrides the expected placement
Recovery	Return to the saved configuration	Whether the change is reversible

The desired result is not merely “it opened on the ultrawide once.” It is repeatable placement after a fresh launch, with the other monitors still working normally.

What I know, and what remains untested

Observed: On my EndeavourOS/Hyprland desktop, games opened on the secondary display even though the ultrawide was my intended gaming screen. Minimizing sometimes made relocation possible.

Not yet established: A universal Hyprland rule, a specific game class, or a verified configuration change that permanently resolves this for every game. The commands above are inspection steps, not a claimed completed experiment.

This is a narrower lesson than a general Hyprland setup guide: first identify who controls placement, then change that layer.

References

Privacy and reproducibility

Output names, machine identifiers, private paths, and personal monitor serial numbers are deliberately omitted. Capture them locally when diagnosing a specific machine; do not publish raw diagnostics without review.

A decision tree for the next launch

The most useful next test is a controlled comparison, not another global display tweak. First record the output name and focused workspace with hyprctl monitors and hyprctl activeworkspace. Launch the same game twice from the same launcher without changing its graphics settings. After each launch, inspect hyprctl clients and note the actual window class, initial title, workspace, and monitor. Do not assume that the Steam launcher window and the game window share a class.

If the client is created on the wrong workspace, investigate the compositor’s workspace assignment and focus policy. If it is created on the expected workspace but displays elsewhere, investigate the window’s own monitor assignment and fullscreen transitions. If it moves only when switching from windowed to fullscreen, inspect the game’s display selector before changing a global compositor setting. A single successful launch is insufficient: repeat after closing the game and after a new login.

The current Hyprland window-rule reference documents a monitor effect for selecting where a matching window opens and a separate workspace effect. Static effects are evaluated at window creation, so matching the initial class or title matters. Hyprland’s configuration interfaces have changed across releases. Copying a rule from an older tutorial without checking the installed version can introduce a second problem. Use the syntax in the documentation corresponding to the installed Hyprland release, and apply a narrowly matched rule only after the client identity is known.

Observation	Next layer to inspect	Avoid changing first
Launcher is on the ultrawide, game is elsewhere	Game client class and initial window rule	Global monitor geometry
Game opens correctly windowed, then jumps on fullscreen	Game display selector and fullscreen behavior	Proton version
Every new window appears on the wrong output	Focused workspace and compositor defaults	Individual game rules
One game fails while others place correctly	That game’s launch and fullscreen settings	System-wide display order

Validation status: This is a documented diagnostic procedure, not a claim that a particular rule fixed my setup. The observed symptom remains the misplaced game window. Keep a copy of the previous configuration, test a single application at a time, and remove an unsuccessful rule before trying the next hypothesis.

Record the placement transition, not just the final screen

A screenshot of the game on the wrong monitor captures the symptom but not the transition that caused it. A useful local test records the state before launch, after the game window appears, and after changing fullscreen mode. Keep this worksheet locally rather than publishing unredacted command output.

Moment	Output and workspace	Client class/title	Windowed or fullscreen	What changed
Before launch	Capture with `hyprctl monitors` and `hyprctl activeworkspace`	No game client yet	N/A	Baseline
First game window	Capture with `hyprctl clients`	Copy the actual game client identity	Record observed mode	Creation and placement
After mode change	Inspect the same client again	Check whether identity or workspace changed	Record selected mode	Fullscreen transition
After fresh relaunch	Repeat the first-window inspection	Confirm the match is stable	Same initial mode	Reproducibility

This separates a window creation problem from a later fullscreen transition. If a proposed rule only affects window creation, it cannot be assumed to repair a game that changes its own output after launch. Conversely, changing the game’s video settings is unlikely to fix unrelated applications opening on the wrong focused workspace.

Keep the experiment reversible

Before editing any compositor configuration, copy the relevant file to a local backup outside the published site. Make one change, reload Hyprland using the mechanism supported by the installed version, and test both the affected game and an ordinary window. If the behavior worsens, restore the backup and reload again. Do not stack several speculative monitor, workspace, and fullscreen rules: overlapping changes make the outcome difficult to attribute.

When using a class-based rule, inspect the game client, not just Steam, Prism Launcher, or another launcher. A launcher may exit or spawn a distinct window with a different class. Confirm the match using the installed release’s window-rule reference and verify the result after a fresh login.

Evidence boundary: This worksheet and rollback method are recommended tests. They do not establish that a specific window rule was executed or that the original symptom has been permanently fixed. The known observation remains that the game sometimes appeared on the secondary monitor and minimizing made relocation possible.

Before Friday: distinguish compositor output names from physical labels

An output called DP-1 in one session is not a durable promise that the same connector name will identify the ultrawide forever. Inspect the current output inventory before writing any monitor-specific rule:

hyprctl monitors
hyprctl activeworkspace
hyprctl clients

Record the intended output name, resolution, refresh rate, scale, and current workspace, then inspect the game’s own client entry after its actual rendering window appears. Do not infer the game’s window class from the launcher process. If the window appears correctly at first and migrates only when fullscreen activates, repeat the inspection after the transition. That difference is evidence about when placement changed, not proof of which component caused it.

For a repeatable comparison, launch the same game twice with the same monitor arrangement and game display mode. Record whether the outcome is consistent; avoid claiming a permanent fix from one successful launch. For a configuration experiment, preserve the original file, change one matching rule, reload, and check that ordinary desktop windows still behave correctly. If the intended output disappears after a dock or cable change, restore the known-good configuration instead of assuming the old connector name remains valid.

Reference and limitation: Hyprland monitor configuration and window rules describe separate mechanisms; documentation paths and rule syntax can change between releases. Verify against the installed Hyprland version before copying an example. These checks are a proposed reproduction protocol, not a claim that the game was retested today.

Final pre-publication check: do not confuse moving a window with fixing launch placement

A successful manual move answers only whether the compositor can relocate the existing window. It does not show that a new game process will select the intended display. Treat the two as separate acceptance tests:

Check	Evidence to capture	What it does not prove
Existing window relocation	The actual game client appears on the ultrawide after a deliberate move	A subsequent launch will choose that monitor
Fresh game launch	The rendering window first appears on the intended output	Fullscreen transitions will preserve placement
Fullscreen transition	The client remains on the intended output after switching modes	Every game or Proton version behaves the same
Session restart	The same result occurs after a new Hyprland login	Connector identities remain stable after hardware changes

Use hyprctl version to record the compositor release, then hyprctl monitors, hyprctl activeworkspace, and hyprctl clients to capture current state. Do not publish a universal windowrule snippet without checking that release’s parser and the actual game window’s class or title. Hyprland’s window rules and monitor configuration are the primary references for that version-sensitive behavior.

The practical lesson is narrow: establish which layer changed placement before changing that layer’s configuration. For this machine, the observed workaround was minimizing and relocating the game. A persistent rule-based fix remains unverified, and no claim of a measured performance improvement follows from display placement alone.