17:21rodrigovivi: any public list of registered XDC attendees?! I just registered myself...
17:35HdkR: There's at least dozens of us
19:20mupuf: ha ha
19:21mupuf: isnt the list public on the XDC website?
19:27HdkR: mupuf: Not yet
19:43radiumatic: Hello,
19:43radiumatic: I'm sorry if this is the wrong room, but I have an issue with the r600 driver, Chromium and Wayland. I thought it's better to ask opinions here before I try to make a bug report. My GPU is a TeraScale 2. Elements randomly flicker between their old and new states. It doesn't happen with Xorg, XWayland, llvmpipe or Swiftshader. (the Chromium software renderer)
19:43radiumatic: Using --disable-gpu-compositing also hides the problem. I tried these and they had no effect:
19:43radiumatic: mesa_glthread=false
19:43radiumatic: vblank_mode=0 and vblank_mode=3
19:43radiumatic: R600_DEBUG=nodma
19:43radiumatic: R600_DEBUG=notiling
19:43radiumatic: R600_DEBUG=nosb
19:43radiumatic: R600_DEBUG=nocmask,nohyperz
19:43radiumatic: MESA_EXTENSION_OVERRIDE="-EGL_EXT_buffer_age -EGL_KHR_partial_update -EGL_EXT_swap_buffers_with_damage -EGL_KHR_swap_buffers_with_damage"
19:43radiumatic: MESA_EXTENSION_OVERRIDE="-EGL_KHR_image_base -EGL_KHR_image -EGL_EXT_image_dma_buf_import"
19:43radiumatic: --disable-gpu-vsync
19:43radiumatic: --disable-gpu-rasterization
19:43radiumatic: --disable-dma-buf
19:43radiumatic: --ui-disable-partial-swap
19:43radiumatic: --disable-partial-raster
19:43radiumatic: --disable-gpu-memory-buffer-compositor-resources
19:43radiumatic: --disable-zero-copy
19:43radiumatic: --double-buffer-compositing
19:43radiumatic: --enable-hardware-overlays=""
19:43radiumatic: --use-cmd-decoder=validating
19:43radiumatic: --disable-gpu-driver-bug-workarounds
19:43radiumatic: --single-process
19:43radiumatic: --gl=egl-angle --angle=opengl
19:43radiumatic: --gl=egl-angle --angle=opengles
19:43radiumatic: --gl=egl
19:43radiumatic: --disable-features=DelegatedCompositing
19:43radiumatic: --disable-features=HardwareOverlays
19:44radiumatic: --disable-features=PartialSwap
19:44radiumatic: --disable-features=WaylandPerSurfaceDamage
19:44radiumatic: --disable-features=WaylandLinuxDmabuf,WaylandLinuxDrmSyncobj
19:56mupuf: HdkR: oh, weird! mfillion must have hidden it on purpose. For now, we have fewer attendees than I would expect... so people should register themselves :)
19:58alyssa: Come to Toronto we have uhh
19:59alyssa: ravines
19:59alyssa: and cheaper rent than Bosotn
19:59Sachiel: Bosotn
19:59HdkR: Come for the poutine at least
19:59alyssa: and government service centres that you can demand to speak French at
20:00alyssa: (even though there are 0 native French speaking employees and thre's a good chance French is the 3rd language of the person who helps you)
20:00radiumatic: Sorry, I've never worked with IRC before. Will the server store the messages I sent? Can I disconnect now?
20:00alyssa: HdkR: nah go to Montreal for that
20:01HdkR: radiumatic: Yes, but you also won't be able to see the responses
20:02HdkR: radiumatic: #radeon is probably the better channel for the question, although might have crickets responding there as well
20:02pixelcluster: (you can view them if you go look for them on a public mirror of this channel, for what it's worth)
20:02alyssa: radiumatic: https://oftc.catirclogs.org/dri-devel/2026-08-25 public logs here if you do disconnect
20:03radiumatic: Thank you. Is it bad manners to copy my message over to the radeon channel?
20:06pixelcluster: radiumatic: no, feel free to do that
20:06pixelcluster: one tip i would have is to skip over all the options you tried except for R600_DEBUG in order to keep the message a bit more condensed
20:12HdkR: alyssa: But Montreal is so far away and I'll be in Toronto already :P
20:14alyssa: HdkR: me constantly
20:15radiumatic: The file on Gitlab said people check in on the chat at different times. How does that work if IRC doesn't save messages?
20:16HdkR: radiumatic: We never disconnect
20:16pixelcluster: many people have so-called "bouncers" active
20:16pixelcluster: these bouncers keep the connection to the irc server alive and store incoming messages for whenever the actual user may return
20:18radiumatic: Do you think I'd get any answer to my question? Should I create a bug report instead?
20:19pixelcluster: as Venemo said over in #radeon it's probably indeed best to create an issue on https://gitlab.freedesktop.org/mesa/mesa/-/work_items
20:23radiumatic: I missed the message. I was probably disconnected.
20:24mareko: we do have ravines and forests inside the city
21:22airlied: mripard, mlankhorst : hey so is drm-misc-next-fixes always maintainer only?
21:51Lyude: drm-tip rebuild issue, will have it fixed in just a moment
21:58Lyude: fixed
22:34Plagman: maybe better channel for this: was there ever a bug about xlib-xcb deadlocking if two threads call XOpenDisplay simultaneously? does that ring any bells?
22:46zmike: that maybe sounds a little familiar
23:06jannau: Plagman: should be either in a vk-gl-cts bump MR this spring or linked from there
23:13Plagman: :eyes:
23:15jannau: Plagman: I misremembered. I was thinking of https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15116 which is something else
23:15Plagman: ah, thanks for trying though, appreciate it
23:21HdkR: Ask them politely to stop contending the display.
23:22HdkR: Maybe we can just slam a mutex in to XOpenDisplay
23:37karolherbst: wasn't somebody talking about clients with two X connections somewhere?
23:37karolherbst: like recently?
23:39karolherbst: ah yeah somebody asked on #xorg-devel about it a few weeks ago and apparently it's a supported thing
23:48Plagman: yeah i think it's not as simple as adding a mutex somewhere, it seems like one of the opens is getting hosed in some way and never returning
23:53airlied: could just be traditonal memory corruption, if it started happening since a new xlib, it could be we started to call XInitThreads
23:56Plagman: yeah maybe something messed with the fd of one of the opens