[01:18] *** BrianG61UK_ has quit IRC (Read error: Connection reset by peer)
[01:20] *** BrianG61UK_ has joined #linux-media
[02:10] *** eelstrebor has quit IRC (Quit: Ex-Chat)
[02:30] *** jarthur has quit IRC (Ping timeout: 480 seconds)
[03:25] *** xiaer1921 has joined #linux-media
[03:27] *** xiaer1921 has left 
[03:28] *** xiaer1921 has joined #linux-media
[05:15] *** jm_h has joined #linux-media
[05:39] *** epoll has quit IRC (Ping timeout: 480 seconds)
[05:48] *** epoll has joined #linux-media
[06:04] *** GBenji has joined #linux-media
[06:20] *** djrscally has joined #linux-media
[07:23] *** svarbanov has joined #linux-media
[07:26] *** ao2 has joined #linux-media
[11:40] *** jarthur has joined #linux-media
[12:40] <pinchartl> hverkuil: ping
[12:46] <hverkuil> pinchartl: pong
[12:47] <pinchartl> I've had a discussion with Tomi regarding control of pipelines that have no DMA engine
[12:47] <pinchartl> camera -> ... -> connector
[12:48] <pinchartl> where connector can be an HDMI connector, an ethernet connector, ...
[12:48] <pinchartl> my initial proposal, which I've discussed with you previously, was a new subdev ioctl on the subdev at the end of the pipeline
[12:49] <pinchartl> (an ethernet controller in my case)
[12:50] <pinchartl> and Tomi proposed creating a video_device there instead, with either a new vfl_devnode_type, or reusing VFL_TYPE_VIDEO but with a new capability (V4L2_CAP_VIDEO_xxx, name to be defined)
[12:50] <pinchartl> the video node would then essentially expose VIDIOC_QUERYCAP, VIDIOC_STREAMON and VIDIOC_STREAMOFF
[12:50] <pinchartl> and that's it
[12:51] <pinchartl> as it wouldn't expose any of the existing V4L2_CAP_VIDEO_* caps, it shouldn't confuse userspace
[12:52] <pinchartl> ideally, we should then rework video_device to separate the media entity and the media interface, as we should there have a media interface linked to a connector media entity, not to a MEDIA_ENT_F_IO_V4L media entity
[12:52] <pinchartl> what do you think would be best ?
[12:54] <hverkuil> I don't really like that approach. I'm perfectly fine with STREAMON/OFF ioctls for v4l-subdev. It's simple and clean.
[12:57] <tomba> who handles that subdev STREAMON ioctl? a subdev doesn't know it's at the end of the pipeline. or can STREAMON be called on any subdev? that doesn't make sense either, as it must be called last subdev.
[13:00] <tomba> (pinchartl: I still don't get that whole separation thing and the media functions and why that's needed. I need to read the code =)
[13:02] <hverkuil> isn't that why the media controller was invented? I would also suggest signaling the STREAMON/OFF capability through a VIDIOC_SUBDEV_QUERYCAP capability, that would make a lot of sense.
[13:03] <pinchartl> hverkuil: that's not Tomi's question. the issue is that a subdev doesn't intrinsincly know if it should support STREAMON/OFF
[13:03] <pinchartl> in the case we have to support, the ethernet controller is a very custom device that can then be considered as "special", its driver can implement support for those ioctls and hardcode that
[13:03] <pinchartl> but if you imagine the same pipeline with an HDMI output
[13:03] <pinchartl> the last subdev could be an ADV7511
[13:04] <hverkuil> Ah, OK, now I understand the problem.
[13:04] <pinchartl> how would its driver know that it has to implement support for the subdev stream on/off ioctls ?
[13:05] <hverkuil> One solution is that the top-level driver that knows this can set a V4L2_SUBDEV_FL_STREAMING flag.
[13:05] <hverkuil> the core v4l2_subdev ioctl function can then enable STREAMON/OFF. Basically similar to V4L2_SUBDEV_FL_HAS_EVENTS.
[13:11] <tomba> so the top-level driver would modify the subdev's flags in its notifier bound call, and the ioctl itself would be handled in the v4l2 framework?
[13:11] <tomba> which would just call s_stream on the subdev
[13:14] <pinchartl> that won't be enough though
[13:14] <pinchartl> at streamon time, we have to validate the pipeline configuration
[13:14] <pinchartl> there are helpers for that
[13:14] <pinchartl> but it's trigerred by whoever handles the streamon ioctl
[13:15] <pinchartl> and subdevs currently rely on the fact that the pipeline is valid
[13:15] <pinchartl> again that's something we can implement in our subdev driver
[13:15] <pinchartl> but I don't think the adv7511 driver should do that
[13:16] <pinchartl> and I also don't think we can implement a fully generic validation in v4l2-subdev.c when handling VIDIOC_SUBDEV_STREAMON before calling the subde
[13:16] <pinchartl> v
[13:17] *** eelstrebor has joined #linux-media
[13:19] <tomba> wouldn't all these problems go away with using video device? =). I still don't understand what the problem is with it (although I don't deny that there might be a lot of code to work on). It would be just like a normal video device and video node, but without dma.
[13:19] <tomba> I'm good with the subdev STREAMON option too. I'm just curious why the video device is a clear no-go.
[13:23] <pinchartl> the issue with the video_device is technical, it will require decoupling its MC entity from its MC interface
[13:28] <tomba> what is MEDIA_ENT_F_IO_V4L? why is the connector not such? the docs say "Data streaming input and/or output entity".
[13:29] <tomba> oh, there are separate types for connectors
[13:32] <hverkuil> It's not just technical, it also means adding yet another variant of a video device (currently all video nodes can stream to/from memory, but now we introduce one that can't), and I think that can be quite confusing.
[13:34] <pinchartl> we could add "something else", but I wonder what that should be
[13:35] <hverkuil> Also, if it is the bridge driver that needs to validate the pipeline, then that can be done by using a similar technique that v4l2_subdev_notify() uses, i.e. calling the bridge driver to implement the functionality of streamon/off.
[13:37] <hverkuil> From a userspace perspective you introduce a new device node just for this purpose, and that is something that I think is not necessary.
[13:39] <hverkuil> Would this work:
[13:40] <hverkuil> 1) add V4L2_SUBDEV_FL_STREAMING (naming TBD)
[13:40] <hverkuil> 2) in subdev_do_ioctl you can test for this and if set implement STREAMON/OFF.
[13:41] <hverkuil> 3) The subdev_do_ioctl STREAMON/OFF implementation just calls v4l2_subdev_notify(), telling the bridge driver that it should start/stop streaming.
[13:42] <hverkuil> 4) the notify callback in v4l2_device needs to be changed to return an int.
[13:42] <hverkuil> (currently it's a void function)
[13:43] <hverkuil> 5) signal streaming support in VIDIOC_SUBDEV_QUERYCAP with a new capability, otherwise it's hard for userspace to tell if a subdev can start/stop streaming.
[13:45] <hverkuil> This way everything is done in the bridge driver with some core support, and subdev drivers do not need to be modified at all.
[13:45] <pinchartl> I don't think that will work
[13:45] <pinchartl> because in the HDMI output case
[13:45] <pinchartl> there's no bridge driver
[13:46] <pinchartl> we have to create one
[13:46] <pinchartl> and if we create one
[13:46] <pinchartl> I think the above is really convoluted
[13:46] <pinchartl> we should stop calling it a bridge driver too, there's no bridge
[13:46] <pinchartl> it's a kind of top-level driver that binds the pieces together
[13:47] <pinchartl> the problem is similar to what has been solved with xilinx-vipp.c
[13:47] <hverkuil> top-level driver, whatever. There is some driver that binds everything together, right? And that has the info needed to validate video pipelines?
[13:47] <pinchartl> except that one depends on DMA engines
[13:47] <pinchartl> so we need to remove the DMA engine dependency
[13:47] <pinchartl> which is doable I believe
[13:49] <pinchartl> but going through the subdev for this... seems like a hack
[13:49] *** camus has quit IRC ()
[13:50] <pinchartl> why do you think a new video device capability would be confusing ?
[13:53] <hverkuil> All /dev/videoX devices today can do I/O, now suddenly you create a variant that can't. I think that is confusing. Certainly more confusing than advertising streamon/off support for a subdev device where you never expect I/O anyway.
[13:57] *** camus has joined #linux-media
[13:59] <hverkuil> I probably wouldn't call it STREAMON/OFF for a subdev device anyway. Perhaps something like VIDEO_PIPELINE_ON/OFF might be a better fit.
[13:59] <hverkuil> Just brainstorming here.
[14:02] <pinchartl> the more I think about it, the more I believe that controlling the whole pipeline through a subdev is a very big hack
[14:03] <pinchartl> especially given how we'd have to jump through hoops and loops to implement it, using notifiers
[14:03] <hverkuil> the more I think about it, the more I believe that controlling the whole pipeline through a video device is a very big hack :-)
[14:04] <pinchartl> that's what we do today on all devices
[14:04] <pinchartl> video devices start and stop the whole pipeline
[14:04] <pinchartl> even radio devices do
[14:04] <pinchartl> and they don't do DMA
[14:04] <pinchartl> so there's a precedent there
[14:04] <hverkuil> radio devices have no STREAMON/OFF.
[14:07] <hverkuil> have to leave soon, will be gone for the evening. I may not be around tomorrow either (day off).
[14:16] <pinchartl> how do you turn the radio on/off ?
[14:25] *** camus1 has joined #linux-media
[14:26] *** camus has quit IRC (Ping timeout: 480 seconds)
[14:37] *** xiaer1921 has quit IRC (Remote host closed the connection)
[14:37] *** xiaer1921 has joined #linux-media
[16:04] *** camus has joined #linux-media
[16:05] *** camus1 has quit IRC (Ping timeout: 480 seconds)
[16:36] *** GBenji has left 
[16:37] *** BrianG61UK has quit IRC (Read error: Connection reset by peer)
[16:42] *** BrianG61UK has joined #linux-media
[17:07] *** gouchi has joined #linux-media
[18:04] *** camus1 has joined #linux-media
[18:07] *** camus has quit IRC (Ping timeout: 480 seconds)
[18:30] <macc24> ezequielg: re: "[PATCH v3 07/10] media: hantro: Enable H.264 on Rockchip VDPU2", why is this only enabled on socs without rkvdec?
[18:31] <ezequielg> macc24: ndufresne and me were just talking about this commit.
[18:31] <macc24> ezequielg: here?
[18:31] <ezequielg> in private :-)
[18:31] <ezequielg> macc24: that commit is merged, iirc.
[18:32] <macc24> ezequielg: yea but is there any reason?
[18:32] <ezequielg> yes, h264 is offered by rkvdec.
[18:32] <ezequielg> if you also offer h264 in hantro -- then you need to come up with a mechanism to tell userspace which one to pick.
[18:33] <macc24> which one is better at h264?
[18:33] <ezequielg> some sort of "score"
[18:33] <ezequielg> well, rkvdec of course.
[18:33] <ezequielg> if hantro would be better than rkvdec, we would have enabled that one instead :)
[18:33] <macc24> hmm
[18:34] <macc24> is hantro cursed?
[18:34] <ezequielg> not sure what you mean.
[18:34] <ezequielg> in rk3399, rkvdec is simply more powerful.
[18:34] <ezequielg> no curse.
[18:34] <macc24> like, is it more cursed ip block to work with than rkvdec?
[18:34] * ezequielg brb
[18:35] <macc24> ...
[18:39] <ndufresne> macc24: damn, someone notices ;-D
[18:39] <ndufresne> I actually reported the bug on the ML, so its recorded in public now
[18:40] <ndufresne> now I had to fix some gst regression, https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1154
[18:40] <macc24> ndufresne: no commit regarding rk3326 or arm chromebook shall go unnoticed by me
[18:40] <ndufresne> well, excellent !
[18:41] <ndufresne> (in absence of CI, that's all we got, people testing)
[18:42] <ndufresne> ezequielg: to make things worst, the vdpu2 does not even work for me here on rk3399, I'm checking now, VIDIOC_G_EXT_CTRLS failed: Invalid Argument
[18:42] <ndufresne> -> Driver did not report framing and start code method
[18:43] <ndufresne> haha, it's really a bug, since the format is exposed, but not the controls
[18:43] <ndufresne> I was hoping that at least it would be exposed in a usable way
[18:44] <macc24> ndufresne: if you help me get gstreamer v4l2codecs running on a chromebook kevin i can test stuff for you if you ping me
[18:47] <ndufresne> macc24: you have mainline running already ?
[18:48] <macc24> ndufresne: ever heard of cadmium?
[18:49] <ndufresne> nop, but I just googled it
[18:49] <macc24> yea i made it
[18:49] <ezequielg> ndufresne: I know. The commit does an attempt to not expose it, it's just incomplete, since it exposes the format too. :(
[18:49] <ndufresne> I think as soon as you passed booting linux there, you can pretty much run a standard distro these days
[18:49] <macc24> yep
[18:50] <ndufresne> ezequielg: if only git was smart enough to read our commit message and fix our patch ;-P
[18:50] <macc24> still there are some hardware... quirks
[18:51] <ndufresne> yeah, I do suspect stuff around DMR, as not all chromeos patches got cleaned-up and merged
[18:51] <macc24> DMR?
[18:51] <ndufresne> DRM/display driver (typo sorry)
[18:51] <ndufresne> not sure if/what else, and it may be very kevin specific
[18:51] <macc24> yea
[18:52] <macc24> there are some analogix_dp quirks
[18:52] <ndufresne> I know Alyssa was writing panfrost on a kevin
[18:52] <macc24> yep
[18:52] <macc24> ndufresne: the patches beginning with gru. are for rk3399 machines https://github.com/Maccraft123/Cadmium/tree/master/kernel/patches
[18:53] <ndufresne> ezequielg: I could probably write this patch now, I see what mistake you did ;-P
[18:53] <macc24> without them the panel seems to freeze weirdly
[18:54] <ezequielg> ndufresne: please write all the patches you want.
[18:56] <jernej> ndufresne, ezequielg: are there any differences between hantro and rkvdec, except max. supported size?
[18:56] <ndufresne> haha, you simply need to filter the formats against the variant.codec 
[18:57] <ndufresne> right now, even if the variant.codec does not include H264, the format is still expose, while the controls are filtered
[18:57] <ndufresne> but I'm curious, I'll add H264 first, to see if it works as expect at least
[18:57] <ndufresne> (for future, when I manage to write appropriate code for gst/ffmpeg I suppose ...)
[18:57] <ndufresne> not sure if that will ever happen
[18:59] <ndufresne> yep, work as expected
[19:09] *** gouchi has quit IRC (Remote host closed the connection)
[19:11] *** gouchi has joined #linux-media
[19:11] <ndufresne> ezequielg: the code is a bit more annoying (aka naive) then I hoped ;-P
[19:14] *** jarthur has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[19:31] *** camus has joined #linux-media
[19:32] *** camus1 has quit IRC (Read error: Connection reset by peer)
[20:01] *** jm_h has quit IRC (Remote host closed the connection)
[20:14] *** camus1 has joined #linux-media
[20:15] *** camus has quit IRC (Read error: Connection reset by peer)
[21:08] *** gouchi has quit IRC (Remote host closed the connection)
[21:50] *** ao2 has quit IRC (Quit: Leaving)
[22:41] *** svarbanov has quit IRC (Ping timeout: 480 seconds)
[23:22] *** djrscally has quit IRC (Ping timeout: 480 seconds)
[23:29] *** camus has joined #linux-media
[23:34] *** camus1 has quit IRC (Ping timeout: 480 seconds)