00:24 i509vcb: What is the intended use for a xdg-toplevel resize edge of none?
08:23 vova: Hi
08:23 vova: Do you think it's possible to do screensharing in wayland without using pipewire ?
08:24 soreau: yes
08:24 soreau: of course it might depend on what compositor you're using
08:25 vova: Currently I'm using river
08:25 soreau: then you can use wf-recorder, I believe
08:26 vova: https://gist.github.com/telamon/23e5362757339bc8f22e9d40f9f1bd8e seems to do that
08:27 vova: Yeah it seems to works fine
08:27 vova: Thanks !
08:28 soreau: np
08:29 vova: Except for screensharing (via xdg-desktop-portal ?), pipewire is required for what else on wayland ?
08:31 YaLTeR[m]: depending on your definition of wayland, from "nothing" to "remote desktop, cameras, audio playback and recording, ..."
08:31 soreau: pipewire isn't required for anything afaik, but it can handle audio (like pulseaudio)
08:32 soreau: so in practice, if you remove it, you might need to install pulseaudio to have apps that use pulseaudio to output sound
08:33 vova: I always thought that pipewire was required for screensharing/webcam access/etc. I asked that question because tbh just alsa is enough for my use case, so having to install pipewire+wireplumber just to do screensharing seemed a little bit too much. But screensharing with wf-recorder seems to work just fine !
11:38 Max1: Is it a known issue that Weston doesn't reposition popups correctly? e.g. if you maximize Chromium in Weston, the submenus of the three dot menu are positioned outside of the screen
12:09 dottedmag: Max1: sounds like a Weston bug?
12:25 pq: Max1, if you make sure there is an issue filed, then it would be known. Mention whether Chromium runs through Xwayland or as Wayland native, and what the steps to reproduce that are, please.
12:45 wlb: weston Issue #816 opened by Max Ihlenfeldt (mihlenfeldt) xdg_popup can be positioned offscreen https://gitlab.freedesktop.org/wayland/weston/-/issues/816
12:45 Max1: pq Let me know if there's any additional info that would be helpful
12:53 pq: Max1, that's a good report, thanks!
14:10 wlb: weston/main: Marius Vlad * backend-wayland: Don't signal out resize events for activation https://gitlab.freedesktop.org/wayland/weston/commit/b51462d001df libweston/backend-wayland/wayland.c
14:10 wlb: weston Merge request !1349 merged \o/ (backend-wayland: Don't signal out resize events for xdg-shell activation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1349)
15:48 wlb: wayland Issue #407 opened by Jonathan Leivent (jonleivent) CI/CD privileges for wayland-idfix fork https://gitlab.freedesktop.org/wayland/wayland/-/issues/407
19:32 bunni: using the desktop shell in weston, is there any concept of a desktop icon, or, a way to increase the launcher bar size to make the icons a bit more obvious and easier to click on a touchscreen?
19:32 bunni: or are there any other alternatives to get similar functionality of large-ish icons that can be pressed
19:51 aleasto: why does mutter send the preferred_fractional_scale only after a buffer is attached and the surface state commited? i create a surface with xdg_toplevel role, maximized, and i know mutter knows which output to put the surface on because it sends a configure with the correct maximized size, so surely it knows the preferred scale too at this point
19:51 aleasto: i don't understand why i should commit a buffer with the wrong scale before mutter can tell me the right scale
19:51 kchibisov: aleasto: it all depends on the role of the surface.
19:52 aleasto: eh i wrote a lot of text but it's in there :D
19:52 aleasto: it's an xdg_toplevel
19:52 aleasto: maximized
19:52 kchibisov: I understand.
19:52 kchibisov: I'm answering the "why" part.
19:52 kchibisov: So the logic mutter has might be not tuned for surface roles.
19:53 kchibisov: xdg_shell(protocol) suggests that you should send state(including scaling) the way you expect.
19:54 kchibisov: but mutter does nothing wrong from the correctness pov, it just isn't optimal for clients.
19:54 aleasto: yea...
19:55 aleasto: i have not checked whether the same behaviour happens for the wl_surface preferred_buffer_scale (integer)
19:55 kchibisov: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/213/diffs
19:56 kchibisov: I had similar issue, but because 'order' is not defined or suggested.
19:57 kchibisov: Which is true, because you can't define order.
19:57 kchibisov: unless you know the exact role of the object.
19:57 kchibisov: So if you take arbitrary wl_surface you can't send scaling early on.
19:58 aleasto: i see your change is merged. so compositors should comply and send it immediatly?
19:58 kchibisov: It just says that it will.
19:59 kchibisov: So sort of, but compositors can violate.
19:59 kchibisov: Though, I don't see a reason to violate that.
19:59 aleasto: fwiw i know kwin does what i expect
20:00 kchibisov: I mean, bug mutter.
20:01 kchibisov: The reason the change you're seing is merged and was submitted, because we have a "every frame is perfect", yet until you follow what I wrote in MR you can't do that.
20:02 aleasto: yea i'll open a ticket against mutter. thanks!
20:02 aleasto: i feel lucky i caught you reading
20:03 kchibisov: You can get lucky by searching the bug tracker.
20:03 kchibisov: There's an issue about this first frame not being perfect on HiDPI.
20:04 kchibisov: it's still open, because we have cursors.
20:05 aleasto: mmmh got a link?
20:07 kchibisov: https://gitlab.freedesktop.org/wayland/wayland/-/issues/133
20:08 kchibisov: I think the only part which is left is a cursor.