04:43whot: Consolatis: to can download the messages as mbox format. month-per-month but the urls are predictable so you can script it
06:15wlb: weston Issue #979 opened by () Weston 14 will affect the performance of glmark https://gitlab.freedesktop.org/wayland/weston/-/issues/979
12:06upichika: Hello, I have a question on sharing the image data to the fragment shader in weston
12:08upichika: the client is giving the data to the compositor as dmabuf in YUV. Could some one please help me to point, where exactly this buffer is being fed to shaders ?
12:09upichika: I see in gl-renderer.c -> gl_renderer_attach_dmabuf() -> gr->image_target_texture_2d(target, gb->images[i]);
12:09upichika: Is this is correct ?
12:10pq: upichika, the dmabug is imported into an EGLImage or a few, then those are bound as textures, and the shader samples from those. Depending on the importing and formats, the shader does YUV-to-RGB conversion.
12:10pq: *dmabuf
12:10pq: upichika, that is a texture binding step, yes.
12:10upichika: will it be possible to read the pixel data from this dmabuf before shader reads this data ?
12:11pq: what do you mean?
12:11pq: by CPU?
12:11upichika: yes
12:11pq: well, GBM does have API for it, but it will likely take significant time to do so.
12:12pq: as in, it's slow.
12:12pq: For what purpose?
12:13any1: I doubt that gbm_bo_map is implemented for YCbCr on any platform
12:14pq: true - one could lie about the format through, it's likely DRM_FORMAT_MOD_LINEAR I guess.
12:14upichika: I wanted to implement a small functionality to get the mean brightness of the frame on CPU side
12:15pq: that's probably going to be quite slow
12:16upichika: okay, but is there any feasibility of that ?
12:17pq: feasiblity as in, can it work, even if slow? Theoretically yes, if gbm_bo_map() does not refuse.
12:18pq: Maybe a compute shader would be a performant way.
12:19upichika: Yeah, I got it
12:20any1: Well, you're intested in the brightness, so you only need the luma plane
12:21upichika: can we differentiate only luma plane data from the dmabuf ?
12:22any1: yes
12:22upichika: Y-plane data
12:22any1: yep
12:24pq: if it's a planar pixel format
12:24any1: Let's hop that it's not that interleaved YUYV crap :p
12:24any1: hope*
12:25upichika: Got it
12:25any1: But, yeah, if it's coming from a webcam, it's most likely interleaved
12:25pq: unfortunately luma is not quite luminance
12:26pq: upichika, is this about computing maxFALL specifically, or something else?
12:26upichika: that is the reason, am trying to calculate the brightness of the whole pixels in the frame
12:27upichika: pq, as the content is not giving maxFAL, am trying to calculate it in the compositor
12:28upichika: maxFALL*
12:30pq: upichika, there a few problems with that. One is that the compositor can take max() over only the frames it has already seen (and displayed), but it has no knowledge of the future. Future frames may change the current idea of maxFALL radically. If you use maxFALL for tone mapping purposes, the tone mapping won't be stable - or even deterministic.
12:31pq: hmm, where was maxFALL defined again...
12:31pq: cta-861-h
12:35pq: upichika, while you get some sort of approximation by averaging the luma channel, the algorithm in CTA-861-I uses max(R, G, B), which requires you to convert YUV to R'G'B' and then use the EOTF.
12:38pq: given that luma is in electrical domain, it might be a poor approximation, since the average is supposed to be computed in optical domain.
12:41pq: If it's a live video stream, I suspect it might be better to not try to measure any FALL.
12:45pq: Maybe a player application can do some dynamic contrast control, maybe a sliding window for estimating maxFALL and then communicate that to the compositor. The player knows when that estimate needs to be reset for deterministic tone mapping, while the compositor does not.
12:46pq: e.g. user switches videos, or rewinds the video for re-play
12:51upichika: we cant use the maxFALL calculated based on the luma plane.
12:52upichika: to get the proper brightness value, we need to convert to linear data first
13:03pq: upichika, right.
13:06upichika: pq, thanks for the info
13:48wlb: weston/main: Tomek Bury * gl-renderer: make DMABUF allocator optional https://gitlab.freedesktop.org/wayland/weston/commit/b14461b13b54 libweston/ meson.build renderer-gl/gl-renderer.c renderer-gl/meson.build
13:48wlb: weston Merge request !1648 merged \o/ (Make DMABUF allocator optional https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1648)
15:26wlb: weston Merge request !1657 opened by () compositor: re-order paint node placeholder checks https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1657 [Core compositor]
15:45llyyr: is there a test client for xdg-foreign?
15:57upichika: pq, could you please help in sharing the details on where the texture is being sent to shaders for the yuv to rgb conversion ?
16:32soreau: upichika: maybe somewhere around here? https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/renderer-gl/fragment.glsl#L98
16:35soreau: like https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/renderer-gl/gl-renderer.c#L3465
16:37upichika: soreau, first link is to call perform pixel conversion from yuv to rgb which is happening in Fragment shader
16:37upichika: and the second link is to bind elg-image as texture
16:39upichika: what i want to know is, how does the fragment shader will get the texture from gl-renderer ?
16:41soreau: one of the glTexImage2D() calls in the renderer? maybe in gl_renderer_flush_damage()
17:35wlb: weston Merge request !1658 opened by () drm: Fix underlay test https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1658 [DRM/KMS backend]
17:43bluetail: seriously, are there any works in regard of fixing xwayland and making it work with wayland without having to force one screen to be at pos 0 0? It even applies for winecfg, and the issue has been stale upstream at winehq now for a while. And it is because in wayland positions are relative, compared to xorg where they are absolute.
17:55ofourdan: no, I tried and it's been discussed in https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/395 and the consensus is it's easier to fix your Wayland ouput configuration than making Xwayland accept non-zero coordinate for the top left screen corner.
17:55ofourdan: so I gave up on this.
17:56bluetail: that kind of sucks.
17:56bluetail: okay, so I am going to ask at #sway more about a convenient mode switch.
17:56bluetail: I got 7 screens at the moment, and it would just need to reload part of the config
18:01bluetail: I use sway. If you already got some convenient script, you could share it, otherwise I'd temporarily comment/uncomment stuff and reload
18:10ofourdan: I don't use sway myself, but it looks like you can play with the config using swaymsg?
18:11bluetail: correct. I currently use output identifiers, but the proper call to them is somewhere in my notes, it's somewhat of a lemon. And I know it will work...
18:12bluetail: oh yea, found. The syntax is: swaymsg "focus output 'BNQ ZOWIE XL LCD REDACTED'"
18:12bluetail: instead, I would define pos
18:25soreau: there is a wlr function to get the nearest output to a point IIRC
21:31wlb: weston/main: Derek Foreman * drm: Fix underlay test https://gitlab.freedesktop.org/wayland/weston/commit/8dbb3e17d038 libweston/backend-drm/state-propose.c
21:31wlb: weston Merge request !1658 merged \o/ (drm: Fix underlay test https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1658)
21:38wlb: weston/main: Derek Foreman * compositor: re-order paint node placeholder checks https://gitlab.freedesktop.org/wayland/weston/commit/53189ebb89df libweston/compositor.c
21:38wlb: weston Merge request !1657 merged \o/ (compositor: re-order paint node placeholder checks https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1657)
21:57wlb: weston/main: Tomek Bury * tests: fix test build error on older Linux https://gitlab.freedesktop.org/wayland/weston/commit/67253b30e8e8 tests/constraints-test.c
21:57wlb: weston Merge request !1647 merged \o/ (Fix test build error on older Linux https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1647)