Dunst: Las notificaciones de Dunst se muestran en la pantalla de bloqueo (betterlockscreen, xtrlock)

Creado en 27 mar. 2020 · 5Comentarios · Fuente: dunst-project/dunst

Información de instalación

Si su versión es anterior a la 1.2, descarte que el comportamiento ya esté arreglado en el maestro.

Versión: Dunst - A customizable and lightweight notification-daemon 1.4.1 (2019-07-03)
Tipo de instalación: dunst de los repositorios oficiales de Arch
Distribución y versión: Arch Linux

Número original: https://github.com/pavanjadhaw/betterlockscreen/issues/160

Preguntando aquí, ya que el problema ocurre tanto con betterlockscreen como con xtrlock .

Estoy usando Arch Linux con los siguientes paquetes:

Mi problema es que las notificaciones dunst todavía aparecen en la pantalla de bloqueo.

Ejecuté systemctl enable betterlockscreen@$USER para habilitar el servicio de usuario.

Si lo entiendo correctamente, dado que el servicio de usuario systemd está habilitado, betterlockscreen hace lo siguiente antes de bloquear, y esto después de desbloquear.

Intenté usar un script de pantalla de bloqueo que replicara estos comandos en lugar de usar el comando betterlockscreen -l -t "" normal como solución alternativa (ya que las notificaciones dunst todavía se mostraban), pero desafortunadamente no hace ninguna diferencia.

lockscreen.sh

#!/bin/bash

pkill -u "$USER" -USR1 dunst
betterlockscreen -l -t ""
pkill -u "$USER" -USR2 dunst

_Nota: También probé con killall -SIGUSR1 dunst y killall -SIGUSR2 dunst como se sugiere en Arch Wiki ._

y así es como xidlehook ^AUR lo activa:

~/.xinitrc

#!/bin/bash

dunst &
xset s on &
xset s 600 &
xidlehook \
--not-when-fullscreen \
--not-when-audio \
--timer 300 '~/scripts/lockscreen.sh' '' &

Básicamente, la pantalla se bloquea después de 5 minutos y se apaga después de otros 5 minutos adicionales. Esto funciona perfectamente bien, mi único problema es que las notificaciones dunst todavía se muestran en la pantalla de bloqueo.

Es bastante difícil de reproducir.

Gracias por adelantado.

Editar: también estoy usando picom con lo siguiente en picom.conf :

picom.conf

backend = "glx";

glx-no-stencil = true;
glx-copy-from-front = false;

shadow = false;
shadow-radius = 5;
shadow-offset-x = -5;
shadow-offset-y = -5;
shadow-opacity = 1;

shadow-ignore-shaped = false;

inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;

detect-client-opacity = true;

blur-background = false;
blur-background-frame = false;
blur-background-fixed = false;

fading = true;
fade-delta = 4;
fade-in-step = 0.03;
fade-out-step = 0.03;

fade-exclude = [ ];

mark-wmwin-focused = true;
mark-ovredir-focused = true;

use-ewmh-active-win = true;
detect-rounded-corners = true;
refresh-rate = 0;
vsync = true;
dbe = false;
unredir-if-possible = false;

focus-exclude = [ ];

detect-transient = true;
detect-client-leader = true;

wintypes:
{
    tooltip =
    {
        # fade: Fade the particular type of windows.
        fade = true;
        # shadow: Give those windows shadow
        shadow = false;
        # opacity: Default opacity for the type of windows.
        opacity = 1;
        # focus: Whether to always consider windows of this type focused.
        focus = true;
    };
    popup_menu = { opacity = 1; };
};

xrender-sync-fence = true;

Bug graphics help wanted

Fuente

ghost

Todos 5 comentarios

Bueno, soy un mantenedor de esto e incluso tengo el mismo problema. : see_no_evil: Estoy usando i3lock como pantalla de bloqueo y estoy usando compton como administrador de composición.

En nuestra investigación, descubrimos que está vinculado al compositor de su sistema, lo que introduce algunas condiciones de carrera extrañas o algo así ...: confuso: Ref: i3 / i3lock # 204 # 553

bebehei en 27 mar. 2020

👀1 👍1

Aparte del problema del compositor, la solución de pausa / reanudación mencionada anteriormente es mi solución, y funciona perfectamente en mi caso.
Por qué no funciona aquí, sospecho que se trata de un error en betterscreenlock de una lectura rápida del script que llama a i3lock sin el --nofork por lo que i3lock se bifurca inmediatamente en el lanzamiento, lo que hace ejecuta el comando unpause.

tsipinakis en 27 mar. 2020

En nuestra investigación, descubrimos que está vinculado al compositor de su sistema,

Gracias por la información, desactivaré picom por ahora y veré si eso resuelve el problema.

Aparte del problema del compositor, la solución de pausa / reanudación mencionada anteriormente es mi solución, y funciona perfectamente en mi caso.
Por qué no funciona aquí, sospecho que se trata de un error en mejor bloqueo de pantalla debido a una lectura rápida del script al que llama i3lock sin el --nofork, por lo que i3lock se bifurca inmediatamente al iniciarse, lo que hace que ejecute el comando unpause.

Como dije, el problema también ocurre con xtrlock (que no usa i3lock si no me equivoco), invocado con el siguiente script:

lockscreen.sh :

#!/bin/bash

pkill -u "$USER" -USR1 dunst       # or killall -SIGUSR1 dunst  
xtrlock -b
pkill -u "$USER" -USR2 dunst       # or killall -SIGUSR2 dunst

ghost en 27 mar. 2020

Así que desactivé picom y puedo confirmar que no apareció una sola notificación en mi pantalla de bloqueo (actualmente usando betterlockscreen ) en las últimas ~ 15 horas. Todos se mostraron después de que abrí.

ghost en 28 mar. 2020

Puedo confirmar que tengo el mismo problema al ejecutar picom. Desactivarlo también resuelve el problema, pero desafortunadamente lo necesito. ¿Quizás deberíamos llevar esto a picom?