08:17 tzimmermann: javierm, did you ever try buffer import/export with the ssd130x driver?
08:22 javierm: tzimmermann: I don't think that did, but AFAIU the GEM shmem allows to do dma-buf import/export through PRIME
08:23 javierm: tzimmermann: why are you asking?
08:23 tzimmermann: javierm, i currently review a usb-based driver at https://lore.kernel.org/dri-devel/4BAFD886-84E0-4C4C-94B3-90BF911ED0E7@live.com/T/#m0bc0b8cb87320085c4471e9097b75ebfd6899286
08:24 tzimmermann: and for usb, we require special handling of buffer imports because it requires a dma-capable device and usb devices don't have dma
08:24 tzimmermann: we use the usb-controller device instead
08:25 tzimmermann: and that got me thinking that we have plenty of drivers on serial busses. i wonder if these devices are capable of dma
08:25 tzimmermann: like i2c and spi in the solomon driver
08:26 javierm: tzimmermann: in most cases they are not, just like USB devices you need to copy from system memory to a device internal memory using I2C or SPI commands
08:27 javierm: I didn't know about this limitation of drm_gem_prime_* helpers
08:27 tzimmermann: not sure, but that would imply that they have no dma-capability set either. they'd need that workaround as well
08:27 tzimmermann: the limitation is obscure
08:29 tzimmermann: the import code always does dma_buf_attach even if the device never uses dma on the buffer. https://elixir.bootlin.com/linux/v6.13.2/source/drivers/gpu/drm/drm_prime.c#L958
08:32 javierm: tzimmermann: yeah, I'm looking at drivers/gpu/drm/tiny/gm12u320.c that has a custom gm12u320_gem_prime_import() helper that queries the DMA device of the USB controller
08:32 javierm: but that seems to be a workaround indeed
08:32 tzimmermann: also in udl and gud
08:33 javierm: ah, I just did `git grep .gem_prime_import -- drivers/gpu/drm/tiny/` :) to see if a simple driver used it
08:33 tzimmermann: yeah, we added it. there's a todo item to rework the import code. https://elixir.bootlin.com/linux/v6.13.3/source/Documentation/gpu/todo.rst#L615
08:34 tzimmermann: i just thought that the problem might not be exclusive to usb
08:34 javierm: tzimmermann: for sure is not exclusive to usb
08:34 javierm: any simple panel would have the same issue
08:34 tzimmermann: no one complained so far
08:34 javierm: I2C, SPI, parallel port, MIPI DBI, I think all will have the same problem
08:34 tzimmermann: still not pretty ...
08:41 sima: javierm, yeah we probably need special helpers that do cpu-only imports
08:42 sima: ah just caught up with the todo.rst link
08:43 javierm: tzimmermann: what's the actual error, if I'm reading the code correctly, the prime import will fail with -EINVAL?
08:44 javierm: sima, tzimmermann: but I was wondering if this isn't the correct behavior. I mean, after all zero copy is not supported for cpu-only imports
08:45 javierm: although I understand that might be desirable to provide a consistent uAPI for all KMS devices for user-space to not care
08:45 sima: javierm, well it's not more copies than what you'd get with a dumb buffer created on the device directly
08:45 javierm: sima: that's true
08:45 sima: if we'd fail import, then you'd get a copy done by userspace and one again in the kernel
08:46 javierm: sima: yeah, and also is annoying for user-space that might expect let's say a GStreamer pipline that does dma-buf import/export between a camera sensor and a display driver, to always work
08:47 javierm: (assuming that can negotiate the correct pixel format and whatnot)
08:47 tzimmermann: javierm, i think the device doesn't have a dma mask
08:47 tzimmermann: but i cannot find the actual test that fails
08:48 javierm: tzimmermann: I see
08:48 javierm: tzimmermann: thanks for mentioning this issue, I never thought about it
09:03 mripard: sima: could you have a look at https://lore.kernel.org/r/20250113101100.1373856-1-mripard@kernel.org ?
09:05 sima: mripard, hm I thought I've acked that already? at least gives me old memories vibes, and I think it summarizes the discussion we had a while back
09:05 sima: we = bunch of folks on dri-devel, not me iirc
09:06 sima: or do you mean the question where to put it?
09:06 sima: https://dri.freedesktop.org/docs/drm/gpu/introduction.html#contribution-process contribution process is maybe a better place?
09:08 sima: docs have become a bit messy anyway, probably a few things to move around that shouldn't be in top-level directories ...
09:08 javierm: sima: I think is better where mripard put it, because that's the section about unit testing
09:08 javierm: https://docs.kernel.org/gpu/drm-internals.html#unit-testing
09:08 sima: or maybe move the entire uapi stuff out into the uapi top-level doc dir
09:08 javierm: so makes sense to have their the expections documented
09:08 javierm: *there
09:09 sima: hm I'd move the entire thing to the top-level contributing maybe?
09:10 sima: drm-internals.rst is kinda about core drm concepts like drm_device and a few other things like that
09:10 javierm: sima: hmm, that sound correct indeed. But in any case would be a separate patch
09:10 sima: we don't do kunit just for that, but for all of drm
09:10 sima: yeah
09:10 sima: yeah kunit testing in there feels rather wrong to me ...
09:12 javierm: sima: agreed
09:12 sima: it's also annoying that the new stylesheet doesn't have a deep doc, so it's really hard to navigate
09:12 sima: I still keep the old one for those reasons
09:13 sima: since so much structure is lost otherwise
09:13 sima: and people just dump stuff into the top-level for lack of better place
09:14 mripard: sima: I didn't have any ack but jani's so I didn't merge it, and I'd still like to merge it :)
09:14 mripard: but yeah, I can shuffle the doc around
09:14 mripard: it's not clear to me what you want me to do from thta discussion though
09:16 sima: mripard, I think get some more acks from people working on kunit stuff
09:16 sima: tursulin just did a few drm/sched tests
09:16 sima: and then land it
09:17 sima: javierm, also wondering whether we should move all the uapi stuff into Documentation/userspace-api/gpu/ or so
09:19 javierm: sima, mripard: I just r-b the patch too in case it helps
09:20 javierm: sima: I don't have strong opinions on that. On one hand, having all the docs in the same dir could be convenient but separating uAPI and internal could be desirable too
09:21 mmind00: robertfoss: for the dw-hdmi-qp audio patch you gave a Reviewed-by ... can I just apply that patch to drmmisc or should I wait for a listed bridge maintainer to pick that up (seems I don't venture out of drm/rockchip enough)
09:40 sima: javierm, we can still link criss-cross to help find stuff
09:53 javierm: sima: I meant more for developers doing grep than users but yeah
09:55 sima: hm
09:55 sima: javierm, that already fails since large chunks of our docs are in source files within DOC: blocks
09:56 javierm: sima: right, that's true too
09:58 mlankhorst: mripard: looks like there's a potential mismatch between expectations of maintainership of dmem. :)
09:58 sima: mlankhorst, hm why?
09:59 sima: but yeah if tejun doesn't want it, I guess we should have a MAINTAINERS entry for cc: dri-devel and pointing at drm-misc git?
10:00 sima: tejun should still get them that way too
10:25 mlankhorst: Yeah
10:39 sima: mlankhorst, you'll send a MAINTAINERS patch then?
10:53 mripard: mlankhorst: yeah, I'm a bit confused
10:54 mripard: we're going to use it for more than drm, and it's a cgroup, so I'm not sure why we should maintain it in the first place
10:54 mripard: I know at least I don't know anyting about cgroups :)
10:55 mripard: sima: back to the bridge state discussion, you said you were fine with patches up until patch 30, does that mean I can add your r-b / a-b for those?
10:56 sima: mripard, I didn't really read most of them closely since they had an r-b already, but it looked all reasonable
10:56 sima: if you need an r-b or ack on specific ones, I think I'd need to look a bit more closely
10:59 javierm: mripard: I guess if fair for tejun to ask you (Friedrich, mlankhorst and you) to be Cc'ed in patches and listed as maintainer in MAINTAINERS but the list and tree should be cgroup indeed
11:00 javierm: just like is the case for any other cgroup driver in kernel/cgroup
11:02 javierm: tzimmermann: I was talking with mripard and probably you want to further clarify in https://elixir.bootlin.com/linux/v6.13.3/source/Documentation/gpu/todo.rst#L615 what is the plan for this
11:02 javierm: tzimmermann: because IIUC the agreegment is that KMS devices that don't support zero-copy, will "emulate" and support prime import. Similar like all KMS devices can emulate supporting XRGB8888
11:03 mripard: sima: I have the r-b I need already, so it's all good :)
11:21 stsquad: I'm still struggling to figure out what needs enabling in mesa to support the VK_KHR_display extension. AFAICT the bits of wsi_common_display.c that are marked for the extension are linked into the build - but I don't know what the entry point should look like.
11:21 stsquad: http://paste.debian.net/1351639
11:21 stsquad: ^ e.g stuff looks like its linked into libvulkan_virtio.so ^
12:10 stsquad: hmm manywin with any number greater than 1 reports "got error from kernel - expect bad rendering 114"
12:36 tzimmermann: javierm, mripard, i've now started working on a series to start resolving that todo
12:37 tzimmermann: the first step is to expose less of the import state to drivers; especially drm_gem_object.import_attach
12:37 tzimmermann: and then the import_attach should be made optional
12:51 mlankhorst: mripard: https://paste.debian.net/1351707/ ack?
12:51 mlankhorst: pixelcluster: want to be dmem maintainer too?
13:01 mripard: mlankhorst: yep
13:06 javierm: tzimmermann: yeah, the first step sounds desirable regardless
13:12 tzimmermann: javierm, the second step involves per-driver review. that might take abit longer to get right
13:40 mlankhorst: sima: so through cgroup git tree or drm-misc?
13:42 sima: mlankhorst, I'd propose drm-misc and ask tejun to ack that?
13:42 sima: seems where most of the interactions are currently
13:42 sima: mlankhorst, and I guess list you+whoever else as maintainers, plus dri-devel as list?
13:42 mlankhorst: Yeah ok, lets see. :)
13:46 pixelcluster: mlankhorst: I'd be honored :)
13:47 pixelcluster: jfyi I'm kinda in the middle of transitioning and switching everything over to new name - hadn't yet used it for the initial dmem patchset but if we could switch to "Natalie Vock <natalie.vock@gmx.de>" going forward that'd be cool
13:54 sima: pixelcluster, could also sneak in the .mailmap entry in the same patch if you want
13:54 sima: maybe even extra sneaky just as part of applying it
13:55 sima: entirely up to you, there's no requirement to have .mailmap entries in public upstream at all
13:57 pixelcluster: sima: <3
13:58 pixelcluster: had thought about that already but was scared to ask because "I've only written a handful of patches so far..."
13:58 sima: sometimes airlied or me also pushed one directly to drm.git somewhere in the middle of the merge-window pile where no one looks
13:58 sima: pixelcluster, a name change is a name change
13:58 sima: (mr incredible meme here)
13:58 pixelcluster: lmao
14:23 mlankhorst: pixelcluster: will add you under that name, if you want can add the mailmap in the patch
14:23 mlankhorst: or have sima do it
14:26 DemiMarie: pixelcluster: Congratulations!
14:29 pixelcluster: mlankhorst: adding it in the patch sounds good to me, thanks!
16:29 daniels: eric_engestrom: thanks for the release!
16:30 zmike: eric_engestrom: 💪
16:30 HdkR: 🎉
16:58 eric_engestrom: :)
16:58 eric_engestrom: and thanks to gfxstrand for correcting me!
16:58 eric_engestrom: I should've asked here for confirmation
17:03 daniels: meh, give it another week
17:10 eric_engestrom: daniels: ?
17:10 daniels: panvk will obviously be at 1.4 rsn :P
17:11 eric_engestrom: haha
17:12 eric_engestrom: too late for 25.0 though :P
17:15 eric_engestrom: scrolling back a bit; congrats pixelcluster!
17:49 any1: I think I recall two different people saying in here that they made some tools for generating EDIDs, but I don't remember who. Care to refresh my memory?
17:56 javierm: any1: https://github.com/mripard/redid maybe?
17:57 any1: javierm: well, that's one. Thanks ;)