Add the disable_lockdead_screen option

[aacebedo]

Describe your PR, what does it fix/add?

When running on slow computer (in my case laptop in powersave mode), hyprland can display lockdead screen before the lockscreen has started. It results in seeing for 1 or 2 second before the lockscreen actually starts.

This PR add a config option to disable the lockdead screen, solving the issue at the same time.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

Another solution would be to wait for a configurable delay before displaying it. If this solution is preferable, let me know.

Is it ready for merging, or does it need work?

It shall be mergeable

[PaideiaDilemma]

How does that fix the problem? By not drawing a frame at all??
I don't think that this option should exist.

BUT I think i know why that happens and how to fix it properly. Here is how stuff works:

1. Client sends a lock request.
2. Client creates session lock surfaces.
3. Only when all outputs have a session lock surface committed, the compositor sends the locked event.

Regarding point 3 the protocol says

The locked event must not be sent until a new "locked" frame (either from a session lock surface or the compositor blanking the output) has been presented on all outputs and no security sensitive normal/unlocked content is possibly visible.

To me it seems like we generally want to render the lockscreen starting from when the clients gets the locked event. Currently we start right on the lock event.

However, this would introduce the following problem:
When a client fails to commit a surface for a monitor, the this additional locked state would never be reached.
Possible mitigation would be to guard it with a timer.

[aacebedo]

How does that fix the problem? By not drawing a frame at all?? I don't think that this option should exist.

BUT I think i know why that happens and how to fix it properly. Here is how stuff works:

1. Client sends a lock request.

2. Client creates session lock surfaces.

3. Only when all outputs have a session lock surface committed, the compositor sends the `locked` event.

Regarding point 3 the protocol says

The locked event must not be sent until a new "locked" frame (either from a session lock surface or the compositor blanking the output) has been presented on all outputs and no security sensitive normal/unlocked content is possibly visible.

To me it seems like we generally want to render the lockscreen starting from when the clients gets the locked event. Currently we start right on the lock event.

However, this would introduce the following problem: When a client fails to commit a surface for a monitor, the this additional locked state would never be reached. Possible mitigation would be to guard it with a timer.

I mentioned the timer in my PR but not was not aware of the internal mechanics (I am not familiar with wayland protocols). I saw that some lock event is processed by the compositor but I do no know exactly from where it is originating from, gtklock or logind?

[PaideiaDilemma]

gtklock or any other lockscreen client can send the lock request.

River has an additional state "waiting_for_lock_surfaces" and a timer with 200ms that disables rendering normal content. Basically what i described in my first comment.

I think we can solve the issue by implementing something like that. And if it is really needed, we could make this timeout configurable.

[aacebedo]

thanks for the Analysis. I am currently trying a fix with a timer. I'll update this when I have finished

[aacebedo]

@PaideiaDilemma Created the following PR with a delay: #8467