sway reload breaks kanshi config

This is my config

    output eDP-1 enable mode 1920x1080
    output eDP-1 disable
    output "Dell Inc. DELL U3415W F1T1W88R0A1L" enable mode 3440x1440

On sway start, profiles are applied correctly. When i reload sway (mod+shift+r), both profiles get applied, resulting in both displays being turned on. Kanshi is started via sway config (exec kanshi). If I rerun kanshi from the terminal, profiles gets applied correcly.

Is kanshi meant to be started this way (via sway config)?

Running it on archlinux via aur packages (kanshi-git, sway-git, wlroots-git, ... the whole shabang )

github.com:itapai (unverified)
Assigned to
4 years ago
2 months ago
No labels applied.

github.com:emersion (unverified) 4 years ago · edit

This is kind of a sway bug. It should keep the configuration on reload. Or request that kanshi sends the configuration again? I'm not sure how it could do this.

github.com:layus (unverified) 4 years ago · edit


I have investigated this and it appears that sway sends the right information, but kanshi does not react to that, because of the check below. Removing that check makes kanshi react to the done() event after the changes induced by the reload have been sent.

This happens because kanshi never changes its current profile pointer. The struct is updated in place, and the check fails.

diff --git a/main.c b/main.c
index c25e2bb..768e381 100644
--- a/main.c
+++ b/main.c
@@ -118,9 +133,7 @@ static struct kanshi_mode *match_mode(struct kanshi_head *head,
 static void apply_profile(struct kanshi_state *state,
                struct kanshi_profile *profile,
                struct kanshi_profile_output **matches) {
-       if (state->current_profile == profile) {
-               return;
-       }
+       // TODO: Skip if nothing changed.
        struct kanshi_pending_profile *pending = calloc(1, sizeof(*pending));
        pending->state = state;

github.com:layus (unverified) 4 years ago · edit

Well, I guess it depends on what we want. Do we want kanshi to apply configs only when a new config matches, or do we want it to enforce the given config all the time ?

If we are to solve this in sway (keep the current config), then why is sway not able to collect it from the state of the monitor themselves ?

github.com:MichaelAquilina (unverified) 4 years ago · edit

This issue seems to break my current configuration. Right now I have the following in my sway config

exec kanshi

as soon as I reload sway as mentioned above - the wrong configuration seems to be picked up. Is there a workaround for this or is reloading sway's config currently broken?

github.com:layus (unverified) 4 years ago · edit

Using kanshi + sway relaod is broken. You can call kanshi (and kill it afterward ) after each sway reload to force update it's config.

Seems like a good fix would make sway keep outputs config on reload (but sway has output directives that could have changed and need to be re-applied).

github.com:layus (unverified) 4 years ago · edit

Found a very effective solution, that may not prove as temorary as expected (hear: It could become the official solution).

exec_always pkill kanshi; exec kanshi

It ensures a full restart (reload) of kanshi on every sway reload. The second exec is to avoid a leftover sh -c invocation. It is not a sway command but part of the pkill kanshi; exec kanshi shell script.

:sparkles: Expect some flickering :sparkles:

github.com:layus (unverified) 4 years ago · edit

The same technique can be used to launch swayidle (in case of parameters change) and waybar (if you use it).

github.com:itapai (unverified) 4 years ago · edit

@layus when i reload and if I have an external display connected, all my windows close. do you experience this as well? if i dont have an external display connected, it works fine

github.com:MichaelAquilina (unverified) 4 years ago · edit

@itapai I have also experienced this issue several times. I've had to stop using kanshi until I can figure a way to work round it / fix the issue

github.com:emersion (unverified) 4 years ago · edit

when i reload and if I have an external display connected, all my windows close

This should fix it: https://github.com/swaywm/wlroots/pull/1765

github.com:emersion (unverified) 4 years ago · edit

Sway could destroy all output-management heads and re-add them to ask clients to configure them again.

github.com:fourstepper (unverified) 4 years ago · edit

Is the best solution to this still exec_always pkill kanshi; exec kanshi ?

github.com:danjclegg (unverified) 3 years ago · edit

@fourstepper I just very successfully applied that sway line from @layus and can't find a better answer elsewhere. I wonder if this line should be put in some kind of doc? I had a hard time finding out how to integrate kanshi with sway due to the reload issue. Particularly I think pywal was causing a reload of sway config right away so kanshi wouldn't work with a simple exec in sway config even on startup. With the exec_always kanshi survives the sway reconfig that pywal causes when loaded in sway config at startup. Thanks!

github.com:yaymukund (unverified) 3 years ago · edit

If you use systemd to run kanshi as a user service, you can do:

exec_always "systemctl --user restart kanshi.service"

~diegovsky 2 years ago*

I don't think killing and starting kanshi is a good idea. While reading the protocol I think it's sway's fault because when a reload happens it changes the outputs and does not advertise it.

I have read kanshi's debug log (using WAYLAND_DEBUG=1) and it indeed does not receive any zwlr_output_head_v1::position events, even though they have been rearranged.

Edit: It does receive the events, but not after the second time.

~diegovsky 2 years ago

I agree with @emersion, sway should re-add all heads and ask the manager to set them up again. Since this is useful not just to sway, should this be asked in wlroots instead?

~emersion 2 years ago

No, wlroots is not aware of Sway reloads.

~jlo62 2 months ago*

Isn't it quite overkill to kill/restart kanshi? for me, a simple reload does the same job:
exec_always kanshictl reload

Register here or Log in to comment, or comment via email.