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
pseigo_ has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Arnavion has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
cabal704 has quit [Quit: WeeChat 3.5]
pseigo_ has joined #wayland
pseigo_ has quit [Ping timeout: 480 seconds]
pseigo_ has joined #wayland
pseigo has joined #wayland
pseigo_ has quit [Ping timeout: 480 seconds]
pseigo has quit [Ping timeout: 480 seconds]
pseigo has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Ping timeout: 480 seconds]
txtsd is now known as Guest3894
txtsd has joined #wayland
Guest3894 has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
cabal704 has joined #wayland
Company has quit [Quit: Leaving]
cabal704 has quit []
shankaru has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
dcz_ has joined #wayland
dcz has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
systwi_ has quit [Ping timeout: 480 seconds]
pseigo has quit [Quit: left]
pseigo has joined #wayland
tzimmermann has joined #wayland
mvlad has joined #wayland
hardening has joined #wayland
jgrulich has joined #wayland
Lucretia has quit []
Lucretia has joined #wayland
WhizzWarlock has quit []
WhizzWr has joined #wayland
ppascher has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
slattann has joined #wayland
bittin has quit [Read error: Connection reset by peer]
bittin has joined #wayland
hardening_ has joined #wayland
pseigo has quit [Quit: left]
mbalmer has joined #wayland
pseigo has joined #wayland
rasterman has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
<pq>
emersion, I'm still waiting for someone to associate PQ TF with French for "toilet paper" ;-)
<pq>
swick, what do you mean going from linear to HLG does not need parameters? The monitor will apply the parametrized HLG EOTF, so if we want to convert PQ to HLG in any luminance controlled way, don't we need to invert exactly what the monitor does?
<pq>
(I picked my nick some time in the mid 90s :-)
<MrCooper>
visionary
<pq>
hwentlan, yeah, like swick says, you can choose whether you gamut/tone-map before or after blending with different implications.
<pq>
emersion, thank you for the release!
<pq>
MrCooper, more like a phonetic encoding of my IRL nick name which is a shorter form of my real first name. In the context of Finnish, of course. :-)
<pq>
swick, hwentlan, AFAIU pre-defined HLG TF is fine if you don't care about absolute luminance, which is kinda sorta the opposite of the idea of PQ. But of course the idea PQ to display absolute luminance doesn't work in general environments, and HLG acknowledges that.
<pq>
I've actually been thinking about using "the HLG OOTF" to tone-map PQ content to the monitor at hand, and see how that looks.
<pq>
there's some nice theory and studies behind the HLG OOTF
<pq>
while for a PQ system the tone-mapping that a must happen anyway is *shrug*
<pq>
emersion, my suggestion is to make the BT.2020 case be specifically the non-constant luminance one, and simply leave the constant luminance option out for now.
<pq>
that way all of bt601, bt709 and bt2020 can be implemented the same way without difficult questions.
<emersion>
cool, thanks, then let's do that and see what others think
txtsd has joined #wayland
<pq>
the important part is to explicitly say bt2020 non-constant luminance, which is something most other APIs forget to say at all
<emersion>
do you think it's worth it to mention in the enum entry name?
<emersion>
like bt2020_non_const_luminance
<emersion>
?
<jadahl>
dynamic_luminance?
<pq>
yes, in some way
<pq>
jadahl, nope :-)
<jadahl>
:(
<emersion>
nice try :P
<emersion>
any other suggestions for the shed color?
<jadahl>
orange
<emersion>
ship it!
<pq>
non-constant just means that the Y channel encoding is not the same regardless of what RGB combination gives the total luminance
maxzor_ has quit [Ping timeout: 480 seconds]
<pq>
if you want to find luminance, you have to first linearize R, G and B before you can compute their weighted average. This is what the constant luminance variant does.
<pq>
while the non-constant luminance variant does not bother with linearizing, so the result is not the same
<pq>
sorry, weighted sum rather than average
<pq>
BT.2020-2 uses the term "non-constant luminance", it the enum value could be e.g. bt2020_nc
<pq>
if you want the shortest possible
<pq>
bt2020_nonconst would be fine too
systwi has joined #wayland
devilhorns has joined #wayland
slattann has quit [Ping timeout: 480 seconds]
mclasen_ has joined #wayland
slattann has joined #wayland
fmuellner has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
maxzor_ has joined #wayland
slattann1 has joined #wayland
slattann has quit [Ping timeout: 480 seconds]
<emersion>
i see
mclasen_ has quit []
nerdopolis has joined #wayland
pseigo has quit [Ping timeout: 480 seconds]
andyrtr has quit [Read error: Connection reset by peer]
andyrtr has joined #wayland
mclasen has joined #wayland
pseigo has joined #wayland
shankaru1 has joined #wayland
shankaru1 has left #wayland [#wayland]
<pq>
MrCooper, eh heh, looks like the legacy gamma LUT ioctl has no way to indicate "no LUT". I'll have to explicitly create an identity LUT to load that.
shankaru has quit [Ping timeout: 480 seconds]
<swick>
pq: the point here is that HLG is designed to adjust the luminance in the EOTF so we don't want to undo that when going from linear to HLG
<swick>
if you want to go from PQ to HLG "all" you have to do is find a matching signal level
<pq>
IOW, you want the compositor to work in relative luminance?
<swick>
well, if you're in HLG mode you have to
<pq>
not if you invert what the monitor does
<swick>
but you can't do that because you don't know what it does at any moment in time
<pq>
yes, we do: HLG spec defines the OOTF, and theoretically we should be able to find the absolute luminance range
<swick>
you know what it does in theory, which allows you to match the signal levels but it doesn't tell you what adjustment it makes in practice
<pq>
it's just the same problem we have with PQ monitors, just a little less undefined since the OOTF is defined
<pq>
relative luminance is probably a good idea for most consumer use cases, but I don't think that there would not be use cases where absolute luminance is desired.
<pq>
FWIW, even when we have PQ content and PQ monitor, I would try to use HLG OOTF for tone-mapping and see how well that works.
<pq>
speaking of which, I've been idly wondering why taking photos in hard sunlight makes the photos... look like hard sunlight. Is the censor running out of dynamic range, or is it an artifact from saving SDR sRGB images.
<pq>
...must be the sensor, otherwise it would just work by now
pseigo has quit [Quit: left]
pseigo has joined #wayland
<vsyrjala>
pretty sure i had a patch somewhere to add constant luminance bt.2020 to the kms color encoding enum, but no takers at the time so it didn't go in
<pq>
vsyrjala, sounds like it's not popular?
<pq>
oh, there is not even bt.2020 non-const either
<swick>
pq: PQ is encoded for one specific environment and that gets magically converted to the actual environment, HLG is signal without environmental adjustment and it's added in the display. Other TFs usually also are for a specific environment and then change the EOTF to compensate to the actual environment.
<pq>
I always look at drm_info output, because KMS docs rarely list the possible values
<swick>
pq: it's only in source based tonemapping scenarios where we actually have to compensate for the environment and have absolute luminance
<swick>
but that kind of includes PQ sometimes because of how it's actually implemented for Windows/DisplayHDR reasons
<pq>
swick, yes
<pq>
aren't some laptop panels effectively SBTM already?
<swick>
gtg, brb
wvanhauwaert has joined #wayland
Net147 has quit [Quit: Quit]
<wvanhauwaert>
kms
Net147 has joined #wayland
<wvanhauwaert>
woops, sorry about that one. I was actually attempting to search in the history :-) does somebody know if there is some default colour correction done on imx53 (a2xx) kms driver? I don't know where to look for it?
<pq>
wvanhauwaert, I'd probably take a look with drm_info first, but that won't show things the driver might do without exposing to userspace.
tanty has quit [Quit: Ciao!]
tanty has joined #wayland
<swick>
pq: I'm not sure… internal panels are just the wild west. at least the brightness control seems to be in absolute luminance and I've heard that some are apparently SBTM without ever having anyone confirm that
pseigo has quit [Ping timeout: 480 seconds]
<wvanhauwaert>
thing is, I don't know very little about the internals. But we have a wpewebkit running on wayland, on mesa, on drm, on a2xx. But we need to make sure that, when we put a rgb value to a pixel, it's exactly this one coming on the display port
<wvanhauwaert>
so there may be no correction whatsoever
<pq>
wvanhauwaert, you get audit everything then. FWIW, the kernel devs are more on #dri-devel.
<pq>
incidentally, I am right now writing Weston patches to make sure there is no unexpected color modifications done in KMS by left-over KMS state.
cabal704 has joined #wayland
rgallaispou has joined #wayland
<wvanhauwaert>
in weston itself? I thought weston was not altering colors?
Company has joined #wayland
<pq>
wvanhauwaert, exactly. Weston is not overwriting all KMS state that exists, so left-over state in KMS in the kernel can change things.
rgallaispou1 has quit [Read error: Connection reset by peer]
<pq>
KMS state is persistent between all userspace processes and fbdev when you switch between them, unless you explicitly go out of your way to program everything yourself
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
devilhorns has quit []
bittin has quit [Remote host closed the connection]
bittin has joined #wayland
jgrulich has quit [Remote host closed the connection]
maxzor__ has joined #wayland
pseigo has joined #wayland
wv has joined #wayland
wvanhauwaert has quit [Remote host closed the connection]
pseigo has quit [Ping timeout: 480 seconds]
cabal704 has quit [Remote host closed the connection]
cabal704 has joined #wayland
pseigo has joined #wayland
wv has quit []
wvanhauwaert has joined #wayland
pseigo has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #wayland
jimjams has joined #wayland
pseigo has joined #wayland
<jimjams>
Is there an existing wayland protocol that lets you describe what kind of content a surface has? I'd like to be able to give a hint to the compositor that videos are being rendered.
<jimjams>
If not, does it make sense to add to an existing protocol?
rgallaispou has quit [Read error: Connection reset by peer]
maxzor__ has quit [Ping timeout: 480 seconds]
maxzor__ has joined #wayland
tzimmermann has quit [Quit: Leaving]
zebrag has joined #wayland
maxzor__ has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
cabal704 has joined #wayland
pseigo has joined #wayland
pseigo has quit [Ping timeout: 480 seconds]
pseigo has joined #wayland
nurupo has quit [Quit: nurupo.ga]
nurupo has joined #wayland
maxzor_ has quit [Ping timeout: 480 seconds]
pseigo has quit [Ping timeout: 480 seconds]
pseigo has joined #wayland
pseigo has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
mvlad has quit [Remote host closed the connection]
MajorBiscuit has quit [Quit: WeeChat 3.5]
<i509VCB>
When I was updating wayland.xml for wayland-rs, I noticed that lines 262-266 are indented with spaces and not tabs: (github renders spaces differently) https://github.com/Smithay/wayland-rs/pull/513/files
<i509VCB>
(not spaces differently, but I think with 4 spaces to 1 tab)
slattann1 has quit [Ping timeout: 480 seconds]
systwi_ has joined #wayland
pseigo has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
dcz has quit [Ping timeout: 480 seconds]
systwi has joined #wayland
systwi_ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Remote host closed the connection]