If a call is incomming and the proximity doesn't unlock the screen,
cause near initial state, or because it is bugged, then we was setting
the "menu" mode while screenoff. Which means the power button was
picking the dmenu entry instead of unlocking the device.

We disable the "menu" mode if the proximity lock turns the screen off,
so we should not set this mode if the initial state is screenoff.

Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
---
 scripts/core/sxmo_dmenu.sh | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/scripts/core/sxmo_dmenu.sh b/scripts/core/sxmo_dmenu.sh
index 68d95314..ee4dfbfb 100755
--- a/scripts/core/sxmo_dmenu.sh
+++ b/scripts/core/sxmo_dmenu.sh
@@ -43,11 +43,13 @@ case "$1" in
 esac
 
 if [ -n "$WAYLAND_DISPLAY" ]; then
-	swaymsg mode menu -q # disable default button inputs
-	cleanmode() {
-		swaymsg mode default -q
-	}
-	trap 'cleanmode' TERM INT
+	if grep -q unlock "$SXMO_STATE"; then
+		swaymsg mode menu -q # disable default button inputs
+		cleanmode() {
+			swaymsg mode default -q
+		}
+		trap 'cleanmode' TERM INT
+	fi
 
 	bemenu -l "$(sxmo_rotate.sh isrotated > /dev/null && \
 		printf %s "${SXMO_BEMENU_LANDSCAPE_LINES:-8}" || \
-- 
2.42.0

sxmo-utils/patches/test.yml: SUCCESS in 45s

[sxmo_dmenu.sh: do not set menu mode if the state isn't unlock][0] from [Willow Barraco][1]

[0]: https://lists.sr.ht/~mil/sxmo-devel/patches/44825
[1]: contact@willowbarraco.fr

✓ #1059120 SUCCESS sxmo-utils/patches/test.yml https://builds.sr.ht/~mil/job/1059120

Applied!