10:22 King_DuckZ: hey all, I'm trying to figure something out in weston, I understand that fragment.glsl runs once for each window or program doing stuff, that's good
10:23 King_DuckZ: but can one program modify the overall output? for example clear a certain rectangle no matter what?
10:23 King_DuckZ: I guess what I don't understand is where the "compositing" part happens in the compositor
10:25 soreau: if your goal is to render a rectangle of something, you could do it after the rendering has completed for each frame
10:26 King_DuckZ: is there another shader for that step, or where does that happen?
10:26 soreau: libweston/renderer-gl/gl-renderer.c ?
10:26 soreau: seems like the first place I'd look
10:27 King_DuckZ: thanks, I'm looking now
10:28 soreau: the calls containing 'Draw' are typically of interest
10:31 soreau: I think repaint_region is the thing that actually renders the surfaces
10:32 soreau: called only from draw_repaint_node
10:32 King_DuckZ: so am I correct in that each window gets rendered on their own isolated surface, and then there is a final compositing step (repaint_views()?) of all that right before the swap buffers?
10:33 soreau: usually, the surface textures are rendered from bottom to top, on top of each other, to the frame buffer
10:33 soreau: weston might have some optimizations where it doesn't render beneath client-defined opqaue regions, not sure
10:34 soreau: oh right, it does have separate calls for opaque and blend in draw_repaint_node
10:35 King_DuckZ: I implemented a green screen removal thing in fragment.glsl and I know that if I set alpha to 0 I can see whatever is underneath (I play 2 videos on top of each other in my case), so I'm guessing there must be one more step after the shader is run
10:35 soreau: see repaint_views
10:36 soreau: it renders the views in reverse order (bottom to top) and after that, you can render your thing
10:36 soreau: at least, AFAIU
10:38 King_DuckZ: a-ha interesting, so a "view" is what I call a surface
10:40 soreau: but if you just want to replace all green pixels with alpha = 0 or whatever, you should be able to do that in the fragment shader
10:41 King_DuckZ: that's already done yes, it works, just I wasn't clear on the other steps past that stage
10:41 King_DuckZ: for other purposes and to gain a general understanding
10:42 King_DuckZ: it's very useful what you told me :)
10:45 soreau: 👍
19:33 wlb: wayland-protocols Issue #207 opened by Hugo (WhyNotHugo) Allow exposing select priviledged protocols to security-contexts https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/207
19:36 WhyNotHugo: I'd welcome feedback on this proposal ^
19:37 emersion: this was discussed in the issue about wayland protocol security
19:37 emersion: and the current approach was preferred over this one
19:39 emersion: note, there is no use for app_id/etc if the client decides what to expose
19:40 WhyNotHugo: emersion: which issue is that? I didn't find any on the topic
19:41 emersion: https://gitlab.freedesktop.org/wayland/weston/-/issues/206#note_183479
19:41 wlb: weston Issue #206 closed \o/ (A security context implementation for authenticating and/or authorizing clients https://gitlab.freedesktop.org/wayland/weston/-/issues/206)
19:50 WhyNotHugo: From what I see in that discussion, no concesus was reached.
19:51 WhyNotHugo: I don't understand what you mean by "there is no use for app_id/etc". This is required to identify _to which_ client you are granting access.
19:53 emersion: yeah, your protocol is lacking a way to create a socket and uses that instead
19:53 emersion: sounds a bit weird to me
19:53 emersion: anyways, i'm not personally interested
19:53 WhyNotHugo: we already have a way to create a socket.
19:53 WhyNotHugo: the scope here is "I want a sandboxed application to use a single priviledged protocol"
19:54 WhyNotHugo: weird in what way?
19:54 emersion: the sandbox engine needs to use two separate protocols to achieve a single thing
19:55 emersion: and the sandbox engine has global side effects
19:55 WhyNotHugo: I think you're misunderstanding my intent here; I'm doing something separate to security-context-v1, I'm complementing it.
19:55 emersion: yes
19:55 WhyNotHugo: Basically, if I have a running client sandboxed, I'd grant it access to, for example, layer-shell.
19:55 emersion: i don't think that's a good idea for the goal you want
19:56 emersion: sorry, ENOTIME, i'll stop here
19:56 WhyNotHugo: np. I'd like to hear more when you do have time. Cheers!