Re: Fwd: DVB-APPS patch for uk-WinterHill
Hi guys, 2009/12/4 BOUWSMA Barry freebeer.bouw...@gmail.com: On Thu, 3 Dec 2009, Justin Hornsby wrote: Since 02 Dec 2009 the UK WinterHill transmitter site has been broadcasting on different frequencies in a different mode with different modulation. Channels have been re-arranged to occupy five multiplexes and the original BBC 'B' mux is now broadcasting DVB-T2 for high definition services (which of course cannot yet be tuned by mere mortals). The 'WinterHill B' transmitter stopped broadcasting on 02 Dec. The attached file is a patch to reflect these changes. +T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE Updated. While the DVB-T2 multiplex (MUX B) cannot be tuned by existing DVB-T-only devices, and I don't know if the dvb-apps are being prepared for DVB-T2 (there don't appear to be any of the known DVB-S2 transponders listed in a couple positions), the modulation parameters, for future reference, are probably something like +# T2 73800 8MHz 2/3 NONE QAM256 32k 1/128 NONE #E54 DVB-T2 HD MUX B There may need to be additional details specified, I'm no expert. These values are, of course, unconfirmed. The same would be true for Crystal Palace at 10kW, but on channel E31, or 55400, no offset. I think it's too early to add T2 transponders (and guys playing around with such equipment usually know how to get the necessary parameters). barry bouwsma 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
help with cx88 blackbird
I need some help trying to get a second tuner card setup, the card is a Kworld mce 201, it has a conexant cx23416-12 and a conexant 23880-19 chips the tuner is a TNJ7751-MFF . I am running Ubuntu 8.04 with mythtv fixes .21. The card is found as an anolog V4l capture card by mythtv but the Mpeg-2 encoder part isnt found. Dmesg says that the card type is unknown and to add it to the modeprobe.d options file, but I am unsure witch card to choose, I have tried card 45 which loads it as device video3 ( I have to manually enter the video device number in mythtv backend to make it show the probed info) but when I switch to this tuner on a frontend it just sits on a black screen for a few minutes then returns to the mythtv menu. I can use Mplayer from the command line using mplayer -vo xv /dev/video3 the Mplayer window opens but all I get is colored snow. In case it matters my other cards that work with mythtv are a Hauppauge PVR 350 and an ATI TV Wonder dvb card. any help with this would be appreciated. -- 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: Details about DVB frontend API
Michael Krufky wrote: On Fri, Dec 4, 2009 at 3:02 PM, VDR User user@gmail.com wrote: I have stated that I like Manu's proposal, but I would prefer that the get_property (s2api) interface were used, because it totally provides an interface that is sufficient for this feature. Manu and I agree that these values should all be read at once. I think we all (except Mauro) agree that the behavior within the driver should fetch all statistics at once and return it to userspace as a single structure with all the information as it all relates to each other. You're contradicting yourself: by using S2API, the userspace API won't be using a single structure, since S2API will break them into pairs of attributes/values. Nothing limits that the in-kernel API will group those values into a struct, but the internal API should be smart enough to not return to userspace the values that weren't requested by the call. 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: Details about DVB frontend API
On Sat, Dec 5, 2009 at 12:30 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Michael Krufky wrote: On Fri, Dec 4, 2009 at 3:02 PM, VDR User user@gmail.com wrote: I have stated that I like Manu's proposal, but I would prefer that the get_property (s2api) interface were used, because it totally provides an interface that is sufficient for this feature. Manu and I agree that these values should all be read at once. I think we all (except Mauro) agree that the behavior within the driver should fetch all statistics at once and return it to userspace as a single structure with all the information as it all relates to each other. You're contradicting yourself: by using S2API, the userspace API won't be using a single structure, since S2API will break them into pairs of attributes/values. Incorrect. Userspace would issue a get_property call and kernelspace would return a block of key/value pairs. Nothing limits that the in-kernel API will group those values into a struct, but the internal API should be smart enough to not return to userspace the values that weren't requested by the call. The call should be generic, something like get_property_signalstats ... Kernelspace should return all related information, and userspace should pick out what it needs. -Mike -- 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
Linux Video Capture
Xpert DVD Maker USB 2.0 V-STREAM (Empia Newest High-Quality USB2.0 Chipset) USB2.0 Support to 720x480 VS-USB2800D DMESG LOG: usb 1-3: new high speed USB device using ehci_hcd and address 2 usb 1-3: New USB device found, idVendor=eb1a, idProduct=2800 usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-3: configuration #1 chosen from 1 choice Linux video capture interface: v2.00 em28xx: New device @ 480 Mbps (eb1a:2800, interface 0, class 0) em28xx #0: Identified as Unknown EM2800 video grabber (card=0) em28xx #0: em28xx chip ID = 7 em28xx #0: board has no eeprom em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. em28xx #0: You may try to use card=n insmod option to workaround that. em28xx #0: Please send an email with this log to: em28xx #0: V4L Mailing List linux-media@vger.kernel.org em28xx #0: Board eeprom hash is 0x em28xx #0: Board i2c devicelist hash is 0x1b800080 em28xx #0: Here is a list of valid choices for the card=n insmod option: em28xx #0: card=0 - Unknown EM2800 video grabber em28xx #0: card=1 - Unknown EM2750/28xx video grabber em28xx #0: card=2 - Terratec Cinergy 250 USB em28xx #0: card=3 - Pinnacle PCTV USB 2 em28xx #0: card=4 - Hauppauge WinTV USB 2 em28xx #0: card=5 - MSI VOX USB 2.0 em28xx #0: card=6 - Terratec Cinergy 200 USB em28xx #0: card=7 - Leadtek Winfast USB II em28xx #0: card=8 - Kworld USB2800 em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker em28xx #0: card=10 - Hauppauge WinTV HVR 900 em28xx #0: card=11 - Terratec Hybrid XS em28xx #0: card=12 - Kworld PVR TV 2800 RF em28xx #0: card=13 - Terratec Prodigy XS em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 em28xx #0: card=15 - V-Gear PocketTV em28xx #0: card=16 - Hauppauge WinTV HVR 950 em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2) em28xx #0: card=19 - PointNix Intra-Oral Camera em28xx #0: card=20 - AMD ATI TV Wonder HD 600 em28xx #0: card=21 - eMPIA Technology, Inc. GrabBeeX+ Video Encoder em28xx #0: card=22 - Unknown EM2750/EM2751 webcam grabber em28xx #0: card=23 - Huaqi DLCW-130 em28xx #0: card=24 - D-Link DUB-T210 TV Tuner em28xx #0: card=25 - Gadmei UTV310 em28xx #0: card=26 - Hercules Smart TV USB 2.0 em28xx #0: card=27 - Pinnacle PCTV USB 2 (Philips FM1216ME) em28xx #0: card=28 - Leadtek Winfast USB II Deluxe em28xx #0: card=29 - NULL em28xx #0: card=30 - Videology 20K14XUSB USB2.0 em28xx #0: card=31 - Usbgear VD204v9 em28xx #0: card=32 - Supercomp USB 2.0 TV em28xx #0: card=33 - NULL em28xx #0: card=34 - Terratec Cinergy A Hybrid XS em28xx #0: card=35 - Typhoon DVD Maker em28xx #0: card=36 - NetGMBH Cam em28xx #0: card=37 - Gadmei UTV330 em28xx #0: card=38 - Yakumo MovieMixer em28xx #0: card=39 - KWorld PVRTV 300U em28xx #0: card=40 - Plextor ConvertX PX-TV100U em28xx #0: card=41 - Kworld 350 U DVB-T em28xx #0: card=42 - Kworld 355 U DVB-T em28xx #0: card=43 - Terratec Cinergy T XS em28xx #0: card=44 - Terratec Cinergy T XS (MT2060) em28xx #0: card=45 - Pinnacle PCTV DVB-T em28xx #0: card=46 - Compro, VideoMate U3 em28xx #0: card=47 - KWorld DVB-T 305U em28xx #0: card=48 - KWorld DVB-T 310U em28xx #0: card=49 - MSI DigiVox A/D em28xx #0: card=50 - MSI DigiVox A/D II em28xx #0: card=51 - Terratec Hybrid XS Secam em28xx #0: card=52 - DNT DA2 Hybrid em28xx #0: card=53 - Pinnacle Hybrid Pro em28xx #0: card=54 - Kworld VS-DVB-T 323UR em28xx #0: card=55 - Terratec Hybrid XS (em2882) em28xx #0: card=56 - Pinnacle Hybrid Pro (2) em28xx #0: card=57 - Kworld PlusTV HD Hybrid 330 em28xx #0: card=58 - Compro VideoMate ForYou/Stereo em28xx #0: card=59 - NULL em28xx #0: card=60 - Hauppauge WinTV HVR 850 em28xx #0: card=61 - Pixelview PlayTV Box 4 USB 2.0 em28xx #0: card=62 - Gadmei TVR200 em28xx #0: card=63 - Kaiomy TVnPC U2 em28xx #0: card=64 - Easy Cap Capture DC-60 em28xx #0: card=65 - IO-DATA GV-MVP/SZ em28xx #0: Config register raw data: 0x42 em28xx #0: No AC97 audio processor 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 em28xx-audio.c: probing for em28x1 non standard usbaudio em28xx-audio.c: Copyright (C) 2006 Markus Rechberger Em28xx: Initialized (Em28xx Audio Extension) extension usb 1-3: selecting invalid altsetting 7 bash-4.0$ -- 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
GrabBeeX light
I recently bought a GrabbeeX light video capture USB device that seems to be based on the EM2820 chipset. But I can't get it to work. Does anyone else have this card or have tried to get it to work ? I'm using Ubuntu 9.10 with Linux kernel version 2.6.31-16-generic. Here are the kernel prints when I plugged in the device: Dec 4 10:52:15 marvin kernel: [ 294.732251] usb 2-2: new high speed USB device using ehci_hcd and address 4 Dec 4 10:52:15 marvin kernel: [ 294.870541] usb 2-2: configuration #1 chosen from 1 choice Dec 4 10:52:15 marvin kernel: [ 294.927578] Linux video capture interface: v2.00 Dec 4 10:52:15 marvin kernel: [ 294.973120] em28xx: New device USB 2820 Device @ 480 Mbps (eb1a:2820, interface 0, class 0) Dec 4 10:52:15 marvin kernel: [ 294.973219] em28xx #0: chip ID is em2820 (or em2710) Dec 4 10:52:15 marvin kernel: [ 295.119666] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 20 28 80 00 11 03 6a 22 00 00 Dec 4 10:52:15 marvin kernel: [ 295.119696] em28xx #0: i2c eeprom 10: 00 00 04 57 06 21 00 00 00 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.119722] em28xx #0: i2c eeprom 20: 02 00 00 01 f0 10 00 00 00 00 00 00 5b 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.119748] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 03 01 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.119774] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.119800] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.119825] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 Dec 4 10:52:15 marvin kernel: [ 295.119850] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 32 00 30 00 20 00 44 00 Dec 4 10:52:15 marvin kernel: [ 295.119876] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.119901] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.119926] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.119952] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.119977] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.120023] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.120048] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.120073] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 4 10:52:15 marvin kernel: [ 295.120102] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xd5da7b8a Dec 4 10:52:15 marvin kernel: [ 295.120107] em28xx #0: EEPROM info: Dec 4 10:52:15 marvin kernel: [ 295.120111] em28xx #0: No audio on board. Dec 4 10:52:15 marvin kernel: [ 295.120115] em28xx #0: 500mA max power Dec 4 10:52:15 marvin kernel: [ 295.120121] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x Dec 4 10:52:15 marvin kernel: [ 295.133525] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) Dec 4 10:52:15 marvin kernel: [ 295.147762] em28xx #0: found i2c device @ 0x4a [saa7113h] Dec 4 10:52:15 marvin kernel: [ 295.167726] em28xx #0: found i2c device @ 0xa0 [eeprom] Dec 4 10:52:15 marvin kernel: [ 295.185978] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. Dec 4 10:52:15 marvin kernel: [ 295.185984] em28xx #0: You may try to use card=n insmod option to workaround that. Dec 4 10:52:15 marvin kernel: [ 295.185987] em28xx #0: Please send an email with this log to: Dec 4 10:52:15 marvin kernel: [ 295.185989] em28xx #0: V4L Mailing List linux-media@vger.kernel.org Dec 4 10:52:15 marvin kernel: [ 295.185992] em28xx #0: Board eeprom hash is 0xd5da7b8a Dec 4 10:52:15 marvin kernel: [ 295.185995] em28xx #0: Board i2c devicelist hash is 0x6ba50080 Dec 4 10:52:15 marvin kernel: [ 295.185997] em28xx #0: Here is a list of valid choices for the card=n insmod option: Dec 4 10:52:15 marvin kernel: [ 295.186001] em28xx #0: card=0 - Unknown EM2800 video grabber Dec 4 10:52:15 marvin kernel: [ 295.186004] em28xx #0: card=1 - Unknown EM2750/28xx video grabber Dec 4 10:52:15 marvin kernel: [ 295.186007] em28xx #0: card=2 - Terratec Cinergy 250 USB Dec 4 10:52:15 marvin kernel: [ 295.186009] em28xx #0: card=3 - Pinnacle PCTV USB 2 Dec 4 10:52:15 marvin kernel: [ 295.186012] em28xx #0: card=4 - Hauppauge WinTV USB 2 Dec 4 10:52:15 marvin kernel: [ 295.186015] em28xx #0: card=5 - MSI VOX USB 2.0 Dec 4 10:52:15 marvin kernel: [ 295.186017] em28xx #0: card=6 - Terratec Cinergy 200 USB Dec 4 10:52:15 marvin kernel: [ 295.186020] em28xx #0: card=7 - Leadtek Winfast USB II Dec 4 10:52:15
Re: Details about DVB frontend API
Michael Krufky wrote: On Sat, Dec 5, 2009 at 12:30 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Michael Krufky wrote: On Fri, Dec 4, 2009 at 3:02 PM, VDR User user@gmail.com wrote: I have stated that I like Manu's proposal, but I would prefer that the get_property (s2api) interface were used, because it totally provides an interface that is sufficient for this feature. Manu and I agree that these values should all be read at once. I think we all (except Mauro) agree that the behavior within the driver should fetch all statistics at once and return it to userspace as a single structure with all the information as it all relates to each other. You're contradicting yourself: by using S2API, the userspace API won't be using a single structure, since S2API will break them into pairs of attributes/values. Incorrect. Userspace would issue a get_property call and kernelspace would return a block of key/value pairs. If userspace does a call with space for just one key/value pair, where do you expect to store the other key/value pairs? 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
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: WARNINGS
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:Sat Dec 5 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13546:309f16461cf4 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: OK linux-2.6.32-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: OK 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: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: OK linux-2.6.32-x86_64: OK spec: OK sparse (linux-2.6.32): ERRORS linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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: [PULL] http://kernellabs.com/hg/~mkrufky/hcw-ids
Michael Krufky wrote: Mauro, Please pull from: http://kernellabs.com/hg/~mkrufky/hcw-ids for: - smsusb: add autodetection support for five additional Hauppauge USB IDs smsusb.c | 10 ++ 1 file changed, 10 insertions(+) It seems that your site is unstable. I had to run the hgimport and the hg pull command twice here to get the patches: hg pull http://kernellabs.com/hg/~mkrufky/hcw-ids abort: error: timed out Anyway, patches applied. 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/~pb/v4l-dvb/
Patrick Boettcher wrote: Hi Mauro, please pull from http://linuxtv.org/hg/~pb/v4l-dvb/ for the following changeset: DiB8090: Add the DiB0090 tuner driver and STK8096GP-board This is the adding support for the DiB809x-device you were asking 2 weeks ago. If possible, please include it into the patches which will go for 2.6.33 . This repo also includes the changesets which were in my previous pull request. Hi Patrick, In the last patch, checkpatch.pl returned: total: 134 errors, 220 warnings, 3291 lines checked Would it be possible to correct the CodingStyle errors on it? There are lots of comments that aren't following C99 specs. Also, some code is indented with 4 spaces, instead of tabs, making really hard to read the code, among several other codingstyle violations. Thanks, 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
[em28xx] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [ffffffffa00997be] :ir_common:ir_input_free+0x26/0x3e
Hi All, Tried to update my v4l-dvb modules today, but got a bug with my pinnacle card, seems to be related to the recent changes in the ir code. I have added dmesg output of the bug (changeset a871d61b614f tip), and dmesg output of the previous modules (working). -- Sander Dec 5 23:30:25 security kernel: [5.596128] em28xx: New device Pinnacle Systems GmbH PCTV USB2 PAL @ 480 Mbps (2304:0208, interface 0, class 0) Dec 5 23:30:25 security kernel: [5.596535] em28xx #1: chip ID is em2820 (or em2710) Dec 5 23:30:25 security kernel: [5.726154] em28xx #1: i2c eeprom 00: 1a eb 67 95 04 23 08 02 10 00 1e 03 98 1e 6a 2e Dec 5 23:30:25 security kernel: [5.726181] em28xx #1: i2c eeprom 10: 00 00 06 57 6e 00 00 00 8e 00 00 00 07 00 00 00 Dec 5 23:30:25 security kernel: [5.726203] em28xx #1: i2c eeprom 20: 16 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726226] em28xx #1: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726247] em28xx #1: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726270] em28xx #1: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726290] em28xx #1: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 2e 03 50 00 69 00 Dec 5 23:30:25 security kernel: [5.726312] em28xx #1: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 Dec 5 23:30:25 security kernel: [5.726333] em28xx #1: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 20 00 47 00 Dec 5 23:30:25 security kernel: [5.726354] em28xx #1: i2c eeprom 90: 6d 00 62 00 48 00 00 00 1e 03 50 00 43 00 54 00 Dec 5 23:30:25 security kernel: [5.726376] em28xx #1: i2c eeprom a0: 56 00 20 00 55 00 53 00 42 00 32 00 20 00 50 00 Dec 5 23:30:25 security kernel: [5.726397] em28xx #1: i2c eeprom b0: 41 00 4c 00 00 00 06 03 31 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726420] em28xx #1: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726440] em28xx #1: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726461] em28xx #1: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726484] em28xx #1: i2c eeprom f0: 00 00 00 00 00 00 00 00 07 56 d9 35 01 ed 0b f8 Dec 5 23:30:25 security kernel: [5.726506] em28xx #1: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x0fd77740 Dec 5 23:30:25 security kernel: [5.726513] em28xx #1: EEPROM info: Dec 5 23:30:25 security kernel: [5.726517] em28xx #1: AC97 audio (5 sample rates) Dec 5 23:30:25 security kernel: [5.726522] em28xx #1: 500mA max power Dec 5 23:30:25 security kernel: [5.726528] em28xx #1: Table at 0x06, strings=0x1e98, 0x2e6a, 0x Dec 5 23:30:25 security kernel: [5.726534] em28xx #1: Identified as Pinnacle PCTV USB 2 (card=3) Dec 5 23:30:25 security kernel: [5.735698] BUG: unable to handle kernel NULL pointer dereference at Dec 5 23:30:25 security kernel: [5.735716] IP: [a00997be] :ir_common:ir_input_free+0x26/0x3e Dec 5 23:30:25 security kernel: [5.735736] PGD 1fdcb067 PUD 1f65d067 PMD 0 Dec 5 23:30:25 security kernel: [5.735744] Oops: [1] SMP Dec 5 23:30:25 security kernel: [5.735750] CPU 0 Dec 5 23:30:25 security kernel: [5.735754] Modules linked in: ir_kbd_i2c(+) saa7115 usbhid(+) hid ff_memless em28xx(+) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 ir_common videobuf_vmalloc videobuf_core tveeprom i2c_core evdev ext3 jbd mbcache ohci_hcd ohci1394 ieee1394 ehci_hcd uhci_hcd thermal_sys Dec 5 23:30:25 security kernel: [5.735793] Pid: 1091, comm: modprobe Not tainted 2.6.26-2-xen-amd64 #1 Dec 5 23:30:25 security kernel: [5.735798] RIP: e030:[a00997be] [a00997be] :ir_common:ir_input_free+0x26/0x3e Dec 5 23:30:25 security kernel: [5.735812] RSP: e02b:88001e12fd28 EFLAGS: 00010246 Dec 5 23:30:25 security kernel: [5.735817] RAX: RBX: RCX: Dec 5 23:30:25 security kernel: [5.735823] RDX: 0202 RSI: 7fff RDI: 88001f6b9000 Dec 5 23:30:25 security kernel: [5.735829] RBP: ffed R08: 8800016c9270 R09: 88001f6bca50 Dec 5 23:30:25 security kernel: [5.735835] R10: R11: a0080ec6 R12: 0063 Dec 5 23:30:25 security kernel: [5.735840] R13: 88001f6b9000 R14: 8800016c9008 R15: 88001f65e1a8 Dec 5 23:30:25 security kernel: [5.735848] FS: 7fe1b4eb76e0() GS:80539000() knlGS: Dec 5 23:30:25 security kernel: [5.735855] CS: e033 DS: ES: Dec 5 23:30:25 security kernel: [5.735860] DR0: DR1:
Technisat SkyStar2 DVB card (rev 02)
Hi, Does this card require additional non-GPL binary driver? According to the Wiki it does, whats the kernel to use with it? It does not compile with 2.6.31 02:0c.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02) It does not load the frontend: 6[ 13.055957] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully 6[ 13.099612] flexcop-pci: will use the HW PID filter. 6[ 13.117656] flexcop-pci: card revision 2 6[ 13.135722] b2c2_flexcop_pci :02:0c.0: enabling device (0004 - 0007) 7[ 13.154137] alloc irq_desc for 20 on node -1 7[ 13.154143] alloc kstat_irqs on node -1 6[ 13.154156] b2c2_flexcop_pci :02:0c.0: PCI INT A - GSI 20 (level, low) - IRQ 20 6[ 13.190184] DVB: registering new adapter (FlexCop Digital TV device) 6[ 13.210549] b2c2-flexcop: MAC address = 00:08:c9:e0:96:ff 3[ 13.229739] CX24123: wrong demod revision: 62 4[ 13.524474] mt352_read_register: readreg error (reg=127, ret==-121) 4[ 13.555822] nxt200x: nxt200x_readbytes: i2c read error (addr 0x0a, err == -121) 4[ 13.574430] Unknown/Unsupported NXT chip: 00 00 00 00 00 4[ 13.611181] lgdt330x: i2c_read_demod_bytes: addr 0x59 select 0x02 error (ret == -121) 4[ 13.669970] stv0297_readreg: readreg error (reg == 0x80, ret == -121) 7[ 13.708395] mt312_read: ret == -121 3[ 13.708549] b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter 6[ 13.728109] b2c2_flexcop_pci :02:0c.0: PCI INT A disabled Jonas -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, 2009-12-04 at 22:45 -0500, Jon Smirl wrote: On Fri, Dec 4, 2009 at 8:48 PM, Andy Walls awa...@radix.net wrote: On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote: On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de wrote: BTW, I just came across a XMP remote that seems to generate 3x64 bit scan codes. Anyone here has docs on the XMP protocol? Assuming a general purpose receiver (not one with fixed hardware decoding), is it important for Linux to receive IR signals from all possible remotes no matter how old or obscure? Importance of any particular requirement is relative/subjective. As is usefulness of any existing functionality. Personally, I just think it's cool to pick up a random remote and use Linux to figure out its protocol and its codes and get it working. You are a technical user. Yes, I agree. I do not know what percentage of current Linux users are technical vs non-technical, so I cannot gauge the current improtance. I can see the trend line though: as time goes by, the percentage of all linux users that have a technical bent will only get smaller. I've been working off the premise of getting rid of obscure remotes and replacing them with a universal one. The universal one can be set to send a common protocol like JVC or Sony. That implies that we only need one or two protocol decoders in-kernel which greatly reduces the surface area of the problem. The design should serve the users, the users should not serve the design. If the reduction of requirements scope starts forcing users to buy new hardware, are we really serving the users or just asking them to pay to compensate for our shortcomings? Use of arbitrary remotes is a complex process. It almost certainly can not be done in a transparent just works manner. Let me rephrase, is it ok to tell people to buy a new remote if they want to avoid a complex, technical configuration process that isn't even guaranteed to work (they might have a 56K remote and a 38K receiver or a Sony remote and a fixed RC-5 receiver). Recommended hardware to guide users is usually an acceptable concept. I have a feeling though, we may end up with a lot of hey I got this remote and video card on eBay and ... If the in kernel IR Rx handling is going to be really limited in trying to keep it simple, then that remote control hardware recommendation should probably be strictly the remote bundled with your IR receiver hardware to handle the most important use case for the in kernel IR Rx handling to meet. I'm not proposing that we prevent arbitrary remotes from working, you're just going to need to expend more effort to make them work. For example, you have to have a fair amount of IR knowledge to figure out why those two cases above don't work. You might have to install LIRC and futz with irrecord and build your own config files and mapping tables, etc... It doesn't have to only be a universal remote, we can pre-install mapping tables for the remotes commonly shipped with the v4l hardware. At least one vendor, has shipped two different type of remote with the same board over the years. Also MCE versions of cards usually ship with an MCE remote versus the standard one. I think it still could be possible to avoid a user interview process, but I suspect you'll need a userspace set of scripting tools to take detection data from the kernel and select the right kepymap. When the v4l drivers load they could even poke the default map for their bundled remotes directly into the input system if they wanted to. Doing that might save a lot of config issues. They do that right now (well some of them and ir-kbd-i2c). But there is *no* intelligence beyond the most current or popular remote for a board. Also, some things require things a manual or scripted module load by the user: ir-kbd-i2c and lirc_i2c can't currently hook to the same I2C device at once, so the user has to set one or the other up to be loaded. How this for new goals? Specific IR drivers autoload maps for their bundled remotes by poking them into the input subsystem during module load IR always has default map for a universal remote - it provides five devices and uses a common protocol like JVC (may not work for fixed hardware, you have to set these five common devices into the universal remote) All of these maps can be overriden with user space commands (which lets you configure funky remotes) This looks like it just adds the option for the user to trade away mental effort with purchasing power (for a universal remote). Not an unacceptable trade for many people I guess. I suppose it gives the user one option than he had before, if you have a target set of universal remote hardware. I'd like to see some vendor diversity in that target set of just works universal remotes. My whole thought on the in-kernel IR Rx implementation is try to do it all, or do just enough to
Heads up, I'm adding IR stuff to cx23885 and cx25840
Mauro, I noticed you've added some changes to th v4l-dvb tree for IR. Just to let you know, I've added an NEC protocol implementation to cx23885-input.c. The two relevant changes are here: cx23885: Convert from struct card_ir to struct cx23885_ir_input for IR Rx http://linuxtv.org/hg/~awalls/cx23885-ir/rev/c51daeba32cb cx23885: Add NEC protocol decoding for IR Rx http://linuxtv.org/hg/~awalls/cx23885-ir/rev/6cba2fc1ea99 I haven't kept track with all your changes so far, but just wanted to let you know these would be ready sometime before Christmas for hopefully the HVR-1800 and TeVii S470. Hopefully, the changes will also be brought up to date with your changes by then too. Regards, Andy -- 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
AF9035 USB2 DVB-T device
Hi guys, I see some work has been done on the AF9015 driver, but I've found yet another variant. It was branded WandTV. |[ 3531.496078] usb 1-4: new high speed USB device using ehci_hcd and address 15 [ 3531.634713] usb 1-4: New USB device found, idVendor=15a4, idProduct=1001 [ 3531.634777] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3531.634832] usb 1-4: Product: AF9035A USB Device [ 3531.634875] usb 1-4: Manufacturer: Afa Technologies Inc. [ 3531.634922] usb 1-4: SerialNumber: AF010202071 [ 3531.635169] usb 1-4: configuration #1 chosen from 1 choice [ 3531.644931] input: Afa Technologies Inc. AF9035A USB Device as /devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.1/input/input9 [ 3531.645175] generic-usb 0003:15A4:1001.0005: input,hidraw0: USB HID v1.01 Keyboard [Afa Technologies Inc. AF9035A USB Device] on usb-:00:1d.7-4/input1| Any ideas where to start? The main variation seems to be the firmware (on Windows), but I'm not experienced enough to fire up usbsnoop. Thanks, Adam Baxter -- 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: Heads up, I'm adding IR stuff to cx23885 and cx25840
Andy Walls wrote: Mauro, I noticed you've added some changes to th v4l-dvb tree for IR. Just to let you know, I've added an NEC protocol implementation to cx23885-input.c. The two relevant changes are here: cx23885: Convert from struct card_ir to struct cx23885_ir_input for IR Rx http://linuxtv.org/hg/~awalls/cx23885-ir/rev/c51daeba32cb cx23885: Add NEC protocol decoding for IR Rx http://linuxtv.org/hg/~awalls/cx23885-ir/rev/6cba2fc1ea99 I haven't kept track with all your changes so far, but just wanted to let you know these would be ready sometime before Christmas for hopefully the HVR-1800 and TeVii S470. Hopefully, the changes will also be brought up to date with your changes by then too. By looking on your code, as you're calling: ir_input_init(input_dev, ir-ir, ir_type, ir_codes); You'll already be using my new code. However, you'll need to add a call to ir_input_free(input_dev), at the IR unregistering code, and on an error condition. You should notice that you're not limited to use only 128 scancodes from 0 to 127, as the previous versions of the ir-common allowed. The new version supports 32 bits for scancodes, and use dynamic allocation to allow adding/removing codes from the table. 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi, Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl: On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de wrote: BTW, I just came across a XMP remote that seems to generate 3x64 bit scan codes. Anyone here has docs on the XMP protocol? Assuming a general purpose receiver (not one with fixed hardware decoding), is it important for Linux to receive IR signals from all possible remotes no matter how old or obscure? Or is it acceptable to tell the user to throw away their dedicated remote and buy a universal multi-function one? Universal multi-function remotes are $12 in my grocery store - I don't even have to go to an electronics store. finally we have some point here, IMHO, that is not acceptable and I told you previously not to bet on such. Start some poll and win it, and I'll shut up :) To be frank, you are quite mad at this point, or deliver working other remotes to __all__ for free. 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
Sky2PC Rev. 3.1
Hello: I've had a Sky2PC (ver 3.1) DVB-S card kicking around for a while and I'd like to get it operational. According to the v4l-dvb wiki, this card requires a definition, and to post the details to the linuxtv mailing list, so here goes.. Thank you. Sandy MacDonald On the back of the card: Model: SKY2PC P/N: 92105-20101 Rev: 3.1 Serial no. and MAC address The front of the card: DBC1201 (on the metal shielding), nothing else. Main chip: B2C2 Flexcop III M3B9E-001 0215 lspci -v 01:0e.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopIII DVB chip / Technisat SkyStar2 DVB card (rev 01) Subsystem: Techsan Electronics Co Ltd Device 2104 Flags: bus master, slow devsel, latency 64, IRQ 10 Memory at f410 (32-bit, non-prefetchable) [size=64K] I/O ports at 3400 [size=32] lspci -vn 01:0e.0 0280: 13d0:2200 (rev 01) Subsystem: 13d0:2104 Flags: bus master, slow devsel, latency 64, IRQ 10 Memory at f410 (32-bit, non-prefetchable) [size=64K] I/O ports at 3400 [size=32] -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi, On Sun, Dec 06, 2009 at 04:36:33AM +0100, hermann pitton wrote: Hi, Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl: On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus l...@bartelmus.de wrote: BTW, I just came across a XMP remote that seems to generate 3x64 bit scan codes. Anyone here has docs on the XMP protocol? Assuming a general purpose receiver (not one with fixed hardware decoding), is it important for Linux to receive IR signals from all possible remotes no matter how old or obscure? Or is it acceptable to tell the user to throw away their dedicated remote and buy a universal multi-function one? Universal multi-function remotes are $12 in my grocery store - I don't even have to go to an electronics store. finally we have some point here, IMHO, that is not acceptable and I told you previously not to bet on such. Start some poll and win it, and I'll shut up :) Who would participate in the poll though? To be frank, you are quite mad at this point, or deliver working other remotes to __all__ for free. I do not believe you are being realistic. Sometimes we just need to say that the device is a POS and is just not worth it. Remember, there is still lirc hole for the hard core people still using solder to produce something out of the spare electronic components that may be made to work (never mind that it causes the CPU constantly poll the device, not letting it sleep and wasting electricity as a result - just hypotetical example here). We still need to do cost-benefit analysis and decide whether supporting the exotic setups _in kernel_ makes sense if it encumbers implementation and causes issues to the other 95% people. -- Dmitry -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
Em Fri, 4 Dec 2009 02:06:42 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:
evdev does not really care what you use as scancode. So nobody stops
your driver to report index as a scancode and accept index from the
ioctl. The true scancode will thus be competely hidden from userspace.
In fact a few drivers do just that.
Let me better express here. It is all about how we'll expand the limits of
those
ioctls to fulfill the needs.
The point is that we'll have, let's say something like to 50-500
scancode/keycode tuples
sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure if
is there any
IR protocol/code with a bigger scancode).
On such universe if we want to get all keycodes with the current ioctls for a
scancode in
the range of 32 bits, we need to do something like:
u32 code;
int codes[2];
for (code = 0; code = (unsigned u32) - 1; code++) {
codes[0] = (int)code;
if (!ioctl(fd, EVIOCGKEYCODE, codes))
printf(scancode 0x%08x = keycode 0x%08x\n, codes[0],
codes[1]);
}
So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE
ioctl to
read the complete scancode space, to get those 50-500 useful codes.
Right, currently there is no need to query all scancodes defined by
device. Quite often drivers don't even know what scancodes device
actually generates (ex AT keyboard).
Could you describe in more detail how you are using this data?
Due to the current API limit, we don't have any way to use the full 64bits
space for scancodes.
Can we probably reduce the scancode space? ARe all 64 bits in
protocols used to represent keypresses or some are used for some kind of
addressing?
if we use code[0] as an index, this means that we'll need to share the 32
bits on code[1]
for scancode/keycode. Even using an 32 bits integer for keycode, it is
currently limited to:
#define KEY_MAX 0x2ff
#define KEY_CNT (KEY_MAX+1)
So, we have 10 bits already used for keycode. This gives only 22 bits for
scancodes, if we share
codes[1] for both keycode/scancode. By sharing the 32 bits, we'll need to be
care to not extend
KEY_MAX to be bigger than 0x3ff, otherwise the keytable won't be able to
represent all keys of the
key universe.
What is need for this case is that the arguments for get key/set key to be
something like:
struct {
u16 index;
u64 scancode;
u32 keycode;
};
Hmm, so what is this index? I am confused...
Thanks.
--
Dmitry
--
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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote: How related lirc-core to the current lirc code? If it is not the same maybe we should not call it lirc to avoid confusion. Just for better illustrate what I'm seeing, I broke the IR generic code into two components: lirc core - the module that receives raw pulse/space and creates a device to receive raw API pulse/space events; IR core - the module that receives scancodes, convert them into keycodes and send via evdev interface. We may change latter the nomenclature, but I'm seeing the core as two different modules, since there are cases where lirc core won't be used (those devices were there's no way to get pulse/space events). OK, I think we are close but not exactly close. I believe that what you call lirc core will be used always - it is the code that create3s class devices, connectes decorers with the data streams, etc. I believe it will be utilized even in case of devices using hardware decoders. That is why we should probably stop calling it lirc core just tso we don't confuse it with original lirc. Then we have decoders and lirc_dev - which implements original lirc interface (or maybe its modified version) and allows lircd to continue working. Lastly we have what you call IR core which is IR-to-input bridge of sorts. Right? -- Dmitry -- 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
