If a floating window is using CSD, the geometry should not be used to
define the clipping region. Otherwise drop shadows and such may be
clipped excessively.
Instead of having a build-time option to enable/disable xwayland
support, just use the wlroots build config: enable xwayland in
Sway if it was enabled when building wlroots. I don't see any
use-case for disabling xwayland in Sway when enabled in wlroots:
Sway doesn't pull in any additional dependency (just pulls in
dependencies that wlroots already needs). We have a config command
to disable xwayland at runtime anyways.
This makes it so xwayland behaves the same way as other features
such as libinput backend and session support. This also reduces
the build matrix (less combinations of build options).
I think we originally introduced the xwayland option when we didn't
have a good way to figure out the wlroots build config from the
Sway build system.
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
We want to check if a config_head existed for the current
matched_output_config, so we should check cfg->output. sway_output is a
temporary variable from a previous wl_list_for_each, and does not
contain anything useful to us.
Fixes: https://github.com/swaywm/sway/issues/8128
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
Without this change, i see the following in the sway-ipc manpage:
```
9. GET_CONFIG
MESSAGE
Retrieve the contents of the config that was last loaded
REPLY
An object with a single string property containing the contents of the
config
Example Reply:
{
"config": "set $mod Mod4nbindsym $mod+q exitn"
}
```
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.
If we can't create the XKB keymap used for keysym translation,
gracefully error out instead of crashing. This can happen if the
XKB_DEFAULT_LAYOUT is set to an invalid value, for instance.
Closes: https://github.com/swaywm/sway/issues/7789
My code archaeology isn't good enough to determine what this is here
for, but it isn't correct. We should be able to move containers in a
direction without focusing them. AFAICT i3 doesn't do this, so we
shouldn't either.
This fixes ipc commands like move <dir> with criteria that apply to
containers which are not the current focus.
i3 has had this property for over a decade but it wasn't documented
until a couple of years ago, so it was likely missed when developing
sway. Add the property to get us closer to ipc parity with i3.
