When attaching more than one cursor to wlr_output, the first one
will pick the output's hardware cursor, then for the second one
output_set_hardware_cursor() would fail (since the hardware cursor
was already taken), but we still ended up resetting the current
hardware cursor (by calling output_disable_hardware_cursor() below).
As a result only the second cursor would be displayed.
To fix this, move the current hardware cursor check to the caller.
Fixes: 510664e79b ("output: disable hardware cursor when falling back to software")
We were iterating over involved outputs, applying the new state and
sending the commit event for each one. This resulted in commit
events being fired while we weren't done applying the new state for
all outputs.
Fix this by first applying all of the states, then firing all of
the events.
Closes: https://github.com/swaywm/sway/issues/8829
When we fail to render the cursor (in my case because the cursor is too
large) we bail out of the output_cursor_attempt_hardware function. This
causes output_cursor_set_texture to clean up after us, but we've already
cleared the hardware_cursor, and so output_disable_hardware_cursor
thinks we don't have a hardware cursor to disable.
We shouldn't modify the hardware_cursor variable before we've
successfully changed the hardware cursor, this way the caller can clean
up after us like it expect to.
This was brought up by an actual bug when playing the game Kaizen. Which
uses oddly sized cursors, that fell back to software cursors for me, and
left the hardware cursor hanging around. This change has been tested to
fix that.
During the testing of this change, I have noticed that the previous code
worked fine the first time the cursor was switch to software. It only
failed on subsequent attempts. I haven't figured out why that is.
Color transforms are better suited than raw gamma tables, because:
- They don't need to get copied around: they are ref'counted.
- They can represent more color operations (will be useful for the
upcoming KMS color pipeline API, and for the Wayland color
management protocol).
Follow-up from !4803. Make things consistent by making all `struct
timespec`s in events owned. Reduces the need for thinking about
ownership/lifetimes.
Replace them with pixman_region32_empty(), which avoids using a
double-negative when checking if a region is empty. Also use that
new function when checking for non-empty regions so that only one
variant of the Pixman API is used.
Up until now only the DRM backend required an output commit after
updating the cursor. Unify this for all backends, because:
- Screen capture can now catch cursor updates listening for output
commits
- In the future we want to make the cursor a regular wlr_output_layer,
which would need an output commit to be updated anyways
We'd print "cursor texture size exceeds hardware limitations" when
some hardware doesn't support cursors at all. Change the message
to better indicate the cause.
Enable scene-tree direct scanout of a single buffer with various options
for scaling and source crop. This is intended to support direct scanout
for fullscreen video with/without scaling, letterboxing/pillarboxing
(e.g. 4:3 content on a 16:9 display), and source crop (e.g. when
1920x1088 planes are used for 1920x1080 video).
This works by explicitly specifying the source crop and destination box
for the primary buffer in the output state. DRM atomic and libliftoff
backends will turn this into a crop and scale of the plane (assuming the
hardware supports that). For the Wayland/X11/DRM-legacy backends I just
reject this so scanout will be disabled.
The previous behaviour is preserved if buffer_src_box and buffer_dst_box
are unset: the buffer is displayed at native size at the top-left of the
output with no crop.
The change to `struct wlr_output_state` makes this a binary breaking
change (but this works transparently for scene-tree compositors like
labwc after a recompile).
Since wlr_damage_ring now only works with buffer local coordinates, this
creates an inpedance mismatch for compositors that want to use this
function. Instead of compositors needing to the the conversion itself,
change thu function to take buffer local coordinates directly.
The DRM backend's set_cursor function always return true if the
buffer is NULL. If using a NULL cursor's buffer on startup, the
wlr_output_cursor will be marked as a hardware cursor. If the
cursor later gains a non-NULL buffer and the DRM backend rejects
that buffer, the cursor will remain marked as a hardware cursor,
despite the backend not displaying it as such. As a result, the
cursor will not be displayed at all. Fix this by always resetting
the hardware_cursor field in output_cursor_attempt_hardware().
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.
Sadly, the new API is not backwards compatible with the old API. Since
we have already switched all users in wlroots to the new API compositors
are already practically mandated to implement the new API. Let's get rid
of the old one since there is no point.
