08:35 pq: zamundaaa[m], RAOF, I totally agree with your opinions in the xdg-placement discussion, FWIW.
08:35 pq: I don't intend to get more involved than I already have.
08:51 pq: we have so many wl_proxy_marshal_*() functions it's hard to tell which ones are the latest recommended ones
09:11 zzag: The satellite window idea is interesting
13:45 JoshuaAshton: Has anyone considered adding 64-bit types to Wayland? It would obviously be a big change, and need a newer libwayland for newer protocols, but I think we use enough 64-bit types that it would be justified? Very often we are doing _lo and _hi for serials, timestamps, etc.
13:47 soreau: what's the use case?
13:47 soreau: seems like there would be twice the overhead on the socket for no real gain
13:48 kennylevinsen: the wire protocol could just be 2x 32-bit
13:48 JoshuaAshton: The usecase would be stuff we are already sending uint64_ts now but as separate hi and lo parts
13:48 JoshuaAshton: The wire protocol already is that, but we do it often enough that it really should be first-class imo
13:49 kennylevinsen: Main point is "what would be gained by the libwayland breakage that two 32-bit ints does not handle"
13:49 ascent12: It's mentioned here https://gitlab.freedesktop.org/wayland/wayland/-/issues/247
13:49 ascent12: Basically, not worth the breakage just for that. Maybe worth sneaking in if there was a breakage for something else.
13:50 JoshuaAshton: I mean, not really "breakage" if nothing existing breaks. It would only be an incompatibility with newer protocols.
13:50 kennylevinsen: ABI breakage
13:50 ascent12: ^
13:51 ascent12: See 'union wl_argument'
13:51 JoshuaAshton: I see, that would break ABI on 32-bit
13:51 JoshuaAshton: bleh
13:51 JoshuaAshton: Welp
13:52 pq: unless the u64 is behind a pointer, which is also bleh
13:52 pq: but wouldn't hurt the user facing generated API
13:53 kennylevinsen: it's hard to justify breakage when it does not enable something new :(
13:54 pq: well...
13:54 pq: maybe it would be worth it, and not hurt anythin
13:55 jadahl: maybe it can be 64 bit in the xml and generatec C API, with wayland-scanner hiding the hi/lo boilerplate. sounds complicatedt though
13:55 pq: that's an alternative
13:56 pq: or we can have union wl_argument { ... uint64_t *pu64; };
13:56 jadahl: zamundaaa: thanks for arguing for sanity btw. i'm on pto so keeping to the sidelines until i actually have time
13:56 pq: we already have a pointer in that union
13:58 pq: negotiation for uint64 support would be really simple: a server just won't advertise and a client just won't bind a global that would use u64 if libwayland is too old.
14:00 pq: I don't see any technical problem adding a 64-bit wire datatype. Or float types.
14:09 JoshuaAshton: I didn't even realise wl_argument was ABI
14:09 JoshuaAshton: I guess it is in wayland-util.h yeah
14:10 pq: it's used by probably all other language bindings than wayland-scanner's
14:12 JoshuaAshton: I recently did a VK_GOOGLE_display_timing impl for Gamescope and was like... hmmm... lots of _lo and _hi here :P
14:12 JoshuaAshton: I imagine satisfying for VK_EXT_present_timing would be even more lo hi x)
14:15 pq: I wouldn't nak the addition of uint64_t, float or double in wire types.
14:17 JoshuaAshton: That's good to know. I think I'd want to use float types at some point for gamescope private protocol with Steam someday :)
14:18 JoshuaAshton: Right now we are using properties on the root XWayland server window and just bitcasting floats there, which is kinda gross, but works
14:18 JoshuaAshton: Wanting to move away from that... slowly
14:18 pq: IIRC I'm already using floats, just wrapped in a wl_array...
14:18 JoshuaAshton: Oh? How does that work, are you just bitcasting as some generic 32-bit type?
14:18 JoshuaAshton: Never touched wl_array actually
14:19 pq: wl_array on the wire is essentially a bag of bytes
14:19 pq: wl_array C API kinda assume you have an array of <any C type>, but it could also literally be a bag of bytes
14:21 pq: JoshuaAshton, https://gitlab.freedesktop.org/wayland/weston/-/blob/main/clients/touch-calibrator.c?ref_type=heads#L387-402
14:22 pq: wl_array on the wire has a little bit of overhead: the size
14:22 pq: since the size is variable
14:23 pq: weston_touch_calibration_save() is a wayland-scanner generated request sender
14:24 pq: server side: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/touch-calibration.c?ref_type=heads#L582-608
14:25 pq: ooh, I think I saw a bug
14:29 Company: swick[m], robertmader[m]: re https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/441#note_2106725 - it would be convenient if that layering stuff wouldn't need to be managed by creating subsurfaces, but applications could just submit multiple buffers for the same surface
14:29 Company: if you combine that with wp_viewporter's positioning, it's already good enough for video playback
14:30 pq: Company, what would that do, and how is it different from sub-surfaces?
14:31 Company: pq: it's different from subsurfaces in that I don't need to manage the subsurfaces and don't get into stacking and input games
14:32 Company: pq: and it would just composite the N buffers on top of each other - with potential offloading to hardware and all that jazz
14:32 pq: so how would you manage the multiple buffer on the same wl_surface?
14:32 pq: what kind of protocol interface, and how would that differ from wl_subsurface?
14:33 Company: dunno, something like surface_attach_with_z (int z_index, wl_buffer buffer)
14:34 pq: how do you move/position them?
14:34 pq: (hint: we are on the road to re-invent wl_subsurface here)
14:35 Company: like wp_viewporter does, jsut again with a z-index
14:35 pq: wp_viewporter ties to the wl_surface and has no z-index
14:36 Company: right, you'd need a new function for that
14:36 pq: why not use an actual protocol object instead of a z-index that could easily be lost track of?
14:37 Company: could make it an actual object, too
14:37 pq: why should that protocol object duplicate the attach and other requests from wl_surface when it could, well, tie to an actual wl_surface?
14:38 Company: because a wl_surface does tons of other stuff
14:38 pq: it doesn't, really
14:39 pq: not much
14:39 Company: but you could try to do it with subsurfaces - or a new role - too
14:42 pq: in the end, I think what the protocol looks like here is small peanuts, and the hard part is in the client to choose the scenegraph splitting points and render the different buffers.
14:42 Company: there's just a bunch of things that need updating on the surface (like buffer scale and size) that would be bound to the actual surface if this was just about buffers
14:43 pq: true
14:43 pq: and hardcode input region to empty
14:43 Company: yes and no - GTK manages surfaces in a different part of the code than rendering
14:44 Company: and rendering would be the part that decides how to split, so would need to create the surfaces
14:44 pq: oh, so you just wanted something that fits better your internal architecture
14:44 Company: of course :)
14:44 Company: I was actually wondering if this was a general thing
14:45 Company: I have no idea how other toolkits or Firefox or compositors do this
14:46 pq: me neither, but I wouldn't want to add protocol interfaces that are just sub-sets of already existing interfaces that would work just as well from protocol design point of view.
14:47 daniels: yeah, especially when you attach HDR metadata to your YUV surface and now your RGB subtitles are unreadably bright
14:48 Company: right, HDR metadata would need to be per-buffer
14:48 pq: heh, somehow I didn't even think of that :-D
14:49 pq: color metadata is per wl_surface for now
14:49 Company: the Wayland protocol has struggled with per-buffer vs per-surface more than once
14:50 Company: but yeah, you need to negotiate the color stuff in advance
14:50 pq: is there actually any API (GL, Vulkan, ...) that would associate color metadata with buffers?
14:50 pq: a Wayland WSI could always do it for you, but...
14:51 Company: I think Vulkan only has color metadata in the swapchain
14:51 Company: apart from the RGB texture formats
14:51 pq: and EGL does not expose buffers at all
14:51 Company: *sRGB
14:51 Company: but I guess the sRGB texture formats count as per-buffer color metadata?
14:52 pq: I suppose
14:54 pq: given we have the wl_surface.commit mechanism, surface vs. buffer doesn't make that big a difference. But being on surface means that you can, if you want to, manually manage the color metadata EGL Wayland platform.
14:54 Company: I mean, the end goal here is to create an app window with UI and an image that sits in a dmabuf
14:54 Company: either video or from a VM
14:56 Company: and being able to seamlessly transition back into compositing into a single surface
14:56 Company: like when switching tabs in the app
14:59 daniels: subsurfaces do let you do that
15:05 Company: I'm just thinking
15:05 Company: we could let widgets reserve surfaces with the renderer
15:06 Company: and if the renderer determines that it can't use the surface - for example because the contents are rotated or otherwise not easily blendable - we skip the surface
15:07 Company: just unset the surface's buffer
15:07 Company: and composite onto the toplevel
15:13 pq: Company, the decision to off-load an element as a (sub)surface to the compositor should not be "can I do it" but more of "how likely this could benefit from direct scanout".
15:14 Company: sure
15:14 Company: it's a combination of both really
15:15 pq: naturally :-)
15:16 Company: but just like with direct scanout, the "can I do it" part is something you need to determine automatically, and not via some app-level setting
15:17 pq: what app-level setting?
15:18 pq: I mean, indeed
15:40 wlb: wayland-protocols Issue #159 closed \o/ (Make inlined methods accessible for other compilers than gcc or clang. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/159)
17:10 swick[m]: Company: I don't really get why it would be so hard to create subsurfaces on demand with gtk
17:43 lileo: > and if the renderer determines that it can't use the surface - for example because the contents are rotated or otherwise not easily blendable - we skip the surface
17:43 lileo: That has to be a compositor decision, no? whether direct scanout can happen depends heavily on the display hardware
18:04 swick[m]: this is about gtk deciding to render the entire tree into a single surface or parts of the tree into subsurfaces
18:11 lileo: ah
18:14 lileo: the decision to make here sounds quite similar to what libliftoff does on the compositor side
18:33 swick[m]: not really. libliftoff is concerned with figuring out if you can put something on an overlay plane. a compositor still has to provide planes to libliftoff. for gtk the hard part is figuring out what parts of the render tree should become surfaces/planes.
18:38 lileo: right, libliftoff today just tries to maximize hw plane usage with whatever it's given. Though theoretically, it has kind of a similar problem
18:38 lileo: compositors can create an arbitrary number of layers, while there are only a few hw planes available
18:38 lileo: So it's important to select the most beneficial layers
18:39 lileo: there's some code there that elevates a layer's offload priority if it's updating frequently
18:39 lileo: but not used anywhere
18:50 kennylevinsen: I wonder if it just boils down to a threshold for update rate for certain widget types, or even just always for those widget types in some contexts…
19:56 swick[m]: I think that's spot on. Some kind of update frequency estimate provided either by the user or by some widgets. E.g. a video widget can guess that subtitles update every few seconds and the video itself around 30 times.
20:15 Company: swick[m]: I have no idea how expensive surface creation is
20:16 swick[m]: shouldn't be expensive...
20:17 Company: and how much work is involved there - like if setting sizes and such is just a bunch of commands or if roundtrips are required
20:18 swick[m]: you probably know all the things you care about from the toplevel so it should just be a bunch of requests without roundtrip
20:18 Company: and of course, there's the Vulkan/GL wsi
20:18 Company: which isn't built around rendering to multiple surfaces at once
20:19 swick[m]: don't use it :>
20:19 Company: I will consider that once the dmabuf code is not a huge amount of magic
20:20 swick[m]: nice
20:21 Company: I've been wondering about using GTK without a display anyway
20:21 Company: to be able to do rendering
20:21 Company: so having generic GL would be neat
20:23 kennylevinsen: creating a surface is free, issue is allocating a buffer and rerendering - need to be a bit smart about it
20:24 Company: true, if there's too many surfaces and we create swapchains for each, we might allocate a bit much memory
20:25 swick[m]: thus, no wsi
20:25 Company: well, even without wsi we run into that issue
20:25 Company: the biggest benefit of avoiding wsi is that we can resize
20:25 swick[m]: well, the buffers can be added to any surface instead of being bound to a specific one
20:26 Company: that too
20:26 Company: we have to send one per surface to the compositor though
20:26 swick[m]: and be lazy with allocating I think
20:27 Company: doesn't GL do that?
20:27 swick[m]: yes, but not vulkan
20:27 Company: Vulkan doesn't I think
20:27 swick[m]: iirc there was an extension to allow this
20:27 Company: I'm sure there was
20:32 Company: hrm, can you do a fade-in by keeping the buffer and changing the colorspace every frame?
20:32 Company: I guess?
20:32 swick[m]: yes
20:32 swick[m]: please don't
20:34 Company: for (nits = 0; nits < 1000; nits += 1000/framerate) { ... }
20:35 Company: I think that doesn't handle transparency properly anyway
20:43 swick[m]: creating image descriptions is probably much more expensive than creating surfaces
20:44 kennylevinsen: There was a talk about an opacity protocol to not need rerender I think
20:51 Company: there's talk about many protocols
20:52 Company: like reddit is talking about a window placement protocol
20:57 bl4ckb0ne: this? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247
20:58 Company: yup