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
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
robobub has quit []
navi has quit [Quit: WeeChat 3.7.1]
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
Leopold_ has quit []
Leopold_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner has quit [Remote host closed the connection]
Company has quit [Quit: Leaving]
cool110 has quit [Quit: ZNC 1.8.2+deb2build6 - https://znc.in]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
pochu has joined #wayland
danvet has joined #wayland
<pq>
yshui`, attaching two buffers before committing is described in protocol spec: only when pending surface state is committed, the buffer will become used. Hence, the overridden buffer will not be getting releases, because never came into use.
<pq>
DemiMarie, I don't know.
eroux has joined #wayland
mvlad has joined #wayland
rasterman has joined #wayland
ukiran has joined #wayland
nnm_ has quit []
nnm has joined #wayland
nnm has quit [Read error: Connection reset by peer]
nnm has joined #wayland
nnm has quit [Read error: Connection reset by peer]
nnm has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
roshan has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
roshan_ has joined #wayland
roshan_ has quit []
roshan has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
roshan has joined #wayland
roshan_ has joined #wayland
andyrtr has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
Leopold__ has joined #wayland
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
nerdopolis has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 has quit [Remote host closed the connection]
astlep4 has joined #wayland
astlep4 was banned on #wayland by pq [*!*astlep@*.lightspeed.nsvltn.sbcglobal.net]
<pq>
excessive join/quits
roshan has quit []
roshan has joined #wayland
jmd has quit [Ping timeout: 480 seconds]
roshan has quit []
roshan_ has quit [Remote host closed the connection]
Company has joined #wayland
kts has quit [Quit: Konversation terminated!]
astlep4 has quit [Remote host closed the connection]
ukiran has joined #wayland
ukiran85 has joined #wayland
ukiran85_ has joined #wayland
agd5f has joined #wayland
ukiran85_ has quit []
ukiran85_ has joined #wayland
ukiran85_ has quit []
ukiran1 has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
ukiran has quit [Ping timeout: 480 seconds]
ukiran85 has quit [Ping timeout: 480 seconds]
ukiran1 has quit []
ukiran has joined #wayland
<ukiran>
hello
<ukiran>
swick, pq, I have few doubts about the color representation protocol
<ukiran>
as this protocol is used to perform the format conversion from YUV to RGB using the code points exposed through interfaces
<ukiran>
this is based on the ITU-H.273 document.
<ukiran>
Similar to that, are there any standards which does the conversion from RGB to YUV ?
floof58 has joined #wayland
fmuellner has joined #wayland
<JEEB>
ukiran: H.273 technically specifies XYZ to {RGB,YCbCr,YCgCo,ICtCp,ITPv2} and vice versa. biggest problem seems to mostly be the cases where EOTF and OETF are not the same thing, such as the old BT.709|BT.2020 transfer function entries.
<JEEB>
they have notes for those where f.ex. BT.1886 should be utilized for EOTF while OETF is the marked one
kts has joined #wayland
<ukiran>
The Color primary code point values mentioned are with the reference of XYZ color space ?
Fxzxmic has joined #wayland
<JEEB>
ukiran: so matrix is the thing you need to apply to get to the point where you can handle primaries (basically "identity matrix" meaning that depending on the primaries value it's either RGB or XYZ). and in primaries one of them is XYZ which is in many workflows the "end point" until you convert then to another thing, and transfer is what you need to apply to get to/from linear
<JEEB>
I think H.273 (which is freely available) defines this rather well
<JEEB>
and the other primaries generally are defined in the XYZ meaning
<JEEB>
for example your bog standard sRGB being identity matrix, BT.709 primaries and sRGB transfer
<JEEB>
or well, technically H.273 defines the code points which then refer to these different things and describe how the image should be interpreted
<JEEB>
aka CICP (common independent code points)
sav10 has joined #wayland
sav10 has quit []
ukiran has quit [Ping timeout: 480 seconds]
<pq>
JEEB, color-representation deliberately does not carry the colorimetry CICP fields. :-)
<pq>
ukiran, there is no difference between YUV->RGB and RGB->YUV. Both use the same matrices and stuff. This is not like the TransferCharacteristics mess.
<pq>
...except for the "constant luminance" variants...
<pq>
color-representation alone is insufficient for the constant luminance variants, those need also color-management to carry the rest of the CICP fields.
<pq>
JEEB, sounds like you were talking about ColourPrimaries and TransferCharacteristics when the question was about MatrixCoefficients.
<pq>
I'm so grateful that H.273 put names on those things.
<pq>
would be nice if it suggested names for the actual code points, too
bodicceaII has quit [Remote host closed the connection]
bodiccea has joined #wayland
<yshui`>
@pq, that is not what I asked. I probably phrased it poorly 😅
<yshui`>
so my current understanding is like this: the client attaching a wl_buffer to a wl_surface gives the compositor a "token" so to speak, which it can use to access the content of the buffer. when the compositor is done, it sends out a wl_buffer.released to give up that token.
<yshui`>
and when the buffer naturally drops off the surface, the client would receive a released event as well.
<yshui`>
so right now I only have one thing that's unclear. if the client attaches a buffer to a sync subsurface, commits the subsurface but not the parent, can the compositor access the buffer? and does the compositor need to send released for that buffer?
tzimmermann has quit [Quit: Leaving]
<MrCooper>
yes and yes
<MrCooper>
in a nutshell, buffer attach + commit transfers ownership of the buffer to the compositor, buffer release event transfers it back to the client
<yshui`>
even if it is just committed to the cached state of a sync subsurface?
<yshui`>
i would prefer it to be this way because it's easier to keep track of.
<tommybomb>
I'm developing a command runner like bemenu. Right now I have the application launch, but in sway it's forcing it as a tiled application. Should I be using "wlr_layer_shell_v1" to properly launch it as an overlay? Or is there another way of going about this?
<emersion>
you could set a fixed sized on your window if you wanted to make it floating by default
<tommybomb>
Sorry, what method & protocol would that be?
<tommybomb>
xdg_shell set_max_size?
<tommybomb>
(on the toplevel)
<emersion>
set_max_size and set_min_size with the same size on both
<tommybomb>
That appears to have done the trick, thanks.
<RAOF>
tommybomb: Yeah, if you want to be chrome (ie: something that decorates the desktop / an application), you'll need t ouse something like layer_shell.
<tommybomb>
ok, thanks figured as much
Arnavion has quit []
<yshui`>
hmm, i thought the surface pending state is like a shadow state, which the requests operate on. and then on commit, the current state is simply replaced wholesale by the pending state. but that's not the case, right?
<yshui`>
pending state is like an accumulation of changes, which is then applied to the current state on commit.
<yshui`>
like if you do damage, set_buffer_transform, damage, both damage should use the new buffer transform on commit.