Re: udev rules for persistent symlinks for adapter?/frontend0 devices
KERNEL[1335308536.258048] add
/devices/pci:00/:00:14.4/:03:00.0/dvb/dvb0.frontend0 (dvb)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/pci:00/:00:14.4/:03:00.0/dvb/dvb0.frontend0
Perhaps this is the ultimate in persistence, but unfortunately is also
highly dependent on physical location in the machine (i.e. which PCI
slot even).
SUBSYSTEM=dvb
DEVNAME=dvb/adapter0/frontend0
AFAIU, the adapter0 is not representative of physical device
persistence but is rather dependent on probing order. IOW,
dvb/adapter0/frontend0 will always be the first DVB device found but
won't be a guarantee of which physical device it is. This is what I
currently have with /dev/dvb/adapter{0.1} which is unfortunately
unsuitable since it's so predictable.
I might end up having to bite the bullet and using DEVNAME. :-(
Thanks for the info though, much appreciated,
b.
All you need to do is to use adapter_nr option passed to the kernel module, i.e.
options dvb_usb_dib0700 adapter_nr=0,1
The above line tell the module to assign 0 and 1 to the card that uses
that module, so in your case you create a options.conf under
/etc/modprobe.d/
then do 2 lines of
option kernel_module adapter_nr=0
option kernel_module adapter_nr=1
On reboot the kernel modules will pick up it's adapter number and
apply it for you, no need for any udev rules.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[media-ctl PATCH] Compare entity name length aswell
Otherwise, some false positives might arise when
having 2 subdevices with similar names, like:
OMAP4 ISS ISP IPIPEIF
OMAP4 ISS ISP IPIPE
Before this patch, trying to find OMAP4 ISS ISP IPIPE, resulted
in a false entity match, retrieving OMAP4 ISS ISP IPIPEIF
information instead.
Checking length should ensure such cases are handled well.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
src/mediactl.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mediactl.c b/src/mediactl.c
index 5b8c587..451a386 100644
--- a/src/mediactl.c
+++ b/src/mediactl.c
@@ -66,7 +66,8 @@ struct media_entity *media_get_entity_by_name(struct
media_device *media,
for (i = 0; i media-entities_count; ++i) {
struct media_entity *entity = media-entities[i];
- if (strncmp(entity-info.name, name, length) == 0)
+ if ((strncmp(entity-info.name, name, length) == 0)
+ (strlen(entity-info.name) == length))
return entity;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG
Hi,
On 04/24/2012 12:34 PM, Jean-Francois Moine wrote:
On Mon, 23 Apr 2012 23:34:05 +0200
Hans de Goedehdego...@redhat.com wrote:
Thanks for your work on this! I've just spend almost 4 days wrestling
which the Pixart JPEG decompression code to try to better understand
these cams, and I have learned quite a bit and eventually came up
with a different approach.
But your effort is appreciated! After spending so much time on this
myself, I can imagine that it took you quite some time to come up
with your solution.
Attach is a 4 patch patchset which I plan to push to v4l-utils
tomorrow (after running some more tests in daylight). I'll also try
to do some kernel patches tomorrow to match...
Hi Hans,
I tried your patch, but I am not happy with the images I have (pac7302).
You say that the marker cannot be in the range 0..31 (index 0..7), but
I have never seen a value lower than 68 (index 17).
If you change register 0x80 in bank/page 1 to 42 on pac7311 or larger then
circa 100 on pac7302, you will get markers with bit 8 set. When this happens
you will initially get markers 0xa0 - 0xa4 ... 0xbc and the stream tends to
stabilize on 0xbc. Likewise if you remove the artificial limiting of
the pac7302 to 15 fps from the driver you will get markers 0x44 - 0x48 ...
0x7c.
The images look a lot better with bit 8 set, so I plan to run some tests
wrt what framerates can safely handle that (it uses more bandwidth) and set
bit 8 on lower framerates.
This last marker value (68) is the default when the images have no big
contrasts. With such images / blocks, the standard JPEG quantization
table does not work well. It seems that, for this value, the table
should be full of either 7 or 8 (8 gives a higher contrast).
Using a table with all 7's or 8's looses a lot of sharpness in image which
high frequency components, for example the grain of a rough wall completely
disappears.
I've (once more) tried to use a more simplified / flat quant table, I
ended up with the table below, so as to not loose too much sharpness:
0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x10, 0x10,
0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20,
0x28, 0x28, 0x28,
0x28, 0x28, 0x28, 0x28,
0x30, 0x30, 0x30, 0x30,
0x30, 0x30, 0x30, 0x30,
0x38, 0x38, 0x38, 0x38,
0x38, 0x38, 0x38,
0x40, 0x40, 0x40, 0x40, 0x40,
0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40,
0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40,
Using the same qfactor as before, so the 0x0b translates to 7, with this
table the images only change slightly, mostly because of the lower
values at the end. This means we loose some sharpness of the picture
(loose of high frequency components), and when watching a moving picture
with that loose of sharpness we also loose some noise. But other then that
the results are almost the same.
When using 0x08 rather then 0x07 we seem to get accumlating DC errors,
leading to clear block divisions at the end of an mcu row.
Given the above I've decided to stick with my solution for now, I know
it is not the ideal solution, but I believe it is the best we have. Also
notice that my solution in essence gives us the same table for marker 68
as we used before your tinyjpeg: Better luminance quantization table for
Pixart JPEG patch.
Here is the sequence which works better (around line 1420 of tinyjpeg.c):
-8--
/* And another special Pixart feature, the DC quantization
factor is fixed! */
qt[0] = 7; // 8 gives a higher contrast
// special case for 68
if (marker == 68) {
for (i = 1; i 64; i++)
qt[i] = 7; // also works with 8
} else {
for (i = 1; i 64; i++) {
j = (standard_quantization[0][i] * comp + 50) / 100;
qt[i] = (j 255) ? j : 255;
}
}
build_quantization_table(priv-Q_tables[0], qt);
-8--
About the other marker values, it seems also that the quantization
tables are not optimal: some blocks are either too much (small
contrasted lines) or not enough (big pixels) decompressed. As you know,
a finer adjustment would ask for a long test time, so, I think we can
live with your code.
Yeah short of someone disassembling and reverse-engineering the windows driver
we will probably never figure out the exact correct tables.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Using UVC webcam gadget with a real v4l2 device
Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Tuesday, April 24, 2012 2:26 AM To: Bhupesh SHARMA Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; ba...@ti.com; g.liakhovet...@gmx.de Subject: Re: Using UVC webcam gadget with a real v4l2 device Hi Bhupesh, On Tuesday 24 April 2012 02:46:22 Bhupesh SHARMA wrote: On Monday, April 23, 2012 7:47 PM Laurent Pinchart wrote: On Monday 23 April 2012 02:24:53 Bhupesh SHARMA wrote: Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. The UVC webcam gadget works fine with the user space application handling the CONTROL events and providing DATA events. Now, I wish to interface a real v4l2 device, for e.g. VIVI or more particularly a soc_camera based host and subdev pair. Now, I see that I can achieve this by opening the UVC and V4L2 devices and doing MMAP - REQBUF - QBUF - DQBUF calls on both the devices per the UVC control event received. But this will involve copying the video buffer in the user-space application from v4l2 (_CAPTURE) to uvc (_OUTPUT) domains, which will significantly reduce the video capture performance. Is there a better solution to this issue? Maybe doing something like a RNDIS gadget does with the help of u_ether.c like helper routines. But if I remember well it also requires the BRCTL (Bridge Control Utility) in userspace to route data arriving on usb0 to eth0 and vice- versa. Not sure though, if it does copying of a skb buffer from ethernet to usb domain and vice-versa. To avoid copying data between the two devices you should use USERPTR instead of MMAP on at least one of the two V4L2 devices. The UVC gadget driver doesn't support USERPTR yet though. This shouldn't be too difficult to fix, we need toreplace the custom buffers queue implementation with videobuf2, as has been done in the uvcvideo driver. I was thinking of using the USERPTR method too, but I realized that currently neither UVC webcam gadget nor soc-camera subsystem supports this IO method. They support only MMAP IO as of now :( Both soc-camera and the UVC gadget driver should be ported to videobuf2 to fix the problem. I'll try to implement this. Would you then be able to test patches ? For sure, I can test your patches on my setup. I had a quick look, but there's a bit more work than expected. The UVC gadget driver locking scheme needs to be revisited. I unfortunately won't have time to work on that in the next couple of weeks, and very probably not before end of June. Sorry. If you want to give it a try, I can provide you with some pointers. It's a pity. You are the best person to do it as you have in-depth know -how of both v4l2 and UVC webcam gadget. But I can give it a try if you can provide me some pointers.. BTW, I was exploring GSTREAMER to use the data arriving from soc- camera (v4l2) capture device '/dev/video1' via 'v4l2src' plugin and routing the same to the UVC gadget '/dev/video0' via the 'v4l2sink' plugin. Don't know if this can work cleanly in my setup and whether GSTREAMER actually performs a buffer copy internally. But I will at-least give it a try :) There will definitely be a buffer copy (and actually two copies, as the UVC gadget driver performs a second copy internally) if you don't use USERPTR. That's what I was afraid of. But can you let me know where the gadget driver performs a second copy internally, so that I can also start exploring the USERPTR method using the pointers provided by you.. Regards, Bhupesh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 3.3-rc1] media updates
On Sun, Jan 15, 2012 at 14:41, Mauro Carvalho Chehab mche...@redhat.com wrote:
Laurent Pinchart (18):
[media] uvcvideo: Move fields from uvc_buffer::buf to uvc_buffer
[media] uvcvideo: Use videobuf2-vmalloc
It seems these change (3d95e932573c316ad56b8e2f283e26de0b9c891c
resp. 6998b6fb4b1c8f320adeee938d399c4d8dcc90e2) broke the
build for nommu a while ago, as uvc_queue_get_unmapped_area() was not
or was incorrectly updated:
drivers/media/video/uvc/uvc_queue.c:254:23: error: 'struct
uvc_video_queue' has no member named 'count'
drivers/media/video/uvc/uvc_queue.c:255:18: error: 'struct
uvc_video_queue' has no member named 'buffer'
drivers/media/video/uvc/uvc_queue.c:256:19: error: 'struct vb2_buffer'
has no member named 'm'
drivers/media/video/uvc/uvc_queue.c:259:16: error: 'struct
uvc_video_queue' has no member named 'count'
drivers/media/video/uvc/uvc_queue.c:263:23: error: 'buf' undeclared
(first use in this function)
Cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/6171077/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG
Hi Hans, On Wed, 25 Apr 2012 16:19:57 +0200 Hans de Goede hdego...@redhat.com wrote: You say that the marker cannot be in the range 0..31 (index 0..7), but I have never seen a value lower than 68 (index 17). If you change register 0x80 in bank/page 1 to 42 on pac7311 or larger then circa 100 on pac7302, you will get markers with bit 8 set. When this happens you will initially get markers 0xa0 - 0xa4 ... 0xbc and the stream tends to stabilize on 0xbc. Likewise if you remove the artificial limiting of the pac7302 to 15 fps from the driver you will get markers 0x44 - 0x48 ... 0x7c. The images look a lot better with bit 8 set, so I plan to run some tests wrt what framerates can safely handle that (it uses more bandwidth) and set bit 8 on lower framerates. I carefully looked at the ms-windows pac7302 traces I have. The register 1-80 stays always in the range 0d..11, except sometimes 19 at start time. In these traces, the images with marker 44 (dec 68) look really better with all 08's as the quantization table. [snip] Yeah short of someone disassembling and reverse-engineering the windows driver we will probably never figure out the exact correct tables. Well, I got the SPC230NC.SYS of the ms-windows pac7302 driver, but it is not easy to disassemble because it has no symbol table. But, inside, I found this tables just before the Huffman table: - 0006C888 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006C908 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006C988 08 08 08 08 08 08 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 - 0006CA08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 20 - 0006CA88 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006CB08 08 0b 0b 0b 0b 0b 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 40 40 40 40 40 40 40 40 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006CB88 11 12 12 18 15 18 2f 1a 1a 2f 63 42 38 42 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006CC08 10 0b 0c 0e 0c 0b 10 0e 0d 0e 12 11 10 13 18 28 1a 18 16 16 18 31 23 25 1d 28 3a 33 3d 3c 39 33 38 37 40 48 5c 4e 40 44 57 45 37 38 50 6D 51 57 5F 62 67 68 67 3E 4D 71 78 70 64 78 5C 65 67 63 Don't they look like quantization tables? (the table 0006CB08 is quite the same the flat table you tried!) BTW, I don't think the exposure and gain controls use the right registers as they are coded in the actual gspca pac7302 subdriver. The ms-windows driver uses the registers (3-80 / 3-03), (3-05 / 3-04), (3-12) and (1-80) for autogain/exposure. The gspca test tarball of my web site includes a new AGC using these registers, but it does not work well. Maybe you could tell me what is wrong with it... Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Apr 25 19:00:17 CEST 2012 git hash:aa6d5f29534a6d1459f9768c591a7a72aadc5941 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: OK linux-3.1-i686: OK linux-3.2.1-i686: OK linux-3.3-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: tm6000 driver questions
- Message Transféré - Date: Wed, 25 Apr 2012 10:16:57 -0700 De: Vladimir Kerkez vker...@gmail.com À: castet.matth...@free.fr Sujet: tm6000 driver questions Hello, I would like to thank you for your outstanding work on the tm6000 chipset. Because of you (and many other people) I now have a pal tv tuner I can use. I just recently bought a mac book pro, how ever most of the drivers were not supported under the 3.2 kernel. I pulled down the latestest drivers for my Hauppauge 900H from linux tv (tm6000 edition). I read the your patch changes that you have made here: http://patchwork.linuxtv.org/patch/8968/ One of the first things I noticed is that the firmware for the tm6000 loads about 10-12 seconds faster, my tvtime starting at a normal speed ( it used to take up to 20 seconds to load ). Im assuming this is something you may have patched? If you did thanks so much! However I am now running into a issue I never saw before with my tm6000 tuner. I noticed that in this new version of the driver the channel switching is a lot faster, but it seems to be causing kernel panics. I believe the issues is that the channel switches so fast before the tuner gets a signal causing the kernel panic (the usb gets bad data and throws and emi). This always happens when the channel is changed. Here is a snippet of the kernel panic: [ 4760.587553] xc2028 14-0061: xc2028_get_reg 0004 called [ 4760.591160] xc2028 14-0061: xc2028_get_reg 0008 called *[ 4760.633815] hub 2-0:1.0: port 4 disabled by hub (EMI?), re-enabling...* [ 4760.633827] usb 2-4: USB disconnect, device number 3 [ 4760.637748] xc2028 14-0061: Device is Xceive 0 version 2.0, firmware version 3.6 [ 4760.637756] xc2028 14-0061: Read invalid device hardware information - tuner hung? [ 4760.650641] tm6000: IR URB failure: status: -71, length 0 Have you seen this issue? I would love to fix this and commit it to linux tv but, im still uncertain as to what changes need to be made. The drivers that do come with the 3.2 kernel work fine but however the firmware loading is taking forever (stable though when it is running). Any information you may have to help me out here would be much appreciated. I am not working this weekend and was looking forward to take a peak at the driver. I'll let you know where I stand with this next week. thank you so much for your hard work, -Vladimir -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Unable to open frontend of divb0700 / w_scan fails / Channel scan works on Windows
Hello, I am trying to understand what is going wrong on a Pinnacle 73e running on Linux Mint 12. The system seems to recognize the device properly: dmesg [ 25.571464] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [ 25.795650] DiB0070: successfully identified [ 25.820158] Registered IR keymap rc-dib0700-rc5 [ 25.820357] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/rc/rc0/input8 [ 25.820494] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/rc/rc0 [ 25.820716] dvb-usb: schedule remote query interval to 50 msecs. [ 25.820719] dvb-usb: Pinnacle PCTV 73e successfully initialized and connected. [ 25.820807] dib0700: rc submit urb failed [ 25.820810] [ 25.820853] usbcore: registered new interface driver dvb_usb_dib0700 Sometimes dmesg shows a message about installing the firmware /lib/firmware/dvb-usb-dib0700-1.20.fw but this time it didn't issue that message. uname -r gives 3.0.0-12-generic If I try to scan the channels using VLC, w_scan or scan, it fails to find anything. I have tried forcing the LNA: ~ $ cat /etc/modprobe.d/options.conf options dvb-usb-dib0700 force_lna_activation=1 but that didn't make a difference. The output from dvbscan is: ~ $ dvbscan /usr/share/dvb/dvb-t/es-Valencia Unable to query frontend status The output from w_scan is: w_scan /usr/share/dvb/dvb-t/es-Valencia w_scan version 20110616 (compiled for DVB API 5.3) guessing country 'ES', use -c country to override using settings for SPAIN DVB aerial DVB-T Europe frontend_type DVB-T, channellist 4 output format vdr-1.6 output charset 'UTF-8', use -C charset to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - DVB-T DiBcom 7000PC: good :-) Using DVB-T frontend (adapter /dev/dvb/adapter0/frontend0) -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.3 frontend 'DiBcom 7000PC' supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO FREQ (45.00MHz ... 860.00MHz) -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Scanning 7MHz frequencies... 177500: (time: 00:00) 184500: (time: 00:03) 191500: (time: 00:06) 198500: (time: 00:09) 205500: (time: 00:12) 212500: (time: 00:15) 219500: (time: 00:18) 226500: (time: 00:21) Scanning 8MHz frequencies... 474000: (time: 00:24) 482000: (time: 00:27) 49: (time: 00:32) 498000: (time: 00:35) 506000: (time: 00:38) 514000: (time: 00:41) 522000: (time: 00:44) 53: (time: 00:47) 538000: (time: 00:52) 546000: (time: 00:55) 554000: (time: 00:58) 562000: (time: 01:01) 57: (time: 01:04) (time: 01:05) signal ok: QAM_AUTO f = 57 kHz I999B8C999D999T999G999Y999 Info: NIT(actual) filter timeout 578000: (time: 01:20) 586000: (time: 01:23) 594000: (time: 01:26) 602000: (time: 01:29) 61: (time: 01:32) 618000: (time: 01:35) 626000: (time: 01:39) (time: 01:40) signal ok: QAM_AUTO f = 626000 kHz I999B8C999D999T999G999Y999 Info: NIT(actual) filter timeout 634000: (time: 01:54) 642000: (time: 01:57) 65: (time: 02:01) (time: 02:02) signal ok: QAM_AUTO f = 65 kHz I999B8C999D999T999G999Y999 Info: NIT(actual) filter timeout 658000: (time: 02:16) 666000: (time: 02:20) 674000: (time: 02:23) (time: 02:24) signal ok: QAM_AUTO f = 674000 kHz I999B8C999D999T999G999Y999 Info: NIT(actual) filter timeout 682000: (time: 02:39) 69: (time: 02:42) 698000: (time: 02:45) 706000: (time: 02:48) 714000: (time: 02:51) 722000: (time: 02:54) 73: (time: 02:57) 738000: (time: 03:00) 746000: (time: 03:03) 754000: (time: 03:06) 762000: (time: 03:09) (time: 03:10) signal ok: QAM_AUTO f = 762000 kHz I999B8C999D999T999G999Y999 Info: NIT(actual) filter timeout 77: (time: 03:25) (time: 03:26) signal ok: QAM_AUTO f = 77 kHz I999B8C999D999T999G999Y999 Info: NIT(actual) filter timeout 778000: (time: 03:41) 786000: (time: 03:44) 794000: (time: 03:47) 802000: (time: 03:50) 81: (time: 03:53) 818000: (time: 03:56) 826000: (time: 04:00) 834000: (time: 04:03) (time: 04:04) signal ok: QAM_AUTO f = 834000 kHz I999B8C999D999T999G999Y999 Info: NIT(actual) filter timeout 842000: (time: 04:18) (time: 04:19) signal ok: QAM_AUTO f = 842000 kHz I999B8C999D999T999G999Y999 Info: NIT(actual) filter timeout 85: (time: 04:34) (time: 04:35) signal ok: QAM_AUTO f = 85 kHz I999B8C999D999T999G999Y999 Info: NIT(actual) filter timeout 858000: (time: 04:50) (time: 04:51) signal ok: QAM_AUTO f = 858000 kHz I999B8C999D999T999G999Y999 Info: NIT(actual) filter timeout tune to: QAM_AUTO f = 57 kHz I999B8C999D999T999G999Y999 (time: 05:06) Info: PAT filter timeout Info: SDT(actual) filter timeout Info: NIT(actual) filter timeout tune to: QAM_AUTO f = 626000 kHz I999B8C999D999T999G999Y999 (time: 05:21) Info: PAT filter timeout Info: SDT(actual) filter timeout Info: NIT(actual) filter timeout tune to: QAM_AUTO f = 65 kHz I999B8C999D999T999G999Y999 (time: 05:36) Info: PAT filter
RE: Using UVC webcam gadget with a real v4l2 device
Hi Laurent, Sorry to jump-in before your reply on my previous mail, but as I was studying the USERPTR stuff in more detail, I have a few more queries which I believe you can include in your reply as well.. -Original Message- From: Bhupesh SHARMA Sent: Wednesday, April 25, 2012 8:37 PM To: 'Laurent Pinchart' Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; ba...@ti.com; g.liakhovet...@gmx.de Subject: RE: Using UVC webcam gadget with a real v4l2 device Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Tuesday, April 24, 2012 2:26 AM To: Bhupesh SHARMA Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; ba...@ti.com; g.liakhovet...@gmx.de Subject: Re: Using UVC webcam gadget with a real v4l2 device Hi Bhupesh, On Tuesday 24 April 2012 02:46:22 Bhupesh SHARMA wrote: On Monday, April 23, 2012 7:47 PM Laurent Pinchart wrote: On Monday 23 April 2012 02:24:53 Bhupesh SHARMA wrote: Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. The UVC webcam gadget works fine with the user space application handling the CONTROL events and providing DATA events. Now, I wish to interface a real v4l2 device, for e.g. VIVI or more particularly a soc_camera based host and subdev pair. Now, I see that I can achieve this by opening the UVC and V4L2 devices and doing MMAP - REQBUF - QBUF - DQBUF calls on both the devices per the UVC control event received. But this will involve copying the video buffer in the user-space application from v4l2 (_CAPTURE) to uvc (_OUTPUT) domains, which will significantly reduce the video capture performance. Is there a better solution to this issue? Maybe doing something like a RNDIS gadget does with the help of u_ether.c like helper routines. But if I remember well it also requires the BRCTL (Bridge Control Utility) in userspace to route data arriving on usb0 to eth0 and vice- versa. Not sure though, if it does copying of a skb buffer from ethernet to usb domain and vice-versa. To avoid copying data between the two devices you should use USERPTR instead of MMAP on at least one of the two V4L2 devices. The UVC gadget driver doesn't support USERPTR yet though. This shouldn't be too difficult to fix, we need toreplace the custom buffers queue implementation with videobuf2, as has been done in the uvcvideo driver. I was thinking of using the USERPTR method too, but I realized that currently neither UVC webcam gadget nor soc-camera subsystem supports this IO method. They support only MMAP IO as of now :( Both soc-camera and the UVC gadget driver should be ported to videobuf2 to fix the problem. I am now a bit confused on how the entire system will work now: - Does USERPTR method needs to be supported both in UVC gadget and soc-camera side, or one can still support the MMAP method and the other can now be changed to support USERPTR method and we can achieve a ZERO buffer copy operation using this method? - More specifically, I would like to keep the soc-camera still using MMAP (and hence still using video-buf) and make changes at the UVC gadget side to support USERPTR and videobuf2. Will this work? - At the application side how should we design the flow in case both support USERPTR, i.e. the buffer needs to be protected from simultaneous access from the UVC gadget driver and soc-camera driver (to ensure that a single buffer can be shared across them). Also in case we keep soc-camera still using MMAP and UVC gadget side supporting USERPTR, how can we share a common buffer across the UVC gadget and soc-camera driver. - In case of USERPTR method the camera capture hardware should be able to DMA the received data to the user space buffers. Are there any specific requirements on the DMA capability of these use-space buffers (scatter-gather or contiguous?). Regards, Bhupesh I'll try to implement this. Would you then be able to test patches ? For sure, I can test your patches on my setup. I had a quick look, but there's a bit more work than expected. The UVC gadget driver locking scheme needs to be revisited. I unfortunately won't have time to work on that in the next couple of weeks, and very probably not before end of June. Sorry. If you want to give it a try, I can provide you with some pointers. It's a pity. You are the best person to do it as you have in-depth know -how of both v4l2 and UVC webcam gadget. But I can give it a try if you can provide me some pointers.. BTW, I was exploring GSTREAMER to use the data
