wayland: Support xdg-shell as a fallback

[pslldq]

Support the xdg-shell wayland protocol as a fallback in case the wlr-layer-shell-unstable-v1 protocol is not present. This allows running dunst on wayland compositors not supporting the layer shell protocol.

Note that the xdg-shell protocol doesn't allow dunst to specify where it should be displayed on the screen. Therefore it is only chosen, when the layer-shell protocol is not available.

Currently this allows dunst to also run on the Gnome shell (using a different session D-Bus) and weston.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 0% with 67 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.83%. Comparing base (1dcc520) to head (83e95f9).
⚠️ Report is 44 commits behind head on master.

Files with missing lines	Patch %	Lines
src/wayland/wl.c	0.00%	67 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1433      +/-   ##
==========================================
- Coverage   65.47%   64.83%   -0.64%     
==========================================
  Files          50       51       +1     
  Lines        8923     9010      +87     
  Branches     1044     1055      +11     
==========================================
  Hits         5842     5842              
- Misses       3081     3168      +87     

Flag	Coverage Δ
unittests	64.83% <0.00%> (-0.64%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bynect]

@alebastr sorry to bother, I'm asking you since you did work a lot on the wayland code. from the review I don't see anything wrong but maybe you can spot some problem?

also why were the protocols changed @pslldq ?

[pslldq]

The xdg_shell protocol was changed due to the included version being outdated and printing the following error on my machine (Arch Linux):

interface 'xdg_toplevel' has no event 3

As the code generated with my wayland-scanner version (1.23.1) caused build errors on Debian buster and bullseye, I've used the wayland-scanner executable from a Debian buster docker container.

While this caused an older wayland-scanner executable being used (1.16 from Debian buster) for the code generation, it uses the xdg_shell protocol file from the current wayland-protocols 1.39 release.

[fwsmit]

I made the initial Wayland version of dunst (mostly copy pasted from the Mako notification daemon). I dont have time right now to look at it, but i can take a look at it in a week.
The Wayland scanner situation is not ideal, but I don't know of a better solution. We could also take a look at how other projects handle this

[pslldq]

The Wayland scanner situation is not ideal, but I don't know of a better solution. We could also take a look at how other projects handle this

Looking at the packages depending on the Arch Linux wayland-protocols package, the common way seems to depend on the wayland-protocols package of the given distribution and generate the protocol files as part of the build process. This has the advantage of not including generated files into the repository.

But it requires to check for the wayland-protocols version and dynamically set macros to support potentially missing fields (see wl-clipboard as an example)

[alebastr]

I'm not sure if supporting GNOME is a worthy reason to complicate the code. GNOME has its own notification daemon as an integral part of the shell, and it actually works better than anything third-party.
Weston support sounds a bit more reasonable, until you try it and see the notifications appearing randomly positioned on the screen. And most of the remaining non-wlroots-based compositors (Cosmic, niri, jay, Mir, etc) seem to support layer-shell.

---

The xdg_shell protocol was changed due to the included version being outdated and printing the following error on my machine (Arch Linux):

interface 'xdg_toplevel' has no event 3

This could be solved without touching the protocol files by binding to xdg_wm_base_interface version 3 or lower. You don't use anything from versions 4 or 5 and thus don't need it.

Requesting version 5 also breaks dunst with older compositors (anything before wlroots 0.18):

wl_registry@2: error 0: invalid version for global xdg_wm_base (11): have 2, wanted 5

I suggest doing something like this:

                 ctx.xdg_shell = wl_registry_bind(registry, name,
-                                &xdg_wm_base_interface, 5);
+                                &xdg_wm_base_interface, MIN(version, 3));
                 xdg_wm_base_add_listener(ctx.xdg_shell, &xdg_wm_base_listener, NULL);

and removing the protocol change commit.

---

Some changes in wl.c look suspicious, but I haven't touched the dunst code for almost a year. I'll try to find time for a closer look within a week.

[pslldq]

I'm not sure if supporting GNOME is a worthy reason to complicate the code. GNOME has its own notification daemon as an integral part of the shell, and it actually works better than anything third-party.
Weston support sounds a bit more reasonable, until you try it and see the notifications appearing randomly positioned on the screen.

The main use case is weston with the ivi-shell, which allows to programmatically control the window layout.

Without an external window positioning system, it is not really useful for a day to day use (resulting from the fact that the xdg-shell doesn't provide the means to set the global window positions). But it might be useful in case of development, where you're just interested in testing some input, D-Bus or rendering changes (e.g. avoid having to spawn a nested compositor on a GNOME/Weston desktop).

This could be solved without touching the protocol files by binding to xdg_wm_base_interface version 3 or lower. You don't use anything from versions 4 or 5 and thus don't need it.

Requesting version 5 also breaks dunst with older compositors (anything before wlroots 0.18):

oh, thanks. I was thinking "latest is greatest" when deciding what to use for the version and didn't realize that you want to use the lowest version number required for your application. As I also don't seem to use anything from version 2 or 3, I've now fixed it to version 1 for the broadest range of compability (and removed the protocol change commit).

[pslldq]

@alebastr gentle ping 😉

[bynect]

it looks good to me but again I'm not very knowledgeable about wayland

[fwsmit]

LGTM as well

[pslldq]

@alebastr Can you maybe take a look again on the PR? It currently seems to be stalled and I guess @bynect just waits for your closer look :D

[bynect]

alebastr Can you maybe take a look again on the PR? It currently seems to be stalled and I guess bynect just waits for your closer look :D

that's right. but I don't want to bother him too much. I will merge this if he doesn't reply since LGTM

[alebastr]

Apologies. As you may guess, lately I have significantly less time available for open-source than I'd prefer.

I wanted to do a proper review of the surface initialization sequence (which wasn't quite right even before this PR, given all the scaling problems), but haven't found enough time. So I'll mark a change that made me think that something suspicious is going on here and ask you to not block the progress on me.
Sorry for not being able to offer more help :'(

[alebastr]

This change looks suspicious.

Pending frame callback means that the compositor is not ready to process the update yet, and it will be queued or ignored. Bypassing this check and committing could lead to an inconsistent state, growth of the compositor update queue and locking of the wl_buffers until the next frame callback. I don't see an obvious risk of the latter, but I also don't understand why this change was necessary.

[pslldq]

From the method name schedule_frame_and_commit I've assumed that it would always do a commit (e.g. schedule_frame & commit vs. &&), so it looked a bit odd to me. Given that a potential geometry change may have happened in send_frame, I wanted to directly commit it to trigger a configure event. Therefore I've moved the surface damage from send_frame to schedule_frame_and_commit to avoid damaging the surface if the frame won't be drawn and did a commit in the bailout case.

Looking at the docs the commit should always be queued and committing despite the frame callback should just be a waste of resources.

But as it practically didn't make any difference, I've removed it and also moved the damaging back to send_frame.

[pslldq]

FYI: I've now noticed, that I've probably introduced the additional commit due to wlroots creating an wrong configure serial error, when seemingly a previous ack_configure wasn't commited. This was introduced while limiting the commit + roundtrip to only be done when no configure event was called yet (which also broke the infinite loop, if the compositor doesn't provide us with the desired size).

It may be a wlroots issue, as the spec specifies that multiple ack_configure are allowed without doing a commit.

[alebastr]

Huh. wlroots allows multiple ack_configures (with this clarification: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/115ba71872914f7b7dc3e5e57d4eff0ca892608b). And looking at the wlroots implementation, I don't understand how it's even possible to get a "wrong configure serial" if all we do is passing a serial from the configure event.

Can you check WAYLAND_DEBUG log for the exact configure/ack_configure sequence that triggers the error?

[pslldq]

Here you go: https://gist.github.com/pslldq/095f26c1f25de043bf36a6bce7b3478a

It's probably a misleading error message given the somewhat questionable behaviour of dunst. It seems to somehow trigger a second configure event with the same size (without a call to set_size), which triggers the error message.

Probably a deep dive into the wayland flow of dunst is necessary to understand why it behaves this way and correctly fix it (and weird stuff like why buffers are created and immediately destroyed).

[bynect]

There are probably some funky stuff going on with the wayland backend. Unfortunately I still didn't find the time to study how wayland works. So help in that regard is appreciated.
In the meantime, is the pr ready or is this part still a problem?

[pslldq]

The PR is ready. I've adapted the code to match the old behavior for the layer-shell: https://github.com/dunst-project/dunst/pull/1433/files#diff-112674804a66c58d30903e8bd842be763898fc1e5038394011f909108bdeb800R602-R606

[pslldq]

While reasoning/testing why I implemented the additional commit, I've stumbled upon a mutter warning:

(gnome-shell:4950): libmutter-WARNING **: 08:02:31.310: Invalid window geometry for xdg_surface@17. Ignoring for now, but this will result in client termination in the future.

I've now adapted the code to fix the warning (which resulted in a smaller patch) and rebased it on top of the current dunst master.

[bynect]

is it ready then?

[pslldq]

@bynect thanks for asking. Just tested it again and noticed I've missed testing the layer-shell (I've had it locally patched to force the xdg-shell, as wlroots has some checks, which weston/gnome just don't notice). And it quickly crashed with the layer-shell and wlroots. I've remembered that this was the issue, why I've introduced the additional commit back then. But to avoid other potential errors, I've reintroduced the potential infinite loop (if the compositor doesn't give us the size we want).

Now I've tested it against wlroots with layer-shell, weston and gnome-shell . So it's now ready from my side. But feel free to do a quick test yourself before merging.

[bynect]

Since I need to install wayland environment to test this, what compositor/settings do you recommend?

[pslldq]

Ah, ok. If you want to, then choose your favorite Wayland desktop environment, that's not Gnome or Weston (unless you want to test the new xdg-shell support). Here are some: https://wayland.app/protocols/wlr-layer-shell-unstable-v1#compositor-support

KDE is probably the easiest (while not that practical), as everybody would just use the integrated notifications. For this you'll probably need to start a dedicated dbus with dbus-launch to test it.

I think the rest of the wayland spectrum are tiling compositors. Some tiling compositors (like mine too) use wlroots to handle most of the wayland stuff. So these should work (in my quick testing). But if you want to invest the work of getting started with a compositor, just choose one of the list and try it. Sway is probably the most used tiling wayland compositor (but it's also based on wlroots).

[bynect]

Ah, ok. If you want to, then choose your favorite Wayland desktop environment, that's not Gnome or Weston (unless you want to test the new xdg-shell support). Here are some: https://wayland.app/protocols/wlr-layer-shell-unstable-v1#compositor-support

KDE is probably the easiest (while not that practical), as everybody would just use the integrated notifications. For this you'll probably need to start a dedicated dbus with dbus-launch to test it.

I think the rest of the wayland spectrum are tiling compositors. Some tiling compositors (like mine too) use wlroots to handle most of the wayland stuff. So these should work (in my quick testing). But if you want to invest the work of getting started with a compositor, just choose one of the list and try it. Sway is probably the most used tiling wayland compositor (but it's also based on wlroots).

I wanted to try both of the layer and non layer compositor.

I guess sway and weston should do the trick?

But is some configuration needed to make this work on then?

[pslldq]

I wanted to try both of the layer and non layer compositor.

I guess sway and weston should do the trick?

yeah, testing the most used/useful compositors is not a bad choice.

But is some configuration needed to make this work on then?

No, you don't have to. You can just run weston and without any configuration it will run the desktop shell, where you can start a shell (i think it's weston-shell) from the toolbar. Then just run dunst and send some notifications with dunstify.

I'm not that familiar with sway, but looking at the video on their homepage, you can simply start a program with Super+d and typing it's command to start it. So you can just start your favorite terminal emulator and then start dunst + send notifications with dunstify

[pslldq]

rebased the PR to the current master to resolve merge conflicts

[pslldq]

@bynect any updates on this?

[bynect]

Sorry I was busy this days. If it is completed I will merge it 👍

[pslldq]

From my side this is completed and tested. My last info was that you wanted to test it.

[bynect]

From my side this is completed and tested. My last info was that you wanted to test it.

Yes I wanted to test it. However in this period I don't think I will find enough time to do it properly. If you tested it thoroughly I will trust you and merge anyway to not block this too much

[pslldq]

Yes I wanted to test it. However in this period I don't think I will find enough time to do it properly. If you tested it thoroughly I will trust you and merge anyway to not block this too much

Just did a rebase against the current master (to be sure), built it with meson and tested it on weston, a nested gnome-shell and river. My testing consisted of displaying multiple notifications, dismissing them via clicking or timeout and after all notifications were gone (i.e. window closed), create a new notification to see it still works.

So on my side, I don't see any problem or warning message.

[bynect]

Thanks for the hard work 👍