Skip to content

Conversation

@BlueZeeKing
Copy link
Contributor

Currently, when suspending the system, hyprlock stills tries to fade in, so it
is still fading in when the system resumes. This change simply prevents the fade
in if the system is actively suspending.

@PointerDilemma
Copy link
Collaborator

This makes us block on dbus each time we start without allowing a configuration for that.
I am sort of against that, but would have nothing against it with a configuration option that is off by default.

I just don't understand why you can't launch hyprlock with --no-fade-in in whatever mechanism you use to launch hyprlock before suspend. In hypridle that would be general:before_sleep_cmd = hyprlock --no-fade-in.
That has a lot less overhead.

I feel like most of why people don't want to do that is that they for some reason want to use loginctl lock-session on suspend? I understand that the login dbus interface has a locked state, but one can still set that and still use --no-fade-in directly.

@BlueZeeKing
Copy link
Contributor Author

You're totally right that it could just be in the hypridle config. I completely forgot about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants