Dunst: Notifications Dunst affichées sur l'écran de verrouillage (betterlockscreen, xtrlock)

Créé le 27 mars 2020 · 5Commentaires · Source: dunst-project/dunst

Informations sur l'installation

Si votre version date d'avant la 1.2, veuillez exclure que le comportement soit déjà corrigé dans le master

Version : Dunst - A customizable and lightweight notification-daemon 1.4.1 (2019-07-03)
Type d'installation : dunst partir des dépôts officiels d'Arch
Distribution et version : Arch Linux

Numéro d'origine : https://github.com/pavanjadaw/betterlockscreen/issues/160

Demander ici car le problème se produit à la fois avec betterlockscreen et xtrlock .

J'utilise Arch Linux avec les packages suivants :

Mon problème est que les notifications dunst apparaissent toujours sur l'écran de verrouillage.

J'ai exécuté systemctl enable betterlockscreen@$USER pour activer le service utilisateur.

Si j'ai bien compris, puisque le service utilisateur systemd est activé, betterlockscreen fait ce qui suit avant le verrouillage, et ce après le déverrouillage.

J'ai essayé d'utiliser un script lockscreen répliquant ces commandes au lieu d'utiliser la commande betterlockscreen -l -t "" habituelle comme solution de contournement (puisque les notifications dunst étaient toujours affichées), mais malheureusement cela ne fait aucune différence.

lockscreen.sh

#!/bin/bash

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

_Remarque : j'ai également essayé avec killall -SIGUSR1 dunst et killall -SIGUSR2 dunst comme suggéré sur Arch Wiki ._

et voici comment il est déclenché par xidlehook ^AUR :

~/.xinitrc

#!/bin/bash

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

Donc, fondamentalement, l'écran se verrouille après 5 minutes et s'éteint après 5 minutes supplémentaires. Cela fonctionne parfaitement bien, mon seul problème est que les notifications dunst sont toujours affichées sur l'écran de verrouillage.

C'est assez difficile à reproduire.

Merci d'avance.

Edit : j'utilise également picom avec ce qui suit dans 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

Source

ghost

Tous les 5 commentaires

Eh bien, je suis un mainteneur de cela et j'ai même le même problème. :see_no_evil: j'utilise i3lock comme écran de verrouillage et j'utilise compton comme gestionnaire de composition.

Dans nos recherches, nous avons découvert que c'est lié au compositeur de votre système, ce qui introduit des conditions de course étranges ou presque.... :confused: Ref: i3/i3lock#204 #553

bebehei le 27 mars 2020

👀1 👍1

Outre le problème du compositeur, la solution de pause/reprise mentionnée ci-dessus est ma solution de contournement et elle fonctionne parfaitement dans mon cas.
Pour savoir pourquoi cela ne fonctionne pas ici, je soupçonne qu'il s'agit d'un bogue dans betterscreenlock partir d'une lecture rapide du script qu'il appelle i3lock sans le --nofork donc i3lock bifurque immédiatement au lancement, ce qui rend il exécute la commande unpause.

tsipinakis le 27 mars 2020

Dans nos recherches, nous avons découvert que c'est lié au compositeur de votre système,

Merci pour l'info, je vais désactiver picom pour le moment et voir si cela résout le problème.

Outre le problème du compositeur, la solution de pause/reprise mentionnée ci-dessus est ma solution de contournement et elle fonctionne parfaitement dans mon cas.
Pour savoir pourquoi cela ne fonctionne pas ici, je soupçonne qu'il s'agit d'un bogue dans betterscreenlock à partir d'une lecture rapide du script qu'il appelle i3lock sans --nofork donc i3lock bifurque immédiatement au lancement, ce qui lui permet d'exécuter la commande unpause.

Comme je l'ai dit, le problème se produit également avec xtrlock (qui n'utilise pas i3lock si je ne me trompe pas), invoqué avec le script suivant :

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 le 27 mars 2020

J'ai donc désactivé picom et je peux confirmer qu'aucune notification n'est apparue sur mon écran de verrouillage (en utilisant actuellement betterlockscreen ) au cours des ~15 dernières heures. Ils ont tous été affichés après mon déverrouillage.

ghost le 28 mars 2020

Je peux confirmer que j'ai le même problème avec picom. Le désactiver résout également le problème, mais malheureusement j'en ai besoin. Peut-être devrions-nous prendre cela pour picom?