Dunst notifications displayed on lockscreen (betterlockscreen, xtrlock)

[ghost]

Installation info

• Version: Dunst - A customizable and lightweight notification-daemon 1.4.1 (2019-07-03)
• Install type: dunst from official Arch repositories
• Distro and version: Arch Linux

Original issue: https://github.com/pavanjadhaw/betterlockscreen/issues/160

Asking here since the issue occurs both with betterlockscreen and xtrlock.

---

I'm using Arch Linux with the following packages:

• betterlockscreen-git^AUR
• dunst
• xidlehook^AUR

My issue is that dunst notifications still appear on lockscreen.

I've run systemctl enable betterlockscreen@$USER to enable the user service.

If I understand correctly, since the systemd user service is enabled, betterlockscreen does the following before locking, and this after unlocking.

I tried to use a lockscreen script replicating these commands instead of using the regular betterlockscreen -l -t "" command as a workaround (since the dunst notifications were still displayed), but unfortunately it doesn't make any difference.

• lockscreen.sh

#!/bin/bash

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

_Note: I also tried with killall -SIGUSR1 dunst and killall -SIGUSR2 dunst as suggested on the Arch Wiki._

and here's how it's triggered by xidlehook^AUR:

• ~/.xinitrc

#!/bin/bash

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

So basically, the screen locks after 5 minutes and turns off after another extra 5 minutes. This works perfectly fine, my only issue is that dunst notifications are still displayed on the lockscreen.

It's quite difficult to reproduce.

Thanks in advance.

Edit: I'm also using picom with the following 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; ```

[bebehei]

Well, I'm a maintainer of this and I even have the same problem. :see_no_evil: I'm using i3lock as lockscreen and I'm using compton as a compositing manager.

In our research, we found out, that, it's linked to the compositor of your system, which introduces some weird race conditions or so.... :confused: Ref: i3/i3lock#204 #553

[tsipinakis]

Other than the compositor issue the pause/unpause solution mentioned above is my workaround, and it works perfectly in my case. For why it doesn't work here, I suspect this is a bug in betterscreenlock from a quick read-through of the script it calls i3lock without the --nofork so i3lock forks immediately on launch which makes it run the unpause command.

[ghost]

In our research, we found out, that, it's linked to the compositor of your system,

Thanks for the info, I'll disable picom for now and see if that solves the issue.

Other than the compositor issue the pause/unpause solution mentioned above is my workaround, and it works perfectly in my case. For why it doesn't work here, I suspect this is a bug in betterscreenlock from a quick read-through of the script it calls i3lock without the --nofork so i3lock forks immediately on launch which makes it run the unpause command.

As I said, the issue also occurs with xtrlock ( which doesn't use i3lock if I'm not mistaken), invoked with the following 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]

So I disabled picom and I can confirm that not a single notification appeared on my lockscreen (currently using betterlockscreen) in the last ~15 hours. They were all displayed after I unlocked.

[kamushadenes]

I can confirm I have the same issue running picom. Disabling it solves the problem as well, but unfortunately I need it. Perhaps we should take this to picom?

[shervinsahba]

Are there updates to this? I have the same issue with betterlockscreen: v4.0.3 and picom 8.2-1.

[fwsmit]

#!/bin/bash

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

I think adding a sleep before locking the screen should work. Dunst needs a little but to receive the message and close all notifications. Let me know if it works (if it doesn't, try adding a delay of 1 second, just to be sure).

[snprajwal]

This issue is fixed by enabling unredir-if-possible in either picom.conf or passing it as an arg while starting it.

[vishalmadhvi]

We wants to disable dunst notification on locked xscreensaver and resume notification when xscreen saver is unlocked.