When doing an output configuration search, the intent is to only look
for modes if the output's configuration does not contain a specific
mode. This was done by testing if config_has_auto_mode returned false.
config_has_auto_mode had its return values backwards, leading to other
modes being tested if the output configuration had specified modes or
modelines, leading to unwanted modes being selected.
Invert the function to config_has_manual_mode to give it a clearer name,
and fix the return values in the process.
After 4e38f93f36 ("config/output: Skip VRR tests when not supported"),
the configuration search no longer touches VRR state for outputs that
are known to not support it. This also means that it will not remove VRR
if already set, which could cause output configuration to fail.
Ensure that VRR state is never set for outputs that do not support it by
adding the same test for support to queue_output_config.
Fixes: 4e38f93f36 ("config/output: Skip VRR tests when not supported")
Fixes: https://github.com/swaywm/sway/issues/8296
Adaptive sync is a "soft" setting which we degrade of off when not
supported. Some outputs types do not support turning it off (Wayland,
X11), which makes for an awkward three-way test where we first enable,
disable and finally unset the setting.
wlr_output.adaptive_sync_supported tells us whether the output
definitely does not support making changes (backend without support,
connector without the feature), or whether it might work.
Use this to avoid wasting time on adaptive sync test that can never
succeed, and to avoid the Wayland/X11-backend specific unset step.
We were only passing the color transform when calling
wlr_scene_output_commit(). However when modesetting or pushing a
new gamma LUT we render via wlr_scene_output_build_state(). Pass
the color transform there as well.
The only reason it's included there is for a declaration of
struct sway_server, but we can just forward-declare it.
This avoids rebuilding almost all of Sway when touching server.h.
All other server.h includes are from source files, not headers.
If there's no config for the output, oc is null, but some screens might
have a default rotation, causing the log call to dereference a null
pointer.
Signed-off-by: Anna (navi) Figueiredo Gomes <navi@vlhl.dev>
Instead of having each search function print its various test decisions,
print the full state at the end of every search. This makes it much
clearer what state a particular test includes.
The original sway output config implementation enabled one output at a
time, testing modes, render formats and VRR support as it went along.
While this sort of fallback is easy to do, it has the downside of not
considering the effect of neighbor outputs on the configuration
viability.
With backend-wide commits, we can now better consider the effect of
neighbor outputs, but to handle the fact that we commit all outputs at
once we need to perform a more elaborate search of viable
configurations.
Implement a recursive configuration search for when the primary
configuration failed to apply.
When storing a config, we need to find the output that is being
configured to extract its identifier. output_by_name_or_id does not
return outputs that are disabled, and using this makes it impossible to
merge configurations related to disabled outputs.
Switch to all_outputs_by_name_or_id.
Fixes: https://github.com/swaywm/sway/issues/8141
If there is no output currently connected, we still want to merge
to any existing config.
It shouldn't matter to iterate over the list of outputs to do
nothing anwyays.
../sway/config/output.c:33:21: runtime error: member access within null pointer of type 'struct sway_output'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==7856==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000080 (pc 0x63da8558205c bp 0x7ffdc35881a0 sp 0x7ffdc3588160 T0)
==7856==The signal is caused by a READ memory access.
==7856==Hint: address points to the zero page.
#0 0x63da8558205c in output_get_identifier ../sway/config/output.c:33
#1 0x63da855865c3 in store_output_config ../sway/config/output.c:220
#2 0x63da855d4066 in cmd_output ../sway/commands/output.c:106
#3 0x63da8547f2e3 in config_command ../sway/commands.c:425
#4 0x63da8548f3fc in read_config ../sway/config.c:822
#5 0x63da8548a224 in load_config ../sway/config.c:435
#6 0x63da8548b065 in load_main_config ../sway/config.c:507
#7 0x63da854bee8d in main ../sway/main.c:351
#8 0x77e2ea643ccf (/usr/lib/libc.so.6+0x25ccf) (BuildId: c0caa0b7709d3369ee575fcd7d7d0b0fc48733af)
#9 0x77e2ea643d89 in __libc_start_main (/usr/lib/libc.so.6+0x25d89) (BuildId: c0caa0b7709d3369ee575fcd7d7d0b0fc48733af)
#10 0x63da8547ad64 in _start (/home/simon/src/sway/build/sway/sway+0x372d64) (BuildId: 3fa2e8838c1c32713b40aec6b1e84bbe4db5bde8)
Fixes: 1267e47de9 ("config/output: Refactor handling of tiered configs")
Output configuration can be applied to a particular output in three
ways: As a wildcard, by connector name and by identifier. This in turn
means that three different configurations must be handled at any given
time.
In the current model, this is managed by merging new configuration into
every other matching configuration. At the same time, an additional
synthetic configuration is made which matchehes both identifier and name
at the same time, further complicating logic.
Instead, manage and store each configuration independently and merge
them in order when retrieving configuration for an output. When changes
are made to a less specific configuration, clear these fields from more
specific configurations to allow the change to take effect regardless of
precedence.
Fixes: https://github.com/swaywm/sway/issues/8048
apply_output_config_to_outputs uses the specified output config to check
which outputs to apply to, and to use as backup when no config is found.
If any config matches the output, the specified config will be
disregarded.
The only remaining user of apply_output_config_to_outputs is
reset_outputs, which called apply_output_config_to_outputs with either
the first stored wildcard config, or a new empty wildcard config.
Providing a stored or empty wildcard config is practically the same as
calling `apply_all_output_configs`. Replace uses of `reset_outputs` with
`apply_all_output_configs` and remove the now unused functions.
Introduce apply_output_configs, which applies the specified matched
output configs as a single backend commit.
Reimplement apply_output_config_to_outputs using apply_output_configs.
Applying an output config has two stages: Atomic application of
wlr_output_state, and applicaiton of non-atomic state like output
layout.
Split the latter out into finalize_output_config for use in a later
commit.
This doesn't catch the error if a background changing command is
executed via swaymsg, but improves logging.
The additional checks at least propagate if e.g. forking failed.
Previous behavior was that only if resolution and refresh rate match
exactly, the mode was accepted. As fallback, the mode with the highest
refresh rate and the same resolution was chosen.
New behavior is that the mode with the closest match for the refresh
rate is used with a limit of up to 1Hz. The fallback behavior stays the same.
Additionally, the logging was made more verbose.
This makes it possible to hint to the renderer and backends how many
bits per channel the buffers that the compositor draws windows onto
should have. Renderers and backends may deviate from this if they
do not support the formats with higher bit depth.
Wayland compositors handle many file descriptors: client
connections, DMA-BUFs, sync_files, wl_data_device pipes, and so
on. Bump the limit to the max.
Closes: https://github.com/swaywm/sway/issues/6285
Sometimes the preferred mode is not available due to hardware
constraints (e.g. GPU or cable bandwidth limitations). In these
cases it's better to fallback to lower modes than to end up with
a black screen.
Before this commit, when an output had its scale dynamically changed,
Sway would not load a cursor theme with the new scale. This results
in stale cursor images when moving the cursor into an area controlled
by the compositor, like the background or resize areas.
To reproduce:
- Using IPC, set an output scale to a value that isn't currently used
- Move the cursor into a compositor-controlled area
- The cursor will not change
Previously, we called output_disable prior to wlr_output_commit. This
mutates Sway's output state before the output commit actually succeeds.
This results in Sway's state getting out-of-sync with wlroots'.
An alternative fix [1] was to revert the changes made by output_disable
in case of failure. This is a little complicated. Instead, this patch
makes it so Sway's internal state is never changed before a successful
wlr_output commit.
We had two output flags: enabled and configured. However enabled was set
prior to the output becoming enabled, and was used to prevent the output
event handlers (specifically, the mode handler) from calling
apply_output_config again (infinite loop).
Rename enabled to enabling and use it exclusively for this purpose.
Rename configure to enabled, because that's what it really means.
[1]: https://github.com/swaywm/sway/pull/5521
Closes: https://github.com/swaywm/sway/issues/5483
Kenny Levinsen
Kirill Primak
Ricardo Steijn
Simon Ser
Manuel Stoeckl
Anna (navi) Figueiredo Gomes
Tamino Bauknecht
Alexander Orzechowski
Alexander Orzechowski
Carl Smedstad
Simon Zeni
David Rosca
Tadeo Kondrak
Ronan Pigott