14:08Net147: does weston always flip between two framebuffers or can I configure it to use only one?
14:13mort_: somehow, in Weston, Chromium is black when it's the focused app but renders fine when there are other apps in front...
14:19wlb: weston Issue #921 opened by Kimmo (kimmot) Screen blanking with "idle-time" does not work with "kiosk"-shell https://gitlab.freedesktop.org/wayland/weston/-/issues/921
14:20cmeissl[m]: <mort_> "somehow, in Weston, Chromium..." <- possible that it gets directly scanned out on an drm plane in the top case, but composited if something else overlaps on top
14:21mort_: cmeissl[m]: is it possible to disable direct scanout and always do compositing?
14:26cmeissl[m]: not that I am aware of, but its quite some time I looked at that part in weston
14:33mort_: I guess a horrible workaround could be to have an always-on-top window...
14:40cmeissl[m]: If you can recompile weston, there is certainly a way to disable plane assignments. I am just not aware of a way to disable it during runtime.
16:02daniels: Net147: it always flips
16:03FreeFull: When damaging a buffer, is it guaranteed that the compositor will only redraw that part? Or is it possible that it'll decide to do a larger area anyway?
16:03daniels: mort_: press Win + Shift + space together, then press v
16:03daniels: there’s an environment variable somewhere too
16:03daniels: FreeFull: the compositor can well decide to do a wider redraw, and the wl_buffer must always contain complete and up-to-date content
16:03FreeFull: Thanks
16:06daniels: np
16:22FreeFull: When drawing infrequently (Say, once every 5 seconds), should I even worry about requesting frame callbacks?
16:37FreeFull: Seems not caring about frame callbacks is ok in this case
16:38YaLTeR[m]: You can submit buffers at any time regardless of frame callbacks. But they are useful so that you can avoid doing anything when the surface is completely invisible
16:40mort_: daniels: hmm where is that documented? I can't see win + shift + space in key binding docs
16:41kennylevinsen: FreeFull: think of them as a way to throttle. You might draw on infrequent input that sometimes comes in bursts for example. But e.g. a clock updating every second has no need for it.
16:42FreeFull: In this case I'm working with wlr-layer-shell. The surface can still be invisible if a window is fullscreen though
16:42FreeFull: But yeah, just drawing some text infrequently will probably be ok
16:44YaLTeR[m]: many compositors will also send frame callbacks once a second unconditionally because of some funny clients
16:44YaLTeR[m]: so if you draw once a second anyway there isn't much point
16:46FreeFull: Hmm.. Maybe niri doesn't do that for layer-shell surfaces, though
16:47YaLTeR[m]: I don't remember but I think I intended to do it for everything at least
16:49FreeFull: Well, my client (using sctk) doesn't seem to be getting frame callbacks unless I request them
17:08YaLTeR[m]: Yeah, you need to request them. They are oneshot
17:43vyivel: aside from gtk4/adwaita-driven programs, are there any real-life clients that have reactive xdg_popups?