03:08 riteo: Hi folks I just found something that left me with my head scratching for a while: it looks like compositors, when passing pipe file descriptors, have to close their ends. I know that sounds dumb in hindsight but the whole unix ancillary message thing has already very few resources so it took a while for me to figure out
03:08 riteo: is this common knowledge for linux developers? Perhaps it could be documented somewhere
03:09 danieldg: file descriptors in general should be closed when not needed
03:09 riteo: well I found out that if I did it would do weird things when doing my dumb proxy
03:10 riteo: like, I had to check for pipes/fifos in particular to avoid issues
03:10 danieldg: and yes, if you're creating a pipe and passing one end to a peer, your copy of that end needs to be closed
03:10 riteo: but it's also true that I'm building a very weird and hacky proxy so who knows
03:10 danieldg: pipes are funny this way because many programs wait for the condition "all writers have closed their fd"
03:10 riteo: yea danieldg thing is that this also happened to me while working with ancillary data in unix messages
03:10 riteo: and I had no idea it was actually, a new file descriptor
03:11 riteo: might really be just me who is new to the concept ig
03:11 danieldg: ah, yeah, that's just how cmsg stuff works
03:11 riteo: I see
03:11 riteo: I guess that's just common knowledge then indeed
03:12 danieldg: common knowledge of a feature that is not generally encountered, yes
03:13 riteo: I'm really sorry I have issues getting the tone of the message, is that sarcasm
03:14 riteo: no heat here to be clear
03:14 danieldg: no
03:14 riteo: oh all right
03:14 danieldg: doing fd passing isn't an overly common action in general
03:14 riteo: yeye that's fair
03:14 danieldg: if you do it, then the close behavior is common knowledge
03:15 danieldg: sometimes you discover it when you run out of FDs :)
03:15 riteo: I see lol
03:15 riteo: well it's kinda worring that dmabuf stuff fails when I close the fd after passing it then
03:16 riteo: I have no idea if they're the special boys or if pipes really just want to get closed and that's it
03:16 riteo: well, I guess that's relatively low priority, first I gotta finish up this proxy :P
03:17 danieldg: generally the kernel takes no action on a close of a dup'd file descriptor, only on final close of the file description (sendmsg counts as dup)
03:17 danieldg: that's true for pipes and likely is true of dmabuf
03:17 riteo: Oh. I see. That means I'm doing something quite wrong or I need some special handling somewhere.
03:18 riteo: thank you for clearing that up! :D
03:19 danieldg: strace is pretty good at letting you determine where fds go
03:20 danieldg: it isn't as helpful with drm stuff, though
03:20 danieldg: (that's generally a bunch of ioctls at the syscall interface)
03:25 riteo: I just tried replicating the bug by removing the special stat stuff and well... It's not happening anymore. That's weird.
03:25 riteo: Maybe I just messed up something else while moving stuff around, sorry for the noise then
03:25 riteo: If it ever pops up again I'll definitely try with strace :D
03:29 riteo: yup here it is, catched it again, so it was not useless noise
09:37 pq: riteo, if you can find a good explanation of file descriptor vs. file description, that might clear some confusion. It can also point out hidden pitfalls, like the implicit file offset being stored in the description, meaning it is shared by all descriptors even across process boundaries.
09:38 pq: TL;DR: make sure you never rely on the implicit file offset when touching fd shared with someone else.
09:39 pq: not saying you are hitting this problem, but it's a sneaky problem with mysterious consequences
10:09 pq: I wonder if anyone would like to run with a "color management test app" idea: https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/41
10:10 JEEB: I recall there's a HLG test chart somewhere
10:11 swick[m]: mutter only supports perceptual which kind of destroys most of the value of an app like this
10:15 JEEB: right, this contains the TIFFs https://www.arib.or.jp/english/html/overview/doc/2-STD-B72v1_2.pdf
10:16 emersion: zamundaaa had an HDR test app iirc
10:57 pq: swick[m], I don't think perceptual destroys any value. There will be differences, sure, but it's still an indication whether something is grossly wrong.
10:59 pq: The main point is that the test app is easy to use, and gives two renderings of a picture to compare on the same monitor.
11:00 pq: If perceptual had a rigid definition, we wouldn't need the eye-balling part, unless for a lack of a suitable screenshooting interface.
11:01 pq: JEEB, thanks!
11:08 pq: The app can say whether the two pictures are supposed to look identical or just roughly similar.
12:59 zamundaaa[m]: llyyr: see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34000
13:05 llyyr: zamundaaa[m]: thanks! should this perhaps log a message to inform the user why hdr metadata isn't being used?
13:06 zamundaaa[m]: Not sure, if a game has a bug in the HDR metadata, it would probably spam the warnings every single frame, which would be a bit much
13:07 davidre: static bool "warned once?"
13:07 llyyr: yeah, warning once is probably fine
13:07 davidre: * "static bool warned_once" ?
13:11 pq: Does Vulkan require or encourage setting the HDR static metadata every frame?
13:13 zamundaaa[m]: No, it persists on the swapchain until the application changes it again
13:15 pq: Then it would be nice to see if Mesa can warn once per setting it. Maybe games go through a few (invalid) states before settling for the running state?
13:15 riteo: pq: yea in the end the issue was not stuff regarding offsets, it turns out I skipped certain packets and it messed up the fd queue
13:16 zamundaaa[m]: pq: Vulkan not encouraging or requiring apps to set it every frame doesn't mean they don't do it
13:16 pq: riteo, oh yeah, can't even blindly pass through messages, need to understand each one, at least how many fds it carries.
13:16 riteo: pq: I'll take a look at the concepts you described though, thanks
13:17 riteo: once I get the proxy in good shape I'm definitely going to document everything in my website
13:22 pq: zamundaaa[m], ideally there'd be some way for end users to notice and bug their game providers ;-)
13:25 llyyr: the MR warns once now
13:25 llyyr: seems good to me
13:41 zamundaaa[m]: pq: I think that part mostly has to be tackled at the source, in the game engines. Game publishers ship with pretty broken support on Windows, it's unlikely they'll make Wayland-only changes when users complain
13:43 zamundaaa[m]: I've been nudging Godot into the correct direction for example, they're on a good path to making HDR "just work" on Wayland as it should :)
13:43 pq: awesome!
13:44 zamundaaa[m]: Not sure how feasible that is in other engines, but it's worth trying
13:45 pq: right, so users should complain to game engine projects?
13:51 zamundaaa[m]: I guess. Ultimately most HDR metadata is bad rather than triggering a protocol error, so I don't think that's gonna fix too much
13:52 zamundaaa[m]: Windows games aside, most engines will only do HDR on Wayland once someone adds support for that in the engine, so the developer side is the best way to make it work properly
13:53 pq: and we better make use of that metadata in compositors in a visible way
13:54 zamundaaa[m]: I already do :)
13:55 pq: I *just* started typing some code to make use of parametric image description.
16:25 wlb: weston Merge request !1701 opened by Marius Vlad (mvlad) gl-renderer: Don't hard-stop if debugging scopes aren't enabled https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1701 [Debug]