08:54jfalempe: mripard, tzimmermann: any objection if I push https://patchwork.freedesktop.org/series/135356/ to drm-misc-next ? Is it still time for v6.11 or it will be for v6.12 ?
08:58mripard: jfalempe: do you have an ack by all relevant maintainers?
08:59mripard: daniels: so, just to confirm what we discussed in private, you don't see anything wrong with the issue templates or process for drm-misc commit rights?
09:01jfalempe: mripard: only one ack from Petr Mladek.
09:02jfalempe: Also Kees Cook proposed to take it in the pstore tree, so I think he agrees with the changes.
09:04mripard: yeah, but it's not really a matter of which tree we merge it through, we can't go around and merge patches affecting other trees without their maintainers consent.
09:06jfalempe: so I should ask for more acks ? not really sure who I need to ask, this touches a few different trees.
09:09daniels: mripard: I’m very happy with it - pick whichever process works best for you and use it - let us know when you need any help but no need for us to have a blocking vote on it or anything
09:37tzimmermann: jfalempe, please get reviews (or at least acks) for the affected subsystems
09:43jfalempe: tzimmermann: Petr Mladek is maintainer for printk where the main change is. other trees are barely affected, but I will ping people and see if I can get more reviews.
09:45tzimmermann: jfalempe, if it's really acceptable, let him pick up the change in his tree
09:46jfalempe: tzimmermann: he said he's in PTO for two weeks, and may miss the merge window, so asked if it can be taken by the drm tree.
09:47tzimmermann: i see. in that case think it should have more acks by the relevant devs
09:48jfalempe: ok
10:02tzimmermann: jfalempe, don't worry. it's likely too late for 6.11 anyway. (definately wrt the DRM trees)
10:04jfalempe: ok, then it's better if it's in the drm tree, so drm panic can use it for 6.12, otherwise it would need one more release.
11:57mripard: tzimmermann: so the commit rights issue stuff seems to be alright with you, and daniels is on board, is it ok for me to push the branch and update the doc?
11:57tzimmermann: mripard, sure
12:25graphitemaster: Is there something more I have to do to get RadeonSI's AMD_DEBUG envvar to work?
12:27kode54: is there a known issue with RadeonSI or radv regarding non-native resolutions in wine apps?
12:27kode54: I have at least one game showing tiling artifacts if I set it to half my native resolution as a "fullscreen" video mode on Wayland
12:27kode54: I had to use INTEL_DEBUG=norcs when I had similar on a DG2 card prior to getting this one
12:28kode54: noccs, my bad
12:34Ristovski: graphitemaster: Do note it used to be called R600_DEBUG on older mesa versions (pre ~2019)
12:34graphitemaster: I'm just trying to dump assembly shaders and I can't seem to get AMD_DEBUG=cs to work at all.
12:35graphitemaster: Unless RadeonSI is using ACO as a shader compiler these days in GL which I don't think is the case.
12:35pendingchaos: maybe AMD_DEBUG=cs,asm
12:36Ristovski: yeah cs,asm works for me, just tested
12:36graphitemaster: Ah you need the asm flag too. Thanks
12:36graphitemaster: There a way to output these to files
12:37pixelcluster: best I can think of is 'command 2> file.log'
12:43tzimmermann: jocelyn, wrt michael's answer, it looks like everyone has a different idea of what is acceptable :)
12:44jfalempe: tzimmermann: yes, I think in this case the main change is in printk, the others are just a function parameter change.
12:45tzimmermann: jfalempe, well then, if no one complains, maybe merge the patches mid-next-week into drm-misc-next
12:46jfalempe: tzimmermann: agreed, thanks :)
13:05tzimmermann: jfalempe, BTW i think i've found a general workaround to the multi-connector-per-crtc problem on ast and mgag200
13:06tzimmermann: i've been able to solve this in the drm probe helpers, with minimal drivers support
13:07tzimmermann: i'll post patches next week
13:07jfalempe: tzimmermann: sounds good, will it have visible impact to userspace ?
13:08tzimmermann: jfalempe, not any different than the current workaround
13:09jfalempe: tzimmermann: ok, nice ;)
13:10tzimmermann: but it's all in helpers. and there will be a kernel config option to flip it on/off
15:48leizhou: New to IRC channel and look for some debugging hints. What I'm doing: 1. QEMU/KVM, linux host and debian guest. 2. Host running weston wayland compositor. 3. Guest uses virtio-gpu/mesa stack to run $vkcube-wayland or $vulkaninfo. 4. Both fail at following spot(wsi_wl_display_init/wl_display_roundtrip_queue) and failure code (VK_ERROR_SURFACE_LOST_KHR). much appreciated!
15:49leizhou: this is gdb debugging info on site.
15:49leizhou: (gdb) n
15:49leizhou: 879 wl_display_roundtrip_queue(display->wl_display, display->queue);
15:49leizhou: (gdb) n
15:49leizhou: 880 if (!display->wl_dmabuf && !display->wl_shm) {
15:49leizhou: (gdb) n
15:49leizhou: 881 result = VK_ERROR_SURFACE_LOST_KHR;
15:49leizhou: (gdb) n
15:49leizhou: 882 goto fail_registry;
15:49leizhou: (gdb) p display->wl_dmabuf
15:49leizhou: $1 = (struct zwp_linux_dmabuf_v1 *) 0x0
15:49leizhou: (gdb) p display->queue
15:49leizhou: $2 = (struct wl_event_queue *) 0xaaaaaac21060
15:49leizhou: (gdb) p display->wl_shm
15:49leizhou: $3 = (struct wl_shm *) 0x0
15:54alyssa: 3/close
16:31mareko: DavidHeidelberg: how to update libdrm in the CI here? https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/merge_requests/94
16:41pepp: mareko: one way would be to add gfx-ci/ci-deb-repo to the debian-install.sh, so you'd get the latest libdrm instead of the debian version
16:42pepp: mareko: I'll give it a try
17:56DavidHeidelberg: mareko: vacation mode :) thou I haven't touch this repo
19:56DemiMarie: It looks like Wayland passthrough with virtio-GPU is somewhat broken.
19:56DemiMarie: The guest has a different device number than the host, so looking up the dev_t fails.