[BUG] Hyprlock locks the screen while playing videos.

[blejdraner]

Describe the bug

After the 2.13.0 update, Hyprlock locks the screen after a few minutes while watching a video in the Celluloid player or on YouTube.

Steps to reproduce

Start a video and watch it without using the keyboard or mouse.

Expected behavior

When you play a video, the screen should not lock while it is playing.

Screenshots

No response

Distribution

Arch Linux

If Other, specify

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[eljejer]

I had this behavior too earlier. What's the version of the extra/sdbus-cpp or libsdbus-c++ package on your system?

Maybe see this issue

That solved it for me a while back. However, downgrading is not required anymore, as the package has been updated

Edit June 9th: I misinterpreted the issue; I thought it was about Hyprlock NOT working, i,e, the screen does not lock after certain time lapse without activity. But in this case it is the other way around: the screen DOES lock in spite of activity (e.g. viewing a video)

[blejdraner]

I used AI for this because I don't know much about it myself, and it looks like it was a configuration issue in the hypridle.conf file. I had to change

ignore_wayland_inhibit = true
ignore_dbus_inhibit = true

to

ignore_wayland_inhibit = false
ignore_dbus_inhibit = false

Now it seems to be working fine.

[SerG-Y]

Hi @mylinuxforwork, this was introduced by #1571. I think it should be reverted because it actually breaks more things than it fixes.

[eljejer]

Hi @mylinuxforwork, this was introduced by #1571. I think it should be reverted because it actually breaks more things than it fixes.

What else does #1571 break?

[SerG-Y]

Hi @mylinuxforwork, this was introduced by #1571. I think it should be reverted because it actually breaks more things than it fixes.

What else does #1571 break?

Setting both ignore_dbus_inhibit = true and ignore_wayland_inhibit = true makes hypridle ignore every idle‑inhibit request - on both the D‑Bus (org.freedesktop.ScreenSaver) and the Wayland idle‑inhibit protocols. Those are the standard "keep the session awake" mechanisms, so anything that relies on them stops working.
For example: Video calls, Video / media playback, Manual keep‑awake toggles (caffeine‑ng)

[mylinuxforwork]

I am thinking about reducing the hypridle.conf to a minimum and let the user dicide on the configuration. What do you think?

[dwilliam62]

I am thinking about reducing the hypridle.conf to a minimum and let the user dicide on the configuration. What do you think?

that's what Jak did long ago. ;) I would expect a window rule for when something is fullscreen to inhibit screenlock would work too?

Or maybe something like this? (Not tested)

-- Hook into the fullscreen event listener 
hl.on("window.fullscreen", function(window_address, is_fullscreen)
    if is_fullscreen then
        -- App entered fullscreen: inhibit the screen locker/idle tracker
        hl.exec_cmd("hyprctl dispatch dpms on")
        hl.exec_cmd("killall -SIGUSR1 hypridle")
    else
        -- App exited fullscreen: resume normal hypridle tracking cycles
        hl.exec_cmd("killall -SIGUSR2 hypridle")
    end
end)

[systemeror12]

I have replicated this bug when i play a game while using controller. Just not touching keyboard and mouse is enough to trigger this issue