| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| posciak | hverkuil: ping
hverkuil: ping | [06:20] |
| hverkuil | posciak: pong
posciak: pong | [06:20] |
| posciak | hverkuil: I've been looking at v4l2_input32 and v4l2_input, I was wondering why the former is packed and the latter isn't, is this some kind of legacy issue?
hverkuil: I've been looking at v4l2_input32 and v4l2_input, I was wondering why the former is packed and the latter isn't, is this some kind of legacy issue? | [06:21] |
| hverkuil | Huh, I see that v4l2_input32 doesn't match v4l2_input: one of the reserved fields has been replaced by 'capabilities' and that's not updated in v4l2_input32.
Huh, I see that v4l2_input32 doesn't match v4l2_input: one of the reserved fields has been replaced by 'capabilities' and that's not updated in v4l2_input32. | [06:23] |
| posciak | that's another issue
that's another issue | [06:23] |
| hverkuil | Unrelated to your question, but it should be fixed.
Unrelated to your question, but it should be fixed. | [06:23] |
| posciak | however the packed thing got me interested
however the packed thing got me interested | [06:23] |
| hverkuil | Probably the same is true for v4l2_output32.
Probably the same is true for v4l2_output32. Anyway, it doesn't look like the packed attribute is necessary here since the 'std' field (a u64) is nicely aligned, so packed doesn't do anything. Anyway, it doesn't look like the packed attribute is necessary here since the 'std' field (a u64) is nicely aligned, so packed doesn't do anything. Just checked with a quick program printing the sizeof of the struct, both packed and unpacked. Just checked with a quick program printing the sizeof of the struct, both packed and unpacked. and the sizes are the same. and the sizes are the same. | [06:23] |
| posciak | so adding packed basically is intended to allow direct memcpy?
so adding packed basically is intended to allow direct memcpy? so we are saying "we assume that compiler will make the structfoo packed, even though we don't specify it as packed, on 32b" so we are saying "we assume that compiler will make the structfoo packed, even though we don't specify it as packed, on 32b" | [06:26] |
| hverkuil | No, I'm wrong.
No, I'm wrong. | [06:27] |
| posciak | so we specify structfoo32 packed
so we specify structfoo32 packed why not specify the 64b version as packed then? why not specify the 64b version as packed then? | [06:27] |
| hverkuil | Sorry, I looked at the sizeof when compiling for 32 bit, but I need to look at the sizeof when compiling for 64 bit, and then the sizes differ.
Sorry, I looked at the sizeof when compiling for 32 bit, but I need to look at the sizeof when compiling for 64 bit, and then the sizes differ. sizeof for packed = 76, unpacked = 80. The sizeof when compiling for 32 bit is always 76. sizeof for packed = 76, unpacked = 80. The sizeof when compiling for 32 bit is always 76. So packed is necessary here. So packed is necessary here. | [06:28] |
| posciak | so basically we should've specified structfoo as packed (of course this is too late)
so basically we should've specified structfoo as packed (of course this is too late) which means we can't have 32b packed, or rather, we need to copy field by field which means we can't have 32b packed, or rather, we need to copy field by field | [06:29] |
| hverkuil | I don't follow. Are you talking about structs in general or v4l2_input specifically?
I don't follow. Are you talking about structs in general or v4l2_input specifically? Note that for v4l2_input the difference between packed and unpacked is extra padding at the end (see the comment with get_v4l2_input32()). Note that for v4l2_input the difference between packed and unpacked is extra padding at the end (see the comment with get_v4l2_input32()). So no need to copy field by field in this case. So no need to copy field by field in this case. | [06:31] |
| posciak | yeah, but is it safe to make these assumptions?
yeah, but is it safe to make these assumptions? | [06:32] |
| hverkuil | yes
yes This is used all over in the kernel whenever compat32 support is needed. This isn't just v4l2. This is used all over in the kernel whenever compat32 support is needed. This isn't just v4l2. | [06:32] |
| posciak | I see ok
I see ok thanks thanks | [06:33] |
| hverkuil | see e.g. sound/core/pcm_compat.c
see e.g. sound/core/pcm_compat.c | [06:35] |
| posciak | I see, ok thanks again
I see, ok thanks again | [06:35] |
| hverkuil | what are you trying to do? Can I help?
what are you trying to do? Can I help? | [06:35] |
| posciak | I noticed that v4l2_event needs compat handling
I noticed that v4l2_event needs compat handling and have been reviewing other things while doing that and have been reviewing other things while doing that | [06:36] |
| hverkuil | Ah, OK. Well, checking whether new fields have propagated to the 32 bit structs would be useful. It wouldn't surprise me if there are other mismatches like v4l2_input.
Ah, OK. Well, checking whether new fields have propagated to the 32 bit structs would be useful. It wouldn't surprise me if there are other mismatches like v4l2_input. erm, isn't v4l2_event already there? erm, isn't v4l2_event already there? posciak: compat support for v4l2_event is already part of v4l2-compat-ioctl32.c, so what's the problem? posciak: compat support for v4l2_event is already part of v4l2-compat-ioctl32.c, so what's the problem? | [06:38] |
| posciak | hverkuil: the structs are not in the union, which breaks alignment
hverkuil: the structs are not in the union, which breaks alignment | [06:42] |
| hverkuil | are you sure? None of the structs in the union should have alignment problems.
are you sure? None of the structs in the union should have alignment problems. | [06:43] |
| janaszewski | sailus: hyv?? huomenta
sailus: hyv?? huomenta | [06:44] |
| hverkuil | hmm, that might not be true
hmm, that might not be true | [06:45] |
| posciak | hverkuil: I think it's because structs are aligned to largest member
hverkuil: I think it's because structs are aligned to largest member hverkuil: but in this case we only have an array of bytes hverkuil: but in this case we only have an array of bytes | [06:45] |
| hverkuil | No, I still think this should be OK.
No, I still think this should be OK. It depends on whether the union is 64 bit or 32 bit aligned on a 64 bit platform. It depends on whether the union is 64 bit or 32 bit aligned on a 64 bit platform. If it aligns 64 bit then it's OK, if not, then struct v4l2_event_ctrl needs a compat version. If it aligns 64 bit then it's OK, if not, then struct v4l2_event_ctrl needs a compat version. it aligns at a 64-bit boundary (so there is a hole between 'type' and 'u'), so I think everything is working just fine. it aligns at a 64-bit boundary (so there is a hole between 'type' and 'u'), so I think everything is working just fine. | [06:46] |
| .................... (idle for 1h39mn) | ||
| posciak: ping
posciak: ping | [08:28] | |
| .... (idle for 17mn) | ||
| sailus | janaszewski: Dzien dobry!
janaszewski: Dzien dobry! | [08:45] |
| janaszewski | sailus: you were trying to reach me a few days ago
sailus: you were trying to reach me a few days ago | [08:47] |
| sailus | janaszewski: Yeah, I think I just sent you and e-mail then.
janaszewski: Yeah, I think I just sent you and e-mail then. | [08:47] |
| janaszewski | sailus: ok, I got it
sailus: ok, I got it I am about to send the new patch set I am about to send the new patch set | [08:48] |
| sailus | I think it was related to v4l2_fh_is_singular() .
I think it was related to v4l2_fh_is_singular() . janaszewski: I'm looking forward to that! :-) janaszewski: I'm looking forward to that! :-) | [08:48] |
| ................................................................... (idle for 5h34mn) | ||
| stormer | hverkuil: pinchartl: When UCV drivers says sRGB for a YUV format, it really means sYCC right ?
hverkuil: pinchartl: When UCV drivers says sRGB for a YUV format, it really means sYCC right ? * UVC * UVC (sRGB spec has no YUV->RGB conversion matrix, sYCC do) (sRGB spec has no YUV->RGB conversion matrix, sYCC do) | [14:22] |
| hverkuil | stormer: yes, they mean sYCC.
stormer: yes, they mean sYCC. Or, to be precise: sRGB chromaticities, sRGB transfer function, sYCC Y'CbCr encoding and limited range quantization. Or, to be precise: sRGB chromaticities, sRGB transfer function, sYCC Y'CbCr encoding and limited range quantization. But I'm pedantic about colorspace definitions :-) But I'm pedantic about colorspace definitions :-) | [14:27] |
| stormer | thanks, it created a bit of confusion, as we have sRGB for uncorrected RGB images in GST, someone proposed a patch adding colorimetry support, and because the named match, I never notice there was something wrong ;-P
thanks, it created a bit of confusion, as we have sRGB for uncorrected RGB images in GST, someone proposed a patch adding colorimetry support, and because the named match, I never notice there was something wrong ;-P | [14:28] |
| hverkuil | Note that V4L2 specifies an sYCC Y'CbCr encoding, but that will likely disappear in the future since I'm pretty sure it is identical to the 601 encoding.
Note that V4L2 specifies an sYCC Y'CbCr encoding, but that will likely disappear in the future since I'm pretty sure it is identical to the 601 encoding. | [14:30] |
| stormer | ok
ok hverkuil: don't worry about being pedentic, wtay does pretty much the same, as an example, the color space we speak about is defined as 1:4:0:0 hverkuil: don't worry about being pedentic, wtay does pretty much the same, as an example, the color space we speak about is defined as 1:4:0:0 which is the value of the enum or each range:matrix:transfer:primaries which is the value of the enum or each range:matrix:transfer:primaries most of the devs are completly clueless about these, I only started reading about it recently most of the devs are completly clueless about these, I only started reading about it recently | [14:31] |
| hverkuil | http://hverkuil.home.xs4all.nl/spec/media.html#colorspaces
http://hverkuil.home.xs4all.nl/spec/media.html#colorspaces I spend a lot of time on that section in the V4L2 spec. I spend a lot of time on that section in the V4L2 spec. | [14:34] |
| pinchartl | stormer: the uvcvideo driver doesn't have very good support for colorspaces. that should be fixed
stormer: the uvcvideo driver doesn't have very good support for colorspaces. that should be fixed | [14:43] |
| koike | Hi! I am writing a virtual v4l2 capture device driver with vb2_vmalloc_memops, thus I have a thread to fill out the buffers. But when I get the buffer image pointer with ptr = vb2_plane_vaddr and do a memset(ptr, 0, sizeimage) I was hopping to get a black screen, but it is not what is happening, should this work? Or this is wrong?. I am using V4L2_PIX_FORMAT_RGB24. Here is what I am doing in the thread: http://pastebin.com/GKfv1xF4
Hi! I am writing a virtual v4l2 capture device driver with vb2_vmalloc_memops, thus I have a thread to fill out the buffers. But when I get the buffer image pointer with ptr = vb2_plane_vaddr and do a memset(ptr, 0, sizeimage) I was hopping to get a black screen, but it is not what is happening, should this work? Or this is wrong?. I am using V4L2_PIX_FORMAT_RGB24. Here is what I am doing in the thread: http://pastebin.com/GKfv1xF4 | [14:43] |
| stormer | pinchartl: nod, as long as it's not lieing in a way that the image is radically screwed, no one will complain ;-P
pinchartl: nod, as long as it's not lieing in a way that the image is radically screwed, no one will complain ;-P | [14:46] |
| pinchartl | stormer: if the webcam lies in the first place I can't do anything about it of course
stormer: if the webcam lies in the first place I can't do anything about it of course koike: hello koike: hello | [14:46] |
| stormer | pinchartl: sure, to be honnest, pretty much all webcam uses sYCC (specified as sRGB) because this is what you are suppose to put inside a JPEG image
pinchartl: sure, to be honnest, pretty much all webcam uses sYCC (specified as sRGB) because this is what you are suppose to put inside a JPEG image pinchartl: what I was asking, is what sRGB in V4L2 meants, since according to the spec, it only applies to uncorrected RGB image, but the UVC driver uses it for YUV images too pinchartl: what I was asking, is what sRGB in V4L2 meants, since according to the spec, it only applies to uncorrected RGB image, but the UVC driver uses it for YUV images too | [14:47] |
| pinchartl | koike: what's the value of vcap->format.sizeimage ?
koike: what's the value of vcap->format.sizeimage ? make sure it's not 0 :-) make sure it's not 0 :-) | [14:48] |
| koike | pinchartl, it should be width*3*height = 100*3*100. I'll print that to make sure
pinchartl, it should be width*3*height = 100*3*100. I'll print that to make sure | [14:49] |
| stormer | hverkuil: another unrelated question, when using TS muxers or demuxers through V4L2, is it possible to have more then 1 packet per buffer (e.g. having more then 188 bytes per buffer)
hverkuil: another unrelated question, when using TS muxers or demuxers through V4L2, is it possible to have more then 1 packet per buffer (e.g. having more then 188 bytes per buffer) | [14:51] |
| koike | pinchartl, it is 30000. So what I am doing should work right? Maybe my mistake is in configuring the buffers before the stream
pinchartl, it is 30000. So what I am doing should work right? Maybe my mistake is in configuring the buffers before the stream | [14:52] |
| pinchartl | when do you mean by configuring the buffers before the stream ?
when do you mean by configuring the buffers before the stream ? s/when/what/ s/when/what/ | [14:53] |
| koike | pinchartl, configuring the size of the frame, the pix format, the number of planes, width, height, field, bytesperline, colorspace, or in queue_setup
pinchartl, configuring the size of the frame, the pix format, the number of planes, width, height, field, bytesperline, colorspace, or in queue_setup | [14:56] |
| pinchartl | it's normal to have buffers allocated before the start of the stream
it's normal to have buffers allocated before the start of the stream when do you start your thread ? when do you start your thread ? | [14:58] |
| koike | inside the vb2_ops start_streaming
inside the vb2_ops start_streaming it is the videobuf2 framework that allocates the buffers for me right? it is the videobuf2 framework that allocates the buffers for me right? | [14:58] |
| pinchartl | that's correct
that's correct | [14:59] |
| hverkuil | stormer: Frankly, I don't know. There is nothing in the spec that would prohibit it, but it would definitely be unusual.
stormer: Frankly, I don't know. There is nothing in the spec that would prohibit it, but it would definitely be unusual. | [14:59] |
| pinchartl | userspace asks the driver to allocate buffers by calling the REQBUFS or CREATE_BUFS ioctl
userspace asks the driver to allocate buffers by calling the REQBUFS or CREATE_BUFS ioctl the driver delegates those ioctls to vb2 the driver delegates those ioctls to vb2 | [14:59] |
| koike | I am using read/write, not mmap
I am using read/write, not mmap | [15:00] |
| pinchartl | which then calls the queue_setup function to let the driver compute the proper buffer size and number of buffers
which then calls the queue_setup function to let the driver compute the proper buffer size and number of buffers ah ah I would start with mmap I would start with mmap partly because that's what I know best partly because that's what I know best | [15:00] |
| koike | so userspace doesn't call reqbufs, I thought that videobuf2 calls queue_setup internally
so userspace doesn't call reqbufs, I thought that videobuf2 calls queue_setup internally ok, I'll try mmap :) ok, I'll try mmap :) | [15:01] |
| pinchartl | vb2 calls queue_setup internally when it needs to allocate buffers
vb2 calls queue_setup internally when it needs to allocate buffers | [15:01] |
| stormer | hverkuil: I was wondering, in GST we avoid producing 188bytes per buffer because of the overhead, on v4l2 API there is a huge ioctl overhead, I was mainly wondering how these are used in practive to reduce that
hverkuil: I was wondering, in GST we avoid producing 188bytes per buffer because of the overhead, on v4l2 API there is a huge ioctl overhead, I was mainly wondering how these are used in practive to reduce that | [15:01] |
| pinchartl | and it should do so when using read/write too
and it should do so when using read/write too | [15:01] |
| koike | I am sure it calls it
I am sure it calls it | [15:02] |
| pinchartl | but I would still start with mmap, you'll have more fine-grained control over the process from userspace
but I would still start with mmap, you'll have more fine-grained control over the process from userspace | [15:02] |
| koike | ok
ok | [15:02] |
| stormer | hverkuil: right now we let the driver pick the buffer size, obviously it picks 188, but we thought this might be inefficient
hverkuil: right now we let the driver pick the buffer size, obviously it picks 188, but we thought this might be inefficient | [15:02] |
| pinchartl | you can use yavta (http://git.ideasonboard.org/yavta.git) or v4l2-ctl (part of v4l-utils) to capture frames using mmap
you can use yavta (http://git.ideasonboard.org/yavta.git) or v4l2-ctl (part of v4l-utils) to capture frames using mmap | [15:02] |
| stormer | (actually I have reports that it kills the performance)
(actually I have reports that it kills the performance) | [15:02] |
| pinchartl | stormer: I'm not surprised
stormer: I'm not surprised we should combine multiple packets per buffer we should combine multiple packets per buffer | [15:02] |
| hverkuil | stormer: I stand corrected: looking at drivers/media/pci/cx88/cx88-blackbird.c I see that each buffer has size 188 * 4 * 32 in bytes.
stormer: I stand corrected: looking at drivers/media/pci/cx88/cx88-blackbird.c I see that each buffer has size 188 * 4 * 32 in bytes. | [15:03] |
| koike | pinchartl, ok. I was using qv4l2 to capture the frames
pinchartl, ok. I was using qv4l2 to capture the frames | [15:03] |
| hverkuil | And that's typical for similar drivers.
And that's typical for similar drivers. | [15:03] |
| pinchartl | qv4l2 works too
qv4l2 works too but might exercise more of the v4l2 api but might exercise more of the v4l2 api I personally use yavta for initial driver development, but other applications can be fine too I personally use yavta for initial driver development, but other applications can be fine too | [15:04] |
| stormer | hverkuil: I need to find back which driver it was, maybe I could blame the driver to not pick a sensible default
hverkuil: I need to find back which driver it was, maybe I could blame the driver to not pick a sensible default hverkuil: note that I think ts_packet_size is a lie in that driver, since a packet is really 188bytes, not 188*4 bytes iirc hverkuil: note that I think ts_packet_size is a lie in that driver, since a packet is really 188bytes, not 188*4 bytes iirc | [15:05] |
| hverkuil | stormer: the naming is historical, don't attach too much meaning to it. Bottom line is that 128 packets of 188 bytes are combined in one buffer.
stormer: the naming is historical, don't attach too much meaning to it. Bottom line is that 128 packets of 188 bytes are combined in one buffer. | [15:08] |
| stormer | hverkuil: driver was v4l1722
hverkuil: driver was v4l1722 | [15:08] |
| hverkuil | not upstream, not my problem :-)
not upstream, not my problem :-) | [15:09] |
| stormer | oh really
oh really stormer should have notice that stormer should have notice that | [15:09] |
| hverkuil | google doesn't find anything with that name. Is there a repo somewhere?
google doesn't find anything with that name. Is there a repo somewhere? | [15:10] |
| stormer | hverkuil: so shall I stand with "driver fault" "should pick a better default"
hverkuil: so shall I stand with "driver fault" "should pick a better default" hverkuil: all had was a gst log, in which I dump the name, http://m-to.de/gst_v4l2.log hverkuil: all had was a gst log, in which I dump the name, http://m-to.de/gst_v4l2.log | [15:10] |
| koike | pinchartl, I'll change to mmap then and see if I can debug. I'll came back to make questions if I get stuck again. Thanks
pinchartl, I'll change to mmap then and see if I can debug. I'll came back to make questions if I get stuck again. Thanks | [15:10] |
| hverkuil | yes, it's a bad driver default.
yes, it's a bad driver default. | [15:10] |
| stormer | ok, thanks
ok, thanks | [15:11] |
| hverkuil | Ah, ieee 1722. It is an sdi card perhaps?
Ah, ieee 1722. It is an sdi card perhaps? | [15:11] |
| stormer | I still got a bug in GSt, it's kind of silly to fail if gst decided to group more then the driver, but otherwise, the perf issue is not my problem either
I still got a bug in GSt, it's kind of silly to fail if gst decided to group more then the driver, but otherwise, the perf issue is not my problem either | [15:11] |
| pinchartl | koike: you're welcome
koike: you're welcome I have to call it a day though I have to call it a day though | [15:11] |
| stormer | hverkuil: looks like an AVB appliance, bus_info: 'platform:avb-0
hverkuil: looks like an AVB appliance, bus_info: 'platform:avb-0 | [15:13] |
| hverkuil | stormer: I'm actually very interested in an ieee 1722 driver. Can you find out where the source code is?
stormer: I'm actually very interested in an ieee 1722 driver. Can you find out where the source code is? or a contact or whatever? or a contact or whatever? | [15:13] |
| stormer | the reporter email was @cetitec.com if that helps, I really have no idea
the reporter email was @cetitec.com if that helps, I really have no idea tobias.modschiedler (at) cetitec.com tobias.modschiedler (at) cetitec.com hverkuil: thanks btw, your answer are really useful hverkuil: thanks btw, your answer are really useful pinchartl: same ^ pinchartl: same ^ | [15:14] |
| hverkuil | you're welcome! And thanks for the AVB contact, I'll send out an email later.
you're welcome! And thanks for the AVB contact, I'll send out an email later. | [15:19] |
| ...................... (idle for 1h49mn) | ||
| koike | When my driver sets the width x height, the userspace program always get the width adjusted to the closest multiple of 4. Is this normal? If my driver sets 100x100 in s_fmt/g_fmt/try_fmt, the userspace program reads 96x100, same thing with 50x50 (in the driver) -> 48x50 (in userspace), 450x450->448x450
When my driver sets the width x height, the userspace program always get the width adjusted to the closest multiple of 4. Is this normal? If my driver sets 100x100 in s_fmt/g_fmt/try_fmt, the userspace program reads 96x100, same thing with 50x50 (in the driver) -> 48x50 (in userspace), 450x450->448x450 | [17:08] |
| ................................................. (idle for 4h0mn) | ||
| bparrot | hverkuil, ping
hverkuil, ping running v4l-compliance on a 4.1-rc6 development driver i get the following error: fail: v4l2-test-buffers.cpp(547): check_0(crbufs.reserved, sizeof(crbufs.reserved)) running v4l-compliance on a 4.1-rc6 development driver i get the following error: fail: v4l2-test-buffers.cpp(547): check_0(crbufs.reserved, sizeof(crbufs.reserved)) as far as i know these should be handled all in the vb2 framework, no? the driver is using all vb2_ioctl* helper functions. as far as i know these should be handled all in the vb2 framework, no? the driver is using all vb2_ioctl* helper functions. What can i be missing? What can i be missing? | [21:08] |
| ............................... (idle for 2h31mn) | ||
| stormer | hverkuil: are m2m h264 decoder expected to read the colorimetry information and provide it ?
hverkuil: are m2m h264 decoder expected to read the colorimetry information and provide it ? or is user space expected to parse the sps/pps and figure-out if it's available ? or is user space expected to parse the sps/pps and figure-out if it's available ? | [23:43] |
| posciak | hverkuil: pong, sorry, most likely too late | [23:53] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |