ERROR: cKbdRemote: Invalid argument
Not sure what caused this, but the remote was working and I did an apt-get update/upgrade and then it wasn't. Now the syslog is getting this repeating. Don't seem to have to use the remote for another entry to be added to the log. Jun 24 19:36:33 x64VDR vdr: [4903] ERROR: cKbdRemote: Invalid argument Using Debian Squeeze. remote is on a nexus-s and using ir_kbd_i2c -- 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] Terratec Cinergy 250 PCI support
Hi, Jean-Michel,
Am Freitag, den 25.06.2010, 00:42 +0200 schrieb Jean-Michel Grimaldi:
> Hi, I have a Terratec Cinergy 250 PCI video card, and a small
> modification in saa7134-cards.c is needed for it to work. I built the
> patch on 2.6.34 version (I sent the modification to the maintainer in
> early 2009 but got no feedback):
>
> -- saa7134-cards.old.c2010-06-25 00:31:16.0 +0200
> +++ saa7134-cards.new.c 2010-06-25 00:30:52.0 +0200
> @@ -2833,7 +2833,7 @@
> .tv = 1,
> },{
> .name = name_svideo, /* NOT tested */
> - .vmux = 8,
> + .vmux = 3,
> .amux = LINE1,
> }},
> .radio = {
>
> Thanks for taking it into account in future kernels.
>
hm, don't know who missed it. After Gerd, the main mover on saa7134 was
Hartmut, also /me and some well known others cared.
Official maintainer these days is Mauro.
For latest DVB stuff, you also will meet Mike Krufky.
I'm sorry, but your patch is still wrong.
You do have only a Composite signal. S-Video, with separated chroma and
luma, can only be on vmux 5-9.
NACKED-by: hermann pitton
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
[PATCH] Terratec Cinergy 250 PCI support
Hi, I have a Terratec Cinergy 250 PCI video card, and a small
modification in saa7134-cards.c is needed for it to work. I built the
patch on 2.6.34 version (I sent the modification to the maintainer in
early 2009 but got no feedback):
-- saa7134-cards.old.c 2010-06-25 00:31:16.0 +0200
+++ saa7134-cards.new.c 2010-06-25 00:30:52.0 +0200
@@ -2833,7 +2833,7 @@
.tv = 1,
},{
.name = name_svideo, /* NOT tested */
- .vmux = 8,
+ .vmux = 3,
.amux = LINE1,
}},
.radio = {
Thanks for taking it into account in future kernels.
--
Jean-Michel
--
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: ISDB-T Tuning
Hi Alan Alan Carvalho de Assis wrote: > If you have all frequencies supported in your country you can the > "scan" command to detected all transmitted channels. I do have them but scan is showing no results. I'm using a homemade antenna that is giving 90-100% coverage with the windows app so I'm rather sure this is not a signal strength nor snr issue. Here is my freqs file T 533143000 6MHz 3/4 3/4 AUTO 2k 1/32 NONE # channel 24 T 533143000 6MHz 3/4 AUTO AUTO AUTO AUTO NONE # channel 24 T 569143000 6MHz 3/4 3/4 AUTO 2k 1/32 NONE # channel 30 T 569143000 6MHz 3/4 AUTO AUTO AUTO AUTO NONE # channel 30 T 587143000 6MHz 3/4 3/4 AUTO 2k 1/32 NONE # channel 33 T 587143000 6MHz 3/4 AUTO AUTO AUTO AUTO NONE # channel 33 T 551143000 6MHz 3/4 3/4 AUTO 2k 1/32 NONE # channel 27 T 551143000 6MHz 3/4 AUTO AUTO AUTO AUTO NONE # channel 27 (entries repeated just to try out different combinations) Now, I know for sure there is a 1seg broadcast at 587143 KHZ , that's the one I'm getting with the windows app but scan on Linux keeps showing no results. I'm attaching the verbose scan output (I have also tried with -5 with similar results): Best regards -- Reynaldo scanning ChileISDBT using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 533143000 2 3 3 6 0 0 0 initial transponder 533143000 2 3 9 6 2 4 0 initial transponder 569143000 2 3 3 6 0 0 0 initial transponder 569143000 2 3 9 6 2 4 0 initial transponder 587143000 2 3 3 6 0 0 0 initial transponder 587143000 2 3 9 6 2 4 0 initial transponder 551143000 2 3 3 6 0 0 0 initial transponder 551143000 2 3 9 6 2 4 0 >>> tune to: >>> 533143000:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_3_4:QAM_AUTO:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING: >>> tuning failed!!! >>> tune to: >>> 533143000:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_3_4:QAM_AUTO:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE >>> (tuning failed) >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING: >>> tuning failed!!! >>> tune to: >>> 533143000:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING: >>> tuning failed!!! >>> tune to: >>> 533143000:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE >>> (tuning failed) >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING: >>> tuning failed!!! >>> tune to: >>> 569143000:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_3_4:QAM_AUTO:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING: >>> tuning failed!!! >>> tune to: >>> 569143000:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_3_4:QAM_AUTO:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE >>> (tuning failed) >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING: >>> tuning failed!!! >>> tune to: >>> 569143000:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING: >>> tuning failed!!! >>> tune to: >>> 569143000:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE >>> (tuning failed) >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning sta
Re: ISDB-T Tuning
Hi Reynaldo, On 6/24/10, Reynaldo H. Verdejo Pinochet wrote: > Hi guys > > I have been trying to get a siano based 1seg ISDB-T USB dongle > to scan and tune under Linux to no avail. Asking around it has > been brought to my attention there might be no app available > that would do this successfully even with an adapter currently > supported by the kernel like the one I'm using. Facing that > scenario and assuming my lack of luck trying to find such an > application supports that claim, I'm wondering if there is > anyone reading this that might be working on writing such an > application and/or in extending an existing one like 'scan' > to be able to work with ISDB-T. Just to avoid duplicating the > effort. > If you have all frequencies supported in your country you can the "scan" command to detected all transmitted channels. More info: http://acassis.wordpress.com/2009/09/18/watching-digital-tv-sbtvd-in-the-linux/ Best Regards, Alan -- 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-S Frontend + ARM + DSP
Hello, I've never followed linux-media before, I hope my question is welcome here. I have a basic project(hopefully), involving connection of an DVB-S frontend to an ARM processor. Frontend chip is si2109 which is supported by si21xx driver. I created a pseudo card driver which includes only 3 calls to 'dvb_register_adapter' , 'dvb_attach' and 'dvb_register_frontend'. I can do some channel scanning with this dummy driver then. Now I'm in the phase of demuxing and decoding. Since I don't have any hardware for this I'm planning to do this on software. I'm planning to perform MPEG-TS muxing on ARM and MPEG-2 video decoding on DSP. Is there any example code to begin with such a use case? I tried to read some in tree drivers but I still don't know how to introduce a demux and dvr device to user space so that I can use off-shelf applications like gstreamer. Moreover, I would definetly need some user-space code, at least for mpegts demuxing so I wonder if there is any sane way to make a connection like: demux0 -> userspace demuxing -> dvr0 -> userpace mpeg2 decoding Any help on what path/method to use is very appreciated. Best regards, Caglar -- 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] v4l-dvb daily build 2.6.22 and up: ERRORS, 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:Thu Jun 24 19:00:09 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
Re: update for util/scan/dvb-t/fr-Brest + ask
2010/6/17 Johann Ollivier Lapeyre : > Hi, > > Last week, the France/Bretagne removed analog frequencies and changed > DVB frequencies. Severals files has to changes (Rennes, Brest, ...), > here is the one i made & tested for util/scan/dvb-t/fr-Brest : > > # Brest - France > # Emetteur du Roch Tredudon > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > T 54600 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 57800 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 58600 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 61800 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 65000 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 77000 8MHz AUTO NONE AUTO AUTO AUTO NONE > > ( frequencies with TV Channels). Committed, thanks. > But perhaps you could include all channel to be ready to futurs > changes, i don't know. All frequencies: In this case you could just use autoscan. Christoph > # Brest - France > # Emetteur du Roch Tredudon > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > T 46600 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 47400 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 48200 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 49000 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 49800 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 50600 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 51400 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 52200 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 53000 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 53800 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 54600 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 55400 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 56200 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 57000 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 57800 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 58600 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 59400 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 60200 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 61000 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 61800 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 62600 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 63400 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 64200 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 65000 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 65800 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 66600 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 67400 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 68200 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 69000 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 69800 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 70600 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 71400 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 72200 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 73000 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 73800 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 74600 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 75400 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 76200 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 77000 8MHz AUTO NONE AUTO AUTO AUTO NONE > T 77800 8MHz AUTO NONE AUTO AUTO AUTO NONE > > > And thanks a lot for your job ! -- 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] New DVB-T initial tunning frequencies for gr-Athens
2010/6/20 : > Hi, > As of two days ago (18/06/2010) there are two new frequencies for gr-Athens. > > T 67400 8MHz 3/4 NONE QAM64 8k 1/8 NONE # Digea DVB-T > T 68200 8MHz 3/4 NONE QAM64 8k 1/8 NONE # Digea DVB-T > > It would be nice if you could add them to the scan file. Updated, thanks. > Thanks, > Konstantinos Natsakis Christoph -- 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: Slovak Republic DVB-T scan updates
2010/6/20 Peter Butkovic : > Hi all, > > in Slovak Republic there are some updates regarding DVB-T. > Diff is attached, please commit, thx. Done, thanks! > Updates were made based on official announcement (in slovak): > http://www.dvbt.towercom.sk/odbornici.php > > Kind regards > > Peter Butkovic Christoph -- 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: Switzerland, Geneva DVB-T scan update
2010/6/21 Thomas Kernen : > Hi all, > > For the Switzerland, Geneva region, a new mux has been launched in May 2010 > for the local TV station. Therefore this is now different from the ch-All > DVB-T file. > > Attached is a new file for ch-Geneva containing the SFN frequency for the > main mux and this new mux. I've added this mux to ch-All (this way the file stays valid). > I expect another update may appear in August if/when the French DVB-T mux > start broadcasting in this region. > > Regards, > Thomas Thanks, Christoph -- 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: Update to tuning file frequencies for au-Brisbane location to include a new channel
Hi, Updated, thanks! Christoph 2010/6/23 Jared Norris : > Good morning, > > I would like to include an update in the auto tune file for the > /dvb/dvb-t/au-Brisbane file as there has recently been an additional > channel added to the area. If you can please add the following 2 lines > to the file that would be appreciated. > > # 31 Digital > T 59950 7MHz 2/3 NONE QAM64 8k 1/8 NONE > > It is appropriate for it to be at the end of the list so the whole > file would look like (just in case it makes it easier for you than a > single line in isolation): > > # Australia / Brisbane (Mt Coot-tha transmitters) > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > # ABC > T 22650 7MHz 3/4 NONE QAM64 8k 1/16 NONE > # Seven > T 17750 7MHz 3/4 NONE QAM64 8k 1/16 NONE > # Nine > T 191625000 7MHz 3/4 NONE QAM64 8k 1/16 NONE > # Ten > T 21950 7MHz 3/4 NONE QAM64 8k 1/16 NONE > # SBS > T 585625000 7MHz 2/3 NONE QAM64 8k 1/8 NONE > # 31 Digital > T 59950 7MHz 2/3 NONE QAM64 8k 1/8 NONE > > I hope this is enough information for your requirements. I have tested > this on several devices under several dvb applications and from what I > can see the options are all correct. If further information or testing > is required please let me know and I will happily help out. Thanks for > your time. > > Regards, > > Jared Norris -- 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: [2.6.33.4 PATCH] V4L/uvcvideo: Add support for Suyin Corp. Lenovo Webcam
Hi Laurent,
On Wed 2010-06-23 @ 02-45-53PM +0200, Laurent Pinchart wrote:
# Hi Nils,
#
# On Wednesday 23 June 2010 11:23:16 Nils Radtke wrote:
# > From: Nils Radtke
# >
# > This patch adds support for the Suyin Corp. Lenovo Webcam.
# > lsusb: ID 064e:a102 Suyin Corp. Lenovo Webcam
# >
# > It is available as built-in webcam i.e. in ACER timeline 1810t
# > notebooks.
# >
# > The note in uvc_driver.c about Logitech cameras applies the same
# > to the Suyin web cam: it doesn't announce itself as UVC devices
# > but is compliant.
# >
# > Signed-off-by: Nils Radtke
#
# Thanks for the patch. Could you please send me the output of lsusb -v for
your
Bus 002 Device 002: ID 064e:a102 Suyin Corp. Lenovo Webcam
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x064e Suyin Corp.
idProduct 0xa102 Lenovo Webcam
bcdDevice2.22
iManufacturer 2 SuYin
iProduct1 WebCam
iSerial 3 CN0316-S30C-OV061-VA-R02.02.02
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 569
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 98mA
Interface Association:
bLength 8
bDescriptorType11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 5 Webcam
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 5 Webcam
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 103
dwClockFrequency 15.00MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 5
iTerminal 0
VideoControl Interface Descriptor:
bLength26
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {7033f028-1163-2e4a-ba2c-6890eb334016}
bNumControl 8
bNrPins 1
baSourceID( 0) 3
bControlSize1
bmControls( 0) 0x0f
iExtension 0
VideoControl Interface Descriptor:
bLength26
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 5
guidExtensionCode {3fae1228-d7bc-114e-a357-6f1edef7d61d}
bNumControl 8
bNrPins 1
baSourceID( 0) 4
bControlSize1
bmControls( 0) 0xff
iExtension 0
VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength0
bControlSize 3
bmControls 0x
VideoControl Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize2
bmControls 0x173f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
Backlight Compensation
Gain
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards
ISDB-T Tuning
Hi guys I have been trying to get a siano based 1seg ISDB-T USB dongle to scan and tune under Linux to no avail. Asking around it has been brought to my attention there might be no app available that would do this successfully even with an adapter currently supported by the kernel like the one I'm using. Facing that scenario and assuming my lack of luck trying to find such an application supports that claim, I'm wondering if there is anyone reading this that might be working on writing such an application and/or in extending an existing one like 'scan' to be able to work with ISDB-T. Just to avoid duplicating the effort. Best regards -- Reynaldo -- 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
Help wanted on removing dibusb_rc_keys from dvb_usb_rtl2831u module
This is probably caused by the current dvb_usb_rtl2831u module using dibusb_rc_keys, which disapperead due to IR changes. Syncing the rtl2831-r2/ tree with the main archive cause compilation problems in v4l/dibusb-mc.c and I suppose rtd2830u.c will not compile anymore either. Can somebody with knowledge on IR help me with updating the code ? $ grep dibusb_rc_keys */*.[ch] v4l/dibusb-mc.c:.rc_key_map = dibusb_rc_keys, v4l/rtd2830u.c: d->props.rc_key_map = dibusb_rc_keys; v4l/rtd2830u.c: .rc_key_map = dibusb_rc_keys, v4l/rtd2830u.c: .rc_key_map = dibusb_rc_keys, I addition, I'd like to get help on how to move the IR code into http://linuxtv.org/hg/~anttip/rtl2831u That (in all other respects much better) version has NO IR support at all at. Adding IR to that driver, and getting it into the kernel would solve all problems. Thomas Holzeisen wrote: Hi, i am using a DVB-T USB-Stick with Realtek RTL2831 chip (14aa:0160) on Debian Lenny having the lastest Backport kernel 2.6.32. $ uname -a Linux xbmc 2.6.32-bpo.5-686 #1 SMP Fri Jun 11 22:20:29 UTC 2010 i686 GNU/Linux For v4l I took the drivers from here: http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2/ The checked out source compile and installs fine. I compiled them starting with "make distclean". But when plugging the DVB-Stick this happens: [ 229.524028] usb 4-2: new high speed USB device using ehci_hcd and address 3 [ 229.658591] usb 4-2: New USB device found, idVendor=14aa, idProduct=0160 [ 229.661204] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 229.663841] usb 4-2: Product: DTV Receiver [ 229.666308] usb 4-2: Manufacturer: DTV Receiver [ 229.668826] usb 4-2: SerialNumber: 00067936 [ 229.671609] usb 4-2: configuration #1 chosen from 1 choice [ 230.266960] dvb-usb: found a 'Freecom USB 2.0 DVB-T Device' in warm state. [ 230.270314] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 230.273641] DVB: registering new adapter (Freecom USB 2.0 DVB-T Device) [ 230.277461] DVB: registering adapter 0 frontend 0 (Realtek RTL2831 DVB-T)... [ 230.282081] BUG: unable to handle kernel paging request at 02b65c40 [ 230.285794] IP: [] dvb_usb_remote_init+0x12e/0x209 [dvb_usb] [ 230.291463] *pde = [ 230.293969] Oops: 0002 [#1] SMP [ 230.293969] last sysfs file: /sys/devices/pci:00/:00:06.1/usb4/4-2/bmAttributes [ 230.293969] Modules linked in: dvb_usb_rtl2831u(+) dvb_usb_dibusb_common dvb_usb dib3000mc dibx000_common dvb_ttpci dvb_core saa7146_vv videodev v4l1_compat saa7146 videobuf_dma_sg videobuf_core ttpci_eeprom iscsi_trgt crc32c loop snd_hda_codec_nvhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer snd_seq_device snd tpm_tis soundcore tpm shpchp psmouse wmi serio_raw tpm_bios snd_page_alloc pcspkr pci_hotplug processor evdev button ir_core nvidia(P) lirc_imon i2c_nforce2 i2c_core lirc_dev ext3 jbd mbcache raid1 md_mod usbhid hid sg sr_mod cdrom sd_mod crc_t10dif usb_storage ahci ata_generic libata ehci_hcd ohci_hcd scsi_mod usbcore nls_base forcedeth thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 230.293969] [ 230.293969] Pid: 3279, comm: modprobe Tainted: P (2.6.32-bpo.5-686 #1) Point of View [ 230.293969] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 [ 230.293969] EIP is at dvb_usb_remote_init+0x12e/0x209 [dvb_usb] [ 230.293969] EAX: 69656148 EBX: f589b000 ECX: c14c18e4 EDX: f589b018 [ 230.293969] ESI: f5904000 EDI: 03b8 EBP: 0077 ESP: f5851e88 [ 230.293969] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 230.293969] Process modprobe (pid: 3279, ti=f585 task=f5cd4400 task.ti=f585) [ 230.293969] Stack: [ 230.293969] f589b018 f5904000 f5904000 f5904864 0001 f7c61945 f5904418 f80bb8d0 [ 230.293969] <0> f5912000 f5b8f800 f80bad88 f80bad88 f5912000 [ 230.293969] <0> f80bb894 f80ba970 f80b886d f80ba960 f5912000 f80c8c98 f591201c [ 230.293969] Call Trace: [ 230.293969] [] ? dvb_usb_device_init+0x515/0x51c [dvb_usb] [ 230.293969] [] ? rtd2831u_usb_probe+0x19/0x48 [dvb_usb_rtl2831u] [ 230.293969] [] ? usb_probe_interface+0xe7/0x130 [usbcore] [ 230.293969] [] ? driver_probe_device+0x8a/0x11e [ 230.293969] [] ? __driver_attach+0x40/0x5b [ 230.293969] [] ? bus_for_each_dev+0x37/0x5f [ 230.293969] [] ? driver_attach+0x11/0x13 [ 230.293969] [] ? __driver_attach+0x0/0x5b [ 230.293969] [] ? bus_add_driver+0x99/0x1c2 [ 230.293969] [] ? driver_register+0x87/0xe0 [ 230.293969] [] ? usb_register_driver+0x5d/0xb4 [usbcore] [ 230.293969] [] ? rtd2831u_usb_module_init+0x0/0x2c [dvb_usb_rtl2831u] [ 230.293969] [] ? rtd2831u_usb_module_init+0x15/0x2c [dvb_usb_rtl2831u] [ 230.293969] [] ? do_one_initcall+0x55/0x155 [ 230.293969] [] ? sys_init_module+0xa7/0x1d7 [ 230.293969] [] ? sysenter_do_call+0x12/0x28 [ 230.293969] Code: 3e c6 f7 20 74 18 8b 86 a0 00 00 00 5
[RFC v3] Multi-plane buffer support for V4L2 API
Hello,
I would like to take up the multiplane discussion we had during the Helsinki
summit.
- You can find a detailed description in my original patch series here:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg15850.html
(note: as videobuf will be undergoing a major redesign, the relevant parts
are mostly only those concerning V4L2 API).
- The most recent patch, adding the proposed extensions to the API can be found
here:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg16457.html
- The proposal has sparked more interest from various parties during the summit
and additional requirements and suggestions have been put forward, which I would
like to discuss again here and arrive at a consensus, hopefully reasonably
quickly (this issue has been blocking some our drivers from being posted for
some time already).
In short
===
The previous proposal involved adding a new struct v4l2_plane as an extension
to the current v4l2_buffer struct and has generally been accepted.
This RFC mainly concerns the need to add some more per-plane information,
but to the format definition, as opposed to per-buffer info in the case of
the v4l2_plane struct. In other words, metadata that does not change between
frames.
Discussion points
===
1. We would like to add some additional plane-related information for each
plane, e.g. a per-plane "bytesperline" field. Adding it to the v4l2_plane struct
would result in passing it back and forth on each frame though. It would be
better to pass it when setting up format instead. The following shows how it is
done for the single-plane case in the current API.
Passed to the S_FMT ioctl is the:
struct v4l2_format {
enum v4l2_buf_type type;
union {
struct v4l2_pix_format pix; /*
V4L2_BUF_TYPE_VIDEO_CAPTURE */
struct v4l2_window win; /*
V4L2_BUF_TYPE_VIDEO_OVERLAY */
struct v4l2_vbi_format vbi; /*
V4L2_BUF_TYPE_VBI_CAPTURE */
struct v4l2_sliced_vbi_format sliced; /*
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
__u8raw_data[200]; /* user-defined */
} fmt;
};
where:
struct v4l2_pix_format {
__u32 width;
__u32 height;
__u32 pixelformat;
enum v4l2_field field;
__u32 bytesperline; /* for padding, zero if unused
*/
__u32 sizeimage;
enum v4l2_colorspacecolorspace;
__u32 priv; /* private data, depends on
pixelformat */
};
We have concluded that the way to go would be to add a new
v4l2_pix_format_mplane entry to the union in the v4l2_format struct:
struct v4l2_format {
enum v4l2_buf_type type;
union {
struct v4l2_pix_format pix; /*
V4L2_BUF_TYPE_VIDEO_CAPTURE */
struct v4l2_pix_format_mplane mp_pix;
struct v4l2_window win; /*
V4L2_BUF_TYPE_VIDEO_OVERLAY */
struct v4l2_vbi_format vbi; /*
V4L2_BUF_TYPE_VBI_CAPTURE */
struct v4l2_sliced_vbi_format sliced; /*
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
__u8raw_data[200]; /* user-defined */
} fmt;
};
And the actual struct can now either:
a) store the plane data in the remaining space (should fit if we go for 8 planes
as max I think)
struct v4l2_pix_format_mplane {
struct v4l2_pix_format pix_fmt;
struct v4l2_plane_formatplane_fmt[VIDEO_MAX_PLANES];
};
b) pass a userspace pointer to a separate array
struct v4l2_pix_format_mplane {
struct v4l2_pix_format pix_fmt;
__u32 num_planes;
/* userspace pointer to an array of size num_planes */
struct v4l2_plane_format*plane_fmt;
};
and then fetch the array separately. The second solution would give us more
flexibility for future extensions (if we add a handful of reserved fields to the
v4l2_plane_format struct).
The main discussion point here though was how to select the proper member of the
fmt union from v4l2_format struct. It is normally being done with the type
field. Now, assuming that multiplane pix formats make sense only for CAPTURE and
OUTPUT types (right?), we would be adding two new v4l2_buf_type members:
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE
which is not that big of a deal in my opinion after all.
2. There are other fields besides bytesperline that some parties are interested
in having in the plane format struct. Among those we had: sample range
(sorry, I am still not sure I remember this one correctly, please correct me)
and - optionally - memory type-related (more on this further below).
struct v4
Re: CI-Module not working on Technisat Cablestar HD2
Pascal Hahn writes:
> I can't see any of the expected mantis_ca_init but couldn't figure out
> in the code where that gets called.
I don't think it is. It was at some point, but it seems to be removed.
Most likely because it wasn't considered ready at the time this driver
was merged(?)
BTW, there is a potentional null dereference in mantis_irq_handler(),
which will do
ca = mantis->mantis_ca;
..
if (stat & MANTIS_INT_IRQ0) {
dprintk(MANTIS_DEBUG, 0, "<%s>", label[1]);
mantis->gpif_status = rst_stat;
wake_up(&ca->hif_write_wq);
schedule_work(&ca->hif_evm_work);
}
This will blow up if (stat & MANTIS_INT_IRQ0) is true, since
mantis->mantis_ca never is allocated. But then I guess that the
hardware should normally prevent (stat & MANTIS_INT_IRQ0) from being
true as long as the ca system isn't initiated, so this does not pose a
problem in practice.
Still doesn't look good.
Bjørn
--
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] Cinergy C PCI HD with current v4l-dvb - PATCH for review/pull included
22.06.2010 22:27, Yannick K wrote: > On 6/19/10 15:56 , Marko Ristola wrote: >> >> Hello all interested in a robust Mantis driver. > hi Marko, > > is there a hg/git branch where your (and possibly Bjorn Morks) recent > patches are already in? > since i had difficulties to apply some of them. > Unfortunately there isn't a private Git tree. I've now figured out that Manu is the maintainer who could take the patches in from me first. Manu has some ongoing work to modify the DMA transfer by using different buffering scheme. So he will do the rework, and the changes will go into jusst.de. It seems that my version won't go in. What hg/Git tree you tried to use to apply our patches? I can send you another patch against that. > further more, is there a way/patch for the current tree which gives us > a working remote control? Maybe Manu's jusst.de HG tree? I have been trying to get a working H.264 picture, and the remote control isn't so urgent for me. Regards, Marko -- 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
[GIT PATCHES FOR 2.6.36] gspca staging
Hi Mauro, The following changes apply to the 'linuxtv/staging/gspca' branch. The following changes since commit c10ad929a728e24ca92bca1ec9967d311cd014ff: V4L/DVB: gspca - spca1528: New subdriver (2010-06-21 22:19:57 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git staging Jean-François Moine (5): gspca - pac7302/11: Bad request value in USB write. gspca - sq930x: Check the USB read errors. gspca - sq930x: New sensor mt9v111. gspca - main: Don't use the PG_Reserved flag for mmapped buffers. gspca - main: Remove V4L1 compatibility. Márton Németh (1): gspca - pac7302: add Genius iSlim 310 Olivier Lorin (6): gspca - gl860: new driver for MI2020 sensor gspca - gl860: USB control message delay unification gspca - gl860: setting changes applied after an EOI gspca - gl860: use of real resolutions for MI2020 sensor gspca - gl860: fix for wrong 0V9655 resolution identifier name gspca - gl860: text alignment Documentation/video4linux/gspca.txt|1 + drivers/media/video/gspca/gl860/gl860-mi2020.c | 733 +--- drivers/media/video/gspca/gl860/gl860-ov9655.c |4 +- drivers/media/video/gspca/gl860/gl860.c| 42 +-- drivers/media/video/gspca/gl860/gl860.h| 13 +- drivers/media/video/gspca/gspca.c | 88 +--- drivers/media/video/gspca/pac7302.c|3 +- drivers/media/video/gspca/pac7311.c|2 +- drivers/media/video/gspca/sq930x.c | 402 +++--- 9 files changed, 617 insertions(+), 671 deletions(-) Thanks. -- 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
