Re: [linux-dvb] Kworld DVB-T 323UR problems
On Sun, Jun 21, 2009 at 11:44 PM, Laszlo Kustan wrote: > Hi everyone, > I have a Kword DVB-T 323UR connected to a Linux Mint 7 Gloria (based > on Ubuntu Jaunty), kernel 2.6.28. > I successfully compiled em28xx, the firmware was obtained based on these > steps: > 1) Download the windows driver with something like: > wget > http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip > 2) Extract the file hcw85bda.sys from the zip into the current dir: > unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip Driver85/hcw85bda.sys > 3) run the script: > ./extract_xc3028.pl > 4) copy the generated file: > cp xc3028-v27.fw /lib/firmware > > My windows driver is called embda.sys, so I'm not sure whether the > firmware is 100% good for my tuner or not. > I have a couple of problems: > 1. no analog audio, but I found out this works with workarounds > > I tried several tricks: > a. sox -c 2 -r 32000 -t ossdsp /dev/dsp1 -t ossdsp /dev/dsp > this works, but with a 4-5 second delay between audio and video > > b. arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | play -q -c 2 -r 32000 -t wav - > & > I get an error: > l...@laco-desktop ~ $ arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | play > -q -c 2 -r 32000 -t wav - & > [1] 9084 > l...@laco-desktop ~ $ Recording WAVE 'stdin' : Signed 16 bit Little > Endian, Rate 32000 Hz, Stereo > Warning: rate is not accurate (requested = 32000Hz, got = 48000Hz) > please, try the plug plugin > arecord: pcm_read:1529: read error: Input/output error > play wav: Premature EOF on .wav input file > > c. install modified tvtime from mcentral.de > I get an error in this case too: > Reading configuration from /usr/etc/tvtime/tvtime.xml > Reading configuration from /home/laco/.tvtime/tvtime.xml > HDA NVidia : AD198x Analog hw:0,0 > Em28xx Audio : Empia 28xx Capture hw:1,0 > opening: hw:1,0 > Access type not available > > My arecord -l output is: > l...@laco-desktop ~ $ arecord -l > List of CAPTURE Hardware Devices > card 0: NVidia [HDA NVidia], device 0: AD198x Analog [AD198x Analog] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 1: Em28xx Audio [Em28xx Audio], device 0: Em28xx Audio [Empia 28xx > Capture] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > > 2. my remote is not recognized. Here is the em28xx part from dmesg: > l...@laco-desktop ~ $ dmesg | grep em28xx > [11231.562817] em28xx v4l2 driver version 0.0.1 loaded > [11231.564913] em28xx: new video device (eb1a:e323): interface 0, class 255 > [11231.564920] em28xx: setting up device on a USB 1.1 bus > [11231.564924] em28xx: your device won't work properly when > [11231.564927] em28xx: not attached to a USB 2.0 highspeed bus > [11231.564931] em28xx: more information: > [11231.564933] em28xx: http://mcentral.de/wiki/index.php5/Talk:Em2880 please pay attention to that line... it probably will not work with usb 1.0. Markus > [11231.564942] em28xx #0: Alternate settings: 8 > [11231.564946] em28xx #0: Alternate setting 0, max size= 0 > [11231.564950] em28xx #0: Alternate setting 1, max size= 512 > [11231.564954] em28xx #0: Alternate setting 2, max size= 640 > [11231.564958] em28xx #0: Alternate setting 3, max size= 768 > [11231.564962] em28xx #0: Alternate setting 4, max size= 832 > [11231.564966] em28xx #0: Alternate setting 5, max size= 896 > [11231.564969] em28xx #0: Alternate setting 6, max size= 960 > [11231.564973] em28xx #0: Alternate setting 7, max size= 1020 > [11240.939178] em28xx #0: V4L2 VBI device registered as /dev/vbi0 > [11240.998075] em28xx #0: V4L2 device registered as /dev/video0 > [11240.998087] em28xx #0: Found KWorld E323 > [11240.998153] usbcore: registered new interface driver em28xx > [11241.064491] em28xx-audio.c: probing for em28x1 non standard usbaudio > [11241.064497] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger > [11241.922736] em28xx-audio: device is currently in analog TV mode > > Nothing about input devices here and neither in /proc/bus/input/devices. > > 3. heat problems > I noticed that when it is connected, it gets quite hot, even if no dvb > software is running. In Windows it does not get so hot, even when > watching tv. > > Sorry for this long mail. > The first point would be the most important to solve, if you need more > details to help me, no problem. > Thanks, Laszlo > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > -- 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: [linux-dvb] @Sky Pilot, Neotion Pilot, Checksum hacking
Juergen Urban wrote:
> Now I've a problem with the 1-byte-checksum calculation. Each message
> which I send to the device has a checksum (last byte). I don't know how to
> calculate the checksum.
> Did someone know how to reverse engineer a 1-byte-checksum?
> Did someone see these type of messages before?
> Did someone detect any algorithm in the checksum values?
>
> Here are examples:
>
> static unsigned char ep03_msg109[] = {
> 0x81, 0x05, 0x01, 0x00, 0x02, 0x01, 0x06, 0x00,
> 0x01, 0xd0, 0x1e, 0x01, 0x00,
> 0xca /* Checksum */
> };
>
> static unsigned char ep03_msg110[] = {
> 0x81, 0x05, 0x01, 0x00, 0x02, 0x01, 0x06, 0x00,
> 0x01, 0xd0, 0x1f, 0x01, 0x00,
> 0xcb /* Checksum */
> };
>
> In the above example the checksum is incremented by one and there is also one
> byte incremented by one in the payload (0x1e -> 0x1f and 0xca -> 0xcb). this
> seems to be a simple addition.
>
> static unsigned char ep03_msg111[] = {
> 0x81, 0x05, 0x01, 0x00, 0x02, 0x01, 0x06, 0x00,
> 0x01, 0xd0, 0x20, 0x01, 0x00,
> 0xf4 /* Checksum */
> };
It's a simple XOR of all bytes with an initial value of 0x84.
unsigned int calc_cs(const unsigned char *buf, unsigned int n)
{
unsigned int i, cs = 0x84;
for (i = 0; i < n; i++)
cs ^= buf[i];
return cs;
}
Regards,
Andreas
--
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: Sakar 57379 USB Digital Video Camera...
Andy, You are right. Your camera is emitting JPEG while streaming. I just succeeded in creating an image which resembles your test picture by extracting the frame data for one frame, tacking on a header, and running hex2bin on the combined file. I did not get the thing quite right, because your header is from your JPEG photo (640x480) and your stream is probably 320x240. But I got something out which is obviously recognizable. Therefore with a little bit of further tweaking it will presumably come out exactly so. Namely, I have to remember where to stick the two dimensions into the header. As my students in courses like calculus say, "Sir, it has been a long time since I studied that." Whereupon I reply, "With my white hair, I wonder how far I could get with that excuse?" I will send you a copy of the results for your amusement. It is obviously the first attempt, so do not laugh at the fact that you get two copies of 3 x6 -- side by side, please. Theodore Kilgore -- 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: PULL request - http://linuxtv.org/hg/~hgoede/gspca
Em Sun, 21 Jun 2009 23:57:48 +0200 Hans de Goede escreveu: > Hi, > > On 06/21/2009 02:10 PM, Mauro Carvalho Chehab wrote: > > Em Sun, 21 Jun 2009 08:45:03 +0200 > > Hans de Goede escreveu: > > > >> > >> On 06/21/2009 02:39 AM, Mauro Carvalho Chehab wrote: > >>> Em Sat, 20 Jun 2009 15:26:25 +0200 > >>> Hans de Goede escreveu: > >>> > On 06/20/2009 12:51 PM, Mauro Carvalho Chehab wrote: > > Em Wed, 17 Jun 2009 23:54:40 +0200 > > Hans de Goedeescreveu: > > > >> Support for the st6422 bridge + sensor ! > >> Give it a try, I know now you have a cam which uses this bridge :) > >> When you try it be sure to use the latest (just updated my > >> libv4l tree) libv4l, this enables (software) automatic control of > >> the gain and exposure, for a decent image in most lighting > >> conditions. > > Didn't work :( See the logs bellow. > > > > > > $ dmesg > > STV06xx: Probing for a stv06xx device > > gspca: probing 046d:08f6 > > usbcore: registered new interface driver STV06xx > > STV06xx: registered > > gspca: usb_submit_urb [0] err -28 > > gspca: no transfer endpoint found > > > err -28 is ENOSPC which is given by usb_submit_urb, when the > required bandwidth for the isoc transfer is not available. > > With most cams we then automatically fall back to an altsetting > which requires less bandwidth, but the st6422 has only one > hence the: "gspca: no transfer endpoint found" error. > > There are 3 possible causes for this: > 1) You are using the device through an usb 2.0 hub, this should work > but does not work due to a bug in the usb subsystem of the kernel, > which I have reported but most likely won't be fixed > >>> OK. On a direct port: > >>> > >> OK, better :) > >> > >> mplayer does not recognize /dev/video0 as a "v4l" url, so it will just > >> try to use plain open and then read, which is causing the errors, as > >> read() on a v4l device wants a buffer large enough to hold 1 frame in one > >> read. > >> > > > > Yes, I know, but the v4l1 and v4l2 calls also fails: > > > > > > $ export LD_PRELOAD=/usr/local/lib/libv4l/v4l1compat.so > > $ mplayer -tv driver=v4l2 tv:// > > ... > > Cannot find codec matching selected -vo and video format 0x32315659. > > Read DOCS/HTML/en/codecs.html! > > > > $ mplayer -tv driver=v4l tv:// > > > > The 'outfmt' of 'Planar YV12' is likely not supported by your card > > > > > Hmm, > > This works fine for me, perhaps you are using an older libv4l, mplayer did > not work with some libv4l versions back as it wants YV12 and some versions > back libv4l only did YU12. > > When trying a new libv4l, make sure you don't have an older version elsewhere, > I notice that your LD_PRELOAD points to /usr/local, notice that that will only > specify where the compat wrapper gets loaded from (which hasn't changed in > ages) > the compat_wrapper itself is dynamically linked, so if you have an older > libv4l > in /usr/lib, chances are that one actually gets used. I got the issue: it were completely unrelated with the driver or with the libv4l: I had this line on my ~/.mplayer/config: # Enable video de-interlacing and crop to the proper window vf = crop=628:470:6:10,pp=lb This is nice for TV, but for sure doesn't apply for webcams ;) I replaced it to: vf = screenshot,cropdetect This makes no difference for webcam, and will hopefully auto-crop with some TV boards. It also enables the useful screenshot 's' key. > > I tested also luvcview 0.2.5 without success: > > > > ERROR: Requested frame format MJPG is not available and no fallback format > > was found. > > > > luvcview is a somewhat limited app, which only works with uvc cams, even > libv4l cannot > help it, as it requests uvc specific formats to which libv4l cannot convert. What application works better with libv4l? Btw, it would be nice to have some apps linked with libv4l at epel repository ;) Cheers, Mauro -- 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: Sakar 57379 USB Digital Video Camera...
On Sun, 2009-06-21 at 10:42 -0500, Theodore Kilgore wrote:
>
> On Sun, 21 Jun 2009, Andy Walls wrote:
> > The more I dig into this, the more I think (hope or wish?) the stuff in
> > the usb snoop logs looks MJPEG.
> >
> > I started looking at an AVI file that I recorded with the camera. It
> > looks like a DV AVI Type-2 file.
> >
> > In the AVI file header, my camera reports:
> >
> > 0d0: 7374 7264 ac00 4a65 696c strdJeil
> > 0e0: 696e 2020 5465 6368 6e6f 6c6f 6779 2043 in Technology C
> > 0f0: 6f2e 2c20 4c74 642e 4a4c 3230 3038 5632 o., Ltd.JL2008V2
> > 100: 4330 3037 3030 3130 2020 2020 2020 2020 C0070010
> >
> > So looking up the JL2008A datasheet, my camera's capabilities match the
> > data sheet very well.
> >
> > http://jeilin.com.tw/eng/product_detail.php?p_id=5
> > http://jeilin.com.tw/mana_php/Download/File/JL2008A%20v1.3.pdf
> >
> > The only video compression that is mentioned on the webpage and in the
> > datasheet is JPEG.
> >
> > Trying to learn about DV AVI Type 2 files I've found roughly how
> > individual chunk headers look. They each have a stream fourcc that
> > starts 'nnxx' in ASCII, where nn is the stream number and xx is
> >
> > db - uncompressed video frame
> > dc - compressed video frame
> > wb - audio data
> >
> > $ xxd 4.avi | grep -E ' 303[0-2] ((646)|(776))'
> >
> > 1f0: 14fe 0c00 6d6f 7669 3031 7762 401f movi0...@... <--
> > audio
> > 0002140: 3032 6462 0041 ffe2 55aa 0500 02db.AU. <--
> > video
> > 0006250: 3032 6462 0041 ffe2 55aa 0500 0001 02db.AU. <--
> > video
> > 000a360: 3032 6462 0041 ffe2 55aa 0500 0002 02db.AU. <--
> > video
> > 000e470: 3032 6462 0041 ffe2 55aa 0500 0003 02db.AU. <--
> > video
> > 0012580: 3032 6462 0041 ffe2 55aa 0500 0004 02db.AU. <--
> > video
> > 0016690: 3030 6463 281c ffd8 ffe0 0016 4156 00dc(.AV <--
> > compressed video
> > 00182c0: 3030 6463 e81b ffd8 ffe0 0016 4156 00dc..AV <--
> > compressed video
> > 0019eb0: 3030 6463 c81b ffd8 ffe0 0016 4156 00dc..AV <--
> > compressed video
> >
> >> From the AVI header and from the compressed video chunk headers, the
> > compressed video stream is MJPEG.
> >
> > I don't know what the uncompressed video (02db) chunks are. The AVI
> > header doesn't mention a third stream (stream 02). The length of each
> > chunk of this third stream is 0x4100 = 0x20 * 0x200 and each one has an
> > incrementing sequence number in the header.
> >
> > Doing some math:
> >
> > 320 * 240 = 76800 = 0x12c00
> >
> > 0x12c00 / 0x4100 = 0x4.9d = 4.61
> >
> > so 5 chunks of 0x4100 bytes would be needed for one uncompressed 320x240
> > frame at 8 bits/pixel. Those uncompressed video chunks always come in
> > groups of 5 in the AVI file.
> >
> >
> > The idx section at the end of the AVI file only indexes the compressed
> > video (00dc) and audio (01wb) chunks:
> >
> > 00d: 6964 7831 4005 i...@...
> > 00d0010: 3031 7762 0400 401f 01wb@...
> > 00d0020: 3030 6463 1000 9c64 0100 281c 00dc.d..(...
> > 00d0030: 3030 6463 1000 cc80 0100 e81b 00dc
> > 00d0040: 3030 6463 1000 bc9c 0100 c81b 00dc
> > 00d0050: 3030 6463 1000 8cb8 0100 f81b 00dc
> > 00d0060: 3030 6463 1000 8cd4 0100 581c 00dcX...
> >
> >
> > My tired eyes are telling me the AVI file's MJPEG compressed video
> > stream (00dc) looks like what comes out of the camera in webcam mode
> > than the AVI file's uncompressed video stream.
> >
> > The first 0x110 bytes of the MJPEG stream (00dc) chunks in the AVI file
> > remain invariant, except for 3, 32 bit values related to length: The AVI
> > stream 00dc chunk length and the MJPEG AVI1 App's field size and padded
> > field size (I think).
> >
> > 0099560: 30 30 64 63 78 0e 00 00 ff d8 ff e0 00 16 41 56 00dcx.AV
> > ^^^--- Chunk/padded length
> > 0099570: 49 31 00 00 78 0e 00 00 71 0e 00 00 00 00 00 00 I1..x...q...
> > ^^^ ^^^ --- actual length
> > 0099580: 00 00 ff dd 00 04 00 00 ff db 00 c5 00 14 0e 0f
> > 0099590: 12 0f 0d 14 12 10 12 17 15 14 18 1e 32 21 1e 1c 2!..
> > 00995a0: 1c 1e 3d 2c 2e 24 32 49 40 4c 4b 47 40 46 45 50 ..=,@lkg@FEP
> > 00995b0: 5a 73 62 50 55 6d 56 45 46 64 88 65 6d 77 7b 81 ZsbPUmVEFd.emw{.
> > 00995c0: 82 81 4e 60 8d 97 8c 7d 96 73 7e 81 7c 01 15 17 ..N`...}.s~.|...
> > 00995d0: 17 1e 1a 1e 3b 21 21 3b 7c 53 46 53 7c 7c 7c 7c ;!!;|SFS
> > 00995e0: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c
> > 00995f0: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c
> > 0099600: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 02 15 ||..
> > 0099610: 17 17 1e 1a 1e 3b 21 21 3b 7c 53 46 5
Re: dvb-t with kernel 2.6.15?
Em Sun, 21 Jun 2009 19:36:42 +0200 Dennis Campbell escreveu: > Hello, > I have seen that the v4l-dvb modules work only for kernel > 2.6.15. I > have a Pinnacle 72e USB DVB-T stick i would like to use with a 2.6.15 > (ARM)kernel. This would be a dibcom 0700 driver. Is there any > possibilty at all to get this working, or do I have to get a dvb-t usb > stick that is supported by the 2.6.15 kernel? How good was the dvb-t > support using the 2.6.15 kernel? Thanks for any help. You may try to compile it with 2.6.15, by changing versions.txt file, or by explicitly enabling support for older kernels via "make menuconfig". It is a good idea to take a look at the changeset that stripped compat with kernels older than 2.6.16: changeset: 8240:fc86dc29e6a3 parent: 8235:9ff62c80bf4c user:Hans Verkuil date:Tue Jul 08 17:40:58 2008 +0200 summary: v4l-dvb: remove support for kernels < 2.6.16 Cheers, Mauro -- 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] soc-camera: fix missing clean up on error path
Dear Guennadi Thank you for your hard work > > soc_camera_video_stop is called from icd->ops->remove > > I think it have dead lock by icd->video_lock. > > > > my kernel is from Paul's git and it's Makefile said 2.6.30-rc6 > > Yes, you're right. Please, try this version, but this is a bigger change, > also affecting the regular (not error) path, so, I will have to test it > too. Thanks. but I'm very busy now. Please wait for me. Best regards -- Kuninori Morimoto -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Sun, 21 Jun 2009 20:38:53 +0200 Hans Verkuil escreveu: > On Sunday 21 June 2009 20:31:57 Mauro Carvalho Chehab wrote: > > Em Sun, 21 Jun 2009 20:20:29 +0200 > > > > Hans Verkuil escreveu: > > > On Sunday 21 June 2009 19:33:11 Mauro Carvalho Chehab wrote: > > > > Em Fri, 19 Jun 2009 14:39:14 +0200 > > > > > > > > Hans Verkuil escreveu: > > > > > Hi Mauro, > > > > > > > > > > Please pull from > > > > > http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the > > > > > following: > > > > > > > > > > - tvp514x: Migration to sub-device framework > > > > > > > > Hmm... the kernel-doc format is wrong on all function description > > > > comment changes on tvp514x: > > > > > > I'm assuming this can be corrected in a separate patch later? I don't > > > think this is a blocking issue. > > > > Yes, sure this is not blocking. > > > > BTW, please, _never_ send me an email to a public list C/C a > > subscribers-only list: > > > > Your mail to 'Davinci-linux-open-source' with the subject > > > > Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap > > > > Is being held until the list moderator can review it for approval. > > I knew about this, but since this is the official submission of the davinci > vpfe capture driver I could hardly exclude that list from this pull > request! Perhaps next time I should use a BCC instead, that might be a > reasonable compromise. The better would be to allow public posting on it, like what we did with linux-media. While they not open BCC could be a workaround. Yet, what would be the sense of copying just the pull requests without the revision comments? If reviews are not welcome there, why pull requests would be? Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hi, Am Sonntag, den 21.06.2009, 15:31 -0300 schrieb Mauro Carvalho Chehab: > Em Sun, 21 Jun 2009 20:20:29 +0200 > Hans Verkuil escreveu: > > > On Sunday 21 June 2009 19:33:11 Mauro Carvalho Chehab wrote: > > > Em Fri, 19 Jun 2009 14:39:14 +0200 > > > > > > Hans Verkuil escreveu: > > > > Hi Mauro, > > > > > > > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap > > > > for the following: > > > > > > > > - tvp514x: Migration to sub-device framework > > > > > > Hmm... the kernel-doc format is wrong on all function description comment > > > changes on tvp514x: > > > > I'm assuming this can be corrected in a separate patch later? I don't think > > this is a blocking issue. > > Yes, sure this is not blocking. > > BTW, please, _never_ send me an email to a public list C/C a subscribers-only > list: > > Your mail to 'Davinci-linux-open-source' with the subject > > Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap > > Is being held until the list moderator can review it for approval. > > > Muralidharan, can you take a look at this? > > [snip] this raises some other question. We need to have the links to the video4linux-list and to the dvb ML archives for many years in the future and ivtv was also an important list in the past and is still now and of course many others including those of our app developers too. I can see that people still pick up stuff I once got stuck on. In most cases users/contributors had their stuff finally run, but did not sign any patches for a bunch of devices. But there are also more important cases, like that one Igor tries to take care for now on that Compro stuff with that time new demodulator and tuner. (end of 2007) >From my side, I was probably annoyed enough from that "don't touch anything on dvb stuff", but else nobody did care either. Since, IMHO, we must provide free floating between the prior list archives, we likely need to more carefully think about what to allow and what not for cross posting. The linux-dvb ML is also only for subscribers and for sure we don't want to lose it, if it is about the archives. The same goes for video4linux and ivtv. For video4linux we know now that nobody ever cares for moderation, for ivtv I think it is taken into account that such traffic appears, for davinci I would not care until there is stated something different from the moderator, if any ;) Cheers, Hermann -- 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
Hauppauge HVR-1250 IR Support? (CX23885)
I was wondering if anyone is working on IR support for this card? I looked
through cx23885-cards.c and its not supported.
627 switch (dev->board) {
628 case CX23885_BOARD_HAUPPAUGE_HVR1250:
629 case CX23885_BOARD_HAUPPAUGE_HVR1500:
630 case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
631 case CX23885_BOARD_HAUPPAUGE_HVR1800:
632 case CX23885_BOARD_HAUPPAUGE_HVR1200:
633 case CX23885_BOARD_HAUPPAUGE_HVR1400:
634 /* FIXME: Implement me */
635 break;
Thanks!
--
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: [linux-dvb] Kworld DVB-T 323UR problems
On Sun, Jun 21, 2009 at 5:44 PM, Laszlo Kustan wrote: > Hi everyone, > I have a Kword DVB-T 323UR connected to a Linux Mint 7 Gloria (based > on Ubuntu Jaunty), kernel 2.6.28. > I successfully compiled em28xx, the firmware was obtained based on these > steps: > 1) Download the windows driver with something like: > wget > http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip > 2) Extract the file hcw85bda.sys from the zip into the current dir: > unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip Driver85/hcw85bda.sys > 3) run the script: > ./extract_xc3028.pl > 4) copy the generated file: > cp xc3028-v27.fw /lib/firmware > > My windows driver is called embda.sys, so I'm not sure whether the > firmware is 100% good for my tuner or not. > I have a couple of problems: > 1. no analog audio, but I found out this works with workarounds > > I tried several tricks: > a. sox -c 2 -r 32000 -t ossdsp /dev/dsp1 -t ossdsp /dev/dsp > this works, but with a 4-5 second delay between audio and video > > b. arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | play -q -c 2 -r 32000 -t wav - > & > I get an error: > l...@laco-desktop ~ $ arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | play > -q -c 2 -r 32000 -t wav - & > [1] 9084 > l...@laco-desktop ~ $ Recording WAVE 'stdin' : Signed 16 bit Little > Endian, Rate 32000 Hz, Stereo > Warning: rate is not accurate (requested = 32000Hz, got = 48000Hz) > please, try the plug plugin > arecord: pcm_read:1529: read error: Input/output error > play wav: Premature EOF on .wav input file > > c. install modified tvtime from mcentral.de > I get an error in this case too: > Reading configuration from /usr/etc/tvtime/tvtime.xml > Reading configuration from /home/laco/.tvtime/tvtime.xml > HDA NVidia : AD198x Analog hw:0,0 > Em28xx Audio : Empia 28xx Capture hw:1,0 > opening: hw:1,0 > Access type not available > > My arecord -l output is: > l...@laco-desktop ~ $ arecord -l > List of CAPTURE Hardware Devices > card 0: NVidia [HDA NVidia], device 0: AD198x Analog [AD198x Analog] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 1: Em28xx Audio [Em28xx Audio], device 0: Em28xx Audio [Empia 28xx > Capture] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > > 2. my remote is not recognized. Here is the em28xx part from dmesg: > l...@laco-desktop ~ $ dmesg | grep em28xx > [11231.562817] em28xx v4l2 driver version 0.0.1 loaded > [11231.564913] em28xx: new video device (eb1a:e323): interface 0, class 255 > [11231.564920] em28xx: setting up device on a USB 1.1 bus > [11231.564924] em28xx: your device won't work properly when > [11231.564927] em28xx: not attached to a USB 2.0 highspeed bus > [11231.564931] em28xx: more information: > [11231.564933] em28xx: http://mcentral.de/wiki/index.php5/Talk:Em2880 > [11231.564942] em28xx #0: Alternate settings: 8 > [11231.564946] em28xx #0: Alternate setting 0, max size= 0 > [11231.564950] em28xx #0: Alternate setting 1, max size= 512 > [11231.564954] em28xx #0: Alternate setting 2, max size= 640 > [11231.564958] em28xx #0: Alternate setting 3, max size= 768 > [11231.564962] em28xx #0: Alternate setting 4, max size= 832 > [11231.564966] em28xx #0: Alternate setting 5, max size= 896 > [11231.564969] em28xx #0: Alternate setting 6, max size= 960 > [11231.564973] em28xx #0: Alternate setting 7, max size= 1020 > [11240.939178] em28xx #0: V4L2 VBI device registered as /dev/vbi0 > [11240.998075] em28xx #0: V4L2 device registered as /dev/video0 > [11240.998087] em28xx #0: Found KWorld E323 > [11240.998153] usbcore: registered new interface driver em28xx > [11241.064491] em28xx-audio.c: probing for em28x1 non standard usbaudio > [11241.064497] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger > [11241.922736] em28xx-audio: device is currently in analog TV mode > > Nothing about input devices here and neither in /proc/bus/input/devices. > > 3. heat problems > I noticed that when it is connected, it gets quite hot, even if no dvb > software is running. In Windows it does not get so hot, even when > watching tv. > > Sorry for this long mail. > The first point would be the most important to solve, if you need more > details to help me, no problem. > Thanks, Laszlo Hello Laszlo, Please send correspondence to the linux-media mailing list, as the linux-dvb list is deprecated. Your firmware is fine. The extract_xc3027.pl script will *only* work if the md5 checksum matches, so if it matched then you ended up with the correct firmware. Regarding #1, the audio is working correctly. The problem is that for raw capture devices there is no way currently for the v4l2 to inform applications where to find the ALSA device that provides the audio. Your card is behaving consistently with *every* other product currently supported that provides a raw video stream (as opposed to products with an MPEG encoder onboard). The reason you see the audio being out of sync with the video is because of buffering of the audio prior to playback. You can usually
Re: PULL request - http://linuxtv.org/hg/~hgoede/gspca
Hi, On 06/21/2009 02:10 PM, Mauro Carvalho Chehab wrote: Em Sun, 21 Jun 2009 08:45:03 +0200 Hans de Goede escreveu: On 06/21/2009 02:39 AM, Mauro Carvalho Chehab wrote: Em Sat, 20 Jun 2009 15:26:25 +0200 Hans de Goede escreveu: On 06/20/2009 12:51 PM, Mauro Carvalho Chehab wrote: Em Wed, 17 Jun 2009 23:54:40 +0200 Hans de Goedeescreveu: Support for the st6422 bridge + sensor ! Give it a try, I know now you have a cam which uses this bridge :) When you try it be sure to use the latest (just updated my libv4l tree) libv4l, this enables (software) automatic control of the gain and exposure, for a decent image in most lighting conditions. Didn't work :( See the logs bellow. $ dmesg STV06xx: Probing for a stv06xx device gspca: probing 046d:08f6 usbcore: registered new interface driver STV06xx STV06xx: registered gspca: usb_submit_urb [0] err -28 gspca: no transfer endpoint found err -28 is ENOSPC which is given by usb_submit_urb, when the required bandwidth for the isoc transfer is not available. With most cams we then automatically fall back to an altsetting which requires less bandwidth, but the st6422 has only one hence the: "gspca: no transfer endpoint found" error. There are 3 possible causes for this: 1) You are using the device through an usb 2.0 hub, this should work but does not work due to a bug in the usb subsystem of the kernel, which I have reported but most likely won't be fixed OK. On a direct port: OK, better :) mplayer does not recognize /dev/video0 as a "v4l" url, so it will just try to use plain open and then read, which is causing the errors, as read() on a v4l device wants a buffer large enough to hold 1 frame in one read. Yes, I know, but the v4l1 and v4l2 calls also fails: $ export LD_PRELOAD=/usr/local/lib/libv4l/v4l1compat.so $ mplayer -tv driver=v4l2 tv:// ... Cannot find codec matching selected -vo and video format 0x32315659. Read DOCS/HTML/en/codecs.html! $ mplayer -tv driver=v4l tv:// The 'outfmt' of 'Planar YV12' is likely not supported by your card Hmm, This works fine for me, perhaps you are using an older libv4l, mplayer did not work with some libv4l versions back as it wants YV12 and some versions back libv4l only did YU12. When trying a new libv4l, make sure you don't have an older version elsewhere, I notice that your LD_PRELOAD points to /usr/local, notice that that will only specify where the compat wrapper gets loaded from (which hasn't changed in ages) the compat_wrapper itself is dynamically linked, so if you have an older libv4l in /usr/lib, chances are that one actually gets used. I tested also luvcview 0.2.5 without success: ERROR: Requested frame format MJPG is not available and no fallback format was found. luvcview is a somewhat limited app, which only works with uvc cams, even libv4l cannot help it, as it requests uvc specific formats to which libv4l cannot convert. Hmm... on a moment of inspiration, I tested it with ekiga, and it properly worked! Great, that supports my using older libv4l theory :) Now, I just want to find a way for it to work with the applications I use ;) See above. I'll try to test later the patches you've sent me for the hub Thanks. 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: Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Sun, Jun 21, 2009 at 3:51 PM, George Adams wrote: > > Thank you so much, everyone who has replied to my question! It's nice to > find a community of people willing to help. Here is the dmesg output that > appears when the Pinnacle device gets plugged in, along with a few "ls" > commands: George, It will definitely be interesting to see if the device works under Windows. It is very interesting that the tvp5150 driver isn't being loaded at all, nor the xc3028 during analog initialization (and as a result the DVB won't work because the analog initialization sets the firmware to be used). We've got the exact same USB device ids and last night I confirmed the board is working fine here with the latest tree, suggesting no regression in the driver code. Did you happen to configure for only a subset of drivers to be compiled? Or did you just do a checkout and "cd v4l-dvb", "make", "make install", reboot? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
Thank you so much, everyone who has replied to my question! It's nice to find a community of people willing to help. Here is the dmesg output that appears when the Pinnacle device gets plugged in, along with a few "ls" commands: * usb 1-1: new high speed USB device using ehci_hcd and address 2 * usb 1-1: configuration #1 chosen from 1 choice * Linux video capture interface: v2.00 * em28xx: New device Pinnacle Systems PCTV 800e @ 480 Mbps (2304:0227, interface 0, class 0) * em28xx #0: Identified as Pinnacle PCTV HD Pro Stick (card=17) * em28xx #0: chip ID is em2882/em2883 * em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 27 02 d0 12 5c 03 8e 16 a4 1c * em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00 00 00 00 00 00 00 * em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 1c 00 00 * em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 * em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 50 00 69 00 * em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 * em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 00 00 16 03 * em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00 38 00 30 00 30 00 * em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 36 00 31 00 30 00 30 00 * em28xx #0: i2c eeprom b0: 31 00 30 00 33 00 39 00 34 00 34 00 32 00 00 00 * em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x2de5abbf * em28xx #0: EEPROM info: * em28xx #0:AC97 audio (5 sample rates) * em28xx #0:500mA max power * em28xx #0:Table at 0x27, strings=0x168e, 0x1ca4, 0x246a * input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1a.7/usb1/1-1/input/input6 * em28xx #0: Config register raw data: 0xd0 * em28xx #0: AC97 vendor ID = 0x * em28xx #0: AC97 features = 0x6a90 * em28xx #0: Empia 202 AC97 audio processor detected * em28xx #0: v4l2 driver version 0.1.2 * em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 * usbcore: registered new interface driver em28xx * em28xx driver loaded * xc2028 0-0061: creating new instance * xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner * em28xx #0/2: xc3028 attached * DVB: registering new adapter (em28xx #0) * DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3303 VSB/QAM Frontend)... * Successfully loaded em28xx-dvb * Em28xx: Initialized (Em28xx dvb Extension) extension > ls -lR /dev/dvb /dev/dvb: total 0 drwxr-xr-x 2 root root 120 2009-06-21 13:06 adapter0 /dev/dvb/adapter0: total 0 crw-rw 1 root video 212, 1 2009-06-21 13:06 demux0 crw-rw 1 root video 212, 2 2009-06-21 13:06 dvr0 crw-rw 1 root video 212, 0 2009-06-21 13:06 frontend0 crw-rw 1 root video 212, 3 2009-06-21 13:06 net0 > ls -l /dev/vid* crw-rw 1 root video 81, 0 2009-06-21 13:06 /dev/video0 A much fuller dmesg (from the system boot) is below, but everything that appears to be em28xx-related is shown above. Terry, you mentioned the program "Zapping". I've just installed in Ubuntu and will give it a try when I get to the console later on. Paul, thank you for your message. I will try your mplayer suggestion once I'm at the console. One thing I failed to mention in the original e-mail is that I HAD this device working once before (back in February). I put the device away for a few months after that. Since then, Ubuntu has updated the kernel, so I updated and reinstalled the v4l drivers. This time, though, something seems to be going wrong, and I don't know what's different. Either 1) I've forgotten a criticial step that I did last time, or 2) something in the v4l drivers has changed resulting in a problem, or 3) the device itself has broken. Assuming #2 is unlikely, I intend to try to rule out #3 by hooking the Pinnacle device up to a Windows box tomorrow. Meanwhile, I'm operating on assumption #1: I'm missing something important. I don't understand why there is no mention of the Xceive tuner in the dmesg output, though... or an attempt to load the firmware for it. Anway, here's a much longer dmesg. Any other information that would help, I'll be happy to add. * Initializing cgroup subsys cpuset * Initializing cgroup subsys cpu * Linux version 2.6.24-24-server (bui...@rothera) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)) #1 SMP Wed Apr 15 16:36:01 UTC 2009 (Ubuntu 2.6.24-24.53-server) * BIOS-provided physical RAM map: * BIOS-e820: - 0009e800 (usable) * BIOS-e820: 0009f800 - 000a (reserved) * BIOS-e820: 000f - 0010 (reserved)
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
On Sunday 21 June 2009 20:31:57 Mauro Carvalho Chehab wrote: > Em Sun, 21 Jun 2009 20:20:29 +0200 > > Hans Verkuil escreveu: > > On Sunday 21 June 2009 19:33:11 Mauro Carvalho Chehab wrote: > > > Em Fri, 19 Jun 2009 14:39:14 +0200 > > > > > > Hans Verkuil escreveu: > > > > Hi Mauro, > > > > > > > > Please pull from > > > > http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the > > > > following: > > > > > > > > - tvp514x: Migration to sub-device framework > > > > > > Hmm... the kernel-doc format is wrong on all function description > > > comment changes on tvp514x: > > > > I'm assuming this can be corrected in a separate patch later? I don't > > think this is a blocking issue. > > Yes, sure this is not blocking. > > BTW, please, _never_ send me an email to a public list C/C a > subscribers-only list: > > Your mail to 'Davinci-linux-open-source' with the subject > > Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap > > Is being held until the list moderator can review it for approval. I knew about this, but since this is the official submission of the davinci vpfe capture driver I could hardly exclude that list from this pull request! Perhaps next time I should use a BCC instead, that might be a reasonable compromise. > > > Muralidharan, can you take a look at this? Yes, please. Regards, Hans > > > > Regards, > > > > Hans > > > > > -/** > > > +/* > > > * struct tvp514x_decoder - TVP5146/47 decoder object > > > - * @v4l2_int_device: Slave handle > > > - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device > > > + * @sd: Subdevice Slave handle > > > * @tvp514x_regs: copy of hw's regs with preset values. > > > * @pdata: Board specific > > > - * @client: I2C client data > > > - * @id: Entry from I2C table > > > * @ver: Chip version > > > - * @state: TVP5146/47 decoder state - detected or not-detected > > > + * @streaming: TVP5146/47 decoder streaming - enabled or disabled. > > > * @pix: Current pixel format > > > * @num_fmts: Number of formats > > > * @fmt_list: Format list > > > * @current_std: Current standard > > > * @num_stds: Number of standards > > > * @std_list: Standards list > > > - * @route: input and output routing at chip level > > > + * @input: Input routing at chip level > > > + * @output: Output routing at chip level > > > */ > > > > > > Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper > > > format. Basically, it should be like this example: > > > > > > /** > > > * foobar() - short function description of foobar > > > * @arg1: Describe the first argument to foobar. > > > * @arg2: Describe the second argument to foobar. > > > * One can provide multiple line descriptions > > > * for arguments. > > > * > > > * A longer description, with more discussion of the function > > > foobar() * that might be useful to those using or modifying it. > > > Begins with * empty comment line, and may include additional embedded > > > empty * comment lines. > > > * > > > * The longer description can have multiple paragraphs. > > > **/ > > > > > > > - v4l: vpfe capture bridge driver for DM355 and DM6446 > > > > - vpfe_capture: add missing newlines and fix an incorrect error > > > > code. - v4l: ccdc hw device header file for vpfe capture > > > > - v4l: dm355 ccdc module for vpfe capture driver > > > > - v4l: dm644x ccdc module for vpfe capture driver > > > > - v4l: ccdc types used across ccdc modules for vpfe capture driver > > > > - v4l: common vpss module for video drivers > > > > - v4l: Makefile and config files for vpfe capture driver > > > > - v4l: davinci drivers should only be compiled for kernels >= > > > > 2.6.31. > > > > > > I'll try to analyze those remaining patches later today. > > > Unfortunately, I'm very busy this weekend finishing some pending > > > work. > > > > > > > Hopefully these changes can be merged into 2.6.31. > > > > > > > > There are two arch/arm patches that need to be applied to the git > > > > tree. These patches should be applied last. > > > > > > > > They are: > > > > > > > > http://patchwork.kernel.org/patch/30968/ > > > > http://patchwork.kernel.org/patch/30974/ > > > > > > > > Note that I had to move patch 9 (vpss) in the original patch series > > > > before patch 6 (the Makefile changes) to make sure everything would > > > > still compile. > > > > > > > > Thanks, > > > > > > > > Hans > > > > > > > > diffstat: > > > > b/linux/drivers/media/video/davinci/Makefile |9 > > > > b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 > > > > b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 > > > > + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | > > > > 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | > > > > 878 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | > > > > 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | > > > > 2136 +
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Sun, 21 Jun 2009 20:20:29 +0200 Hans Verkuil escreveu: > On Sunday 21 June 2009 19:33:11 Mauro Carvalho Chehab wrote: > > Em Fri, 19 Jun 2009 14:39:14 +0200 > > > > Hans Verkuil escreveu: > > > Hi Mauro, > > > > > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap > > > for the following: > > > > > > - tvp514x: Migration to sub-device framework > > > > Hmm... the kernel-doc format is wrong on all function description comment > > changes on tvp514x: > > I'm assuming this can be corrected in a separate patch later? I don't think > this is a blocking issue. Yes, sure this is not blocking. BTW, please, _never_ send me an email to a public list C/C a subscribers-only list: Your mail to 'Davinci-linux-open-source' with the subject Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Is being held until the list moderator can review it for approval. > Muralidharan, can you take a look at this? > > Regards, > > Hans > > > > > -/** > > +/* > > * struct tvp514x_decoder - TVP5146/47 decoder object > > - * @v4l2_int_device: Slave handle > > - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device > > + * @sd: Subdevice Slave handle > > * @tvp514x_regs: copy of hw's regs with preset values. > > * @pdata: Board specific > > - * @client: I2C client data > > - * @id: Entry from I2C table > > * @ver: Chip version > > - * @state: TVP5146/47 decoder state - detected or not-detected > > + * @streaming: TVP5146/47 decoder streaming - enabled or disabled. > > * @pix: Current pixel format > > * @num_fmts: Number of formats > > * @fmt_list: Format list > > * @current_std: Current standard > > * @num_stds: Number of standards > > * @std_list: Standards list > > - * @route: input and output routing at chip level > > + * @input: Input routing at chip level > > + * @output: Output routing at chip level > > */ > > > > Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper > > format. Basically, it should be like this example: > > > > /** > > * foobar() - short function description of foobar > > * @arg1: Describe the first argument to foobar. > > * @arg2: Describe the second argument to foobar. > > * One can provide multiple line descriptions > > * for arguments. > > * > > * A longer description, with more discussion of the function foobar() > > * that might be useful to those using or modifying it. Begins with > > * empty comment line, and may include additional embedded empty > > * comment lines. > > * > > * The longer description can have multiple paragraphs. > > **/ > > > > > - v4l: vpfe capture bridge driver for DM355 and DM6446 > > > - vpfe_capture: add missing newlines and fix an incorrect error code. > > > - v4l: ccdc hw device header file for vpfe capture > > > - v4l: dm355 ccdc module for vpfe capture driver > > > - v4l: dm644x ccdc module for vpfe capture driver > > > - v4l: ccdc types used across ccdc modules for vpfe capture driver > > > - v4l: common vpss module for video drivers > > > - v4l: Makefile and config files for vpfe capture driver > > > - v4l: davinci drivers should only be compiled for kernels >= 2.6.31. > > > > I'll try to analyze those remaining patches later today. Unfortunately, > > I'm very busy this weekend finishing some pending work. > > > > > Hopefully these changes can be merged into 2.6.31. > > > > > > There are two arch/arm patches that need to be applied to the git tree. > > > These patches should be applied last. > > > > > > They are: > > > > > > http://patchwork.kernel.org/patch/30968/ > > > http://patchwork.kernel.org/patch/30974/ > > > > > > Note that I had to move patch 9 (vpss) in the original patch series > > > before patch 6 (the Makefile changes) to make sure everything would > > > still compile. > > > > > > Thanks, > > > > > > Hans > > > > > > diffstat: > > > b/linux/drivers/media/video/davinci/Makefile |9 > > > b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 > > > b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 > > > + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 > > > ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ > > > b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + > > > b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 > > > + > > > b/linux/drivers/media/video/davinci/vpss.c | 301 ++ > > > b/linux/include/media/davinci/ccdc_types.h | 43 > > > b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ > > > b/linux/include/media/davinci/dm644x_ccdc.h| 184 + > > > b/linux/include/media/davinci/vpfe_capture.h | 188 + > > > b/linux/include/media/davinci/vpfe_types.h | 51 > > > b/linux/include/media/davinci/vpss.h | 69 > > > linux/drivers/media/video/Kconfig | 49 > > >
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
On Sunday 21 June 2009 19:33:11 Mauro Carvalho Chehab wrote: > Em Fri, 19 Jun 2009 14:39:14 +0200 > > Hans Verkuil escreveu: > > Hi Mauro, > > > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap > > for the following: > > > > - tvp514x: Migration to sub-device framework > > Hmm... the kernel-doc format is wrong on all function description comment > changes on tvp514x: I'm assuming this can be corrected in a separate patch later? I don't think this is a blocking issue. Muralidharan, can you take a look at this? Regards, Hans > > -/** > +/* > * struct tvp514x_decoder - TVP5146/47 decoder object > - * @v4l2_int_device: Slave handle > - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device > + * @sd: Subdevice Slave handle > * @tvp514x_regs: copy of hw's regs with preset values. > * @pdata: Board specific > - * @client: I2C client data > - * @id: Entry from I2C table > * @ver: Chip version > - * @state: TVP5146/47 decoder state - detected or not-detected > + * @streaming: TVP5146/47 decoder streaming - enabled or disabled. > * @pix: Current pixel format > * @num_fmts: Number of formats > * @fmt_list: Format list > * @current_std: Current standard > * @num_stds: Number of standards > * @std_list: Standards list > - * @route: input and output routing at chip level > + * @input: Input routing at chip level > + * @output: Output routing at chip level > */ > > Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper > format. Basically, it should be like this example: > > /** > * foobar() - short function description of foobar > * @arg1: Describe the first argument to foobar. > * @arg2: Describe the second argument to foobar. > * One can provide multiple line descriptions > * for arguments. > * > * A longer description, with more discussion of the function foobar() > * that might be useful to those using or modifying it. Begins with > * empty comment line, and may include additional embedded empty > * comment lines. > * > * The longer description can have multiple paragraphs. > **/ > > > - v4l: vpfe capture bridge driver for DM355 and DM6446 > > - vpfe_capture: add missing newlines and fix an incorrect error code. > > - v4l: ccdc hw device header file for vpfe capture > > - v4l: dm355 ccdc module for vpfe capture driver > > - v4l: dm644x ccdc module for vpfe capture driver > > - v4l: ccdc types used across ccdc modules for vpfe capture driver > > - v4l: common vpss module for video drivers > > - v4l: Makefile and config files for vpfe capture driver > > - v4l: davinci drivers should only be compiled for kernels >= 2.6.31. > > I'll try to analyze those remaining patches later today. Unfortunately, > I'm very busy this weekend finishing some pending work. > > > Hopefully these changes can be merged into 2.6.31. > > > > There are two arch/arm patches that need to be applied to the git tree. > > These patches should be applied last. > > > > They are: > > > > http://patchwork.kernel.org/patch/30968/ > > http://patchwork.kernel.org/patch/30974/ > > > > Note that I had to move patch 9 (vpss) in the original patch series > > before patch 6 (the Makefile changes) to make sure everything would > > still compile. > > > > Thanks, > > > > Hans > > > > diffstat: > > b/linux/drivers/media/video/davinci/Makefile |9 > > b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 > > b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 > > + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 > > ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ > > b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + > > b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 > > + > > b/linux/drivers/media/video/davinci/vpss.c | 301 ++ > > b/linux/include/media/davinci/ccdc_types.h | 43 > > b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ > > b/linux/include/media/davinci/dm644x_ccdc.h| 184 + > > b/linux/include/media/davinci/vpfe_capture.h | 188 + > > b/linux/include/media/davinci/vpfe_types.h | 51 > > b/linux/include/media/davinci/vpss.h | 69 > > linux/drivers/media/video/Kconfig | 49 > > linux/drivers/media/video/Makefile |2 > > linux/drivers/media/video/davinci/vpfe_capture.c | 27 > > linux/drivers/media/video/tvp514x.c| 879 ++ > > linux/drivers/media/video/tvp514x_regs.h | 10 > > linux/include/media/tvp514x.h |4 > > v4l/versions.txt |7 > > 21 files changed, 6346 insertions(+), 555 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Jun 21 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12099:c570be1f6fad gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS sparse (linux-2.6.30): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
Em Sat, 20 Jun 2009 09:45:41 -0700 (PDT) Trent Piepho escreveu: > On Sat, 20 Jun 2009, Hans Verkuil wrote: > > - compat: fix __fls check for the arm architecture. > > This one isn't quite right. The __fls defined for arm in 2.6.27 (between > v2.6.26-7260-g0c65f45 and v2.6.28-rc6-187-g94fc733) isn't the same as the > __fls() used everwhere else in the kernel. This alternate fix should > work. > > 01/01: compat: Fix __fls for certain ARM kernels > http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=518b7754cd3d Agreed. I cherry-picked Hans patch and merged ~tap/fix tree to fix the __fls(). Cheers, Mauro -- 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
dvb-t with kernel 2.6.15?
Hello, I have seen that the v4l-dvb modules work only for kernel > 2.6.15. I have a Pinnacle 72e USB DVB-T stick i would like to use with a 2.6.15 (ARM)kernel. This would be a dibcom 0700 driver. Is there any possibilty at all to get this working, or do I have to get a dvb-t usb stick that is supported by the 2.6.15 kernel? How good was the dvb-t support using the 2.6.15 kernel? Thanks for any help. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Fri, 19 Jun 2009 14:39:14 +0200 Hans Verkuil escreveu: > Hi Mauro, > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for > the following: > > - tvp514x: Migration to sub-device framework Hmm... the kernel-doc format is wrong on all function description comment changes on tvp514x: -/** +/* * struct tvp514x_decoder - TVP5146/47 decoder object - * @v4l2_int_device: Slave handle - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device + * @sd: Subdevice Slave handle * @tvp514x_regs: copy of hw's regs with preset values. * @pdata: Board specific - * @client: I2C client data - * @id: Entry from I2C table * @ver: Chip version - * @state: TVP5146/47 decoder state - detected or not-detected + * @streaming: TVP5146/47 decoder streaming - enabled or disabled. * @pix: Current pixel format * @num_fmts: Number of formats * @fmt_list: Format list * @current_std: Current standard * @num_stds: Number of standards * @std_list: Standards list - * @route: input and output routing at chip level + * @input: Input routing at chip level + * @output: Output routing at chip level */ Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper format. Basically, it should be like this example: /** * foobar() - short function description of foobar * @arg1: Describe the first argument to foobar. * @arg2: Describe the second argument to foobar. * One can provide multiple line descriptions * for arguments. * * A longer description, with more discussion of the function foobar() * that might be useful to those using or modifying it. Begins with * empty comment line, and may include additional embedded empty * comment lines. * * The longer description can have multiple paragraphs. **/ > - v4l: vpfe capture bridge driver for DM355 and DM6446 > - vpfe_capture: add missing newlines and fix an incorrect error code. > - v4l: ccdc hw device header file for vpfe capture > - v4l: dm355 ccdc module for vpfe capture driver > - v4l: dm644x ccdc module for vpfe capture driver > - v4l: ccdc types used across ccdc modules for vpfe capture driver > - v4l: common vpss module for video drivers > - v4l: Makefile and config files for vpfe capture driver > - v4l: davinci drivers should only be compiled for kernels >= 2.6.31. I'll try to analyze those remaining patches later today. Unfortunately, I'm very busy this weekend finishing some pending work. > > Hopefully these changes can be merged into 2.6.31. > > There are two arch/arm patches that need to be applied to the git tree. > These patches should be applied last. > > They are: > > http://patchwork.kernel.org/patch/30968/ > http://patchwork.kernel.org/patch/30974/ > > Note that I had to move patch 9 (vpss) in the original patch series before > patch 6 (the Makefile changes) to make sure everything would still compile. > > Thanks, > > Hans > > diffstat: > b/linux/drivers/media/video/davinci/Makefile |9 > b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 > b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 + > b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ > b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ > b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + > b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 > + > b/linux/drivers/media/video/davinci/vpss.c | 301 ++ > b/linux/include/media/davinci/ccdc_types.h | 43 > b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ > b/linux/include/media/davinci/dm644x_ccdc.h| 184 + > b/linux/include/media/davinci/vpfe_capture.h | 188 + > b/linux/include/media/davinci/vpfe_types.h | 51 > b/linux/include/media/davinci/vpss.h | 69 > linux/drivers/media/video/Kconfig | 49 > linux/drivers/media/video/Makefile |2 > linux/drivers/media/video/davinci/vpfe_capture.c | 27 > linux/drivers/media/video/tvp514x.c| 879 ++ > linux/drivers/media/video/tvp514x_regs.h | 10 > linux/include/media/tvp514x.h |4 > v4l/versions.txt |7 > 21 files changed, 6346 insertions(+), 555 deletions(-) > -- Cheers, Mauro -- 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: Sakar 57379 USB Digital Video Camera...
I mentioned in my last message a couple of things to try in order to make further progress. One of those was 2. Take some of the snoop log output and convert it by hand to a binary file, so that it can actually be looked at with hexdump to see if similar clues are present. I have a few tools that, while not making this automatic, do make the job not too too unpleasant. So, I have implemented this one. That is, I have removed everything other than frame data from your log file, and from mine. After that, I have converted said frame data to binary, using a program called "hex2bin" that I found several years ago (see footnote). After that, I have done hexdump -C to the result in order to see if any interesting text becomes visible. What I have to report is: No detectable text patterns, neither in the raw data output from your camera, nor from mine. It appears to me that we have nothing there but raw data and the camera-specific frame headers which we have already figured out are there. (footnote) The program was in source form, and carries the following notice /* hex2bin.creverse hexdump Copyright (c) 1996 by Andreas Leitgeb (AvL) Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. */ Probably nobody on a list like this one needs a thing like this, but just in case that anyone does, I just checked with Google for hex2bin.c and this one comes up as the second hit. I have used it on previous occasions, and it seems to work nicely. (end footnote) Theodore Kilgore -- 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: Sakar 57379 USB Digital Video Camera...
On Sun, 21 Jun 2009, Andy Walls wrote: On Sat, 2009-06-20 at 20:04 -0500, Theodore Kilgore wrote: Sure looks that way. I took a closer look at the lines starting with ff ff ff ff strings, and I found a couple more things. Here are several lines from an extract from that snoop, consisting of what appear to be consecutive SOF lines. : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00 : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00 : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00 : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00 : ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00 The last non-zero byte is a frame counter. Presumably, the gap between the 01 and the 06 occurs because the camera was just then starting up and things were a bit chaotic. The rest of the lines in the file are completely consistent, counting consecutively from 09 to 49 (hex, of course) at which point I killed the stream. The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives the number of 0x200-byte blocks in that frame, before the next marker comes along. So if we start from the frame labeled "06" then from there on the frames are approximately the same size, but not identical. For example the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes. Here's the init for my camera: : 71 81 : 70 05 : 95 70 : 00 : 71 81 : 70 04 : 95 70 : 00 : 71 00 : 70 08 : 95 70 : 00 : 94 02 : de 24 : 94 02 : dd f0 : 94 02 : e3 22 <--- different : 94 02 : e4 00 : 94 02 : e5 00 <--- not repeated like in the sequence above : 94 02 : e6 22 <--- different : 94 03 : aa 01 <--- different : 71 1e : 70 06 : 71 80 : 70 07 And here's the terminal sequence: : 71 00 : 70 09 : 71 80 : 70 05 They look amazingly similar to yours. Here are the buffers with the supposed SOF marker: : ff ff ff ff 00 00 18 43 1e 00 0d fa 00 00 00 00 : ff ff ff ff 00 00 18 26 1e 00 0d 00 00 00 00 00 : ff ff ff ff 00 00 17 fa 1e 00 0c 01 00 00 00 00 : ff ff ff ff 00 00 18 4e 1e 00 0d 02 00 00 00 00 : ff ff ff ff 00 00 18 91 1e 00 0d 03 00 00 00 00 : ff ff ff ff 00 00 18 90 1e 00 0d 04 00 00 00 00 : ff ff ff ff 00 00 18 4b 1e 00 0d 05 00 00 00 00 : ff ff ff ff 00 00 18 8a 1e 00 0d 06 00 00 00 00 Again very similar. I had the camera pointed at a mostly white test target with some large blue numbers printed on it, so the sammler buffers probably just indicate how simple the test target was. The frames from my camera were coming at 100 ms intervals instead of 130 ms intervals. So maybe some scaling constant has changed with my supposed frame presentation frequency field that contains 0x1e00. This looks quite similar. The differences in the init sequence may be significant, but more likely I would speculate that they are insubstantial. Probably the little differences are due to who actually wrote the camera driver. Those guys over there also put their pants on one leg at a time just like the rest of us, after all. I think they do things like hiring students to write their drivers. If so, they might possibly get the same kind of results that could be expected over here from similar arrangements. Agree. The more I dig into this, the more I think (hope or wish?) the stuff in the usb snoop logs looks MJPEG. I started looking at an AVI file that I recorded with the camera. It looks like a DV AVI Type-2 file. In the AVI file header, my camera reports: 0d0: 7374 7264 ac00 4a65 696c strdJeil 0e0: 696e 2020 5465 6368 6e6f 6c6f 6779 2043 in Technology C 0f0: 6f2e 2c20 4c74 642e 4a4c 3230 3038 5632 o., Ltd.JL2008V2 100: 4330 3037 3030 3130 2020 2020 2020 2020 C0070010 So looking up the JL2008A datasheet, my camera's capabilities match the data sheet very well. http://jeilin.com.tw/eng/product_detail.php?p_id=5 http://jeilin.com.tw/mana_php/Download/File/JL2008A%20v1.3.pdf The only video compression that is mentioned on the webpage and in the datasheet is JPEG. Trying to learn about DV AVI Type 2 files I've found roughly how individual chunk headers look. They each have a stream fourcc that starts 'nnxx' in ASCII, where nn is the stream number and xx is db - uncompressed video frame dc - compressed video frame wb - audio data $ xxd 4.avi | grep -E ' 303[0-2] ((646)|(776))' 1f0: 14fe 0c00 6d6f 7669 3031 7762 401f movi0...@... <-- audio 0002140: 3032 6462 0041 ffe2 55aa 0500 02db.AU. <-- video 0006250: 3032 6462 0041 ffe2 55aa 0500 0001 02db.AU. <-- video 000a360: 3032 6462 0041 ffe2 55aa 0500 0002 02db.AU. <-- video 000e470: 3032 6462 0041 ffe2 55aa 0500 0003 02db.AU. <-- video 0012580: 3032 6462 0041 ffe2 55aa 0500 0004 02db.AU. <-- video 0016690: 3030 6463 281c ffd8 ffe
Seeking recommendation for DVB-S PCI card with on-card CI
Hello all, I'm attempting to find a supported DVB-S PCI card with an on-card CI (ie: not a seperate daughter board) to contain all in one slot. Based on the wiki and mailing list archives I seem to come up with the Twinhan AD-SP300(1034): http://www.twinhan.com/product_satellite_1034.asp But the wiki entries seem to refer to a 1030A version: http://www.linuxtv.org/wiki/index.php/Twinhan_VP-1030A Are these the same boards and/or different revisions? Are they supported by the Mantis driver including the CI? This part I wasn't able to confirm from my search. Are there other suggestions for such cards that are 100% supported? Thanks, Thomas -- 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: [linux-dvb] Can't use my Pinnacle HDTV USB stick
On Sun, Jun 21, 2009 at 9:49 AM, Paul Guzowski wrote: > George, > > I can appreciate your frustration because I went through the same struggle a > while back. Fortunately, persistence and a lot of help from the great > people on this forum helped me finally solve the problems I was having. I > have had enough time to study your message line by line and compare it with > my own but will offer a few words on what I did. > > I am using the same stick to capture cable channel three from my cable > set-top box. I had a lot of struggles in the process of getting it to work > beginning with Ubuntu 8.04 but it has worked flawlessly through all the > upgrades to Ubuntu 9.04. I do know there were and maybe still are two > different sets of firmware for the 800e and I had both or parts of both > installed at the same time and that was causing a problem. > > Once I got the hardware, firmware, and drivers sorted out, I think I tried > just about every video/tv software program available for linux and couldn't > get any of the full-featured ones with GUIs to work though I admit I didn't > try very hard with MythTV. When I tried to scan for a signal either from > the basic cable coming out of the wall or from the RF-out on the back of my > set-top box, I could not get anything with any of the pre-built frequency > scanning tables and I never succeeded to find a channel configuration file > for my cable company's (Brighthouse Networks, panhandle of Florida) signal. > > I finally found a reference somewhere to using mplayer from the command line > and feeding it several specific arguments. Once I got it to work, I put the > following in a launcher for easy activation: > > mplayer -vo xv tv:// -tv > driver=v4l2:alsa:immediatemode=0:adevice=hw.1,0:norm=ntsc:chanlist=us-cable:channel=3 > > Admittedly, all this does is put whatever is selected on my cable box in a > window with sound on my desktop. The only thing I can do is resize the > window or turn it off but I can control the volume or change the channel > with the cable box remote so it does the basics I need. I haven't tried the > fancy programs since upgrading to 9.04 nor have I tried mencoder but I would > like to eventually be able to record the signal for delayed viewing (i.e. > use my computer as a PVR). > > Hope this helps. > > Paul in NW Florida Hello Paul, The bulk of the problems you had are usability issues with userland applications rather than issues with the drivers themselves. When it comes to Linux TV applications, the US is much worse off in terms of digital support than Europe and other parts of the world. Much of this is a result of the fact that so much of this country uses cable rather than terrestrial broadcasting, combined with the significantly worse situation with regards to the DRM found in US digital cable systems which effectively prevents people from accessing digital cable on a PC. I can count the list of developers on one hand who work on US based ATSC and QAM drivers. Even fewer actively contribute to application support for these standards. The documentation is lousy, and those who go through the trouble to figure out how to get their stuff to work do not contribute back the information into the wiki. There are just too many devices out there, too many applications out there, and two few developers willing to dedicate the time and energy to do the work. The fact that there is also no way for developers to even recover their costs just further discourages doing new work (a challenge I've had given I've now spent hundreds of dollars on devices and tools and that money is long gone)... I'll get off my soapbox now. :-) Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: PULL request - http://linuxtv.org/hg/~hgoede/gspca
Em Sun, 21 Jun 2009 08:45:03 +0200 Hans de Goede escreveu: > > > On 06/21/2009 02:39 AM, Mauro Carvalho Chehab wrote: > > Em Sat, 20 Jun 2009 15:26:25 +0200 > > Hans de Goede escreveu: > > > >> > >> On 06/20/2009 12:51 PM, Mauro Carvalho Chehab wrote: > >>> Em Wed, 17 Jun 2009 23:54:40 +0200 > >>> Hans de Goede escreveu: > >>> > Support for the st6422 bridge + sensor ! > Give it a try, I know now you have a cam which uses this bridge :) > When you try it be sure to use the latest (just updated my > libv4l tree) libv4l, this enables (software) automatic control of > the gain and exposure, for a decent image in most lighting > conditions. > >>> Didn't work :( See the logs bellow. > >>> > >> > >> > >>> $ dmesg > >>> STV06xx: Probing for a stv06xx device > >>> gspca: probing 046d:08f6 > >>> usbcore: registered new interface driver STV06xx > >>> STV06xx: registered > >>> gspca: usb_submit_urb [0] err -28 > >>> gspca: no transfer endpoint found > >>> > >> err -28 is ENOSPC which is given by usb_submit_urb, when the > >> required bandwidth for the isoc transfer is not available. > >> > >> With most cams we then automatically fall back to an altsetting > >> which requires less bandwidth, but the st6422 has only one > >> hence the: "gspca: no transfer endpoint found" error. > >> > >> There are 3 possible causes for this: > >> 1) You are using the device through an usb 2.0 hub, this should work > >> but does not work due to a bug in the usb subsystem of the kernel, > >> which I have reported but most likely won't be fixed > > > > OK. On a direct port: > > > > OK, better :) > > mplayer does not recognize /dev/video0 as a "v4l" url, so it will just > try to use plain open and then read, which is causing the errors, as > read() on a v4l device wants a buffer large enough to hold 1 frame in one > read. > Yes, I know, but the v4l1 and v4l2 calls also fails: $ export LD_PRELOAD=/usr/local/lib/libv4l/v4l1compat.so $ mplayer -tv driver=v4l2 tv:// ... Cannot find codec matching selected -vo and video format 0x32315659. Read DOCS/HTML/en/codecs.html! $ mplayer -tv driver=v4l tv:// The 'outfmt' of 'Planar YV12' is likely not supported by your card I tested also luvcview 0.2.5 without success: ERROR: Requested frame format MJPG is not available and no fallback format was found. Hmm... on a moment of inspiration, I tested it with ekiga, and it properly worked! Now, I just want to find a way for it to work with the applications I use ;) I'll try to test later the patches you've sent me for the hub Cheers, Mauro -- 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: PULL request - http://linuxtv.org/hg/~hgoede/gspca
Hi,
On 06/21/2009 02:39 AM, Mauro Carvalho Chehab wrote:
Em Sat, 20 Jun 2009 15:26:25 +0200
Hans de Goede escreveu:
err -28 is ENOSPC which is given by usb_submit_urb, when the
required bandwidth for the isoc transfer is not available.
With most cams we then automatically fall back to an altsetting
which requires less bandwidth, but the st6422 has only one
hence the: "gspca: no transfer endpoint found" error.
There are 3 possible causes for this:
1) You are using the device through an usb 2.0 hub, this should work
but does not work due to a bug in the usb subsystem of the kernel,
which I have reported but most likely won't be fixed
Hi,
This morning I had a bit of inspiration, the stv6422 has a register to which
the current isoc packet size should be written, so I though, hmm, maybe the
whole one altsetting which requests max bandwidth thingie is a bit bogus, and
instead it has a variable (so not fixed by altsetting) packet size,
and indeed it has.
Attached is a patch which:
1) makes it work through an usb 2.0 hub (work around the cannot
alloc max isoc bandwidth through a usb 2.0 hub bug, by falling
back in speed).
2) makes the mic and video work at the same time
Unfortunately 1 + 2 combined do not work, this is clearly a bug of the usb
subsystem :(
Regards,
Hans
p.s.
Jean-Francois Moine, can you please take a look at this patch and provide
feedback? It also makes changes the gscpa core.
diff -r 2899ad868fc6 linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Thu Jun 18 19:31:36 2009 +0200
+++ b/linux/drivers/media/video/gspca/gspca.c Sun Jun 21 10:14:28 2009 +0200
@@ -525,6 +525,9 @@
/* See paragraph 5.9 / table 5-11 of the usb 2.0 spec. */
psize = (psize & 0x07ff) * (1 + ((psize >> 11) & 3));
+ /* Variable packet size overriding alt setting ? */
+ if (gspca_dev->isoc_pkt_sz)
+ psize = gspca_dev->isoc_pkt_sz;
npkt = gspca_dev->cam.npkt;
if (npkt == 0)
npkt = 32; /* default value */
@@ -595,6 +598,7 @@
*/
static int gspca_init_transfer(struct gspca_dev *gspca_dev)
{
+ struct cam *cam = &gspca_dev->cam;
struct usb_host_endpoint *ep;
int n, ret;
@@ -609,9 +613,9 @@
/* set the higher alternate setting and
* loop until urb submit succeeds */
gspca_dev->alt = gspca_dev->nbalt;
+ gspca_dev->isoc_pkt_sz = cam->max_isoc_pkt_sz;
+ ep = get_ep(gspca_dev);
for (;;) {
- PDEBUG(D_STREAM, "init transfer alt %d", gspca_dev->alt);
- ep = get_ep(gspca_dev);
if (ep == NULL) {
ret = -EIO;
goto out;
@@ -648,7 +652,17 @@
if (ret == -ENOSPC) {
msleep(20); /* wait for kill
* complete */
- break; /* try the previous alt */
+ if (gspca_dev->isoc_pkt_sz) {
+ /* Try smaller packet size */
+ gspca_dev->isoc_pkt_sz -= 100;
+ if (gspca_dev->isoc_pkt_sz <
+ cam->min_isoc_pkt_sz)
+ goto out;
+ } else {
+ /* try the previous alt */
+ ep = get_ep(gspca_dev);
+ }
+ break;
}
goto out;
}
diff -r 2899ad868fc6 linux/drivers/media/video/gspca/gspca.h
--- a/linux/drivers/media/video/gspca/gspca.h Thu Jun 18 19:31:36 2009 +0200
+++ b/linux/drivers/media/video/gspca/gspca.h Sun Jun 21 10:14:28 2009 +0200
@@ -57,6 +57,12 @@
u8 bulk;/* image transfer by 0:isoc / 1:bulk */
u8 npkt;/* number of packets in an ISOC message
* 0 is the default value: 32 packets */
+ /* min / max isoc packet size for camera's which have a variable
+ packet size, when this is the case BOTH must be set to a non zero
+ value, the wMaxPacketSize of the alsetting will be ignored and the
+ highest alt setting will be used */
+ int min_isoc_pkt_sz;
+ int max_isoc_pkt_sz;
u32 input_flags;/* value for ENUM_INPUT status flags */
};
@@ -135,6 +141,7 @@
#define USB_BUF_SZ 64
__u8 *usb_buf; /* buffer for USB exchanges */
struct urb *urb[MAX_NURBS];
+ int isoc_pkt_sz;
Re: [PATCH / resubmit] USB interrupt support for radio-si470x FM radio driver
On Sat, Jun 20, 2009 at 11:31 PM, Tobias Lorenz wrote: >> Thanks for all your help, now on to Tobias, I guess! > > perfect patch. Thank you Ed. I never figured out how to use interrupt URBs. > This really seams to fix the click problem on unbuffered audio forwarding. Thanks! > The suggestion/question I have is if we want to keep the "users now" log > messages in fops_open and fops_release. > After all the testing today this fills up my logs... Indeed, these messages are probably a bit too low-level, no problem to remove them... Regards, Ed -- 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
