08:50 staceee: question about viewporter: if the src and dst rectangle ratio missmatch, is the output stretched?
08:50 staceee: or is there some blank space at one corner? if so, is the buffer centered somehow?
08:54 vyivel: staceee: stretched
08:54 davidre: stacee strecthed in my readin
08:54 davidre: > If the destination size is set, it causes the surface size to become dst_width, dst_height. The source (rectangle) is scaled to exactly this size.
08:54 staceee: arf
09:06 staceee: but I should be able to do that with xdg_positionner right?
09:06 staceee: how they would interract with each-other?
09:06 davidre: xdg_positioner is completely orthogonal
09:08 staceee: ah it position xdg_surface, not wl_surface in xdg_surface, right?
09:11 MrCooper: specifically a child relative to its parent
09:11 vyivel: viewport is responsible for mapping a part of a buffer to a surface, xdg_positioner is responsible for providing rules to position a surface in the global space
09:11 vyivel: position/resize, to be precise
09:11 staceee: ok alternatively, can I enforce a window dimension ratio somehow?
09:12 staceee: to be sure it match my buffer ratios
09:12 vyivel: what are you trying to do
09:12 staceee: working on a vnc client. I'm trying to offload the scaling to the compositor, using viewporter. But I don't want to stretch the buffer
09:13 staceee: so either I can position it inside the top level, or I stretch the buffer in a surface with a matching geometry
09:13 vyivel: put the buffer into a subsurface, put viewport-scaled buffer into it while preserving aspect ratio, then center the subsurface within the toplevel
09:13 vyivel: uh
09:14 vyivel: the first part of that sentence doesn't make sense but you get what i mean hopefully
09:14 staceee: mhh
09:14 vyivel:isn't fully awake yet
09:15 staceee: subsurface? is that xdg-shell specific?
09:15 vyivel: nope, see wl_subcompositor in the core protocol
09:16 staceee: okay thanks!
10:07 pq: staceee, FYI, a Wayland client always sets the size of its wl_surfaces. A compositor either uses that, or disconnects the client with a protocol error when the protocol spec mandates so. Size mismatch between compositor and client points of view on a wl_surface simply cannot exist.
10:08 staceee: meant ratio missmatch
10:08 pq: there cannot be a ratio mismatch
10:10 pq: staceee, xdg_surface is an additional interface on a wl_surface. It's not "another" surface as if it had geometry or anything, so there is no concept of positioning a wl_surface in xdg_surface.
10:10 staceee: viewporter would stretch on ratio missmatch
10:11 pq: staceee, only if you tell viewporter to do so.
10:11 staceee: right
10:12 ifreund: the client can also commit a size that does not match what the compositor sent in the configure event
10:12 ifreund: for example, mpv does this to maintain the aspect ratio of its window if it is not tiled
10:12 ifreund: (which does make things quite tricky for the compositor to handle correctly in some cases)
10:13 pq: The sub-surface suggestion is a good one. You can keep your window decorations etc. UI separate from the remote screen contents and off-load the scaling to the compositor. It does raise a question, though:
10:14 pq: What is the benefit of off-loading a VNC screen image scaling to the compositor?
10:17 MrCooper: e.g. it allows the compositor to scan out the client buffer directly in some cases?
10:17 pq: It's from VNC, does it live in a dmabuf?
10:18 pq: Is there GPU-accelerated VNC image decoding?
10:24 MrCooper: admittedly I don't know if there's any VNC client with GPU acceleration, it seems plausible in principle at least though
10:24 MrCooper: even if not though, it means the compositor can scale the buffer contents with the GPU
10:55 staceee: wlvncc got some GPU related feature
10:55 staceee: what I'm primarly trying to do is to support fractionnal scaling
10:55 staceee: on the client side
10:56 staceee: and secondary benefit would be better performance I guess
10:56 staceee: We would skip one scaling, and positionning
10:57 staceee: ifreund, pq, MrCooper ^
10:58 staceee: additional context in the end of the discuss here: https://github.com/any1/wlvncc/pull/36
11:02 ifreund: I think using viewporter here is a good idea
11:04 staceee: but that means we need to use sub-surface if I understood correct. So I need to rework the positionning
11:15 pq: sounds good
14:19 swick[m]: pq, zamundaaa: Anything left to do for the color management protocol?
14:20 swick[m]: we could try to figure out https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/113 first?
14:21 pq: yeah, I was about to work on 113 right now
14:22 pq: https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/108 is a clarification, so no rush.
14:23 swick[m]: ack, let's give us a bit of time to solve 113 then
14:24 pq: https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/99 bt1886 default luminances is still open. Probably inconsequential in practice, but would be awkward to make them conditional on interface version.
14:26 emersion: i would be fine (degrudgingly :P ) with !113 if it didn't make everything inert
14:27 pq: emersion, what would you do instead?
14:27 emersion: same as linux-dmabuf not throwing everything on the floor if the client keeps using an old buffer with a format no longer advertised
14:27 pq: ...wait, that's supposed to work?
14:28 pq: or just silently not work?
14:35 swick[m]: sure, why not? A global is just an object and destroying an object don't have a knock-on effect (if not explicitly defined).
14:36 pq: Does that mean that clients are good to continue using the image descriptions they already got, and creating new ones if they had the old global bound?
14:37 swick[m]: that's how I understand it at least
14:37 pq: What's the expected outcome of that, given the compositor may have lost its capability to use those image descriptions?
14:37 pq: Or should the compositor delay its loss of capability?
14:38 swick[m]: I don't think there is any meaning behind it, it's just how things are, if left unspecified
14:39 pq: What's the incentive for clients to get back to good working state?
14:39 swick[m]: if color management support is supposed to be something that can be removed and added by the compositor, then it's not useful behavior
14:40 swick[m]: I'm just trying to say that I think this behavior just naturally happens if you don't explicitly design the behavior for adding/removing a feature
14:40 pq: AFAIU that's exactly what mahkoh wants, when the end user tells his compositor to switch from a color-managing renderer to one that cannot.
14:41 swick[m]: Yes, but to me it's not even clear if that's a good goal to have
14:41 pq: Me neither, yet I lack solid counter-rationale.
14:45 swick[m]: well, the implementations for it that we could come up with are:
14:45 swick[m]: 1. if a client doesn't handle global remove, everything will become inert and the colors look wrong, (also probably racy even if the client handles the global remove)
14:45 swick[m]: 2. if a client doesn't handle global remove, it will receive protocol errors, but even if it handle it, clients still might because it's racy
14:46 pq: right
14:47 swick[m]: a more fundamental issue: if the compositor stops doing color management, then how does it composite surfaces with already committed image description state?
14:47 pq: badly
14:48 pq: That's a good question to raise.
14:49 pq: I'm running out of time today, let's see tomorrow.
14:49 swick[m]: o/
14:56 ifreund: I'd personally prefer a "manager_manager" object with a destroy event over using global_remove
15:04 wlb: weston Merge request !1685 opened by Michael Olbrich (mol) backend-drm: make sure outputs are enabled during plane assignment https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1685 [DRM/KMS backend]
15:04 pq: We could easily add a "please, stop using this" event in the global interface. Though, clients might not hang on to it to get the event.
15:08 emersion: ifreund: why?
15:09 DemiMarie: pq: I think a renderer with no color management is broken. All renderers should support it.
15:12 pq: DemiMarie, nah, it's a fine design decision to assume everything is in sRGB as long as everything makes the same assumption.
15:25 LaserEyess: maybe a dumb question, but would something like https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/180 help for this? I mean, ultimately, isn't what he wants just some way for the compositor to say "things have changed, make sure you redo your buffers with the new assumptions"?
15:32 ifreund: emersion: it dodges the global_remove race for one...
15:32 emersion: we've fixed the race
15:33 ifreund: oh? do we have something better than delaying the destroy on the server side by a few seconds now?
15:33 ifreund: Maybe that is a 100% fix in practice but it feels ugly to me
15:34 emersion: we could add something in wl_fixes if we wanted to, but shrug, it's good enough
15:34 emersion: we have bigger fish to fry imho
15:34 ifreund: fair
15:36 ifreund: I just can't stop wishing that global_remove didn't exist and we had wl_seat_manager and wl_output_manager objects rather than advertising multiple instances of the same global
15:40 pq: ifreund, what would be the difference?
15:42 ifreund: I think it would be simpler to use and understand for both clients and compositors
15:42 ifreund: having globals follow 3? different patterns of behavior isn't great
15:44 ifreund: (normal advertise once never destroy globals, wl_seat/wl_output "multi" globals, and the third advertise once maybe destroy and re-create kind that color management might and apparently some others are?)
17:07 MrCooper: does any compositor actually send WL_SURFACE_ERROR_DEFUNCT_ROLE_OBJECT?
17:09 MrCooper: git grep comes up empty in mutter, kwin & weston
17:14 ifreund: MrCooper: wlroots code appears to
17:15 MrCooper: good, I wonder if nautilus popups survive that :)
17:19 vyivel: they should
17:29 MrCooper: I mean totem, I wonder if https://gitlab.gnome.org/GNOME/mutter/-/issues/3106 could be due to that not destroying an xdg_popup before the corresponding wl_surface
17:35 vyivel: xdg_popup 🚬
17:36 vyivel: randfall has some xdg_popup clients, you can try that though i don't remember if any of them crashed mutter
17:46 MrCooper: doesn't look like it has the case I'm thinking of (wl_surface destroyed before corresponding xdg_popup)
18:06 soreau: sounds like one for wleird
18:07 soreau: is there any client that allows resize but has max size set?
19:18 YaLTeR[m]: i think i saw one qt client do that
19:40 Ermine: On which channels XWayland releases are announced?
19:52 Ermine: s/channels/mail lists/
20:06 soreau: I think it's xorg-announce ml