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.

Hi,

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;

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 ?

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?

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).

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:

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

@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

@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

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

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

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

@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!

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

exec_always "systemctl --user restart kanshi.service"

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.

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?

No, wlroots is not aware of Sway reloads.

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