10:09 hummer12007: a stupid libdrm question: why does drmModeGetProperty blob for a connector's EDID return NULL, while /sys/class/drm/<connector>/edid file has the EDID?
10:10 emersion: hm, can't think of a reason why this would happen
10:10 emersion: maybe invalid prop ID or object ID?
10:11 emersion: do you see the EDID with drm_info?
10:11 hummer12007: yes, i figured i fucked up somewhere in my code
10:14 hummer12007: here's the code in question: https://paste.sr.ht/~hummer12007/9804ee1cfe61d43201e4586e785e6abf1b802aa1
10:15 hummer12007: i'm passing the prop_id as returned by drmModeGetProperty
10:25 sima: hummer12007, you're missing one indirection
10:25 sima: the property id isn't the value, just the id of the property
10:25 hummer12007: yeah, i found an example on getting the blob id
10:25 hummer12007: thanks!
10:26 sima: so you need to take what your get_property_id() returns, ask the connector for the value of that property
10:26 sima: and then use that value as the blob id
10:26 sima: hummer12007, nw
10:26 sima: was just worried for a moment that you've found a really hilarious kernel bug, they do happen :-)
10:36 hummer12007: and another stupid question i had: can i get the corresponding connector name (card0-DP-1 etc.) with the connector object?
10:37 hummer12007: except by enumerating /sys/class/drm/*/connector_id
10:43 emersion: drmGetDevice2() can give you "card0"
10:44 emersion: there is a type field in drmModeConnector, and a libdrm function to get the type string
10:44 emersion: there is "connector_type_id" which gives you the "1"
10:45 emersion: out of curiosity, why do you need to access sysfs? for i2c related things?
10:53 hummer12007: yeah, i want to get the i2c bus
10:53 emersion: makes sense
10:54 hummer12007: i wasn't sure if the numbering is shared or not on multi-gpu systems so i didn't want to make assumptions on that
10:58 emersion: it is shared
10:58 hummer12007: ack
10:58 hummer12007: ah
10:58 hummer12007: connector_type_id
10:59 hummer12007: thanks!!
10:59 emersion: IWO, DP-1 is enough to identify a unique connector on multi-GPU setups
10:59 emersion: it's first come first served
10:59 hummer12007: not persistent though
11:00 ukleinek: ..ooOO(persistent while the driver is bound)
11:01 hummer12007: it depends on gpu probe ordering from what i understand
11:01 hummer12007: so as soon as you reboot it might change
11:02 emersion: correct
11:22 dolphin: hummer12007: As far as I know, you can use /sys/bus/pci/devices for locating connectors per device
11:22 dolphin: and /dev/dri/by-path if you know the target system runs specific udev config
11:23 hummer12007: i'm not sure if it'll work with mst setups
11:24 dolphin: I would expect a single PCI driver instance to still own them
11:24 dolphin: (under /sysy/bus/pci that is)
11:25 dolphin: but that is slightly beyond my expertise, so can't say for sure. I would only expect hotpluggable GPUs to maybe be difficult to locate that way
15:43 rodrigovivi: sima airlied: gentle ping on this: https://lore.kernel.org/intel-gfx/Z2WB9KDsuRN-xgo-@intel.com/ any issue there? I'm going to do the PR for both drm-xe-next and drm-intel-next today, but I'm not sure if I should do a PR for drm-intel-next with full long or on top of this previous one...
15:46 sima: rodrigovivi, might just have fallen through cracks, somehow I didn't get a pile of mails from lore despite that the archive has them all
15:47 sima: rodrigovivi, nah so I got both those and your follow-up
15:47 rodrigovivi: sima, cool then, thank you!
15:48 sima: hm fdo patchwork has it too (that's the one airlied checks I think)
15:48 sima: rodrigovivi, let me do some pr processing
15:57 sima: rodrigovivi, looks all fine to me, I guess airlied just missed it
15:58 sima: or maybe wanted to delay due to the drm_connector_dynamic_init rework that went in through drm-misc (there was a conflict)
18:45 rodrigovivi: sima: thank you... will prepare the following up, and last one of this round right now...
19:37 sima: rodrigovivi, airlied ok pushed it now, got a bit distracted
19:39 rodrigovivi: sima: now worries, I assumed you had left that for tomorrow because of the conflicts, but I did the PR now considering you would get that first... thank you
21:02 lynxeye: zmike: What's the process to get a trivial OpenGL registry fix like https://github.com/KhronosGroup/OpenGL-Registry/pull/639 merged?
21:24 zmike: lynxeye: the working group meets regularly and oddhack merges trivial stuff independently
21:34 soreau: how is weston able to run in wslg with the 'native' gl/d3d12 driver but wlroots gles renderer fails gbm_bo_create?
21:35 DemiMarie: Is every major GPU able to import linear buffers that are 256-byte aligned, have row pitches that are a multiple of 256, and have no more than 255 bytes of padding per row?
21:35 soreau: alternatively, is there a way to run a wayland compositor with gles on zink on dzn in wslg?
21:37 soreau: (I guess the former should be a #wlroots question)
21:54 jenatali: soreau: d3d12 doesn't do gbm?
21:56 soreau: idk, you tell me
21:57 jenatali: I'm telling you, it doesn't
21:57 soreau: oh
21:57 soreau: so weston uses the 'magic' of freerdp-server gfx redirection?
21:58 jenatali: Yeah IIRC it uses "RAIL" to basically do rdp remoting of individual windows. The bits for the window flow over a network channel to the host instead of shared memory
21:59 soreau: ah ok
21:59 jenatali: And for cross-process stuff within the host it's all just plain shared system memory, no dmabuf or anything else
21:59 jenatali: Er, within the gues*
21:59 jenatali: guest*
22:01 soreau: some folks managed to build wslg with udmabuf config and get wayfire running with udmabuf allocator in software llvmpipe, but I was wondering how weston seems to use the GL driver and not fail on gbm.. but I guess it's not using gbm at all in this case
22:01 jenatali: Yeah
22:02 jenatali: Theoretically the d3d12 driver could export fds for shared resources, but they're not dmabuf, they're WDDM shared resources, so it's an ecosystem problem to be able to consume them
22:02 jenatali: At some point we'd talked about trying to get a path at least to XWayland and Weston to avoid the GPU -> CPU hop that every GL app currently hits in wslg
22:04 soreau: I see
22:05 DemiMarie: jenatali: Could WDDM shared resources be wrapped in dmabufs?
22:15 jenatali: No
22:19 DemiMarie: Is this because of different semantics, the lack of implicit sync in WDDM2, or the lack of an open-source userspace for upstreaming?
22:22 jenatali: Different semantics. Dmabuf is a bag-of-bytes with sync attached. WDDM shared resources are strongly typed
22:23 jenatali: Dmabuf also implies that a DRM driver is the one responsible for it, but the wslg dxgkrnl driver isn't a DRM driver
22:24 DemiMarie: Dmabuf is used by non-DRM drivers too.
22:25 DemiMarie: At least V4L2 and accelerator drivers also use dmabuf.
22:34 airlied: jenatali: dma-buf is not drm-buf, it is meant for non-drm drivers as well
22:34 jenatali: Maybe I'm misremembering then