Dunst: Dunst does not update screen size when resolution changes

[josswright]

I use dunst on a laptop where I often present on an external screen. When I do so, I tend to reduce my internal monitor resolution to match the external. (My internal monitor goes from 1920x1080 to, for example, 1024x768).

On reducing the screen resolution, dunst seems to display notifications correctly. When, however, I retun to the larger screen size, dunst notifications now appear in the correct location for the smaller screen. (So 1024x768 pixels into my 1920x1080 screen.)

For reference, I'm running this under i3, and changing resolution using xrandr directly.

Installation info

• Version: Dunst - A customizable and lightweight notification-daemon 1.2.0 (2017-07-12)
• Install type: Package
• Distro and version: Arch Linux

[tsipinakis]

Can you run xev -event randr, reproduce it and post the output? We might be looking for the wrong screen update event.

[tsipinakis]

Ping @josswright

[josswright]

Oh, sorry. I didn't see the reply. I'll upload the data later today when I'm connected to an external projector.

[josswright]

Here's a dump, as requested. The steps were:
1) Connect to external projector and enable. (xrandr --output DP1 --auto)
2) Manually set internal monitor resolution to match external. (xrandr --output eDP1 --mode 1024x768)
3) Disconnect external and disable. (xrandr --output DP1 --off)
4) Reset internal resolution. (xrandr --output eDP1 --auto).

Tested, and the dunst notification appears 1024x768 pixels into my 1920x1080 internal monitor.

randr.log

[wavexx]

I have the same issue. When disconnecting the external screen, thus reducing the overall geometry, the notification is still shown outside of the current screen boundaries [I'm on the current master branch].

I'm using notification-screen-follows-mouse, so it might be that the notification of pointer changing screen is never emitted? I manually invoke xrandr --auto when plugging/unplugging extra monitors.

[bebehei]

@wavexx What does xrandr --version report? I can't reproduce it with my own system.

[josswright]

For me:

xrandr program version       1.5.0
Server reports RandR version 1.5

[bebehei]

@josswright Thanks for the answer. Could you also please paste the systemctl status --user dunst.service output after reproducing this?

[wavexx]

On Thu, Dec 21 2017, Benedikt Heine wrote:

@wavexx What does xrandr --version report? I can't reproduce it with my own system.

I'm on debian unstable.

$ xrandr --version
xrandr program version 1.5.0
Server reports RandR version 1.5

I'm not sure the output of systemctl status --user dunst.service
matters here. If I kill dunst, it gets respawned correctly and the
notifications are shown correctly using the new geometry.

I tried again and narrowed the issue a bit:

• follow=mouse is set
• mouse is on external screen
• disconnect external screen
• generate notification -> not shown (likely offscreen)
• mouse the mouse
• generate notification -> correctly shown

The current screen is probably not updated until the pointer is moved.

Not sure this is the complete story, but since I'm a keyboard-heavy
user, it would explain why I would see it so often.

[josswright]

I also don't run dunst through a systemd service -- I just spawn it manually. (Arch Linux.)

(Or, I should clarify, through my .xinitrc.)

[bebehei]

@josswright Interesting that you don't spawn dunst via dbus. But anyways, what's your setting of i3's focus_follows_mouse?

@wavexx do you run also i3? If so, could you also tell me the value of focus_follows_mouse?

[josswright]

@bebehei Just default: focus_follows_mouse yes

[wavexx]

On Thu, Dec 21 2017, Benedikt Heine wrote:

@wavexx do you run also i3? If so, could you also tell me the value of
focus_follows_mouse?

follow=mouse is the dunst setting.

As a WM I'm using spectrwm (which does focus-follows-mouse anyway).

[josswright]

Oh, sorry, for dunst configuration I've got follow = keyboard

[bebehei]

This issue is getting weirder to debug by every comment 😂 I've tested all four combinations already yesterday and nothing made me able to reproduce this.

Well, I can only shoot into the dark and I'm guessing around. I'm not getting illuminated by the randr.log. I've created now a branch with Debug output of the events. Could you please build the 434-debug branch from my repository and paste the output while reproducing? If you annotate the output with the specific "I've done this/that here" that would be great.

I've also created a PKGBUILD.gz, which builds this as a package directly from there. (You have to gunzip it first, github does not allow me to push it raw.)

Thanks in advance.

[wavexx]

Still affected by this. When the screen configuration changes, dunst still uses the old screen.

I'm pretty sure this happens due to:

• follow=mouse
• window is moved to another region due to xrandr configuration change
• mouse is never actually moved (hotkey)
• the focused window never changed

I can easily "fix" dunst by moving the mouse to another window, thus triggering a focus change event. This does update the position of the notification instantly to the current screen.

[tsipinakis]

@wavexx Can you build https://github.com/tsipinakis/dunst/commit/e97f22600fefdd93b3da481c95d2c9750a768d24 and tell me if that fixes it?

From a few tests I've tried I can't reproduce this locally.

[wavexx]

On Sat, Mar 23 2019, Nikos Tsipinakis wrote:

@wavexx Can you build tsipinakis@545db8c and tell me if that fixes it?

Ok, I've built it but testing is also going to take a while on my side.
This is annoying to reproduce :/