ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
bjorkintosh has joined #wayland
lbia has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
CME_ has joined #wayland
CME has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
Company has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
Company has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
Company has quit [Remote host closed the connection]
Company has joined #wayland
glennk has joined #wayland
feaneron has joined #wayland
Company has quit [Remote host closed the connection]
Company has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
Brainium has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
mxz__ has joined #wayland
mxz___ has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz___ is now known as mxz
mxz_ has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
<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
mclasen has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
pominator1 has joined #wayland
pominator1 has left #wayland [#wayland]
kts has joined #wayland
bindu has quit [Remote host closed the connection]
abeltramo589523 has quit [Ping timeout: 480 seconds]
abeltramo589523 has joined #wayland
pominator1 has joined #wayland
<MrCooper>
JoshuaAshton: sounds like clearly an amdgpu DC bug
benh has joined #wayland
<benh>
MrCooper: here ? :-)
<MrCooper>
yep, welcome
<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
<MrCooper>
kennylevinsen: ^ did that move somewhere else?
<kennylevinsen>
Nope
<kennylevinsen>
Sourcehut outage?
<kennylevinsen>
Yeah they’re getting hammered and decided to take a maint window during
<kennylevinsen>
Seems back
<kennylevinsen>
Ahh no they didn’t do a maint window, it was just DDoS.
<kennylevinsen>
benh: did you try rebuilding?
Brainium has joined #wayland
mvlad has joined #wayland
garnacho has joined #wayland
<JoshuaAshton>
MrCooper: Yeah, and the page flips that are happening in the transition are taking 33ms+ which is :S
<JoshuaAshton>
And here I was thinking the 11ms for re-uploading all LUTs when planes changed was bad...
<MrCooper>
yeah that's also bad, not necessarily a bug though
Company has joined #wayland
<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?
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
dri-logger has quit [Remote host closed the connection]
dri-logger has joined #wayland
naemi4491 has quit []
naemi4491 has joined #wayland
psykose has quit [Remote host closed the connection]
Moprius has joined #wayland
kts has joined #wayland
psykose has joined #wayland
Calandracas_ has joined #wayland
Calandracas has quit [Ping timeout: 480 seconds]
Brainium has quit []
kts has quit [Quit: Konversation terminated!]
mclasen has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<King_DuckZ>
well that's embarrassing, git must have pulled a prank on me, let me check wth I copy-pasted...
fmuellner has joined #wayland
<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!
<kennylevinsen>
The main branch cannot be amended, that would break all existing clones
<kennylevinsen>
(history rewrite would make pulls fail)
<kennylevinsen>
open merge requests can of course be arbitrarily amended and rewritten before merge
<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
<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?
<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
nerdopolis has quit [Ping timeout: 480 seconds]
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
bjorkintosh has joined #wayland
Brainium has joined #wayland
<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.
<kennylevinsen>
blending will not work as expected if you use the wrong formula
<kennylevinsen>
that also gives some examples of what happens when done wrong
<King_DuckZ>
I'm reading, that's super useful, thank you!
nerdopolis has joined #wayland
<King_DuckZ>
so hmmm instead of mucking around with GL_ONE I should make sure output of my shader is premultiplied alpha, yes?
<kennylevinsen>
are you writing a compositor or a client?
<kennylevinsen>
if compositor, yeah you should treat the input as pre-multiplied alpha
mclasen has joined #wayland
<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
<Ermine>
wayland-client.h says that its usage is discouraged. Should I include wayland-client-core.h and -protocol.h by hand?
<vyivel>
yes
<Ermine>
okay, thank you
<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!
nerdopolis has quit [Ping timeout: 480 seconds]
Guest1884 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest1941
iconoclasthero has quit [Remote host closed the connection]
iconoclasthero has joined #wayland
kts has quit [Ping timeout: 480 seconds]
iconoclasthero has quit [Remote host closed the connection]
kts has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
<swick[m]>
kennylevinsen: I would always say electrically premultiplied alpha
Moprius has joined #wayland
<swick[m]>
which is a horrible thing
<kennylevinsen>
I personally prefer hydraulically premultiplied alpha
<swick[m]>
well, the point is that premultiplication on an encoding is kind of stupid
<swick[m]>
it really needs to be on tristimulus values
<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...
<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
<swick[m]>
but that's not really what we do nowadays
<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...
<swick[m]>
except for direct scanout and there it matters
<swick[m]>
yes
<kennylevinsen>
with the cost being loss of dynamic range on the color channels whenever the alpha channel isn't 1
<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
rv1sr has quit []
<swick[m]>
also scaling etc should be done in optical premult to be "correct"
<swick[m]>
so all in all, you basically always want optical premult, sometimes encoded, sometimes linear
<emersion>
the reason for premult alpha is to be able to just use a simple OpenGL shader, instead of a two-pass thing
<emersion>
(or a very simple/fast pixman op)
<kennylevinsen>
I wonder where the whole linear blending thing will land in the end given clients getting surprised by it
nerdopolis has joined #wayland
<kennylevinsen>
didn't kwin end up reverting linear blending?
<swick[m]>
if you do linear blending with PQ everything looks like dogshit
<swick[m]>
so you have to option of sometimes blending in linear and sometimes in sRGB
<swick[m]>
which is horrible because now if a client switches from sRGB to PQ suddenly alpha looks wrong
<kennylevinsen>
as I always say, colors were a mistake :(
<swick[m]>
or live with dogshit blending everywhere
<swick[m]>
or just break stuff once now and do linear blending even if there are minor problems
<swick[m]>
kwin did the sRGB and PQ do different blending and I don't agree with that
<swick[m]>
GTK also switched to linear blending and will break everything once
<King_DuckZ>
just learning but what I'd do is linear non-premult everywhere, do it as late as possible
<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
Brainium has joined #wayland
<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
<kennylevinsen>
not to mention luminance in case of HDR
<kennylevinsen>
and now you're entering the fun world of color management
<kennylevinsen>
which I am entirely the wrong guy to explain
* kennylevinsen
points at swick[m]
<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
<swick[m]>
the EDID technically tells you the gamma of the display in default mode
<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
<zamundaaa[m]>
kennylevinsen: yes, KWin git master blends in a gamma 2.2 space
<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
feaneron has joined #wayland
rv1sr has joined #wayland
<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
<swick[m]>
end result is still the same: different blending in some situations and I think that's not good
<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
<zamundaaa[m]>
Yes, that was a bad situation, which is why we now always blend in some gamma 2.2 space
<swick[m]>
we're still doing the same in mutter
<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?
<swick[m]>
it doesn't look completely right, no
<swick[m]>
to some degree some players convert things
<swick[m]>
but because they don't really know the display capabilities even that isn't that useful
<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)
<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
<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
<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
<King_DuckZ>
just output linear or whatever you get in, for specialised hardware
<King_DuckZ>
swick[m]: can you? iirc last time I tried even resizing was wrong in gimp
<King_DuckZ>
to my great disappointment
<swick[m]>
ah, working color space
<swick[m]>
yeah, that might still not work correctly in gimp. dunno.
<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
<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
<King_DuckZ>
swick[m]: we had a room like that, maybe we did have that hardware in there and I didn't know
<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 :)
<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
<swick[m]>
at the end, color grading happens with those cards in tightly controlled viewing environments
<swick[m]>
btw, the video touches onto something about premultiplied images: they can store more information than un-premultiplied ones
cyrinux has quit []
<King_DuckZ>
yes true
cyrinux has joined #wayland
<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
<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
leon-anavi has quit [Quit: Leaving]
feaneron has quit [Remote host closed the connection]
<King_DuckZ>
from my link: "[...] and they perceive the public software tools as toys" I can confirm that to be true
julio7359 has joined #wayland
julio7359 has quit [Remote host closed the connection]
julio7359 has joined #wayland
iconoclasthero has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
coldfeet has joined #wayland
<mclasen>
swick[m]: we haven't switched yet
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Remote host closed the connection]
lbia_ has joined #wayland
lbia has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
pominator1 has quit [Quit: Leaving.]
lbia has joined #wayland
lbia_ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
lbia has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
lbia has joined #wayland
Moprius has joined #wayland
Brainium has joined #wayland
mohan43u has quit [Quit: WeeChat 4.3.3]
mohan43u has joined #wayland
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
Company has joined #wayland
sima has joined #wayland
Moprius has quit [Quit: bye]
sima has quit [Remote host closed the connection]
sima has joined #wayland
Guest1941 has quit [Remote host closed the connection]
sima has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest1971
sima has joined #wayland
sima has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
julio7359 has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
vincejv_ has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
rv1sr has quit []
glennk has quit [Read error: Connection reset by peer]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
overholts has quit [Server closed connection]
overholts has joined #wayland
<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?
<kennylevinsen>
Ermine: it's the xdg_surface.configure that you xdg_surface.ack_configure with the serial from the former
<kennylevinsen>
xdg_surface.configure will follow the zxdg_toplevel_decoration_v1.configure, similar to how xdg_toplevel.configure works
<Ermine>
Ah, so zxdg_toplevel_decoration_v1.configure is to communicate to me what mode compositor wants