ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Guest4288 has quit [Ping timeout: 480 seconds]
kelnos has joined #wayland
novenary has quit [Remote host closed the connection]
novenary has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
luyn has quit [Remote host closed the connection]
Dami_Lu has quit [Read error: Connection reset by peer]
Dami_Lu has joined #wayland
carlos_ has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest4301
Guest4257 has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
Brainium has quit [Quit: Konversation terminated!]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #wayland
Guest4301 has quit [Remote host closed the connection]
<pq>
emersion, I'm curious, how will it be different from LittleCMS 2? What made you start on that?
<emersion>
lower level, raw access to ICC
<emersion>
less features, simpler
<pq>
even lower?
<emersion>
i mean, currently you need to write LCMS plugins and other hacks
<pq>
true
<pq>
but starting from scratch seems... a lot, if just for that reason
<emersion>
i don't think it's that much work, for my purposes
<pq>
Interesting to see how that works out.
<emersion>
i already have everything i need for v2
<zamundaaa[m]>
emersion: I don't think I can adopt that this short before the Plasma 6 feature freeze, but I am interested in using it later on
<zamundaaa[m]>
Especially if we can add some higher level APIs too, like getting the effective primaries + whitepoint of a display profile, or inverting curves
<pq>
inverting LUT curves can be tricky for precision; Weston does do that today with LCMS, but I'm not sure how far that carries. Parametric curves are better anyway, if available.
<pq>
a Display class profile can (and for measured monitors, does) include a 3D LUT, which means trying to extract primaries is probably going to hurt, assuming the user has a reason to use a measured profile.
<zamundaaa[m]>
The profile always contains primaries directly too, even if it has a 3D lut
<pq>
but are they supposed to be used *instead*?
<pq>
are you still going to use the 3D LUT?
<pq>
ICC profiles seem to be able to contain multiple levels of information, where more sophisticated CMMs would use the more precise information.
<zamundaaa[m]>
The spec is pretty clear about that: Use BToD tags if available, BToA if not, and the primaries if that isn't available either
<pq>
right
<zamundaaa[m]>
In the current KWin impl I'm using the primaries for the blending color space; the 3D lut from the ICC profile gets applied post-blending
<pq>
interesting
<pq>
our Weston approach is to take a Display profile as an opaque box, and approximate a linearization of that to produce the blending space.
<pq>
Graeme Gill suggested this, as the blending space does not need to be too precisely anything specific, as long as it is light-linear enough.
rumpelsMongol__ has quit [Remote host closed the connection]
rumpelsMongol__ has joined #wayland
<pq>
and as long as the linearization can be undone precisely enough, which may be of question in Weston at the moment.
<pq>
exactly because representing the inverse of a LUT as a LUT is prone to problems
sevz has joined #wayland
AnuthaDev has joined #wayland
<pq>
Maybe Weston should attempt fitting a power function to the recovered linearization LUT in order to improve roundtrip precision...
nerdopolis has joined #wayland
iomari893 has quit []
<pq>
use the curve in both directions
<Consolatis>
Small question about xdg-shell: There is a xdg_surface.set_window_geometry() request defined. It is used by a (Qt) client which then later gets a configure request from the compositor, ACKs the request, updates its viewporter and buffer size but does *not* update the window_geometry. Is that a client bug and how should compositors reacts to this, keep using the outdated geometry (so we ignore drop shadows and friends) or just update it manually ba
<Consolatis>
sed on the new viewporter / buffer sizes?
iomari891 has joined #wayland
<vyivel>
you are supposed to ignore drop shadows and friends
<vyivel>
window_geometry is the geometry without that
<Consolatis>
vyivel: I am aware of that. The question is what should happen if a client does not keep it in sync with size changes
<vyivel>
report a bug to the client i presume
<Consolatis>
so it *is* a client bug then
<vyivel>
probably; what program is this?
<Consolatis>
random ones, all Qt based
<Consolatis>
it also doesn't seem to happen all the time so there might be some race condition within Qt itself that sometimes prevents sending the new window_geometry
<vyivel>
sounds like it
<vyivel>
generally if the buffer is resized the window geometry should be updated as well so yeah a qt bug i assume
AnuthaDev has quit []
<Consolatis>
for now we'll likely just add a workaround and check if the reported extents of the surface match those of our configure request and if yes use those instead of the window geometry. Feels pretty hacky though.