[07:31] <neg> sailus: hej
[10:10] <sailus> neg: Hejssan!!!
[10:12] <neg> sailus: I finaly finished the last patch to add a new use-case to your VC series and I would like to post that :-)
[10:13] <neg> sailus: Before I do I would like to check a few things with you, there are smiapp patches in your branch which I can not test do you wish me to include them if I post the series?
[10:14] <sailus> Please do.
[10:15] <sailus> Are there any changes to the patches in my vc branch?
[10:20] <neg> sailus: I added the same changes you make to other driver to the rcar-vin driver as it was not in the media-tree at the time of your latest rebase
[10:20] <sailus> Ack.
[10:20] <sailus> Sounds good.
[10:20] <neg> Also checkpatch warns about some small things I could fix but I have not to ease integration of our two branches
[10:20] <sailus> Have you used the PM code in the patches?
[10:21] <sailus> I think there are some things that could need cleaning up as well in my patches.
[10:22] <sailus> Feel free to post them though; I think your patches would probably be primarily the subject for review. My recollection is that I have posted these long time ago for review. :-)
[10:22] <sailus> I could take your changed bit and see if there's anything more to fix.
[10:23] <neg> Appart from adding the rcar-vin changes and rebasing on top of the media-tree your vc branch is not touched
[10:23] <sailus> Ah, ok.
[10:23] <sailus> So your patches are directly on top of the rebased vc branch?
[10:24] <neg> yes
[10:24] <sailus> Nice.
[10:24] <neg> My patches only add changes to the rcar-csi2 and adv748x drivers which allows the CSI-2 VC channel to be selected at runtime using the G/S_ROUTING ioctls
[10:25] * kbingham 's ears picked up on the talk of VC
[10:25] <sailus> Cool!
[10:25] <sailus> Were there any issues with the patches in the vc branch?
[10:25] <sailus> I've tested them slightly.
[10:25] <sailus> But I have a vague recollection that I saw something going wrong with the PM code.
[10:25] <neg> sailus: no issue with them there was one trivial merge conflict
[10:26] <sailus> Speaking of which --- the drivers should switch to runtime PM anyway.
[10:26] <sailus> The function is, well, rather complicated.
[10:26] <neg> sailus: and I have not tested the PM code so there might be something lurking
[10:26] <sailus> Ok.
[10:26] <neg> next step for me is to add PM to the rcar capture drivers so I might hit something
[10:26] <sailus> One way to address that could be to require that drivers supporting S_ROUTING will have to support runtime PM.
[10:31] <sailus> Hmm. Perhaps that wasn't the complicated part.
[10:31] <sailus> I wrote the first patches in 2014...
[10:31] <sailus> X-)
[10:32] <neg> :-)
[10:32] <neg> I will post the patches and we can start the review process
[10:33] <neg> sailus: thanks for your time
[10:38] <sailus> Great!
[10:56] <mchehab> hverkuil: I'm having some troubles with qvidcap... depending on the resolution, I'm getting Unsupported format
[10:56] <mchehab> (I'm testing with a Logitech HD camera)
[10:56] <mchehab> so far, it seems that only 640x480 works
[10:58] <mchehab> 	Card type        : HD Pro Webcam C920
[10:58] <hverkuil> It only support uncompressed formats, not MJPEG
[10:58] <mchehab> for example, it fails with:
[10:58] <mchehab> 	Width/Height      : 960/720
[10:58] <mchehab> 	Pixel Format      : 'MJPG' (Motion-JPEG)
[10:58] <mchehab> does it use libv4l?
[10:59] <hverkuil> No. I might add that. It's primary purpose is for uncompressed formats.
[10:59] <hverkuil> Use qv4l2 if you want to work with webcams.
[11:00] <mchehab> nah, I just wanted to test it :-)
[11:00] <hverkuil> I should improve the error message though.
[11:01] <mchehab> v4l2-ctl --list-framesizes 'YUYV'
[11:01] <mchehab> ...
[11:01] <mchehab> 	Size: Discrete 960x720
[11:01] <mchehab> (in thesis, it should support YUYV with 960x720)
[11:02] <mchehab> but I'm not sure if this is emulated or not
[11:02] <mchehab> I guess v4l2-ctl doesn't list what's emulated
[11:02] <mchehab> no, YUYV is not emulated
[11:03] <hverkuil> --list-formats would show emulated formats since they have V4L2_FMT_FLAG_EMULATED set.
[11:04] <mchehab> $ qvidcap -W 960 -H 720 -P 'YUYV'
[11:04] <mchehab> Unsupported format
[11:04] <mchehab> camorama debug output shows what's emulated or not
[11:05] <hverkuil> Run v4l2-ctl -v pixelformat=YUYV, then try qvidcap again.
[11:05] <mchehab> https://pastebin.com/j77ixxm2
[11:06] <mchehab> ah, now it worked
[11:06] <hverkuil> It just takes the current format, but explicitly changing the format is a good idea.
[11:06] <mchehab> it would also make sense to print what format it is trying to use
[11:07] <hverkuil> OK, it now shows what the unsupport format is :-)
[11:10] <mchehab> $ qvidcap
[11:10] <mchehab> Unsupported format: 'MJPG' Motion-JPEG
[11:10] <mchehab> better
[11:12] <mchehab> I would still print, when format is recognized, camera's width, height and pixelformat
[11:13] <mchehab> it is not obvious that -W, -H and -P doesn't change it at the camera
[11:13] <mchehab> just my 2 cents
[11:16] <mchehab> hmm... partially my fault... I just looked at the options, not at what was written before that
[11:16] <mchehab>   The following options are ignored when capturing from a video device:
[11:16] <mchehab>   The following options are only valid when reading from a file:
[11:18] <mchehab> anyway, good tool
[11:26] <hverkuil> mchehab: updated qvidcap so that you can use -P to select a pixelformat from a video device.
[11:26] <hverkuil> qvidcap -P YUYV should now work for your webcam
[11:28] <mchehab> worked, thanks!
[11:31] <angelo_ts> kbingham, gm. I can now start the stream, but, there is something strange: i capture with v4l2-ctl, i see s_stream called and data on the CSI lines, but nothing is written in the output file.jpg
[11:32] <angelo_ts> kbingham, i am using v4l2-ctl -d /dev/video4 --stream-mmap=3 --stream-count=100 --stream-to=file.jpg
[11:34] <angelo_ts> also pressing CTRL-C s_stream is not called again
[12:21] <neg> sailus: Are you OK with me removing the Gerrit Change-Id tags from your commits in the VC series before posting? :-P
[12:26] <sailus> neg: Ouch.
[12:26] <sailus> Where there some of those?
[12:26] <sailus> Yeah... I must have had these patches on an Android kernel once upon a time. :-P
[12:27] <sailus> Shame on me.
[12:27] <sailus> That's actually what I meant with cleanups as well. ;-)
[12:27] <sailus> These patches need a proper description, too.
[12:27] <pinchartl> sailus: yes, shame on you :-)
[12:32] <neg> sailus: do you wish to do some cleanups of the vc branch before I post it or should I just remove the tags ?
[12:35] <sailus> neg: I removed the tags and added some more explanation to the patches.
[12:35] <sailus> I'm pushing now...
[12:36] <neg> sailus: can you also fold in the rcar-vin updates if I send you two fixup patches ?
[12:36] <sailus> neg: Certainly.
[12:36] <neg> sailus: thanks, give me a minute to break them out again :-)
[12:37] <sailus> If you have the changed patches, I can take them as well.
[12:43] <sailus> ttomov: A quick question: why does CONFIG_VIDEO_QCOM_CAMSS depend on IOMMU_DMA?
[12:43] <neg> sailus: sent, thanks for folding them
[12:43] <sailus> It seems I'll need to enable a Mediatek IOMMU driver to get that. :-)
[12:47] <sailus> neg: I wonder if something's wrong... the patches do not apply cleanly.
[12:47] <sailus> Although the conflicts were trivial.
[12:48] <ttomov> sailus: strange, I have to check
[12:48] <neg> sailus: I might have used your latest vc branch as a base to extract the patches quick and dirty, sorry about that
[12:49] <neg> and by latest vc branch I mean the latest public one from 3 months ago
[12:50] <sailus> Ok, that could have been the issue.
[12:50] <sailus> There have been some changes to the driver I think.
[12:50] <sailus> And I've probably resolved them but may not have pushed the driver.
[12:50] <sailus> The branch, I mean.
[12:50] <sailus> A moment.
[12:51] <neg> no problem, let me know if you wish to resend them using a different base
[12:52] <sailus> I'm using media tree master.
[12:55] <neg> sailus: v2 sent based on media-tree master
[13:08] <sailus> neg: pushed.
[13:10] <cristian_c> hello
[13:11] <cristian_c> I've taken a look at v4l2-ctl manpage
[13:12] <cristian_c> but I don't know exactly how to grab a frame from a capture device
[13:12] <cristian_c> any ideas?
[13:12] <hverkuil> v4l2-ctl --stream-mmap
[13:12] <hverkuil> If you want to store one or more frames in a file:
[13:12] <cristian_c> I remeber I typed that command in past, I chech it out immediately
[13:13] <hverkuil> v4l2-ctl --stream-mmap --stream-to x.raw --stream-count=N
[13:13] <hverkuil> where N is the number of frames you want to capture and store in x.raw.
[13:13] <hverkuil> v4l2-ctl --help-streaming gives all the streaming options.
[13:13] <neg> sailus: thanks, trying the result now
[13:14] <sailus> I'll need to leave.
[13:14] <sailus> Have a nice week-end!
[13:14] <neg> sailus: you too and thanks for all your help
[13:16] <cristian_c> when I typed v4l2-ctl -d /dev/video1 --streams-mmap, the command hanged
[13:17] <hverkuil> ctrl-c breaks off the command? I.e. did your kernel crash, or if v4l2-ctl just waiting for frames and ctrl-C breaks that off.
[13:17] <cristian_c> instead, when I typed v4l2-ctl -d /dev/video1, commands returned prompt immediately
[13:17] <hverkuil> or if -> or is
[13:17] <cristian_c> in past.
[13:17] <hverkuil> v4l2-ctl -d /dev/video1 doesn't do anything :-)
[13:18] <hverkuil> what sort of device is /dev/video1?
[13:18] <cristian_c> ctrl+c just broke the command
[13:18] <hverkuil> v4l2-ctl -D -d /dev/video1
[13:18] <hverkuil> (or -d1 instead of /dev/video1, it's a shortcut)
[13:18] <cristian_c> no, I didn't remember crashes
[13:20] <cristian_c> yeah, I know the -dn shortcut
[13:20] <cristian_c> (n = 0,1,2 , ...)
[13:21] <cristian_c> ok, -D stands for driver info
[13:21] <cristian_c> it's a video capture device from composite to usb
[13:22] <hverkuil> Then the hardware probably can't lock to the signal. Possibly due to a standard mismatch (PAL vs NTSC)
[13:23] <hverkuil> What's the output of: v4l2-ctl -d1 -I -S --get-detected-standard
[13:25] <cristian_c> I can try now
[13:26] <hverkuil> You DO have a source running, do you? If there is no video signal at all, then it likely won't capture anything.
[13:27] <cristian_c> I tried v4l2-ctl -d1 -s pal in past, and it returned Standard set to 000000ff
[13:27] <cristian_c> I can try using --get-detected-stabdard option
[13:28] <cristian_c> yeah, I've tested using a running source
[13:28] <hverkuil> Just run: v4l2-ctl -d1 -I -S --get-detected-standard
[13:29] <hverkuil> and report the output.
[13:29] <hverkuil> that's what I need to see.
[13:29] <hverkuil> Oh, add -D to the option list, that way I know what driver you are using
[13:29] <cristian_c> does -l stands for list-controls?
[13:30] <hverkuil> -I, --get-input    query the video input [VIDIOC_G_INPUT]
[13:30] <hverkuil> That also tells you if the HW sees a valid signal.
[13:30] <cristian_c> ah, ok, -I. intead of -l
[13:31] <hverkuil> uh, yes :-)
[13:40] <cristian_c> ok, done, without -D
[13:41] <cristian_c> now, by -D too
[13:42] <cristian_c> I pastebin
[13:44] <cristian_c> hverkuil: https://pastebin.com/WGFEGJS2
[13:45] <hverkuil> smi2021 is an out-of-tree driver, I can't give support for that.
[13:46] <hverkuil> the driver claims that is sees a valid signal, and the driver uses the NTSC standard.
[13:46] <hverkuil> Is that correct? If your source uses pal, then call v4l2-ctl -d1 -s pal and try to stream again.
[13:46] <hverkuil> Otherwise I can't help you.
[13:49] <cristian_c> I've already tried that, btw, but I'll try it again
[13:50] <hverkuil> don't you know what your source format is? I've no idea what you are using as source...
[13:50] <cristian_c> and I always get Standard set to 000000ff
[13:51] <cristian_c> hverkuil: funai bhs recorder
[13:51] <cristian_c> *vhs
[13:51] <hverkuil> Yes, that means it switched the driver to PAL. v4l2-ctl -d1 -S will now report PAL.
[13:51] <hverkuil> v4l2-ctl -d1 -V should report a height of 576 lines or thereabouts.
[13:51] <cristian_c> yeah, I confirm
[13:52] <cristian_c> video standard = 0x000000ff PAL-B/B1/G/H/I/D/D1/K
[13:52] <hverkuil> VHS, ok. So what is the TV standard where you live? pal/ntsc/secam?
[13:53] <cristian_c> pal, usually
[13:54] <cristian_c> ntsc is for united states, I suppose, europe shpuòd be pal
[13:54] <cristian_c> *should
[13:54] <hverkuil> Where do you live? (Or really: where was the VHS tape recorded?)
[13:54] <cristian_c> -V returns some info, included 720/576 width/height, uyvy pixel format, ....
[13:55] <cristian_c> italy, but I think the funai hq is implemented for europe
[13:55] <cristian_c> if  needed , I ca pastebin -V output
[13:56] <cristian_c> I mean, vhs tape is recorded in italy
[13:57] <hverkuil> OK, Italy is PAL. So if --stream-mmap still doesn't work after setting the receiver to PAL, then I don't know.
[13:57] <cristian_c> hverkuil: strange thing is abput some years ago, driver was able to capture stream
[13:57] <cristian_c> in linux
[13:58] <cristian_c> I don't know it it comes from the same tree of old smi2021 driver
[13:59] <hverkuil> Sorry, can't help.
[13:59] <cristian_c> hverkuil: btw, I try to grab a frame by --stream-count option
[14:06] <cristian_c> 'panasonic raw picture' capturee, 600 KiB
[14:06] <cristian_c> *captured
[14:15] <hverkuil> So it does work after all?
[14:17] <hverkuil> Why not try qv4l2 to view the video? It has a proper GUI :-)
[14:17] <cristian_c> I've made two tests with v4l2-ctl, and I've opened the two .raw files by rawthreapee application
[14:17] <cristian_c> hverkuil: yeah, I've tried qv4l2 sometimes
[14:18] <cristian_c> btw, the two RAW files are both almost green
[14:18] <cristian_c> there are some white stripes/dots
[14:21] <cristian_c> rawthreapee creates a pp3 raw related file, after closed
[14:21] <hverkuil> Sorry, it all sounds like a crappy driver to me.
[14:21] <cristian_c> it includes a lot of info about the captured raw
[14:22] <hverkuil> got to go.
[14:22] <cristian_c> maybe, the driver doesn't work properly anymore
[15:03] *** prabhakarlad has left 
[23:25] <scootergrisen> Are there any instructions on how to translate linuxtv stuff?
[23:26] <scootergrisen> I would like to translate V4L2 test utility if possible
[23:50] *** gnurou has quit IRC (Ping timeout: 260 seconds)