diff options
author | Katharina Fey <kookie@spacekookie.de> | 2019-10-05 22:42:42 +0000 |
---|---|---|
committer | Katharina Fey <kookie@spacekookie.de> | 2019-10-05 22:44:50 +0000 |
commit | 73d865b1dae7585d0eff167271dabe77c9d0b8e6 (patch) | |
tree | 337324fab29014f3d60a8bff4979e397fb556d88 /home-manager/modules/services/screen-locker.nix | |
parent | 670a2de0037acadb83433165344710dd3ac03adf (diff) | |
parent | e14d8e29606feddb29d7c27ea62dd514ef80f1e4 (diff) |
Replacing nixcfg with libkookierebuild
Generally, nixcfg grew out of a dotfiles repository, that happened to
also have some scripts in it. As more and more of the configuration
was replaced with nix specifics (home-manager, etc...), so did nixcfg
change over time (previously "stuff").
As part of this, kookiepkgs was introduced along-side nixcfg, to make
it easier to add custom things to nixpkgs-based systems
(NixOS). Additionally, the core system configuration was handled via
private infrastructure repositories, each specific to the machine in
question.
The problem with this approach is a lot of redundancy when building
non-userspace (read home-manager) systems and a lot of chaos with
having to cherry-pick commits from different branches to work with
nixpkgs trees in development.
Ultimately, keeping both new package definitions, patches and
configuration for the root system and userspace (home-manager) in the
same repository is a _much_ better approach to solving these issues.
And as such, libkookie was started: the general idea is that it
includes all nix expressions that are relevant to _any_ of my
computers. Under `roots`, a machine can have it's primary
configuration file which is built andcopied into the nix store, so
that nixpkgs can always point at the version a generation was built
with, not what is on disk).
Overlays contains everything that kookiepkgs used to, modules contains
both system-level modules (only required on NixOS), as well as
anything that is being built with home-manager. Modules are all kept
in the same tree, however some require system-level access while
others don't. There could be some kind of list to distinguish the two,
so that userspace-only systems can still take advantage of libkookie.
Diffstat (limited to 'home-manager/modules/services/screen-locker.nix')
-rw-r--r-- | home-manager/modules/services/screen-locker.nix | 76 |
1 files changed, 76 insertions, 0 deletions
diff --git a/home-manager/modules/services/screen-locker.nix b/home-manager/modules/services/screen-locker.nix new file mode 100644 index 00000000000..e3da14069bc --- /dev/null +++ b/home-manager/modules/services/screen-locker.nix @@ -0,0 +1,76 @@ +{ config, lib, pkgs, ... }: + +with lib; + +let + + cfg = config.services.screen-locker; + +in { + + options.services.screen-locker = { + enable = mkEnableOption "screen locker for X session"; + + lockCmd = mkOption { + type = types.str; + description = "Locker command to run."; + example = "\${pkgs.i3lock}/bin/i3lock -n -c 000000"; + }; + + inactiveInterval = mkOption { + type = types.int; + default = 10; + description = '' + Inactive time interval in minutes after which session will be locked. + The minimum is 1 minute, and the maximum is 1 hour. + See <link xlink:href="https://linux.die.net/man/1/xautolock"/>. + ''; + }; + + xautolockExtraOptions = mkOption { + type = types.listOf types.str; + default = []; + description = '' + Extra command-line arguments to pass to <command>xautolock</command>. + ''; + }; + + xssLockExtraOptions = mkOption { + type = types.listOf types.str; + default = []; + description = '' + Extra command-line arguments to pass to <command>xss-lock</command>. + ''; + }; + + }; + + config = mkIf cfg.enable { + systemd.user.services.xautolock-session = { + Unit = { + Description = "xautolock, session locker service"; + After = [ "graphical-session-pre.target" ]; + PartOf = [ "graphical-session.target" ]; + }; + + Install = { + WantedBy = [ "graphical-session.target" ]; + }; + + Service = { + ExecStart = concatStringsSep " " ([ + "${pkgs.xautolock}/bin/xautolock" + "-detectsleep" + "-time ${toString cfg.inactiveInterval}" + "-locker '${pkgs.systemd}/bin/loginctl lock-session $XDG_SESSION_ID'" + ] ++ cfg.xautolockExtraOptions); + }; + }; + + # xss-lock will run specified screen locker when the session is locked via loginctl + # can't be started as a systemd service, + # see https://bitbucket.org/raymonad/xss-lock/issues/13/allow-operation-as-systemd-user-unit + xsession.initExtra = "${pkgs.xss-lock}/bin/xss-lock ${concatStringsSep " " cfg.xssLockExtraOptions} -- ${cfg.lockCmd} &"; + }; + +} |