Skip to content

Commit 733cd91

Browse files
committed
post: write up sway misclick post and add code block default to styleguide
1 parent 8d42420 commit 733cd91

File tree

2 files changed

+47
-5
lines changed

2 files changed

+47
-5
lines changed

AGENTS.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -134,7 +134,7 @@ Guidelines for tone, punctuation, and structure in blog post content.
134134
- Open with a short paragraph that sets up the problem and gives enough context (what system, what hardware, what the symptom was) for a reader to know if this post is relevant to them.
135135
- Use `##` headings to break the post into logical sections. Each section should advance the narrative or introduce a new concept.
136136
- End with a summary or outcome, not a call to action or sign-off. A short closing reflection that ties the post to a broader theme or links to a related post is fine, as long as it adds context rather than generic optimism.
137-
- Code blocks should use language hints where appropriate (e.g. ` ```nix `, ` ```rust `).
137+
- Code blocks should use language hints where appropriate (e.g. ` ```nix `, ` ```rust `). If the language is unknown, default to `console`.
138138

139139
### Links
140140

Lines changed: 46 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,51 @@
11
+++
22
title = 'A sway misclick'
33
date = 2024-05-12T12:48:00Z
4-
draft = true
4+
draft = false
5+
tags = ['linux', 'sway', 'gaming', 'wayland', 'debugging']
56
+++
67

7-
- Wine + Sway
8-
- Cursor tracking in Game but clicks not registering
9-
- Check screen `pos` params.
8+
On a Sunday morning I sat down to start playing a Steam game via Proton on my Framework 13 laptop. Upon booting into the game I noticed that the cursor tracked perfectly, moving exactly where I expected it to, but clicks never registered. I could hover over a button in the game, click, and nothing would happen.
9+
10+
I hadn't used the laptop for gaming in a long while, the Steam Deck had mostly taken over that role, but I had a hankering for a more mouse-driven game and the Framework 13 has plenty of power for these cases.
11+
12+
## The setup
13+
14+
I run [Sway](https://swaywm.org/) as my tiling window manager of choice and have multiple outputs defined for when the laptop is docked at my desk. I had a suspicion that this had something to do with my multi-monitor setup since the game I was playing had worked great on my Desktop (where I only have 1 monitor) on the exact same NixOS setup.
15+
16+
My sway config looked like this:
17+
18+
```console
19+
output "eDP-1" {
20+
scale = "1.5";
21+
pos = "760 1440";
22+
}
23+
24+
output "HDMI-A-1" {
25+
mode = "3440x1440@100Hz";
26+
pos = "0 0";
27+
}
28+
```
29+
30+
The `pos` on `eDP-1` offsets the laptop display below and to the right of my desk monitor, so when both are connected the layout makes sense. The problem is that this config is always active, even when the laptop is undocked and `eDP-1` is the only display.
31+
32+
## What was happening
33+
34+
This turns out to be a [known Sway bug](https://github.com/swaywm/sway/issues/6651). With `eDP-1` positioned at `(760, 1440)` in the compositor's coordinate space, the game's cursor rendering and click coordinates diverge. The cursor draws at the correct visual position on screen, but Xorg applications (including games running via Proton/Wine) send click events using coordinates that include the `pos` offset. So the compositor receives a click at `(760 + x, 1440 + y)` when the game intended `(x, y)`. With no other display connected, those offset coordinates land outside the visible area.
35+
36+
Wayland-native applications are unaffected, this only hits Xorg applications running through XWayland.
37+
38+
## The fix
39+
40+
I set `eDP-1` to `pos = "0 0"`. Since I don't frequently use the laptop display alongside the desktop monitor, there's no need for the offset to be permanently set:
41+
42+
```console
43+
output "eDP-1" {
44+
scale = "1.5";
45+
pos = "0 0";
46+
}
47+
```
48+
49+
After applying the config, clicks registered immediately.
50+
51+
For a proper solution that handles both docked and undocked layouts, [Kanshi](https://wiki.archlinux.org/title/Kanshi) can switch output profiles automatically based on which displays are connected. Something to set up if I start hotplugging displays more regularly.

0 commit comments

Comments
 (0)