Any alternative to exec_always from sway?

[ErikReider]

I added Kanshi to autostart kanshi = kanshi and it works fine until I change a setting in the Wayfire config. I also experienced this issue in sway emersion/kanshi#43. To fix this, I ran this script in exec_always:

killall -9 kanshi
while pgrep -u $UID -x kanshi >/dev/null; do sleep 1; done
kanshi &

This isn't possible here because of the lack of exec_always. Is there any other alternative to exec_always or any other way?

Wayfire version
0.8.0-e510e70f (May 26 2021, branch 'master')

[ammen99]

What does exec_always do in sway?

[ammen99]

FWIW, the kanshi problem will also be solved, but in a different way. I'm envisioning an option which tells Wayfire: 'as soon as an external entity has configured the outputs, do not ever read their configuration from the config file'. This is not implemented yet, however.

[ErikReider]

@ammen99 the command executes a command on config reload while the normal exec runs once on start

[soreau]

@ErikReider Can you elaborate on what you mean by config reload? This may have different meanings depending on the compositor.

[ErikReider]

@soreau I'm not sure about what sway exactly does but you're able to reload the conf file while waybar does this automatically on save

[ammen99]

@ErikReider Can you elaborate on what you mean by config reload? This may have different meanings depending on the compositor.

reload-config is a signal in Wayfire :)

This is the general bug where Wayfire resets the output config set by an external application (kanshi, wdisplays, etc.) when the config file is changed and Wayfire re-parses the config file.

[ErikReider]

@ammen99 what's weird is that I've removed all of the output lines in the config. It's probably using a default value. Weird that both sway and wayfire have this issue

[soreau]

I added Kanshi to autostart kanshi = kanshi and it works fine until I change a setting in the Wayfire config.

Can you say what stops working when the problem happens? What happens with kanshi that makes you think there is a problem?

[soreau]

This is the general bug where Wayfire resets the output config set by an external application (kanshi, wdisplays, etc.) when the config file is changed and Wayfire re-parses the config file.

Ah, this bug^^

[soreau]

For this to work we should get rid of output config in wayfire.ini altogether and use default output configuration when wayfire starts without configuration, and kanshi instead when it's available.

[ammen99]

For this to work we should get rid of output config in wayfire.ini altogether and use default output configuration when wayfire starts without configuration, and kanshi instead when it's available.

Getting rid of wayfire.ini configurarion is nowhere near good enough. Kanshi does not support mirrored outputs, custom modelines and potentially more things we'll add in the future.

#1201 (comment) provides a much better fix, because it still allows for these use-cases where kanshi is not enough.

[soreau]

Getting rid of wayfire.ini configurarion is nowhere near good enough. Kanshi does not support mirrored outputs, custom modelines and potentially more things we'll add in the future.

Sounds like opportunities for improvement in wlr-output-management-unstable protocol.

[AdrianVovk]

gde-gnome-bridge depends on setting display options through wf-config currently too! Would rather not have to rewrite all that code just yet :)

But I agree wlr-output-management should be extended. Also, I'm pretty sure it already supports mirroring: just set both outputs to the same x,y position

[ammen99]

@ErikReider try the option described in #1202

[ammen99]

But I agree wlr-output-management should be extended. Also, I'm pretty sure it already supports mirroring: just set both outputs to the same x,y position

Not really. swaywm/wlr-protocols#101

We could special-case this by saying "equal x/y == mirrored", but this is not described in the protocol, and also a bit counter-intuitive IMO.

[ammen99]

Putting low-priority as the kanshi problem was fixed in a different way, and we don't really have a use-case for exec_always