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 joined #wayland
everfree_ has quit []
everfree has joined #wayland
mclasen has joined #wayland
cabal704 has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #wayland
unix has joined #wayland
unix-supremacist[m] has joined #wayland
pseigo_ has quit []
pseigo_ has joined #wayland
pseigo_ has quit []
pseigo_ has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
nerdopolis_ has quit [Ping timeout: 480 seconds]
pseigo_ has quit []
pseigo_ has joined #wayland
pseigo_ has quit [Ping timeout: 480 seconds]
txtsd is now known as Guest3784
txtsd has joined #wayland
maxzor_ has joined #wayland
Guest3784 has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
pseigo_ has joined #wayland
pseigo_ has quit [Ping timeout: 480 seconds]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
jgrulich has joined #wayland
bittin has joined #wayland
jgrulich has quit [Remote host closed the connection]
jgrulich has joined #wayland
hardening has joined #wayland
dos11 has quit []
dos1 has joined #wayland
MajorBiscuit has joined #wayland
tzimmermann has joined #wayland
benbrown has quit [Quit: benbrown]
benbrown has joined #wayland
mbalmer has joined #wayland
danvet has joined #wayland
shankaru has joined #wayland
dcz_ has joined #wayland
mvlad has joined #wayland
wvanhauwaert has joined #wayland
wv has joined #wayland
wv has quit []
wv has joined #wayland
wv has quit []
wvanhauwaert has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
mceier is now known as Guest3804
mceier has joined #wayland
Guest3804 has quit [Ping timeout: 480 seconds]
pseigo_ has joined #wayland
rasterman has joined #wayland
<pq>
mvlad, daniels, if you are going to build a more recent fontconfig for CI, then please also make it an explicit versioned build requirement, so people like me running with ASan on Debian stable know to get a fresher fontconfig.
<pq>
and make the "with pango or not" stop being automagic in the build so that I actually see the failure instead of simply not using pango
<pq>
who knows if that might incite Debian getting a fresher fontconfig sooner...
<mvlad>
pq, yeah, alright.
bookworm has quit []
bookworm has joined #wayland
<daniels>
I really don’t want to version fontconfig to something a lot of people don’t have tbh
jgrulich has quit [Remote host closed the connection]
jgrulich has joined #wayland
<mvlad>
daniels, :shrug:, then I guess we'll stick to suppression file for the time being. I'll have a look in parallel to see if we can update the debian package instead.
<pq>
fontconfig is not a mandatory dep, FWIW - althoug, should it be?
emersion_ has quit [Remote host closed the connection]
emersion has joined #wayland
<emersion>
PSA: wayland final release today unless someone objects
<pq>
daniels, mvlad, I guess I can be persuaded to upgrade fontconfig in CI without making it a build requirement. We'll just reject if anyone posts leak fixes or suppressions for those.
Guest3814 has quit [Ping timeout: 480 seconds]
MrCooper has quit [Quit: Leaving]
<pq>
mvlad, FWIW, any process to update fontconfig that is fine for CI is also fine for me in my developer setup.
MrCooper has joined #wayland
MrCooper has quit [Remote host closed the connection]
<daniels>
I don't like the suppressions, but most of the other solutions seem worse tbh
<pq>
daniels, and upgrading fontconfig would be best? Would it also let you drop all the things you called in your MR?
<pq>
*called horrible
<pq>
aside the llvm thing
<daniels>
shrug, the only horrible fontconfig thing is really the suppression (including the no-fast-unwind), which ... isn't that horrible, it's really just doing what suppressions are there for, which is wilful blindness to SEP
<pq>
um... so what *do* you want?
<daniels>
one of the reasons I didn't really want to probe too much deeper is that it only happens in the Xwayland test, and some of the allocations do trace back to pthread_atfork() handlers, which makes me think that if we _do_ need to try to clean up some of the implicit pango/fontconfig/etc global state, then we might not be able to because we're handing over control to Xwl
<daniels>
honestly I'm content to just leave things as is for now - I don't think it's a great use of time & energy to maintain our own fontconfig build in CI (which will eventually become outdated and weirdly different to Debian), to avoid one line in a suppression file
<pq>
oookay
<daniels>
I don't _like_ what's in those commits, but I like the alternatives less
<pq>
no-fast-unwind is a massive time sink...
txtsd has quit [Ping timeout: 480 seconds]
<daniels>
yeah it's pretty slow, but otoh we win like a minute back from the config-parser/zuc changes, so it's still net positive to runtime :P
maxzor_ has quit [Remote host closed the connection]
<pq>
eh.. ahaha
maxzor_ has joined #wayland
<daniels>
(we can't enable it generally because it just makes us smash through timeout)
<pq>
daniels, mvlad, so how about a Gitlab milestone for things to immediately on libweston major bump to 12?
<pq>
*to do
<mvlad>
pq, milestone or rather a gitlab issue with bullet points?
<pq>
er, milestones are, like, meant as lists of things to handle
<mvlad>
ok
<pq>
a milestone is reached, when all issues and MRs assigned to the milestone have been closed/merged
txtsd has joined #wayland
<emersion>
i like to create a dedicate issue for each release, to put random notes in it
<emersion>
e.g. breaking changes
<emersion>
and notes for packagers/users
<emersion>
(for wlroots/sway)
<emersion>
dedicated*
<pq>
that issue could be one of the issues assigned to the milestone
<daniels>
either wfm
<emersion>
yeah, i also use milestones
<pq>
the point of a milestone is to make it easy to assign issues and MRs to it, and you can easily see filtered lists of issues/MRs to-do vs. done
<pq>
two MRs and one issue currently assigned to the new milestone
txtsd has quit [Ping timeout: 480 seconds]
<pq>
daniels, I think my next step in the HDR saga is to attack DRM-backend's gamma and CTM programming, which probably means eradicating drm_output_set_gamma.
<emersion>
wasn't the plan to do everything in GL at first?
<pq>
weston already uses drmModeCrtcSetGamma for legacy "color management"
<pq>
and weston does not ensure the KMS gamma LUT is not messed up when it starts
<pq>
I'd fix these both: use atomic UAPI to set gamma LUT *always*
<pq>
it's a small step towards more reliable display
<emersion>
ah, so hardcode a linear LUT?
<pq>
yes, unless explicitly otherwise needed
<pq>
identity LUT *should* be the same as setting the property to NULL blob
shankaru has quit [Quit: Leaving.]
<emersion>
i've heard someone say it's not always the case
<emersion>
i'd expect NULL to bypass the LUT, ie. identity, indeed
<emersion>
but who knows
<pq>
yeah, I think AMD uses NULL blob to indicate "blend in linear" or vice versa or something like that
<pq>
meaning that they automatically apply sRGB inverse EOTF before blending and EOTF after blending, based on whether gamma LUT blob is 0 or not
<pq>
that's just rumours I've heard
<daniels>
pq: sounds good, I have absolutely no objection to obliterating set_gamma :)
<emersion>
fun…
<daniels>
just ping me if I can help any
<pq>
hehe, I thought so
<emersion>
i think the docs explicitly says "bypass", which would make AMD behavior incorrect
<pq>
emersion, of course :-)
<emersion>
"Setting this to NULL (blob property value set to 0) means a linear/pass-thru gamma table should be used."
<pq>
but I bet there was some Xorg / Xv use case where someone needed it, and that was the quickest way to make it look right
<pq>
oh well, who knows. I'll scream if I actually see problems.
<pq>
I wonder if anyone cares about Weston's old cms plugins.
<pq>
or should I just delete them
<daniels>
pq: think same as usual for deprecation - change the option name and make it false-by-default + throw a warning when enabled for one release, then delete it the next?
<pq>
oh yeah, that was my plan 1.5 years ago: make the cms plugins simply load the ICC profile into color manager, which means they stop working completely without color management and do something completely different with color management.
<pq>
daniels, well, if we want to keep them, I need to design a new API to keep them working like they used to.
devilhorns has quit []
<pq>
daniels, the new API would be like the old set_gamma, except on weston_output and handled by color manager... but in that case the old plugins stop working without color management.
devilhorns has joined #wayland
<pq>
daniels, or... I simply don't delete the old drm_output_set_gamma API at all, and leave it conflicting with everything new, fighting over who set things last in KMS.
<daniels>
pq: mmmmmmmmmm
<daniels>
I guess there are a few ways to skin that cat
<pq>
I could convert drm_output_set_gamma() to just use atomic, and leave it in as mutually exclusive with new color management
<daniels>
one is that you just have the backend declare all its capabilities (e.g. 'pre-CTM LUT + CTM + post-CTM LUT present') and the frontend puts appropriate values somewhere within weston_output - but that seems like it falls apart very quickly
<pq>
yeah, that has never been the idea
<daniels>
another is that you retain something like set_gamma, but you maybe give it a return value rather than void ... but then you want to carefully restrict where you call it, because presumably if it can fail then you want it to be called before repaint so you can shift work back to the renderer?
<pq>
the idea for new color management is that DRM-backend itself looks at a weston_color_transform object and ponders itself if it can off-load that or not.
<daniels>
yet another is that you take an assign_planes()-alike model, where the backend can examine the desired transform that's present on the output, and 'remove' some of it so the renderer doesn't have to do it
<daniels>
I'd probably lean towards the latter personally, but guiding it by what makes the most sense for the caller is I think ideal
<daniels>
++
<pq>
unfortunately this is utterly incompatible with how the old cms plugins work
<daniels>
ah yeah, gotcha
<daniels>
burn them then :)
<pq>
so if they need to be kept working, they need an alternative, parallel API
<daniels>
eh, I think just burn them
<daniels>
when you asked about removing earlier, I'd just thought that they were mildly awkward rather than like ... completely incompatible
<pq>
yeah
<pq>
the old cms plugins only read the VCGT tag from an ICC profile, ignore all the actual color information, and just load the VCGT into the gamma LUT
shankaru has joined #wayland
<pq>
If we pass that ICC profile to the new color manager, it will actually use all the color information *and* VCGT, which is obviously different.
<pq>
the color manager produces color transformations, assuming that nothing else is going on in KMS
<pq>
so DRM-backend would have two different sources for gamma LUT: what the old cms plugins set vs. what color manager would like to use.
<pq>
presumably, you'd never enable new color manager while also using old cms plugins
<pq>
but even then, there would be two different paths for the DRM-backend to get the contents for the gamma LUT
<pq>
There are two old cms plugins: static and colord. Static loads an ICC file through weston.ini. The other one asks colord for an ICC file.
<pq>
Asking colord for an ICC file could perhaps be useful with the new color manager, too.
<pq>
but then, the compositor behaviour will be very different: the compositor will be using the whole ICC file and not only the VCGT.
<pq>
if applications work the old way, they *too* will get the ICC file from colord, and use the color information *without* VCGT.
<pq>
This means that an old application with new color manager would result in applying the ICC file twice, which would be wrong.
<daniels>
heh ...
<pq>
swick, jadahl, what do you think gnome-shell would here? Will you require that the real monitor ICC profile is loaded in colord and used by gnome-shell, while old applications must be configured to user the standard sRGB profile until they grow support for Wayland color management protocol?
<pq>
that would make WCG monitor owners unhappy until the applications are updated...
<pq>
maybe that requires an end-user toggle: are untagged surfaces assumed to be in sRGB or in current output's color space?
<pq>
or would you force colord to deliver only standard sRGB profiles for outputs, and get the compositor output ICC file from some other config?
<dottedmag>
A (slightly) related question: I have tried to understand what colord does, and it looks like it's just a very complicated database for ICC files. Is there a real functionality in there?
<pq>
dottedmag, that is my understanding as well. No actual color processing in there, just info.
<pq>
and change notifications etc. I'd expect
pnowack has joined #wayland
<pq>
for monitors/outputs, the Wayland extension will replace colord, but colord is still needed for cameras, printers, etc. anything that is not driven by the compositor.
<dottedmag>
It looks like there is some (confusingly) code to deal with colorimeters too.
<pq>
interesting
<pq>
could it be also an abstraction for colorimeters?
<pq>
the Wayland effort is not going to replace that either
<dottedmag>
dtp94 goes via... libusb, yay.
sychill has quit [Remote host closed the connection]
<pq>
don't look at the argyll driver ;-)
pnowack has quit [Quit: pnowack]
<pq>
although, forking another program is perhaps a better idea than calling into arbitrary libraries from a system daemon
sychill has joined #wayland
maxzor_ has quit [Ping timeout: 480 seconds]
<pq>
for my immediate plans, I guess just nuking both old cms plugins is the best plan, but I'm afraid I need to go through the deprecation process
<pq>
mm, yeah.
<pq>
deprecate old cms plugins. Add the new atomic code for programming gamma LUT, but skip that if anyone ever called the old drm_output_set_gamma() API.
<pq>
garbage-collect the plugins and the old API after a release
txtsd has joined #wayland
<pq>
thank you my dear rubber ducks :-)
<emersion>
🦆 glad we helped!
<dottedmag>
pq: Oh, I remember that. I had argyll that handled my colorimeter, but there was a list of known colorimeters in argyll driver, so I had to upgrade colord. And of course it's shelling out.
toothe has quit [Quit: Konversation terminated!]
maxzor_ has joined #wayland
<MrCooper>
pq: FWIW, atomic code for programming gamma LUT won't work for non-atomic drivers like radeon
<pq>
MrCooper, there's no choice either.
<emersion>
also atomic gamma LUT size can be different from legacy size
<MrCooper>
weston-presentation-shm from weston >= 6 doesn't work with mutter >= 42: it binds to any advertised version of xdg_wm_base, but it can't actually work with version 4
<pq>
MrCooper, wait, non-atomic KMS drivers still exist?
<MrCooper>
yes, I gave radeon as an example
<daniels>
MrCooper: ruh row
<daniels>
MrCooper: I'll happily approve the obvious MR :)
<MrCooper>
nouveau also still defaults to non-atomic, though that's getting fixed
<MrCooper>
daniels: it's not obvious to me I'm afraid
<MrCooper>
(I don't know if it requires some minimum version)
<pq>
MrCooper, I suppose radeon is not silly enough to expose the gamma LUT atomic property when it doesn't work, is it?
<MrCooper>
not sure it even could expose that property, not being an atomic driver
<pq>
no problem then
<MrCooper>
except the problem of weston not setting a defined gamma LUT
<pq>
no different from what it does now - not setting it :-)
<MrCooper>
which has always been a problem :)
<pq>
well, let's see if fixing that turns out to be too easy or not
<swick>
pq: we run mutter in a session where we have g-s-d which tries to make sure all outputs have a profile. that's moving over to mutter itself.
nerdopolis has quit [Ping timeout: 480 seconds]
<swick>
and yeah, that means colord becomes more useless to the point where it's not sure if there is anything useful left
<pq>
swick, sure colord should remain useful: camera, scanner, printer profiles, and colorimeter abstraction?
<swick>
even for printers and scanners it would probably make more sense to handle profiles in cups or whatever than in what's basically a complicated database
<swick>
the colorimeter abstraction might still be useful but the whole calibration and profiling workflow also changes with wayland
<pq>
swick, er.. but it's the application rendering or interpreting the images, not cups or scanner driver, and the app needs the profiles from somewhere.
<pq>
wayland changes only the displaying part but leaves all the rest of the existing calibration and profiling workflow untouched
<swick>
sure, but the point here is that you have to choose a printer or scanner first to deliver a bunch of metadata so why not just also deliver the profile
<swick>
calibration and profiling still requires a special surface role which guarantees passthrough
<dottedmag>
sensors abstraction looks like "agryll for everything except a few drivers that are due to some reason are not in argyll"
<pq>
that's still just display
<swick>
mh?
<pq>
the surface is just a detail in displaying test images
<pq>
you still need some program that generates the test images, drives the colorimeter, and computes a profile
<swick>
yeah, all I'm saying is that the colord daemon is kind of useless
<swick>
the colorimeter and calibration/profiling stuff could be pulled out to a library specifically for that
<pq>
or "just" update Argyll for the new display path
<swick>
if you want to deal with that upstream, sure
<dottedmag>
Heh, I have checked the list of supported colorimeters in Argyll, and all the devices that have separate drivers in colord: colorhug, dtp94, huey, huey2 and munki (if colormunki is the same one) are documented as supported by Argyll.
<pq>
if you are going to fight for cups, sane, and what-for-cameras thing to deliver profiles, then ok :-)
<swick>
yeah, colord is also bitrotting hard
<pq>
what about all apps already using the colord D-Bus APIs?
<swick>
all the apps which care about color will have to update for wayland anyway so I'm not too worried
<pq>
Do they, really? Maybe we can have a compatibility story here.
<swick>
maybe, but thats still for out
<swick>
far*
<pq>
a toggle for "untagged surface content is: a) sRGB, b) in whatever output's colorspace the surface happens to mostly be on right now"
<pq>
and if you are in HDR, then never b), otherwise it would be a user toggle
<swick>
pq: I talked with hughsie a bit about the problem of displays having multiple states which require different profiles
<swick>
currently there can be a bunch of profiles for one device but only one default
<swick>
and changing the default from under the user would be bad UX so we would need defaults for all states
<MrCooper>
emersion: thanks for merging
<pq>
swick, by multiple states, do you meant something like SDR and HDR modes?
<swick>
ye
ppascher has quit [Ping timeout: 480 seconds]
mriesch has joined #wayland
<jadahl>
pq: whether to involve colord will probably eventually be a per backend (x11 vs native) decision
<pq>
alright, with Weston I don't yet see the need for that.
<pq>
jadahl, heh, I'm happy to not have to care about that, but I wonder how that's going to work. You also probably have applications that expect colord.
mclasen has quit [Ping timeout: 480 seconds]
<swick>
meh, especially for x11 colord is not that useful and everyone just looks at the X atom
<pq>
aha
<jadahl>
still, how to deal with calibration and selecting that, is an open question. all that goes via colord now, with colord telling what profile to use etc
ppascher has joined #wayland
hwentlan____ is now known as hwentlan
<hwentlan>
for the question of offloading post-blending EOTF^-1 to KMS should KMS expect an FP16 buffer in that case?
<swick>
when offloading only EOTF^-1 then I would say it's very likely that the FB is fp16
<pq>
yup
<hwentlan>
that's what I thought as well. RGB 10-bit won't have enough precision for linear content
<hwentlan>
A bigger question that we previously talked about but not sure if it was settled: will the post-blending EOTF^-1 always be a pre-defined TF (such as PQ or sRGB) or will it be a custom curve including things like tone-mapping to monitor nits?
<pq>
maybe barely for 8 bpc sRGB SDR
<pq>
hwentlan, I can see it being a custom curve, if it comes from e.g. a measured ICC profile.
<pq>
I guess if you drive the monitor with HLG, it needs to be parameterized, unless your blending/FB space is not the HLG... um, standard luminance space?
<pq>
s/is not/is/
mclasen has joined #wayland
<hwentlan>
that's a similar question to PQ tone-mapping then, would that happen pre- or post-blending?
ppascher has quit [Ping timeout: 480 seconds]
<swick>
pq: HLG is parameterized in the EOTF not the EOTF^-1... which sounds really stupid when you put it like that
<swick>
but still, going from linear values to the HLG encoding doesn't require any parameters
<hwentlan>
ah, that explains why we have pre-defined HLG TFs in HW
<emersion>
how many times has the "pq is my preferred transfer function" joke been made already?
* hwentlan
is seemingly to dense to get the joke
<swick>
hwentlan: to do things correctly you have to bring content to the same image state, including dynamic range, before combining it
<swick>
but… you can combine things into a really big thing without tone and gamut mapping and then map that once
<emersion>
hwentlan: pekka is very perceptual
<swick>
it's worse because you loose information about the original gamut and dynamic range but it's easier to implement and also probably less power intensive
<hwentlan>
oh, boy i'm slow
<emersion>
(sorry pekka)
<swick>
the good thing about the whole pekka pq thing is that he never misses any HDR discussions ;)
ppascher has joined #wayland
jgrulich has quit [Remote host closed the connection]
<daniels>
emersion: but is he quantised?
Arnavion has quit [Ping timeout: 480 seconds]
rubdos has joined #wayland
cabal704 has quit [Quit: WeeChat 3.5]
cabal704 has joined #wayland
cabal704 has quit []
cabal704 has joined #wayland
cabal704 has quit []
cabal704 has joined #wayland
cabal704 has quit []
cabal704 has joined #wayland
shankaru has quit [Quit: Leaving.]
pseigo_ has joined #wayland
reillybrogan has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
shankaru has joined #wayland
mbalmer has quit []
anon12344 has joined #wayland
ybogdano has joined #wayland
anon12344 has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
cabal704 has quit [Quit: WeeChat 3.5]
cabal704 has joined #wayland
cabal704 has quit []
MajorBiscuit has quit [Quit: WeeChat 3.5]
pseigo_ has quit [Read error: No route to host]
pseigo_ has joined #wayland
cabal704 has joined #wayland
cabal704 has quit []
cabal704 has joined #wayland
pnowack has joined #wayland
pnowack has quit [Remote host closed the connection]
AJ_Z0 has quit [Quit: I have to return some videotapes]
AJ_Z0 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
mclasen has quit [Ping timeout: 480 seconds]
devilhorns has quit []
yoslin has quit [Quit: WeeChat 3.5]
yoslin has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
shankaru has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
mclasen has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
dblsaiko has quit [Remote host closed the connection]
dblsaiko has joined #wayland
hergertme_ has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]