One pixel screen padding on sway built against the newer wayland package (1.24.0)

[gryzus24]

Sway Version:

sway version 1.12-dev-340505bb (Aug 10 2025, branch 'master')

I'm compiling sway from the master branch on Arch Linux where the wayland package recently received an update to the version 1.24.0 from 1.23.1. Sway, once compiled on a system with the newer package version installed exhibits a weird issue. Whenever the cursor is positioned at the outermost edge of the screen I'm unable to interact with whatever element should be interactable therein (e.g. firefox scrollbar at the right edge of the screen or workspace buttons with numbers in the bottom-left corner) as if the screen had a 1 pixel padding to it. The element becomes interactable once I move the cursor 1 pixel in the direction of the element and the tip of the cursor sprite appears from behind the shroud of the screen edge. It appears the top edge of the screen is not affected (moving the swaybar to the top and clicking the workspace buttons works as expected).

Sway compiled against the older wayland package (1.23.1) behaves as desired irrespective of the wayland package version installed. It is the act of compiling sway against the newer package and running it that exhibits the issue. (Tested by soft-rebooting after every package upgrade/downgrade or sway rebuild).

I have tried disabling the secondary monitor in the config and compiling sway and sway alongside different wlroots versions (commits) up to one month back but everything points to some change in the wayland package (I haven't bisected it).

I have looked at the symmetric difference of the debug log of both "sways" (sway compilations) and haven't noticed anything interesting stand out.

As the issue will be present only among people compiling sway from sources directly I would be glad if someone confirms the finding (especially as I only have access to an nvidia GPU and it would be good to rule that one variable out).

[ThGrSoRu]

This sounds similar to what I've experienced after compiling wlroots only with the udmabuf allocator, leading to some sort of 1 pixel offset.
Try compiling with only the gbm or udmabuf allocator, and see if there's any difference.
My issue: #8769

[gryzus24]

While the issue looks similar, swaymsg -t get_outputs reports the same modeline values as the working version. I have tried compiling with only gbm and udmabuf allocators respectively but the issue persists. It is of note that it is not the physical resolution that is affected i.e. the view is not scaled back to 1919x1079 but the logical resolution is lacking the right-most and bottom-most line of pixels at the edges of the screen. As if program windows could be tiled/fullscreened to at most the aforementioned off-by-one resolution while the tip of the cursor could be moved over the "deactivated" line of pixels at the edges, thus, being outside the bounds of the window (and annoyingly, not respecting Fitts's law).

Also, outside the scope of the issue, sway compiled with only udmabuf allocator enabled does not activate any of my displays and is unusable in my case.

[emersion]

libwayland's version cannot affect Sway's rendering behavior.

[gryzus24]

And yet somehow the hashes of executables emitted by the compiler (both gcc and llvm) differ.

The only difference between the builds is the partial upgrade of wayland 1.23.1-2 -> 1.24.0-1. The name of the build directory and current time does not affect reproducibility. This is the compilation with the following build options enabled among others:

-D wlroots:default_library=static \
-D default_library=static \
-D default_both_libraries=static \

$ sha256sum build_12{31,40}/sway/sway
bbb4ec768807ffdcd0a4e423d895a7d57cc2a5398e71040672bdcb4ea9a8d673  build_1231/sway/sway
bee03d82eca8e8e4ef5c9d16c62c6eca4c3904461fa7b2f4bcc9c16cf1d7801e  build_1240/sway/sway

Even the seemingly non-relocatable error symbol from the .dynsym table (the executables were stripped) resolves to a different address.

$ icdiff.py <(readelf -W --syms build_1231/sway/sway) <(readelf -W --syms build_1240/sway/sway)
/dev/fd/63                                                                                      /dev/fd/62
   961: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (32)         961: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (32)
   962: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memmove@GLIBC_2.2.5 (3)                 962: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memmove@GLIBC_2.2.5 (3)
   963: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memset@GLIBC_2.2.5 (3)                  963: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memset@GLIBC_2.2.5 (3)
   964: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy@GLIBC_2.14 (33)                  964: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy@GLIBC_2.14 (33)
   965: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __register_atfork@GLIBC_2.3.2 (34)      965: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __register_atfork@GLIBC_2.3.2 (34)
   966: 00000000001ae[44]8   8 OBJECT  GLOBAL DEFAULT   28 error                                   966: 00000000001ae[a6]8   8 OBJECT  GLOBAL DEFAULT   28 error

And while I wholeheartedly believe that libwayland's version cannot affect Sway's rendering behavior the more customary build with wlroots compiled as a dynamic library results in identical executables (as expected):

$ sha256sum build_12{31_2,40_3}/sway/sway
52b2637e15b5de17e9be25b2610cf2e43a5dc34ef5303d66c0fcd75b703a3bd6  build_1231_2/sway/sway
52b2637e15b5de17e9be25b2610cf2e43a5dc34ef5303d66c0fcd75b703a3bd6  build_1240_3/sway/sway

Yet the issue persists (build_1231 works, build_1240 doesn't). This leads me to believe that it is some difference in these objects that causes the issue:

libwayland-server.so.0 => /usr/lib/libwayland-server.so.0 (0x00007f3083eca000) [ASLR mangled]
libwayland-client.so.0 => /usr/lib/libwayland-client.so.0 (0x00007f30839f8000) [ASLR mangled]

[gryzus24]

I have found the culprit commit in the wayland repository: https://gitlab.freedesktop.org/wayland/wayland/-/commit/f246e619d17deb92f414315d1747a9b7aca659b9

The wl_fixed_from_double has a lot of callers throughout the wlroots code base and there is a bug-prone incongruity with signed fixed point 24.8 and double conversions (there is probably a fairly good reason for dealing with doubles there but it would be arguably better to expose the fixed_t interface and open-code the shifts and masks). The commit that introduces the round call is nebulous as to what problem it solves (what does the imprecision in the conversion entail?). Also, changing the rounding behavior from "truncation" to "rounding half away from zero" is undoubtedly a breaking change as there are a lot of exclusive range semantics in wlroots (e.g. struct box, fbox).

I haven't been able to locate the problematic conversion yet.

Some observations:

• Moving the pointer to the very bottom of the screen causes the coordinates (of a local surface?) of the swaybar to report 21.999985 indicating that my swaybar has the height of 22 pixels and the sx, sy coordinates of the pointer are warped to the double and converted to a fixed_t of 5632 instead of 5631 before, i.e. 5632 & 255 == 0, 5631 & 255 == 255 - which is a possible incongruity.
• Changing the rounding behavior from "round half away from zero" to "round half up" ((fixed_t)(d * 256.0 + 0.5)) still causes the problem described in the issue which indicates that it is most likely caused by the rounding of a positive number.

@emersion, I'm not familiar with the code base enough to locate the precise issue in a reasonable time frame (obviously reverting the linked commit fixes this issue, though it might hide the real problem that rounding exposed), could you take a look? Thanks.

[eternal-sorrow]

I have this problem but only at the bottom and right of the screen. I have my bar at the bottom and cannot switch workspaces when the cursor is all the way down. I can press my Firefox tabs at the top of the screen normally. I cant interact with Firefox scrollbar when the cursor is all the way right, but I can interact with widgets all the way left.

[eternal-sorrow]

I tried to downgrade wayland to 1.23.1, but sway refused to start, even though it and wlroots both compiled well against that version of wayland. It complained about EGL_EXT_platform_base not supported.

[eternal-sorrow]

Reverting the mentioned commit didn't fix the issue in my case.

[gryzus24]

Reverting the mentioned commit didn't fix the issue in my case.

Are you sure you rebuilt sway against the correct wayland headers (with the revert). The most reliable way to test it is to just manually edit the /usr/include/wayland-util.h like so:

@@ -643,7 +643,7 @@ wl_fixed_to_double(wl_fixed_t f)
 static inline wl_fixed_t
 wl_fixed_from_double(double d)
 {
-       return (wl_fixed_t) (round(d * 256.0));
+       return (wl_fixed_t) (d * 256.0);
 }

I'm 99% sure the round call is the culprit here. Reverting the commit and building sway's master branch against the newest wayland headers resolves the issue in my case.

[yuiiio]

https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/448 seems restore the behavior before https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/351

I also create wayland repository issue(https://gitlab.freedesktop.org/wayland/wayland/-/issues/555) but,
Is it going to be "wontfix" ?

[eternal-sorrow]

I can confirm that with edited /usr/include/wayland-util.h and rebuilt wlroots and sway the problems goes away.

[WhyNotHugo]

I can reproduce this issue on Alpine's native packages for a few months now.

Today I reverted this patch to libwayland, https://gitlab.freedesktop.org/wayland/wayland/-/commit/f246e619d17deb92f414315d1747a9b7aca659b9, recompiled wlroots and sway. I can confirm that this fixes the issue.

My exact patch is:

From 8b01a1f219fdce60e6a63048fb694d4bade77a4b Mon Sep 17 00:00:00 2001
From: Hugo Osvaldo Barrera <hugo@whynothugo.nl>
Date: Wed, 17 Sep 2025 22:51:08 +0200
Subject: [PATCH] Revert "util: reduce error of wl_fixed_from_double()"

This reverts commit f246e619d17deb92f414315d1747a9b7aca659b9.
---
 src/wayland-util.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/wayland-util.h b/src/wayland-util.h
index 98c72fd..816b3a6 100644
--- a/src/wayland-util.h
+++ b/src/wayland-util.h
@@ -643,7 +643,7 @@ wl_fixed_to_double(wl_fixed_t f)
 static inline wl_fixed_t
 wl_fixed_from_double(double d)
 {
-	return (wl_fixed_t) (round(d * 256.0));
+	return (wl_fixed_t) (d * 256.0);
 }
 
 /**
-- 
2.51.0

I'm not confident that this is entirely correct and doesn't break anything else, but it most definitely fixes this issue.