| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When | |
|---|---|---|---|
| CarlFK | im trying to write tests for custom hardware http://hdmi2usb.tv
is there a "test /dev/video0" for uvc ness? when it is working, this is a test: gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=3 ! jpegdec ! fakesink but that assumes mjpeg is working, trying to have a more forgiving test | [05:01] | |
| ...... (idle for 29mn) | |||
| *** | tensa has quit IRC (Quit: Ping timeout (120 seconds)) | [05:36] | |
| ........................... (idle for 2h10mn) | |||
| pinchartl | CarlFK: nice project !
I'm not aware of an open-source UVC compliance tool there's a V4L2 compliance tool, but it's more aimed at testing the driver, not the hardware | [07:46] | |
| CarlFK | thanks - ans what is it | [07:47] | |
| pinchartl | it's called v4l2-compliance :-) | [07:47] | |
| CarlFK | lol | [07:47] | |
| pinchartl | part of v4l-utils
based on my experience with UVC devices, I would recomment stress-testing controls and starting/stopping capture in tight loops is the UVC data transfer fully handled in the FPGA, including generation of headers ? | [07:48] | |
| CarlFK | I think so - I'm more of a user and QA | [07:50] | |
| pinchartl | ok | [07:51] | |
| CarlFK | https://github.com/timvideos/HDMI2USB-litex-firmware
I guess you know some fpga? | [07:51] | |
| pinchartl | some :-) | [07:52] | |
| CarlFK | wanna be a GSoC mentor?
last year we got 4 slots, I haven't found 4 full time mentors this year er, do you know about GSoC? | [07:52] | |
| pinchartl | :-)
I know about GSoC, yes but I'm not sure I'd have enough free time | [07:53] | |
| CarlFK | understood | [07:53] | |
| pinchartl | when is the deadline to find mentors ? | [07:53] | |
| CarlFK | im guessing when we allocate proposals to slots | [07:55] | |
| pinchartl | and when would that be ? | [07:55] | |
| CarlFK | April 9 18:00 UTC Student application deadline
May 6 18:00 UTC Accepted student proposals announced | [07:58] | |
| pinchartl | could you ping me closer to the deadline, when the applications will be known ? | [07:59] | |
| CarlFK | sure thing - and thanks | [07:59] | |
| hverkuil | CarlFK: I might be able to mentor, depending on the project. I have to leave soon, so contact me this afternoon (CET) or tomorrow. | [07:59] | |
| pinchartl | you're welcome. no commitment yet though :-) | [07:59] | |
| CarlFK | of course
hverkuil: will do v4l2-compliance|grep FAIL test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL test VIDIOC_G/S_PARM: FAIL what does this tell me? | [08:00] | |
| pinchartl | that's probably an issue in the UVC driver
what's the full output ? | [08:01] | |
| CarlFK | http://paste.ubuntu.com/p/66JB38s7k4/ | [08:03] | |
| hverkuil | https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=uvc
That has an S_PARM fix that I haven't gotten around to post. Also has work-in-progress on at least some of the CTRL fails. | [08:03] | |
| pinchartl | most likely driver issues, yes | [08:04] | |
| CarlFK | diff <(v4l2-compliance) v4l2-compliance.txt
if it changes, I know something changed :p | [08:06] | |
| pinchartl | one thing you should look at is the kernel log when you plug your device
make sure it doesn't report control-related failures, or workarounds being enabled | [08:06] | |
| CarlFK | uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
| [08:12] | |
| pinchartl | that one should be fixed
the rest looks fine could you try echo 0xffff > /sys/module/uvcvideo/parameters/trace before you plug the device in ? the driver will print more verbose messages to the kernel log (you can run echo 0 > /sys/module/uvcvideo/parameters/trace afterwards or a capture attempt will then get *very* verbose) | [08:16] | |
| CarlFK | http://paste.ubuntu.com/p/GfzwZ6mcbb/ | [08:20] | |
| pinchartl | the non-compliance part is the only thing that require attention in that log | [08:22] | |
| CarlFK | lol oh geez, I found all of this March 31, 2015
https://github.com/timvideos/HDMI2USB-fx2-firmware/issues/9 | [08:26] | |
| *** | prabhakarlad has left | [08:33] | |
| ............ (idle for 57mn) | |||
| bbrezillon | pinchartl, hverkuil: should I add a new type for the extended pix format?
my version uses the original VIDEO_{CAPTURE,OUTPUT} types http://code.bulix.org/6ewjxf-625716 but I'm not sure this is what you had in mind | [09:30] | |
| ....... (idle for 32mn) | |||
| mchehab | pinchartl: submit it as a patch series. I'll review it. Then we can see what to do with them | [10:04] | |
| bbrezillon | hverkuil, pinchartl, tfiga: also, do we want v4l2_exportbuffer to be extended to support exporting 1 dmabuf for all planes? | [10:10] | |
| ............... (idle for 1h11mn) | |||
| hverkuil | bbrezillon: yes, that needs to be addressed as well. | [11:21] | |
| ...... (idle for 28mn) | |||
| bbrezillon | hverkuil: good, I already started to do it | [11:49] | |
| ..................... (idle for 1h44mn) | |||
| pinchartl | mchehab: ok, thanks
the patches have been posted already I'll post a v7 they have all been reviewed BTW when do you think you'll look at them ? I'm planning to send a pull request to Dave by the end of the week, as I have more to build on top of this | [13:33] | |
| ........ (idle for 36mn) | |||
| ndufresne | tfiga, bbrezillon: did you already have a "porting" plan and check how this can be generically support with backward compatibility ?
I have a slight impression that this is forking a lot of API, so unless we check that it's feasible to support both, it won't happen | [14:10] | |
| ...... (idle for 28mn) | |||
| bbrezillon | ndufresne: all the ioctls() I add can be supported by old drivers (through wrappers)
and I do the same thing for old (non _EXT_) ioctls(), the code is patched to use the new ->vidioc_xxx_ext_xx() hooks such that drivers don't have to support both and I plan to add new tests to v4l2-compliance (+ make sure the old ones still pass) | [14:39] | |
| ndufresne | bbrezillon, what I mean is did you check if there is a way to detect absence of these new ios
bbrezillon, userspace like gstreamer is expected to be built once and run on various kernel without having to rebuilt for each kernels ioctl forking has made our life pretty hard in the past as there was often no way to detect the new features this is why a lot of flags are being added lately, a bit like the queue orphaning support | [14:42] | |
| bbrezillon | yes, I can imagine (given the number of ioctls and variants I've seen in there :-)) | [14:46] | |
| mchehab | pinchartl: just did | [14:46] | |
| pinchartl | mchehab: that was fast :-) thank you
those are indeed the only changes | [14:46] | |
| mchehab | anytime | [14:46] | |
| pinchartl | so I'll send a pull request to Dave
and if I later have more VSP changes for v5.2 that would conflict, I'll base it on the same branch (based on v5.1-rc1) so there will be no conflict | [14:46] | |
| bbrezillon | ndufresne: well, I do add flags to the valid_ioctls bitmap
but I'm not sure that's enough | [14:48] | |
| ndufresne | bbrezillon, what does this mean from userspace point of view ?
bbrezillon, anyway, nothing to worry now for a RFC patch, you should have plenty of time to check what has been added latency * lately ndufresne keeps discussing latency lately, and my brain match la... with latency ... | [14:48] | |
| mchehab | ok
please ask Dave for a stable branch after his merge, so that we can pull back on our tree | [14:49] | |
| bbrezillon | ndufresne: I'm checking if ->valid_ioctls is exposed | [14:51] | |
| ndufresne: nope, it's not to userspace
:-( *not exposed | [15:01] | ||
| ndufresne | bbrezillon, meanwhile no worries, this is just to place a sticker in your mind ;-P
bbrezillon, for the reference, V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is one example of flag we added, of course after we found that there was no other solution | [15:03] | |
| bbrezillon | too many things to remember, and everytime I think I've delimited the scope of the refactor, something else comes in | [15:04] | |
| *** | benjiG has left | [15:07] | |
| bbrezillon | ndufresne: hm, so I think there are 2 things, being able to determine if the kernel supports an ioctl, and being able to know when some features of the ioctl are not available
looks like like the ENOTTY is returned when you try to use an ioctl that does not exist but I can you want to know that before actually trying to use the ioctl s/can/guess/ | [15:14] | |
| ndufresne | well, ENOTTY works fine, as long as the ioctl support is not conditional
e.g. it must not be ENOTTY for format X but active for format Y (not sure what conditions make sense) though if you look at the memory flags, they simply got exposed in the caps, because the ENOTTY trick was quite a pain (to detect if MMAP, DMABUF, USRPTR, DMABuf importation is supported) | [15:18] | |
| mchehab, hverkuil, maybe you know what this is, we are (curiosity) wondering what "blue stretch" mean in analog to digital video converter | [15:28] | ||
| bbrezillon | in my case, if the non _EXT_ variant is supported the _EXT_ variant will be (assuming the kernel is recent enough of course)
but, if the driver does not implement the ->vdioc_xx_ext_xx() hooks, then some features (like allowing a dmabuf offset for a plane) won't work and EINVAL or ENOTSUPP will be returned | [15:28] | |
| ............. (idle for 1h4mn) | |||
| mchehab | ndufresne: this is a new term for me too
found a reference about it at the net: Blue Stretch When Blue Stretch is selected, the brightest part of the screen will be leveled down to reduce the saturation https://www.manualslib.com/manual/151640/Sharp-Aquos-Z41g460184301a.html?page=35 it seems to be a sort of blue level control on some TVs | [16:34] | |
| ............. (idle for 1h1mn) | |||
| ndufresne | mchehab, ok, on our side we came across this in TW (s-video to digital) converter chip specification
TW99 something, and were left wondering mchehab, I think from other reading the stretch is what visually happen to the histogram | [17:36] | |
| .............. (idle for 1h9mn) | |||
| mchehab | yeah, perhaps it is passing the blue channel to a compressor
to reduce its dynamic range | [18:46] | |
| ........................... (idle for 2h12mn) | |||
| CarlFK | hverkuil: pinchartl: you two should /j #timvideos so I can try to persuade you to write a kernel driver in exchange for more work :D (free trip to somewhere to help teach fpga stuff...)
or anyone else that knows fpga, or just wants another #chan to lurk in. | [20:59] | |
| ............ (idle for 56mn) | |||
| pinchartl | CarlFK: a kernel driver for what ? | [21:55] | |
| CarlFK | pinchartl: https://github.com/timvideos/litex-buildenv/wiki/FPGA_Linux_module | [21:56] | |
| I just wrote that page in anticipation of your question :D | [22:01] | ||
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |