02:12 yshui`: What happens to frame callbacks when a surface is destroyed? I assume I can just send delete_ids for them?
07:15 emersion: you can, but your listener might still be invoked with a NULL wl_callback arg
07:17 emersion: in case the compositor sent the wl_callback.done event before receiving the wl_surface.destroy request
07:24 yshui`: So what is the expected behavior of the compositor in this case?
07:35 zzag: the compositor just destroys the callback resources
07:44 emersion: what I'm describing is a race you need to account for in you client
08:36 MrCooper: yshui`: see https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/125 , I think that mostly applies to frame events as well
09:12 yshui`: Doesn't mention wl_surface.frame guess I will add a comment 🤔
09:13 yshui`: emersion: I am not writing a client 😆
09:23 MrCooper: yshui`: don't see any significant difference between frame events and presentation feedback for that discussion
09:37 yshui`: added a comment
09:38 yshui`: btw, it wouldn't be unreasonable to impose a limit of how many pending frame callbacks a surface can have, right?
09:39 emersion: it wouldn't be unreasonable to set a limit of how many objects the client can create in general
09:39 emersion: on*
09:40 emersion: with per-object-type buckets or something
09:46 ifreund: it's currently trival to DoS any wayland compositor I know of by just creating a ton of objects :/
09:48 yshui`: it's actually a good idea to have limits then. what's the appropriate error for hitting the limit, no_memory?
10:15 kennylevinsen: Would probably be an acceptable error for now. Not sure if one should make a new one specifically for object limits
10:21 pq: swick[m], why would you be interested in true content color volume if we have the mastering display content color volume? Anything outside of the mastering volume should be brought inside the mastering volume, regardless of where we display it. How to do that is my question.
10:24 pq: haasn, how do you "just clip" color gamut in the same way as the mastering display did, so that we get the same hue shifts etc.?
10:39 pq: yshui`, I'd use no_memory for now indeed. If you use wl_resource_post_error() to send it, you can customize the error message.
10:42 pq: yshui`, I think it is very fitting to the semantics of the frame callback for a compositor to just destroy that wl_resource when the wl_surface is destroyed. There will never be a good time to draw for that wl_surface again.
10:43 pq: I'd even say it's a bug to send frame callbacks after the wl_surface has been destroyed. It makes no sense.
10:45 pq: but we never wrote that down I think, so that's just another reason why clients should destroy their proxies instead of letting them uselessly linger.
12:20 pq: SardemFF7, I just landed weston!1143 and the bot is silent.
12:55 yshui`: pq: I agree with that, but from my understanding they had that bug in mpv, because they chose to destroy the present feedback in the callback
12:55 ManMower: it didn't want to scare anyone
12:56 yshui`: So maybe being explicit that events aren’t guaranteed would clearly indicate that is what clients should do?
12:56 pq: yshui`, one should destroy it in both places.
12:58 pq: events are guaranteed as long as the client doesn't destroy or unmap the surface
13:28 haasn: pq: in practice, you don’t
13:29 haasn: Just clip to the output display
13:29 haasn: In real content it’s basically unheard of for pixels to be outside the mastering display volume
13:30 haasn: As for how to clip, just do it to the rgb cube if you don’t have the luxury of pregenerating a lut
13:30 haasn: Or use an ICC profile
13:32 pq: haasn, ok, so you say it's a bug in the content if it extends outside of the mastering display volume?
13:33 haasn: Yeah pretty much, and if so, I would not try and recreate the mastering display’s clipping behavior
13:33 pq: cool
13:33 haasn: But display it faithfully (if your output device can)
13:34 haasn: (If not, you have to clip anyway)
13:34 pq: that would need taking care and testing, though
13:34 pq: I'd prefer to just declare it a source bug with undefined results
13:40 SardemFF7: pq: I see no request to the /webhook endpoint, however I see a bunch of SSL handshake failures
13:41 SardemFF7: though the IP is not the gitlab.freedesktop.org one, it could be that
13:42 SardemFF7: I hardened my TLS config a bit, but that’d be surprising that fd.o would have no available algo :-/
15:05 ukiran: pq, i had gone through the color representation protocol. As per my understanding, it is used to convert the YUV data into RGB based on the formulae derived from the Matrix Coefficients and VideoFullRangeFlag
15:06 alatiera: is there a weston related channel or can I ask things here?
15:06 qyliss: this is the right channel for weston aiui
15:07 alatiera: this is related to weston-launch's deprecation
15:08 ukiran: as part of the protocol, client is requesting the Coefficients and the server has to respond with the codepoints supported
15:08 ManMower: alatiera: this is the appropriate channel
15:09 alatiera: so previously I had a bash script that would do openvt -- /usr/bin/weston-launch && /foobar/runappbinary and the app would pickup the the env somehow and launch in the proper tty and env
15:09 ukiran: in this case, does client need to fetch the formulae based on the codepoint and other flags?
15:10 ManMower: alatiera: hmm, can you "just install seatd" and make the problem go away? or is that a deal breaker
15:10 alatiera: with `seatd-launch -- weston --backend=drm-backend.so` I got weston launch, but it seems the behavior is different from weston-launch and I can't launch the app
15:10 ManMower: oh interesting
15:10 emersion: that's not related to seatd
15:10 emersion: it's related to the WAYLAND_DISPLAY env var
15:10 alatiera: I am guessing wesont-launch was setting some env var or so
15:12 ManMower: can you just put /foobar/runappbinary in an [autolaunch] in your weston.ini?
15:12 alatiera: oh interesting, didn't think to try that
15:12 alatiera: or rather didn't knew it existed tbh
15:12 alatiera: (also this is a docker container, we can't have nice things and systemd :/)
15:12 alatiera: (not my choice)
15:13 ManMower: no judgment here :)
15:22 ukiran: pq, i see that the table-4 in H.273 document talks about the co-efficients values and the corresponding functions to be called
15:29 alatiera: ManMower seems to "run" and prints logs though I don't see the window spawning for some reason
15:33 ManMower: alatiera: if you launch something simple like weston-terminal or weston-simple-egl via [autolaunch] does that work?
15:35 ManMower: I don't know what your app does - but both of the ones I mentioned should crash/exit promptly if they can't connect to a compositor.
15:35 pq: ukiran, it is about YUV-to-RGB yes. The compositor advertises the code points it supports, and the client must pick one of them for each parameter. H.273 is the definition of what the values mean.
15:36 alatiera: yeap the terminal shows up
15:36 alatiera: might be some gtk issues
15:36 pq: ukiran, the client has some it wants to present, the content matches specific CICP code points, and if the compositor supports those code points, the client can pass the content to the compositor directly with those code points.
15:37 pq: *the client has some content it wants to present
15:37 ukiran: pq, the client should be intelligent enough to pick the codepoints based on its input data ?
15:37 pq: if the content doesn't match what the compositor supports, then the client must convert to something the compositor does support.
15:37 ukiran: so that when the code-point has been set from the client, compositor will pick the right formaulae for the conversion ?
15:38 pq: ukiran, based on its content sources metadata, yes. Or if it creates the content on the fly, the client knows anyway.
15:38 pq: yes
15:39 pq: ukiran, the point of all this is to avoid extra conversions on CPU or GPU, and maybe push the only necessary conversions all the way too the display controller.
15:40 ukiran: pq, it means, the client who implements this interface must aware of the code points.
15:40 pq: for displaying videos, this is the first half of decoding the pixels, and the second half is the color-management extension
15:40 pq: of course
15:40 ukiran: hmm..
15:40 pq: though it is possible that if you have video file, it already uses CICP code points in its metadata
15:41 pq: the client needs to be able to understand the video metadata and how it maps to CICP code points
15:41 ukiran: does this needs to be extracted through ffmpeg tool in the client application to read this CICP code points ?
15:41 pq: I have no idea, but yes ;-)
15:42 pq: you have to know what your content is, it cannot be guessed from raw pixels
15:42 ukiran: obviously yes
15:43 JEEB: if an application utilizes FFmpeg, in most cases the CICP values are extracted
15:44 JEEB: if they're not, then watches very much pelcome
15:44 ukiran: pq, you said that "Avoid the extra conversion on CPU or GPU and needs to be presented to display controller", meaning of the gamma/degamma conversion ?
15:45 ukiran: JEEB, great, i will extract the metadata and verify the CICP values
15:46 pq: alatiera, maybe you upgraded weston past this commit: https://gitlab.freedesktop.org/wayland/weston/-/commit/ae69381b6eb43ab63992906d1bf29ffd2b4df10d - that explain why externally launched app no longer connects.
15:47 ukiran: pq, "for displaying videos, this is the first half of decoding the pixels, and the second half is the color-management extension", inorder to make the color-management extension to work, color-representation protocol is also necessary then, am i right ?
15:48 pq: ukiran, I mean any kind of pixel manipulation.
15:49 ukiran: pq, yeah..
15:50 pq: ukiran, color-management can work on its own, if you only have RGB pixels. If you have YUV, you need color-representation too.
15:51 JEEB: YCbr/YCoCg/ICtCp/ITP etc, which have a non-identity thing set as the matrix coefficients :)
15:51 JEEB: *YCbCr
15:52 JEEB: oh, and apparently there's a thing called YDzDx as well
15:53 pq: ukiran, the reason we can do anything without color-management is that a lot of assumptions are made in all of compositors, clients, and displays, and mistakes there with SDR content are often not that obvious to see, so it doesn't need to be exactly correct.
15:54 pq: the reason we can display any YUV without color-representation is pretty much the same: the error is not always that obvious, or video players convert to RGB.
15:54 alatiera: pq indeed, last time it was working was with weston 9
15:55 pq: but also, people have slowly accustomed to seeing the wrong thing, and think it's the right thing
15:56 ukiran: pq, now-a-days most of the video content is in yuv, do you think this CR protocol is must to perform the colorspace conversion ?
15:57 pq: only if you do not want to do it in the client
15:58 pq: but if you do it in the client, it's probably costing more memory bandwidth, and it is impossible to use the display controller for it
15:58 pq: till tomorrow .o/
16:01 ukiran: pq, it is coming to my point. to do the conversion from YUV BT.601 to BT.709/sRGB/BT.2020 i can use this Color-Representation protocol
16:43 alatiera: ManMower surprise surprise the app itself was bugged and wasn't spawning its window
16:43 alatiera: pq, ManMower thanks!
17:10 alatiera: is there a way to get seatd to deinitialize from the cli?
18:35 kennylevinsen: alatiera: what do you mean? If you use seatd-launch, then seatd will shut down when Weston terminates.
18:44 alatiera: kennylevinsen if weston terminates on its own
18:45 alatiera: my issue was what happens when the supervisor just kills it with a hammer
18:45 alatiera: but I think I kinda manged to workaround that
19:29 emersion: would be nice to plan for a new wayland release soonish
19:29 emersion: it's been a while
19:51 zzag: emersion: it would be nice to get axis direction stuff before release https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/183 :)
21:34 manuels: Why exactly does Wayland not support hotkeys?
21:34 manuels: Iirc the argument was like it allows keyboard sniffing
21:35 idkrn[m]: Well only the application in focus can see keyboard inputs
21:35 manuels: But if I don't just grab but rather reserve and current focus app will not even receive the key?
21:36 idkrn[m]: There are portals and other things that allow for global keyboard shortcuts without exposing the input to every running process
21:36 idkrn[m]: manuels: Not sure I understand your question
21:37 manuels: Or force compositors to give a dialog. Like eg apples security mechanisms (disc access, cam, mic etc)
21:37 manuels: Idkrn nevermind the last proposal is safer and more "modern"
21:37 manuels: What are portals?
21:38 idkrn[m]: manuels: Look up xdg desktop portals
21:38 idkrn[m]: manuels: They are vaguely similar to this
21:38 idkrn[m]: But I didn't know what the exact term for what the global shortcuts on Wayland uses
22:39 manuels: Looks like portals is dir sandbox es apps
22:39 manuels: *for
22:39 manuels: But I wouldn't care if it works
22:39 manuels: Is portals "production ready"?
22:53 ftpd: Hey! Any simple way to synchronize 'primary' and 'clipboard' clipboards? On X I was using https://github.com/CristianHenzel/ClipIt, I'm looking for something similar for Wayland.
22:54 ftpd: (I don't care about gui, I don't care about history. I just want to have the same content in both clipboards, no matter where or how I add/copy it)
23:13 ftpd: `wl-paste -w wl-copy -p -n` to my wm's autostart. I didn't expect it to be so easy ;-)
23:48 daniels: manuels: yes they’re used in most environments, whether or not they’re sandboxed