01:43 wlb: weston Issue #913 closed \o/ ([Support] Clone LVDS output to HDMI card https://gitlab.freedesktop.org/wayland/weston/-/issues/913)
07:53 pq: King_DuckZ, probably best to use a solid-color surface. No need to mess with the shaders.
07:54 pq: King_DuckZ, well, I cannot guess what kind of chroma-keying, and would be showing through and how, so hard to say.
07:55 pq: *and what would be
09:22 King_DuckZ: pq: I'm trying to figure myself, but as I understand I get a frame from a video stream and a colour threshold and need to get rid of any pixels beyond that threshold, there's a requirement to do it on gpu and to show "what's behind" after chroma-keying, whatever that means
09:22 King_DuckZ: soreau: thanks
09:23 pq: King_DuckZ, wait, so you need to emulate chroma-keying with shaders, and not use the chroma-keying hardware of a display controller?
09:24 King_DuckZ: pq: yeah because *I think* the hardware one has certain limitations that won't work in our case
09:24 pq: oh, then forget what I said
09:25 King_DuckZ:presses the forget button
09:27 pq: If that needs to be off-loaded to the compositor, then shaders it is: if (color threshold) color = vec4(0, 0, 0, 0); or maybe even discard;
09:34 King_DuckZ: yep, just wondering how to inject that into the compositor's default shader, soreau suggested I try wayfire, I'll be looking into that if weston can't do it out of the box
09:41 daniels: King_DuckZ: libweston/renderer-gl/fragment.glsl is the shader source
09:42 daniels: you'll want to also make pixel_format_is_opaque() inside libweston/pixel-formats.c return false for any format you're planning to apply this to
10:11 pq: King_DuckZ, you need a new field in struct gl_shader_requirements for turning the chroma-keying on/off.
10:12 pq: King_DuckZ, is this something for downstream only, or do you hope to upstream this?
10:15 pq: King_DuckZ, Weston has no "default" shader. There is one shader source file, which gets compiled many times with different #defines. Those #defines come from struct gl_shader_requirements.
10:22 soreau: wayfire's default shader is here https://github.com/WayfireWM/wayfire/blob/master/src/core/shaders.tpp#L15
10:23 soreau: but instead of mucking about with the default shader, you can apply your own fullscreen shader with a plugin like this https://github.com/soreau/filters
10:23 soreau: this plugin allows applying a shader to the entire output, or a single surface
10:24 soreau: (directly from a shader file, not compiled upfront)
10:28 soreau: and you'd have a shader kinda like https://github.com/WayfireWM/wayfire-plugins-extra/blob/master/src/keycolor.cpp#L52
10:40 soreau: but, "what's behind" sounds like if you do it correctly, it will show some hidden video
10:40 soreau: so I'd say the shortcut is, just use keycolor plugin on mpv under wayfire and done
10:42 soreau: keycolor shader basically operates on a single toplevel, and replaces one color + threshold, with another color
10:42 soreau: https://github.com/WayfireWM/wayfire-plugins-extra/blob/master/metadata/keycolor.xml
10:43 soreau: plus, I think you can install latest releases of wayfire and wayfire-plugins-extra, and keycolor will be ready OOTB
10:46 soreau: oh, I am wrong about the operation: it takes a color + threshold but only affects the alpha output, not the color
10:47 soreau: so filters plugin would probably be better but it requires latest wayfire git
10:50 soreau: but for the simple purposes of just revealing the hidden message/video, keycolor still might work
11:58 King_DuckZ: soreau: thanks, unfortunately from asking around it seems I'll have a hard time getting wayfire approved as a new dependency, which is a shame because I think that mpv idea is exactly what's required
11:59 King_DuckZ: I think there will be two videos playing, the one at the front will have this chroma key applied and it will be overlayed on top of the "background" video
12:04 pq: King_DuckZ, and the top video cannot come with an alpha channel to begin with?
12:17 King_DuckZ: pq: top video is a regular mp4, I *think* I can access the shader in mpv while it gets played back, I'm just not clear how that shader will interact with weston's, if at all
12:18 pq: it cannot interact per se, they are different processes
12:18 pq: but if it changes the pixels that go into the buffer that weston gets, then yeah
12:19 King_DuckZ: I mean, say my frag shader in mpv outputs (1, 0, 0, 0), does that get rendered to black immediately (because a=0) or does it magically go through weston's shader first?
12:19 pq: in weston, everything goes through weston's shaders, or the equivalent
12:19 King_DuckZ: interesting, thanks for clarifying that!
12:20 pq: I have a hard time imagining how it wouldn't. :-)
12:20 King_DuckZ: so I think the answer is yes, I can set an alpha channel
12:20 pq: cool, then you don't need to hack Weston or any other compositor
12:20 JEEB: pq: magical passthrough somehow? but yea, not weston :)
12:21 King_DuckZ: idk, I might be stuck in DirectDraw's days, but to me the graphics library is something that completely "takes over" the video card
12:21 King_DuckZ: cool indeed
12:21 pq: weston has passthrough, however it also ensures to use it only if it is equivalent (enough) to the shaders
12:22 JEEB: drm interfaces can override other things on screen
12:22 JEEB: something similar to ye olde overlay in dshow
12:22 pq: yeah, except apps won't get access to them
12:23 pq: unless is some vendor-butchered downstream kernel, anyway
12:23 pq: *in
12:23 King_DuckZ: ok, well that's not my case as far as I know
12:24 King_DuckZ: so just having two mpv's playing, with the front one doing the chroma stuff, should just work
12:25 pq: There is no "taking over the video card" in the Wayland architecture by design.
12:26 pq: hardware is fast enough to get stuff on screen without needing to cut corners
12:27 pq: everything has exceptional cases though, like drm-leasing can give a whole output to an app, or a set-top box may want to push 4k video while its GPU cannot even copy so many pixels.
12:29 pq: none of that is reason enough to cut corners, though
12:29 King_DuckZ: yeah it's embedded stuff, but I think it's high power enough, and either way if we want to apply some effects, there's no other way than spending the cpu/gpu time to do so
12:29 pq: yes - unless your display controller could do it
12:29 pq: the not-GPU part
12:30 King_DuckZ: it doesn't, at least that's the premise I was given when they handed this over to me
12:30 pq: alright
12:30 pq: then it should be architecturally "easy"
12:32 King_DuckZ: I tried asking about wayfire btw, they flat-out rejected adding new packages :| no wiggle room there
12:32 pq: Things get complicated, when one wants to off-load things to the display controller in order to not use the GPU, which means the stuff must be off-loaded to the compositor first, and that takes protocol extensions.
12:59 soreau: well, in the case of wayfire filters plugin at least, the shaders and other 'commands' are side loaded through a separate ipc socket, kinda like sway has
13:01 soreau: for the shaders, it just gives an absolute path to the shader
13:04 soreau: King_DuckZ: but it sounds like your task has you painted in a corner
16:36 wlb: weston/main: Marius Vlad * gitlab-ci.yml: Always run container jobs to allow page deploy to work https://gitlab.freedesktop.org/wayland/weston/commit/538146380a7c .gitlab-ci.yml
16:37 wlb: weston Merge request !1540 merged \o/ (gitlab-ci.yml: Remove dependency on docs-build to publish docs https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1540)
17:25 sewn: why does every wayland application seem to have it's own way of doing wl_buffer creation? (eg. shm_open randomized seen in wayland book, memfd_buffer, mkostemp, and the list goes on)
17:25 sewn: it seems to be in EVERY wayland application that wants to make a non-compositor surface, shouldn't it be provided by wayland?
17:36 vyivel: sewn: shm buffers aren't the only type of buffers
17:39 bl4ckb0ne: and there's different ways to open a shm
18:22 sewn: bl4ckb0ne: its almost always the same for most platforms, just needs proper compiler checks and its crossplatform just like that
18:22 sewn: most applications have to do these things themselves
18:35 ids1024_: sewn: I believe the correct way to do it is generally memfd_create on modern Linux and FreeBSD, and shm_open/shm_unlink with a random name on an OS that doesn't support it. But that can be a bit verbose for an example.
18:37 sewn: ids1024_: this makes sense, but i still don't get the reasoning for most wayland applications having to do the same shm or buffer creation for every codebase
18:39 ids1024_: Most applications aren't using Wayland directly anyway. They're using a toolkit.
18:41 sewn: right, and each toolkit has to do the same thing their own way
18:41 sewn: when it's all similar and to achieve the same task
18:50 kennylevinsen: sewn: 1. It’s pretty simple so eh, 2. The Wayland protocol is not limited to one way to do it (what about dmabufs?), 3. libwayland is not that kind of utility lib - that’s what toolkits are
18:50 sewn: ok makes sense
18:52 wlb: weston Merge request !1545 opened by Derek Foreman (derekf) Draft: libweston: Return NULL from creation of animations that have finished https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1545 [libweston API]