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
jmd has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold__ has joined #wayland
shsharma_ has joined #wayland
busheling has quit [Ping timeout: 480 seconds]
busheling has joined #wayland
shsharma has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fvok4 has joined #wayland
rg has joined #wayland
rg has quit []
molinari has quit [Ping timeout: 480 seconds]
bookworm_ has joined #wayland
bookworm has quit [Read error: Connection reset by peer]
agd5f_ has joined #wayland
julio7359 has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
ukiran has joined #wayland
ukiran1 has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
barrett has quit [Ping timeout: 480 seconds]
rcampbell has quit []
BlkPoohba has joined #wayland
julio7359 has quit [Remote host closed the connection]
julio7359 has joined #wayland
realivanjx5 has joined #wayland
realivanjx5 has quit []
realivanjx5 has joined #wayland
realivanjx has quit [Ping timeout: 480 seconds]
floof58 has quit [Remote host closed the connection]
<ukiran>
As per my understanding about the CICP H.273 doc, CP/TC/MC these will be used to decode the colorspace of the incoming pixel buffer to the output color space
<ukiran>
The input pixel format could be anything, but what matters is color space. CICP codepoints helps in mapping the color space right ?
<JEEB>
it describes what the samples mean, yes
BlkPoohba has quit []
<ukiran>
as per the Annex-1 diagram in my link, if the pixel format is RGB, then it does the colorspace mapping based on the input and output (Depends on the compositor selection)
BlkPoohba has joined #wayland
<ukiran>
If it is YUV, we need to do the conversion first to RGB, then do the color space mapping
<JEEB>
yes if your compositor does not support YCbCr
<JEEB>
or well, doesn't support direct output of YCbCr
<ukiran>
Usually all primary planes supports YCbCr.. in that case, for colorspace mapping, dont we need to convert to RGB
<ukiran>
?
<JEEB>
I know YUV is utilized in various APIs, but technically YUV was only in analog :D
<JEEB>
including FFmpeg's APIs which still call it yuvxyz
<ukiran>
Okay.
<JEEB>
anyways, for YCbCr passthrough if you now know of CICP/H.273 you then need to check which matrix, primaries and transfer the output thing supports
<JEEB>
otherwise if you don't check the device might support only BT.709, yet then you push BT.2020 YCbCr to it :D
<ukiran>
let me put an example, have a req where the input's format YUV420P10 in Bt.709 colorspace. Monitor supports Bt.2020 and the clients wants to map this the output's gamut.
<JEEB>
in CICP you need to define the holy triplet for both sides
<JEEB>
matrix, primaries and transfer
<ukiran>
What does the compositor's triplet in this case
<ukiran>
i can read the triplet from the AVCodec's API from client
<JEEB>
compositors usually do two things: they either attempt to pass-through, or they do something like conversion to floaty linear RGB and then to the output triplet
<JEEB>
also you did not define the triplet for that "monitor supports BT.2020"
<JEEB>
that could be primaries for RGB, in which case you have not defined the transfer. it could also mean YCbCr where matrix and primaries are BT.2020-NCL, and in this case as well you have not defined the transfer.
<ukiran>
could you please elaborate on "also you did not define the triplet for that "monitor supports BT.2020""
<JEEB>
I noted two common alternatives :P
<JEEB>
and how you left out transfer
BlkPoohba has quit []
<JEEB>
not sure if it helps your understanding, but what I commonly see with macOS and Windows regarding compositors you have the following: { application surface triplet } - { compositor that converts from input triplet to floaty linear scRGB when required } - { monitor output triplet }
BlkPoohba has joined #wayland
<ukiran>
am trying to understand. what you mentioned is the stages involved from app to the display right
<ukiran>
i know the application surface triplet. Ex: yuv420P10le(tv, bt709/bt09/arib-std-b67)
<JEEB>
and there you finally said out loud the transfer :P
<pq>
zubzub, Mesa needs to still do some throttling even without framecallbacks to not need an enormous pool of buffers to draw into. The sync make any wl_buffer.release and equivalent events more likely to come back to Mesa before it spams a new buffer.
<pq>
ukiran, no-one that I know of yet.
<JEEB>
ukiran: please do not PM me
<ukiran>
JEEB, sure
<ukiran>
pq, we are planning to work on server side
<ukiran>
so am getting better understanding on the CICP usage.
<pq>
zubzub, I didn't think the serial from wl_display.sync replies is good for anything... it comes from an era when serials had a flawed design.
<pq>
ukiran, JEEB, btw. DRM KMS is incapable of direct YCbCr output. There will always be full-range RGB in the middle, even if both framebuffers and monitor signal were YCbCr.
<pq>
they are likely different YCbCr, too
<ukiran>
pq, so the conversion is needed from YUV to RGB in the middle ?
<JEEB>
pq: at least I've looked at people who accidentally had YCbCr advertised in the output lol. good to know that that's not a feature
<emersion>
JEEB: it is but gets converted to RGB but the hw
<emersion>
by*
<JEEB>
no I mean like the HDMI connection being YCbCr
<emersion>
yeah, that too
<ukiran>
emersion, though the planes/CRTC supporting ycbcr, there would be a conversion by the HW before display ?
<emersion>
source YUV -> RGB -> YUV -> monitor
<emersion>
it's just that the RGB in the middle can't go away
<emersion>
ie, *direct* YUV not a thing
<pq>
JEEB, what do you mean "advertised"?
<JEEB>
metadata on the display connection
<JEEB>
HDMI/DP
<pq>
JEEB, HDMI signal can well be YCbCr with DRM KMS, and it won't tell us if it is.
<JEEB>
this was mostly people accidentally getting that with some AMD mesa drivers etc
<pq>
it's all negotiated between the driver and the monitor, not telling userspace what it picked
<pq>
JEEB, the metadata is also, well, a broken story.
Leopold___ has joined #wayland
<pq>
JEEB, currently if a KMS driver exposes "Colorspace" connector property, userspace can set that to RGB while the driver is sending YCbCr, and any other nonsense or correct combination of metadata vs. actual signal.
<pq>
Harry Wentland et al. are looking to fix that.
<pq>
the gist being that userspace cannot set it guaranteed right, because it makes a difference between RGB and YCbCr and userspace cannot know which one the driver picked.
<JEEB>
nice
<pq>
userspace also cannot control which one the driver picks
<ukiran>
pq, means though we set the pixel format of ycbcr on the plane, HW does the conversion to RGB ?
<ukiran>
before it display ?
<dottedmag>
pq: is this RGB-in-the-middle pretty much unfixable at this stage, or can be fixed without too much pain?
<pq>
ukiran, yes, the KMS color pipeline will do *some* conversion to *some* RGB which may or may not be what you wanted.
pochu has joined #wayland
<pq>
ukiran, and the KMS color pipeline will also then convert from RGB to YCbCr if that is what the kernel driver chooses to send to the monitor.
<ukiran>
Revathi@1990
<ukiran>
sorry.. wrong window
<pq>
dottedmag, it is a built-in assumption into how KMS color pipeline works. It's not unfixable, but fixing it probably means throwing all existing color related KMS properties out.
<pq>
the latter will take days or more to go through, but I think it is very much worth it
<pq>
ukiran, you need to build an understanding of how color is encoded, and what those encodings are actually anchored to (the concept of the CIE 1931 2-degree observer). Then it becomes much more clear on what, how and when to convert and what you actually need to know to able to do any of that.
<pq>
it's not absolutely necessary if you want to just follow pre-made recipes, but it helps in making sense of everything
<pq>
An important thing to remember, using CICP words, is that MatrixCoefficients would be BT.601, ColourPrimaries could be BT.709, and TransferCharacteristics could be from a third spec.
<pq>
*could be
<JEEB>
yea
<pq>
ukiran, yes, you can. That's a good diagram, generic for many but not all conversions. It does not work for constant-luminance MatrixCoefficients encodings, and PQ and HLG systems may add more details.
<ukiran>
for constant luminance, there is another diagram Figure-2 in the same doc
<pq>
ukiran, it is also a conversion from input to output. It does not enable composition alone.
<pq>
right
Major_Biscuit has quit [Ping timeout: 480 seconds]
<ukiran>
pq, "it does not enable composition alone" --> meaning w.r.t format conversion ?
<ukiran>
normalized RGB colour signals EREGEB (Rec. 709) to
<pq>
composition requires not only format conversion but also fitting the color gamut and dynamic range of the different inputs into a single reference
rasterman has joined #wayland
<pq>
If you want to do alpha-coverage blending, that needs to be done in optical color values (tristimulus).
fmuellner has joined #wayland
<pq>
I guess one can get far by just doing the format conversions properly into a single common format, and composite there, but I feel it is eventually going to need something more.
<pq>
depends on what such "format conversion" actually means
<ukiran>
okay
kts has joined #wayland
<pq>
I didn't check what BT.2087 does with e.g. the color gamut. Color gamut can be handled in various different ways depending on what the goals are. This is what ICC calls "rendering intents".
<pq>
A pure format conversion would not do color gamut or tone mapping, which means that the original colorimetry is preserved. Whether you actually want that or not depend on where the result will be used.
<pq>
With entertainment like video and games, you probably want to do some kind of re-mapping there to make the picture look "better".
<ukiran>
pq, am trying to understand the steps involved during this color mapping w.r.t cicp code points
<ukiran>
client read the cicp points from the video file, and the server has exposed the supported points through Imagedescription as per the protocol.
d__ed has quit [Ping timeout: 480 seconds]
<ukiran>
once the points matched, client will set the image description with the set_image_description() call.
<ukiran>
client video contains the triplets : yuv420p10le(tv, bt2020nc/bt2020/smpte2084, progressive)
<ukiran>
Monitor is normal monitor supports sRGB/Bt.709 color gamut
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
<pq>
ukiran, what is your question?
kts has quit [Quit: Konversation terminated!]
Dami_Lu has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
<pq>
ukiran, since your content is WCG HDR and your monitor is "normal" color gamut and SDR, you will necessarily also need some form of color gamut and tone mapping to squeeze the content into the tiny color volume of the monitor.
<pq>
a plain format conversion, even correctly done, likely won't look good enough
<ukiran>
my question is what are the steps involved in order to apply the CICP triplets here ?
Dami_Lu has quit [Ping timeout: 480 seconds]
<pq>
The first step is to understand what each element in each triplets means.
<pq>
They are not operations.
<pq>
Instead, they describe how the pixels were or need to be encoded.
<pq>
You need to decode the input image, apply any appropriate gamut and tone mapping, and then encode for the monitor.
<pq>
the video triplet describes the input encoding, and the monitor triplet describes the output encoding
<ukiran>
bt2020nc/bt2020/smpte2084 --> this actually tells how the pixels are encoded in the given file
<pq>
It gives the color encoding, yes. You need other things as well to actually interpret the binary data.
<pq>
pixel format, quantization range, chroma siting
<ukiran>
Okay.
<pq>
and if we are talking about actual *files* and not images in RAM, then those are compressed as well with codecs and whatnot, but that's irrelevant to Wayland.
<pq>
so far we only have Wayland protocol for carrying uncompressed 2D images
Dami_Lu has joined #wayland
<pq>
width, height, stride, pixel format & modifier - these are the starting point for color decoding using quantization range, chroma siting (YUV only), MatrixCoefficients, TransferCharacteristics, ColourPrimaries.
<pq>
The result from those is an image in some arbitrary (your chosen) tristimulus triplets.
<pq>
Then you have to do color gamut and tone mapping, which are more of an art than science.
<pq>
If you are compositing, do that at this point.
<pq>
Then encode the result according to a similar set of monitor parameters.
<ukiran>
do we display the pixel by encoding on the monitor ?
<pq>
The video signal sent to a monitor is necessarily encoded in a way the monitor uses it.
<pq>
Otherwise you don't get what you want on screen.
<pq>
IOW, you must encode the image in the exact way the monitor expects it, or will show up wrong.
<ukiran>
encoding means the pixel format encoding like yuv420, yuv422, argb2101010, etc
<pq>
encoding includes pixel format, quantization range, chroma siting, MatrixCoefficients, TransferCharacteristics, ColourPrimaries
<pq>
it's the exact same list, always, for content, monitors, whatever.
<ukiran>
okay.. i think i get what you say.
<pq>
and it *all* is needed to be known in order to understand what the colors are
<ukiran>
Thanks for the detailed information. will do some more home work to understand these things better
<pq>
You could also have "CIE 1931 XYZ for the 2-degree standard observer" but as a color encoding that is quite wasteful, hence not used for transmission or storage.
kts has joined #wayland
<pq>
ukiran, color-and-hdr repository also has a small glossary, FWIW.
<zubzub>
ugh SDL doesn't seem use the frame callback to throttle and instead seems to use it's own internal timer <o>
<zubzub>
the only way to make it throttle is to delay the display sync callback
<pq>
that may be wise, because apps written on SDL probably do not expect at all the frame callback semantics
<pq>
we've been talking that Mesa EGL should probably do the same if it could
<zubzub>
could do what? throttle on display sync or frame callback?
<pq>
to stop using frame callbacks for throttling
<pq>
because apps simply cannot handle eglSwapBuffers blocking indefinitely
<pq>
apps expcet that swap interval 1 means a steady pace regardless of whether the window is visible or not.
<zubzub>
what if the compositor can't handle the rate at which the app is committing?
<pq>
there is a bug open about that in... Wayland, was it?
<pq>
zubzub, then the app dies on overflowing its socket. Which the wl_display.sync helps avoid.
<pq>
any way, a compositor handling a wl_surface commit should be very very quick
<zubzub>
ok looks like I just need to change my entire backpressure architecture, no biggy
<pq>
how did you do backpressure if not by controlling wl_buffer.release events?
<zubzub>
frame callback
<pq>
that's not backpressure, is it?
<pq>
frame callbacks are a different mechanism for clients that are prepared to make use of it.
<zubzub>
sure by neither is buffer release or display sync
<zubzub>
I can an SDL game at 60fps on a 30Hz monitor
<pq>
buffer release is, though?
<zubzub>
it mighty implicitly do that if the client allocates a fixed number of buffers
<pq>
Unfortunately, EGL, SDL and other "game toolkits" kind of things are not that.
<pq>
yes, that's the definition of backpressure, right?
<zubzub>
in my case the buffer is only needed for like 1ms, but the rest of the commit can take anything from 5ms to 50ms
<pq>
both EGL and Vulkan work on fixed size buffer pools AFAIK
<zubzub>
anyway so I have to queue buffer releases (not because I'm using them, but to keep the client from using them) if the client is committing too fast
<zubzub>
that all still sounds very much like abusing side effects for what the protocol was intended to do
<pq>
yeah, and frame callbacks is what the clients should listen, but instead they would just break if it doesn't fire at a fixed rate, so a timer they use.
d___ed has left #wayland [#wayland]
barrett has joined #wayland
d_ed is now known as Guest7688
d_ed has joined #wayland
<pq>
The problem of not using frame callbacks is indeed the question of the frequency and phase of the timer. Presentation-time feedback could help there, if client libs used it.
<zubzub>
would be nice if I could just tell them at what rate (and by able to change the rate at will)
<pq>
yes, that's in the presentation-time feedback event
<pq>
good luck finding anyone who listens for it, thoguh
<pq>
d_ed, thanks, that was probably the link I was thinking of.
ukiran has quit [Ping timeout: 480 seconds]
barrett has quit [Remote host closed the connection]
<kennylevinsen>
well, there isn't technically anything wrong with SDL using its own timer, it's just silly if it wanted frame callbacks
<d_ed>
it does also do something with framecallbacks
<zubzub>
rendering @60FPS on a 30Hz monitor is imho a bit silly
<kennylevinsen>
committing at arbirtrary times and arbitrary rates is fine, frame callbacks are just one way to voluntarily throttle. There isn't normally any backpressure there - a client can commit at 1000 fps, and all commits get accepted (and immediately superseded)
<kennylevinsen>
granted, for most applications, frame callbacks fit the bill and is superior to what they currently do, but it is voluntary
Leopold has joined #wayland
Leopold___ has quit [Remote host closed the connection]
<JEEB>
mpv went through a few iterations on how it attempted to time video rendering on wayland
<d_ed>
Qt's situation is quite complex too to handle all clients, and it's still not perfect
<d_ed>
the fallback timers we need to have for the few bad clients end up interfering with our well behaved clients
<zubzub>
kennylevinsen: in my case it's commit latency. A commit is handled in like 8ms but there might be 50ms latency before it is shown on screen, I can't make the commit block, or the app would run at <20FPS instead of 60FPS
<d_ed>
SDL currently appears to do the following: if there's a frame block locally and wait for a framecallback, but after an arbitrary timeout commit and proceed anyway
<kennylevinsen>
zubzub: hmm, most compositors do not really do anything on commit, only when the output needs to render
<zubzub>
I have a weird compositor
<zubzub>
network and video and stuff
<daniels>
that's an understatement
<kennylevinsen>
there must be room for those as well
<kennylevinsen>
but throttling rendition could still be a good idea
<zubzub>
anyway, I guess the buffer release abuse that pq suggested might make it work
<pq>
weeelll...
<pq>
it might also multiply the latency from draw to screen
<pq>
or would it...
<pq>
depends on how you throttle those releases vs. which image you use
<zubzub>
it would force the app to only start drawing on frame callback (because coincidentally only then it's other buffer becomes available)
<pq>
the pool side in Mesa EGL is IIRC 4
<pq>
*size
<kennylevinsen>
I have a few clients that would wait for buffer release, but I assume other clients might just allocate more buffers and get mad once the number went above N where N is some single-digit number...
<pq>
the max pool size should never be less than that, because then it might start limiting framerate in some conditions
<pq>
under the usual operating environment, that is
<pq>
so you would need to keep all 4 buffers reserved until you are ready to let the client proceed and release one of them
<zubzub>
kennylevinsen: yeah that's also what I fear will happen
<pq>
anyway, you are trying to force clients behave in a way they have simply not been written to behave
<pq>
I doubt it can end up well.
<pq>
clients are allowed to be wasteful, maybe they have a good reason to not throttle, or maybe they do
<pq>
*don't
<zubzub>
sure, I'm just dissapointed that a display sync is [ab]used as a compositor paint fence just because [most] compositors just happen to work that way
<pq>
what's a paint fence?
<zubzub>
like a wait for compositor to signal me it has painted what I committed
agd5f has joined #wayland
<pq>
no, it definitely does not do that
<pq>
The sync request is only used to ensure that the compositor has processed the previously sent requests, which is the definition of the sync request.
<zubzub>
well SDL seems to use it that way I noticed
<pq>
didn't you say SDL uses a timer?
<zubzub>
pq: yes that's what it's supposed to used for
<zubzub>
I throttles down if the dispay sync is later
<pq>
and is it SDL or is it eglSwapBuffers from Mesa with swap interval 0?
<zubzub>
that I don't know
<zubzub>
I just happen to have tested with supertux and tuxracer :p
<pq>
Mesa does that, and the whole point there is to ensure the compositor has seen the previous requests.
<pq>
Because if the previous requests might have released some buffers, then Mesa would be sure to have seen the release events by the sync returns.
<pq>
There are expectations that wl_display.sync replies ASAP, unlike with wl_buffer.release or frame callback.
agd5f_ has quit [Ping timeout: 480 seconds]
<pq>
So delaying sync replies is very much unexpected, and if you do that, you would break the games that could not use the frame callback to begin with.
<zubzub>
I'm not advocating or trying to do that! (not sure where I might have said that either)
<pq>
I mean, no-one uses sync as a "compositor paint fence".
<zubzub>
well implicitly they do no? If the app starts rendering as soon as there is a buffer and the sync callback is fired?
busheling has quit [Read error: Connection reset by peer]
busheling has joined #wayland
<zubzub>
aaanyway, I have to figure out how to deal with this first :)
<pq>
it's not a "compositor paint fence", it says nothing about compositor's painting
<zubzub>
I know, I worded it badly
<pq>
it's only purpose is to make sure the compositor is keeping up with the commits
<zubzub>
yes I know that :)
<pq>
alright
<zubzub>
what I was trying to say is that just because a compositor can keep up with the rate of commits, doesn't mean it can keep up with rendering or state updates of an app.
<zubzub>
and that a sync & callback is used by apps because most compositors are single threaded and all these updates happen in the commit and as a side effect the sync callback is only fired *after* the compositor has done all the work
MrCooper has quit [Ping timeout: 480 seconds]
<pq>
a compositor is expected to *not* render on commit
<pq>
a compositor renders whenever it feels like, but definitely not as a part of handling a wl_surface.commit request
<pq>
a compositor is expected to discard frames when a client commits frames more often than frame callbacks would imply
kts has quit [Quit: Konversation terminated!]
<pq>
Also window state updates do not need to be put into use immediately on commit, no. They do need to be accumulated, though, so that when a compositor decides to use a new set of state, the set is complete.
<zubzub>
a frame being the render result of state that was committed (potentially too fast)
<pq>
so don't render that on commit, render it on your own time
<pq>
using the latest committed buffer and state you have
MrCooper has joined #wayland
<zubzub>
ugh
ukiran has joined #wayland
<zubzub>
I think I'm just going to become a goat farmer or something
<kennylevinsen>
... fast forward to having to throttle goat grass consumption
ukiran1 has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
ukiran has joined #wayland
ukiran1 has quit [Ping timeout: 480 seconds]
<MrCooper>
zubzub: forcing clients to wait for frame callbacks like that will prevent some of them from sustaining full frame rate
<MrCooper>
(coincidentally, Mesa's EGL Wayland platform code accidentally did just that until this week)
cwittlut has quit [Quit: _]
cwittlut has joined #wayland
cwittlut has quit []
cwittlut has joined #wayland
<JEEB>
oh right, one thing I noticed regarding CICP/H.273. there is actually a document regarding their usage :D
caveman has quit [Remote host closed the connection]
agd5f_ has joined #wayland
caveman has joined #wayland
kts has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
<pq>
JEEB, oh right, the supplements. When I re-write well_known.rst, I had in mind to use spec links where one can also find the supplements and not just the spec itself.
agd5f_ has quit []
agd5f has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
rv1sr has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
kts has quit [Quit: Konversation terminated!]
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #wayland
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
fmuellner_ has joined #wayland
agd5f_ has joined #wayland
jmdaemon has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #wayland
DodoGTA has quit [Remote host closed the connection]
DodoGTA has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
<DemiMarie>
Is there a reason that Mesa on Wayland only supports 2 of the 4 Vulkan display sync options?
DodoGTA has left #wayland [#wayland]
DodoGTA has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
devilhorns has quit []
<kennylevinsen>
some of the others imply tearing, no?
<kennylevinsen>
and so it requires the tearing protocol
DodoGTA has left #wayland [#wayland]
<emersion>
missing features in the wayland protocol, DemiMarie
DodoGTA has joined #wayland
agd5f_ has joined #wayland
<DemiMarie>
emersion: are those being worked on?
<emersion>
not actively
<emersion>
there are multiple opened MRs for presentation protocols
<zamundaaa[m]>
emersion: on the topic of tearing... is there any progress on the kernel side?
<zamundaaa[m]>
All this stuff in userspace ultimately barely matters if atomic modesetting doesn't support it
<emersion>
i'm wondering whether the kernel side really makes sense
<emersion>
if the kernel API restricts to primary plane FB_ID and nothing else, then… there's no real benefit
<emersion>
restricts as in only allows the atomic commit to contain FB_ID
<emersion>
and no other prop
<zamundaaa[m]>
that would definitely not be good
<emersion>
my last email explains why it's tricky to allow other props even if they don't change
<emersion>
we'd need to rework the kernel internals quite a bit to fix it
<zamundaaa[m]>
The reason that the early fail is desired is that that i915 doesn't do the proper checks itself, right? How hard would it be to fix that?
<emersion>
drivers would need to check each property one by one
<emersion>
and not forget to expand the check once a new property is added
<zamundaaa[m]>
sure, but then the API wouldn't be limited to what the most restricted hardware can do