onny commented 8 years ago

I tried to run dunst with the i3-compatible wayland twm sway but it won't work yet. Is there any wayland support planed or has this to be done in sway itself?

Best regards, Jonas

aaron-rohn commented 8 years ago

What issues were you running into? Are you not willing to use the xwayland module? I've run dunst on xwayland in sway with good results. Due to the relative inactivity on this project I wouldn't expect to see any of the major overhauls necessary to switch over to a pure-wayland implementation.

WhyNotHugo commented 7 years ago

I've tried using dunst under wayland/sway but:

Positioning is off. Dunst is always on the upper left corner.
Global hotkeys don't work, so I can't close notifications with them, etc.
Clicking notifications clicks through to the window behind it.

tjaartvdwalt commented 7 years ago

@hobarrera, is there any progress on this?

My experience on positioning: I struggled to get dunst to show in the top right corner, and failed. Hower, after a reboot, dunst now does appear on the top right. I am not sure why...

On the notifications clicks, I think this may be a sway issue, because a similar thing happens with popup dialogs.

tsipinakis commented 7 years ago

I am currently in the process of refactoring the drawing code and separating from X11 related code in the refactor-drawing branch, once that's done it should be easy to add on other display servers such as wayland.

That being said, I'm not using wayland myself so if it is to be implemented someone should step up and make sure it works properly since I can't test it that well.

akiva commented 6 years ago

Any updates on this issue? Perhaps Sway's in-progress migration from wlc to wlroots will be of help?

bebehei commented 6 years ago

First, we have to refactor our X11/drawing code. The code has to get split and simplified. Then we can get on and make it compatible to wayland. The process will take some time.

emersion commented 6 years ago

I'm a sway/wlroots dev and I'm interested to help getting dunst work natively in Wayland. We have designed a protocol that would allow to show notifications.

It seems the drawing code refactor PR (#496) is getting reviewed. As you said, it's better to wait until this gets merged.

alex3kov commented 6 years ago

I would gladly test dunst under Sway. Subscribed to this issue, please post here once there is something to test.

bebehei commented 6 years ago

We have designed a protocol that would allow to show notifications.

@emersion Could you please elaborate this? I guess, your referenced protocol is not about freedesktop notifications sent via DBus.

The main problems using dunst via the x11 wayland compatibility layer is that XCreateWindow is created with x=0,y=0 and then dunst moves the window via XWinMove to its actual position. And according to those IRC logs, XWinMove isn't supported on XWayland.

I'm not sure what might help, but @tsipinakis and myself are very inexperienced in X11 programming. @emersion If you want to review our current code and our thinking model, that would be a good choice.

emersion commented 6 years ago

I guess, your referenced protocol is not about freedesktop notifications sent via DBus.

The protocol can be used to create native Wayland surfaces on top of other windows, on a screen corner. No Xwayland involved.

The main problems using dunst via the x11 wayland compatibility layer is that XCreateWindow is created with x=0,y=0 and then dunst moves the window via XWinMove to its actual position. And according to those IRC logs, XWinMove isn't supported on XWayland.

I'm using Dunst on Xwayland with sway-1.0-alpha.1 right now, and notifications appear at the correct position, so I guess XWinMove works now. It requires the compositor to support it though.

I'm not sure what might help, but @tsipinakis and myself are very inexperienced in X11 programming. @emersion If you want to review our current code and our thinking model, that would be a good choice.

I'm not an experienced X11 dev, and I'm not really interested in making the X11 code nice. :)

Though, I'm interested in adding nice Wayland support, without Xwayland. Is that something you're interested in?

tsipinakis commented 6 years ago

Sorry for the late reply to this one. The drawing refactor is pretty much ready to be merged.

I'm interested in adding nice Wayland support, without Xwayland. Is that something you're interested in?

Definitely, this refactor was done with having support for multiple outputs in mind.

I have pushed my proposal on how multiple outputs should work in the refactor-outputs branch (keep in mind this is completely unreviewed, would love @bebehei's opinion on this.). You can use it as a way to start testing out how well wayland works with dunst if you are still interested in implementing native support.

emersion commented 6 years ago

Gah, I started looking at porting dunst a week ago and concluded it would be difficult, so I ended up starting a new project from scratch.

tsipinakis commented 6 years ago

That's fine, if you'd rather focus on your new project I'm sure somebody else will step up to implement wayland support.

To make a quick list of what has to be implemented:

Final refactors/abstractions
- [x] Move (basically copy-paste) color initialisation from x_setup to settings
- [x] Abstract get_active_screen to output struct
- [X] ~~Refactor keyboard_shortcut struct in settings to be output agnostic~~ Edit: Keyboard shortcuts don't work in wayland, this is redundant.
Implementation
- [ ] Implement functions mentioned in output.h (display_surface, create_window etc)
- [ ] Implement mouse click detection

That's all I can think of right now but I'm sure I missed a thing or two. I'll try to do the first few myself but I can't implement the actual support since I haven't used wayland and I'm not familiar with the API.

emersion commented 6 years ago

Implement key combination parsing & grabbing

Note that Wayland clients cannot set global keybindings.

tsipinakis commented 6 years ago

We've been planning to migrate away for global keybindings ourselves (see #284 ) so that shouldn't be a problem in the long run. For now that does mean that history is not going to work that well though unfortunately.

concatime commented 6 years ago

Any news on this thread?

emersion commented 6 years ago

@concatime If you want a Dunst replacement for Sway, you can try https://github.com/emersion/mako

tsipinakis commented 6 years ago

@concatime Since none of the current maintainers (me and @bebehei ) actively use wayland we are waiting for someone that does to step up and implement this properly.

If anyone wants to work on this feel free to ping me for guidance or for any questions.

Most of the work would be implementing these functions with the wayland API.

ZakharEl commented 5 years ago

Tsipinakis' refactor-outputs branch works in sway with correct positioning of the notifications but the keybindings still don't work. Thanks for the hard work Tsipinakis.

bebehei commented 5 years ago

@ZakharEl Nice to hear this. I'm working currently on a dunstcmd command client. I haven't implemented a replacement for the keybindings yet. But I'll finish this pretty soon and fire then a PR. So we'll have wayland support pretty soon.

It may not be native support yet, but at least it should work.

ZakharEl commented 5 years ago

@bebehei whenever you got the dunstcmd with a manual I'll be willing to test it for you and report what features work. Thanks bebehei I appreciate all the work you software developers do and the linux community.

ZakharEl commented 5 years ago

Did more testing with the refactor-outputs branch and transparency does not work in sway but it does not click through the notification box to any app behind it which is good.

tsipinakis commented 4 years ago

Since dunstctl is now merged and dunst no longer depends on keyboard shortcuts for basic functionality, I thought I'd give wayland support a shot.

If you want a Dunst replacement for Sway, you can try https://github.com/emersion/mako

Kudos to the mako devs, I used the mako output/buffer code as a base and ported it to the dunst api.

Currently it's pretty simplistic, doesn't support any mouse events and only anchors the window on the top right, but I'll try to have full support for it soon.

You can try it out on the wayland branch, if anyone is interested in either helping improve this or test it please do ping me here (PR's on the wayland branch welcome :) ).

Note: That branch currently forces wayland and doesn't even attempt to start X11, this will obviously be changed in the future.

A rough todo list:

[ ] Fix existing leaks/properly deconstruct all objects
[ ] Screen dimension detection support
[ ] Geometry margin support
[ ] Geometry anchor support (top-left, top-right etc)
[ ] Mouse click event support
[ ] Focus follow mode support (AFAIK, there's no way to tell keyboard/mouse focus apart in wayland, so these will probably behave identically)
[ ] Idle detection support
[ ] round corner support
[ ] transparency support
[ ] X11/Wayland auto detection
[ ] Fullscreen window detection support (is this possible in wayland?)

emersion commented 4 years ago

Since dunstctl is now merged and dunst no longer depends on keyboard shortcuts for basic functionality, I thought I'd give wayland support a shot.

Nice!

Screen dimension detection support

Wayland clients shouldn't try to detect the screen size. The layer-shell configure events should be enough.

AFAIK, there's no way to tell keyboard/mouse focus apart in wayland, so these will probably behave identically

wl_pointer and wl_keyboard focus are separate, see each interface's enter/leave events.

Fullscreen window detection support

Not possible with wayland, however letting uses pick the layer-shell layer should allow them to choose whether notifications show on top of fullscreen windows or under them.

ZakharEl commented 4 years ago

Sweet are you meaning to say that the master branch of dunst from the dunst-project now have been merged with dunst-ctl? If so what commit and what version of dunst were they merged? I'll try testing it out on wayland but I not sure if sway would be the best wayland window manager to test it with.

tsipinakis commented 4 years ago

It was merged with https://github.com/dunst-project/dunst/commit/fb2ffd425e2cfe42de0c633bcdf3a0203bfef90d. So just building from master also gets you dunstctl now.

Edit: Also it hasn't been in a release yet, but I aim to release 1.5 with it soon.

progandy commented 4 years ago

AFAIK, there's no way to tell keyboard/mouse focus apart in wayland, so these will probably behave identically

wl_pointer and wl_keyboard focus are separate, see each interface's enter/leave events.

As far as I know, an unfocused client cannot detect the currently active output, though. It could be done on sway with the sway IPC protocol. I'd suggest adding a dunstctl command to change the output, then a script like this can move the notification window:

old=""
while read change && read output ; do
  if [[ $change = "focus" && ! $output = $old ]]; then
    old=$output
    dunstctl set-output $output
  fi
done < <(swaymsg -t subscribe -m '[ "workspace" ]' | jq --unbuffered ".change,.current.output")

emersion commented 4 years ago

To display a layer-shell surface on the active output, set the output argument to NULL when creating the layer surface.

ZakharEl commented 4 years ago

The problem with sway for this test case is the use of xorg-server-xwayland for X11 support might just port the functionality without actually natively running it through wayland thus not actually serving as a native wayland test case. I think I'll test it without that optional dependency. If anyone else has or is planning on testing it with sway I would probably advise against having that dependency while testing it or pick a different wayland window manager, desktop environment, etc. The idea is that any and all wayland window managers, etc used to test it avoid an x11 compatability layer to truely test wayland support.

ZakharEl commented 4 years ago

also thanks progandy for the advice.

WhyNotHugo commented 4 years ago

Would testing it with unset DISPLAY ensure that no xwayland functionality gets in the way of testing?

tsipinakis commented 4 years ago

To be completely sure, unseting $DISPLAY would work. However, the wayland branch currently forces the use of the wayland protocol (read: X11 shouldn't work at all in that branch at the moment), so it shouldn't matter.

fwsmit commented 3 years ago

Hi I've picked up the project of making dunst work on wayland. Here is what I've done. I've fixed a bug in #779 where notifications were not disappearing on wayland, because dunst thought the user was idle. The idle functionality is now turned off in wayland, because there is no way to detect if a user is idle in wayland, I think. Because of this bugfix, dunst should work well on XWayland. I'm not aware of any issues with that currently.

On top of that, I've been working on native wayland support. There are still a few bugs, but I'm getting there. You can look at #781 for a list of bugs that have to be fixed, but I've copied the todo from above as well.

Current progress:

[x] Fix existing leaks/properly deconstruct all objects
[x] Screen dimension detection support (by using anchors)
[X] Geometry margin support
[X] Geometry anchor support (top-left, top-right etc)
[X] Mouse click event support
[x] Focus follow mode support
[x] Idle detection support (Not possible)
[x] round corner support (mouse clicks are still detected in a square though)
[x] transparency support (only when specifying with color alpha, not with the setting 'transparency')
[x] X11/Wayland auto detection
[x] Idle handling
[x] Fullscreen handling (requires changing how the settings work)

progandy commented 3 years ago

Idle detection might be possible by reading the systemd-logindl IdleHInt for the session or the idle-client protocol. For XWayland someone would have to teach it that or write some daemon (or patch the compositor) to simulate user activity while wayland is not idle.

Focus follow mode support

That is partially possible (comment from emersion):

To display a layer-shell surface on the active output, set the output argument to NULL when creating the layer surface.

fwsmit commented 3 years ago

Idle detection might be possible by reading the systemd-logindl IdleHInt for the session or the idle-client protocol. For XWayland someone would have to teach it that or write some daemon (or patch the compositor) to simulate user activity while wayland is not idle.

Thanks, I've implemented that protocol. It's not an official wayland protocol yet, but wlroots (and with it sway) supports it.

To display a layer-shell surface on the active output, set the output argument to NULL when creating the layer surface.

Turns out we already did that due to a bug. I'm working on fixing that.

fwsmit commented 3 years ago

I have one bug that I can't seem to fix, so maybe one of you can help. When running #781 on sway I have an issue where the input region is only updated after moving the poiner. So to reproduce this open two notifications:

notify-send "a notification that is longer than the one below it."
notify-send "short"

When clicking the long notification away and (without moving your pointer) you can click again to dismiss the short notification. Even when your pointer isn't on a notification anymore.

The layer_surface gets updated correctly after clicking away the notification and according to the docs, only input that's on the surface should be accepted. This might be a sway bug, but i wasn't able to test this on another window manager. Mako avoids this bug by having only notifications of the same width.

fwsmit commented 3 years ago

If anyone is able to test #781 on wayland, that would be very welcome (@alex3kov).

Narrat commented 3 years ago

No real testing involved currently, but at least I have your wayland-2 branch running with the hikari compositor. Which means I cannot test idle behaviour, as it doesn't support idle-client (as far as I know). So far it is working as 1.5.0 (but I cannot really tell if it uses the xwayland backend or running natively :D )

fwsmit commented 3 years ago

Cool. On a wayland compositor it will default to wayland output. If you want to be entirely sure, you can dunst -verbosity info and it will tell you what output it's using. I see that hikari is based on wlroots, which does support the idle protocol, so there is a good chance hikari will as well. Until a few commits ago it even crashed when there was no idle support, so depending on the version you used you would have probably noticed. To test if a compositor supports a given protocol you can run weston-info, which will list all supported protocols.

Narrat commented 3 years ago

Thank you for the infos regarding on how to get the information. Yes, hikari is wlroots based. But for example the layer-shell support is a rather newish enhancement (came with 1.1.0) for this compositor, so I doubt a less needed protocol is already implemented/supported :D One general note: weston-info has a deprecation warning. So everyone who stumbles upon this and their weston-package doesn't offer the binary anymore: wayland-info is the replacement (https://lists.freedesktop.org/archives/wayland-devel/2020-July/041520.html) (https://gitlab.freedesktop.org/ofourdan/wayland-info). Dunno if it will be shipped with the wayland package or stays standalone. (Edit: There will be wayland-utils)

Running the dunst command at least offered the information what output is used. Looking good so far. The following line not so much. Dunno what is at fault.

~ $ dunst -verbosity info                                                        
INFO: Using Wayland output
zsh: segmentation fault (core dumped)  dunst -verbosity info

Compositor Hikari:

~ $ wayland-info                                                                 
interface: 'wl_shm',                                     version:  1, name:  1
interface: 'wl_drm',                                     version:  2, name:  2
interface: 'zwp_linux_dmabuf_v1',                        version:  3, name:  3
interface: 'wl_compositor',                              version:  4, name:  4
interface: 'wl_subcompositor',                           version:  1, name:  5
interface: 'wl_data_device_manager',                     version:  3, name:  6
interface: 'zxdg_output_manager_v1',                     version:  3, name:  7
interface: 'zwlr_gamma_control_manager_v1',              version:  1, name:  8
interface: 'zwlr_screencopy_manager_v1',                 version:  3, name:  9
interface: 'org_kde_kwin_server_decoration_manager',     version:  1, name: 10
interface: 'zxdg_decoration_manager_v1',                 version:  1, name: 11
interface: 'zwlr_data_control_manager_v1',               version:  2, name: 12
interface: 'gtk_primary_selection_device_manager',       version:  1, name: 13
interface: 'zwp_primary_selection_device_manager_v1',    version:  1, name: 14
interface: 'wl_seat',                                    version:  7, name: 15
interface: 'xdg_wm_base',                                version:  2, name: 16
interface: 'zwlr_layer_shell_v1',                        version:  2, name: 17
interface: 'wl_output',                                  version:  3, name: 18

fwsmit commented 3 years ago

I didn't know that weston-info was deprecated, I never read the first few lines of output. Arch doesn't even have it in the main repos yet.

Running the dunst command at least offered the information what output is used. Looking good so far. The following line not so much. Dunno what is at fault.

Good to see that wayland is detected correctly at least. Does dunst also crash when not using -verbosity info?

The idle protocol is called 'org_kde_kwin_idle', so hikari doesn't support it yet. This should be handled gracefully, however.

Narrat commented 3 years ago

Propably only a matter of time. I pushed at least the respective PKGBUILDs for wayland-utils to the aurweb.

Does dunst also crash when not using -verbosity info?

Yes, dunst also crashes in this case. So propably unrelated?

The idle protocol is called 'org_kde_kwin_idle', so hikari doesn't support it yet. This should be handled gracefully, however.

Time will tell if it is handled gracefully ;) But so far so good (Casually "using" dunst like before)

fwsmit commented 3 years ago

If it crashes, how are you using it then?

Narrat commented 3 years ago

I would guess D-Bus interface(?) is working correctly? Creating notifications via notify-send works fine. But it should be something I could bisect. I tried regular dunst 1.5.0 and invoking dunst works fine. Installing the wayland-2 based git build and the dunst command segfaults as before.

Narrat commented 3 years ago

Hrm.. Dunno what went wrong. My assumption is, that it is somehow related to the dunst-git PKGBUILD or magic. First build breaks reliable, but a newly created package (with modified PKGBUILD) and local builds work fine. So the segfault can be disregarded. Something on my end that went wrong.

fwsmit commented 3 years ago

That's weird. Did you change the PKGBUILD to point it to the right branch as well? The master branch is the same as the dunst master. Could you run pacman -Qi dunst-git to check if you are using right version? I've recently added some more things, so could you update to the latest version? And to be sure you are not running an older version of dunst accidentally, I would recommend to remove dunst 1.5.0. It can indeed be started automatically via D-Bus.

All features should be present in the latest commit, so it's a matter of improving the stability now. If you run into any issues, please let me know and send output of dunst -verbosity debug. Thanks for helping.

Narrat commented 3 years ago

That's weird. Did you change the PKGBUILD to point it to the right branch as well? The master branch is the same as the dunst master.

Of course. Else it wouldn't have been possible to get the output regarding the actively used wayland output. I additionally synchronized for the next build (which was then working) the PKGBUILD with the one from community. The -git is in this regard a little bit out of date (but not outrightly broken).

Could you run pacman -Qi dunst-git to check if you are using right version? I've recently added some more things, so could you update to the latest version? And to be sure you are not running an older version of dunst accidentally, I would recommend to remove dunst 1.5.0. It can indeed be started automatically via D-Bus.

Did make sure that there weren't conflicting dunst versions running. But who knows, maybe I forgot it once. At least stable vs dev build isn't a problem, as the -git package rightly conflicts the repo package. So all the time only one dunst binary available (systemwide). Currently running a build based on commit 639447e (dunst-git 1.5.0.r46.g639447e-1). Next time it will updated to a build based on 8299f86

All features should be present in the latest commit, so it's a matter of improving the stability now. If you run into any issues, please let me know and send output of dunst -verbosity debug. Thanks for helping.

Will do :) And thanks for your work in adding this feature :)

tsipinakis commented 3 years ago

781 is now marked for review (which I'll do shortly). Since I'm not a wayland user myself I'd appreciate it if anyone that's interested in this switches to using that branch locally to test and point out any existing issues.

Narrat commented 3 years ago

And another curious case :D With a build based on 7c2f56f dismissing a notification window via mouseclick just causes said window to flicker. Starting dunst with -verbosity debug and dismissing works fine.

fwsmit commented 3 years ago

Thanks for reporting. There is a known bug in the current wayland build that looks as you describe (it's also on the current master btw). That is only when using X11 output, however (at least on xwayland it's broken, I'm not sure about X11). Tsipankis has already made a fix for it, but he didn't yet push it to master. Are you using the X11, xwayland or wayland output? Also, the verbosity should have no effect on the drawing, so that's weird.

dunst-project / dunst

Wayland support, e.g. for sway wm #264

781 is now marked for review (which I'll do shortly). Since I'm not a wayland user myself I'd appreciate it if anyone that's interested in this switches to using that branch locally to test and point out any existing issues.