[00:04] *** johancb has joined #linux-media
[00:46] *** tmerciai has quit IRC (Ping timeout: 480 seconds)
[00:48] *** danitool has quit IRC (Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos)
[01:13] *** johancb has quit IRC ()
[03:34] *** BrianG61UK has joined #linux-media
[04:40] *** tmerciai has joined #linux-media
[04:41] *** mvchtz has quit IRC (Remote host closed the connection)
[04:42] *** mvchtz has joined #linux-media
[05:30] *** Mo_ has joined #linux-media
[05:37] *** Mo has quit IRC (Ping timeout: 480 seconds)
[06:10] *** Mo_ has quit IRC (Remote host closed the connection)
[06:46] *** tmerciai has quit IRC (Ping timeout: 480 seconds)
[07:07] *** tmerciai has joined #linux-media
[07:15] *** djrscally has joined #linux-media
[07:23] *** mvaittin has joined #linux-media
[07:25] *** lplc has quit IRC (Ping timeout: 480 seconds)
[07:47] *** Mo has joined #linux-media
[07:49] *** GBenji has joined #linux-media
[08:27] *** dcz has joined #linux-media
[08:28] *** thansen has quit IRC (Ping timeout: 480 seconds)
[08:32] *** thansen has joined #linux-media
[08:33] *** prabhakalad has quit IRC (Quit: Konversation terminated!)
[08:33] *** prabhakalad has joined #linux-media
[08:38] *** sgruszka has joined #linux-media
[08:42] *** sgruszka has quit IRC (Remote host closed the connection)
[08:49] *** tmerciai1 has joined #linux-media
[08:52] *** tmerciai has quit IRC (Remote host closed the connection)
[08:53] *** tmerciai1 has quit IRC (Remote host closed the connection)
[08:53] *** tmerciai1 has joined #linux-media
[08:54] <mriesch> hi all
[08:54] <mriesch> the rk3568 vicap mipi capture is able to capture four different mipi csi ids
[08:54] *** ao2 has joined #linux-media
[08:55] <mriesch> i imagine that the driver creates four video devices for that
[08:55] *** lplc has joined #linux-media
[08:55] <mriesch> but how are the ids of the four devices set?
[08:56] <mriesch> i.e. video0 could listen to mipi csi id 42, if i am not mistaken. where do i get this 42 from in my driver (because i need to enter it in the corresponding register)
[09:01] <jmondi> mriesch: "mipi csi ids" == mipi CSI-2 Data Type ?
[09:02] <mriesch> jmondi: no, csi virtual channel (vc)
[09:02] <jmondi> mriesch: "mipi csi id 42" == MIPI CSI-2 Data Type RAW8 (0x2a) ?
[09:02] <jmondi> ah
[09:02] <jmondi> what's 42 then ?
[09:02] <mriesch> an example, and probably not a good one at that
[09:03] <mriesch> but as a real life example: the imx415 image sensor is able to send two streams
[09:04] <mriesch> vc 0 would stream the image data with long exposure, vc 1 would stream the short exposure (in a wdr/hdr setup)
[09:05] <jmondi> does the " vicap mipi capture" write frames to mem ?
[09:05] <mriesch> correct
[09:05] <jmondi> or does it feed the ISP in-line ?
[09:06] <jmondi> ok, so the pipeline is roughly "sensor -> vicap -> mem" ?
[09:06] <mriesch> vicap mipi capture writes (possibly raw) frames to memory, indeed
[09:07] <jmondi> ok, so I would create a multiplexed source pad in the imx415 entity
[09:07] <mriesch> (disclaimer: the vicap as a whole may feed the isp as well, but i am talking exclusively about the mipi capture block of it)
[09:07] <jmondi> connect it to a multiplexed sink pad on the vicap that is then demultiplexed to two (or more) dma engines video nodes
[09:07] <jmondi> are you familiar with v4l2 streams and the routing APIs ?
[09:08] <mriesch> not one bit
[09:08] <mriesch> well i am aware that they exist and that they should cover this scenario
[09:09] <jmondi> that's already something :)
[09:09] <jmondi> tomba: ^ what's the most recent and shiny example of streams+routing that we can point mriesch to ?
[09:10] <jmondi> I can show you as we've handled the [image + embedded data] use case for the Pi5 if you want, it should be similar, if no that embedded data are originated by an "internal sink" pad
[09:10] <jmondi> and you manipulate the sensor's routing table to enable/disable the embedded data route
[09:11] <mriesch> any pointers are most welcome
[09:11] <jmondi> for multiple exposures I'm not sure if the same internal pad model fits... sailus pinchartl  ?
[09:12] <mriesch> i *think* the use case with this mipi capture things is a multi-id receiver
[09:12] <tomba> well... we don't have everything upstream, so nothing easy to point. the upstream rpi cfe driver handles streams on the receiver side. but internal pads and embedded data is missing from upstream sensors.
[09:12] <mriesch> but maybe it would be nice as well to extract raw image sensor data, be it certain exposures, be it the embedded data
[09:13] <mriesch> the real life hdr application will be (most definitely) carried out with the isp
[09:13] <jmondi> mriesch: this commit in example
[09:13] <jmondi> https://github.com/raspberrypi/linux/pull/6437/commits/c41fb1246125c185e5fb1fba20d2b30efb8cc42c
[09:15] <jmondi> adds support for embedded data to imx519 by introducing an internal source pad and by introducing support for routing and multi-stream
[09:16] <jmondi> the upstream CFE driver (drivers/media/platform/raspberrypi/rp1-cfe/) handles this and demultiplexes the streams received on its sink pad to multiple video device nodes
[09:16] <mriesch> so in the cfe example, there is one real sink pad and more than one virtual sink pad?
[09:17] <mriesch> or one real sink pad and that's it?
[09:21] <sailus> jmondi: Good questions. (Btw. use nick followed by colon, many IRC clients won't pick nick strings alone.)
[09:21] <sailus> These are separate streams after all so we likely should model them this way.
[09:21] *** tmerciai2 has joined #linux-media
[09:26] <jmondi> mriesch: there is one sink pad with multiple streams :) 
[09:26] <mriesch> good, good..
[09:26] <jmondi> sailus: thanks, that was my gut feeling too
[09:27] <mriesch> jmondi: because the image sensor driver you pointed at seems to create different pads for image data, embedded data, ...
[09:27] *** tmerciai1 has quit IRC (Ping timeout: 480 seconds)
[09:31] <tomba> mriesch: those are "internal pads". internal sources for the video and embedded streams. which are multiplexed into the csi-2 output pad.
[09:32] <mriesch> ah
[09:35] <jmondi> yes, these are internal pads.. and I was wondering if multiple-exposures should/could modeled in the same way as [img + embedded data]
[09:35] *** charrus has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
[09:35] *** charrus has joined #linux-media
[09:36] <mriesch> jmondi: i would guess so
[09:38] <mriesch> from a user space perspective, you can use media-ctl set-routes, right.. does it link the internal pads then?
[09:39] <mriesch> in the sense of "as a user i would like to connect imx715 embedded data to vicap mipi capture id0", no matter what is between the two
[09:40] <tomba> mriesch: sorry, no such thing. you have to go through all the subdevs and configure the routing and formats properly.
[09:41] <tomba> and, again, note that internal pads are not in upstream yet
[09:41] <mriesch> oh. ok.
[09:42] *** charrus has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
[09:42] *** chewitt has joined #linux-media
[09:42] *** charrus has joined #linux-media
[09:43] <mriesch> but would this be the envisaged goal, to link internal pad to internal pad (ignoring everything in between for a moment)
[09:43] <jmondi> internal pads only exists on the media entity the originate streams, the sensor in this case
[09:43] <jmondi> then along the pipeline you only have "regular" pads with multiple streams
[09:44] <jmondi> you use the routing API to .. route ... streams within an entity, in example to enable/disable the emebdded data generation on the sensor
[09:44] <jmondi> then you configure formats on the [pad, stream] paris along the pipeline
[09:44] <jmondi> and when you get to a demux (like your vidcap, that splits multiple streams to different dma engines)
[09:45] <jmondi> you use the routing API again there to control where a streams is directed to
[09:45] <jmondi> sailus: where does your most recent branch with internal pads live ?
[09:50] <sailus> jmondi: I just updated it. 
[09:51] <jmondi> sailus: could you point mriesch: to it ? :)
[09:51] <sailus> metadata in either in my git.linuxtv.org or git.retiisi.eu tree.
[09:52] <sailus> https://git.retiisi.eu/?p=~sailus/linux.git;a=summary
[09:53] <mriesch> sailus: that's... radish? or is google translate lying to me?
[09:53] <sailus> mriesch: Correct.
[09:54] <mriesch> sailus: perfect. i like that a lot
[09:55] *** charrus has quit IRC (Ping timeout: 480 seconds)
[09:57] <jmondi> spicy code there
[09:59] <mriesch> ah :) nice
[10:00] *** johancb has joined #linux-media
[10:02] <mriesch> thx for all the pointers, i'll dig into them
[10:08] *** johancb has quit IRC ()
[10:09] <jmondi> mriesch: if you also want to see how this is handled in userspace this is how rpi did it in libcamera
[10:09] <jmondi> https://github.com/raspberrypi/libcamera/pull/200/commits/07e84f2cf75f528f775a9fbd6997cff94a156d01
[10:27] *** lplc has quit IRC (Quit: WeeChat 4.0.4)
[10:29] *** lplc has joined #linux-media
[10:29] *** lplc has quit IRC ()
[10:30] *** lplc has joined #linux-media
[10:31] <mriesch> thx
[10:32] <mriesch> one loosely related, yet different questions: is anyone aware of anything like mipi virtual channels in bt.601 or bt.1120?
[10:33] <mriesch> the rk3568 vicap dvp (digital video port, e.g., bt.601, bt.1120, ...) capture features capturing four ids as well. but i have no idea what for
[10:36] <jmondi> no idea, MIPI CSI-2 VC only apply to... MIPI CSI-2 as far as I can tell :)
[10:36] *** lplc has quit IRC (Quit: WeeChat 4.0.4)
[10:38] <mriesch> maybe i just create one video device, call it dvp-id0, hardcode 0 and get away with it. i guess right now it is about whether future streams/multiple ids/vcs/... additions will cause a breaking change
[10:40] *** lplc has joined #linux-media
[11:14] *** tmerciai1 has joined #linux-media
[11:20] *** tmerciai2 has quit IRC (Ping timeout: 480 seconds)
[11:29] *** BrianG61UK has quit IRC (Remote host closed the connection)
[11:59] *** tmerciai2 has joined #linux-media
[12:01] *** paulk-bis has quit IRC ()
[12:01] *** paulk has joined #linux-media
[12:05] *** tmerciai1 has quit IRC (Ping timeout: 480 seconds)
[12:07] *** wallacer has quit IRC (Ping timeout: 480 seconds)
[12:16] *** wallacer has joined #linux-media
[12:16] *** tmerciai1 has joined #linux-media
[12:16] *** tmerciai2 has quit IRC (Remote host closed the connection)
[12:17] *** tmerciai1 has quit IRC (Remote host closed the connection)
[12:18] *** tmerciai1 has joined #linux-media
[12:32] *** tmerciai2 has joined #linux-media
[12:38] *** tmerciai1 has quit IRC (Ping timeout: 480 seconds)
[12:40] *** tmerciai1 has joined #linux-media
[12:46] *** tmerciai2 has quit IRC (Ping timeout: 480 seconds)
[13:13] *** wallacer_ has joined #linux-media
[13:17] *** wallacer has quit IRC (Ping timeout: 480 seconds)
[13:17] *** dcz has quit IRC (Quit: Konversation terminated!)
[13:22] *** wallacer_ has quit IRC (Ping timeout: 480 seconds)
[13:23] *** wallacer has joined #linux-media
[13:26] *** wallacer has quit IRC (Read error: Connection reset by peer)
[13:30] *** wallacer has joined #linux-media
[13:36] *** BrianG61UK has joined #linux-media
[13:59] *** dcz has joined #linux-media
[14:16] *** mvaittin has quit IRC (Ping timeout: 480 seconds)
[15:28] *** Mo has quit IRC (Ping timeout: 480 seconds)
[15:40] *** hansg has joined #linux-media
[15:44] *** BrianG61UK has quit IRC (Read error: Connection reset by peer)
[15:45] <hansg> sailus, I know it is close or to even past the end of the day for you, but can you maybe (tomorrow?) look at my RFC for handling the new INT3472 "handshake" GPIO thingie: https://lore.kernel.org/linux-media/59f672c3-6d87-4ec7-9b7f-f44fe2cce934@redhat.com/  ?
[15:46] <hansg> Note I'm off myself tomorrow. If you have any questions you would like to discuss in real-time, maybe we can set apart some time Monday morning to discuss this here ?
[16:07] <sailus> hansg: I saw your e-mail, I can reply it tomorrow.
[16:08] *** dcz has quit IRC (Ping timeout: 480 seconds)
[16:08] <hansg> sounds good, thank you
[16:25] *** f_ is now known as funderscore
[16:39] *** dcz has joined #linux-media
[17:10] *** hansg has quit IRC (Quit: Leaving)
[17:15] *** meiser79 has quit IRC (Ping timeout: 480 seconds)
[17:16] *** mrpops2ko_ has joined #linux-media
[17:17] *** TeriR has joined #linux-media
[17:19] *** mrpops2ko has quit IRC (Ping timeout: 480 seconds)
[17:23] *** TeriR has quit IRC ()
[17:32] *** GBenji has left 
[17:33] *** tmerciai1 has quit IRC (Ping timeout: 480 seconds)
[17:39] *** mriesch has quit IRC (Quit: No Ping reply in 180 seconds.)
[17:40] *** mriesch has joined #linux-media
[17:41] *** meiser79 has joined #linux-media
[17:48] *** funderscore is now known as f_
[17:48] *** lplc has quit IRC (Quit: WeeChat 4.0.4)
[17:48] *** BrianG61UK has joined #linux-media
[17:50] *** lplc has joined #linux-media
[17:53] *** mrpops2ko_ has quit IRC ()
[17:57] *** mrpops2ko has joined #linux-media
[18:00] *** BrianG61UK has quit IRC (Read error: Connection reset by peer)
[18:06] *** chewitt has quit IRC (Quit: Zzz..)
[18:24] *** linkmauve has left Error from remote client
[18:33] *** thansen is now known as Guest6791
[18:33] *** thansen has joined #linux-media
[18:38] *** Guest6791 has quit IRC (Ping timeout: 480 seconds)
[18:44] *** thansen has quit IRC (Ping timeout: 480 seconds)
[18:49] *** darkapex has quit IRC (Remote host closed the connection)
[18:49] *** darkapex has joined #linux-media
[19:37] *** lplc has quit IRC (Quit: WeeChat 4.0.4)
[19:39] *** lplc has joined #linux-media
[19:41] *** ao2 has quit IRC (Quit: Leaving)
[19:53] *** linkmauve has joined #linux-media
[22:29] *** dcz has quit IRC (Quit: Konversation terminated!)
[23:37] *** danitool has joined #linux-media