| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| User_ | Where exactly should I do frame processing when I capture from camera input? | [02:26] |
| ............................................................... (idle for 5h13mn) | ||
| hverkuil | mchehab: see https://patchwork.linuxtv.org/patch/54559/ (fixes compilation breakage)
Do you have CONFIG_IMX_IPUV3_CORE=y in your .config? Without it the imx driver isn't enabled. Since you missed this breakage I suspect that you never actually compiled the imx driver. | [07:39] |
| ...... (idle for 27mn) | ||
| *** | [LOGGER] has quit IRC (Ping timeout: 250 seconds) | [08:07] |
| .... (idle for 19mn) | ||
| prabhakarlad has left | [08:26] | |
| ..... (idle for 20mn) | ||
| javier__ | hverkuil: I believe he builds everything that's buildable from x86_64 with COMPILE_TEST
so I guess it would be good to allow the driver to build with depends on MEDIA_CONTROLLER && VIDEO_V4L2 && (IMX_IPUV3_CORE || COMPILE_TEST) | [08:46] |
| hverkuil: in fact, the driver builds just fine so it seems that only has runtime dependency and no build depedency with IMX_IPUV3_CORE
hverkuil: https://paste.fedoraproject.org/paste/2RmMUr43UHY1zPqOGqInEw/raw | [08:56] | |
| ............ (idle for 56mn) | ||
| *** | nico__ has quit IRC (Quit: Leaving) | [09:52] |
| headless has quit IRC (Quit: headless) | [10:01] | |
| .............. (idle for 1h8mn) | ||
| bparrot has quit IRC (Remote host closed the connection) | [11:09] | |
| ................... (idle for 1h32mn) | ||
| awalls has quit IRC (Ping timeout: 259 seconds) | [12:41] | |
| ..... (idle for 24mn) | ||
| mchehab | hverkuil: probably not... my build script should be able to detect config changes and let me manually select, but from time to time, this breaks
probably due to some Kbuild changes that affects "ssh" and "ssh -t" from time to time, I need to either add or remove "-t" probably such change happened when pulling from -rc7 | [13:05] |
| javier__ | mchehab: that driver wasn't build with COMPILE_TEST though, I've posted a patch for that | [13:09] |
| mchehab | ah
nah, it broke here after doing a make allyesconfig | [13:09] |
| javier__ | ah, I wasn't selected here with a allmodconfig
*it | [13:10] |
| mchehab | i usually do allyesconfig, as this detects symbol collisions | [13:11] |
| javier__ | mchehab: right | [13:11] |
| mchehab | in the past, we had some people doing export 'foo' on multiple drivers
built with warnings drivers/staging/media/imx/imx7-media-csi.c: drivers/staging/media/imx/imx7-media-csi.c:1077 imx7_csi_set_fmt() error: uninitialized symbol 'outcc'. drivers/staging/media/imx/imx7-media-csi.c: drivers/staging/media/imx/imx7-media-csi.c:1083 imx7_csi_set_fmt() error: uninitialized symbol 'cc'. drivers/staging/media/imx/imx7-media-csi.c: In function 'imx7_csi_enum_mbus_code': drivers/staging/media/imx/imx7-media-csi.c:926:33: warning: variable 'in_cc' set but not used [-Wunused-but-set-variable] const struct imx_media_pixfmt *in_cc; ^~~~~ I'll fix those crap gah, there are real bugs there | [13:11] |
| ok, patches with the fixups sent
let me do a clean build to double check if everything is ok i really hate all those ipu3 warnings.... strongly tempted on making this depend on BROKEN :-p | [13:25] | |
| hverkuil | mchehab: give sailus some time to work on this :-) | [13:30] |
| mchehab | I'm giving... first time I complained was at the end of last year :-p | [13:31] |
| hverkuil | must have missed that. | [13:31] |
| mchehab | I complained by the time ipu3 stuff got merged
it should be somewhere there at the e-mail thread while this is at staging, we should at least shut up the errors from this crap, just like we did with atomisp and add the need for fixing those at their TODO list I will eventually do this today, if no news from sailus with that regard | [13:32] |
| fixes to imx7 pushed
this is what we did with atomisp: -# HACK! While this driver is in bad shape, don't enable several warnings -# that would be otherwise enabled with W=1 -ccflags-y += $(call cc-disable-warning, implicit-fallthrough) | [13:49] | |
| hverkuil, sailus: just pushed two patches to shut up ipu3 warnings... it is really tiring to see this on all builds over the last 3-4 months
the first patch is not really a fix, it just supress warnings report once the proper fixes get merged, it should be reverted | [14:01] | |
| hverkuil | mchehab: BTW, Steve was working on these imx errors: https://www.mail-archive.com/linux-media@vger.kernel.org/msg144721.html | [14:05] |
| mchehab | ok, good to know. there are two new warnings there, it seems
drivers/staging/media/imx/imx7-mipi-csis.c: drivers/staging/media/imx/imx7-mipi-csis.c:716 mipi_csis_set_fmt() error: we previously assumed 'fmt' could be null (see line 709) drivers/staging/media/imx/imx7-mipi-csis.c:834:46: warning: 'mipi_csis_internal_ops' defined but not used [-Wunused-const-variable=] at least now the build is clean enough to allow identifying new warnings | [14:07] |
| hverkuil | mchehab: once it is all clean, then I want to enable checks in the daily build for new sparse/smatch warnings. | [14:08] |
| mchehab | there are those false "divide by zero" reports | [14:09] |
| hverkuil | I strip those. | [14:10] |
| mchehab | the better would be to have a fix for it upstream at smatch/sparse
still there... btw updating to latest version is now producing a lot more warnings :-( | [14:10] |
| hverkuil | BTW, I am still using your sparse/smatch repos in my daily build, those are still correct? | [14:12] |
| mchehab | including this hateful one:
drivers/media/usb/gspca/nw80x.c: drivers/media/usb/gspca/nw80x.c:1144 (null)() debug XXX: trouble parsing 0-22,24-29,31-34,41,46,50,53-54,60,62-65,67,70,73-74,77,80,84,86,94,98,100,104,110-111,116,120,122,128,130,132-134,136,139-140,143,146,148,153,158,160-161,164,168,170,173-174,179-182,186,188,192-193,195,198-199,201-202,204,206-208,210,226,228,233,238-s3+ c = s3+ yeah, let's keep using it | [14:12] |
| sailus | mchehab: I've told you I'm working on this.
The second patch is fine, but the first one would be presumably reverted soon. | [14:19] |
| mchehab | sailus: that's ok. let's revert it as soon as this gets fixed | [14:20] |
| sailus | I'll send something probably either today or tomorrow. | [14:20] |
| mchehab | ok, great! | [14:21] |
| .... (idle for 17mn) | ||
| *** | mszyprow has quit IRC (Ping timeout: 250 seconds) | [14:38] |
| .... (idle for 19mn) | ||
| Killerkid_ has quit IRC (Quit: ZNC - http://znc.in) | [14:57] | |
| ........ (idle for 39mn) | ||
| andrey_utkin has quit IRC (Excess Flood) | [15:36] | |
| .............. (idle for 1h6mn) | ||
| mtretter has quit IRC (Quit: Leaving) | [16:42] | |
| ..... (idle for 21mn) | ||
| ndufresne | hverkuil, I've been looking around blitter ip, and indeed, we can only cover a subset of what they usually do with a m2m driver
hverkuil, some of them have up to 3 sources, and it's not clear if they can really do in-place worst is that each source can have it's down destination rectangle (.e.g. one source could be a solid black color, the background, and then you could place the video on trop) | [17:03] |
| shuah | hverkuil: I am running a few corner case type testing with v4l2-ctl. What would you expect when v4l2-ctl -f and v4l2-ctl --stream-mmap --stream-count=100 run in parallel. | [17:09] |
| ........... (idle for 54mn) | ||
| *** | ao2 has quit IRC (Remote host closed the connection) | [18:03] |
| ..... (idle for 20mn) | ||
| pH5 has quit IRC (Quit: bye) | [18:23] | |
| ndufresne | shuah, at least one of the two calls should fail, but both may fail
it could also crash one or the other, the problem is the concurrent calls to S_FMT prior to STREAMON I added tones of validation in gst to not crash with this case | [18:30] |
| shuah | ndufresne: I expected the second one to fail with EBUSY. It appears the driver (au0828) keeps track of streaming users, but s_frequency doesn't check it.
I think it might be that s_freq could be called while streaming from the same app. When you mix two apps, there is a problem with exclusion. | [18:42] |
| ndufresne | well, it's racy if you start both at the same time, but if you wait for the first one to be streaming, it should give you back EBUSY, except for things that can be changed like frame interval and controls | [18:43] |
| shuah | I mean when one app is streaming and another does s_freq call
Yeah I started streaming with 1000 count and ran another app to change freq. It isn't a race in my case. | [18:43] |
| ndufresne | it's should change the freq, unless the specific driver does not support live change on that, and then the driver code can check and return EBUSY
shuah, oops, freq, is radio freq, sorry, sometime I confuse with frame interval | [18:44] |
| shuah | Sorry I didn't make it clear. I am talking about video streaming | [18:48] |
| ndufresne | shuah, in theory you should be able to switch that at run-time from a separate process
strange, I'm reading the doc now, and learning stuff I didn't know "However VIDIOC_S_FREQUENCY is a write-only ioctl, it does not return the actual new frequency." | [18:48] |
| shuah | Right that is what I think should happen. I am looking at a case where audio and video are sharing the tuner with more than one video app in the mix. Fun times!
Right s_frequency is write | [18:50] |
| ndufresne | it means if you pick the freq wrong, it will fix it, but won't update the app structure, you'd have to do a G_FREQUENCY to check
and the doc says that EBUSY means "A hardware seek is in progress." | [18:52] |
| shuah | Right, it doesn't return the new freq to user
It is disruptive, it does reset the stream | [18:54] |
| ..................... (idle for 1h43mn) | ||
| hverkuil | shuah: it depends on the driver and hardware.
BTW, are you setting the radio frequency or the TV tuner frequency? Not that it matters, the answer remains the same. | [20:37] |
| If there are separate radio and TV tuners, then it is fine to set one while the other is in use.
If it is one tuner, but with different modes, then changing mode while streaming should return EBUSY If you just change the frequency while streaming (not tuner mode), then that is usually fine. Unless the DMA is particularly picky, but just as you can change channels while listening to the radio or watching TV, the same is possible with V4L2. | [20:45] | |
| .............. (idle for 1h6mn) | ||
| *** | cybrNaut has quit IRC (Ping timeout: 240 seconds) | [21:53] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |