00:41 jenatali: Ugh, silly bridge not authenticating for me...
00:41 jenatali: Anyway, \o/ GL4.4 is dine
00:41 jenatali: Done*
00:41 karolherbst: noice
00:41 karolherbst: congratz
00:41 jenatali: Should probably be able to get 4.6 next week :)
00:45 kisak: historically, 4.5 -> 4.6 is not an easy increment
00:45 jenatali: kisak: For new drivers inside Mesa? Or just for GL drivers in general?
00:46 jenatali: Seems like the hard part is SPIR-V, which... seems like it should be pretty straightforward
00:46 kisak: I'm going off memory and the time it took for other drivers in mesa to get it bolted together
00:48 jenatali: Right, seems like the first one or two is where the difficulty would be. I'm hoping that I can just leverage the infrastructure that was built at the time
00:59 mareko: should be easy now
16:58 strobo5: hi
17:00 strobo5: first time here - I'm looking into the VC4 KMS kernel driver and I think this might the right place to ask for help. I'm just learning about DRM.. and trying to solve an issue
17:00 strobo5: right now I'm trying to get the current content of 'drm_connector_state' in the VC4 driver, but I think with libdrm from user space I can't do that, or can I?
17:28 emersion: strobo5: can you explain what you're trying to do? what info do you need from where, and why?
17:41 strobo5: emersion: sure! The issue is that the margin setting on the composite video output does not seem to work. It's a Raspberry Pi. Its firmware passes this to the kernel: 'video=Composite-1:720x576@50i,margin_left=96,...', and I want to see if it becomes part of any of the driver's data structures.
17:42 strobo5: What I understand is that each connector has these margins in its 'drm_connector_state', and the CRTC queries these when it is attached to that connector
17:42 emersion: oh, so you don't need to actually access anything from libdrm
17:42 emersion: just debug the driver
17:43 emersion: hm, i've no idea how that gets passed down to the driver
17:43 strobo5: I guess user space does not or should not know about these margins and lets the driver handle it?
17:44 emersion: yeah
17:46 strobo5: makes sense!
17:47 strobo5: thanks for your 2020 foss-north presentation btw, this was a nice intro for looking at things from user space :)
17:47 emersion: it seems to be handled in
17:47 emersion: drm_modes.c:2214: } else if (!strncmp(option, "margin_left", delim - option)) {
17:47 emersion: oh - glad to hear it's useful! :)
17:48 emersion: i should update it with latest libdrm functions
17:48 emersion: i've introduced a few helpers which simplify things
17:49 strobo5: cool!
17:55 strobo5: I think this function in drm_modes.c is what I had seen in one session and was never able to find again :D
19:11 strobo5: hmm so during drm_connector_init(), the kernel cmdline is checked for these options, but this doesn't seem to work - in dmesg with enabled DRM_DEBUG_KMS printks, I see "looking for cmdline mode on connector 51" and it seems to find none
19:12 strobo5: to further investigate this I would add more DRM_DEBUG_KMS("") - is this the way to go?
19:14 emersion: yeah, or some more printk
19:16 strobo5: alright, that's for tomorrow though, thanks for helping :)
19:16 emersion: np!
21:54 i509vcb: eglCreateSync states that the default value of EGL_SYNC_STATUS is EGL_UNSIGNALED. However it seems that when I create an EGLSync and check if it is signalled immediately EGL says the signal is already signalled
21:56 i509vcb: eglClientWaitSync however does behave correctly
22:30 i509vcb: Mesa seems to do a client wait under the hood when checking if a sync is signalled immediately after creation? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/egl/main/eglsync.c#L126-133
22:37 HdkR: i509vcb: If you follow the chain, it ends up going all the way to the driver backend to set if it is signaled or not. So backend driver bug?
22:37 i509vcb: I think it's a driver bug from a bit more stepping
22:38 i509vcb: Although it's occuring on asahi and amd
23:53 i509vcb: I'm struggling to find documentation for drmSyncobjWait