Dunst: Notificações Dunst exibidas na tela de bloqueio (betterlockscreen, xtrlock)

Criado em 27 mar. 2020 · 5Comentários · Fonte: dunst-project/dunst

Informação de instalação

Se sua versão for anterior a 1.2, exclua que o comportamento já foi corrigido no mestre

Versão: Dunst - A customizable and lightweight notification-daemon 1.4.1 (2019-07-03)
Tipo de instalação: dunst dos repositórios oficiais do Arch
Distribuição e versão: Arch Linux

Problema original: https://github.com/pavanjadhaw/betterlockscreen/issues/160

Perguntando aqui desde que o problema ocorre com betterlockscreen e xtrlock .

Estou usando o Arch Linux com os seguintes pacotes:

Meu problema é que dunst notificações ainda aparecem na tela de bloqueio.

Executei systemctl enable betterlockscreen@$USER para habilitar o serviço de usuário.

Se bem entendi, uma vez que o serviço de usuário systemd está habilitado, betterlockscreen faz o seguinte antes de bloquear, e isso após desbloquear.

Tentei usar um script lockscreen replicando esses comandos em vez de usar o comando betterlockscreen -l -t "" normal como uma solução alternativa (já que as notificações de dunst ainda eram exibidas), mas infelizmente isso não fez nenhuma diferença.

lockscreen.sh

#!/bin/bash

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

_Nota: Eu também tentei com killall -SIGUSR1 dunst e killall -SIGUSR2 dunst como sugerido no Arch Wiki ._

e é assim que ele é acionado por xidlehook ^AUR :

~/.xinitrc

#!/bin/bash

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

Basicamente, a tela bloqueia após 5 minutos e desliga após 5 minutos extras. Isso funciona perfeitamente bem, meu único problema é que dunst notificações ainda são exibidas na tela de bloqueio.

É muito difícil de reproduzir.

Desde já, obrigado.

Editar: Também estou usando picom com o seguinte em 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

Fonte

ghost

Todos 5 comentários

Bem, eu sou um mantenedor disso e até tenho o mesmo problema. : see_no_evil: Estou usando i3lock como lockscreen e estou usando compton como um gerenciador de composição.

Em nossa pesquisa, descobrimos que está ligado ao compositor do seu sistema, o que apresenta algumas condições de corrida estranhas ou algo assim ....: confused: Ref: i3 / i3lock # 204 # 553

bebehei em 27 mar. 2020

👀1 👍1

Além do problema do compositor, a solução pausar / retomar mencionada acima é minha solução alternativa e funciona perfeitamente no meu caso.
Por que ele não funciona aqui, eu suspeito que este seja um bug em betterscreenlock de uma leitura rápida do script que chama i3lock sem o --nofork então i3lock bifurca-se imediatamente no lançamento, o que torna ele executa o comando unpause.

tsipinakis em 27 mar. 2020

Em nossa pesquisa, descobrimos que está ligado ao compositor do seu sistema,

Obrigado pela informação, vou desativar picom por enquanto e ver se isso resolve o problema.

Além do problema do compositor, a solução pausar / retomar mencionada acima é minha solução alternativa e funciona perfeitamente no meu caso.
Por que ele não funciona aqui, eu suspeito que este seja um bug no betterscreenlock de uma leitura rápida do script que ele chama de i3lock sem o --nofork, então o i3lock bifurca-se imediatamente na inicialização, o que o faz executar o comando unpause.

Como eu disse, o problema também ocorre com xtrlock (que não usa i3lock se não me engano), invocado com o seguinte 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 em 27 mar. 2020

Portanto, desativei picom e posso confirmar que nem uma única notificação apareceu na tela de bloqueio (atualmente usando betterlockscreen ) nas últimas ~ 15 horas. Eles foram todos exibidos depois que eu desbloqueei.

ghost em 28 mar. 2020

Posso confirmar que tenho o mesmo problema ao executar o picom. Desativá-lo também resolve o problema, mas infelizmente eu preciso disso. Talvez devêssemos levar isso para picom?