Age | Commit message (Collapse) | Author |
|
Make the status command a process group leader and change the kill(2)
calls to target the new process group. Signals sent by swaybar will then
be received by both the status command and its children, if any. While
here, check the result of fork(2).
Without this, children spawned by the status command may not receive the
signals sent by swaybar. As a result, these children may be orphaned on
reload.
The issue could be shown by setting the bar to
bar {
status_command i3status | tee /tmp/i3status.out
}
which would leave orphaned processes for each reload of sway
$ ps o pid,ppid,cmd | grep i3status | grep -v grep
43633 43624 sh -c i3status | tee /tmp/i3status.out
43634 43633 i3status
43635 43633 tee /tmp/i3status.out
$ swaymsg reload
$ ps o pid,ppid,cmd | grep i3status | grep -v grep
43634 1 i3status
43635 1 tee /tmp/i3status.out
43801 43788 sh -c i3status | tee /tmp/i3status.out
43802 43801 i3status
43803 43801 tee /tmp/i3status.out
This fixes #5584.
|
|
sway-bar(5) says:
> For compatibility with i3, bar mode <mode> [<bar-id>] syntax is
> supported along with the sway only bar <bar-id> mode <mode> syntax.
while the actual behavior is that `bar_cmd_mode` ignores already
selected `config->current_bar` and applies the change to all the
configured bars.
|
|
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.
|
|
wlroots now required the compositor to create its own wlr_renderer and
wlr_allocator to initialize the wlr_output
|
|
|
|
Proprietary drivers require --unsupported-gpu to be allowed, and IPCs
require no option to be passed.
The only way to satisfy both is to run IPCs before checking for
proprietary drivers.
|
|
|
|
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
|
|
Add a subcommand for `smart_gaps` that enables outer gaps only
on workspaces with exactly one visible child.
Also add documentation for `smart_gaps toggle`.
|
|
previously, fullscreen global containers would grab cursor input
even if a shell-layer surface was on top of it
related issue: https://github.com/swaywm/sway/issues/6501
|
|
|
|
|
|
INT_MAX causes a NULL pointer if there is not enough memory available to
fit (INT_MAX * sizeof(struct json_tokener_srec)).
|
|
if there is not enough memory to fit json_tokener and (depth *
json_tokener_srec) in RAM, don't segfault.
|
|
If the focused container is floating by itself, create a new container
in tiling mode as a sibling of the inactive focused container instead of
creating it as a sibling of everything that is in tiling mode in that
workspace. This is the i3 behavior.
|
|
seat_get_focus_inactive_floating and seat_get_focus_inactive_tiling do
not always return a view, so get the previously focused view from the
container with seat_get_focus_inactive_view. This is the i3 behavior.
|
|
If the destroyed xwayland view is in transaction, it won't
be destroyed immediately. wlr_xwayland_surface then becomes
dangling pointer.
Closes #6605
Closes #5884
|
|
Nvidia has historically been a bad actor in the open-source graphics
ecosystem because they required a special EGLStreams code-path
instead of exposing the de-facto standard GBM API. However, with
their upcoming release they now support GBM as well.
This is a push in the right direction for Nvidia, so there's no
reason we should be more hostile to them than to any other proprietary
driver. Let's remove the --my-next-gpu-wont-be-nvidia flag, and advise
users to use --unsupported-gpu now.
Note, proprietary Nvidia drivers are still unsupported by the Sway
project (just like all other proprietary drivers).
|
|
|
|
|
|
Same reasoning as fe11caeac946cecda491d592044a6b9519ef2035.
Without this, swaymsg would fail with a cryptic error message
when the JSON was nested too deep.
|
|
'-b' spawns a terminal, which is unnecessary for this use case
|
|
This happens a lot, the latest one is [1].
[1]: https://github.com/swaywm/sway/issues/6570
|
|
|
|
See [1].
[1]: https://github.com/swaywm/wlroots/pull/3245
|
|
|
|
|
|
|
|
|
|
Adds detection code to handle pci-*-platform-* strings
in ID_PATH
References: https://github.com/swaywm/sway/issues/6590
Signed-off-by: Jari Ronkainen <ronchaine@gmail.com>
|
|
|
|
|
|
- The contact info is out-of-date
- Sway is packaged in many distributions now
- I don't think we necessarily need to mention this in the README
|
|
Commit 152a559e replaced the view pointer in the inhibitor struct with a
pointer to the wlr_inhibitor for application inhibitors. But this was not
changed in the sway_idle_inhibit_v1_application_inhibitor_for_view function.
This caused a bug in the sway tree view where the application inhibitor is
always "none".
|
|
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
|
|
Clang 13 reports:
../sway/commands.c:470:23: error: variable 'context' set but not used
[-Werror,-Wunused-but-set-variable]
enum command_context context = 0;
^
Last use of was removed in commit 1d3681f52135.
Downstream PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258813
|
|
See [1].
[1]: https://github.com/swaywm/wlroots/pull/3106
|
|
References: https://github.com/swaywm/wlroots/pull/3205
|
|
|
|
This commit makes sure the extents are kept up-to-date, fixes not
damaging the surface if its layer shell-specific state didn't change,
and adds a check if the layer shell-specific state didn't change but the
surface got mapped/unmapped, which could affect keyboard focus.
|
|
This avoids infinite configure-ack_configure-commit loop.
|
|
|
|
|
|
This reverts commit 4dd46f06acc520449b980a5ea52be544cc5bfb6d, as the
logic is now handled by wlroots.
|
|
|
|
This can help debugging direct scan-out issues, such as [1].
[1]: https://github.com/swaywm/wlroots/issues/3185
|
|
while the draw itself is a no-op, alignment must still be accounted
this requires more signalling about the blocks (border_set; was the
border set?)
|
|
|
|
Prior to 62d90a8e, titlebar's font height (and other related values)
would change any time any titlebar's content changed, so these values
were recalculated each time any titlebar's content changed (or a new
titlebar was created).
However, since the above was merge, these values no longer change so
often and we only need to recalculate them when the configured font
changes (and stop calling `config_update_font_height` each time
titlebars are rendered).
This commit removes all the unecessary calls to this function and avoids
all those unecessary calculations. Whenever the font strays from the
default value, the `font` command is called, and it calls
`config_update_font_height`, which is enough to keep the value always up
to date.
I've also added a default value to the `font_baseline` config, since
otherwise that's zero for setups that don't explicitly specify a font.
|
|
|