Limiting the position to (x + width - 1, y + height - 1) created a 1px
"dead zone" at monitor edges, noticeable with high-resolution mice with
motion deltas of <1px.
See: https://github.com/swaywm/sway/issues/8110
Using (x + width - 1/65536, y + height - 1/65536) instead should make
the "dead zone" small enough to be unobservable, while the value 1/65536
is still large enough to avoid rounding to zero (due to loss of
significant digits) in simple floating-point calculations.
This does expose a client-side bug in Qt layer-shell applications,
noticeable in right/bottom panels which do not accept positions beyond
(x + width - 1, x + height - 1) as valid - thus driving the cursor
to the bottom/right of the screen to click on the panel does not work.
I don't have a good workaround for this, and probably it needs to be
fixed in Qt itself.
Fixes: 3fc66d4525
("util: fix non-linear behavior of wlr_box_closest_point()")
Per comments in util/box.h, the width and height of a wlr_box are
exclusive; that is, for a 100x100 box at (0,0), the point (99,99) is
inside it while the point (100,100) is outside it.
Thus mathematically, there exists no single closest point to the
bottom-right corner of the box while remaining inside it. You can
construct an infinite series approaching the limit, such as {(99,99),
(99.9,99.9), (99.99,99.99)...}, but since the intervals are half-open,
there is no "last" point.
wlr_box_closest_point() must therefore define an arbitrary "closest"
point. For points below and to the right of the box, the current
implementation returns (box.x + width - 1, box.y + height - 1). Let's
continue to do this.
However, the current implementation is non-linear: with the example
100x100 box, it will return an input point of (99.9,99.9) unchanged, but
for an input point (100.1,100.1) the returned point will jump back to
(99.0,99.0).
In practice, this non-linearity results in strange behaviors when
driving the mouse cursor to a screen corner. On a 1920x1080 display for
example, driving the cursor quickly to the bottom-left corner results in
a position of exactly (0,1079). Continuing to slowly nudge the cursor
downward results in the position jumping between (0,1079) and other,
fractional coordinates such as (0,1079.88).
The fractional coordinates expose some client/toolkit-side bugs (which,
to be clear, should be fixed on the client side), but IMHO the wlroots
behavior is also inconsistent and wrong -- when I drive the mouse cursor
into the corner of the screen, it should come to a stop at a fixed
position, not jitter around.
Stop trying to maintain a per-file _POSIX_C_SOURCE. Instead,
require POSIX.1-2008 globally. A lot of core source files depend
on that already.
Some care must be taken on a few select files where we need a bit
more than POSIX. Some files need XSI extensions (_XOPEN_SOURCE) and
some files need BSD extensions (_DEFAULT_SOURCE). In both cases,
these feature test macros imply _POSIX_C_SOURCE. Make sure to not
define both these macros and _POSIX_C_SOURCE explicitly to avoid
POSIX requirement conflicts (e.g. _POSIX_C_SOURCE says POSIX.1-2001
but _XOPEN_SOURCE says POSIX.1-2008).
Additionally, there is one special case in render/vulkan/vulkan.c.
That file needs major()/minor(), and these are system-specific.
On FreeBSD, _POSIX_C_SOURCE hides system-specific symbols so we need
to make sure it's not defined for this file. On Linux, we can
explicitly include <sys/sysmacros.h> and ensure that apart from
symbols defined there the file only uses POSIX toys.
While the xdg-shell protocol requires this, it does not yet have
a dedicated error code for invalid titles; this commit makes
wlroots send a generic error instead.
TOKEN_STRLEN is not actually the strlen() of the token. It's the
size taken by the token included the final zero byte.
Change the name to make this clearer, and remove unnecessary +1's.
The new struct rect_union is designed to make it easier to
efficiently accumulate a list of rectangles, and then operate
on an exact cover of their union.
Using rect_union, the times needed to added t rectangles, and then
compute their exact cover will be O(t), and something between Ω(t) and
O(t^2), depending on the rectangle arrangement. If one tries to do
the same by storing a pixman_region32_t and updating it with
pixman_region32_union_rect(), then total time needed would be between
Ω(t^2) and O(t^3), depending on the input. Without changing the public
API (data structure + rectangle ordering rules) for pixman_region32_t,
it is impossible to improve its worst case time.
0xFFFFFFFF milliseconds is 4,294,967,295 ms so about 50 days.
A little bit too close for comfort.
Use int64_t instead of uint64_t to avoid C's implicit conversion
footguns in computations.
array_realloc will grow the array for the target size like wl_insert_add, but
will also shrink the array if the target size is sufficiently smaller than the
current allocation.
If the display is destroyed before wlr_global_destroy_safe's timer
fires, the struct destroy_global_data is leaked. This shouldn't cause
issues in practice because the timer will never fire, but makes it
harder to spot compositor memory leaks.
When testing Xwayland multi-HiDPI support with Wine + SimCity4
I encountered a 100% CPU lockup from sway. This turned out to be
triggering a bug in the wlroots pointer contraint code.
region_confine() contains multiple recursive calls where arguments
are modified and resubmitted to the function. One of the calls
is however made using the original arguments, if/when this triggers
it results in the same codepath being followed each loop so the
condition always applies.
It makes much more sense if this was intended to apply the clamped
values x,y instead of the original x1,y1, and indeed this fixes the
infinite loop and results in correct behaviour.
This function behaves like allocate_shm_file, except it also
returns a read-only FD. This is useful to share the same segment
of memory with many Wayland clients.
