Arch Linux User Repository

This package comes with a systemd unit file that is not supported by the upstream. To enable the unit, run $ systemctl --user enable kanshi.service. Some notes:

1. This unit won't automatically start unless graphical-session.target has already started. Though on many users' systems, graphical-session.target always starts under Sway, Sway actually does not activate graphical-session.target by default. The graphical-session.target may be activated silently by some other applications/units or by explicit exec command in the Sway config.
2. Many other X11 window managers or Wayland compositors also activate graphical-session.target. This says, if you sometimes use other WM, like gnome or kde, kanshi.service will also automatically start (and then fail because kanshi is a Sway-only application).

The best practice is to create your own sway-session.target, and modify (or create your own) the kanshi.service to be wanted by sway-session.target. See the Wiki at Sway's GitHub and also ArchWiki:

• https://github.com/swaywm/sway/wiki/Systemd-integration
• https://wiki.archlinux.org/index.php/Sway#Manage_Sway-specific_daemons_with_systemd

This package comes with a systemd unit file that is not supported by the upstream. To enable the unit, run $ systemctl --user enable kanshi.service. Some notes:

1. This unit won't automatically start unless graphical-session.target has already started. Though on many users' systems, graphical-session.target always starts under Sway, Sway actually does not activate graphical-session.target by default. The graphical-session.target may be activated silently by some other applications/units or by explicit exec command in the Sway config.
2. Many other X11 window managers or Wayland compositors also activate graphical-session.target. This says, if you sometimes use other WM, like gnome or kde, kanshi.service will also automatically start (and then fail because kanshi is a Sway-only application).

The best practice is to create your own sway-session.target, and modify (or create your own) the kanshi.service to be wanted by sway-session.target. See the Wiki at Sway's GitHub and also ArchWiki:

• https://github.com/swaywm/sway/wiki/Systemd-integration
• https://wiki.archlinux.org/index.php/Sway#Manage_Sway-specific_daemons_with_systemd

Despite that service might not fit into each and every setup, I was pretty happy to find service units to be included in some other packages while switching to systemd as the only apps startup manager for Sway. Current setup has been my only daily driver for a few weeks already, so I thought, that someone else could also benefit from having similar service units added to the packages, which don't yet provide one.

For example, gammastep, being a community package and wlroots-specific, does include a user service and uses graphical-session.target:

~ $ yay -Q | grep gammastep
gammastep 2.0.7-1
~ $ yay -Ql gammastep | grep service
gammastep /usr/lib/systemd/user/gammastep-indicator.service
gammastep /usr/lib/systemd/user/gammastep.service
~ $ cat /usr/lib/systemd/user/gammastep.service | head -4
[Unit]
Description=Display colour temperature adjustment
PartOf=graphical-session.target
After=graphical-session.target

Same applies to flashfocus-git. Mako also includes a service, althought it's service is not attached to any target.

@lowercase I would suggest putting the kanshi service unit under /usr/lib/systemd/user or /etc/systemd/user because graphical-session.target is a user-space unit (launched with --user flag). And sway-session.target should be something depending on graphical-session.target.

@gmy I'm not sure how many Wayland WMs support wlr-output-management, but at least kanshi does not work with gnome's Wayland session. Also, graphical-session.target runs even under X11 WMs, i.e., not just Wayland WMs use graphical-session.target. I think that's probably why Arch's official kanshi package and other Sway-specific utilities (like swayidle) do not include a service file.

I'm thinking about including either @lowercase's or @gmy's systemd unit in this package and adding documentation in wiki or somewhere to let users know about the caveats.

@pychuang, @lowercase, but how kanshi is related specifically to sway? Shouldn't it support any wayland WM?

kanshi can be used on Wayland compositors supporting the wlr-output-management protocol.

https://github.com/emersion/kanshi

Also, isn't it up to user to deside whether enable systemd service or not? And, isn't it disabled by default?

AFAIK, even if service file gets installed with the package, user won't see any differences, until he/she enables it. Also, user is free to override it or change.

Heya,

just looked around and there is indeed an aur package that implements the necessary service unit. Here is my proposal: https://gist.github.com/mattiasgiese/d0c9054daf562ea8aae106cce2e02a4b

Heya,

sorry for the late reply. As pychuang indicated it is tricky to just pump a systemd-unit that would only work in a specific setting. A sway-session.target would indeed make sense, but that should be implemented in the respective sway packages first.

@gmy That systemd unit starts whenever graphical-session.target starts (including when using gnome or any other graphical environments). Though if a user only uses Sway, that service unit should work fine, I'm not sure if we should assume users only use Sway.

I guess the best way is to make this service wanted by something like sway-session.target. But then it requires users to manually create the sway-session.target because Sway does not come with one.

Could you please add a systemd user service (https://gist.github.com/gmykhailiuta/3e1fe01f6980b9d81933c3b1fa3e0c1d)? For instance, gammastep package includes one.

Heya,

building in aurtools works fine now. Thanks!

@lowercase Thanks for pointing out. I updated the PKGBUILD based on the recommendation in https://wiki.archlinux.org/index.php/Meson_package_guidelines.

I don't use the tools you mentioned, so could you please test the new PKGBUILD and let me know if it works now? Thanks!