handle_destroy would mark the output es being destroyed and commit the
transaction. Committing the transaction results in the output being
freed, the output manager can not retrieve the server reference
afterwards, resulting in the following use-after-free:
==22746==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000017088 at pc 0x560c1ac17136 bp 0x7ffeab146f20 sp 0x7ffeab146f10
READ of size 8 at 0x614000017088 thread T0
#0 0x560c1ac17135 in handle_destroy ../sway/desktop/output.c:566
#1 0x7f38af69330e in wlr_signal_emit_safe ../subprojects/wlroots/util/signal.c:29
#2 0x7f38af5d3dfc in drm_connector_cleanup ../subprojects/wlroots/backend/drm/drm.c:1448
#3 0x7f38af5d2058 in scan_drm_connectors ../subprojects/wlroots/backend/drm/drm.c:1240
#4 0x7f38af5c6a59 in drm_invalidated ../subprojects/wlroots/backend/drm/backend.c:135
#5 0x7f38af69330e in wlr_signal_emit_safe ../subprojects/wlroots/util/signal.c:29
#6 0x7f38af5e827a in udev_event ../subprojects/wlroots/backend/session/session.c:52
#7 0x7f38aef5d7f1 in wl_event_loop_dispatch (/usr/lib/libwayland-server.so.0+0xa7f1)
#8 0x7f38aef5c39b in wl_display_run (/usr/lib/libwayland-server.so.0+0x939b)
#9 0x560c1ac0afbe in server_run ../sway/server.c:225
#10 0x560c1ac09382 in main ../sway/main.c:397
#11 0x7f38aed35ce2 in __libc_start_main (/usr/lib/libc.so.6+0x23ce2)
#12 0x560c1abea10d in _start (/usr/local/bin/sway+0x3910d)
0x614000017088 is located 72 bytes inside of 432-byte region [0x614000017040,0x6140000171f0)
freed by thread T0 here:
#0 0x7f38af82df89 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:66
#1 0x560c1acbd1ed in output_destroy ../sway/tree/output.c:243
#2 0x560c1ac23ce5 in transaction_destroy ../sway/desktop/transaction.c:66
#3 0x560c1ac26b71 in transaction_progress_queue ../sway/desktop/transaction.c:348
#4 0x560c1ac284ca in transaction_commit_dirty ../sway/desktop/transaction.c:539
#5 0x560c1ac17110 in handle_destroy ../sway/desktop/output.c:564
#6 0x7f38af69330e in wlr_signal_emit_safe ../subprojects/wlroots/util/signal.c:29
#7 0x7f38af5d3dfc in drm_connector_cleanup ../subprojects/wlroots/backend/drm/drm.c:1448
#8 0x7f38af5d2058 in scan_drm_connectors ../subprojects/wlroots/backend/drm/drm.c:1240
#9 0x7f38af5c6a59 in drm_invalidated ../subprojects/wlroots/backend/drm/backend.c:135
#10 0x7f38af69330e in wlr_signal_emit_safe ../subprojects/wlroots/util/signal.c:29
#11 0x7f38af5e827a in udev_event ../subprojects/wlroots/backend/session/session.c:52
#12 0x7f38aef5d7f1 in wl_event_loop_dispatch (/usr/lib/libwayland-server.so.0+0xa7f1)
previously allocated by thread T0 here:
#0 0x7f38af82e5a1 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:95
#1 0x560c1acbc228 in output_create ../sway/tree/output.c:91
#2 0x560c1ac17ba2 in handle_new_output ../sway/desktop/output.c:656
#3 0x7f38af69330e in wlr_signal_emit_safe ../subprojects/wlroots/util/signal.c:29
#4 0x7f38af5e4ce8 in new_output_reemit ../subprojects/wlroots/backend/multi/backend.c:143
#5 0x7f38af69330e in wlr_signal_emit_safe ../subprojects/wlroots/util/signal.c:29
#6 0x7f38af5d26d4 in scan_drm_connectors ../subprojects/wlroots/backend/drm/drm.c:1294
#7 0x7f38af5c6a59 in drm_invalidated ../subprojects/wlroots/backend/drm/backend.c:135
#8 0x7f38af69330e in wlr_signal_emit_safe ../subprojects/wlroots/util/signal.c:29
#9 0x7f38af5e827a in udev_event ../subprojects/wlroots/backend/session/session.c:52
#10 0x7f38aef5d7f1 in wl_event_loop_dispatch (/usr/lib/libwayland-server.so.0+0xa7f1)
SUMMARY: AddressSanitizer: heap-use-after-free ../sway/desktop/output.c:566 in handle_destroy
Shadow bytes around the buggy address:
0x0c287fffadc0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
0x0c287fffadd0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c287fffade0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c287fffadf0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c287fffae00: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
=>0x0c287fffae10: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c287fffae20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c287fffae30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa
0x0c287fffae40: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c287fffae50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c287fffae60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Retrieve the reference before the output is destroyed and update the
output_management state with the saved reference.
Subsurfaces need access to the parent get_root_coords impl for positioning in
popups. To do this, we store a reference to the parent view_child where
applicable.
Fixes#4191.
This just removes the ipc recv timeout log statement in
`ipc_recv_set_timeout`. The `tv_sec` field of `struct timeval` has
varying types and/or sizes depending on the platform and architecture.
On some of these, the current format string will cause compilation
errors. Additionally, the log statement is not extremely useful and the
function is currently only used by swaymsg, which has a hardcoded log
level that will prevent it from even being shown, so there is no point
in even keeping it.
This just changes the indentation of `sway/input/switch.c` to use
tabs instead of spaces since I messed up and missed it when approving
the PR that added the file.
For compatibility with i3, `bar mode` and `bar hidden_state` do not
require bar-ids (in the normal location) at runtime since they follow
the alternative syntax: `bar mode|hidden_state <option> [<bar-id>]`
This removes the incorrect error that the bar-id is missing for those
two bar subcommands
Prior to this patch, if I ran something like this, sway would crash:
swaymsg bar height 50
or
swaymsg bar not-a-bar-id color bg #ff0000
This was in contrast to other bar subcommands, like status_command,
which would exit with a "No bar defined" message.
The difference between the subcommands that crashed and the ones that
exited was that some subcommands had a check to see if a bar was
specified, while others just assumed that it had been and carried on
until they segfaulted.
Because this check was identical in every subcommand it was present in,
and I couldn't think of a case where it would be valid to run a bar
subcommand without specifying which bar to apply it to, I moved this
check from individual subcommands into the bar command, which is already
responsible for actually setting the specified bar. This reduced code
duplication, and fixed the crash for the subcommands that were missing
this check.
This attempts to use the default keymap when the one defined in the
input config fails to compile. The goal is to make it so the keyboard
is always in a usable state, even if it is not the user's requested
settings as usability is more important.
This also removes the calls to `getenv` for the `XKB_DEFAULT_*` family
of environment variables. The reasoning is libxkbcommon will fallback
to using those (and then the system defaults) when any of the rule
names are `NULL` or an empty string anyway so there is no need for
sway to duplicate the efforts.
This fixes a typo in `merge_id_on_name` for output configs that
resulted in incorrect id-on-name output configs being generated.
Instead of using the output that matched the name or identifier, the
first output in the list was being used instead. This could cause
merging across unrelated output configs and preventing output configs
from being applied correctly
When reloading, this destroys the old config's swaybg client before
spawning the new config's swaybg. This fixes a race condition where the
old config's swaybg client's destroy was being called after the new
config's swaybg client was being spawned. This was causing the
reference to the new swaybg client to be removed and never destroyed.
This also modifies handle_swaybg_client_destroy to grab the config
reference using wl_container_of on the listener since the swaybg client
may be the old config swaybg client and should be used instead of the
global config instance
In case a set_mode/unset_mode request is sent before the first commit, we need
to handle the value and send our preference accordingly.
This fixes xdg-decoration support for Qt apps.
This clarifies that `workspace <name> output <outputs...>` and
`workspace <name> gaps ...` do not operate on existing workspaces.
Additionally, alternate commands/solutions that operate on existing
workspaces are listed.
This adds support for the following commands for i3 compatibility:
- `move [window|container] [to] output current`
- `move workspace to [output] current`
- `move workspace [to] output current`
The above commands are only useful when used with criteria.
* `bindsym --to-code` enables keysym to keycode translation.
* If there are no `xkb_layout` commands in the config file, the translation
uses the XKB_DEFAULT_LAYOUT value.
* It there is one or more `xkb_layout` command, the translation uses
the first one.
* If the translation is unsuccessful, a message is logged and the binding
is stored as BINDING_KEYSYM.
* The binding keysyms are stored and re-translated when a change in the input
configuration may affect the translated bindings.
If unspecified, feature options are set to "auto", which means enabled only if
the required dependencies are found. In CI we don't want to miss compilation
errors because a dependency hasn't been found and code isn't built.
Leave FreeBSD out for now because it uses a subproject (haven't found a way to
make auto_features=enabled only apply to the toplevel project).
The new upstream is https://github.com/swaywm/swaybg
This commit also refactors our use of gdk-pixbuf a bit, since the only
remaining reverse dependency is swaybar tray support.
When moving a container to become a direct child of the workspace and
the workspace's layout is tabbed or stacked, wrap it in a container
with the same layout. This allows for the following:
- Run `layout tabbed|stacked` on an empty workspace (or use
`workspace_layout tabbed|stacked` in the config)
- Open some views
- Move one of the views in any direction
- Open another view
- The new container should also be `tabbed`/`stacked`
This allows swaybar to become visible when the mode changes (to any
mode other than the default). swaybar will be hidden again when the
modifier is pressed and released or when switching back to the default
mode.
This also applies the same logic to visible by urgency to hide swaybar
when the modifier is pressed and released.
These changes are to match i3's behavior.
The read_theme_file function used to return an invalid icon_struct in
some cases, for example when an empty index.theme file was read.
This makes sure the struct we're returning is always valid as per the
Icon Theme specification.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This revamps the type configs for swaynag. All sizing attributes for
swaynag are now `ssize_t` instead of `uint32_t` to allow for a default
value of `-1`, which allows for `0` to be a valid value. Additionally,
the initialization of the type configs has been changed from a simple
calloc to use a new function `swaynag_type_new`. `swaynag_type_new`
calloc's the memory, checks for an allocation failure, sets the name,
and all sizes to -1. The layering order has also been changed to
default, general config, type config, and as highest priority command
line arguments. Finally, `swaynag_type_merge` has been modified to
handle the layering and sizing changes.
This fixes the criteria for emitting a `bar_state_update` event to
notify swaybar (and any other bars utilizing the event) on whether the
bar is visible by modifier. It is not enough to only emit the event
when both the bar mode and bar hidden state are `hide` since it is
possible to release the modifier while hidden state is `show` and then
change hidden state to `hide` without pressing the modifier. This also
emits the event whenever visible by modifier is set and should no
longer be regardless of the mode and state to ensure that it gets
properly cleared. If visible by modifier is not set and the bar is not
in `hide`/`hide`, then no events will be sent and visible by modifier
will not be set
This modifies cmd_move to allow for the syntax options allowed by i3.
The following syntaxes are supported:
- `move left|right|up|down [<amount> [px]]`
- `move [--no-auto-back-and-forth] [window|container] [to] workspace
<name>|next|prev|next_on_output|prev_on_output|current|number <num>`
- `move [window|container] [to] output <name/id>|left|right|up|down`
- `move [window|container] [to] mark <mark>`
- `move workspace to [output] <name/id>|left|right|up|down`
- `move [window|container] [to] [absolute] position <x> [px] <y> [px]`
- `move [window|container] [to] [absolute] position center`
- `move [window|container] [to] position mouse|cursor|pointer`
This also allows retains the following syntax option that is not
supported by i3, but is supported in sway 1.0:
- `move workspace [to] output <name/id>|left|right|up|down`
The changes are:
- `window` and `container` are now optional
- `output` is now optional for `move workspace` when `to` is given
There is also stricter command checking now. If `absolute` or
`--no-auto-back-and-forth` are given for commands that do not support
them, it will be treated as invalid syntax instead of being silently
ignored.
Disable the i3-compatible behavior if the option '--i3' is not given.
Previously it was only possible to disable it by changing the config
file. Now it also works via swaymsg.
This adds a 3 second timeout to the initial reply in swaymsg. This
prevents swaymsg from hanging when `swaymsg -t get_{inputs,seats}` is
used in i3. The timeout is removed when waiting for a subscribed event
or monitoring for subscribed events.
This also adds type checks to commands where i3 does not reply with all
of the properties that sway does (such as `modes` in `get_outputs`).
This is mostly just a behavioral adjustment since swaymsg should run on
i3. When running under i3, some command reply's (such as the one for
`get_outputs) may have more useful information in the raw json than the
pretty printed version.
If a client is subscribed and sends a subsequent ipc command which
causes event updates, then those event updates override the
`client->current_command` and send the incorrect type for the payload
associated with the command.
Example:
SUBSCRIBE {window}
RUN_COMMAND focus -> PAYLOAD_TYPE is 0x80000002 for window events
Therefore, we decouple the `client->current_command` by passing it as an
argument to the ipc_send_reply function, avoiding a data race. The same
is done for the `client->payload_length` as a precautionary measure for
the same reason.
