Here's an example of attempting to enable it. Whether I let it use an implicit path or force an explicit one, as long as I pass a non-mustache filter and a valid filter name, it seems it does try to apply it, and there's no error output I can see either. This is true both for filters in the /nix/store/* path, and the ~/.config/hyprland/shaders. Other paths you mentioned too I think.

So even when the path is valid, though it says it's turning it on, it's just not applying it for some reason. Maybe someone else on NixOS unstable will chime in if they're experiencing the same thing. If there's other helpful info I can provide you, let me know. For now, that's probably the extent of my helpful knowledge.

I have the same issue on NixOS with Hyprland git (commit c21a5a934061c248ff1cdd459a74a05b621fb427), however, on Hyprland v0.39.1 hyprshade (3.2.1) works fine.

hyprctl keyword decoration:screen_shader /nix/store/80fjhzmrkpi4zx9x2c8lgf0fxwk23ccp-python3.11-hyprshade-3.2.1/share/hyprshade/shaders/blue-light-filter.glsl

running this applied the filter with no issues

hyprctl -j getoption decoration:screen_shader

{"option": "decoration:screen_shader", "str": "/nix/store/80fjhzmrkpi4zx9x2c8lgf0fxwk23ccp-python3.11-hyprshade-3.2.1/share/hyprshade/shaders/blue-light-filter.glsl", "set": true }

and now the hyprctl JSON seems fine too

I have the same issue on NixOS with Hyprland git (commit c21a5a934061c248ff1cdd459a74a05b621fb427), however, on Hyprland v0.39.1 hyprshade (3.2.1) works fine.

Since the error seems not to occur for @willswats in Hyprland v0.39.1, I wonder if the same would also apply for @markaacosta. @markaacosta Would you mind confirming if this is true?

on 0.39 hyprland everything works fine for me too

I think I figured out whats wrong, the hyprshade in nixpkgs is using Hyprland v0.39.1 as that's currently the latest version, and it hasn't been updated probably because of this issue. To fix this you can override the Hyprland package that hyprshade uses like so (this is if you are using flakes):

(pkgs.hyprshade.override {
  hyprland = inputs.hyprland.packages.${pkgs.system}.hyprland;
})

I don't know if this is the typical behavior for when there is a difference between the Hyprland version that hyprshade uses, or if this only occurred due to there being a lot of under-the-hood changes in the Hyprland v0.40.0 release.

Perhaps it's due to this breaking change in Hyprland v0.40.0:

• The hyprland logs, sockets, etc. have moved from /tmp/hypr to $XDG_RUNTIME_DIR/hypr.

I think I figured out whats wrong, the hyprshade in nixpkgs is using Hyprland v0.39.1 as that's currently the latest version, and it hasn't been updated probably because of this issue. To fix this you can override the Hyprland package that hyprshade uses like so (this is if you are using flakes):

(pkgs.hyprshade.override {

  hyprland = inputs.hyprland.packages.${pkgs.system}.hyprland;

})

I don't know if this is the typical behavior for when there is a difference between the Hyprland version that hyprshade uses, or if this only occurred due to there being a lot of under-the-hood changes in the Hyprland v0.40.0 release.

I didn't even think of the possibility that Hyprshade is running the wrong hyprctl executable! Bravo, William. Let's hope this fix also works for @markaacosta.

(pkgs.hyprshade.override {
  hyprland = inputs.hyprland.packages.${pkgs.system}.hyprland;
})

I'm on flakes, yeah. Did you add this directly to the inputs block of flake.nix? Or add it somewhere else?

(pkgs.hyprshade.override {
  hyprland = inputs.hyprland.packages.${pkgs.system}.hyprland;
})

I'm on flakes, yeah. Did you add this directly to the inputs block of flake.nix? Or add it somewhere else?

Add it to environment.systemPackages:

{ pkgs, inputs, ... }:

{
  environment.systemPackages = [
    (pkgs.hyprshade.override {
      hyprland = inputs.hyprland.packages.${pkgs.system}.hyprland;
    })
  ];
}

Or home.packages if you are using home-manager:

{ pkgs, inputs, ... }:

{
  home.packages = [
    (pkgs.hyprshade.override {
      hyprland = inputs.hyprland.packages.${pkgs.system}.hyprland;
    })
  ];
}

And If you haven't done so already, you will also need to add @inputs to the outputs part of your flake, and then inherit inputs in specialArgs, or in extraSpecialArgs for home-manager so that you can access inputs as an argument.

@willswats I've got all that other scaffolding and have modularized things pretty well, but I hadn't seen this construct for overriding specific attributes or dependencies for a package. Thanks for the great tip - and @loqusion this also definitely fixed / rolled back hyprshade for me!

Great! I'll pin the issue in case it helps anyone else experiencing the same error, and hide some comments to increase visibility of the solution.