05:39 consolers: so on oct i updated from wayland from 1.21.0 to 1.22.0 and the existing wayland firefox --profileManager starts crashing when exiting the profile
05:41 consolers: if I LD_PRELOAD=/usr/lib64/libwayland-client.so.0.21.0 from a preserved lib and run firefox it doesn't segfault
05:42 consolers: how do they manage this
10:11 MrCooper: if a surface commit changes buffer scale, but doesn't attach a new buffer, is the new scale applied to the existing buffer? And is an invalid_size error generated if the existing buffer size isn't a multiple of the scale?
10:12 emersion: i think so
10:25 Company: of, MrCooper is here
10:25 Company: MrCooper: I've had a thought a few days ago and people thought you ight know the answer
10:26 Company: Could it make sense for GTK3's Cairo rendering to VkAllocateMemory a dmabuf as a backing store instead of using wl_shm?
10:32 MrCooper: I don't really see the point: 1) the wl_shm path will always be needed as a fallback, so it results in more code to maintain 2) it's doubtful that it'll make a big difference for performance, and a client with software rendering is kind of a slow path anyway
10:34 Company: the main benefit I was wondering about is large redrawn areas that are quick to redraw
10:34 MrCooper: also, at least with dGPUs, memory which isn't super-slow for CPU rendering is pretty slow for GPU sampling, which might eat up any gains from saving the glTexImage calls
10:35 Company: so where the limiting factor is the amount of copies
10:35 Company: for example scrolling in a fullscreen Gimp window
10:36 Company: Gimp has a backing store, copies it to the cairo surface and then the compositor copies it into the texture again
10:37 Company: same thing with a text editor - that's alpha blending, but it's still limited mostly by memory speed
10:37 Company: at least I think it is
10:41 Company: and I know that jadahl is very sensitive about glTexImage2D() performance - it came up in the GLES discussions a lot.
10:41 Company: so avoiding it seemed like a worthwhile goal to me
10:44 MrCooper: glTexImage being slow is most likely a bug in Mesa and/or mutter
10:44 MrCooper: let's just fix those
12:56 wlb: weston Merge request !1428 opened by zhou liang (zhouliang) backend-drm: fix drm find wrong connector https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1428
17:40 bwidawsk: If a client destroys a popup that current has a pointer, what is the expectation for a leave event to be emitted?
18:46 riteo: oh boy this is going to be a dumb one
18:46 riteo: (this is unrelated to the question above)
18:47 riteo: the dumb question follows: are we supposed to embed the various protocols in the client source code or should we depend on wayland-protocols?
18:47 riteo: (yeah sorry for the suddenness, it makes me look like I was commenting the question above as dumb, which is NOT what I intended)
18:47 emersion: you mean check in the XML?
18:47 riteo: yeah
18:47 emersion: it doesn't really matter too much
18:47 riteo: I've seen some clients do that and others not
18:48 emersion: depending on wayland-protocols makes the updates free
18:48 emersion: and XMLs guaranteed to match upstream
18:48 riteo: mh
18:49 riteo: I've noticed that some older wayland-scanner versions complain about DTD though
18:49 riteo: not sure if that matters
18:49 emersion: complain about DTD?
18:49 riteo: yeah because of the new array_flag functions or something like that
18:49 kchibisov: Usually clients have protocols in source for the ones not in wayland-protocols, e.g. wlr ones.
18:49 emersion: that sounds orthogonal
18:50 riteo: emersion: the DTD thing?
18:50 riteo: kchibisov: if that's the norm I can adapt godot-side
18:50 riteo: might make the PR smaller
18:50 RobertAyrapetyan[m]: Is it possible to force wlroots to emit frames even if image remains static?
18:50 emersion: yeah, depending on w-p is the norm
18:50 bl4ckb0ne: RobertAyrapetyan[m]: thats a question for #wlroots on libera
18:51 emersion: RobertAyrapetyan[m]: the client needs to ask for wl_surface.frame
18:51 emersion: the compositor can't ask the client to redraw
18:51 riteo: I see, thanks for the clarification!
18:51 riteo: I just look for wp with pkgconf, right?
18:51 kchibisov: emersion: I think it's only _yet_ though?
18:52 kchibisov: There was a protocol for GPU resets which basically had a concept like that.
18:52 emersion: riteo: yeah
18:52 emersion: kchibisov: indeed, not merged
18:52 riteo: emersion: great!
18:53 riteo: as long as there isn't some vendoring policy I think that I should manage to shave quite a bit of lines from the PR
18:53 RobertAyrapetyan[m]: emersion: I'm using wlrtoots -> xdg-desktop-portal-wlr -> pipewire pipeline. Which of these should ask for a frame?
18:53 kchibisov: vendoring is usually done in the context of non-c stuff.
18:53 kchibisov: Because you're likely using different scanner, etc.
18:54 emersion: RobertAyrapetyan[m]: ah, important precision. please ask in #wlroots on Libera
19:00 RobertAyrapetyan[m]: <emersion> "Robert Ayrapetyan: ah, important..." <- do you know if there is a bridge for matrix.org available?
19:01 RobertAyrapetyan[m]: RobertAyrapetyan[m]: nevermind, found something, thanks
19:03 emersion: the bridge to Libera has been shut down because it caused too many issues
19:36 roussinm: I am using Weston(10) as a compositor with Xilinx hardware. We face an issue where rendering falls back to mixed mode instead of using plane-only composition. The Xilinx DRM plane initialization (drm_universal_plane_init) uses a NULL as modifiers. Although the DRM format is compatible (RGB565), the modifiers seem to be the root cause. Weston's drm_fb_compatible_with_plane calls
19:36 roussinm: indicate format compatibility, but the modifier is not DRM_FORMAT_MOD_INVALID, and weston_drm_format_has_modifier returns false. This leads to the mixed mode. Manually modifying the code to return true for the correct plane resolves the rendering performance (mixed mode is slower). Is this a Weston problem, or is it more likely an issue with the Xilinx DRM driver's handling of
19:36 roussinm: modifiers during plane initialization?
20:17 daniels: roussinm: it's a Xilinx DRM issue - it needs to support modifiers to have any chance of working correctly
20:38 roussinm: daniels: we upgraded from weston 7 to weston 10, and bunch of other libraries libdrm, etc... but not the kernel. Since the upgrade we lost plane-only composition. I guess some checks must have been added in userspace and prevents use of using it again.
20:40 daniels: roussinm: yeah, if you provide a buffer with an explicit modifier, then we won't try to use implicit modifiers with it ...
20:43 roussinm: daniels: when you said `explicit modifier`, does it mean how xilinx setup the plane with NULL as the modifiers? I think we it used DRM_FORMAT_MOD_INVALID it would be different.
20:43 daniels: roussinm: when you said 'but the modifier is not DRM_FORMAT_MOD_INVALID' (presumably it's DRM_FORMAT_MOD_LINEAR), that's an explicit modifier: the client is telling you which modifier the buffer has
20:44 daniels: DRM_FORMAT_MOD_INVALID is 'who knows what the modifier is, maybe try and guess if you can'
20:44 daniels: and you can't mix the two worlds: if xilinx-drm is saying it can't handle explicit modifiers, then we can't give it a client buffer which was given to us with explicit modifiers
20:45 roussinm: daniels: ok so from weston-debug output I can see the modifiers LINEAR. How is that set if xilinx send NULL, is that libdrm ?
20:46 daniels: roussinm: if it's from a client, it's from ... whatever your client is
20:46 daniels: be that libmali, or GStreamer, or whatever
20:47 roussinm: Ok we use Qt, with mesa, kernel is lima driver. So client is mesa.
20:47 roussinm: if I understand that correctly.
20:48 roussinm: Oh no, you are right, probably libmali from xilinx
20:56 roussinm: daniels: I'm all over the place, probably a bit over my head, but actually mesa is the client.
20:58 daniels: right, in that case it's still the xilinx drm driver which needs to be fixed to handle modifiers to make this work
21:01 roussinm: daniels: what kind of work does that imply? If I wanted to implement modifiers handling in their driver?
21:06 daniels: roussinm: tbh it should just be passing { DRM_FORMAT_MOD_LINEAR, DRM_FORMAT_MOD_INVALID } as the supported modifiers, and returning true to both in the format_mod_supported hook
21:06 daniels: (newer kernels just do this automatically, so I guess the kernel is pretty old)
21:06 roussinm: daniels: 5.4
21:06 emersion: daniels: the kernel doesn't use INVALID to mean implicit
21:07 emersion: KMS cannot say that it doesn't support implicit mods
21:13 daniels: emersion: hrm?
21:14 emersion: daniels: "tbh it should just be passing { DRM_FORMAT_MOD_LINEAR, DRM_FORMAT_MOD_INVALID } as the supported modifiers"
21:18 daniels: emersion: oh right, you mean that it's only LINEAR in the list?
21:18 emersion: yea
21:18 daniels: thanks for the correction :)
21:18 emersion: either way, doesn't matter with the new kernels :)
21:18 roussinm: Looking at the documentation: * @format_modifiers: array of struct drm_format modifiers terminated by DRM_FORMAT_MOD_INVALID
21:19 roussinm: shouldn't I add it anyway? Since I'm not gonna upgrade the kernel atm.
21:19 emersion: oh...
21:19 roussinm: It is used as a sentinel flag or error code.
21:19 emersion: so yeah, INVALID should be in the array, however it's not used to indicate support for implicit mods, it's used to end the list
21:24 roussinm: Since 5.18, apprently LINEAR is the default: https://github.com/torvalds/linux/commit/8be576837b6e62b2ad0de2f9ba31cef618fa2891, it doesn't seem to add the MOD_INVALID, interesting.
21:29 emersion: hm, maybe the kernel docs are out of sync with reality
21:29 emersion: if the size is passed explicitly, no need for a terminating INVALID
21:31 roussinm: Fair.
21:34 bwidawsk: no takers on popup destroy + pointer leave event behavior?
21:45 kennylevinsen: bwidawsk: the same as for any other surface, destroying the role object unmaps the surface at which point focus is lost
21:46 bwidawsk: kennylevinsen: there is verbiage though about not sending a second enter event without a leave in between
21:46 bwidawsk: so I'm confused if a leave should be sent when destroy request comes
21:46 kennylevinsen: wlroots sends a leave event, if the wl_surface is destroyed it's to a nil surface
21:48 kennylevinsen: my point is that this is the same as if you created and destroyed a toplevel, nothing popup specific
21:48 bwidawsk: okay