do not display notifications when screensaver/lock is on or when app is in full screen mode

[fawaf]

this might be expected behavior (or possibly configurable?), but it would be great to support this

Installation info

• Version: Dunst - A customizable and lightweight notification-daemon 1.3.0 (2018-01-05)
• Install type: package
• Distro and version: ubuntu 18.04.1 LTS

[fawaf]

oh, just found the closed issues about this. do you know if the state querying with i3lock works?

[bebehei]

could you give us please some more information? like some related issues, or some more details about the bad behavior.

[fawaf]

ah yeah, sorry about that.

#77 (comment) says that xscreensaver does not use X11 extensions for setting the screensaver state. i was wondering if i3lock does that and whether dunst respects that.

[bebehei]

Well, #77 is so old, I wouldn't bother to read it 😉

Do you experience problems? Because usually these type of problems are solved in i3lock.

[fawaf]

yeah, when i3lock is on, dunst still shows notifications over it.

[bebehei]

Tell me more. Which i3lock version? Reproducible behavior? desktop i3wm?

[tsipinakis]

@gnowxilef Can you try building from master? dffe1e1 is an attempt to improve the situation but hasn't been in a release yet.

[fawaf]

sure, i can do both.

i3lock version: i3lock: version 2.10 (2017-11-25) © 2010 Michael Stapelberg
yep, always happens
yes, desktop i3wm.

[bebehei]

@gnowxilef And does building dunst from master and running it help you, like @tsipinakis said?

git clone https://github.com/dunst-project/dunst.git
cd dunst
make all test
killall dunst
./dunst

[fawaf]

the latest master seems to fix the issue for fullscreen mode, but still displays over i3lock.

[bebehei]

Sorry, I can't reproduce it. I've tested it in my Ubuntu 18.04 VM, installed i3, i3lock and dunst. The notification does flicker shortly. But i3lock takes control (it probably receives an XVisibilityEvent) and redraws its own window.

The whole thing happens in less than 50ms.

I can't reproduce it. Could you please deliver a reproducer? Otherwise, I can't help you.

[fawaf]

what do you mean by "deliver a reproducer"? what do you want specifically?

[bebehei]

I just need some kind of information how I can reliably reproduce it on my system.

[progandy]

It seems that i3lock doesn't redraw on top of the notifications if a composition manager like compton is active (at least in glx mode, I did not try xrender). I never noticed that since I pause dunst notifications with SIGUSR1/2.

My steps were: Start an i3 session, start compton, start i3lock, sleep a bit and send a notification.

[bebehei]

@progandy Yeah, I can reproduce it now! Thank you very much!

The question is now: Is it dunst's or i3lock's issue?

[fawaf]

ah yes, i use compton as well.

[progandy]

That is probably i3lock. For some reason it doesn't raise itself if a compositor is enabled. Try this:

i3lock ; sleep 1; dunstify test; sleep 1; xdotool search --name '^i3lock' windowraise

[bebehei]

Well, I think i3/i3lock#130 is quite related. Interestingly, they claim to have it fixed in 2.10.

[progandy]

The readme and code from xsecurelock make for intersting reading. To hide notifications with a compositor, i3lock probably needs proper compositing support and not that half-baked thing that was reverted.

[WhyNotHugo]

Is the fullscreen behaviour configurable though? While I agree it makes sense to hide notifications when i3lock is running, I'd rather keep notifications around when running fullscreen apps (which is kinda 90% of the time for me).

[bebehei]

@WhyNotHugo The fullscreen behavior is something completely different. But it's implemented in #472 and on current master. Search for fullscreen in the dunstrc for more information.

[WhyNotHugo]

@bebehei Thanks for the clarification!

[bebehei]

So guys, can somebody please go on and upstream this to the correct repository?

[progandy]

As far as I can see, i3lock will just close the issue unless you come with a complete fix in a pull request.

i3/i3lock#130 (comment)
i3/i3lock#152

[bebehei]

Well, I've upstreamed it now with fairly easy reproduction instructions. I'm going to close this. We can't fix it in this repo.

[snprajwal]

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

[deescuderoo]

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

So far it works, thanks! Does this have any side effects? I'm not sure I get the docstring for the option: Unredirect all windows if a full-screen opaque window is detected, to maximize performance for full-screen windows. Known to cause flickering when redirecting/unredirecting windows, and the last sentence sounds a bit concerning. Thanks!

[snprajwal]

@deescuderoo as far as I have seen, it does not have any side effects apart from losing out on the transitions for lock/unlock. The flickering issue happens only on certain older versions of NVIDIA drivers, and shouldn't be an issue for most users.