01:03outfoxxed[m]: is there a single compositor that supports xdg_positioner::set_reactive
03:36vyivel: outfoxxed[m]: mutter
03:36vyivel: ...i think
03:37outfoxxed[m]: any others that will run without having to install gnome?
03:37outfoxxed[m]: mutter didn't seem to work when I tried
03:37outfoxxed[m]: wanted a dbus service
08:46wlb: weston/main: Derek Foreman * rdp: Align nsc_compose_message content https://gitlab.freedesktop.org/wayland/weston/commit/302a1b143fbc libweston/backend-rdp/rdp.c
08:46wlb: weston Merge request !1573 merged \o/ (rdp: Align nsc_compose_message content https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1573)
08:53wlb: weston Merge request !1579 merged \o/ (C++ header file build fixes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1579)
08:53wlb: weston/main: Ray Smith * helpers: don't override C++11's built-in static_assert https://gitlab.freedesktop.org/wayland/weston/commit/7b1520c4d922 shared/helpers.h
08:53wlb: weston/main: Ray Smith * backend-drm: rename "virtual" to work with C++ compilers https://gitlab.freedesktop.org/wayland/weston/commit/ee5b6bcc302f libweston/backend-drm/ drm-internal.h drm-virtual.c drm.c kms.c modes.c state-propose.c
08:57jadahl: outfoxxed[m]: weston has reposition support too
08:58jadahl: outfoxxed[m]: if you're just going to test reposition support, you can run mutter --nested without anything special e.g. logind dbus service
08:58wlb: weston/main: Loïc Molinari * rdp: Fix invalid free and memory leak on error https://gitlab.freedesktop.org/wayland/weston/commit/db66a64aabdb libweston/backend-rdp/rdp.c
08:58wlb: weston Merge request !1578 merged \o/ (rdp: Fix invalid free and memory leak on error https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1578)
09:02outfoxxed[m]: mutter seems to work, weston not at all
09:02outfoxxed[m]: what should the behavior of popups of popups be when positioned with regards to flip?
09:03outfoxxed[m]: should the whole popup tree flip to the opposite direction or just the popup that hit an edge
09:04wlb: weston Issue #928 closed \o/ (Broken wireframes when flushing SHM damages https://gitlab.freedesktop.org/wayland/weston/-/issues/928)
09:04wlb: weston/main: Loïc Molinari * gl-renderer: Prepare for reset to default pixel storage states https://gitlab.freedesktop.org/wayland/weston/commit/4fab505b9646 libweston/renderer-gl/gl-renderer.c
09:04wlb: weston/main: Loïc Molinari * gl-renderer: Assume default GL_PACK_REVERSE_ROW_ORDER_ANGLE state https://gitlab.freedesktop.org/wayland/weston/commit/1a0e450da540 libweston/renderer-gl/gl-renderer.c
09:04wlb: weston/main: Loïc Molinari * gl-renderer: Assume default GL_PACK_ALIGNMENT state https://gitlab.freedesktop.org/wayland/weston/commit/84d83f5bf8c2 libweston/renderer-gl/gl-renderer.c
09:04wlb: weston/main: Loïc Molinari * gl-renderer: Assume default GL_UNPACK_* states https://gitlab.freedesktop.org/wayland/weston/commit/95c3f9687016 libweston/renderer-gl/ gl-renderer.c gl-shader-config-color-transformation.c
09:04wlb: weston Merge request !1580 merged \o/ (Assume default GL pixel store states https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1580)
09:05outfoxxed[m]: it seems like flipping every child would work better for context menus and such but no compositor seems to do that
09:07outfoxxed[m]: since theres not a way for a popup to tell if its been flipped how are nested context menus supposed to reverse direction?
09:09kennylevinsen: The constraints are applied to the specific popup, they do not propagate to parents
09:10outfoxxed[m]: is there supposed to be a way to reverse trees of children?
09:10kennylevinsen: What would the use-case be? Having the whole tree move when a child is opened does not sound like a good idea...?
09:11outfoxxed[m]: ah wait nevermind, was thinking popups on other platforms did something they don't
09:12outfoxxed[m]: thought the direction of the popup tree would reverse when it hit the screen edge instead of just overlapping again
09:12outfoxxed[m]:uploaded an image: (104KiB) < https://matrix.org/_matrix/media/v3/download/outfoxxed.me/boQNLTRZluvyNxmvryDkhhlP/image.png >
09:14kennylevinsen: ah I get what you mean now, but definitely not
09:17outfoxxed[m]: seems odd that they just pile up in a corner
09:17outfoxxed[m]: granted bouncing all around the screen isn't amazing either but its better than that
09:20kennylevinsen: I disagree - if they changed their growing direction each time they hit a screen edge, the end-user would have a harder time assuming where a next popup would appear
09:21outfoxxed[m]: but is that worse than having a bunch of them stacked on top of eachother in a corner
09:21outfoxxed[m]: though hopefully nobody has enough nested menus for this to actually be a problem
09:23kennylevinsen: You would also stack on top if you had a nested setup that zig-zagged across the entire screen
09:23outfoxxed[m]: you'd have to go all the way around the screen before that happens though
09:24kennylevinsen: And I think it's easier for users to reason about "Grows to the right like always unless there's no room" is easier than "grows to the right unless an odd number of ancestors hit constraints"/"unless the last ancestor that hit a screen edge hit the right one"
09:25kennylevinsen: You don't have to go all the way around - have the first constraint be on the third popup level and you're overlapping with the first popup
09:25kennylevinsen: *first hit constraint
09:26outfoxxed[m]: yeah I guess its just preference
09:27kennylevinsen: deep nested popups flipping around is going to be bad UX anyway, so I prefer at least keeping it simple :)
09:38jadahl: iirc gtk will flip the direction of the constraints rule when the direction change
09:38jadahl: so it'll bump between the screen edges
09:40jadahl: or maybe not, or maybe that was gtk3
09:50jadahl: seeems to be only gtk3 menus that switch direction at the screen edges
12:33wlb: weston Merge request !1584 opened by Michael Tretter (m.tretter) backend-pipewire: add fence to synchronize on finish of render https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1584
15:48JoshuaAshton: swick[m]: Did you have any opinion on my MR to add scRGB support? We'd need this to support Proton/Wine apps without set_luminances https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/78
15:51JoshuaAshton: It's worth noting that this is also a VkColorSpace and gl_colorspace that is very commonly used, and developers will expect it to exist.
16:09Company: JoshuaAshton: btw, do you know what format/colorspace macOS composites in?
16:09Company: I tried figuring that out after I learned that Windows uses scrgb after reading about in your MR
16:10Company: but couldn't find any info about it
16:16JoshuaAshton: I have no idea, I imagine it's just some FP16 format. What the primaries are and values represent in terms of luminance are in that format doesn't really matter as it's just an implementation detail. It all ends up as HDR10 anyway =P
16:17JoshuaAshton: In terms of applications, for UI stuff, it's their own EDR format, where 1.0 = max sdr brightness and above that is the hdr headroom
16:34Company: it was mostly about what colorspace I want to make GTK composite so that the mac compositor doesn't have to transform it again
16:35Company: and Apple was big on dci-p3 in the past, but I do not know if they built hardware explicitly targeting it
16:35Company: and all the hardware I own wants BT2020
16:36Company: (or srgb of course)
16:37JoshuaAshton: it's always going to need some transformation, you're talking about potentially saving two fmas and a dot product at the composition time, that probably won't be saved anyway cause the compositor is just going to pass some matrix in =)
16:38JoshuaAshton: or potentially not even that if it uses a LUT
16:38JoshuaAshton: we use a 3D LUT for all our color xforms on Deck, so everything is the same cost regardless of what you do
16:39Company: you're thinking full-screen or compositor, I'm thinking application
16:39Company: that wants to make life as easy as possible for the compositor
16:40Company: so that it can ideally glBlitFramebuffer() from my buffer to the target
16:42JoshuaAshton: There is like no case where you can do that with actual color management going on
16:42JoshuaAshton: and definitely no case where it is consistent across different displays/output modes/etc
16:45Company: yeah, but I can change what my app does on different displays/outputs modes
16:45zamundaaa[m]: Company: does the MacOS API not have something similar to the Wayland preferred image description?
16:45Company: I'm just trying to make the compositor happy, because happy compositors like my apps
16:46Company: zamundaaa[m]: I don't know enough about macOS to know where to even look for it - and the people I asked didn't know
16:47Company: the windows people I know found the one paragraph on MSDN where it's explained - I wouldn't have found that one either
16:48Company: windows uses fp16 scrgb-linear, which makes a lot of sense
16:48Company: because for backwards compat, you can treat srgb apps with GL_SRGB
16:49Company: without any extra work to do in shaders while compositing
16:49zamundaaa[m]: It doesn't really make any difference
16:50Company: depends on what you run it on I suppose
16:51zamundaaa[m]: No, the fp16 framebuffer is the performance bottleneck, a single matrix multiplication doesn't hurt when you need to apply an EOTF in a shader anyways
16:58Company: do you need to though?
16:59Company: with GL_SRGB you don't have an eotf
16:59Company: that only works for opaque content, but most of the content of an app is opaque
17:01Company: or do you mean on the other end, when going from compositing to kms?
17:01Company:always confuses eotf and oetf and eotf^-1 and ootf and I've even seen eetf mentioned
17:13zamundaaa[m]: Company: you do have an eotf with GL_SRGB, it's just applied in hardware. IIRC on older hw it's limited to 8 bits per color, and that's where running a shader matters
17:16wlb: weston Issue #785 closed \o/ (Send wl_surface::enter right after xdg_surface creation https://gitlab.freedesktop.org/wayland/weston/-/issues/785)
17:18Company: zamundaaa[m]: yeah, but 8bits per color is exactly what you are gonna get with backwards compat code
17:18Company: and afaik it's implemented as a table lookup, a float[256] - one for linear, one for srgb
17:19Company: and I've tested it with linear compositing in GTK, and it's almost zero performance difference if I read/write via GL_SRGB or not
17:20zamundaaa[m]: Right, I read that outside of exclusive fullscreen, win32 was also limited to 8 bits per channel for the longest time. So that does make some amount of sense
17:20Company: I might remember it somewhat wrong, it might have been measurable, but I decided it's fast enough to allow switching to linear compositing
17:21Company: my low end target is rpi4 hardware
17:23Company: my goal of how things are going to work is that we switch to linear compositing in GTK, and depending on the compositor, we either hand it GL_SRGB U8 buffers for backwards compatibility, so they see the same they see before
17:24Company: or we render to FP16 linear scrgb
17:24coucouf1: Dear waylanders, we have freezes with wayland 1.23 + Plasma 5 in Debian
17:24Company: and then the compositor gets to do its own linear stuff on top of it
17:24coucouf1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076729
17:24coucouf1: is it something you’ve heard of already ?
17:25Company: both of those methods have very low performance impact in the general case
17:25coucouf1: triggered in the Plasma 5 wayland session when starting Xwayland according to the stack traces
17:25Company: my intel laptop is memory bound in the right benchmarks so I can make it drop to half the performance by switching from u8 to fp16
17:26Company: but I need to do fullscreen 4k on it to see the effects
17:26Company: my Radeon doesn't much care about me using u8 vs fp16
17:27Company: though they also don't care much about me doing eotfs/oetfs
17:28Company: the one thing they care about is shadow buffers, and are very clear I should avoid them like the plague
17:28dottedmag: coucouf1: the original signal was lost when Xwayland caught it, so Xwayland log is also needed to understand what went wrong
17:29Company: so my goal is to make compositors take the data I produce in a way that doesn't need conversion via shadow buffer
17:30coucouf1: ok, it breaks the VM where I tested badly enough that I cannot VT switch after that
17:31coucouf1: will get that and add it to the bug report
17:53wlb: weston Merge request !1585 opened by Marius Vlad (mvlad) gitlab-ci: Use virtme-ng for running our tests https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1585 [CI]
19:08kchibisov: Can a string on the wire has multiple NUL bytes in it including the terminating one? Just reading wire spec it seems like it can.
21:42wlb: weston Merge request !1586 opened by Leo Li (leoli) backend-drm: Use plane's zpos_min to check for underlay ability https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1586
22:29coucouf1: dottedmag: here’s a diff of logs for ok (wayland libs 1.22) vs crash (1.23)
22:29coucouf1: https://paste.debian.net/1324284/
22:29coucouf1: the crashing run says:
22:29coucouf1: wl_global_create: implemented version for 'wl_shm' higher than interface version (2 > 1)