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
hergertme has quit [Remote host closed the connection]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Quit: Konversation terminated!]
hergertme has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
Moprius has joined #wayland
Moprius has quit [Quit: Konversation terminated!]
Company has quit [Quit: Leaving]
shankaru has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
systwi has joined #wayland
sychill has quit [Read error: Connection reset by peer]
systwi_ has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
dcz has joined #wayland
shankaru has quit [Quit: Leaving.]
shankaru has joined #wayland
hardening has joined #wayland
bittin has quit [Read error: Connection reset by peer]
bittin has joined #wayland
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
dcz has quit [Ping timeout: 480 seconds]
systwi_ has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
cool110 has joined #wayland
cool110_ has quit [Ping timeout: 480 seconds]
bittin has quit []
mvlad has joined #wayland
MajorBiscuit has joined #wayland
rasterman has joined #wayland
cool110_ has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
cool110_ has quit [Remote host closed the connection]
<pq>
haven't got to working on that yet, or any protocol bits for a year or two
<emersion>
JoshuaAshton: ^
<emersion>
i see, so a separate protocol extension
<pq>
yup, he asked me too, and I gave the same reply
<emersion>
from what i've seen, mesa just ignores the EGL hints :S
<emersion>
oh, sorry for the double-question then
<emersion>
i'll forward to the other person as well
<pq>
no prob, his fault for asking in private ;-)
<pq>
sure, because the EGL spec allows implementation to ignore practically all details it offers API for
<pq>
so if anyone cares about their YCbCr-RGB conversions, do not let EGL do that
<emersion>
so BT.601, BT.709, etc define the coefficients
<pq>
yup
<emersion>
and that's completely orthogonal to the colorspace in the WIP color management ext?
<pq>
yup
<emersion>
okay, that was a source of confusion for me
<pq>
yes, it usually is :-)
<pq>
it's a bit similar to understanding the difference between electrical and optical pixel values of RGB.
<pq>
YUV is "just" an encoding, RGB electrical values put through a matrix, so that sub-sampling U and V planes hurts less
<pq>
..hurts perceived image quality less
<pq>
and the point of sub-sampling is to reduce the amount of data one has to shovel around
<emersion>
you mean, there's a EOTF (aka gamma function) to go from electrical to optical?
<pq>
exactly
<emersion>
yea that makes sense
<emersion>
do we have any kind of "default" for these, in the absence of the future yuv ext?
<emersion>
just like we assume sRGB pre-mult alpha
<pq>
in fact, nowadays all of this is just to reduce the amount of data: sub-sampling, EOTF...
<emersion>
right
<pq>
maybe... I guess that depends on the context
<pq>
if you take any old 8-bit "just RGB" pixels in the context of desktop computers, the chances are pretty good that if you guess EOTF to be gamma=2.2 curve, the result is reasonable.
<pq>
also assuming the sRGB color space (primaries and white point) in that case, you're probably good enough - unless people have accustomed to over-saturated colors due to monitors widening the actual color volume
<pq>
for YUV-RGB, BT.601, maybe? For reasons I'm not quite sure, maybe it's the oldest or most widely implicitly used standard.
<pq>
another thing adding confusion is that many of the standards like BT.601 define multiple separate things: YUV-RGB conversion matrix, the actual RGB color space, and EOTF or similar.
<pq>
Yet another fun thing is that if you think about all this as just data compression, you might assume that if you take a signal, compress it, and then uncompress it (i.e. display it), you would get the original signal.
<pq>
That's usually false.
<pq>
The standards define one formula for compressing, another formula for decompressing, and the combination of these is some intentional signal transformation that is *not* identity transformation, not even if you ignore any precision loss.
<pq>
This is especially true with transfer functions.
<pq>
with YUV-RGB matrices I don't think I've seen this
<pq>
and with color space definitions, there can be long arguments about which numbers are the fundamental definition: the primaries and white point, or the matrix to convert *to* CIE XYZ, or the matrix to convert *from* CIE XYZ, or something else. Ideally there is no difference, but when writing values down on paper or using in computers, especially in integer pipelines, some rounding happens which makes the make
<pq>
things compouted from different sources to give different answers.
<pq>
I mean, depending on which fundamental definition you start with by assuming it accurate, all the others get slightly different values.
<pq>
squeezing all this stuff into a very limited number of integer bits is an endless source of confusion and complexity, particularly with older standards that might have never heard of, say, 10 bpc color depth.
rpigott has quit [Read error: Connection reset by peer]
<emersion>
pq, swick: maybe we should always use sized types everywhere…?
<emersion>
in our public API at least
<pq>
that would be nice
<pq>
at least when something like size_t etc. are not more appropriate
rv1sr has joined #wayland
<pq>
ffs gitlab, stop scrolling the page while I'm reading it...
fmuellner has joined #wayland
<pq>
emersion, btw. if you wanted to compact those big switch-statements like in !40, designated array initializers (or whatever you call them) might be an idea, at the cost of taking more static const data size in the binary.
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110_ has quit [Ping timeout: 480 seconds]
<emersion>
yeah, i'm not a fan of these macros
<emersion>
if it's just to save a few characters, i'd rather just write the whole thing down
<pq>
even if it's around 30 characters per line, that would allow you to align the two columns without excessively long lines, while also reducing line count to half? :-)
<pq>
30 characters less per line, some replaces with spaces for column alignment
<daniels>
for stuff like that where it trims out a lot of repetition, I'm in favour of macros because it reduces mental bandwidth to parse when reading
<daniels>
which in turn makes it harder to screw up
<emersion>
well, it's the contrary for me
<emersion>
macros are unreadable
<emersion>
an error-prone
<emersion>
and*
<emersion>
also aligning is bad
<emersion>
screws up diffs
<pq>
how does it screw up diffs?
<daniels>
tbh I think a single macro followed by 30 lines of (AUDIO, "Audio Data Block") is much more readable than 30 lines of case DI_CTA_DATA_BLOCK_AUDIO: return "Audio Data Block";
<emersion>
if you add a new member, you may need to reformat the whole block
<daniels>
when I try to read through the latter, my eyes start to glaze over
<pq>
oh, the new value thing, that depends on its name length and how much you reserved for it before
<daniels>
I think 'do not use macros' is hideous advice tbh, in the same vein that 'goto considered harmful' taught a generation of programmers that nesting conditionals 30 deep was a better idea than having a single escape route to unwind
<emersion>
the macro trick is not possible in other languages, yet we still survive somehow
<daniels>
I mean, don't write hugely overengineered macros just because you want to show how clever you are, but that advice is true in all generality, not just for macros :)
<daniels>
emersion: sure, but other languages (worthwhile ones anyway) don't make you open-code associations, they have a natural type for it
<jadahl>
emersion: *common lisp enters the chat*
<emersion>
natural type?
<emersion>
this code is exactly what i'd write in say, Go
<emersion>
i'm not sure even idiomatic Rust would be different (s/switch/match/)
<emersion>
or Python
<emersion>
you may use a map/dict in these languages to implement this, but then as said above, you can do the same in C as well
<emersion>
the kernel is a good example of bad macro usage, btw
<daniels>
I agree the kernel goes too far
<daniels>
I also don't think Go is a worthwhile language tbh :)
<emersion>
libwayland is fine, because it's reduced to the cases where absolutely necessary
<daniels>
all the downsides of C, all the downsides of not C
<emersion>
well, to each their own
<emersion>
i think Rust is on the same level of awfulness as C++
<emersion>
yet, most Go code you can find is… readable
<emersion>
the same can't be said of C or Rust
<emersion>
but oh well, maybe not a good channel for programming language discussions
<daniels>
Rust definitely requires quite a bit of work to get used to, but otoh does provide a lot of very tangible benefit, unlike C++ ...
<daniels>
but yeah, as you say, wildly OT by this point and also I really needed to leave the house about half an hour ago bye!
<emersion>
i really like libwayland overall
<emersion>
in terms of style and idioms at least
<emersion>
the macro trick for switch, i can live with it, i won't die on this hill, even if i prefer to not have it
ofourdan has quit [Remote host closed the connection]
Major_Biscuit has quit [Ping timeout: 480 seconds]
<pq>
putting such big switches into a function of its very own is something I favor regardless of the switch style
<pq>
being able to do 'case x: return y;' is neat and tidy
<emersion>
agreed
ofourdan has joined #wayland
<ManMower>
I like original.c the best
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
adia has quit [Quit: Ping timeout (120 seconds)]
<vsyrjala>
what's the point of a macro when you don't even stringify?
cool110_ has joined #wayland
adia has joined #wayland
<pq>
it's in the eye of the beholder
bindu_ has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
bindu has quit [Ping timeout: 480 seconds]
<jadahl>
pq: not that I see the library being translated, but the _ macro would conflict with common translation macros in C
<pq>
yay for using non-namespaced stuff in public API
<pq>
but ok, just use anything else
<ManMower>
jadahl: that absolutely occurred to me too. :)
<ManMower>
but yeah, just use a slightly different macro and that complaint goes away
<jadahl>
yea, not making it look like gettext magic would be better
<pq>
I've used CASERET() before, and I have never seen gettext used at all
<jadahl>
as a side note, translated errno messages is annoying, maybe we should translate all error messages so they at least match the errno messages?
<jadahl>
/s fwiw
<ManMower>
I don't see big savings, but will concede that it doesn't hide the strings from grep in a painful way, since if I'm grepping for DI_CTA_DATA_BLOCK_AUDIO I really don't care if I miss that particular site
<pq>
grep is a good counter-argument to using ##
<jadahl>
well it does hide it in a slightly annoying way
<daniels>
no-one doing any work today huh :P
<emersion>
what do you mean ranting about C isn't important work?
<ManMower>
this bikeshed clearly needed my fingerprints in the paintwork.
<ManMower>
this is the kind of thought leadership my employer values at performance review time.
Company has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
<swick>
well, we were about to add that stuff to the CM protocol
fmuellner has quit [Ping timeout: 480 seconds]
<pq>
not much different than what emersion did now
<pq>
I might have kept it in the same XML file as color management, or make a new file to allow it to land sooner.
shankaru has joined #wayland
fmuellner_ has quit []
fmuellner has joined #wayland
cvmn has joined #wayland
fmuellner_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
cabal704 has joined #wayland
devilhorns has quit []
devilhorns has joined #wayland
devilhorns has quit []
devilhorns has joined #wayland
mclasen_ has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
<pq>
emersion, welcome to the world of color protocol design! Good night! ;-)
<emersion>
;_;
<pq>
so many standards to choose from
<emersion>
"it should be pretty simple" were my thoughts when i started writing this
<pq>
that's how we all start
<pq>
implementing this spec in our compositors is going to be fun too, and writing the tests to ensure we get it right
devilhorns has quit []
<pq>
I'm going to let you file the Mesa bugs, I'll just disable direct import to EGL in Weston. :-P
<emersion>
i intend to use vulkan
<pq>
ooh, nice. Does it actually require correct operation, unlike the EGL extension?
<i509VCB>
Might be unrelated to the color protocol, graphics apis like vulkan encode the layout of the format with the format code. How would I know whether the client has given me srgb, unorm, snorm, whatever else? Or would the color api partially solve that problem?
<emersion>
maybe we could have an EGL ext which guarantees the hints are used
systwi_ has joined #wayland
<emersion>
i509VCB: i use SRGB, but people are already complaining about it
<pq>
I'm unfamiliar with Vulkan, so I'm not sure what those are in that context.
<emersion>
pq, gamma-encoded or gamma-decoded values
<emersion>
i think?
<i509VCB>
There is also the issue that not every vulkan format has a variant with an srgb numeric type
<emersion>
i don't remember the "correct" wording for this
<pq>
ah, so electrical vs. optical? or in practise, compositor blending in linear or non-linear?
<emersion>
pq, explicit YCbCr conversion metadata is required if the format is YCbCr
<emersion>
pq, yes
systwi has quit [Ping timeout: 480 seconds]
<pq>
emersion, not really, we already decode YCbCr, just with some arbitrary implementation defined defaults. We can't make that illegal, it would be a regression breaking old clients.
<emersion>
i mean, for vulkan
<pq>
ah?
<emersion>
it's an error to use a YCbCr format without providing YCbCr metadata
<emersion>
in vulkan
<pq>
i509VCB, all pixels in Wayland are non-linear unless some Wayland extension says otherwise. The default non-linearity is undefined, but can be assumed to be sRGB EOTF.
<emersion>
pq, where would be a good place to document this?
<emersion>
hm, i think i already asked and the answer was "nowhere" :S
<pq>
color-and-hdr I guess, if not the Wayland docbook
<pq>
but really it's all undefined and driven by practise and accidents until an extension defines it
<pq>
we can only document what the stuff *usually* is unless otherwise spec'd
zebrag has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
<i509VCB>
So if I wanted to support something like VK_FORMAT_A2R10G10B10_<numeric-type>_PACK32 to allow Bgra1010102 (no SRGB for these formats) I'd have to convert unless some protocol explicitly states the linear encoding is fine?
MajorBiscuit has quit [Quit: WeeChat 3.5]
cool110_ has quit [Remote host closed the connection]
cool110 has joined #wayland
rv1sr has quit []
shankaru has quit [Quit: Leaving.]
rv1sr has joined #wayland
ahartmetz has joined #wayland
dnkl_ is now known as dnkl
sychill has joined #wayland
emery has quit []
emery has joined #wayland
Seirdy has joined #wayland
Moprius has joined #wayland
andyrtr has quit [Read error: Connection reset by peer]
andyrtr has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
fmuellner_ has quit [Remote host closed the connection]