< geertu> pinchartl: mic [17:18] < pinchartl> thank you welcome to the multimedia meeting we have 12 minutes ;-) Topic 1. Status Check for the Multimedia Tasks * Jacopo [17:19] Since last meeting: - V6 of max9286 integration on Eagle and Condor [PATCH v6 0/8] arm64: dts: renesas: Enable GMSL on Eagle and Condor - MAX9271 as a proper subdevice driver [RFC 0/5] media: i2c: Add MAX9271 subdevice driver - Investigated IMR support with a V4L2 M2M driver Until next meeting: - If Mauro replies, continue MAX9271 breakout - Make a plan for IMR ? Issues and blockers: None jmondi: any comment ? I've added IMR as a discussion point Since last meeting: - V3U display investigations - V3U DU v2 - Supporting Wolfram with V3U access (fun poking CN4 pins) - Misc review Until next meeting: - Investigate V3U display timings Not happy at 4k resolution - https://lore.kernel.org/r/CAMuHMdWSeeifBLqi4S6LrgcQg9E_1xFXzLzBBBqMf1Fc0kbMhg@mail.gmail.com/ Issues and blockers: None kbingham: any comment ? (missing the header with your name, oops, sorry) * Laurent [17:20] Since last meeting: - V4L2 multiplexed streams development Continued working with Tomi Valkeinen. Still work in progress (v8 is out). - Resuscitated non-contiguous DMABUF import for DU No review received so far, which is good as it means nobody objects (or maybe the patch went under the radar). Still, a review before merging would be good. Added support for buffer sharing between V4L2 and DRM to the excellent 'cam' tool from libcamera, highly recommended for testing ;-) - Fixed DU regression on Draak/Ebisu Will be integrated in v5.16. Until next meeting: - Upstream pending patches - V4L2 multiplexed streams development - If time permits, fix known issues with V3U displa Issues and blockers: None any question ? * Morimoto-san Since last meeting: - Plenty of cool non-multimedia things Until next meeting: - Resume ALSA work Issues and Blockers: None moriperi: any comment ? * Niklas Only that I wonder if I need to buy ... another DisplayPort monitor - or a DisplayPort/HDMI analsyzer... I know which one is cheaper, and I know which one has more guaranteed results ... Since last meeting: - [PATCH 0/3] rcar-csi2: Improve link frequency selection - [PATCH 0/2] rcar-csi2: Serialize format cfg and improve mutex handling - Tested and rebased work on-top the async rework/rename Until next meeting: - Follow up pending patches [17:21] Issues and blockers: None neg: any comment ? (trying to pipeline the status reports this time, let's see if it helps) the latter costs and arm and a leg and the soul of a few children Yes, I'm aware of the costs ;-) I have two child souls available, but I don't own the rights to disperse their souls, so I can't use them as payment. [17:22] how about some sort of exchange? [17:24] haha ;-) =) any other comment ? [17:25] not here Topic 2. Discussions [17:26] - IMR development jmondi: did you want to discuss this ? I would like to, yes mostly to confirm it's a viable plan viable in what sense ? :-) that it makes sense to upstream it [17:27] considering how tightly it is connected to the userpsace application exercizing it [17:28] to which, afaict, we have no access to ? I think it makes sense [17:29] but it means we'll have to create an application using it then there's the discussion about which subsytem to use cogent went up to v7 using the v4l2 m2m API my understanding is that DRM would be more appropriate [17:30] what do you think ? I think DRM would be better, yes [17:31] if you can't decide then how about putting the driver in user space (if possible with IOMMU of course) obviously a proper subsystem is better it's not just that it's an accelerator (see https://lwn.net/Articles/867168/ for context) [17:32] but it's a rendering engine the device takes textures + command buffer in, and outputs an image damm: with UIO you mean ? conceptually, that's like a GPU so, the current implementation from cogent is much like the HanbanaLab thing the article references to [17:33] jmondi: if doing a user space driver is the best option then perhaps UIO is good, but other more suitable options may exist too a custom IOCTL to have the driver swallow a command set and apply it to the HW [17:34] damm: I think DRM is better than a userspace driver in this case pinchartl: most likely yes =) I'm surprised they went up to v7 without getting a nack, as even with v4l2 m2m a different mechanism might be more opportune like a set of v4l2-ctl like we have for codecs [17:35] i suppose the documentation is not public which means it is hard to get the details for people reviewing? damm: that's why we would need to provide an open-source userspace application that actually uses the device [17:36] it moves the burden of creating a standard userspace API from the kernel to userspace yeah makes sense I've discussed this with Daniel Vetter, and it would be enough to satisfy the DRM upstreaming criteria, provided that the application would be structured as a library with the device-dependent code, and the application on top [17:37] then when the next similar device gets upstream support, we can turn the application into a proper framework where would you see that userspace code living ? I assume it cannot be a 'main.c + Makefile' in some random git tree fd.o [17:39] and it should be a lib + main.c a framework for dewarp engines in a sense but as a prototype we can defer making it a real framework until a second driver gets upstreamed [17:40] but it should be architectured in that way to facilitate the transition can we take commands and textures and store then in DT somehow? =) [17:41] to make it side-ways compatible somehow if you want the output of the device to be static then yes but in that case I'd prerender the output and use that :-) maybe different DT information could be overlaid during runtime? [17:42] (sorry i will stop now) [17:43] :-) :) so it seems we have a plan I admit the userspace part is kind of scary a fun research project :-) the driver part is too, but I can cope I'm afraid the acceptance criteria for userspace can quickly escalate to "implement it in weston" or similar [17:44] that's why I've discussed it with Daniel implementing it in mesa doesn't make too much sense and creating the mesa of dewarp engines with a single device as an example isn't a good idea am I wrong assuming that if I do enbark in this 'reserach project' I will fill up my time up to the next year ? so making a prototype for such a framework is enough next year is fairly soon [17:45] I meant end of Q12022 maybe it's even too optimistic I gotta leave now. Have a nice day everyone! [17:46] *** wsa (~wsa@mue-88-130-48-230.dsl.tropolys.de) has quit: Quit: ... any other discussion topic for today ? [17:49]