ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
ar1nov has joined #wayland
st3r4g has quit [Quit: おやすみ]
arinov has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
Seirdy has quit []
Seirdy has joined #wayland
wahfato has joined #wayland
wahfato has quit []
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
TattooedTech has joined #wayland
aetnaeus has joined #wayland
wahfato has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
aetnaeus has quit [Quit: leaving]
c7s has quit [Ping timeout: 480 seconds]
flibitijibibo has quit [Ping timeout: 480 seconds]
jgrulich has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
louipc has joined #wayland
bodiccea has quit [Remote host closed the connection]
louipcm has joined #wayland
aetnaeus has joined #wayland
bodiccea has joined #wayland
bodiccea has quit [Remote host closed the connection]
maxzor has quit [Remote host closed the connection]
bodiccea has joined #wayland
maxzor has joined #wayland
danvet has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
alexmitchellmus_ has quit [Remote host closed the connection]
alexmitchellmus_ has joined #wayland
Ariadne has quit [Read error: Connection reset by peer]
Ariadne has joined #wayland
Ariadne has quit [Read error: Connection reset by peer]
Ariadne has joined #wayland
JPEW has quit [Read error: Connection reset by peer]
tzimmermann has joined #wayland
JPEW has joined #wayland
rgallaispou has joined #wayland
hardening has joined #wayland
ar1nov has quit [Ping timeout: 480 seconds]
pnowack has joined #wayland
ar1nov has joined #wayland
rasterman has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
Seirdy has joined #wayland
marmarek has joined #wayland
<MrCooper>
teh1[m]: not Wayland itself, though the specific Wayland compositor you're using might; e.g. at least older versions of mutter created X11 display sockets such that they were not accessible to other users at the filesystem level
ar1nov has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
ammen99[m] has quit []
heftig[m] has quit [Quit: Bridge terminating on SIGTERM]
MatrixTravelerbot[m] has quit []
Eighth_Doctor has quit []
HayashiEsme[m] has quit []
DrNick has quit []
GrahamPerrin[m] has quit []
MarcusBritanicus[m] has quit []
DemiMarieObenour[m] has quit [Quit: Bridge terminating on SIGTERM]
kajiryoji[m] has quit []
toggleton[m] has quit []
ar1nov has joined #wayland
x[m] has quit []
ignapk[m] has quit []
nielsdg has quit []
YaLTeR[m] has quit []
gnustomp[m] has quit []
reactormonk[m] has quit []
niecoinny[m] has quit []
Guest3434 has quit []
inkbottle[m] has quit []
apol[m] has quit []
pac85[m] has quit []
shadowninja55[m] has quit []
teh1[m] has quit [Quit: Bridge terminating on SIGTERM]
danburd[m] has quit []
smasher_tati[m] has quit []
jryans has quit []
ujineli[m] has quit []
Sumera[m] has quit []
doras has quit [Quit: Bridge terminating on SIGTERM]
bdaase[m] has quit []
junglerobba[m] has quit []
Mershl[m] has quit []
FbioPacheco[m] has quit []
idkrn[m] has quit []
ttancos[m] has quit []
arichardson[m] has quit []
japchae[m] has quit []
rails[m] has quit []
ongy[m] has quit []
charafau[m] has quit []
zzag[m] has quit []
robertmader[m] has quit []
GeorgesStavracasfeaneron[m] has quit []
vchernin[m] has quit []
botiapa[m] has quit []
digitalshethey[m] has quit []
Levans has quit [Quit: Bridge terminating on SIGTERM]
edrex[m] has quit []
[old]freshgumbubbles[m] has quit []
frytaped has quit [Quit: Bridge terminating on SIGTERM]
psydroid[m]1 has quit []
MA[m] has quit []
louipcm has quit []
halfline has quit []
mooff[m] has quit [Quit: Bridge terminating on SIGTERM]
flyingketh[m] has quit []
AndrewAylett[m] has quit []
ivyl has quit [Quit: Bridge terminating on SIGTERM]
msisov[m] has quit []
unrelentingtech has quit [Quit: Bridge terminating on SIGTERM]
<maxzor>
Can I use a subsurface to render 2D with the CPU, another subsurface GPU-accelerated, and hand them to the compositor for them to be blended?
<maxzor>
I am trying to render a few curves, and thought of some eGui widgets next to these.
<ishitatsuyuki>
yes you can
<ishitatsuyuki>
but you said "blended"?
<ishitatsuyuki>
does it involve alpha compositing?
<maxzor>
can it not be?
<maxzor>
I understood I could alpha blend subsurfaces
<emersion>
yes, if it has a alpha channel, it'll be blended with the surfaces underneath
<emersion>
weston-subsurfaces does something similar, mixing GL accelerated and shm buffers
<ishitatsuyuki>
alpha compositing is OK but just keep in mind that alpha blending does have a cost proportional to the alpha-enabled buffer
<maxzor>
👍 Well right now I'm on a quest to learn rust and went with the smithay toolkit
<ishitatsuyuki>
proportional to the dimensions*
<maxzor>
but might install weston^
TattooedTech has quit [Quit: Leaving]
fmuellner has joined #wayland
zebrag has joined #wayland
Guest7762 has quit []
enick_484 has joined #wayland
<maxzor>
Couldn't find the feature defined in either core nore protocols, so it's de facto?
<maxzor>
s/nore/nor
<emersion>
which feature?
<maxzor>
the alpha blend
<kennylevinsen>
you control it with the alpha channel of your buffer if you picked a format that has one
<ishitatsuyuki>
speaking of alpha blending, I'm bit concerned what will happen with gamma-corrected vs direct sRGB space blend especially when color management support is in the work
fmuellner has quit [Ping timeout: 480 seconds]
<kennylevinsen>
it'll go from being largely undefined to being well-defined if proper color management is used?
<kennylevinsen>
the end-result from blending will likely differ from what is seen right now though
<ishitatsuyuki>
so yeah, that would be kinda backward incompatible?
<ishitatsuyuki>
or maybe we could make linear blending opt-in in some ways
<emersion>
well, it's undefined right now, so no
<ishitatsuyuki>
huh
<emersion>
some (most) compositors do incorrect blending right now
<emersion>
they don't linearize before blending
<ishitatsuyuki>
deviating from de-facto is a compatibility breaking change
<emersion>
not really
<kennylevinsen>
compositors do not agree on a de-facto right now
<emersion>
some compositors do the right thing
<ishitatsuyuki>
just want to say that there's no "correct" blending
<emersion>
some don't
<emersion>
there is one "correct" blending
<ishitatsuyuki>
designers are used to sRGB blending
<ishitatsuyuki>
linear blending isn't used anywhere in practice
<ishitatsuyuki>
except HDR rendering in games maybe, but that has nothing to do with compositing
<emersion>
in any case, nothing's in the spec, so there's nothing to break
caveman has quit [Remote host closed the connection]
<ishitatsuyuki>
if you force linear on everyone you're basically overriding every designer's intention and laughing at them saying "no that's the 'wrong' blending! lol"
<emersion>
the spec doesn't say that a compositor will blend in any manner, nor does it say that the compositor won't invert color channels when rendering, nor does it say that the compositor won't paint cats all over the screen when rendering
<ishitatsuyuki>
just for your further reference, the SVG spec allows you to specify linear or sRGB blending with sRGB being the default
<kennylevinsen>
even when it's defined, I doubt how critical it will ever be - for a single application designer, it only affects blending of overlapping subsurfaces and popups
<ishitatsuyuki>
well, it changes the visual of shadows
<ishitatsuyuki>
critical? no. noticable? yes.
<emersion>
the color management protocol will allow specifying whether a buffer is sRGB or linear, iirc
<ishitatsuyuki>
it's not about the buffer itself, but rather the blending operation
<emersion>
the buffer properties affect the blending
<ishitatsuyuki>
huh, no
<emersion>
if the buffer is marked as linear, the buffer won't linearize it before blending
<emersion>
s/buffer/compositor/
<emersion>
if the buffer is marked as sRGB, the compositor will linearize
* kennylevinsen
was about to nitpick that regex
<emersion>
some compositors might have user-configurable knobs to switch between the current behaviour and the new one
<ishitatsuyuki>
you should think sRGB vs linear blending as a difference in blending operation, something like multiply, sunburn etc
<emersion>
no, it's not, the blending is the same
<emersion>
what matters is whether your linearize or not before
<emersion>
maybe you're not talking about linear vs. sRGB, but something else?
<ishitatsuyuki>
well, what I want to say that it changes the treatment of pixel data *below* the buffer as well
<kennylevinsen>
maybe pq's extensive color management intro thing would be good here?
<ishitatsuyuki>
I know what I'm saying
<emersion>
*everybody* knows what they're saying :P
<ishitatsuyuki>
when fg and bg is in linear space, sRGB blending means fromSrgb(toSrgb(fg) * a + toSrgb(bg) * (1-a))
<emersion>
nobody does this
<emersion>
because it's more effort to do the incorrect thing
<emersion>
what happens usually is that input data is sRGB and compositors just add the values as-is
<ishitatsuyuki>
yes, but what if bg is linear and fg is srgb?
<emersion>
right now all input data is assumed to be sRGB
tzimmermann has quit [Quit: Leaving]
<emersion>
compositors clear, then blend the first buffer into the screen (maybe they do the sRGB → linear conversion, maybe not), then carry on with the second one, etc
<ishitatsuyuki>
it's late at night and I need to sleep right now, sorry maybe will continue this later
<emersion>
no worries
flibitijibibo has joined #wayland
c7s has quit [Ping timeout: 480 seconds]
ar1nov has joined #wayland
marmarek has joined #wayland
<swick>
there is multiple "correct" blending modes but blending in non-linear space is always "wrong"
<swick>
that doesn't mean that the wrong blend mode should not be supported somehow
<swick>
but emersion is right that the blending mode currently is completely undefined so we can choose a "correct" mode in the CM protocol
<glennk>
ultimately its graphics, if it looks right, it *IS* right :-)
ar1nov has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
enick_484 has quit []
enick_484 has joined #wayland
caveman has joined #wayland
creich has quit [Remote host closed the connection]
creich has joined #wayland
wahfato has quit []
creich has quit [Remote host closed the connection]
creich has joined #wayland
creich has quit [Remote host closed the connection]
ar1nov has joined #wayland
spstarr has joined #wayland
Guest7738 has left #wayland [#wayland]
DrNick has joined #wayland
wahfato has joined #wayland
<mtj>
hey folks, do i need to restart Xorg after editing my /etc/libinput/local-overrides.quirks file - for my trackpad to use the new values?
ofourdan has quit [Remote host closed the connection]
ar1nov has joined #wayland
maxzor_ has joined #wayland
<pq>
ishitatsuyuki, unless *all* the content in the desktop is plain old sRGB, I don't see a way to even define what backward-compatible blending should do.
<pq>
ishitatsuyuki, if you want the blending results to be something specific, then do not off-load that to a compositor without using a protocol extension to guarantee the result.
<pq>
also off-loading alpha blending to KMS adds another layer of unknown behavior
<pq>
emersion, ishitatsuyuki, seems you were both talking about the same thing in different words. That's so common with color, and neither will understand the other, or what the difference is. Unfortunately explaining these takes a huge amount of effort in any chat.
<pq>
though ishitatsuyuki's example of having linearly encoded color and then temporarily non-linearising it for the blending operation is... well, the first I've seen.
<pq>
IMO, traditional sRGB (non-linear) blending is just an abstract operation with no physical meaning. It is used, and colors are adjusted to produce acceptable results with it, which means computing something else is a change, even a regression.
<pq>
But I cannot see how that could work with any material that is not in plain old sRGB color space and SDR.
<emersion>
so, you're planning to use "gamma-incorrect" blending by default?
<pq>
yes when color management is disabled, and cannot do it at all when color management is enabled.
<emersion>
ah, okay, that makes sense
<pq>
...if I guessed what you mean by gamma-incorrect blending: the old thing everyone does with non-linear color values.
jgrulich has quit [Remote host closed the connection]
<pq>
it's "incorrect" in the sense that is has no physical meaning, but it's still a computable mathematical operator.
<pq>
the "correct" blending has a physical meaning: you have pixels emitting light, and the pixel on top is partly occluding the pixel beneath.
<pq>
Tor occluded part, the below pixel's light is completely blocked, and only the above pixel's light comes through.
<pq>
*For
<pq>
For the unoccluded part, the below pixel's light comes through and the above pixel does not exist.
<pq>
This is very much connected to the concept of "alpha as coverage", which leads the "normal" blending equation you're accustomed to.
<pq>
a.k.a Over in Porter-Duff terms
<pq>
*leads to
<emersion>
pq, do you think we should document the untold sRGB rule, just like the pre-multiplied rule?