Dunst: Dunst-Benachrichtigungen werden auf dem Sperrbildschirm angezeigt (betterlockscreen, xtrlock)

Erstellt am 27. März 2020 · 5Kommentare · Quelle: dunst-project/dunst

Installationsinfo

Wenn Ihre Version älter als 1.2 ist, schließen Sie bitte aus, dass das Verhalten im Master bereits behoben ist

Version: Dunst - A customizable and lightweight notification-daemon 1.4.1 (2019-07-03)
Installationstyp: dunst aus offiziellen Arch-Repositorys
Distribution und Version: Arch Linux

Originalausgabe: https://github.com/pavanjadhaw/betterlockscreen/issues/160

Frage hier, da das Problem sowohl bei betterlockscreen als auch bei xtrlock auftritt.

Ich verwende Arch Linux mit den folgenden Paketen:

Mein Problem ist, dass dunst Benachrichtigungen immer noch auf dem Sperrbildschirm angezeigt werden.

Ich habe systemctl enable betterlockscreen@$USER , um den Benutzerdienst zu aktivieren.

Wenn ich das richtig verstehe, führt betterlockscreen, da der systemd-Benutzerdienst aktiviert ist, vor dem Sperren Folgendes aus , und dies nach dem Entsperren.

Ich habe versucht, ein Lockscreen-Skript zu verwenden, das diese Befehle repliziert, anstatt den regulären betterlockscreen -l -t "" Befehl als Problemumgehung zu verwenden (da die dunst Benachrichtigungen immer noch angezeigt wurden), aber leider macht es keinen Unterschied.

lockscreen.sh

#!/bin/bash

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

_Hinweis: Ich habe es auch mit killall -SIGUSR1 dunst und killall -SIGUSR2 dunst versucht, wie im Arch-Wiki vorgeschlagen._

und so wird es durch xidlehook ^AUR ausgelöst:

~/.xinitrc

#!/bin/bash

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

Grundsätzlich wird der Bildschirm nach 5 Minuten gesperrt und nach weiteren 5 Minuten ausgeschaltet. Das funktioniert einwandfrei, mein einziges Problem ist, dass dunst Benachrichtigungen immer noch auf dem Sperrbildschirm angezeigt werden.

Es ist ziemlich schwer zu reproduzieren.

Danke im Voraus.

Bearbeiten: Ich verwende auch picom mit dem folgenden in 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

Quelle

ghost

Alle 5 Kommentare

Nun, ich bin ein Betreuer von diesem und ich habe sogar das gleiche Problem. :see_no_evil: Ich verwende i3lock als Sperrbildschirm und Compton als Compositing-Manager.

Bei unseren Recherchen haben wir herausgefunden, dass es mit dem Compositor Ihres Systems verbunden ist, was einige seltsame Racebedingungen oder so einführt.... :verwirrt: Ref: i3/i3lock#204 #553

bebehei am 27. März 2020

👀1 👍1

Abgesehen vom Compositor-Problem ist die oben erwähnte Pause/Unpause-Lösung meine Problemumgehung, und sie funktioniert in meinem Fall perfekt.
Warum es hier nicht funktioniert, vermute ich, dass dies ein Fehler in betterscreenlock aus einem schnellen Durchlesen des Skripts hervorgeht, das i3lock ohne --nofork aufruft es führt den unpause-Befehl aus.

tsipinakis am 27. März 2020

Bei unseren Recherchen haben wir herausgefunden, dass es mit dem Compositor Ihres Systems verknüpft ist,

Danke für die Info, ich werde picom vorerst deaktivieren und sehen, ob das das Problem löst.

Abgesehen vom Compositor-Problem ist die oben erwähnte Pause/Unpause-Lösung meine Problemumgehung, und sie funktioniert in meinem Fall perfekt.
Warum es hier nicht funktioniert, vermute ich, dass dies ein Fehler in betterscreenlock ist, wenn man das Skript schnell durchliest, das es i3lock ohne --nofork aufruft, sodass i3lock sofort beim Start verzweigt, wodurch es den unpause-Befehl ausführt.

Wie gesagt, das Problem tritt auch mit xtrlock (das i3lock wenn ich mich nicht irre), aufgerufen mit dem folgenden Skript:

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 am 27. März 2020

Also habe ich picom deaktiviert und kann bestätigen, dass in den letzten ~15 Stunden keine einzige Benachrichtigung auf meinem Sperrbildschirm (derzeit betterlockscreen ) angezeigt wurde. Sie wurden alle angezeigt, nachdem ich entsperrt hatte.

ghost am 28. März 2020

Ich kann bestätigen, dass ich das gleiche Problem beim Ausführen von picom habe. Das Deaktivieren behebt das Problem auch, aber leider brauche ich es. Vielleicht sollten wir das zu picom bringen?

kamushadenes am 21. Apr. 2020

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen

Dunst: Dunst-Benachrichtigungen werden auf dem Sperrbildschirm angezeigt (betterlockscreen, xtrlock)

Installationsinfo

Alle 5 Kommentare

Verwandte Themen