| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | jmleo has quit IRC (Quit: Disconnecting from stoned server.)
sailus has quit IRC (Remote host closed the connection) pfallenop has quit IRC (Write error: Broken pipe) mripard has quit IRC (Write error: Broken pipe) r0kc4t has quit IRC (Write error: Broken pipe) javier__ has quit IRC (Write error: Broken pipe) smartin has quit IRC (Write error: Broken pipe) gnurou has quit IRC (Quit: No Ping reply in 180 seconds.) d0ggie has quit IRC (Write error: Broken pipe) evalenti has quit IRC (Remote host closed the connection) pinchartl has quit IRC (Remote host closed the connection) mmattice has quit IRC (*.net *.split) d00gster has quit IRC (*.net *.split) Killerkid has quit IRC (*.net *.split) kbingham has quit IRC (*.net *.split) tfiga has quit IRC (*.net *.split) svarbanov has quit IRC (*.net *.split) syoung has quit IRC (*.net *.split) al has quit IRC (*.net *.split) harrow has quit IRC (*.net *.split) sunxi_fan has quit IRC (*.net *.split) milian has quit IRC (*.net *.split) arnd has quit IRC (*.net *.split) macmaN has quit IRC (*.net *.split) jj- has quit IRC (*.net *.split) griffinp has quit IRC (*.net *.split) MJRider has quit IRC (*.net *.split) bengan has quit IRC (*.net *.split) _sic_ has quit IRC (*.net *.split) zaxari has quit IRC (*.net *.split) APic\splat has quit IRC (*.net *.split) indy has quit IRC (*.net *.split) WeaselSoup has quit IRC (*.net *.split) luisbg has quit IRC (*.net *.split) TFKyle has quit IRC (*.net *.split) narmstrong has quit IRC (*.net *.split) broonie has quit IRC (*.net *.split) Marex has quit IRC (*.net *.split) crope has quit IRC (*.net *.split) rellla has quit IRC (*.net *.split) ChanServ has quit IRC (*.net *.split) | [00:15] |
| orwell.freenode.net sets mode: +o ChanServ | [00:22] | |
| ...... (idle for 26mn) | ||
| mchehab | hverkuil: no idea. There's nothing that changed on our side that would affect it. Maybe something changed at either gcc-make or at the Kernel build
s/gcc-make/gnu-make/ | [00:48] |
| ................................................................... (idle for 5h31mn) | ||
| hverkuil | mchehab: do you observe the same thing when using media_build? Just making sure it isn't just my setup. | [06:19] |
| .................................. (idle for 2h48mn) | ||
| berget | Hello, anyone here that might answer a question I have about V4L2? | [09:07] |
| jmleo_ | berget, don't ask if you can ask, just ask :p | [09:07] |
| berget | Sorry, let's say I have a camera device and I set it's brightness using V4L2 VIDIOC_S_CTRL, if the device then changes its own brightness internally, what value should I get when I retrieve brightness with VIDIOC_G_CTRL? The value I previously set, or the new one that was changed on the device? I guess what i'm trying to say, is the value I set with VIDIOC_S_CTRL cached or not? | [09:10] |
| hverkuil | berget: it depends on the driver what happens. You can tell whether the value is cached or not by calling VIDIOC_QUERYCTRL and check if the VOLATILE control flag is set.
If set, then it will retrieve the current brightness value from the hardware. otherwise it is the cached value. | [09:11] |
| berget | so if it has indeed changed internally, and not by set, I will only get the cached?
and if queryctrl.flags & V4L2_CTRL_FLAG_VOLATILE is TRUE then it's not cached? | [09:14] |
| hverkuil | I'm confused. When you say "the device then changes its own brightness internally" do you mean that the hardware changes it, or that the driver changes the control value?
VOLATILE is for the first (HW changes the brightness). | [09:16] |
| mchehab | hverkuil: same behavior here | [09:17] |
| sailus | mchehab: Could you subscribe me to the media-submaintainers list at linuxtv.org?
I wasn't aware of the list until pinchartl recently told me about it... | [09:18] |
| mchehab | hverkuil: I think I know why.... gmake uses the source directory when spreading tasks... as all *.mod.c are under v4l/, it ignores -j | [09:19] |
| sailus | I'd prefer sakari.ailus at retiisi.org.uk. | [09:21] |
| mchehab | # echo sakari.ailus@iki.fi | ./add_members -r - media-submaintainers
Subscribed: sakari.ailus@iki.fi | [09:21] |
| sailus | Well, that works, too.
It's a low volume list I presume. | [09:22] |
| mchehab | I can change to the other e-mail if you prefer :-)
yes, it is low volume | [09:22] |
| sailus | Nah, it's fine. | [09:22] |
| mchehab | ok | [09:22] |
| sailus | Obrigado! | [09:22] |
| mchehab | de nada!
sorry for not noticing it before sailus: until very recently, it used to be a zero traffic ML :-) | [09:22] |
| vianpl | I'm working on a capture/playback v4l2 driver for a FPGA based device. On one hand it has a genlock source (apart from the regular clock) and also it can force locking the input clock with the output clock (for in/out loop situations). I haven't seen controls for these kind of scenarios. Am I wrong? if so, would it make sense to make them generic o
r should I add them as pure custom controls? | [09:30] |
| hverkuil | vianpl: Custom controls make sense here. | [09:31] |
| vianpl | Fair enough, thanks! | [09:32] |
| mchehab | sailus: just sent an e-mail to the ML. Please confirm that you received it | [09:39] |
| sailus | mchehab: I did. | [09:42] |
| mchehab | great | [09:42] |
| ............. (idle for 1h2mn) | ||
| ttomov | mchehab: sailus: my patchset about Qualcomm Camera Subsystem driver depends on a patch that is not merged and I got an error message from kbuild test robot. How do I handle that - do I need to include that patch in my patchset?
this is the needed patch: https://git.linuxtv.org/sailus/media_tree.git/commit/?h=packed12-postponed&id=549c02da6eed8dc4566632a9af9233bf99ba99d8 | [10:44] |
| hverkuil | ttomov: when was that patch posted to the linux-media mailinglist? | [10:47] |
| ttomov | hverkuil: http://www.spinics.net/lists/linux-media/msg104013.html
I think this is the last one, last week I asked sailus to rebase it, but it is not sent again | [10:48] |
| hverkuil | Last year. Strange, I don't see it in patchwork.
sailus: ^^^^^^ I think you should discuss this with Sakari. I've no idea what the status of that patch is. it makes sense to carry it at least for now in your tree, if only to keep kbuild quiet. | [10:49] |
| snawrocki | hverkuil: Isn't it this one? https://patchwork.linuxtv.org/patch/36236 | [10:53] |
| hverkuil | Hmm, marked Accepted, but not actually merged! | [10:57] |
| mchehab | weird | [10:57] |
| snawrocki | yeah, I can't see it in mainline | [10:57] |
| hverkuil | I've changed the state to New | [10:58] |
| mchehab | we need to double check if a similar patch weren't merged instead
I remember we had several discussions related to a sailus patchset adding support for some bayer formats that no driver were using yet... he ended by adding support for those at the smiapp driver, and such patch were merged perhaps the name of the macros changed on the final version or perhaps we added only a subset of the fourccs ttomov: in any case, I agree with hverkuil: just add it on the top of your patch series, while we don't figure out what happened there worse case scenario is that it will be merged together with your patch series assuming that you're using all formats defined there... or otherwise a subset of it and the other unused fourcc would be stripped sailus: do you remember the end result of such discussions? | [10:58] |
| sailus | mchehab: The V4L2 pixelformat patches were not merged as there was no driver using them. | [11:04] |
| ttomov | mchehab: yes, I use all of them. Actually I see a copy-paste error now, and one of the formats is misspelled, I will correct this - so all of the formats will be used. | [11:04] |
| mchehab | ttomov: then just add the patch on your series, before the one that starts using them | [11:05] |
| sailus | ttomov, mchehab: I suggest to pick the patches from my tree here:
https://git.linuxtv.org/sailus/media_tree.git/log/?h=packed12-postponed | [11:05] |
| hverkuil | Ah, I probably accepted it, but Mauro rejected it and then the state of the patch in question wasn't updated. | [11:05] |
| sailus | Some of the patches have been merged since posting the original set to the list.
The rest are in that branch. | [11:06] |
| mchehab | ok. so, ttomov just need to pick the one(s) he's using | [11:06] |
| ttomov | mchehab: to pick equals to resend with that patch included? | [11:07] |
| mchehab | yes. be sure to preserve the original authorship when you pick it
newer versions of git should do the right thing by adding a From: <original author> as the first line of the body of the e-mail we'll use such line when applying the patch on our tree, after reviewing | [11:07] |
| ttomov | ok, I'll do
thank you all :) | [11:08] |
| mchehab | ttomov: perhaps you should wait for people to review the patches you already sent
before sending a second version with it included | [11:09] |
| hverkuil | ttomov: I'll probably review it this Friday or the Monday after.
just FYI | [11:09] |
| ttomov | mchehab: ok. I was just worried about this error from kbuild bot. If this is not a problem for anyone, I will wait for review before I resend
hverkuil: thank you | [11:10] |
| hverkuil | mchehab: I expect that after this round of merges the media merge window will close? | [11:10] |
| mchehab | ttomov: no, this is not a problem, but better to reply to that kbuild bot explaining what's needed to fix the issue - for other reviewers to know | [11:11] |
| ttomov | mchehab: ok | [11:12] |
| mchehab | hverkuil: yeah, I'm handling the final patches for 4.13 this week | [11:12] |
| hverkuil | Yeah! imx is in! That will make a few people very happy. | [11:16] |
| ................... (idle for 1h31mn) | ||
| svarbanov1 | mchehab: I've sent an email to you, where I have fixed COMPILE_TEST-ing of venus driver in the venus Kconfig. | [12:47] |
| mchehab | do you know when the patch for the qcom_scm will be applied?
hverkuil: yes... finally :-) respanning a 34 patch series like what happened with i.mx is not fun | [12:49] |
| svarbanov1 | mchehab: it has been rejected, so re-design will be needed, so most probably it will not be 4.13 material | [12:51] |
| mchehab | still, I would have preferred if this were not merged under staging
ok, so let's apply your alternative approach please submit it, c/c me I'll apply it ASAP | [12:51] |
| svarbanov1 | mchehab: what is expected, one patch or the whole series ? | [12:53] |
| mchehab | no, what's applied, is applied
just submit the ones related to Kconfig | [12:53] |
| svarbanov1 | mchehab: ok, thanks! | [12:54] |
| ..... (idle for 21mn) | ||
| mchehab: done! | [13:15] | |
| .............. (idle for 1h9mn) | ||
| mort | hey, I have a device with a camera from Qualcomm. `ioctl(fd, VIDIOC_TRY_FMT, &video_fmt)` returns -1, with the correct file descriptor. video_fmt is an instance of the v4l2_video_format struct, with video_fmt.fmt.pix.width/height/pixelformat set to values which the camera should support.
any idea what could be wrong? it's in code from the webrtc project - what that code does is, for each device in /dev/video{0..63}, go through all combinations of a bunch of pixel formats and a bunch of resolutions, and use the VIDIOC_TRY_FMT ioctl to figure out what each device supports each of the calls to ioctl returns -1 | [14:24] |
| hverkuil | it's a driver from the qualcomm bsp? | [14:29] |
| mort | it's an arm device running Linux 4.9.27+linaro, so it's using whatever driver comes with that | [14:30] |
| hverkuil | what does v4l2-ctl -D return? | [14:31] |
| mort | https://p.iotek.org/abd
"not using libv4l2", is that an issue? | [14:31] |
| hverkuil | no, not a problem.
It's a multiplanar device driver ("Video Capture Multiplanar") | [14:33] |
| snawrocki | mort: with multiplanar API you should use video_fmt.fmt.pix_mplane, not video_fmt.fmt.pix | [14:35] |
| hverkuil | as snawrocki says. | [14:35] |
| mort | hmm. That's a problem with google's webrtc library then
is there a way to figure out if a device is multiplanar or not, such that I can make this code support both? | [14:36] |
| snawrocki | you can use VIDIOC_QUERYCAP for that, https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-querycap.html | [14:40] |
| mort | did you mean pix_mp instead of pix_mplane? GCC claims pix_mplane doesn't exist, but pix_mp does | [14:41] |
| snawrocki | yes, sorry, pix_mp | [14:43] |
| mort | btw, should ioctl set errno to EINVAL if you give it a video_fmt the device doesn't support?
just to make sure I'm not trying to fix the wrong problem yes it is, just found it in the documentation | [14:47] |
| snawrocki | pix vs. pix_mp might also be not your problem in this case since layout of first fields (width/height/pixelformat) is same for struct v4l2_pix_format and struct v4l2_pix_format_mplane | [14:55] |
| mort | how does v4l2 know what struct to use? Does it choose based on whether it's a multiplane device or not? | [14:56] |
| ttomov | To query the current parameters applications set the type field of a struct v4l2_format to the respective buffer (stream) type. For example video capture devices use V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE.
if buffer type value set by the userspace is not suppoted, the ioctl will return error | [14:59] |
| *** | hfr1 has left | [15:05] |
| mort | alright, patched it now to use pix_mp if it's multi planar, and it now finds the correct devices
thanks for the help | [15:07] |
| snawrocki | mort: yes, drivers reporting *_MPLANE capabilities always use pix_mp | [15:07] |
| hverkuil | ANN: I'm unreachable tomorrow and Thursday morning. Just so people are aware. | [15:08] |
| svarbanov1 | hverkuil: can you ping me when you have time to share your ideas about video codec testing | [15:13] |
| hverkuil | svarbanov1: remind me on Friday morning.
But in a nutshell: v4l2-compliance should be extended for this. | [15:19] |
| svarbanov1 | hverkuil: ok, what will be used for demux and to extract elementary stream | [15:20] |
| hverkuil | Testing an encoder is probably easiest: I think the only thing missing is that v4l2-compliance expects that buffers come out at the same order as they come in (i.e. no reordering)
brb svarbanov1: currently v4l2-compliance will use the test pattern generator to generate raw video frames (assuming the tpg can handle one of the available pixelformats). for a decode this is harder: we need a way to package an encoded stream and feed it as input to v4l2-compliance. decode -> decoder the tpg can't be used for that for obvious reasons. | [15:20] |
| svarbanov1 | hverkuil: did you considered to use ffmpeg for example
hverkuil: or we can use a predefined elementary streams for every codec | [15:27] |
| hverkuil | the problem is that v4l2-compliance reads from a file or stdin, and it needs to know the 'bytesused' in each frame. You don't want to link ffmpeg into v4l2-compliance, so we need something smarted.
but i have to leave. Let's discuss this further on Friday. | [15:29] |
| svarbanov1 | ok, see you on Friday | [15:29] |
| hverkuil | it would be good if you can test a bit with v4l2-compliance and the encoder. I'm curious to know how well (or not) v4l2-compliance works.
(that's using the -s option to test streaming) TBC on Friday. | [15:30] |
| ..... (idle for 23mn) | ||
| *** | benjiG has left | [15:54] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |