Hypridle `on-resume` command not triggered after D-Bus inhibit

[nonetrix]

I have the following set

    services.hypridle = {
      enable = true;
      settings = {
        general = {
          after_sleep_cmd = "hyprctl dispatch dpms on";
          ignore_dbus_inhibit = false;
          lock_cmd = "hyprlock";
        };

        listener = [
          {
            timeout = 10;
            on-timeout = "brightness-ctrl set 20";
            on-resume = "brightness-ctrl set 100";
          }
          {
            timeout = 500;
            on-timeout = "hyprlock";
          }
        ];
      };
    };

However, if I do the following:

while true
do
sleep 20
busctl --user call org.freedesktop.ScreenSaver /org/freedesktop/ScreenSaver org.freedesktop.ScreenSaver Inhibit ss 'test' 'foobar'
done

My screen will go dark as expected. However, when the D-Bus command is sent, it doesn't return to full brightness. Instead, it seems to have correctly reset the timer but forgotten to actually run the on-resume command, meaning I have to either change my brightness manually or wait another 10 seconds and use my mouse to wake it instead

[PointerDilemma]

Not sure if anybody thought about this properly. From looking at the code, I doubt it.

The question(s) are:

1. What do we do when we inhibit in between onTimeout and onRestore? Do we block the onRestore? I don't think we should. (We currently do)
2. What do we do when the inhibitor get's released and a listener fired. Shouldn't we call onTimeout immediatly? I think we should. (We currently don't)

I guess there was #72 which sort of addresses 2, but not really.

[3ventic]

I found this because question 1 from @PaideiaDilemma impacts me quite greatly.

If one uses websites or services, where other users can activate inhibit locks (like starting video playback), you can run into this issue a lot, where a listener that correctly went idle does not resume on activity. Based on the documentation as written, it feels like a bug; the on-resume should run if the on-timeout ran.

Having a separate listener that ignores inhibit just to have it the on-resume guaranteed seems both wasteful and potentially buggy, if the resume command expects the timeout command to have set a certain state.

It wasn't a particularly welcome surprise to return to a permanently dimmed display and trying to figure out why.