04:32 JoshuaAshton: Has anyone seen the page flip event be sent before the commit has been completed? I am currently seeing it in AMDGPU (https://gitlab.freedesktop.org/drm/amd/-/issues/3441#note_2511296) and curious if others have seen similar behaviour in certain plane transitions that end up taking a long time
07:02 wlb: weston Merge request !1589 opened by Benjamin Herrenschmidt (benh) Draft: [RFC] Tentative port to FreeRDP 3.x https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1589
08:09 MrCooper: JoshuaAshton: sounds like clearly an amdgpu DC bug
08:15 benh: MrCooper: here ? :-)
08:16 MrCooper: yep, welcome
08:20 benh: Ok so I added a comment about the freerdp 2 vs 3 support and whether to make it built with both ... I'll leave it at that for tonight and will play more this weekend
08:27 benh: CI is dying now because of fatal: unable to access 'https://git.sr.ht/~kennylevinsen/seatd/': The requested URL returned error: 500
08:27 benh: 20876
08:27 benh: :-)
08:29 MrCooper: kennylevinsen: ^ did that move somewhere else?
08:29 kennylevinsen: Nope
08:30 kennylevinsen: Sourcehut outage?
08:31 kennylevinsen: Yeah they’re getting hammered and decided to take a maint window during
08:32 kennylevinsen: Seems back
08:33 kennylevinsen: Ahh no they didn’t do a maint window, it was just DDoS.
08:44 kennylevinsen: benh: did you try rebuilding?
09:06 JoshuaAshton: MrCooper: Yeah, and the page flips that are happening in the transition are taking 33ms+ which is :S
09:07 JoshuaAshton: And here I was thinking the 11ms for re-uploading all LUTs when planes changed was bad...
09:07 MrCooper: yeah that's also bad, not necessarily a bug though
09:22 King_DuckZ: hello, in weston, in gl-renderer.c repaint_views() calls glBlend(GL_ONE, blah), does anyone around here know why GL_ONE and not GL_SOURCE_ALPHA?
09:27 King_DuckZ: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/renderer-gl/gl-renderer.c?ref_type=heads#L1704
09:28 soreau: that's really a generic GL API question
10:00 King_DuckZ: soreau: why generic? is my question too vague?
10:01 soreau: the answer is: because that is what the programmer wrote because that's how they wanted it to work :P
10:03 soreau: conversely, I wonder what makes you think that source alpha would yield the desired outcome in every case
10:03 soreau: but idly, and it's a rhetorical question
10:33 King_DuckZ: it's not a retorical question, it's precisely what I'm trying to find out :)
10:45 kennylevinsen: King_DuckZ: https://gitlab.freedesktop.org/wayland/weston/-/commit/3f59e82c20e2bcbf663701fb1abfb6132e6d04ea
10:45 kennylevinsen: (GL_ONE, GL_ONE_MINUS_SRC_ALPHA) is the blending formula for pre-multiplied alpha
10:46 King_DuckZ: looks like it's been through a lot, that line... someone tried to change it in 2018 1db0e74715a37e7a26e0b801cb0df691bdff8434
10:47 kennylevinsen: fatal: bad object 1db0e74715a37e7a26e0b801cb0df691bdff8435
10:47 wlb: wayland-protocols Issue #91 closed \o/ (linux-dmabuf-next: don't require a main device to be present https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/91)
12:16 King_DuckZ: well that's embarrassing, git must have pulled a prank on me, let me check wth I copy-pasted...
12:20 King_DuckZ: kennylevinsen: I think they like to amend all commits for reasons I'm afraid to dig into, so hashes between my local repo and upstream won't match, sorry about that!
12:21 kennylevinsen: The main branch cannot be amended, that would break all existing clones
12:21 kennylevinsen: (history rewrite would make pulls fail)
12:21 kennylevinsen: open merge requests can of course be arbitrarily amended and rewritten before merge
12:29 King_DuckZ: well either they amended it or it's a commit that is not upstream. it doesn't matter, I think the one you found is way more interesting
12:31 King_DuckZ: the one I wanted to show you replaced the glBlendFunc(GL_ONE) with an if (something) glBlendFunc(foo) else if (something else glBlendFunc(bar) etc, it got reverted later but do you think that would be the right approach?
12:32 King_DuckZ: because right now I just replaced GL_ONE with GL_SRC_ALPHA, everything seems to work but I'm afraid I don't understand all the implications
12:50 kennylevinsen: King_DuckZ: wayland surface use premultiplied alpha, requiring the current formula. The conditional was to support *other* content that wasn't using pre-multiplied alpha.
12:50 kennylevinsen: blending will not work as expected if you use the wrong formula
12:52 kennylevinsen: https://microsoft.github.io/Win2D/WinUI3/html/PremultipliedAlpha.htm
12:54 kennylevinsen: https://www.youtube.com/watch?v=XobSAXZaKJ8
12:54 kennylevinsen: that also gives some examples of what happens when done wrong
12:55 King_DuckZ: I'm reading, that's super useful, thank you!
12:55 King_DuckZ: so hmmm instead of mucking around with GL_ONE I should make sure output of my shader is premultiplied alpha, yes?
12:56 kennylevinsen: are you writing a compositor or a client?
12:56 kennylevinsen: if compositor, yeah you should treat the input as pre-multiplied alpha
13:03 King_DuckZ: green screen removal in weston shader, so I think my RGBs are all wrong, I need to output vec4(rgb * a, a) if I understand correctly, and restore GL_ONE
13:05 Ermine: wayland-client.h says that its usage is discouraged. Should I include wayland-client-core.h and -protocol.h by hand?
13:06 vyivel: yes
13:13 Ermine: okay, thank you
13:26 King_DuckZ: kennylevinsen: haha that's exactly the video I was thinking to go back to and watch, but I thought "let's watch the link first" :D great choice!
14:35 swick[m]: kennylevinsen: I would always say electrically premultiplied alpha
14:36 swick[m]: which is a horrible thing
14:36 kennylevinsen: I personally prefer hydraulically premultiplied alpha
14:38 swick[m]: well, the point is that premultiplication on an encoding is kind of stupid
14:38 swick[m]: it really needs to be on tristimulus values
14:40 kennylevinsen: I never fully understood why one wanted to do premultiplied alpha in the first place, if it's no less difficult for the compositor to blend straight alpha...
14:41 swick[m]: if you want to show something with alpha on the screen, if it is correctly premultiplied you don't need to do anything
14:41 swick[m]: but that's not really what we do nowadays
14:42 kennylevinsen: I suppose it enables you to just ignore the alpha channel when doing direct scanout of an ARGB buffer that you want blended to black...
14:42 swick[m]: except for direct scanout and there it matters
14:42 swick[m]: yes
14:43 kennylevinsen: with the cost being loss of dynamic range on the color channels whenever the alpha channel isn't 1
14:44 swick[m]: it's a trade-off. same with linear vs encoded (gamma). if the compositor actually has to composit, linear is the ideal form, but then you can't do direct scanout, or at least need the scanout hardware to be able to encode it
14:45 swick[m]: also scaling etc should be done in optical premult to be "correct"
14:46 swick[m]: so all in all, you basically always want optical premult, sometimes encoded, sometimes linear
14:46 emersion: the reason for premult alpha is to be able to just use a simple OpenGL shader, instead of a two-pass thing
14:48 emersion: (or a very simple/fast pixman op)
14:48 kennylevinsen: I wonder where the whole linear blending thing will land in the end given clients getting surprised by it
14:48 kennylevinsen: didn't kwin end up reverting linear blending?
14:50 swick[m]: if you do linear blending with PQ everything looks like dogshit
14:50 swick[m]: so you have to option of sometimes blending in linear and sometimes in sRGB
14:50 swick[m]: which is horrible because now if a client switches from sRGB to PQ suddenly alpha looks wrong
14:50 kennylevinsen: as I always say, colors were a mistake :(
14:50 swick[m]: or live with dogshit blending everywhere
14:51 swick[m]: or just break stuff once now and do linear blending even if there are minor problems
14:51 swick[m]: kwin did the sRGB and PQ do different blending and I don't agree with that
14:51 swick[m]: GTK also switched to linear blending and will break everything once
14:54 King_DuckZ: just learning but what I'd do is linear non-premult everywhere, do it as late as possible
14:56 King_DuckZ: I don't even know how it all works, like if I'm connected to a projector, I believe lut should be completely different than that of an oled or an hdr screen, but if you're doing sRGB you're kinda stuck... I know most sources like videos and jpegs will be sRGB already but that doesn't mean everything else has to
15:01 kennylevinsen: you can use wider color spaces, but if the display is operating in e.g. DCI-P3 or Rec2020, the compositor needs to map sRGB content to the appropriate subset of the target color space to not massively oversaturate things
15:01 kennylevinsen: not to mention luminance in case of HDR
15:02 kennylevinsen: and now you're entering the fun world of color management
15:02 kennylevinsen: which I am entirely the wrong guy to explain
15:02 kennylevinsen:points at swick[m]
15:05 swick[m]: projectors, oleds, hdr displays, ... they all basically behave the same in their default mode regarding non-linearity because they all expect input that's sRGB-ish
15:06 swick[m]: the EDID technically tells you the gamma of the display in default mode
15:07 swick[m]: with wayland we're moving towards compositors which handle that mismatch, so if a display doesn't do sRGB non-linearity, it will convert it
15:08 zamundaaa[m]: kennylevinsen: yes, KWin git master blends in a gamma 2.2 space
15:09 King_DuckZ: I remember a few things from my old job, colour scientist sat right next to me, I just wish I paid more attention when he explained stuff xD
15:10 zamundaaa[m]: swick: the different blending wasn't sRGB vs. PQ, it was linear for when some color management features (ICC profile or HDR) were enabled vs. sRGB for when none were enabled
15:11 swick[m]: end result is still the same: different blending in some situations and I think that's not good
15:11 zamundaaa[m]: The latter was just a consequence of KWin having to scale down all the way to things like the Pinephone or old Intel iGPUs, where a shadow buffer isn't an option
15:11 zamundaaa[m]: Yes, that was a bad situation, which is why we now always blend in some gamma 2.2 space
15:11 swick[m]: we're still doing the same in mutter
15:12 King_DuckZ: swick[m]: I suppose you still have to assume sRGB on your end tho, but if say mpv is playing something linear or with rec709 baked in it will all look funny, isn't it?
15:12 swick[m]: it doesn't look completely right, no
15:12 swick[m]: to some degree some players convert things
15:13 swick[m]: but because they don't really know the display capabilities even that isn't that useful
15:13 King_DuckZ: complaint I heard most often from colour scientist is that gimp, krita etc are all broken because they assume sRGB, as opposed to nuke which is proprietary (and very poorly written, having seen the code myself)
15:13 swick[m]: at least if they convert to sRGB and we assume it's sRGB in the compositor, things don't look wrong, just probably worse than they could
15:14 King_DuckZ: not something I need right now, but I think it's important to provide a "don't mess around with my colours" switch somewhere, for pro users
15:14 swick[m]: well, you can configure gimp, krita etc to do the right thing via ICC profiles, just like you can configure nuke to do the right thing via OpenColorIO
15:15 King_DuckZ: just output linear or whatever you get in, for specialised hardware
15:15 King_DuckZ: swick[m]: can you? iirc last time I tried even resizing was wrong in gimp
15:16 King_DuckZ: to my great disappointment
15:16 swick[m]: ah, working color space
15:16 swick[m]: yeah, that might still not work correctly in gimp. dunno.
15:18 swick[m]: instead of a "don't touch my pixels" mode we don't mess up your colors (beyond quantization errors) when you match the display capabilities/properties
15:18 swick[m]: if you need an actual "put this value on the screen" then there are specialized pci cards which generate the signal for you without anything in between
15:19 swick[m]: e.g. that stuff: https://www.blackmagicdesign.com/de/products/decklink
15:23 Ermine: Are there per-interface change logs available? E.g. I want to know what changed in wl_compositor since version 4
15:32 King_DuckZ: oh yeah found it http://www.ericbrasseur.org/gamma.html
15:35 King_DuckZ: swick[m]: we had a room like that, maybe we did have that hardware in there and I didn't know
15:36 King_DuckZ: still, always good to keep high end users in mind, it may be a niche user base but they bring reputation with them :)
15:39 swick[m]: yeah, for sure, but most artists working on 3d modeling, texturing, compositing etc use a normal desktop environment and you can only do so much there
15:40 swick[m]: at the end, color grading happens with those cards in tightly controlled viewing environments
15:41 swick[m]: btw, the video touches onto something about premultiplied images: they can store more information than un-premultiplied ones
15:42 King_DuckZ: yes true
15:42 swick[m]: e.g. if you render a flame in blender with a transparent background, the result is premultiplied with the color channel probably maxing out and the alpha channel being maybe 0.5 at some places. this can only be represented with straight alpha when you can go over the "maximum" i.e. with floats
15:42 King_DuckZ: trying to wrap my head around that but it did stand out to me whe he said that, makes sense to have just 1 32-bit value representing an invisible pixel
15:49 King_DuckZ: from my link: "[...] and they perceive the public software tools as toys" I can confirm that to be true
16:49 mclasen: swick[m]: we haven't switched yet
22:06 Ermine: zxdg_decoration_manager_manager_v1 obliges me to answer with ack_configure to zxdg_toplevel_decoration_v1::configure event. Do I understand correctly I need to send ack_configure for the respective toplevel? And which serial should I use then?
22:10 kennylevinsen: Ermine: it's the xdg_surface.configure that you xdg_surface.ack_configure with the serial from the former
22:11 kennylevinsen: xdg_surface.configure will follow the zxdg_toplevel_decoration_v1.configure, similar to how xdg_toplevel.configure works
22:12 Ermine: Ah, so zxdg_toplevel_decoration_v1.configure is to communicate to me what mode compositor wants
22:12 Ermine: Thank you!