15:43 aktaboot: o/
15:43 aktaboot: I've been encountering an error with wayland, might be a driver issue..
15:43 aktaboot: wl_drm@52: error 0: wl_drm.create_prime_buffer is not implemented
15:44 aktaboot: I am really unsure where I should dig deeper to understand the error, or where to report it
15:44 aktaboot: any help is appreciated :)
15:50 emersion: which compositor?
15:50 ids1024_: aktaboot: What driver is that with? And what compositor?
15:50 emersion: which client?
15:50 emersion: wlroots intentionally doesn't support this request
15:50 emersion: because it uses legacy/insecure GEM names
15:50 emersion: iirc
15:50 emersion: hm
15:51 emersion: might be a different request, seeing "prime" in the name...
15:51 ids1024_: For the most part, drivers/clients should now be using the dmabuf protocol instead of wl_drm. Though things like AMDVLK seem to still rely on it.
15:53 aktaboot: amdgpu driver, I'm using plasma with kwin
15:53 aktaboot: emersion: what do you mean by client ? wayland client ?
15:53 emersion: cc zzag
15:53 emersion: I mean, which app?
15:54 aktaboot: happened with two applications, one is using rust iced for graphics,and changing the iced backend to software rendering make it work
15:55 ids1024_: So is this just all applications using AMDVLK on kwin? Including something like vkcube-wayland?
15:55 aktaboot: the other one is using egui for rust aswell: zed-editor
15:56 emersion: OK, so it's GL or vulkan wsi. are you using Mesa or amdvlk?
15:56 aktaboot: how can I check
15:57 emersion: hm
15:57 emersion: eglinfo maybe
15:58 aktaboot: EGL vendor is Mesa
15:58 emersion: well that's weird
15:58 emersion: which version of mesa?
15:58 aktaboot: this might be a driver issue, since very few seem to encounter it
15:59 aktaboot: or a platform issue
16:00 aktaboot: that's the thing, I'm really unsure where to report it even ...
16:05 aktaboot: oh sorry I missed the question
16:05 aktaboot: Mesa 24.0.5
16:06 aktaboot: OpenGL 4.6
16:09 ids1024_: I don't know about egui, but Iced should default to using Vulkan if available.
16:09 ids1024_: So I'd check vulkaninfo too.
16:13 aktaboot: sure, anything to check for in particular
16:16 emersion: the driver name I'd say
16:25 aktaboot: I couldn't find any of RADV, AMDVLK in vulkaninfo output
16:26 alice: could you pastebin it
16:27 aktaboot: https://0x0.st/XKsu.txt
16:28 ids1024_: "AMD open-source driver" = AMDVLK, I think.
16:29 aktaboot: hardware is: AMD Ryzen 7 7840U w/ Radeon 780M Graphics
16:29 alice: driverInfo = 2023.Q4.2
16:29 alice: yeah it's amdvlk
16:29 alice: https://github.com/GPUOpen-Drivers/AMDVLK/releases/tag/v-2023.Q4.2
16:29 alice: hehe
16:30 alice: well you can try install the mesa vulkan drivers instead, idk how that's done on your distro
16:30 ids1024_: That's what I thought, since RADV shouldn't be using that wl_drm call unless its an old version or the compositor doesn't support the dmabuf protocol.
16:31 aktaboot: mesa vulkan drivers = radv ?
16:31 alice: yea
16:31 aktaboot: thanks!
16:31 alice: usually named something like mesa-vulkan in distro packages
16:31 ids1024_: RADV is the Mesa Vulkan driver for AMD
16:31 alice: which distro do you use
16:31 ids1024_: Hopefully AMDVLK will eventually move to the dmabuf protocol and have fewer issues: https://github.com/GPUOpen-Drivers/pal/issues/96
16:32 alice: yep
16:32 aktaboot: i'm running nixos
16:33 aktaboot: hmm it should be radv by default
16:33 alice: i think you just have to remove amdvlk from hardware.opengl.extraPackages then or whatnot
16:33 alice: unless you never configured anything and got amdvlk somehow
16:34 alice: regular radv should be default
16:34 aktaboot: yeah I have amdvlk installed for some ancient games running on wine, but that might not be required
16:35 alice: probably isn't
16:38 aktaboot: well thanks a lot! that really helps, will look into what dmabuf is compared to wl_drm
16:39 aktaboot: heh i recognise the username https://github.com/GPUOpen-Drivers/AMDVLK/issues/351
16:45 aktaboot: that fixed it!
16:47 alice: nice :)
17:34 zzag: emersion: kwin provides a dummy implementation of wl_drm to expose the information about the render device because xwayland used to need it
17:35 zzag: we plan to drop the support for wl_drm
17:35 zzag: or do I understand correctly that we cannot do it?
17:36 zzag: re wl_drm: more info: kwin posts protocol errors in all factory functions
17:36 zzag: only the device event and some other associated stuff with it is implemented
18:38 wlb: wayland Merge request !394 opened by Kirill Primak (vyivel) server: expose wl_resource_post_error_vargs() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/394
18:52 HildarThedorf: Hello, is this the right place to ask a question about the xdg-shell protocol?
18:55 vyivel: yes
18:56 emersion: zzag: wlroots used to do the same, but we don't enable wl_drm by default anymore
18:57 HildarThedorf: How am I supposed to interpret the following sequence of xdg shell events: xdg_toplevel.configure_bounds(750, 550), xdg_toplevel.configure(0,0,...), xdg_surface.configure(), xdg_toplevel.configure(800,600,...), xdg_surface.configure(). This to me seems to be asking me to resize my surface to a size that violates the configure_bounds I was given?
19:00 vyivel: a compositor shouldn't really send this tbh, but i'd use the 800x600 size
19:00 HildarThedorf: That's what kwin is sending me when I switch to fullscreen. >.>
19:01 zamundaaa[m]: HildarThedorf: configure bounds is the maximum recommended size for when you create a window without special states
19:01 zamundaaa[m]: It's not a size limit, and the fullscreen size is expected to be different
19:02 zamundaaa[m]: In most cases the configure bounds is the size a maximized window would have, so the screen size minus panels and decorations
19:03 vyivel: ah so those are two separate configures
19:03 HildarThedorf: Yeah, that's indeed what it is, the size of my screen minus the taskbar on the left side, and (if enabled) server-side decorations at the top.
19:04 HildarThedorf: Should I 'forget' any state sent from the previous configure sequence? Or is the configure_bounds still 'alid' but overruled by the explicit size in toplevel.configure?
19:04 HildarThedorf: *valid
19:05 vyivel: it applies to the 0,0 case aka "pick the size yourself", if you're sent a specific size just use that
19:05 HildarThedorf: Okay, thank you for the help!