We were incorrectly doing comparison with `!= 0` to detect non-sRGB
tf/primaries. Since these enums are bit flags, the default sRGB values
are 1, not 0, so sRGB buffers were incorrectly rejected.
Fixes: bf40f396bf ("scene: grab image description from output state")
We'd attempt to parse an EDID even when the connector has no EDID,
printing "Failed to parse EDID" in logs. Instead, don't attempt to
parse the EDID and print a more appropriate log message.
It can be a bit confusing to understand why a compositor is shutting
down on its own. Log a message when we get disconnected from the
parent compositor to explain the cause.
The important bit here is whether this is using a single or two
sub-passes. The flag isn't used for anything else.
Preparation for an upcoming one-subpass codepath.
A combined image sampler may need several descriptors in a descriptor
set. We are not currently checking how many descriptors are required,
nor is it presumably guaranteed that such multi-descriptor allocation
will not fail due to fragmentation.
If the pool free counter is not zero, try to allocate but continue with
the next pool and fall back to creating a new pool if the allocation
failed.
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/4010
The issue occurred when `wlr_xwayland_shell_v1` was destroyed before
`wlr_xwayland`. This happened because `wlr_xwayland` didn't remove the
listener for the shell's destroy event in `handle_shell_destroy`.
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")
This sync includes minor non-breaking updates from recent years:
- Fix typos and grammatical issues (e.g. "a an" → "an", "inexistent" → "nonexistent")
- Improve description consistency with `wl_output` (e.g. name, description, make, model, serial)
- Add `destructor` annotation to relevant events (e.g. `finished` in foreign-toplevel)
- Clarify event emission timing and behavior for output management
- No functional or semantic protocol changes introduced
These changes improve the accuracy and consistency of protocol descriptions without impacting compatibility.
Upon leasing, the wlr_drm_lease_connector_v1 will be automatically clean up by the wlr_output
destroy handler. There is no need for the wlr_drm_lease_manager to keep track of leased connectors.
We grab header files from there, ensure include directories are
properly set up when building wlroots.
Fixes missing header files when a wayland-protocols subproject is
used.
We pass an alpha multiplier plus a luminance multiplier now.
Fixes the following validation layer error:
vkCmdPushConstants(): is called with
stageFlags (VK_SHADER_STAGE_FRAGMENT_BIT), offset (80), size (72)
but the VkPipelineLayout 0x510000000051 doesn't have a VkPushConstantRange with VK_SHADER_STAGE_FRAGMENT_BIT.
The Vulkan spec states: For each byte in the range specified by offset and size and for each shader stage in stageFlags, there must be a push constant range in layout that includes that byte and that stage (https://docs.vulkan.org/spec/latest/chapters/descriptorsets.html#VUID-vkCmdPushConstants-offset-01795) (VUID-vkCmdPushConstants-offset-01795)
Fixes: 56d95c2ecb ("render/vulkan: introduce wlr_vk_frag_texture_pcr_data")
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.
We can't expect all clients to support all fancy formats.
WebRTC's reference implementation doesn't support 10-bit formats
yet. More generally, clients are limited by the libraries they
use: for instance, Pixman doesn't implement all OpenGL/Vulkan
formats.
Another MR [1] suggests advertising all render formats. This is a
bit heavy-handed because:
- Upgrading a 8-bit buffer to a 10-bit buffer doesn't make a lot
of sense. I don't think the compositor should expose arbitrary
pixel format conversions.
- The protocol has no preference order. Clients generally pick the
first format they receive and support.
As an alternative, only advertise two fallback formats, ARGB8888
and XRGB8888. These two are already hard-required by wl_shm and
all clients should be able to handle them.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/5019
