00:41kennylevinsen: i509vcb: the configure event specifies a specific size the compositor requests, while the configure_bounds event is a suggested upper bound (e.g., "you won't fit in the screen if you're larger than this")
00:43kennylevinsen: perfectly normal for it to be larger than (or equal to) the configured size
01:15i509vcb: kennylevinsen: yes, however there is nothing really preventing implementations from sending configure bounds larger than the configure
01:16i509vcb: I was wondering if this was a documentation oversight or not
01:51orowith2os[m]: i509vcb: there's probably a use case somewhere where the "maximum size" is smaller than the "suggested size"
01:51orowith2os[m]: not a very useful use case, but a use case nonetheless
01:52orowith2os[m]: scaling something something, maybe
03:01sjao2: I have an issue with attempting to offload rendering to my nvidia card with flatpaks, it just doesn't work and omits egl problems https://paste.debian.net/plain/1288798
03:01sjao2: I'm doing it according to this ask ubuntu answer https://askubuntu.com/questions/1316566/how-do-you-offload-a-flatpak-application-to-run-on-the-nvidia-graphics-card-when Do I need to set env vars on my main shell?
03:02orowith2os[m]: sjao2: run `flatpak update` and ensure the nvidia drivers are working inside of the Flatpak environment.
03:02sjao2: this works on X11
03:03sjao2: there seems to be a minor update for the 32 bit nvidia libraries for the 525 branch but nothing the blender would use
03:13sjao2: ok after unsetting __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json it starts and a process binds to the gpu but nothing appears and the process hangs https://paste.debian.net/plain/1288799
03:14sjao2: I had this set on the host to prevent applications binding to the nvidia card when I didn't want them to
08:49kennylevinsen: i509vcb: "there is nothing really preventing implementations from sending configure bounds larger than the configure" - why would there be? Bounds >= configure is the expected scenario. Did you perhaps mean the other way around?
09:26YaLTeR[m]: size more than bounds is also perfectly normal, you can resize windows larger than screen to cover two screens for example
09:50kennylevinsen: true, I was implying that it would be odd for a compositor to ask for a size bigger than it's bounds but I guess that's fine too
12:28wlb: weston Issue #800 opened by Marcel Partap (eMPee584) Factor out surface rotation into protocol? https://gitlab.freedesktop.org/wayland/weston/-/issues/800
13:15wlb: weston Merge request !1345 opened by Robert Mader (rmader) client/simple-dmabuf-v4l: Add fullscreen support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1345 [Clients]
15:55i509vcb: kennylevinsen: bounds > configure size was what I was asking about
15:56i509vcb: where you have a restricting state such as maximized set on the toplevel
15:57i509vcb: Is the case something like, 50% tiled to the right (so maximized with a 960x1080 size) and then the bounds are 1920x1080 for the entire screen?
15:59kennylevinsen: i509vcb: the expected use-case is something like the user resizing the window to 1920x1200, but the output is 3840x2160. The configure would then be 1920x1200, while bounds could be 3840x2160 (i.e., larger)
16:00kennylevinsen: For tiled, the bounds could be the size of the tile - bounds do not have a hard definition other than being "something the client should probably stay below"
16:00kennylevinsen: needed because the client is free to resize freely, including in most states ignoring configured sizes - but might still want to know how big is too big
16:02kennylevinsen: in states where configure dimensions are a hard demand, bounds become irrelevant - they're just an upper bound hint for when the client *is* in control
16:12i509vcb: ok so it's a hint for when the client is free to do what it wants
16:57wlb: wayland-protocols Issue #156 opened by Consus (heroin-moose) idle-inhibit: concerns about mandatory surface visibility https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/156
17:26sjao2: I figured it out, I have to revoke the wayland permission in flatpak to force it to use xwayland rather than wayland, and it turns out natively offloading was using xwayland aswell