06:11 colinmarc: if the recommendation is just to ignore the ICC stuff, maybe that should be a separate protocol? I found it tricky in my mesa implementation that on the driver side you basically don't have the ability to opt out of certain features - the set of features is determined by the compositer. whereas binding a protocol (version) is a bilateral negotiation. sorry if that's already come up
06:12 colinmarc: compositor*
06:15 emersion: clients don't have to do anything special (they don't have to support ICC if they don't want to)
06:15 emersion: there's no need to "opt out"
06:16 emersion: but yeah, maybe the ICC stuff should be separate, especially if only Weston is going to support it, it wouldn't pass the impl requirements for merging
06:20 colinmarc: emersion: that's not 100% true, since the output's preferred image description can be defined with an ICC file
06:21 colinmarc: but that part of the protocol hasn't been implemented anywhere anyway iirc (it's not in the mesa impl because vulkan doesn't have any surface area for that)
06:43 pq: emersion, a libdisplay-info release would be nice for Weston, I don't remember anything WIP I'd want to wait for.
06:43 colinmarc: (also, as a compositor, if you support ICC profiles at all, you have to expect that any client that binds the hdr protocol (which will be all of them, via mesa) can send an ICC profile, and be ready to accept it. If there was a binding step, then you would be able to gate that functionality. maybe that's not hugely important)
06:50 pq: ICC stuff is for everyone who wants to work with software that is related to cameras, scanners, and prints. The existing industry is largely built on ICC I believe.
06:53 pq: mclasen seems to be missing the fact that everything about Wayland is optional. Even everything that an extension says is mandatory, because the extension itself is optional.
06:54 colinmarc: do video players care about ICC profiles?
06:54 colinmarc: honestly asking, I've never implemented or looked closely at one
06:55 pq: colinmarc, I've never implemented a video player either, or looked at the container specs. Broadcasting in general does not tend to use ICC.
06:56 pq: However, anything that relates to image processing, "photoshopping", drawing, desining printed materials, etc. are likely using ICC.
06:58 pq: All those applications could live the parametric image descriptions, if it wasn't for users who like to measure their monitor response and craft a color profile out of that.
06:58 pq: *live with
06:59 colinmarc: okay, so you have games and video players on the one hand, and content creation tools on the other. they have fairly substantially different requirements. and I don't think it's crazy to venture that there are a lot more users/apps in the former category already existing on linux.
06:59 pq: IOW, ignoring ICC means throwing all professional image processing users out.
07:00 pq: and my dream is to make Linux at least as attractive to such users as Apple
07:01 colinmarc: so, I'm hopelessly biased, as someone who plays games on linux and who is designing a compositor for running games, but I do think there's something being lost here by lumping both categories together in one protocol
07:02 pq: if ICC is moved to a separate protocol extension, I likely will not be funded to work on it anymore, and sounds very much like there aren't (m)any other developers who'd care.
07:02 daniels: there are a _lot_ of people using those kinds of tools on Linux, yeah
07:03 pq: many many years ago, when people started wanting HDR on Linux desktop, I very deliberately wanted to connect that to color management for two reasons: the core of HDR support *is* color management, and to get proper support for ICC that is not extremely fragile
07:04 pq: In the end, ICC support is much easier than HDR support: hook up LittleCMS, and you're done.
07:05 pq: with HDR, you actually have to figure out yourself what to do with all the parameters
07:08 pq: Once you know how to do all the HDR stuff based on parameters, I don't think it's a big step after that to make ICC and parametric interoperable, in a casually satisfactory way.
07:09 colinmarc: I'm just trying to point out that technically, there is a clear split between applications (and even compositors) that want to shovel HDR content around, and those that need color management. By the way, that split is exactly between the apps that would just use the driver's implementation and the apps that would bind the protocol directly.
07:09 pq: I will be seriously disappointed if ICC must be moved into a separate extension. It does add more uninteresting boilerplate just to integrate with the parametric color-management protocol, while it does not make anything easier.
07:10 colinmarc: pq: I'm certain that's true, but as someone who is just beginning their digital color journey, everything is overwhelming enough to understand already
07:10 pq: colinmarc, HDR absolutely needs color management.
07:10 colinmarc: sorry, I was using that as shorthand for the ICC profiles and other advanced ways of doing color management
07:11 pq: and HDR color management is much harder to do than ICC, because in ICC all the difficulty is in crafting the ICC profiles, which for a compositor are handed ready-made.
07:14 colinmarc: pq: it definitely makes things easier, because it allows for a few clarifying assumptions - for example that only the driver will bind the parametric protocol.
07:14 pq: colinmarc, color management in itself is overwhelming. Picking just ICC or HDR does not make it much easier, but it does give a narrower view that is more likely to lead into hidden assumptions.
07:15 colinmarc: I know I'm just a rando so thanks for discussing this with me, in any case :)
07:15 pq: colinmarc, what "driver"?
07:16 colinmarc: I guess I mean the WSI implementation in mesa/eventually other graphics drivers
07:16 colinmarc: there are many other examples of protocols that are meant to be used only by the system-installed driver stack and not by the framework or the app itself. or am I misunderstanding that?
07:16 pq: if you are referring to the HDR capabilities of Vulkan and EGL, the drivers will only pass parameters through. They don't help you in any way. You still need to know in your app, which parameters to pick, and how to actually produce an image that matches those.
07:18 pq: If you choose to use some game engine that has that knowledge alrady built in, that helps you.
07:19 pq: But if you use a game engine, then you probably never use a WSI API anyway, so it doesn't matter who binds the protocol interface, it's not "you" in any case.
07:19 colinmarc: I guess we need to define "easier" then. to me, it is easier to design a protocol which only has to support integration with drivers. this isn't hypothetical - one of the blockers on the CM&HDR protocol is that there's no way for vulkan users to disable mesa's integration in order to use their own, right?
07:21 colinmarc: you don't want both WSI and the framework/engine/app to bind the protocol simultaneously, that's an error. so you need some out of band way to communicate "I've got it, I'm binding the protocol"
07:21 colinmarc: whereas if you put it in the bucket of "only WSI is meant to bind this protocol" that removes that problem
07:21 pq: I thought there was an answer to that question. But that question will continue to be a problem even if ICC and parametric were separate extesions, because then they need to be mutually exclusive on the same wl_surface. Then you have someone who wants to use an ICC profile but render with Vulkan.
07:22 emersion: the original idea was that mesa wouldn't use the protocol if the Vulkan user doesn't use the HDR ext
07:25 colinmarc: @emersion, I wrote a bit about that when I did the mesa impl, here: https://github.com/KhronosGroup/Vulkan-Docs/issues/2307#issuecomment-2060492326
07:25 colinmarc: maybe I'm misunderstanding something, but I don't think it's that simple
07:26 emersion: binding to the global should have no consequences
07:26 emersion: get_surface is the thing that needs gating
07:27 emersion: i don't believe PASSTHROUGH equals "no color_management_surface"
07:28 emersion: isn't PASSTHROUGH supposed to be implemented as setting the surface's color space to the output's?
07:28 emersion: my immediate thought would be to call get_surface lazily, when a swapchain is bound to a surface
07:29 pq: emersion, I think something in Vulkan API design made the convenient solution impractical.
07:29 emersion: VkSwapchainCreateInfoKHR contains the surface
07:30 pq: because there is no Vulkan API object that represents the window system connection
07:30 colinmarc: so you would call get_surface the first time the swapchain is created, and then cache it for future swapchains?
07:32 emersion: yeah, stash it in the surface
07:32 colinmarc: another problem I ran into is that it's not easy to look up the instance extensions that were enabled. and since the extension literally just adds enum values it's a bit weird to gate on that (for example, mesa always exposes all the enum values even if you don't enable the extension, because it's hard to code it otherwise)
07:32 emersion: i mean the VkSurfaceKHR
07:35 pq: If I'm not mistaken, it's related to the reason why Vulkan is creates so many wl_registry objects in the first place.
07:36 colinmarc: yeah, I don't understand 100% why that is, to be honest
07:36 pq: daniels explained it to me once, but I've happily forgot.
07:39 pq: So, if ICC interfaces are put into a separate Wayland extension, it will either need to duplicate both the wl_surface and wl_output extensions interfaces of the parametric color-management extension, or hook onto them.
07:41 pq: Either way, it becomes API-wise possible to tag a wl_surface with both ICC and parametric image descriptions, which makes no sense and must be forbidden somehow. So the "get_surface" is still mutually exclusive and allowed to have only one at a time per wl_surface.
07:41 colinmarc: pq: Couldn't you have them both create image description objects, the same way dma creates wl_buffers?
07:41 colinmarc: to your point, that's still mutually exclusive
07:42 jadahl: colinmarc: count GNOME Shell as one that intends to to both HDR and "real" color management
07:42 pq: If the ICC extension does not duplicate the wl_output, wl_surface, and a small part of the wp_image_description interfaces, it needs to re-use the wp_image_description interface, which means that ICC necessarily still leaks into the wp_image_description interface (in its information provider part).
07:43 pq: and it brings the problem of versioning wp_image_description: now there are two independent extensions creating objects of the same type.
07:44 pq: jadahl, I'm so happy to hear that. :-) And darktable people are too: https://fosstodon.org/@darktable@photog.social/112632428160968975
07:45 jadahl: I imagine photo editor apps like that will want to indeed
07:46 pq: they very least want to get the display's ICC profile, and provide window content matching that
07:46 jadahl: whatever gets them correct output. I can't imagine performance being critical for something like darktable
07:47 colinmarc: yeah, my point was not that those users don't exist, but that the huge userbase of video players and games has a different (sub)set of requirements, which are more easily satisfied, and would be satisfied by a WSI-only protocol (which, even if it's doable to do the protocol-for-both-WSI-and-apps thing, is certainly awkward and more complicated)
07:48 pq: colinmarc, the factory interfaces of wl_buffer do not consider versioning, which means we can never extend wl_buffer interface, and I think would have wanted to several times, but had to put the new stuff in wl_surface instead. Versioning can be made to work (now that we are aware), but it's complicated.
07:48 colinmarc: pq: that's interesting, I didn't know that
07:49 pq: colinmarc, what if someone who usually does photo editing wants to watch a video?
07:50 colinmarc: I'm not sure I understand the question, sorry
07:52 colinmarc: anyone who does content creation probably has a macbook - today. I think it's laudable to try and make linux a better platform for that. but it's a bit weird to bundle those needs in with the needs of the people already on linux playing games and watching HDR movies.
07:52 pq: The user has set up an ICC profile for their display. Video players probably use only the parametric interfaces. Now, the display cannot be described by the parametric interface at all. Video player does not mind, just tags its window with the video color characteristics. The compositor gets to deal with parametric<->ICC interoperability anyway, even if the protocols were separate.
07:54 colinmarc: ah ok. yeah, in that future, it is simpler for it to be one protocol, probably.
07:55 wlb: weston/main: Pekka Paalanen * frontend: remove useless if (section) https://gitlab.freedesktop.org/wayland/weston/commit/3908e3e345af frontend/main.c
07:55 wlb: weston Merge request !1549 merged \o/ (frontend: remove useless if (section) https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1549)
07:56 pq: emersion, does Weston compositor implementation and weston-image client implementation count as one or two implementations for wayland-protocols governance?
07:56 emersion: i thought weston clients are not real-world
07:56 emersion: were*
07:57 emersion: but maybe i'm wrong?
07:57 pq: weston-image is as much real-world simple image viewer as they would be, color-management wise.
07:57 pq: I can do a Weston wayland-backend as a client implementation, too. Should so at some point anyway.
07:58 emersion: i've been wondering about wlroots' backend counting or not as a client impl in the past
07:58 pq: *Should do
07:58 emersion: for wl_surface.get_release
07:59 pq: what would be a more real-world client implementation than a nested compositor?
08:00 emersion: i don't have an answer to these questions
08:01 pq: I'd be happy to count them as two, compositor and client. They are independent implementations, just under the same membership.
08:01 pq: Maybe that should be brought up and decided.
08:01 jadahl: technically they are two separate implementations. so it's more of a philosophical or "governence" question I guess
08:01 pq: I don't see a difference to the same person writing the implementations in two different projects.
08:01 pq: yeah
08:02 wlb: weston/main: Louis-Francis Ratté-Boulianne * clients: add support for surface compression in simple-egl https://gitlab.freedesktop.org/wayland/weston/commit/1703d7682240 clients/simple-egl.c
08:02 wlb: weston Merge request !1551 merged \o/ (Add support for surface compression in simple-egl https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1551)
08:02 jadahl: "GNOME" is one member, but we count mutter and gtk as different implementations
08:02 emersion: Mutter and GTK are separate members
08:02 jadahl: not in the MEMBERS.md
08:02 jadahl: it says GTK/Mutter (then lists me and Carlos)
08:03 emersion: oh, i misremembered
08:03 jadahl: splitting up has been discussed, but didn't happen yet
08:04 emersion: kind-of related is wlroots being a single member representing many different compositors
08:04 jadahl: indeed
08:05 pq: I wouldn't take a "nested compositor" implementation that is just a pass-through of protocol as either compositor or client implementation, btw., as it does not handle the semantics for either side.
08:05 emersion: that's fair
08:06 pq: emersion, I think the deciding factor there is, where does the protocol implementation reside mostly? In the compositors, or in wlroots? Or this that difficult to tell?
08:06 pq: *Or is that
08:06 emersion: in general that's not difficult to tell
08:06 emersion: some compositors use the wlr impl, some compositors do the impl themselves
08:07 pq: if someone does the impl themselves, they should count separately - but also they need to be members separately as well, or?
08:07 emersion: we've been ignoring members for the purposes of counting impls so far
08:07 emersion: e.g. mpv is not a member
08:08 pq: oh, that's good
08:08 emersion: yeah
08:08 pq: then there is no question at all
08:08 emersion: the only question is whether or not the impl is "real" or "toy"
08:09 pq: Weston compositor implementation is one, and weston-image is another
08:09 emersion: and you've answered that question
08:09 pq: so the ICC parts only need one compositor or client impl, right?
08:09 pq: *one more
08:09 colinmarc: there is some sort of soft notability threshold, right? like I wouldn't count my compositor as notable because it has no real users yet.
08:10 pq: easiest is to look for a client to implement it, and then it can exercise the handling for the output ICC profile as well, which weston-image does not do.
08:11 jadahl: pq: could be worth checking how far GTK has come in the color management work
08:11 pq: OTOH, if I implement color-management ICC support in weston's wayland-backend, that would be another client implementation quite different from weston-image. But I'd hesitate to say the Weston project can fulfill all three required implementations, I'd like another project too.
08:11 jadahl: not sure how much ICC profile work has been done, but IIRC e.g. loupe (gtk4 image viewer) might want to plumb the ICC profiles of images
08:12 jadahl: (there is work related to color management going on in gtk/loupe land)
08:12 pq: jadahl, awesome
08:13 pq: jadahl, given weston-image already works on Weston, they could develop against Weston.
08:14 pq: jadahl, how should I get in touch?
08:14 MrCooper: mclasen is working on it for GTK
08:15 jadahl: pq: right, talk to mclasen on #gtk on libera, or here
08:16 pq: he's not here when I am, I think
08:17 jadahl: I think he'll join in three or so hours
08:18 pq: okay, thanks
08:20 pq: Maybe the ICC side will be the first to gather the implementations then. :-)
08:20 pq: The parametric interface is still missing bits even (white levels).
08:21 pq: So at this point it doesn't seem to me that getting the ICC side implementations would considerably hinder landing the protocol.
08:22 colinmarc: just to point it out, there are also many, many thousands of users using a different protocol for HDR today which doesn't support any of that. because there's so much demand that they're circumventing the "official" protocol process
08:23 pq: Sure, that's fine.
08:25 colinmarc: it's a bit odd to me that games seem like such a low priority here, given how much they are driving linux desktop adoption. and the fact that games, on the whole, are relatively simple clients with simple and consistent requirements.
08:25 colinmarc: functionally today they are basically a single client, wine/proton
08:26 pq: and people complain to me that no-one cares about ICC
08:28 pq: why should we create a quick solution for games, when one already exists?
08:28 pq: we should do better, and aim higher
08:30 jadahl: if we would end up with an upstream quick fix for games (like the one in the wild), we'd end up with two HDR protocols, one well designed, and quickly designed
08:32 emersion: my understanding was that ICC was very far off, and would block merging of the HDR stuff
08:32 emersion: but it seems like it's not the case
08:33 colinmarc: I think the WSI/app split is more the issue. the ideal would be to have vulkan APIs to support all those interfaces, and do everything through vulkan. but no one has even proposed those extensions
08:34 colinmarc: the parametric stuff is exposable via Vulkan already. the ICC stuff (and some other pieces of the protocol like preferred descriptions) is not
08:36 pq: ICC alone is easy, because profile builders and CMSs do all the hard work. Mixed ICC/parametric is hard, and splitting the extension in two might sweep that case under the carpet but not make it disappear. Weston has taken (blame me) an unnecessarily hard way of implementing ICC support.
08:37 emersion: that's completely fine if vulkan doesn't expose every feature, i think
08:40 pq: Vulkan and EGL are not the only libraries that wrap the color-management protocol interfaces, more or less fully. App toolkits would do so too. Since neither Vulkan nor EGL are app toolkits, but tookits might use Vulkan or EGL, you still have two independent components doing the same things on the same surfaces. It seems unavoidable.
08:46 King_DuckZ: good morning all~ any hint on how best to retrieve the output's width and height from the fragment shader?
08:47 zamundaaa[m]: pq: I don't think ICC in the protocol is really needed for those "real colormanagement" use cases to work. You only need a profile on the output side, which is simpler to implement, at least in KWin
08:47 pq: zamundaaa[m], the apps also need to get that profile, and then they need to tell the compositor they used that profile.
08:47 zamundaaa[m]: I don't think that's necessary
08:48 pq: why not?
08:48 pq: apps very least do need the display profile
08:49 zamundaaa[m]: Apps need the available gamut, but I don't think it needs to account for the nonlinear nature of the display's response
08:50 pq: but the gamut bounary cannot be expressed otherwise
08:50 pq: *boundary
08:51 zamundaaa[m]: The linear subset of the gamut that the display can present can be expressed
08:52 pq: what subset? A gamut that a display can reproduce is the gamut it can reproduce.
08:52 King_DuckZ: I've been looking around in Weston's code, I don't find any obvious way to propagate that info down into a uniform - I couldn't even find where it's stored at all tbh :/
08:53 zamundaaa[m]: You can pick a set of primaries that is entirely contained in the display's gamut
08:53 pq: you mean you think it is ok to leave parts of the reproducable gamut out of clients' access?
08:53 zamundaaa[m]: Yes
08:53 zamundaaa[m]: They should effectively always be insignificant, right?
08:54 pq: I'm not sure. I don't even know how you could pick such primaries in the first place.
08:54 daniels: colinmarc: it has taken much longer than we'd have liked to have a solution, but tbf we did also start many years later than hoped. the protocol development has been a long twisty road, but otoh there's a _lot_ of infrastructure work required to just make sure that you don't instantly blind people as soon as a notification pops up on top of their HDR game/movie, so splitting things may have compromised things long term & not made it faster
08:55 daniels: pq: the reason the queries are all on VkSurfaceKHR, rather than having a VkDisplayKHR which wraps a surface, is basically that none of Windows/macOS/Android have a display object, because your window system is a system-global singleton
08:55 zamundaaa[m]: pq Microsoft at least seems confident that it's enough, their Windows Advanced Color stuff doesn't deal with ICC profiles at all afaik
08:55 daniels: the surface-based queries do work fine enough, just with some minor annoyance, so that's where we ended up with, rather than having an indirection that's completely superfluous for everything other than generic Linux
08:55 zamundaaa[m]: So I'm at least willing to try it
08:56 pq: zamundaaa[m], The gamut is a 3D volume, and you'd need to make sure that the sub-set gamut 3D volume is fully contained inside the reproducable 3D volume. Maybe it is simple for RGB displays specifically, though, but I would not trust my intuition without mathematical modeling with real-world data.
08:57 pq: zamundaaa[m], well, people also think that sending BT.2020 on the wire is good enough. Depends on what it is designed for.
08:58 pq: I mean HDMI and DisplayPort
08:58 pq: years later, we have rumours of Source-Based Tone Mapping to fix the problems with that.
08:59 colinmarc: daniels: I'm sorry if you read impatience in what I wrote, that's actually not what I was trying to express. I haven't been around for all of that - I only just started getting involved in linux graphics stuff. I would of course like to use (a subset) of the protocol already, and my suggestion was that it might be technically clarifying to simplify or split the protocol. And more broadly I'm concerned that it seems like games are a bit of a
08:59 colinmarc: secondary concern, which is leading to the practical result of wayland being sort of "forked"
08:59 pq: yet, ICC has existed for longer than any of that. But ICC is hard to implement efficiently.
09:00 zamundaaa[m]: pq That is true. I don't intend to stick to this plan no matter what, but to write autotests that check whether or not this works out in practice too. And if it doesn't, we'll just have to add ICC support in KWin too
09:00 pq: zamundaaa[m], cool. How do you plan to test that?
09:01 pq: zamundaaa[m], wait, do you mean that also KWin would not use a user set ICC profile as-is, but only the simple sub-set gamut?
09:02 zamundaaa[m]: Yes, ish. On the output side, the ICC profile is still applied
09:02 pq: what do you as the source profile, if you use the ICC profile as destination?
09:03 pq: or do you make your sources target PCSXYZ?
09:04 zamundaaa[m]: I don't use lcms for that. I just convert the input to XYZ D50, and pass it through for example the B2A1 tag
09:05 zamundaaa[m]: For testing I'll write an integration test in KWin, which tests the whole client -> final framebuffer pipeline, and check delta E at the end, and which part of the gamut it actually manages to use
09:05 daniels: colinmarc: yeah, that's totally fine, I get what you're saying :) it definitely seems from the surface like doing full CM (as opposed to limited HDR) is the hard part, but in reality a huge amount of the implementation work is the same no matter which path you take - teaching compositors to do something more nuanced than just slamming buffers at GL or KMS without thinking about the content
09:05 pq: zamundaaa[m], delta E vs. what? What's the reference?
09:06 daniels: (sort of like how a lot of the engineering effort to 'do Wayland' was actually just a lot of foundational work on toolkits so they were capable of running on non-X11)
09:06 zamundaaa[m]: pq: the reference is lcms doing the conversation like it would on X11
09:07 zamundaaa[m]: Plus the vcgt ofc
09:12 pq: King_DuckZ, https://gitlab.freedesktop.org/wayland/weston/-/commit/cd888bde6fe88314324a80ed805e1be732259090 is an example of adding both a new uniform and a new shader build option.
09:14 swick[m]: trusting MS on anything color is a bit... eh.
09:15 pq: daniels, I was asking what problems not having a VkDisplayKHR caused, rather than why we don't have it.
09:15 King_DuckZ: pq: thanks, looking at it now
09:18 daniels: pq: oh, I don't know what problems it really causes tbh
09:20 pq: daniels, like why does Mesa Vulkan create so many wl_registries? Or how we cannot... something something to to do get_color_management_surface only when we know that Vulkan will actually be driving the color properties?
09:22 emersion: colinmarc: would it help to have a read-only version of get_surface for vulkan, or not?
09:22 pq: colinmarc, if you think games are a secondary concern, what do you see as the primary concern that people are working on?
09:23 colinmarc: emersion: write-only would help but not read-only :)
09:23 pq: zamundaaa[m], ok, so what do you use as the source profile for the reference?
09:24 colinmarc: colinmarc: the main thing vulkan can do today is describe the buffer that it passes up
09:24 daniels: pq: yeah, the client has to specifically enable the VK_EXT_hdr_metadata extension on the VkInstance it creates before it queries surface capabilities, so you could skip that
09:25 colinmarc: daniels: maybe I'm misunderstanding, but I think the metadata is separate from describing the buffer color space
09:27 colinmarc: the issue is that VK_EXT_swapchain_colorspace is awkward to use as a signal, in part because even without that extension mesa would still like to send sRGB
09:28 zamundaaa[m]: pq: various profiles that apps might use - probably mostly profiles from random displays
09:29 zamundaaa[m]: Colin Marc: I don't think you have to use the color management surface for sRGB
09:30 zamundaaa[m]: You can assume that to be the default, that you get when the surface isn't tagged with any image description
09:33 pq: zamundaaa[m], I'm lost. Isn't the goal to test if using a simple sub-set gamut of the output's ICC profile is sufficient? And KWin implements protocol only for parametric surface profiles. If your reference is defined by ICC profile, you'd have to convert that to a parametric profile? Or do you do a re-render of test input from source ICC profile to parametric profile, send that image to compositor, compare
09:33 pq: compositor result to the original ICC source profile coupled with the outputs ICC profile?
09:35 zamundaaa[m]: pq: yes, I commit a re-render of the test input to the parametric profile
09:37 colinmarc: <zamundaaa[m]> "Colin Marc: I don't think you..." <- right, but what about the content creation apps? they want to set P3 or whatever, which means they need to enable the extension, which means mesa will bind the protocol
09:38 colinmarc: or they don't enable the extension and mark their buffers incorrectly as srgb
09:39 zamundaaa[m]: Mesa doesn't mark anything if the extension isn't enabled
09:39 colinmarc: realistically what they want is PASSTHROUGH, if they're doing CM themselves, I think
09:39 zamundaaa[m]: If the app wants to do color management itself, it has to use the color management surface to tag it with whatever colorspace they want
09:39 colinmarc: which is also behind the extension
09:40 zamundaaa[m]: The sRGB thing is quite misleading in Vulkan, it doesn't really mean sRGB
09:40 zamundaaa[m]: It's untagged in this case, and with other operating systems too right now afaik
09:41 zamundaaa[m]: PASSTHROUGH is unfortunately not really usable for our purpose
09:41 zamundaaa[m]: Because you can't really create or destroy the color management surface based on that, right?
09:42 colinmarc: zamundaaa[m]: that's even more awkward, yeah, because it's a property of the swapchain, not the surface
09:43 colinmarc: treating sRGB as "untagged, but only if the extension is not enabled" works but is not very explicit and hard to communicate to users
09:44 zamundaaa[m]: No, you'd also treat is as untagged when the extension is used
09:44 colinmarc: but what if your content is actually srgb?
09:45 zamundaaa[m]: The assumption is that untagged is okay for sRGB content
09:45 zamundaaa[m]: But you're right, it's awkward
09:49 kennylevinsen: "color sensitive sRGB content" is probably always going to be an odd concept
09:59 colinmarc: you also have to convince nvidia to do the same thing in their wsi, I guess. and if you're porting a moltenvk app to linux, then the behavior will be surprising
10:01 King_DuckZ: I'm getting really confused right now but I think shader in Weston got the names wrong, it's got this yuva2rgba function that should really be called ycbcra2rgba
10:14 King_DuckZ: or maybe not :|
10:16 pq: zamundaaa[m], ok, yeah, sounds like that can work. An interesting idea.
10:19 pq: King_DuckZ, YUV and YCbCr are used interchangeably in weston.
10:20 pq: neither means very much, because there are many "flavors" of YCbCr
10:21 King_DuckZ: pq: that's wrong if that's the case, u and v are in the [-0.5..0.5] range, while cb and cr are in the positive range (but not necessarily [0..255])
10:21 pq: King_DuckZ, tell that to all the DRM pixel formats who carry Y, U or V in their names.
10:21 pq: and the channel data type is invariably unsigned integer
10:22 pq: OTOH, shaders always handle [0.0, 1.0] range values. Not [0, 255] and not even [-0.5, 0.5].
10:23 King_DuckZ: pq: well, that doesn't make it "correct" :)
10:23 pq: King_DuckZ, what would be correct?
10:24 King_DuckZ: what wikipedia says is correct :D https://en.wikipedia.org/wiki/Y%E2%80%B2UV (last paragraph)
10:25 King_DuckZ: well the yuva2rgba() function in the shader *is* offsetting u and v by 0.5, so I think that's really converting yuva and not ycbcr in this case
10:26 King_DuckZ: I got confused but I think the naming in the shader is correct
10:26 JEEB: to my knowledge YUV was an analog thing, and people just kept utilizing the same thing for digital, even though it was being called YCbCr or Y'Cb'Cr' (one of those is linear, one of those is transform encoded)
10:26 pq: if U and V are zero for achromatic, and Cb and Cr are in unsigned intereger range, then neither is correct for yuva2rgba()
10:26 JEEB: at least in FFmpeg that is why the pixel formats kept being called YUV...
10:27 pq: JEEB, right. The one with prime ' is electrically encoded.
10:28 King_DuckZ:facepalms
10:28 pq: and YUV drops the prime, because no-one bothers with optical Y - except constant luminance encoding
10:29 King_DuckZ: sorry, I just realised yuva2rgba() is doing -0.5 and not + so my first guess was correct, it is ycbcr and not yuv (let's leave the ' on the side for now)
10:30 King_DuckZ: looking at this line `su = yuva.y - 0.5;`
10:30 pq: King_DuckZ, the input to yuva2rgba() is unsigned integer encoding of YCbCr divided by integer max.
10:31 JEEB: and to see how actual specs call these things, you can take a look at BT.2100, f.ex. 10- and 12-bit integer representation, I don't see YUV being utilized there at all
10:31 King_DuckZ: I don't think the scaling matters here, or else rgb would also be "wrong" since it's not [0..255]
10:31 King_DuckZ: just the fact that it's all positive
10:33 pq: King_DuckZ, and quantization range? The input to yuva2rgba() has the range in it, and the range is normalized only inside yuva2rgba().
10:34 colinmarc: is YUV a legitimate way to talk about pixel layout? or is that also loose?
10:34 pq: colinmarc, YUV is fundamentally loose nowadays.
10:35 colinmarc: it's just easier to type than YCbCr :)
10:35 pq: yup
10:35 King_DuckZ: pq: the wikipedia page I posted earlier says "YCbCr usually scales all channels to either the 16–235 range or the 0–255 range"
10:35 pq: and YCbCr has never been a single definition either
10:35 pq: King_DuckZ, yes, I read that.
10:36 King_DuckZ: so it doesn't really matter if it's starting from 0 or 16, though I agree it's bloody confusing
10:37 King_DuckZ: but calling it the wrong name makes it even more confusing
10:38 King_DuckZ: colinmarc: so is typing mb vs MiB but in code it'd be very confusing if you had *both* megabytes and mebibytes and never knew if bytes2mb() was doing the one or the other
10:38 pq: do you really read YUV as not YCbCr?
10:39 pq: you cannot compute with YCbCr without additional knowledge, anyway
10:40 King_DuckZ: pq: well it might be due to inexperience, but I've been messing around with +0.5 and clamp for the whole week now, all I know for sure at this point is that I know this "try and see what the output looks like" guessing game
10:40 King_DuckZ: is that I hate*
10:40 pq: King_DuckZ, uh... trial end error is probably the most painful path here. What do you want to know?
10:42 King_DuckZ: I'm working on that shader to make it do chroma key and I need yuv (like [-0.5..05] uv) for that to work properly (at least that's my understanding so far)
10:43 pq: well, you probably need to rewrite yuva2rgba() completely to get that.
10:44 pq: currently, the quantization range handling is built into the "matrix" that also does the YCbCr->RGB conversion.
10:44 King_DuckZ: no because that one is used to convert from values coming from the outside the shader (see sample_input_texture())
10:45 pq: what do you need again?
10:46 pq: and why are you looking at yuva2rgba()?
10:46 King_DuckZ: gl_FragColor = f(rgba, yuva(rgba)), and I'm trying not to convert twice where possible
10:48 King_DuckZ: because I wanted to know if the yuva I get when for example `c_variant == SHADER_VARIANT_Y_U_V` is really yuva or if it's ycbcr, and I think it's ycbcr in fact
10:48 King_DuckZ: since I have a chroma key to compare to, I must make sure I'm not comparing apples to oranges
10:50 pq: What the shader calls YUV in yuva2rgba() is the unsigned integer pixel value divided by integer max. Then you have todo undo the offset and the quantization range to get to [-0.5, 0.5].
10:51 King_DuckZ: it wouldn't work if my key was in the [-0.5..0.5] range and the input colour was in the [0..1] range, and it'd work /sometimes/ if input was going through my rgba2yuva conversion sometimes, and coming straight from the input unshifted some other times
10:51 King_DuckZ: sorry if I sound pedantic, I'm really the guy caling gnu "linux" all the time and MiB megabytes, but in this case I think it makes a difference
10:52 King_DuckZ: yep I think that's clear now, thanks!
10:53 pq: To me, what makes the difference is understanding what the values are. Being pedanting, the input to yuva2rgba() is neither YUV nor YCbCr, because it is scaled YCbCr. You cannot compare scaled to non-scaled. Pedantically.
10:55 pq: One can have even more fun similarly with RGB, when you can have unsigned integers, or normalized to peak range, or normalized to SDR range, and then of course in some niche corner there exists the limited quantization range of it as well.
10:56 pq: Not to mention the third quantization range 1-254 that some signaling types use (I forgot the name), but I don't think we encounter that in this context.
10:57 King_DuckZ: yeah I see your point, I'm not saying "call it ycbcr" and suddenly everything is crystal clear, just a bit less confusing
10:58 pq: I was similarly very confused with the terms EOTF, OETF, and OOTF.
10:58 King_DuckZ: it's also true that in a shader's context I think it's normal to have [0..1] ranges instead of 255, so I wouldn't be surprised to see that Y is 1.0 instead of 255 just like I'm not surprised by R doing it
10:59 JEEB: King_DuckZ: too bad that to my knowledge I don't really see there being a definition of YUV in digital space, other than people writing YUV when they mean YCbCr or YCgCo or ICtCp
11:00 JEEB: and I know that from experience since I've worked on FFmpeg enough to know that the YUV... pixel formats are just leftovers from a bygone era when the analog format was more prevalent
11:00 JEEB: (also technically shorter, yes)
11:00 pq: King_DuckZ, how about the RGB range [0.0, 125.0] :-)
11:00 King_DuckZ: :D
11:01 JEEB: pq: the full range stuff which might or might not include 1 is defined in BT.2100. I rewrote the FFmpeg AVColorRange documentation based on that
11:01 JEEB: s/1/0/
11:01 King_DuckZ: JEEB: so you suggest keeping yuv naming and hope for the best? I'm asking in case I try and open a pull request
11:01 pq: JEEB, ah, that's the spec.
11:01 JEEB: pq: yea it defines the limited and full range representations
11:02 JEEB: King_DuckZ: no I definitely don't in any new context :P
11:02 King_DuckZ: JEEB: wouldn't it be confusing if you saw a yuva_chroma_key variable compared to a input_yuva-0.5?
11:03 JEEB: since YUV in digital space is not defined by anything to my knowledge, so if you mean YCbCr or YCgCo or ICtCp or IPTv2 or whatever, you write that xD
11:03 wlb: weston/main: Marius Vlad * backend-drm: Print out planes IDs that have been excluded https://gitlab.freedesktop.org/wayland/weston/commit/3184f5a2df3b libweston/backend-drm/fb.c
11:03 JEEB: (and if you just mean chroma subsampled image format then you can utilize the common names for that)
11:03 wlb: weston Merge request !1523 merged \o/ (backend-drm: Print out planes IDs that have been excluded https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1523)
11:04 King_DuckZ: so what would you call a YUV whith U/V in the [-0.5..0.5] range?
11:06 JEEB: that's the state just before sending it into integer coding
11:06 colinmarc: that's the intermediate form that the matrix transform spits out
11:06 JEEB: basically if I had a floating point 4:2:0 format I'd expect it to have something like that
11:06 colinmarc: YPbPr?
11:07 King_DuckZ: colinmarc: that's the name of the cable, as I understand
11:07 colinmarc: > The resulting luma (Y) value will then have a nominal range from 0 to 1, and the chroma (PB and PR) values will have a nominal range from -0.5 to +0.5. The reverse conversion process can be readily derived by inverting the above equations.
11:07 colinmarc: (from wikipedia)
11:07 JEEB: if it's encoded already with a transfer, then call it luma and have it marked as float
11:07 pq: JEEB, no, it's not BT.2100. It's SDI signalling.
11:08 JEEB: since IIRC there is some best practice that for linear you call it luminance and transfer encoded it's supposedly better to call it luma (and same with chrominance vs chroma)
11:08 pq: https://tech.ebu.ch/docs/r/r103.pdf
11:09 King_DuckZ: JEEB: yes I think so
11:10 JEEB: pq: BT.2100 table 9 (digital 10- and 12- bit integer representation) contains the narrow and full range definitions for RGBYI and CbCrCtCp
11:10 pq: JEEB, yes, but I was referring to SDI "full" range, which is different from both.
11:11 pq: different from both full and narrow
11:11 pq: just to add to the confusion :-)
11:11 King_DuckZ: colinmarc: this random internet guy claims that's incorrect tho https://www.retrosix.wiki/yuv-vs-ycbcr-vs-rgb-color-space
11:11 JEEB: well you mentioned the one that starts with 1 instead of 0 (chroma for full range)
11:12 JEEB: I wrote it out in https://ffmpeg.org/doxygen/trunk/pixfmt_8h.html#a3da0bf691418bc22c4bcbe6583ad589a
11:12 JEEB: so the SDI one is different from these?
11:14 King_DuckZ: it's a very convincing and conveniently schematic explanation, but it seems to contradict wikipedia... so is that wrong? I'm trying to learn and the fact that each website claims the opposite of everyone else is not helping
11:14 pq: JEEB, yes, different. 1-254 for R, G, B, Y
11:14 JEEB: huh, funky
11:14 King_DuckZ: I do have the Poynton book, but it'll take a while before I go through it, I've only just started reading
11:16 pq: King_DuckZ, welcome to color, in general.
11:17 King_DuckZ: :D
11:17 kennylevinsen: King_DuckZ: He's wrong - the cable has never been called YPbPr, but "component video". Some devices have labelled the terminals "Y", "Pb/Cb" and "Pr/Cr"
11:17 King_DuckZ: It's love and hate from day 1!
11:17 JEEB: kennylevinsen: component is analog, right?
11:17 King_DuckZ: kennylevinsen: thanks, so I'll call my function rgb2ypbpr
11:18 JEEB: ugh
11:18 King_DuckZ: well, ypbpra
11:18 JEEB: so you're calculating an analog signal?
11:19 King_DuckZ: no, but colinmarc said ypbpr T_T
11:19 JEEB: it's just the floating point representation of Y'C'bC'r (or whatever luma plus chroma based format)
11:19 JEEB: King_DuckZ: I do not see an actual specification calling this E' variable anything, and E' is the input to the integer representation
11:20 kennylevinsen: JEEB: yup, just intended to get better color separation and reduced artifacts compared to composite
11:20 pq: Different systems really do work slightly differently. People mix up systems, and write it down. People simplify all the way down to not quite right, and write it down. People read those, make utterly false conclusions, and write it down. And the next person comes looking for the truth...
11:21 JEEB: King_DuckZ: as an example, https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2100-2-201807-I!!PDF-E.pdf
11:22 King_DuckZ: JEEB: ok I'll try and read
11:22 JEEB: I just say call it ycc (since I'm not sure if it's cbcr or what) and it's float. the floating point representation of it is the signal you have for chroma (-0.5-0.5)
11:22 King_DuckZ: but I was really hoping to figure out the name I should use before lunch this year ^^
11:23 JEEB: alternatively take a look at how libplacebo calls these things
11:23 kennylevinsen: (PAL composite/RF is itself Y'UV, with component splitting off UV to their own signals)
11:23 JEEB: King_DuckZ: basically, YC(b)C(r) and float is what your signal is, it doesn't have a separate word for it
11:24 King_DuckZ: ycc sounds good enough, thanks
11:25 JEEB: or if it's generic matrix encoding then you'll have to look at libplacebo or zimg or so, for examples of generic matrix coefficient encoding/decoding functions
11:25 JEEB:scrolls up to check the name of the function
11:25 pq: King_DuckZ, https://www.retrosix.wiki/yuv-vs-ycbcr-vs-rgb-color-space goes wrong already in the beginning: it calls RGB and YUV as "color spaces", and "blue luminance (U) and red luminance (V)".
11:25 kennylevinsen: As an aside, the wikipedia article on YCbCr is self-contradicting
11:26 JEEB: yea, which is why it's better to just keep to specs if only possible
11:27 JEEB: King_DuckZ: so is your function something like `rgba2yuva` from the backlog? is it just a generic matrix encoding thing?
11:27 kennylevinsen: It says that Y'PbPr has a range of -0.5 to +0.5 then says Y'CbCr is scaled to an integer space... and then proceeds to have a chart named "Y'CbCr" that goes from -1.0 to +1.0 :P
11:28 kennylevinsen: Petition to throw all these terms away and come up with new ones, anyone?
11:28 pq: People are bound to call the same thing with different names, and different things the same name. One would hope that a document is at least internally consistent.
11:29 wlb: weston Merge request !1552 opened by Derek Foreman (derekf) rdp: Use current_scale instead of scale for input translation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1552 [RDP backend]
11:30 pq: JEEB, the original function in question is https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/renderer-gl/fragment.glsl?ref_type=heads#L98-124
11:31 pq: what I "like" the most is that 'yuva.y' gives you the u. :-P
11:32 kennylevinsen: colors were a mistake
11:32 pq: somehow using r,g,b,a to denote the components of yuva vector didn't seem right...
11:35 JEEB: King_DuckZ: I checked libplacebo and it calls matrix application {encode,decode}_color , which then handles the various matrix coefficients including ICtCp etc.
11:36 kennylevinsen: pq: honestly, rgba might be less confusing as there is no overlap to misinterpret
11:37 pq: except a which accidentally happens to be a
11:38 pq: hmm, the bug still exists, too...
11:39 JEEB: so I guess encode_color or apply_matrix_coefficients (but with apply I don't know what the inverse of it would be :P)
11:42 pq: I kinda think that mentioning *something* of YCrCr or even YUV would make better intuition of what it does. YUV-RGB-conversion is well-known category of algorithms, right?
11:42 pq: *YCbCr
11:43 pq: not an exact name for the algorithm as implemented, but enough to give a good idea what it's about
11:44 JEEB: as a comment, sure. but if you add it to the name then suddenly you're apparently limiting yourself to specific matrix coefficients values
11:47 pq: rgbaize()
11:53 pq: mclasen, do you think Loupe might want to use the ICC profile side of color-management protocol? Either send the image embedded profile up, or get the compositor's preferred when it happens to be an ICC profile?
11:54 wlb: weston Merge request !1553 opened by Derek Foreman (derekf) shared: Add some EGL extensions https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1553 [Clients]
11:55 mclasen: pq: yes, I think they do
11:56 mclasen: I did succeed yesterday btw, in telling both kwin and weston that my surface is srgb
11:56 pq: mclasen, cool. That might be the third implementation needed for the protocol ICC parts.
11:57 pq: Nice!
11:57 mclasen: I did not succeed with srgb-linear, baby steps...
11:58 pq: mclasen, as you found out, Weston only supports ICC profiles right now, so you'd have to craft an ICC file. I would recommend one of the other two options though.
11:58 wlb: wayland Merge request !399 opened by Tejas Vipin (meltq) src: switch asserts to wl_abort https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/399
11:58 mclasen: thats what I did
11:58 mclasen: its of course not very interesting for srgb
11:59 pq: mclasen, would Loupe (or GTK) use a CMM (like LittleCMS) itself?
11:59 mclasen: or handling icc profiles, we will eventually use lcms
11:59 mclasen: I'm trying to keep icc profiles out of this initial work
11:59 pq: ok
11:59 mclasen: weston put a wrench into that plan :)
12:00 pq: You could do what weston-image does, and simply forward the image embedded ICC profile to the compositor.
12:00 mclasen: well, this is not about images, per se. its about making gtk do its compositing in a defined space, and communicate that to the compositor in the end
12:01 pq: Or, if you use a CMM, you could get the compositor's preferred image description, and if it's ICC, use the CMM to convert to that client-side, and and tag the surface as such.
12:01 swick[m]: I remember loupe devs saying that they have ICC profiles that won't get accepted by the cm protocol
12:01 swick[m]: not sure about the details anymore
12:01 pq: swick[m], because of the class, I presume.
12:02 swick[m]: I think also because of non 3 channel profiles
12:02 pq: ok
12:03 wlb: weston Merge request !1552 merged \o/ (rdp: Use current_scale instead of scale for input translation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1552)
12:03 wlb: weston/main: Derek Foreman * rdp: Use current_scale instead of scale for input translation https://gitlab.freedesktop.org/wayland/weston/commit/c3321d581937 libweston/backend-rdp/rdpdisp.c
12:03 pq: all those are such that I'd prefer if the app did its own color management to compositor preferred
12:03 King_DuckZ: sorry I was out for lunch
12:03 swick[m]: exactly, I don't want to handle metallic inks and stuff like that
12:04 mclasen: I've ignored the compositor preferred thing so far, since it is so annoying to get the information about it (two levels of callbacks...)
12:04 pq: if end users want to tune that, that's something the app should allow
12:04 King_DuckZ: JEEB: I already have a matrix that seems to work, I put it together from Poynton's book and god knows what else, but rgb -> yuv -> rgb on shadertoy looks correct afaict
12:05 pq: ok, sounds like Loupe will want to use a CMM itself, targeting the compositor's preferred image description. That's excellent, because that's the case I'm still missing.
12:05 colinmarc: @pq, @swick - would it be helpful if I documented the conversation about vulkan compatibility today in a comment on the MR (or I guess a separate issue somewhere)? even though we didn't really find a solution, maybe discussion could continue there. if we do figure out a way to make it work, I'm happy to update my mesa draft MR.
12:06 King_DuckZ: my matrix 0.2126*f1, -0.2126/1.8556*f2, 0.5*f2, 0.7152*f1, -0.7152/1.8556*f2, -0.7152/1.5748*f2, 0.0722*f1, 0.5*f2, -0.0722/1.5748*f2 you can just set f1=f2=1, it's just there if you have a smaller gamut
12:06 King_DuckZ: (I think it's called gamut)
12:06 pq: colinmarc, I think I am not applicable. I mean, my Vulkan knowledge is nonexistent, and I'm not sure we covered anything new today.
12:07 JEEB: King_DuckZ: if you need matrix details there's BT.273 that goes over the common ones (and then gives you context for the rest of it like primaries or transfer and color range)
12:07 King_DuckZ: pq: thanks for checking, ok I'll disregard that link if it's wrong, but it's annoying how it claims that everyone else is wrong and corrects them, just adding to the noise
12:08 JEEB: https://www.itu.int/rec/T-REC-H.273-202107-S/en
12:08 King_DuckZ: thanks
12:08 JEEB: but I was mostly just noting that if you are indeed just doing a generic matrix coefficient application thing
12:09 King_DuckZ: I hope taking matrices and common computations from gpl source is ok btw?
12:10 JEEB: pretty sure weston is not wanting things that would limit its license to GPL (IIRC its license is more liberal)
12:11 JEEB: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/COPYING?ref_type=heads
12:11 JEEB: yea, so one of the "MIT" licenses
12:11 King_DuckZ: "liberal" is wrong in this case, they both are just in different ways (technically gpl maximises freedom, but enough cans of worms for today)
12:11 JEEB: yea, took a while for me to pick wording :P
12:11 King_DuckZ: I see what you mean :)
12:12 JEEB: of course for your own experientation it's fine, your fork just ends up being GPL due to utilizing GPL code
12:12 JEEB: King_DuckZ: also you can clearly see why I didn't utilize freedom or free as wording :P
12:13 JEEB: anyways, if you are looking at shader bits you might want to also look at libplacebo for inspiration since it already implements a bunch of the stuff mentioned in H.273
12:13 King_DuckZ: yes :)
12:13 pq: Just wait until people ask AI how color works, and write it down. Or just generate docs directly.
12:13 King_DuckZ: I'm having a look, just lots of links and stuff, it'll take me a while
12:13 JEEB: https://code.videolan.org/videolan/libplacebo/-/blob/master/src/shaders/colorspace.c?ref_type=heads
12:14 JEEB: encode_color and decode_color do the matrix coefficients part of H.273 as far as I can tell
12:16 King_DuckZ: pq: idk, ai seems to be doing just fine with recipes https://arstechnica.com/information-technology/2023/08/ai-powered-grocery-bot-suggests-recipe-for-toxic-gas-poison-bread-sandwich/
12:16 King_DuckZ: it can't go wrong with colour!
12:20 King_DuckZ: imagine if you mixed red, green and x-ray for example
12:25 haasn: pq: just store your color in the order CrYCb
12:25 haasn: then you can access .r for the red difference, .b for the blue difference and .y for the luma
12:25 haasn: problem solved /s
12:25 haasn: no but we unironically do this in libplacebo for the intermediates during constant luminance decoding :p
14:03 King_DuckZ: I need some more help, hopefully it's less confusing than earlier today :) how can I pass user parameters to the shader in Weston? for example, from outside user is playing a video and wants to use chroma key green, smoothness=20, and then another video and have key=blue, smoothness=50
14:04 King_DuckZ: is there a way I can pass such parameters, or is a uniform taken from a global ini config the best I can achieve?
14:21 King_DuckZ: I guess another way to put it, can I attach some sort metadata to the output generated by each program running?
14:26 wlb: weston/main: Philipp Zabel * compositor: access correct weston_buffer union field according to type https://gitlab.freedesktop.org/wayland/weston/commit/060f010c35ae libweston/compositor.c
14:26 wlb: weston Merge request !1550 merged \o/ (compositor: do not clear dmabuf pointer for busy buffers https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1550)
14:26 mwhoosier: daniels or mvlad: Is there any dedicated hardware path in the weston DRM backend to handle the "transform" key directly in KMS? I had been almost certain that I'd seen plane properties for this before, but now I can't find them.
14:32 mvlad: mwhoosier, do you mean perhaps the rotation like https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1120?
14:34 mvlad: also, see https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/315 wrt to the panel orientation
14:35 mwhoosier: mvlad: Indeed. It turns out that before complaining here, I should have made sure that I wasn't looking at a massively out of date copy of the Weston source tree :(
14:36 King_DuckZ: ask first, think later - that's what I always do! :p
14:37 wlb: weston Merge request !1554 opened by Robert Mader (rmader) gl-renderer: Fix limited range quantization https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1554
14:37 mwhoosier: mvlad: thanks
14:37 mvlad: np, happy to help!
15:09 daniels: King_DuckZ: look at gl_shader_config
15:27 King_DuckZ: daniels: thanks for the pointer
15:28 King_DuckZ: I have a small emergency tho
15:28 King_DuckZ: as I understand, fragment.glsl runs once for each program
15:29 King_DuckZ: in gl-renderer.c I have glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
15:30 King_DuckZ: and I have two videos playng on top of each other, my chroma key is not working at all, green screen got desaturated but I don't think alpha is being respected
15:41 King_DuckZ: I don't see Weston doing glClear or anything, what's going on? have I made the wrong assumptions?
16:00 wlb: wayland-protocols Issue #202 opened by Max Ihlenfeldt (mihlenfeldt) data_offer.set_actions(0, 0) does not result in data_offer.action(0), but data_offer.finish() causes protocol error https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/202
16:45 emersion: libdisplay-info 0.2.0 https://lists.freedesktop.org/archives/wayland-devel/2024-June/043678.html
16:55 Ermine:throws release confetti
17:12 daniels: King_DuckZ: sounds like you need to make libweston consider your format be transparent
18:09 King_DuckZ: daniels: could you point me to where I should look at? I've been trying to follow weston_output, but with callbacks and all it's not easy to figure who's calling who
19:51 swick[m]: emersion: probably don't have time to do the libdisplay-info changes in mutter this cycle but good to see anyway
19:51 emersion: cool!
19:52 swick[m]: emersion: I'm more worried about libdisplay-info stalling. It was already not great getting one review from you every few month but it looks like it won't improve anytime soon...
19:52 emersion: the problem is that everybody is busy
19:52 emersion: same as always
19:53 emersion: would be really nice to get more contributors involved
19:54 swick[m]: yeah, whatever the reasons are, it's really frustrating to write code that just gets ignored forever
19:55 swick[m]: maybe we can recruit jani and hans?
19:56 emersion: i was going to suggest some KDE folks, but
19:56 emersion: i think a problem is that only very few people are interested in making it parse all of the specs
19:57 emersion: and also, very few people are willing to spend the effort to think about API design and such
21:04 zamundaaa[m]: If you point me to a pdf of the relevant spec in each case, I could do reviews at least
22:03 KarenTheDorf: emersion: And those of us who aren't busy, are unsure how to help without slowing experienced/professional devs down.