hverkuil: ping
hverkuil: ping
posciak: pong
posciak: pong
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?
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.
that's another issue
that's another issue
Unrelated to your question, but it should be fixed.
Unrelated to your question, but it should be fixed.
however the packed thing got me interested
however the packed thing got me interested
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.
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"
No, I'm wrong.
No, I'm wrong.
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?
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.
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
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.
yeah, but is it safe to make these assumptions?
yeah, but is it safe to make these assumptions?
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.
I see ok
I see ok
thanks
thanks
see e.g. sound/core/pcm_compat.c
see e.g. sound/core/pcm_compat.c
I see, ok thanks again
I see, ok thanks again
what are you trying to do? Can I help?
what are you trying to do? Can I help?
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
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?
hverkuil: the structs are not in the union, which breaks alignment
hverkuil: the structs are not in the union, which breaks alignment
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.
sailus: hyv?? huomenta
sailus: hyv?? huomenta
hmm, that might not be true
hmm, that might not be true
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
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.
posciak: ping
posciak: ping
janaszewski: Dzien dobry!
janaszewski: Dzien dobry!
sailus: you were trying to reach me a few days ago
sailus: you were trying to reach me a few days ago
janaszewski: Yeah, I think I just sent you and e-mail then.
janaszewski: Yeah, I think I just sent you and e-mail then.
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
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! :-)
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)
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 :-)
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
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.
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
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.
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
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
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
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
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
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 :-)
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
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)
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
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/
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
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 ?
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?
that's correct
that's correct
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.
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
I am using read/write, not mmap
I am using read/write, not mmap
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
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 :)
vb2 calls queue_setup internally when it needs to allocate buffers
vb2 calls queue_setup internally when it needs to allocate buffers
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
and it should do so when using read/write too
and it should do so when using read/write too
I am sure it calls it
I am sure it calls it
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
ok
ok
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
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
(actually I have reports that it kills the performance)
(actually I have reports that it kills the performance)
stormer: I'm not surprised
stormer: I'm not surprised
we should combine multiple packets per buffer
we should combine multiple packets per buffer
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.
pinchartl, ok. I was using qv4l2 to capture the frames
pinchartl, ok. I was using qv4l2 to capture the frames
And that's typical for similar drivers.
And that's typical for similar drivers.
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
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
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.
hverkuil: driver was v4l1722
hverkuil: driver was v4l1722
not upstream, not my problem :-)
not upstream, not my problem :-)
oh really
oh really
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?
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
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
yes, it's a bad driver default.
yes, it's a bad driver default.
ok, thanks
ok, thanks
Ah, ieee 1722. It is an sdi card perhaps?
Ah, ieee 1722. It is an sdi card perhaps?
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
koike: you're welcome
koike: you're welcome
I have to call it a day though
I have to call it a day though
hverkuil: looks like an AVB appliance, bus_info: 'platform:avb-0
hverkuil: looks like an AVB appliance, bus_info: 'platform:avb-0
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?
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 ^
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.
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
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?
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 ?
hverkuil: pong, sorry, most likely too late