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]
fmuellner has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
danshick has quit [Remote host closed the connection]
danshick has joined #wayland
slattann has quit [Quit: Leaving.]
hariselldon[m] has joined #wayland
cvmn has joined #wayland
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
neonking has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
repetitivestrain has joined #wayland
kts has joined #wayland
danvet has joined #wayland
neonking has quit []
jgrulich has joined #wayland
<repetitivestrain>
has anyone experienced firefox menus just flickering to transparency when writing a wayland compositor? i don't expect asking here will return any useful results as this seems like a pretty obscure bug but one can always hope
<repetitivestrain>
firefox seems to exercise lots of exotic functionality
<repetitivestrain>
the flickering exhibits itself as the menu randomly becoming transparent when the highlighted item is updated by pointer movement
<Sachiel>
I don't see any flickering in sway, it just straight up disappears and never comes back
<repetitivestrain>
they work in sway for me here without any weird flickering
<repetitivestrain>
i can't really imagine what might be going on, as long as firefox doesn't write to buffers which it hasn't gotten wl_buffer.release for yet
<repetitivestrain>
does firefox do anything like that?
<Sachiel>
no idea. For me it mostly works, but the menu from one extension will sometimes disappear, and the burger menu sometimes does too when I try to use a submenu
<repetitivestrain>
odd, it could be related to how subsurfaces are used for the burger menu as well
<repetitivestrain>
thanks, but i already support everything up to and including version 5 of xdg_shell
<repetitivestrain>
so i don't think that's the bug here
<repetitivestrain>
it's probably related to either subsurfaces or wl_buffer release in some way
<repetitivestrain>
but i can't find what that "some way" is
<kennylevinsen>
repetitivestrain: sounds like a damage issue - could be a bug on your end if you mishandle damaged regions.
dcz_ has joined #wayland
dcz_ has quit []
dcz_ has joined #wayland
tzimmermann has joined #wayland
<ofourdan>
zubzub: best would be to file an issue against xwayland in gitlab and I'll cc the nvidia folks there
<repetitivestrain>
kennylevinsen: i tried setting the flag to redraw *everything* on damage and it still kept flickering, so it most likely is not that
<zubzub>
ofourdan: ok will do!
rasterman has joined #wayland
<kennylevinsen>
repetitivestrain: what flag? Content that flickers between two states on every new frame (e.g. for every pixel the cursor moves) is a damage problem 99% of the time - either in client or compositor.
<repetitivestrain>
repetitivestrain: the flag that makes my compositor repaint the entire surface hierarchy without caring about damage at all
<repetitivestrain>
every surface with a buffer attached
<kennylevinsen>
damage would also implies buffer clipping and output scissoring, make sure you flag controls all of it. If moving a cursor outside an application causes one of its surfaces to flicker, I can't think of another cause.
<kennylevinsen>
test in another compositor of course to see if your version of Firefox is broken
<MrCooper>
ofourdan zubzub: sounds like the nvidia driver advertises an illegal modifier?
<ofourdan>
it seems like that
<ofourdan>
and apparently it might be a regression in recent driver, is that right zubzub ?
<ofourdan>
(iiuc)
<repetitivestrain>
it does work in mutter and sway, and yes the flag i used controls all of that
<repetitivestrain>
i'm suspecting firefox clearing the shm buffer at some point before release, because my compositor doesn't (can't) upload the buffer contents to the gpu immediately after commit
<repetitivestrain>
while mutter and wlroots seem to do that
<repetitivestrain>
so it relies on programs respecting .attach/.release more than usual
<repetitivestrain>
so, does anyone know if firefox does anything like that?
<vyivel>
i recall something similar
<zubzub>
ofourdan: no idea, I haven't tested older drivers
<ofourdan>
ah right, so I was mistaken
<kennylevinsen>
repetitivestrain: wlhax can give you a live overview of the buffers in use, might help
<repetitivestrain>
sadly firefox tends to change that too quickly for anything other than rummaging through very long WAYLAND_DEBUG=server printouts to be useful
<kennylevinsen>
yeah in wlroots we generally aim for immediate release of shm, but not all compositors do this so I'd be a bit surprised if Firefox relied on it
<repetitivestrain>
but i doubt looking at buffer ownership will help, since to me it seems that the only way the problem can happen is if firefox wrote to shm buffers before .release is sent
<repetitivestrain>
really odd
<MrCooper>
if all major compositors do it, it wouldn't be too surprising
<kennylevinsen>
repetitivestrain: disabling the optimization in a different compositor would validate your theory
manuel1985 has joined #wayland
chipxxx has joined #wayland
<repetitivestrain>
damn... i hadn't thought of that, thanks
<ofourdan>
zubzub: I cc'ed james and erik on there
<zubzub>
ofourdan: tysm!
repetitivestrain has left #wayland [ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]
<pq>
JEEB, I do think without having both "Colorspace" and "HDR_OUTPUT_METADATA" props, your HDR output is kinda up to luck.
<pq>
JEEB, both of these are "just" infoframe data sent to the sink, so if the property does not exist, I would think the driver just doesn't send anything about it. But who knows.
<pq>
JEEB, I'm not even sure how those two infoframe settings interact. HDR_OUTPUT_METADATA has looks a bit overlapping to Colorspace.
<pq>
JEEB, would need to check HDMI/DP specs about that they do.
kts has joined #wayland
gschwind has joined #wayland
<pq>
JEEB, oh right, some vague memories coming up. Maybe "Colorspace" is the container format and "HDR_OUTPUT_METADATA" describes what sub-volume of the container format color volume is actually meaningful. swick could probably confirm.
mvlad has joined #wayland
<JEEB>
pq: looking at the CTA specs colorspace is matrix and primaries in H.273 (Coding Independent Coding Points) parliance and the dynamic range and mastering one contains the transfer
<JEEB>
without colorspace it's basically "default", whatever the screen may or may not interpret that as
<pq>
yeah
<pq>
(colorspace is never a matrix; a matrix can be transformation between two color spaces)
<JEEB>
matrix coefficients I mean
<pq>
hmm?
<JEEB>
which in case of RGB is "identity"
<JEEB>
and BT.709|BT.2020 YCbCr it's a matrix
<JEEB>
well, asdf I mean extra mangling :V
<pq>
oh, you're talking about YUV encoding/decoding matrices, not colorspaces
<JEEB>
colorspace in that sentence was the infoframe
<JEEB>
which is called Colorspace in linux
<JEEB>
which includes definition of matrix coefficients and primaries in one field
<JEEB>
which is why I said "is matrix (coefficients) and primaries"
<pq>
right
<JEEB>
anyways, afk ($dayjob)
<pq>
"Colorspace" prop indeed defines two different things in the same enum.
<pq>
my understanding is that that anchors the video signal values into a specific colorimetry; the container format.
rasterman has quit [Quit: Gettin' stinky!]
<pq>
then HDR_OUTPUT_METADATA comes up and says wait, the TF is this instead, and the color sub-volume that's actually important is this.
rasterman has joined #wayland
<pq>
The sub-volume is communicated because gamut mapping the whole BT.2020 for instance to what the monitor can actually display would lead to a poor image. Gamut mapping the important sub-volume instead leads to better results.
<pq>
theoretically, one could use HDR_OUTPUT_METADATA to guess what the container should could be, but I don't know if anything does or how good chances it has guessing right.
<pq>
it's possible that the TF from HDR_OUTPUT_METADATA is hint enough about which standard the video signal probably follows. IIRC PQ and HLG tend to use BT.2020. RGB vs. YUV vs. YUV vs. ... is likely something the KMS driver picks on its own, I guess.
<pq>
I'd actually be surprised if monitors/TVs handles anything except the very few standard combination.
jgrulich has quit [Remote host closed the connection]
jgrulich has joined #wayland
<JEEB>
pq: yea screens handle a very limited subset
<JEEB>
and I think basically the transfer is "unset/default" until you set one transfer
<JEEB>
and yes, the mastering display stuff is just "what the mastering person's display showed, so you may ignore the rest"
<JEEB>
which is why you generally see the P3 gamut there
<JEEB>
but that's just display hinting and not related to the basics configuration :)
<pq>
right
<pq>
but in practise, I believe very few combinations are actually used, so sinks will only work with those few and everything else is untested.
<JEEB>
yes
<pq>
in that context, maybe HDR_OUTPUT_METADATA happens to be only thing needed for everything else to accidentally fall into place
<JEEB>
effectively I think BT.709+sRGB | all three (matrix coeffs, primaries, transfer) unset is one, and then for HDR capable there's BT.2020+PQ that's generally supported
<pq>
btw. e.g. my HDR monitor uses the HDR_OUTPUT_METADATA max luminance field as something like: bool bright_backlight = maxLum > 100;
gschwind has quit [Remote host closed the connection]
gschwind has joined #wayland
MrCooper_ has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
<JEEB>
also it could /25
<JEEB>
whoops
MrCooper__ has joined #wayland
MrCooper_ has quit [Ping timeout: 480 seconds]
<JEEB>
pq: anyways the reason I wanted to grab someone's brains is because I was just testing some changes over at mpv where we would also start setting DRM flags when being hooked directly against DRM/KMS, and while nonzero blobs did appear, it didn't seem to cause my monitor actually inform me that a HDR transfer was being fed to it. and then after looking into the CTA spec it seemed that if you wanted the whole
<JEEB>
"triplet" (matrix coeffs, primaries, transfer) being defined, then you needed both of the props. so I wanted to hear what people's experiences so far were
<JEEB>
I see that kodi as well only sets the transfer
<JEEB>
(as well as libweston's DRM back-end)
<JEEB>
thankfully there seems to be a patch set to implement the Colorspace prop for amdgpu
<JEEB>
so I might just test whether setting that helps with my screens (a dell monitor and a samsung TV)
<JEEB>
it in any case seems like the Proper Thing To Do, as otherwise matrix coeffs and primaries are left to undefined/default, which does not sound great if we know what we are feeding :P
<pq>
JEEB, you are correct.
<pq>
JEEB, not so long ago, there were no drivers that supported both. Some supported one, some the other.
<pq>
my HDR testing is on amdgpu, so
<JEEB>
yea, renoir here
<JEEB>
i915 and vc4 are the only ones supporting both looking at the DRM db
<JEEB>
pq: also I generally utilize the wording "presentation hint" for the mastering display info, since there's a nonzero amount of content where f.ex. brightness goes way further than the mastering display capabilities mentioned, so we just assume that such mastering screens clip() at their max capability and it's a hint for gamu/tone mapping to ignore stuff that goes further :)
<JEEB>
*gamut
<JEEB>
while I do understand the container/content wording, of course :) and I do wish they just had something like content color volume or something :P
<abdur>
Greetings! Is there a working example of running weston with seatd-launch somewhere?
<kennylevinsen>
should just be "seatd-launch -- weston"
fahien has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
fahien has joined #wayland
<abdur>
kennylevinsen: Thank you! I am able to pass the arguments to the weston command now. I am trying to run weston from a serial terminal using -Bdrm-backend.so. However it terminates with, "fatal: drm backend should be run using weston-launch binary, or your system should provide the logind D-Bus API." Is using DRM backend possible with seatd-launch. I am on weston 10.0.0.
<kennylevinsen>
abdur: is the libseat launcher enabled in your weston build?
<kennylevinsen>
It was only enabled by default after
<kennylevinsen>
*after 10.0
<abdur>
kennylevinsen: Thanks for the hint! I will confirm this and make changes to the build configuration if required.
<swick>
JEEB pq: fwiw, that's my current understanding as well
<swick>
even though the TF is defined by EDID/DisplayID if it's not explicitly changed
scriptingdad[m] has left #wayland [#wayland]
kts has joined #wayland
<emersion>
pq, i'm on the fence regarding color-representation… maybe compositors should be updated to have one texture per surface+buffer pair, instead of one texture per buffer
<emersion>
i wonder if more color management stuff will force compositors to do this anyways
<pq>
emersion, the current situation is one texture per surface, not per buffer.
<emersion>
maybe compositors need to have a separate concept of texture and texture view, just like vulkan has
<emersion>
pq, i don't think so, at least for dma-buf?
<pq>
oh, right, you cache the dmabuf textures?
<pq>
wl_shm has per surface
<emersion>
with dma-bufs you're supposed to turn the dma-buf into a EGLImage once only?
<emersion>
wl_shm is kind of special because you need to copy/upload the pixels
<emersion>
libwayland takes care of "importing" once (mmap)
<pq>
I don't remember anymore about EGLImage, it has changed in what feels so may times.
fmuellner has quit [Ping timeout: 480 seconds]
<emersion>
are all of the color management bits something done in shaders only?
<pq>
hmm... let's see
<pq>
YUV-RGB conversion is possible to off-load to EGL, right? And Vulkan as well?
<emersion>
there is UNORM/SNORM, but it's just about signedness
<emersion>
there are scaled variants, no idea what these are
<pq>
eheh, EXT_sRGB uses the piece-wise TF, which is what sRGB is encoded with, but the sRGB spec says it should be decode with a pure power-law function instead.
<pq>
classic video standard: encode with this (except you don't), then decode with that
<vsyrjala>
but no vulkan games expect 10bpc anyway, and just fail if you try to force them
<emersion>
pq, i don't see a set_linear() in color management protocol
<emersion>
oh, EOTF
<swick>
pq: I mean, decoding/encoding with the piecewise is the correct thing though for shader access
<pq>
brb
<emersion>
hm, so compositors would potentially need to create one VkImage/EGLImage per surface+buffer pair to implement srgb/linear
<emersion>
sorry, s/EGLImage/GL texture/
<emersion>
i guess there's a more philosophical question: does a wl_buffer represent just the underlying storage, or more?
<pq>
swick, which means you cannot use sRGB shader access for transcoding to something else.
<swick>
oh yeah, that's true
<pq>
so I think we have now listed pretty much everything that dmabuf import or texturing units could do for color management.
<pq>
the next things in the color pipeline are color space conversion (usually a 3x3 matrix), perhaps tone mapping (???), until you arrive at blending space assuming you want to blend with linear characteristic.
<pq>
err, tone mapping + gamut mapping
<pq>
maybe also something to account for environment light, which should just modify tone mapping I guess
<pq>
then, blending, which is simple after all that - maybe
<pq>
finally the resulting composite needs to be encoded for display, which may include color space conversion, another transfer function, YUV-encoding, etc. which may or may not be off-loaded to KMS.
<swick>
jup
<pq>
emersion, I think it's safe to say that aside from KMS-offloading, shaders will be needed for at least some bits.
<pq>
dmabuf import API cannot account for everything, and definitely not if the app uses ICC profiles
<swick>
what makes you say that?
<pq>
swick, I mean, why would you add dmabuf import API to set a color matrix if you're going through Vulkan or OpenGL anyway?
<swick>
pq: currently you can't offload the whole pipeline but that should change
<pq>
plus all the tone and gamut mapping where 3D LUT might be only possible generic representation
<pq>
swick, to OpenGL/Vulkan dmabuf imported texture sampling?
<swick>
no, KMS
<pq>
I said "aside from KMS" you need shaders
<swick>
ahh, that makes more sense
<pq>
now the core question was, should a texture object (sampler whatever) be per wl_buffer or per wl_buffer×wl_surface? hmm...
<pq>
basically, the only thing we can off-load to samplers is the YUV-RGB conversion, right?
<swick>
and sRGB in some cases
<pq>
do you need a different dmabuf import to add/remove sRGB decoding?
<swick>
never know with gl but for vulkan, no
<emersion>
you don't
<pq>
It seems to me that associating color-representation to wl_buffer is a good choice from rendering API perspective, then you can keep a texture/wl_buffer and not texture/(wl_buffer×wl_surface)
<pq>
and I don't see other reasons to need texture/(wl_buffer×wl_surface)
<pq>
If you wanted to make a copy of the dmabuf converted into some more useful format, you'd do what you do with wl_shm. And that's a big if.
<pq>
now, what about KMS import
<pq>
KMS FB has pixel format, and that's it. I don't see that changing.
<pq>
even YUV-RGB conversion is configured with KMS props, and not on the FB object
<pq>
If color-representation was on wl_surface, then if you do rely on YUV-RGB conversion defined on import, you would indeed need to account for texture/(wl_buffer×wl_surface).
<pq>
btw. relying on YUV-RGB conversion on import would complicate Weston's implementation, because the renderer could decide to off-load a *part* of the "input profile transformation", which means the generic color transformation representation would need special bits to represent that.
<pq>
hm.
<pq>
maybe that's necessary anyway, for correctness
<emersion>
pq, it seems like your client is not configured to use UTF-8
<emersion>
pq, one reason why one would beed wl_buffer+wl_surface textures is srgb/linear
<pq>
I see it as UTF-8 cross-product mark, what do you see?
<emersion>
i see �
* MrCooper
too
<emersion>
UTF-8 replacement char
<pq>
quite possible, this irssi config is decades old
<pq>
emersion, for srgb/linear? but you and swick just said re-importing is not needed to add/remove srgb?
<pq>
*srgb decoding
Moprius has joined #wayland
<emersion>
re-importing is not necessary because you can re-create the VkImage from the VkMemory
<emersion>
and the GL texture from the EGLImage
<emersion>
but you'd still need to have multiple of these per wl_buffer
<pq>
aha, terminology failure
<emersion>
ie, you can close() the dmabufs
<emersion>
but still need multiple textures
<pq>
I never expected that to not be "importing"
<emersion>
to me, importing is turning the FDs into a graphics API object
<pq>
hmm, but with EGL you use EGL attribs to set up YUV-RGB params, no?
<emersion>
EGLImage, DRM GEM handle, VkMemory
<emersion>
for EGL you'd need to re-import for color-representation, but not for srgb/linear
<pq>
exactly!
<pq>
so with GL, you don't need multiple textures
<pq>
but in Vulkan you do?
<emersion>
you do
<emersion>
one for srgb, one for linear, potentially
<pq>
hm?
<emersion>
ah, and more
<emersion>
you basically always need one GL texture per color-representation params + srgb/linear
<pq>
ok then
<emersion>
the client could have many surfaces displaying the same wl_buffer
<emersion>
each with their own params
<emersion>
hrm
<emersion>
i'm getting a bit lost here
<pq>
sounds like there is no way you could avoid needing a texture per wl_surface+wl_buffer
<emersion>
if we make color-representation per-buffer, *and* srgb/linear per-buffer
<emersion>
then we could
<emersion>
but who knows, maybe vulkan will grow a new ext for well-known color space conversions sometiume
Moprius has quit [Read error: Connection reset by peer]
<pq>
huh? didn't you just say the opposite? That you must have a different texture for srgb vs. linear?
<emersion>
sorry, that was in the case where everything is per-surface
<pq>
we're talking about EGL/GL and Vulkan here, what surface?
<emersion>
wayland
<pq>
sorry, I was asking about EGL/GL and Vulkan in a vacuum, not wrt. to any Wayland extension.
<i509VCB>
For an implementor, this would mean the concept of an imported buffer would be seperate from a texture representation until we know the color representation or none exists?
<pq>
If some attribute is set on dmabuf import to EGL, then it requires that you import again if you want a different value for the attribute, that's what I'm after.
<pq>
i509VCB, it's more fun than that: the complete color transformation depends also on the output's color profile.
<pq>
or well, depending on what colorspace you choose to blend in, but that's my recommendation for now
<dottedmag>
pq: I saw UTF-8 cross-product mark FWIW
<pq>
that's odd :-)
<pq>
...did latin1 have that char as native?
<dottedmag>
U+00D7 MULTIPLICATION SIGN
<pq>
emersion, ok, so the only conclusion I can understand here is that you cannot avoid needing one texture for each wl_surface + wl_buffer combination anyway.
<pq>
...if you want to use the sampler magic of EGL and Vulkan, of course.
<pq>
if the transfer function was set on wl_buffer, we'd need an EGL extension to let apps set it. It would also start to conflict with the ICC profile interface.
<i509VCB>
So if I wanted to dynamically select the colorspace to blend in I wouldn't know until I render or can figure out what color space I need to blend in
Moprius has joined #wayland
<pq>
i509VCB, well... if you want to know the input colorspace before you decide on your blending colorspace, then naturally you need to know the input colorspace before you can produce any color transformation operators.
<pq>
or all the input colorspace of all surface in that composite
<pq>
I mean, obviously you need to know the thing before you can use the thing.
<pq>
the design Weston is going for is that the output colorspace defines the blending space.
<pq>
Another design could choose one fixed colorspace as the blending space, completely statically. It's all up to the compositor.
<i509VCB>
I was using the scenario of not knowing the output colorspace as a worst case scenario
<i509VCB>
It sounds especially brutal to have to constantly reimport from EGL if the input colorspace rapidly changes
<pq>
you always composite for a specific output, right?
<i509VCB>
yes, would I not need to reimport if the output colorspace is constant?
<pq>
no no, the reimport is not a part of the input-to-blend color transformation, but yes, it may be necessary when the input profile changes.
<pq>
arghs
<pq>
the reimport is *only* a part of the input-to-blend color transformation
<pq>
the things that affect reimport depend only on the input profile. They do not depend on your chosen blending space or output profile.
<pq>
however, the reimport is a part of the input-to-blend color transformation, so if you off-load that to the import, you need to know to not do the same thing again in the renderer. IOW, you have to remove a piece from input-to-blend color transformation to get your texture-to-blend color transformation.
<i509VCB>
eli5: as long as the input profile doesn't change, I can reuse the textures I imported?
<pq>
yes
<pq>
but what's the input profile? that's the gist here.
<i509VCB>
Definitely trying to wrap my head around the color scripture
<pq>
YUV-RGB conversion might be attached to the wl_buffer, which is fine if you want to off-load that to the import API.
<pq>
but if you want to off-load the transfer function also to the import API, you depend on wl_surface state, because the TF is attached to the wl_surface.
<pq>
sorry, not "import API" but "the API you use to import and create a texture"
<pq>
it's all just a chain of lego blocks:
<pq>
{ YUV-RGB, TF, color matrix, tone+gamut map }, this is the whole pipeline from input to blend
<i509VCB>
TF meaning?
<pq>
transfer function
<pq>
when you create a texture from an input buffer, the API may allow you to include YUV-RGB and maybe even TF.
ybogdano has joined #wayland
<pq>
anything not included you do in shaders, likely
<emersion>
pq, my conclusion is that we need to pick a side and be consistent
<pq>
YUV-RGB information might be associate to the wl_buffer or wl_surface
<pq>
TF is associate with wl_surface
<emersion>
pq, if both color-representation and linear/srgb are applied on wl_buffer, then we can avoid to have multiple textures per wl_buffer
<pq>
Color matrix and tone+gamut mapping depend on both wl_surface and output.
<emersion>
and then we need to pray for vulkan to not grow a new API for color management stuff
<emersion>
e.g. well-known CSC
<JEEB>
i509VCB: I recommend taking a look at https://www.itu.int/rec/T-REC-H.273/en for the usual things. matrix coefficients for things that require mixing to/from RGB, then color primaries and finally transfer functions.
<pq>
so depending on how you split that pipeline into groups, each groups depends on one or more of wl_buffer, wl_surface, output.
<emersion>
or at least pray that the new APIs don't supply the params at texture creation time
<emersion>
OTOH, if we apply color-representation on a wl_surface, the compositor will need to support multiple textures per wl_buffer
<pq>
emersion, except EGL does not expose wl_buffers to the client app, we have to take that into account. If there is no EGL ext to tell EGL to attach an attribute with the wl_buffer, then apps cannot.
manuel_ has joined #wayland
<emersion>
then there's the middle-of-the-road solution, with color-representation applied to wl_buffer, and linear/srgb applied to wl_surface
<emersion>
here what we gain is that the compositor can close() the dmabufs in the EGL case. still needs multiple textures per wl_buffer. doesn't change anything for vulkan
<pq>
emersion, I would also not want to pull TF separate from the CM&HDR extension, because TF and ICC profile are mutually exclusive.
<emersion>
(side note: EGL would still need a new ext to advertise reliable support for hints)
<emersion>
pq, right.
<pq>
linear/srgb is just one little detail of the CM&HDR set of parameters
<emersion>
that detail could be per wl_buffer, while the rest is per-wl_surface
<pq>
I think I'm done caring whether color attributes are associated with wl_surface or wl_buffer. The only differences it can make are practical wrt. other APIs. You fight it out, and let me know then, but please make sure application *too* can actually use the interfaces.
<pq>
If it's on wl_surface, applications have no problems using it. Also EGL and Vulkan have no problems setting it under the hood.
<pq>
If it's on wl_buffer, then make sure application can tell EGL and Vulkan to set what they need.
<emersion>
pq, so you're fine having some complications on the compositor side?
<emersion>
i think i'm fine with that
pym_ has quit [Read error: Connection reset by peer]
<vyivel>
any reason for wl_surface.damage{,_buffer} accepting rects one by one instead of taking a wl_region?
<emersion>
i guess it avoids creating an wl_region each time a commit is made
<emersion>
but no real reason i guess
fahien has quit [Quit: fahien]
eroux_ has quit [Read error: Connection reset by peer]
tzimmermann has quit [Quit: Leaving]
eroux has joined #wayland
* any1
didn't even know that wl_region existed until now :p
kts has quit [Quit: Leaving]
Moprius has quit [Ping timeout: 480 seconds]
<daniels>
yeah, shrug
Narrat has joined #wayland
<daniels>
it's the difference between wl_region.create; wl_region.add x $i; wl_surface.damage_region; wl_region.destroy, and wl_surface.damage x $i
<vyivel>
alright, makes sense
flibitijibibo has joined #wayland
zebrag has joined #wayland
<jadahl>
difference is that where wl_region is usually used, you replace the old region with a new, but damage just accumulates
jgrulich has quit [Ping timeout: 480 seconds]
floof58 is now known as Guest3868
floof58 has joined #wayland
Guest3868 has quit [Ping timeout: 480 seconds]
migro has quit [Quit: quit]
migro has joined #wayland
fmuellner has joined #wayland
MajorBiscuit has joined #wayland
jmdaemon has joined #wayland
mokee has quit []
Narrat has quit []
immibis has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
rv1sr has quit []
fmuellner has joined #wayland
genpaku has quit [Remote host closed the connection]
genpaku has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
MajorBiscuit has quit [Read error: No route to host]
dcz_ has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]