wayland support?

[jokeyrhyme]

Howdie, thanks so much for sharing your work here, wired is working terrifically for me! <3

I thought I'd create a dedicated issue for this conversation ( although there are mentions #34 (comment) and #34 (comment) )

I've been using wired with both sway and river compositors (wayland) and I'd like to report that it's working very well

I do see fuzzy font issues when running it on a high-density display with scale=2.0 , which is typical when running an X11 application via xwayland within a wayland compositor

That said, for my use case, I read a notification quickly and then it goes away, I'm not reading this fuzzy text for very long so it doesn't seem super important to me

So, yeah, I thought maybe it would be good to track a decision/reports/progress on wayland, if only to address the fuzzy fonts at scale=2.0 (might become more of a problem as more distributions go wayland-by-default)

Thanks again!

Edit: adding this checklist (to help summarise items from comments)

minimum required to start without crashing and to display something

• need a wayland-friendly way of getting a cairo context/surface without using xlib (ignoring transparency to start with)
• need to use winit::event_loop::EventLoop::new() instead of winit::event_loop::EventLoop::new_x11()
• data for focus_follows: Mouse|Window should only be interrogated when layouts specify monitor: -1 (would help unblock some wayland use cases, and is a possible optimisation), see: fix: only get active monitor when necessary #89

feature parity for wayland

• focus_follows: Mouse functionality depends on get_active_monitor_mouse(), need to use equivalent Wayland protocols when necessary
• focus_follows: Window functionality depends on get_active_monitor_keyboard(), these need to use equivalent Wayland protocols when necessary
• transparency is achieved using cairo + xlib and needs a wayland alternative: https://github.com/Toqozz/wired-notify/blob/d8070a4c872b2c5e6d6a918e192d89a5f6585dc0/src/rendering/window.rs
• alternative implementation of idle monitoring via "unstable" org_kde_kwin_idle wayland protocol for KDE (and compatible with wlroots e.g. sway)
• alternative implementation of idle monitoring for GNOME (assuming someone prefers wired over GNOME's built-in notifications)

[jokeyrhyme]

I'm sure there's much more to it than this, but it looks like winit::event_loop::EventLoop::new() will automatically work for either wayland or X11 🤷

[Toqozz]

So glad to hear that Wired is working on Wayland! Thanks for the report.

I thought that notifications would need to be handled by the WM or something in Wayland, but this seems silly now thinking about how dbus works.

Indeed winit does support Wayland, but we're using a few X11 things to make stuff work properly, which we'd have to find equivalents for on Wayland.

The main ones I can think of are creating our cairo surface (I believe this was to support transparency):

wired-notify/src/rendering/window.rs

Lines 132 to 153 in 549e595

	let xlib_window = winit
	.xlib_window()
	.expect("Couldn't get xlib window, make sure you're running X11.");
	let surface = unsafe {
	/*
	let visual = x11::xlib::XDefaultVisual(
	xlib_display as _,
	0,
	);
	*/
	let sfc_raw = cairo_sys::cairo_xlib_surface_create(
	xlib_display as _,
	xlib_window,
	visual_info.visual,
	width as _,
	height as _,
	);
	Surface::from_raw_full(sfc_raw)
	}.expect("Failed to create cairo surface.");

And setting the X11 window types (there must be alternatives for these):

wired-notify/src/rendering/window.rs

Lines 113 to 116 in 549e595

	let winit = WindowBuilder::new()
	.with_inner_size(PhysicalSize { width, height })
	.with_x11_window_type(vec![XWindowType::Notification, XWindowType::Utility])
	.with_title("wired")

I'll get around to looking for how to get around those eventually.

[jokeyrhyme]

Ah, I hadn't even looked into transparency at all, but I assume others on wayland will probably want this :)

The other thing I can think of is the idle-behaviour, I'm not sure if this is already being done in a systemd/logind/dbus way or if that's being done in an X11/XSS-specific way? 🤷

[Toqozz]

Idle behavior is currently done using XSS, bah!

[LukasDoesDev]

Is there any way to have monitor following in Wayland?

[tdpeuter]

Please note that 'it works on Wayland' is probably only because Xwayland is also running. If you start Sway with xwayland disable configured, Wired does not work.

Transparency is trippy indeed, I suspect (based on what I've tried) that only either completely transparent or completely opaque is supported at the moment, using the Color(hex) or Color(rgba) format.

Also I notice that notifications that are configured to anchor anywhere other than top-left, are first displayed TL before being moved somewhere else (at least, that's my assumption, I can only report a flash of the notification at TL).

[Toqozz]

Yeah, XWayland is definitely doing some heavy lifting. I'm not quite in a position to properly support Wayland yet, as I think it would require a lot of research to get it there. I'm open to PRs getting us most of the way there or similar.

Regarding the top left thing, this should be fixed on master (see #71). I've been slow at getting releases out, apologies. I'll try to release one tonight.

[tdpeuter]

No problem at all!

I thought the 'top left thing' would also be caused by Wayland, didn't see that issue there, sorry for that.

[TornaxO7]

May I ask what the current state is?

[Toqozz]

No progress. I'm not really working on this anytime soon. I'm open to any pull requests in this area.

What are the actual issues at the moment? Monitor following doesn't work, and transparency?

[subterfugue]

Yes, and it looks like one of the actual issues is that it runs on XWayland instead of native Wayland, because of the 2 pieces of code you posted above I believe. You might need to replace them with an X/Wayland agnostic call, maybe by using winit.

[jokeyrhyme]

• I've looked into this a bit more, and I'm not sure how to get from a winit::window::Window to a cairo::Context, without making a cairo::Surface first, and the way we currently do this is with cairo_sys::cairo_xlib_surface_create()
• it does seem that Cairo can be used with OpenGL, which we'd need to work with wayland ( I think? see: https://unix.stackexchange.com/questions/511134/why-wayland-is-using-opengl-es-instead-of-opengl )
• but there's no such thing as a GL or EGL surface according to Cairo's documentation: https://cairographics.org/manual/
• I've looked at other Rust projects that are using cairo, and they either don't seem to support wayland (e.g. xaskpass), or they rely on the cairo::Context provided by GTK (e.g. gatti, eww, sherlog)

I think our options are:

• find a way to use cairo by itself for wayland (not sure how long this will take, looks like dunst uses cairo with wayland, although that is a C project)
• add GTK as a dependency to this project and use it to give wayland-ready cairo (seems like a big dependency that we otherwise wouldn't need)
• find an alternative to cairo that covers what we use cairo for and more easily supports wayland, maybe something here? https://www.areweguiyet.com/

[Toqozz]

Thanks for the research!

Option 1 is ideal, and I think it's doable.

It definitely should be possible to get a cairo context from a wayland window -- well, it is possible since dunst does it.

Cairo does seem to support EGL, I think it's just not documented well. I also can't find anything about it in the cairo_sys package though, so not sure here. But there should be a way forward -- we can make the bindings ourselves if we have to.

Assuming we can find a way to call cairo_gl_surface_create_for_egl, then we just needa figure out how to get the raw device stuff from rust, probably with the wayland_surface() and wayland_display() methods.

wayland_egl is probably a piece of the puzzle (https://docs.rs/wayland-egl/latest/wayland_egl/)

I'll update if I find anything more regarding cairo EGL.

[Toqozz]

It looks like we could maybe also just use a regular cairo image surface and upload it to the window somehow (https://www.cairographics.org/OpenGL/). But this sounds like much more hassle than just having an actual surface.

[jokeyrhyme]

This could be promising (however C, not Rust): https://cairo.cairographics.narkive.com/sz0ZifFB/to-wayland

[jirutka]

This project intrigued me, especially after seeing that it’s flexible enough to display this #63 (comment). Unfortunately, no native Wayland support is a deal breaker. :( This is not a criticism, I just wanted to let you know that this feature is really wanted.

[hnorkowski]

Any updates on this?

[jokeyrhyme]

I was hoping the new release of cairo would unblock us in an obvious way, but it doesn't look like it:

• https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1411180-cairo-1-18-released-first-stable-release-in-five-years
• https://docs.rs/cairo-sys-rs/0.18.2/cairo_sys/

That said, I'm not familiar enough with cairo to really know either way

It does look like GTK itself wants to stop using cairo, which rules out a previous idea I had about us adopting GTK here as a path to getting a wayland-compatible cairo setup: https://blog.gtk.org/2023/09/19/paths-in-gtk/

[TornaxO7]

hm.. would it be worth to maybe switch to another gui-framework like iced?

[Toqozz]

I think if we want to use wayland we should just bite the bullet and render to a surface in memory, then blit the result to whatever context wayland/x11 gives us. It's an extra copy, but it's probably worth it. I'm also unsure if transparency will work properly.

Worth mentioning that there may be a way to draw to the wayland context directly like how we do now with xlib, if we wrote some bindings or something, but I'm not familiar enough with how things plug together here to make it work (if it can).