Re: ATSC Tuner in KWorld PC120-U PCI Hybrid ATSC (17de:a134)
I've been trying to get the ATSC tuner in my KWorld PC120-U PCI Hybrid ATSC (17de:a134) Are you sure you don't mean the PC120-U ? -- I can't find such a product. A PC150-U model, on the other hand I see the drivers for both TDA18271HDC2 and TDA8290 loaded. I thought TDA18271HDC2 was the digital channel decoder, isn't it? Is the digital channel decoder different from the digital tuner?? Should be looking for a different chip? they are detected by chip IDs. The tda8290 is the IF demodulator for global analog TV. In case of the saa7135 it is an extra chip on the PCB, which most often can also control the tuner over an i2c gate. The tda18271hdc2 is a global hybrid tuner for analog and digital terrestrial TV. It can also provide a FM radio IF. Further processing and stereo separation for that is done on capable bridges like saa7133/35/31e, not on the tda 8290. Yes, for any terrestrial digital TV you need an extra channel decoder and all known details about it. http://linuxtv.org/wiki/index.php/Category:ATSC_PCI_Cards In case of terrestrial ATSC, it must be able to deal with 8VSB modulation. From the pics on newegg ( http://www.newegg.com/Product/Product.aspx?Item=N82E16815260032 ), it appears that they have used a Samsung demodulator -- 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
the V4L mailing list is deprecated
Hello whomever at Redhat who is managing this list, Its now been over two years since the Linux Media Mailing List was set up and it, indeed, has become well established (http://www.linuxtv.org/news.php?entry=2009-01-06.mchehab). While most V4L-DVB community participants have transitioned over to the LMML, unfortunately, (likely from those unaware of the change) a fair number of user messages are still getting posted to the now essentially deprecated video4linux mailing list. It is a diservice to those folks to continue allowing messages to make it on to the v4l list, as most of them will go unnoticed (as, as mentioned, most users in a position to respond to the sender have already abandoned this list in favour of the new LMML). Could we please effectively wind down the video4linux by the end of this month -- perhaps by way of setting up an auto notification response to any future submitter to the video4linux mailing list that their message should instead be sent to the LMML instead (perhaps even setting up a courtesy redirect of their message to the LMML for them) ? Cheers -- 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 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Jean Delvare wrote: On Mon, 06 Apr 2009 23:10:36 +0200, hermann pitton wrote: Am Montag, den 06.04.2009, 10:40 +0200 schrieb Jean Delvare: Anyone out there with a MSI t...@nywhere Plus that could help with testing? Here is a link to one of the initial reports by Henry, others are close to it. http://marc.info/?l=linux-videom=113324147429459w=2 There are two different variants of that MSI card, but that undocumented KS003 chip is the same on them. Great, thanks for the pointer. If I understand correctly, the KS003 has a state machine flow which causes the chip to stop answering when an invalid address is used on the bus and start answering again when a valid address other than his own is used. As the old i2c model relied a lot on probing, I am not surprised that this was a problem in the past. But with the new model, probes should become infrequent, so I suspect that the workaround may no longer be needed... except when i2c_scan=1 is used. I'd rather keep the workaround in place for the time being, and only once the ir-kbd-i2c changes have settled, try to remove it if someone really cares. Regarding the KS003 ( KS007; the other mystery chip): Upon further investigation of some info from a post from last year (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html), it appears that these (assuming that they are the same IC across the various MSI, Leadtek KWorld cards; and I believe that to be true) are the AT8PS54/S56 chip from Feeling Technology ... the datasheet for that part is available through a google search probing further (as I had never heard of FT before and so I looked them up), it looks like FT renamed and/or upgraded the chip to the FM8PS54/S56 ... the near identical datasheet for that second version is also available: http://www.feeling-tech.com.tw/km-master/front/bin/ptdetail.phtml?Part=M1-05Category=100018 -- 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 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Mauro Carvalho Chehab wrote: On Tue, 07 Apr 2009 23:02:43 -0400 CityK ci...@rogers.com wrote: Regarding the KS003 ( KS007; the other mystery chip): Upon further investigation of some info from a post from last year (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html), it appears that these (assuming that they are the same IC across the various MSI, Leadtek KWorld cards; and I believe that to be true) are the AT8PS54/S56 chip from Feeling Technology ... the datasheet for that part is available through a google search probing further (as I had never heard of FT before and so I looked them up), it looks like FT renamed and/or upgraded the chip to the FM8PS54/S56 ... the near identical datasheet for that second version is also available: http://www.feeling-tech.com.tw/km-master/front/bin/ptdetail.phtml?Part=M1-05Category=100018 From what I've investigated, several of those IR chips are micro-controllers like the one you pointed. I've seen a few boards whose IR chip is not masked. On those, I always went into some micro-controller datasheet. Those IR's with a micro-controller have some software inside it to decode one IR protocol and generate scan-code sequences that can be received via GPIO or via I2C, depending on the firmware content. The datasheet of those chips are useless, since the behaviour of the device is programmed inside their ROM/EEPROM [1]. So, even being the same chip, you could have two K007 devices with different firmwares, listening on different i2c addresses and eventually generating different scan-codes for the same IR. On the other hand, for USB devices and for bttv, saa7134 and cx88, there are some easy ways to monitor what i2c messages or GPIO pins are involved with IR. In general, the IR received messages generated by the firmware are some header, a scan code, a repeat key bit and a trailer. So, it is not hard to generate a get-key routine to get the scan code and the repeat bit from the protocol. That's why the modern ir-kbd-i2c approach is to select the proper IR parameters after binding the module, at the bridge driver. The bridge driver is the one who knows what's the IR scan code of the original IR (to set it as the default), and the proper get-key function. With the new i2c behaviour, the bridge driver can also specify the proper i2c address for each device. Cheers, Mauro [1] It doesn't seem to be practical for me to get their internal software.In general, such micro-controllers block EEPROM/ROM read of the software inside. If this is the case of this chip, the only remaining option to get the internal software would be to cut the plastic and try to see the state of each eeprom bit with the help of a good microscope. Anyway, assuming that there are some way to read the ROM content, in order to see the device behavior, one should remove the chip from the board, get the ROM/EEPROM content, write a disassembler for this processor, disassemble the code and analyse the results. This would be a real hard work, would take a lot of time, and I doubt that this would help to improve the driver, since we already know how to read scan codes from those devices. Thanks for the detailed response Mauro. I've actually been wondering about whether the specific KS00x designation/label might refer to the embedded firmware or to a dataline, so that thought is certainly consistent with your description. -- 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] Leadtek WinFast DTV-1800H support
Miroslav Šustek wrote: Any problem with this patch? I'm trying to get WinFast DTV-1800H support into repository for seven months. (see: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/1125/match=1800h Hi Miro, Its unfortunate that the patch hasn't been added yet, but I do see a problem (in its current form) that explains why it hasn't been picked up. For the sake of thoroughness, here's an audit trail of the entire history: 1) http://linuxtv.org/pipermail/linux-dvb/2008-October/029859.html - Steve picked up some style flaws - (Although it is more desirable to include patches inline as opposed to as attachments, I note that the attached patch is of type text/x-patch, which is fine) 2) http://linuxtv.org/pipermail/linux-dvb/2008-November/030362.html - I noticed your missing SOB - (Again, I note that the attached patch is of type text/x-patch, which is fine) 3) http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/1125/match=1800h - You note in your message that your prior patch didn't get picked up possibly because of the switch of mail lists. That is quite possible, but whatever the case, your patch was, indeed, lost. - Herman responded with some suggestions, as well as noting that your SOB was absent again with the attached patches (though, I know you had resubmitted back in Nov with a SOB) - But here starts the most recent problem: unfortunately, the attached patches where of type application/octet-stream, which the patchwork tool will NOT pick up. Please see: http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches This is a summary explanation of the submitting process (which includes links to several of the documents you've undoubtedly already read) and touches upon attachments. 4) http://www.mail-archive.com/linux-media@vger.kernel.org/msg05856.html - in Hermann's follow up, he correctly notes that the patches never made it onto the patchwork queue (see my explanation directly above for why they were not). 5) http://www.mail-archive.com/linux-media@vger.kernel.org/msg05888.html Nobody noticed the previous post(s). - Ha, I beg to differ! -- at the very least, Steve, myself and Hermann have all spotted your prior patches and have commented. - Unfortunately, the attached patch is again of the type application/octet-stream and will NOT be automatically picked up by patchwork 6) http://www.mail-archive.com/linux-media@vger.kernel.org/msg05890.html (Shoot me! Now it's correct.) - Nope. The attached patch is still a type application/octet-stream, and that is why it is not showing up on the patchwork queue list - I have also just noticed that Trent has also now commented on the patches (so add another to the list!) /End of audit trail I understand your frustration and I don't mean to be bureaucratic (I have zero say in what patches get picked up), but I hope I have shed some light upon what has gone wrong over the last several months. Although I'd rather suspect that Mauro is now well aware of the issue, I'd urge you to resubmit (following the recommendations from the link I provided above) so that it gets picked up and placed upon the patchwork list. -- 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] Linuxtv wiki needs email notification/more email-ready users
Hi Henrik, CityK wrote: H. Langos wrote: ...I'd like to keep an eye on changes. Not because of fear of vandalisim but because changes to the templates/date potentially have effects on a lot of pages. There are some people who day by day put a lot of effort and work into the wiki and I'd like to thank them all for their continuing effort. I myself have only occasionaly time to update information there and I miss a lot of changes, even to the pages I watch, because the watchlist and recent cahnges reaches only seven days back. Manually going through the pages on my watchlist (currently 57) is not what I'd call good use of resources. It would be great if it was possible to get (immediate/daily/weekly?) change notifications by email in order not to lose track of what is happening to the pages that I care about. (I bet this is standard functionality of mediawiki or at least one of the more common extentions.) In searching for something else, I came across this recent thread on the mediawiki m/l: http://lists.wikimedia.org/pipermail/mediawiki-l/2009-October/032214.html There are a few suggestions in it (I just skimmed through). Perhaps one of them would be good to implement. -- 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: i915 graphics driver
wrong list Neil -- try xorg user support: http://lists.freedesktop.org/mailman/listinfo/xorg -- 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: Status of Terratec S7 drivers
Hi Daniele Venzano wrote: Hello, at this URL: http://linux.terratec.de/tv_en.html there is a driver package for the Terratec S7 DVB-S/S2 USB. I'd like to know if they are (1) working no idea, but perhaps someone else knows, or you could try them yourself (slash volunteer to be the guinea pig for everyone else) if you have the hardware and (2) being considered for inclusion in the dvb tree. no idea if anyone at Terratec is working in conjunction with v4l-dvb, or has plans for its inclusion into the kernel ... there may already be such work/plans, but I'm ignorant of such. In any regards, if they are interested, then they should for the following instructions on route to achieving that purpose: http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches -- 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: [Bulk] help on mercurial
Karicheri, Muralidharan wrote: I am trying to learn mercurial for hosting my own hg tree and ended up here :(. Any help will be appreciated. Hi, see the following link, as it has embedded links for what your after: http://www.linuxtv.org/wiki/index.php/Maintaining_Mercurial_(Hg)_trees -- 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: i915 graphics driver
Neil Sikka wrote: hey. isnt this mailing list where the i915 driver was developed? On Wed, Dec 30, 2009 at 4:53 PM, CityK ci...@rogers.com wrote: wrong list Neil -- try xorg user support: http://lists.freedesktop.org/mailman/listinfo/xorg (note: added LMML back in .. use reply all) nope. likely on http://lists.freedesktop.org/archives/intel-gfx/ (or some precursor ... see http://intellinuxgraphics.org/ ). Anyway, xorg or the Intel list would likely serve your purposes -- 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: hue
Hi Carlos, the video4linux mailing list is all but dead and has been superseded by the linux-media mailing list (Lmml). I've cc'ed the Lmml with this reply. Carlos Lavin wrote: hello, I am develop a driver for a sensor of omnivision ov7670 for work only soc-camera subsystem in the version 2.6.30. I have a problem with the hue, when I put the color bars after DSP, the color fo this bars aren't corrects, the hue function are same that the ov7670 mainline. any body know anything about this topic? -- 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: [Bulk] Need Info
Hi, the video4linux mailing list is all but dead and has been superseded by the linux-media mailing list (Lmml). I've cc'ed the Lmml with this reply. linux newbie wrote: Hi, On my embedded PXA255 platform, we have working USB module. ISP1362 is the controller. Recently we want to integrate Microsoft Lifecam Cinema webcam and want to take still images. Linux kernel is 2.6.26.3 and we enabled V4L2 and UVC class drivers. On plugging the Cam and querying the proc and sys file system, I can able to view cam details. I want to capture the frame (preferably in jpeg) and write to a file. Is there any example code for that? I went through the below web page http://v4l2spec.bytesex.org/spec/capture-example.html, but if you can suggest some more example, it will be of great help to me. Thanks -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list -- 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
video4linux-l...@redhat.com
On the video4linux mailing list, Nicolas Riendeau wrote: Mark wrote: what's the right list? This mailing list is essentially dead (I must confess I wonder why they haven't deleted it). Indeed. At this point, its become a community disservice not to have a redirect/pointer to the new list. Is there anyone at Red Hat who can set up an auto reply redirector to the Linux Media Mailing List (http://vger.kernel.org/vger-lists.html#linux-media ) for any new mails set into the v4l mailing list? I don't know how many people are still subscribed to the v4l, but that number is got to be dwindling, and I think its long about past the time that we turn the lights off. -- 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: No video0, /dev/dvb/adapter0 present
Cliffe, Your card does not support analogue, hence there will be no /dev/videoN node created. You are most likely attempting to use analogue tv viewing applications (i.e. xawtv v3.9x, tvtime, ...). Use applications for digital tv instead (i.e. kaffiene). If you go back over the How to Obtain, Build and Install V4L-DVB Device Drivers article, you will find links to two other articles http://www.linuxtv.org/wiki/index.php/What_is_V4L_or_DVB%3F http://www.linuxtv.org/wiki/index.php/Device_nodes_and_character_devices which should provide you with fuller details. -- 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: Pinnacle PCTV DVB-T 70e
Hi Alex, this list is all but dead. Use the linux-media mailing list instead (I have cc'ed my reply to it).in the olden days, the video4linux list was the correct one for analog devices, and linux-dvb for (surprise, surprise) dvb related discussion. Nowadays, they have both been superseded by the linux-media list. Long time I try to run a particular type of device DVB-T, and sometimes I did. The device in question is a Usbstick Pinnacle PCTV DVB-T (70th); is USB, running lsusb we have this eb1a:2870 eMPIA Technology, Inc. Pinnacle PCTV Stick As I said before, once I managed to get it working with both Fedora and Slackware (the Linux distributions that I use routinely). Did not work with the drivers on the kernel (em28xx, em28xx-dvb); the traditional driver try to recognize the device, but doesn't work. The device works only (and very well) with a version made by some individuals, called em28xx-new. There is a version of these drivers, compile manually, but it works only until kernel 2.6.31 ( http://launchpadlibrarian.net/35049921/em28xx-new.tar.gz ) He stopped supporting his driver and now only works on closed source software. Searching the internet I saw that many users are trying to work this board (very common). Is there a way to incorporate the changes mentioned in the official driver? No. Or, you can suggest how they might be modified drivers indicated to work with recent kernels (2.6.32, and soon 2.6.33 or later)? The person in question, unfortunately and needlessly, came to an impasse with the v4l-dvb project. He later stopped developing his work. And no one here is much interested in touching his with a hundred and ten foot pole. You can, however, look to see if you can add support for your device to the existing v4l-dvb kernel driver. There are several developers that are knowledgeable of the em28xx driver, and whom may be able to help you in that regard, but you will have to gain there attention first. -- 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: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?
Another Sillyname wrote: Guys The TBS 6920 PCI-e card is in the Wiki and is a supported card. The TBS 6980 dual tuner PCI-e card is not in the Wiki at all, is there a reason for this given they have released a non GPL blob at least? Because the wiki relies upon user contributions. No contributions, no information. Simple as that. Also is there a reason that an indicative price for supported cards is not shown in the wiki? It would save a load of time rather then having to search on each card only to find out it's ridiculously priced at $1000. I for one am not particularly keen on inclusion of prices because: - prices are highly subject to temporal variance (i.e. what costs $150 now could be $80 in six months) - prices are often highly variant across broad geographical regions (i.e. what costs $70US in America could, after accounting for exchange rates, cost an equivalent of $100US within Canada) - prices are often highly variant within local geographical markets (i.e what costs $99 at the local big box Bestbuy store could easily cost $79 at the local mompop computer store) - prices require regular updating/maintenance in order for them to be in any way indicative ... the wiki relies upon user contributions ... ergo, I can already tell you in advance that its not going to happen (because its a time consuming endeavour, and there is no critical mass of contributors to keep the information relevant), and so, any original submissions will inevitably just end up suffering information rot (and, thus, end up not being indicative or of particular use for the end user). -- 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
a short video that developers will likely enjoy
The following is a link to an approx. 11min video. The connection pt. to what you are doing here comes in it in around the 8 min mark, so bear with it (though I highly doubt it will be in any way insufferable). I hope you enjoy this little diversion (I think most will). http://www.youtube.com/watch?v=u6XAPnuFjJc -- 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: is the list down?
Jed wrote: nope got that, but not getting other people's emails. weird. Maybe its amnesia? http://www.mail-archive.com/linux-media@vger.kernel.org/msg19011.html I'm unsubscribing from this list... -- 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: DNTV Dual Hybrid (7164) PCIe
Martin Brown wrote: I'm trying to get a driver working for this card under Ubuntu Lucid (10.04). I believe the card is based on the SAA7164 so I'm trying the kernellabs driver. Results of modprobe saa7164 are: /etc/modprobe.d/options.conf contains: options saa7164 card=4 kernel: [ 159.091047] saa7164 driver loaded kernel: [ 159.091102] saa7164 :04:00.0: PCI INT A - GSI 18 (level, low) - IRQ 18 kernel: [ 159.091974] CORE saa7164[0]: subsystem: 107d:6f2c, board: Hauppauge WinTV-HVR2200 [card=4,insmod option] kernel: [ 159.091980] saa7164[0]/0: found at :04:00.0, rev: 129, irq: 18, latency: 0, mmio: 0x9300 kernel: [ 159.135163] tveeprom 0-: Encountered bad packet header [00]. Corrupt or not a Hauppauge eeprom. kernel: [ 159.135168] saa7164[0]: Hauppauge eeprom: model=0 That's it. Nothing more. No /dev/dvb/adpator... created. When /etc/modprobe.conf has: options saa7164 card=5 I get: kernel: [ 547.123384] saa7164 driver loaded kernel: [ 547.123435] saa7164 :04:00.0: PCI INT A - GSI 18 (level, low) - IRQ 18 kernel: [ 547.123614] CORE saa7164[0]: subsystem: 107d:6f2c, board: Hauppauge WinTV-HVR2200 [card=5,insmod option] kernel: [ 547.123619] saa7164[0]/0: found at :04:00.0, rev: 129, irq: 18, latency: 0, mmio: 0x9300 kernel: [ 547.160228] tveeprom 0-: Encountered bad packet header [ff]. Corrupt or not a Hauppauge eeprom. kernel: [ 547.160233] saa7164[0]: Hauppauge eeprom: model=0 kernel: [ 547.207655] tda18271 1-0060: creating new instance kernel: [ 547.211800] TDA18271HD/C2 detected @ 1-0060 kernel: [ 547.469221] DVB: registering new adapter (saa7164) kernel: [ 547.469226] DVB: registering adapter 2 frontend 0 (NXP TDA10048HN DVB-T)... But only one /dev/dvb/adaptor created instead of 2 and I suspect the tveeprom error is fatal. Does anyone have any suggestions? Thanks, Martin -- 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 Read the topmost note of: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Is your device in any way related to those two iterations of the Hauppauge HVR-2200 model? (http://linuxtv.org/hg/v4l-dvb/file/304cfde05b3f/linux/Documentation/video4linux/CARDLIST.saa7164) -- 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: [Bulk] v4l-dvb bug report
Holy cow -- Ubuntu is still borked in regards to the firedtv stuff ?! What is that - something like 4 releases in a row now? Anyway, well known problem, have a look here: http://www.mail-archive.com/search?q=firedtv+Ubuntul=linux-media%40vger.kernel.org first link will give you the easy fix to your compilation/build problem. -- 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: [Bulk] Re: v4l-dvb bug report
matteo sisti sette wrote: Yeah, thank you, I have found the FIREDTV=n trick on some other forum just a few minutes before I read your reply, and with that change it has compiled fine :) oops, I just sent my reply before I saw that you already figured it out I'm not sure what firedtv is but I don't think I need it :) its a driver for some firewire based DVB devices ... you won't need it. By the way may I ask a newbie question? If you need the kernel sources to compile v4l-dvb, it does not mean that you're recompiling the kernel, does it? :$ that's correct ... all you are doing is building the v4l-dvb drivers against your specific kernel ... after building them, you can then install them, which effectively replaces the kernel supplied set of v4l-dvb drivers with the set you just compiled/built -- 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] OnAir creator seems to be recognized, but what device is what?
A. F. Cano wrote: Dvbusb2 seems to recognize the device ok. In fact it seems to create /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/net0 And I also see /dev/video0 But what do those devices represent? Is /dev/video0 the analog tuner? is /dev/dvb/adapter0/dvr0 the digital tuner? What are the others? When a driver module loads, the device manager udev will create device nodes on /dev. For dvb devices you get the character devices under /dev/dvb/adapterN (where N = 0 to whatever). The character devices for each adapter N are enumerated in form of M=0 to whatever. For example: /dev/dvb/adapter0/frontend0 if the same device had a second frontend, that character device would be enumerated by /dev/dvb/adapter0/frontend1 ... if you had another dvb adapter in the system, then you would see /dev/dvb/adapter1/frontend0 and so forth. * The frontend device controls the tuner and demodulator. * The demux controls the filters for processing the transport stream (TS). * the dvr is a logical device that is associated with the demux character device ... it delivers up the TS for either: (1) immediate playback --- in which case it has to be decoded either: a) on the device itself [its rare for PC devices to have hardware decoding, but not so for STB] or b) downstream by the system [the usual route for PC devices -- i.e. software decoding via the host CPU, and possibly assisted by the GPU) ] or (2) saving to disk for later playback. * the net character device controls IP-over-DVB Similarly, with video capture (or, if you prefer, V4L) devices, you get the /dev/video device node and the videoN character devices. For more info, have a look at the DVB and V4L APIs. I have been trying to configure mythtv but have no idea what to tell it about this device. The mythtv docs say that if you have a card with 2 tuners, define it as a DVB. But, mythtv-setup identifies it correcly (by name) as an analog card /dev/video0, if I set it up as a DVB it claims it is a DVICO or Air2PC or... It does not seem to know about the /dev/dvb devices. Do I need to configure the OnAir Creator as 1 or 2 device ... I have posted the higher level questions to the mythtv mailing list, but no answers yet. Any hints would be welcome. Sorry, no input on the myth specific questions, though surely someone else might be able to. Can someone tell me a quick and easy way to test the device? maybe with mplayer? I have an analog camera connected to the composite input, so even if I don't get any channels with the rabbit ears and loop antenna, that should work as a test. See the wiki -- in particular, in the User Section, see the testing your DVB device article. Also see the MPlayer article. -- 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] Pinnacle dual Hybrid pro PCI-express - linuxTV!
Catimimi wrote: Hi, As I didn't yet subscribe to the list, I reply directly to your discussion with Romain sorry, I don't recall it offhand. in ordezr to send you the result of : lspci -vvxxx for the Pinnacle PCTV Dual Hybrid Pro PCI Express (3010i) __ 04:00.0 Multimedia controller: Philips Semiconductors Device 7162 Subsystem: Pinnacle Systems Inc. Device 0100 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 5 Region 0: Memory at dde0 (64-bit, non-prefetchable) [size=1M] Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Queue=0/5 Enable- Address: Data: Capabilities: [50] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 256ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 4us, L1 64us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [74] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Vendor Specific Information ? 00: 31 11 62 71 07 00 10 00 00 00 80 04 04 00 00 00 10: 04 00 e0 dd 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 bd 11 00 01 30: 00 00 00 00 40 00 00 00 00 00 00 00 05 01 00 00 40: 05 50 8a 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 10 74 01 00 80 00 28 00 10 00 0a 00 11 6c 03 01 60: 08 00 11 00 00 0a 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 01 80 02 3e 00 00 00 00 00 00 00 00 80: 09 00 50 00 03 0c 00 00 02 02 00 00 00 00 00 00 90: 00 04 00 00 00 00 00 08 00 00 10 00 00 00 00 00 a0: 01 00 00 04 03 18 00 00 00 00 01 04 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 20 01 2a 00 00 c0: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I hope it'll help. Could you put it in the wiki if its not already contained there. Thanks. I tried the driver found here : http://jusst.de/hg/saa716x It compiles and install, but if I try : modprobe saa716x_hybrid.ko I get a fatal error : module not found. I can't find any message in dmesg. try without the .ko, i.e. instead, use: modprobe saa716x_hybrid Ready for further trials. 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: KWorld ATSC 115 all static
Hans Verkuil wrote: OK, I couldn't help myself and went ahead and tested it. It seems fine, so please test my tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134 Let me know if it works. Hi Hans, It didn't work. No analog reception on either RF input. (as Mauro noted, DVB is unaffected; it still works). dmesg output looks right: tuner-simple 1-0061: creating new instance tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in) I tried backing out of the modules and then reloading them, but no change. (including after fresh build or after rebooting) -- 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: eMPIA camera support?
hermann pitton wrote: Am Sonntag, den 28.12.2008, 21:54 -0500 schrieb CityK: hermann pitton wrote: schrieb CityK: While the bttv gallery remains a very useful resource, I don't believe that Gunther is maintaining it any more. In any regard let s use the V4L-DVB wiki (http://www.linuxtv.org/wiki/index.php/Main_Page), as it is best to keep the information all in one place (i.e. a centralized repository of knowledge and information), as opposed to spread out across multiple 3rd party sources. let's see. It still has lots of advantages. Hacking of hundreds of tuners and advanced gpio and eeprom detection was coordinated there on requests for research coming up on the lists and it has several thousand contributors. A wiki was not even in sight then. I would prefer to see it further maintained for easy searching on hard facts. At least don't call it third party. That is as mad as if you would call the video4linux-list or bytesex.org third party. It is/was to that point the official hardware resource and Gunther a leading tuner/hardware developer and nothing else. This is true, and I don't mean to offend anyone's sensibilities about it. Likewise, I did state that it remains a very useful resource. However, I haven't seen a word of boo from Gunther in probably two years time. Secondly, some of those users that I had, in the past, requested that they submit material to the bttv-gallery have later written/replied to me that their submissions went unanswered/unacknowledged. Thirdly, despite Gunther's distinguished history and involvement, it is likely unclear to an unassuming end user that there is anything other then a passing relation between the project and the bttv-gallery. That is all OK so far. But it is not about sensibilities, but usability in the first place. Your points are duly noted ... and I have attempted to convey the crux of your message in the note provided here: http://www.linuxtv.org/wiki/index.php/Development:_How_to_add_support_for_a_device#Don.27t_forget_to_send_info_to_the_Wiki_.21 I give an example in short. http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards This starts with some ASUS My Cinema P7131-Dual model and the photos are taken from there. But that user had a P7131 Hybrid and he was the only one ever reporting problems like this, DVB, VDR, (***unstable*** causes random memory corruption and crashes), but stays on top of all recent PCI cards with hybrid tuners and speaks for all Asus saa713x ... This should be meanwhile eight different cards including the not yet externally documented Asus Tiger 3in1 I guess. It of cause continues here. http://linuxtv.org/wiki/index.php/ASUS_My_Cinema-P7131_Hybrid Almost all is wrong or at least not differentiated enough. If you look at the bttv-gallery for the related cards, there is at least _nothing_ wrong. Well, in these particular regards, I can only reply with what I have previously noted in the wiki in several places, such as: - from the Main page welcome message: Like all other wikis, the V4L-DVB wiki relies upon the contributions of its users. Hence, it will only be as useful as we make it! - from the DVB-T PCI Cards' note entitled Please be aware that: The information contained here is likely non-exhaustive and, despite best efforts to do otherwise, may contain errors. (Please help to keep these lists up-to-date so that they are useful for everyone!) -- 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: KWorld ATSC 115 all static
Hans Verkuil wrote: is your board suppossed to have a tda9887 as well? Hi Hans, Yes, indeed, the device does contain the tda9887. Hans' changes are not enough to fix the ATSC115 issue. Ah, OK. I believe that if you can confirm that the same problem exists, but the previous workaround continues to work even after Hans' changes, then I believe that confirms that Hans' changes Do the Right Thing (tm). err, I'm afraid I might be reading to much into your statement Michael --- if you meant to question whether, after building Hans' changes, a modprobe tuner -r and modprobe tuner worked, then the answer is no, such did not work. (no results in dmesg are observed either, much like what was discussed later; specifically: we are no longer able to remove the tuner module and modprobe it again -- the second modprobe will not allow for an attach, as there will be no way for the module to be recognized If you had meant taking Hans' source and applying your hack patch to them, building and then proceeding with the modprobe steps, the answer is that I haven't tried yet. Will test -- might not be tonight though, as I have some other things that need attending too. Anyway, if the previous workaround works after Hans' changes, then I think his changes should be merged -- even though it doesnt fix ATSC115, it is indeed a step into the right direction. If the ATSC115 hack-fix patch doesn't apply anymore, please let me know -- I'll respin it. Given this statement, then perhaps it was a case of the latter. As mentioned, I will rebuild and test. Hans, given the discussion that is developed, I don't think the dmesg output is necessary at this point (if you really insist though I will provide :P ). P.S. I think Trent's idea sounds interesting/warrants some consideration. -- 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] Pinnacle dual Hybrid pro PCI-express - linuxTV!
Catimimi wrote: CityK a écrit : Could you put it in the wiki if its not already contained there. Thanks. It was done yesterday. Yep, saw that about 10 minutes later after I responded to this message :P . 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
[PATCH] Siano 10226 Siano sub-system
Uri Shkolnik wrote: Where can I find checklist for that? (coding style and checkpatch.pl are for the source code itself. Which document that covers this?) In addition to the info Trent provided, if you haven't already found it, there are a couple of documents in /usr/src/linux/Documentation that are worthwhile skimming through. We have repeated them here in the wiki, under the development section: - http://www.linuxtv.org/wiki/index.php/Development:_Coding_Style - http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches - http://www.linuxtv.org/wiki/index.php/Development:_Linux_Kernel_patch_submittal_checklist - http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Drivers As well as providing our own brief notice: - http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches -- 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 1/4] em28xx: Fix audio URB transfer buffer memory leak and race condition/corruption of capture pointer
Hi Robert, I don't know if you're aware, but we've recently switched mailing lists for which patches should be submitted (see Mauro's note: http://www.linuxtv.org/news.php?entry=2009-01-06.mchehab) ... I've been busy trying to update the likes of articles such as http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches that may have still contained instructions/links to the older mailing lists. Sorry for the inconvenience. Unless Mauro, or a driver maintainer has already picked them up, please resend them to the new list. -- 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: KWorld ATSC 115 all static
Hans Verkuil wrote: On Sunday 18 January 2009 22:20:30 CityK wrote: The output of dmesg is interesting (two times tuner simple initiating): Shouldn't there be a tda9887 as well? It's what the card config says, but I'm not sure whether that is correct. Would you like to see the results of after enabling 12c_scan to see what is going on, or is this the behaviour you expected? It seems to be OK, although I find it a bit peculiar that the tuner type is set twice. Or does that have to do with it being a hybrid tuner, perhaps? The Philips TUV1236D NIM does indeed use a tda9887 (I know, because I was the one who discovered this some four years ago (pats self on head)). But the module is not loading. I can make it load, just as Hermann demonstrated to Mike in one of the recent messages for this thread. In regards to the tuner type being set twice, that is precisely my point -- its peculiar and not symptomatic of normal behaviour. That is why I asked whether you expected it to do this Some Other Miscellanea: 1) Before this gets merged, can I ask you to also make one small change to tuner-simple; specifically, swap the contents of lines 301 and 304. This will change the driver's default behaviour in regards to the selection of which RF input to use for digital cable and digital over-the-air. Currently, the driver is set to use digital OTA on the top RF input and digital cable on the lower RF input spigot. However, IMO, a more logical/convenient configuration is to have the digital cable input be handled by the top RF input spigot, as this is the same one that the analog cable is also drawn from by default. Mike had made this change, on my request, previously, but it appears that it got reverted after the tuner re-factoring. Note: users have reported different default configurations in the past (e.g. http://www.mythtv.org/wiki/Kworld_ATSC_110), but I actually doubt that there has been any manufacturing difference with the TUV1236D. Rather, I suspect that the user experiences being reported are just reflecting a combination of the different states of how our driver behaved in the past and differences in driver version that they may have been using (i.e. that version provided by/within their distro or by our Hg). After all, this configuration setting has gone from being handled by saa7134-dvb.c to dvb-pll.c to tuner-simple.c, with changes in the behaviour implemented along the way. I'm not going to merge this, it's just a quick hack for this card. This is something for Mike or Hermann to fix. Fair enough -- I will pester them a la Bart Simpson spy camera style (see: http://peanutbutterandpickles.blogspot.com/2008/06/wheres-my-spy-camera-wheres-my-spy.html and for actual dialogue: http://www.snpp.com/episodes/7G10.html) :P It is a trivial change which I can vouch that works (after successfully testing your new KWorld changeset, I immediately applied this change and rebuilt ... with, of course, successful results). Someone with a better knowledge of this driver and these tuners should review the saa7134_board_init2() function and move the opening of tuner gate/muxes to a separate function. 2) This is likely related to the discussion about the gate -- after closing the analog TV app, the audio from the last channel being viewed can still be heard if one turns up the volume on their system. This leakage has always been present. But given that we are addressing this issue now, it strikes me that the gate is being kept open on the audio line after application closing/release occurs. I just did some testing in regards to point number 2 ... at first I was thinking that maybe it was because tda9887 is not loading automatically that, absent of fine control, the audio leakage was occurring. But after loading tda9887 and then removing the module, the leakage continues. Naturally, the other suspect is saa7134. And, as it turns out, if one modprobe -r saa7134-dvb (which obviously uses sa7134), then the audio leakage immediately comes to an end, and checking lsmod, saa7134 is no longer found. So at least I know the source of the bug now ... now its just a case of getting it to release properly. Comments from anyone on this? 3) there is an issue about having two of these cards in the same system --- IIRC, only one card will get /dev/video Mauro touched upon this very briefly in one of the earlier messages; recall: Mauro wrote: This generated lots of issues in the past, like machines with two boards doesn't work anymore. With two boards, and a tuner module, the first board probes tuner after opening the demod gateway. However, the second board will try to probe tuner before opening the i2c gateway. So, tuner is not found. Now, I can't test for this myself, but I do know of several users on AVSforums who have two such cards and can test if that issue is now resolved do you suspect
Re: Analog TV on Leadtek PxDVR 3200 H
Martin Edlman wrote: Hello, I have a problem with module cx23885, it doesn't create the /dev/video0 device. The module doesn't support analogue yet. -- 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: KWorld ATSC 115 all static
CityK wrote: Hans wrote: CityK wrote: In regards to the tuner type being set twice, that is precisely my point -- its peculiar and not symptomatic of normal behaviour. That is why I asked whether you expected it to do this I think it is OK. The second setup is probably done by dvb_attach() in saa7134-dvb.c, line 1191. Can you verify that with a debug message? Could not verify. (dmesg output provided below at end). Actually, looking at the dmesg output now, it is apparent that you are correct: dvb_init() allocating 1 frontend So, its a case of a bit of redundancy now. -- 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] Tuning a pvrusb2 device. Every attempt has failed.
A. F. Cano wrote: Yes. The RF input is hooked up to an 11ft Winegard roof antenna, mounted on a stand behind me, properly oriented according to antennaweb.com for the local stations, and with a UHF pre-amp for good measure. It is inside, but a foot below the reasonably high ceiling, so it doesn't interfere with moving around. With this setup I have succeeded in receiving barely visible analog channels when the Creator is set up as a v4l device using /dev/video0. Yes, the reception sucks, but I want to make sure that it is not something more fundamental before I go to the trouble of mounting the antenna on the roof. Okay. One suggestion I have here is taking the pre-amp out of the chain right now, and just test with as basic a setup as possible. I'm not sure how to change the cable vs. ota setting. Doesn't the digital tuner determine what it is plugged into? Sorry, what I was getting at was the case of user error where one might be trying to use 8VSB for the scanning on a digital cable connection, as opposed to using the correct modulation scheme (QAM256). So, for example, using scan in conjunction with us-ATSC-center-frequencies-8VSB as opposed to us-Cable-Standard-center-frequencies-QAM256. Had that been the case, it could explain the results you observed with scan. However, as you confirmed above, that was not the case. In regards to the determination of what is plugged in -- no, the tuner is a dumb component. It only does what its told. In other words, whatever piece of software you are trying to drive it by has to state that it wants the device to use cable or OTA; as precisely illustrated by the example with the scan utility. As far as mythtv, it thinks the attached device is a DVB/DTV receiver. I'd step back from testing with Myth right now -- it adds to much of extra layer of complexity and sources for further error. In terms of just testing to make sure that the device is working correctly, just stick with the basic apps for the time being (scan, azap, mplayer, femon) Kaffeine has been told to use the us ATSC frequencies, with the results I pointed out earlier. I haven't taken the opportunity to ever use Kaffeine for scanning OTA just yet, however, I do note that it produces similar results for me, as to what you observed, when I scan on digital cable using QAM256. In my case, it repeatedly borks at 61%. I spoke with Mkrufky this morning about Kaffeine's ATSC scanning abilities and he described it as being less then favourablethis was actually a surprise to me, as I thought that OTA scanning was fine. I know Devin added this support so perhaps he could comment upon the capabilities. I also know that Devin does not have cable, so I am not surprised to see, in my case, scans of digital cable failing. Reviewing your prior message, I'd suspect that dvbtune just doesn't have support for ATSC. As you note, the other stuff is for analog. The fact that you have the device node created and the populated by the character devices, along with the femon result is encouraging. Similarly, that scan is detecting something on several frequencies (just not enough to capture any info for it) is also encouraging. I suspect that it comes down to a case of the antenna/cable configuration ... as noted before, take the amp out of the chain and retry ... also, if possible, can you obtain a signal under Windows? -- 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: KWorld ATSC 115 all static
hermann pitton wrote: Am Sonntag, den 25.01.2009, 13:49 -0800 schrieb Trent Piepho: On Sun, 25 Jan 2009, CityK wrote: Hans Verkuil wrote: this still begs Han's question: how do you manage to make analog TV work if the tda9887 isn't found? That's rather peculiar. I don't have an answer for that. The tuner-simple module, however, seems to be able to drive/provide that functionality sufficiently enough. The tda9887 is a simple device with just three registers. If they are set to the right value when the driver loads, which wouldn't be unexpected, then it isn't necessary to actually do anything to the chip. If you had a multistandard tuner (and had access to broadcasts in multiple standards!) then I expect switching standards wouldn't work without the tda9887 driver. Verifying both TV and radio tuning works is probably the most realistic way to check. For radio you need a tda9887 and working i2c for what i can know. Also after a cold boot the tda988x is not in a usable state for any tv standard yet, it needs to be set by i2c first. But for NTSC, and only NTSC, one pin can be strapped, IIRC, and then it works without any i2c programming needed. Guess it is a tda9885 here. Looks like that this is the case, as described by Trent, that is occurring. Herman, is there any difference between the tda9885 and tda887, as I'm pretty sure this is the tda9887 package outlined on page 52 of the tda9887 datasheet. Alas, as being exposed to just NTSC broadcasts, not able to test on the multistandard ;) As for the FM radio, I know that some have mentioned the possibility for that with this device, but I don't think anyone ever has succeeded (not surprising given the i2c situation) and so the assumption was made, rightly or wrongly, that it is not present. I would be amused if FM radio support could be realised for the device. saa7133[1]: i2c xfer: c2 30 90 saa7134[3]: i2c xfer: c2 saa7134[3]: i2c xfer: c2 0b dc 9c 60 saa7134[3]: i2c xfer: c2 0b dc 86 54 Exactly here, when the buffers are sent the second time the tda9887 becomes the first time visible on the bus. According to Hartmut the modification of buffer[3] from 0x60 to 0x54 is that hidden switch, IIRC. I believe Mauro is correct in regards to the tda9887 in that, within the Philips TUV1236D NIM, it is behind the Nxt2004's i2c gate. After re-reading what Michael mentioned previously: Address 0xc2 is the PLL, not the NXT2004. Why would the PLL control an I2C gate on the nxt2004? I think what I said before about a gpio line on the PLL being used to hold the analog demod in reset when not in use is more likely to be correct. That the analog demod is enabled from the pll in case of the FMD1216ME MK3 hybrid is what Hartmut told us. To remeber, the Pinnacle 300i hybrid with mt32xx (3250) disables the analog demod with tda9887 port2=0 in digital mode. That is why Gerd re-enables it on exit of DVB. The i2c command to enable the tuner is sent to nxt200x. If there are any ATSC110 variant with a different demod (maybe a different version of nxt200x?), then the users may experience different behaviors. That command sequence is sent to the PLL, not the nxt2004, so this is wrong. There is another command sent to the nxt2004 (which is at address 0x0a) from code in saa7134-cards.c to enables tuner as well. -- 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: KWorld ATSC 115 all static
CityK wrote: Hans Verkuil wrote: I've made a new tree http://linuxtv.org/hg/~hverkuil/v4l-dvb-kworld/ that calls 'enables the tuner' before loading the module. See if that works. ... I suspect that this might fix the bug. Hans, ... it works !! I may have found a problem (tvtime works perfectly; other analogue apps like xawtv/motv, kdetv ... are not working properly now -- you can do a channel scan with them and everything_appears_to work as expected (i.e. channels are found and are displayed/played correctly during the scan), BUT as soon as you actually go to use the app, it does not work (static). It appears that the issue is related to dga and Xv (as passing the -nodga -noxv options with xawtv/motv actually works ... kdetv is hit and miss -- sometimes the v4l1 mode works, other times it doesn't (likely a pattern there but haven't found it yet), but v4l2 plugin does NOT work at all (static)). In addition, the nvidia driver is NOT the source of the error, as the same occurs under the nv driver as well. Will have to do another test to confirm whether this error was introduced in the KWorld repo. Consequently: Mauro Carvalho Chehab wrote: Hans Verkuil wrote: Note that Mauro merged my saa7134 changes, so these are now in the master repository. Yes. We need to fix it asap, to avoid regressions. It is time to review also the other codes that are touching on i2c gates at _init2(). Thoughts on merging the changes from Hans' KWorld repo? If there were any thoughts on this, please put them on hold until I can test further. -- 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: KWorld ATSC 115 all static
David Engel wrote: I never received received anythin after Jan. 18 and couldn't find anything in the archives. Strange. hermann pitton wrote: Am Dienstag, den 03.02.2009, 01:03 -0500 schrieb CityK: - On Sunday Jan 25th I sent a lengthy message to the list... I went to the mailing list archive to find a link for my message...only to discover it was NEVER achieved/recordedgr. So I'm at a complete loss as to who actually saw the Jan 25th message and who didn't. On Jan. 18 the copy to the video4linux-list was dropped. Some mailers by default have a limit there and the number of recipients must be increased manually, i don't think it was intentionally. However, all on linux-media should have received your postings and they are in the archives. http://www.spinics.net/lists/linux-media/msg00817.html LOL -- that's hilarious; I had checked both http://www.mail-archive.com/linux-media@vger.kernel.org/thrd5.html#01125 and http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/203/focus=42489 and couldn't find it, so I didn't bother looking for it on spinics. (Personally, I prefer neither of the 3 above archives, rather, I like Marc, which I don't believe we've contacted yet ... I will bug Mauro about this in a minute). I had figured that it might have been a limitation with the message size. Anyway, good to know that the Jan 25th message made its way to at least one archive. - Further, somewhat concurrently, I discovered that (with Hans' kworld test repo) analog TV was ONLY working with tvtime ... xawtv/motv and kdetv were borked (I don't use Myth, so I have no idea what its status would be ... though, I'd suspect that it works like tvtime). I will try it with MythTV. Thanks David. -- 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: KWorld ATSC 115 all static
hermann pitton wrote: Am Dienstag, den 03.02.2009, 01:03 -0500 schrieb CityK: - Mauro created a patch intended to be applied against mainline ... I tested and analog tv did NOT work strange, that we don't see at least some error messages. Indeed, on a quick glance, the output looks entirely indifferent hermann pitton wrote: I had a quick test on the in kernel radeon driver on Fedora 10 and recent 2.6.27 with xawtv-3.95. True is, that overlay-preview yields dga is not supported, but with current v4l-dvb master and Hans' conversions mmap/grabdisplay works with the old xawtv -v 1 -nodga -remote -c /dev/video2 something. Yep, as I menitoned: http://www.mail-archive.com/linux-media@vger.kernel.org/msg00989.html. In regards the hit and miss functionality I mentioned with kdetv, the pattern was simple: grabdisplay v4l1 mode would work only after having just used tvtime. Similarly, in the v4l2 mode, after having just used tvtime, one can observe a momentary flicker of video (i.e. lasting only a few hundredths of a second) from a channel before it reverted to all static. Additionally, when the apps fail in overlay mode, and are displaying all static, you can actually simultaneously open up one of the digital apps (take your pick; kaffeine, MPlayer...) and successfully watch dvb. hermann pitton wrote: Like you, I can't imagine that the earlier Kworld ATSC 110/15 initialization in Hans' kworld repo could be related to it. No, no -- Mauro doubts it. I, on the other hand, suspect that there has been something innocuous introduced within the new v4l2 framework that is causing this. hermann pitton wrote: I can test on nv drivers as well next, they might have dropped support for it too and just the x capabilies should be reported. Nope -- as I mentioned, dropping back to a snapshot from roughly 3 weeks ago and applying Mike's patch works with both the nv and nvidia driver, hence disproving that it is anything X related. - Mainline v4l-dvb: Pros: none ... you will achieve this thread's namesake -- all static. Cons: since the code from Hans' v4l-dvb-saa7134 repo was merged, Mike's hack/workaround patch has been rendered ineffective for good. Mauro's later patch was also pulled into mainline, but it does not change the situation analog tv (and I do not mean in relation to Mike's patch, I mean precisely upon its own). - Mike's hack/workaround patch Pros: it will apply and work with snapshots of v4l-dvb up to probably ~ Jan 15th or so. All the apps that I tested with work as expected. Cons: in order to use analog tv, upon each boot, one must do what I termed being a dance with unloading and reloading the tuner module via modprobe. I'm not sure if we even have the status of all devices potentially seeing impacts, but reloading modules becomes more difficult, since we load now saa7134-alsa by default. This will cause that apps like mixers on runlevel 5 need to be closed before you can unload/reload saa7134-alsa and saa7134 and then further any tuner modules. This is fine for all the cards without such problems, but else one must be aware off. With options saa7134 alsa=0 the old behaviour is restored. Mauro also disabled saa7134-alsa support on saa7130 devices, which simply do not support it and the deprecated saa7134-oss. Thanks! And speaking of alsa: CityK wrote (Jan 19th): Some Other Miscellanea: 2) This is likely related to the discussion about the gate -- after closing the analog TV app, the audio from the last channel being viewed can still be heard if one turns up the volume on their system. This leakage has always been present. But given that we are addressing this issue now, it strikes me that the gate is being kept open on the audio line after application closing/release occurs. This issue seems to have been resolved since having updated to the ALSA 1.0.19 release from a couple of weeks ago (which literally contained a zillion fixes, so I'm not going to bother trying to figure out which one might have been the fix).. -- 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: [ANNOUNCE] V4L, DVB and Maintainers Mailing Lists at vger.kernel.org
Mauro Carvalho Chehab wrote: There are a few archives already available, at: * http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure * http://www.spinics.net/lists/linux-media/ * http://www.mail-archive.com/linux-media@vger.kernel.org Hi Mauro, when you get a free moment, can you have MARC added to the list of archive sites: http://marc.info/?q=about#Add 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: firmware
Michele wrote: Hi, I'm new here and i'm trying TM6061 driver from your repo. Actually I'm now able to make the module tm6000 and I find my card (wintv-hvr-900h) as card 9. But when today for the first time my gentoo system recognize it I discovered that I need a firmware called xc3028L-v36.fw. I searched a while over the net and it seems to be in vendor CD but it isn't, even downloading drivers from webpage I find a sys file but it is not tridvid.sys, it is called hcw66xxx.sys (and also it seems to be a 64bit version called hcw66x64.sys). I tried both of them but nothing happend, I also try to find that file over internet but everytime file checks fail. Someone have some suggestion about where to find it? Follow the rabbit: http://www.linuxtv.org/wiki/index.php/Firmware -- 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: firmware
Devin Heitmueller wrote: CityK, That actually wasn't a very helpful link you sent ... the page on the XC3028 and XC2028 pointed to on that page makes no reference to getting the firmware for the low power version of the chip. Michele, You can get the firmware here: http://steventoth.net/linux/hvr1400/xc3028L-v36.fw My apologies, I first off, didn't notice the low power chip, and, in any regard, even if I had, I was under the impression that it was documented there. I will amend that shortly. Devin Heitmueller wrote: On Sun, Feb 15, 2009 at 3:38 PM, CityK ci...@rogers.com wrote: Michele wrote: my gentoo system ... I need a firmware called xc3028L-v36.fw Follow the rabbit: http://www.linuxtv.org/wiki/index.php/Firmware CityK, That actually wasn't a very helpful link you sent ... The user would have to know he has a Xceive 3028L tuner, and even if he had been able to figure that out, I would hope that someone using Gentoo (hardly a hands off distro) would be sharp enough to know how to follow the rabbit down the hole ... although I'd advise that they avoid sipping from any vessel labelled with the words Drink Me -- 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: Sony PlayTV (PS3)
Vigasoco SDL wrote: Quick and dirty patch por Sony PlayTV (Playstation 3 DVB-T) Hi, please see http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches -- 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] A dvb-core code problem
Zhang Xiaobing wrote: I found a code problem in dvb-core when I was debugging with my dvb driver. The code in dvb_dvr_release() file dmxdev.c /* TODO */ dvbdev-users--; if(*dvbdev-users== -1* dmxdev-exit==1) { fops_put(file-f_op); file-f_op = NULL; mutex_unlock(dmxdev-mutex); dvbdev-users== -1 should be changed to dvbdev-users== 1, otherwise driver may block forever in dvb_dmxdev_release() where a wakeup condition is dvbdev-users== 1. Here is the code in dvb_dmxdev_release(). if (dmxdev-dvr_dvbdev-users 1) { wait_event(dmxdev-dvr_dvbdev-wait_queue, *dmxdev-dvr_dvbdev-users==1*); } I hope it is right to post this message here. Hi Zhang, could you post a patch to the linux-media mail list; for general info see here: http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches -- 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: New v4l2 driver for atmel boards
Sedji Gaouaou wrote: Hi everybody, I am writing here to know if it is the proper place to send a driver that I have written for atmel's boards. I would like to know as well if there is a git tree against which I should based my patch or should I based it against the latest rc? Hello, here's an overview for submissions: http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches -- 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] V4L: Storage class should be before const qualifier
Jiri Kosina wrote: On Mon, 16 Feb 2009, CityK wrote: [inline patch] This doesn't seem to be picked by anyone for current -next/-mmotm, I have applied it to trivial tree. Thanks, Will this create any complication? As it is indeed queued in our patchwork: http://patchwork.kernel.org/project/linux-media/list/ Hmm, patchwork ... did this land in any actual code tree? It has been submitted by Tobias on 9th Feb and I was not able to find it in any tree today, so I applied to to trivial tree (to which the patch has been originally CCed). If you guys actually have queued in some tree, please let me know and I will drop it. I'll defer to Mauro for the absolutes, but it looks like it got applied to V4L-DVB mainline Hg yesterday and is in Mauro's Linux-next git. -- 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: PVR x50 corrupts ATSC 115 streams
Steven Toth wrote: Agreed, probably a secondary issue - which probably needs some attention regardless. I don't follow kworld products so I don't pretend to know which demod they're using. I guess my question to the wider audience is, do people with this same demod on other cards experience similar BER issues. The KWorld 11x uses the Nxt2004 demod ... and Zoinks!, upon checking, I find that my single 11x card is now exhibiting BER too ! This is something new to me, as previous femon output was always free of such errors. -- 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: vbox cat's eye 3560 usb device
Hi Amy, Amy Overmyer wrote: I’m trying to write a driver for the device, just as a learning exercise. So far, I’ve got the firmware in intel hex format (from usbsnoop on windows, then a couple perl scripts to mutate it) and am able to use fxload to load it with –t fx2 and there are 2 separate files, a short one (the loader) and the firmware proper; so in fxload I have a –s and a –I. I’m able to take it from cold to warm that way solely within Linux. The device itself has a cypress CY7C68013A fx2 chip and a large tin can tuner/demod stamped with Thomson that has a sticker on it identifying it as 8601A. Helpfully, the 3560 opens up easily with the removal of two screws on the shell. The Thomson NIM is the same one that they use on their 150/151 PCI cards. I don't know what the internal components of it are, but the digital demodulator may be somewhat exposed to view -- the metal can has a ventilation opening, though the metal may actually be bent inwards for contact with the chip (so as to allow the casing to act as a heatsink)). If you can ascertain the identity of the unknown components then you will be in a better position to gauge whether you should bother continuing or not (i.e. if the demod is currently unsupported, you would have to develop support for it in order to ever get the device working under Linux). My suggestion here is: - non-invasive: search for any clues from the Windows driver inf files - invasive: as non-destructively as possible, open the can ... I don't advise this unless it looks do-able ... proceed at your own risk. Lastly, are there any other IC components on the back or front of the PCB ? Can you provide pics (upload them to the wiki article)) ? It’s cold boot usb id is 14f3:3560 and its warm boot is 14f3:a560. I have taken that hex file and created a binary file out of the 2nd file (-I in fxload speak). I think, correct me if I’m wrong, there is already a fx2 loader available, thus I will not need the loader file. One of the stranger things I saw in the usbsnoop trace in windows was when it came to reset of the CPUCS, the driver sent down both a poke at x0e600 and a poke at 0x7f92. One is the fx CPUCS register, I believe the other is a fx2 CPUCS register. Currently I am mutating dibusb-mc just to see if I can get it to the point of going from cold to warm in the driver. I have taken usb sniffs from windows of doing things such as scanning for channels, watching a channel, etc. so I can try to figure out if anything else in the v4l-dvb collection behaves similarly. I guess what I’m looking for is any hints that might be useful to figuring this out. Like I said, it’s a learning exercise, I already have enough tuners, and anyway, the cost of buying a supported tuner is far cheaper than the time needed to develop this! Thanks for any info! I’ve pretty much devoured everything available on the wiki. have a look at the cxusb, its likely closer to what you want: http://linuxtv.org/hg/v4l-dvb/file/tip/linux/drivers/media/dvb/dvb-usb/ -- 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
Regarding development for NXP saa7160/1/2 and saa7164 ICs
Evidently someone from NXP has left a message in the wiki (Ignore the incorrect date, as the message was entered today; see history for confirmation): http://www.linuxtv.org/wiki/index.php/Talk:NXP_SAA716x I will invite them to join into this thread. If octavsly is able to assist, I believe the relevant background on the matters are essentially: A) SAA7160/1/2 - The current rendition of the driver that Manu has been developing resides here: http://jusst.de/hg/saa716x - IIRC, Manu found that some particulars of the chip(s) were not clearly documented within the datasheets he had been provided, so development is still largely a WIP B) SAA7164 - my understanding is that there was a fair amount of work towards a driver put in by Steve, but he has had to put this project on hold - a number of other people have expressed interest in pushing forth with this, but I would imagine that Steve may be prevented by NDA from aiding them in their interest -- 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: PVR x50 corrupts ATSC 115 streams
Andreas wrote: Just to let you know that you're not alone: I had a simiilar problem with the combination of an AverMedia A180 and two Asus Falcon (they use the ivtv drivers and firmware). Whenever one of the Falcons was recording, I got blips and dropouts on the AverMedia. I chalked it off to a flaky mainboard and seperated the Falcons and the Avermedia in two different computers. A while later I got a new mainboard and additional ATSC tuner cards. As long as I had two of the ATSC tuner cards installed, the recordings were ok, except for an occasional dropout. But when I put a third ATSC tuner in, the recordings were barely watchable. After I put two ATSC tuners (2x Avermedia A180) in a different computer, they *all* are recording almost perfectly. Even a HVR-1600 card that I had dismissed as broken, delivers very good recordings in the other computer. It should be noted that a common element here in the two cases is the Nxt2004 (demod for both the A180 and 11x cards). -- 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: [Bulk] [linux-dvb] Problem with TV card's sound (SAA7134)
panagiotis takis_rs wrote: Hey!! I have a problem with my tv card(pinnacle pctv 310i) I can see image but i have no sound. I have tried both tvtime and kdetv. I have found this http://ubuntuforums.org/showthread.php?t=568528 . Is it related with my problem? My tv card give audio output with this way: direct cable connection from tv card to sound card ( same cable witch connect cdrom and soundcard ) I didn't read through the link you provided, but it appeared to be in regards to getting audio via DMA (using the card's 7134 chip to digitize the audio and send it over the PCI bus to the host system). You, on the other hand, indicate that you are attempting to use the method of running a patch cable between your TV card and sound card (meaning that the sound card will do the digitizing instead). Question: have you checked your audio mixer to make sure that any of the inputs are not muted? -- 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://linuxtv.org/hg/~dougsland/v4l-dvb/
Douglas Schilling Landgraf wrote: Hi Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb/ for the following: - v4l2-apps: Add parser for USB snoops captured from SniffUSB 2.0 It is not clear to me why this ended up in /v4l2-apps/test, as opposed to /v4l2/util -- can someone comment? 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran
Hans Verkuil wrote: It took me several long weekends to get all this work done, but I think it's been very worthwhile. Kudos! Well done -- another positive change! Together these cards use the ... ks0127 i2c devices quick question(s) - is this what I think it is -- a remote controller IC ? If so, do you know who manufactures this IC? (I'm trying to connect the dots with the problematic ks003 and ks007 ICs found on some cards) -- 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: POLL: for/against dropping support for kernels 2.6.22
Hans Verkuil wrote: Should we drop support for kernels 2.6.22 in our v4l-dvb repository? Yes Optional question: Why: Its causing skilled developers to waste time that would be better served in other areas. Because of that, these skilled volunteers are becoming frustrated and losing their interest in pressing forth. It causes unnecessary complexity. The golden rule is to keep things as simple as possible. It presents a hurdle to attracting new development talent (both corporate and individual). When upstream technical changes (such as i2c subsystem changes) have made backporting downstream a nightmare, it is time to seriously evaluate why you are even bothering doing such. The salient point is that it is absolutely illogical for volunteers to be catering to narrow commercial interests. - Arguments about appeasing the needs of Enterprise distro's are moot. V4L-DVB owes them nothing. Enterprise distro's are specifically that -- an enterprise's work; if they crave support, then they can put Hans (or whomever) on the payroll to backport for their specific needs. - Arguments about appeasing the needs of embedded distros/platforms are moot. V4L-DVB owes them nothing. Let those groups figure out and/or support such device needs on their own; else they can put Hans (or whomever) on the payroll. Those manufactures releasing products within this space will adapt to whatever V4L-DVB does.This space will not suddenly fall apart because of our decision. These entrepreneurs have entered this space specifically to exploit a market opportunity. If they exit, someone else will move in. Its simple free market dynamics. (As it is, they are getting a free lunch ... seriously, I think that when the embedded space looks at how bent over accommodating we currently are, they must be rubbing their hands together and gleefully repeating Flounders statement: Oh boy, is this great! (http://www.acmewebpages.com/midi/great.wav)) The V4L-DVB is lacking in strategic direction. Yesterday was the time to adopt one; so lets pick up one today! I believe the plan to currently backport to 2.6.22 but to bump/narrow the kernel support window to the ideal/easier_to_maintain 2.6.25, once express support from the big 3 desktop distos ends, is the most logical choice and the one which will have the most beneficial impact on the project's future. -- 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: PVR x50 corrupts ATSC 115 streams
David Engel wrote: I'll start with what worked. ... [test results of BER and UNC under varying configurations ] ... Steven Toth wrote: I think CityK confirmed that the nxt2004 driver statistics are probably bogus so I doubt you're going to get your 115's running with BER 0 regardless, which is unfortunate. FWIW: I'm not seeing any UNC, just the BER (which seems consistent to most, but not all, of David's results with varying configurations). Presently (and a situation that is unlikely to change), I don't have an older kernel built/installed with which I can test/confirm, but from memory, IIRC, I believe that it must have been from around ~2.6.22 that I recall error free femon output. -- 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: Fwd: [linux-dvb] dvico dual express incorrect firmware version readback!!!
sonof...@iinet.net.au wrote: On Mon Feb 16 22:51 , sonof...@iinet.net.au sent: I have done alot more testing and have found that it seems to be only after mythtv has accessed the device where this problem beings begins... Same result with the hg version updated tonight. I haven't had a chance to use another tv app yet as we are currently watching TV. I will send a further update later. Is anyone else actually seeing this Incorrect Firmware Version Readback error?? Is there something I am missing? (stupid kernel setup or something??)... Should I try and source the firmware again or is this unlikely to be the issue? Have you tested this outside MythTV (which is a huge layer of extra complexity) ? -- 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] Add Sony PlayTV to dibcom driver
I don't think the Patchwork tool picked it up, as I don't see it in the queue :( http://patchwork.kernel.org/project/linux-media/list/ I'm wondering it the quotations in the subject line are enough to throw the script off. Mauro, any ideas? -- 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: firmware
Matthias Schwarzott wrote: Btw. I also had a longer look at the firmeware page in wiki and removed that note about gentoo using hotplug-scripts as that is false since a long time. CityK you are right, I think most (if not all) current distributions use udev to create device nodes and upload firmware into the kernel. Yes this ebuild is there. But it is in some respect outdated, due to lack of maintaining. This ebuild fetches the original files get_dvb_firmware also fetches and the runs get_firmware to unpack them. (All this due to license/re-distribution issues as you all know). Okay, thanks Matthias. But: These URLs tend to no longer work after some time, as manufacturers update their drivers or web-pages :( So there should either be someone continuously updating them (in get_dvb_firmware and also here in copy). Or: We find someone ignoring the licenses and hosting the extracted files somewhere. Regards Matthias I think we are stuck with the former. But, fortunately, it looks like schollsky is willing to be the point man :) -- 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: Kworld atsc 110 nxt2004 init
Jonathan Isom wrote: Hi I was looking over my logs and I'm wondering is nxt200x: Timeout waiting for nxt2004 to init common No its not common or is this womething I need to worry about. I got one shortly before a lockup(No backtrace). Nothing was doing other than dvbstreamer sitting idle. I'll provide further logs if it should be needed. I would think that It would need to only be initialize at module load. Am I wrong in this thinking? in kernel drivers 2.6.28.4 Later Jonathan Quick! Get out of you house now, she's about to blow !!! Just kidding. I don't think its anything to worry about. The timeout is by design (see the nxt200x.ko module). I'm not sure why you've run up against this; it looks to have occurred several hours after initialization. Perhaps a quirk in the microcode of the demod caused it. -- 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] Giving Feedback (was Re: Klear?)
Stephen Rowles wrote: Only sending this to linux-dvb as I'm not signed up to the media list, and I'll probably get myself blacklisted from any future help by saying this ;) but... BANISHMENT for Rowles !!! Just kidding. Thanks for the insightful reply. -- 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] [Bulk] Problem with TV card's sound (SAA7134)
panagiotis takis_rs wrote: panagiotis takis_rs wrote: Hey!! I have a problem with my tv card(pinnacle pctv 310i) I can see image but i have no sound. I have tried both tvtime and kdetv. I have found this http://ubuntuforums.org/showthread.php?t=568528 . Is it related with my problem? My tv card give audio output with this way: direct cable connection from tv card to sound card ( same cable witch connect cdrom and soundcard ) I didn't read through the link you provided, but it appeared to be in regards to getting audio via DMA (using the card's 7134 chip to digitize the audio and send it over the PCI bus to the host system). You, on the other hand, indicate that you are attempting to use the method of running a patch cable between your TV card and sound card (meaning that the sound card will do the digitizing instead). Question: have you checked your audio mixer to make sure that any of the inputs are not muted? Yes i have. The only way i managed to get sound is these two commands: tvtime | arecord -D hw:2,0 -r 32000 -c 2 -f S16_LE | aplay - (out of sync) tvtime | sox -r 32000 -t alsa hw:2,0 -t alsa hw:0,1 | aplay - Which, as you likely know, is essentially going the DMA route and using the helper apps (sox, arecord) as tvtime currently doesn't support audio DMA. Hmm, if everything is unmuted, I have no idea why it isn't working simply via your patch cable ... last stab at this -- how about the leads on the patch cable itself; have you tried reversing the way one of the ends is plugged in? -- 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: Newbie question about cheap 4ch security card
Riba Zoltán wrote: Hi, I want to get working this card under my Debian :(2.6.24-etchnhalf.1-686 on i686) http://www.zoneminder.com/wiki/index.php/Image:4ch_DVR_card.jpg But it doesn't want...: dmesg: bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Host bridge needs ETBF enabled. bttv: Bt8xx card found (0). PCI: Found IRQ 15 for device :00:12.0 PCI: Sharing IRQ 15 with :00:07.2 PCI: Sharing IRQ 15 with :00:0b.0 FPCI: Sharing IRQ 15 with :00:12.1F bttv0: Bt878 (rev 17) at :00:12.0, irq: 15, latency: 32, mmio: 0xd7001000 bttv0: using: GrandTec Multi Capture Card (Bt878) [card=77,insmod option] bttv0: enabling ETBF (430FX/VP3 compatibilty) bttv0: gpio: en=, out= in=00f360ff [init] bt878 #0 [sw]: bus seems to be busy bttv0: tuner absent bttv0: registered device video0 bttv0: registered device vbi0 bttv0: PLL: 28636363 = 35468950 .. ok bt878: AUDIO driver version 0.0.0 loaded bt878: Bt878 AUDIO function found (0). PCI: Found IRQ 15 for device :00:12.1 PCI: Sharing IRQ 15 with :00:07.2 PCI: Sharing IRQ 15 with :00:0b.0 PCI: Sharing IRQ 15 with :00:12.0 bt878_probe: card id=[0x0], Unknown card.Exiting.. bt878: probe of :00:12.1 failed with error -22 lspci -vn no subsystem ID reported ... and no card id in dmesg ... I'm wondering if there is no EEPROM on the card also wondering if your card is different (i.e. a new revision) from the card 77 (GrandTec Multi Capture Card). What happens if you don't pass a modprobe parameter (i.e. comment out what you added in your relevant /etc/modprobe.conf file) and let the card autodetect ... (though, as maybe surmised from my above comment, I'm guessing a spectacular nothing ) -- 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: vbox cat's eye 3560 usb device
Amy Overmyer wrote: Lastly, are there any other IC components on the back or front of the PCB ? Can you provide pics (upload them to the wiki article)) ? The back only has a couple components, probably for electrical, no ICs. okay The front only has the cypress (100 pin pkg) chip and the NIM, with a couple small components, that I can't read what they are. The PCB is stamped osc by one of them and usbid on the other, so I'm guessing one is an oscillator and the other the PROM where the cold USB id is stored. okay. I rather imagine that your guesses are correct I opened up the NIM (hey, they're $30 at my local computer store right now, so even if I kill it, I have an extra), and I saw my old friend the BCM3510 (I have a 1rst gen air2pc pci card that works pretty well for me) Wow, I'm kind of surprised about that one -- I would have expected the NIM to have been a little more contemporary (given that I believe these devices (150/151/3560) came out in the ~2005 time frame). and a smaller chip marked tua6030 (or could be 6080, the writing is faint, but infineon doesn't look like they make an 6080). Yes, that would be 6030 I have photos but need to upload them. okay This device might also be close in design to the original Technisat Air2PC-ATSC-USB device (http://www.linuxtv.org/wiki/index.php/TechniSat_Air2PC-ATSC-USB) -- though, obviously it doesn't use a Flexcop controller ... I say might be, as I don't know what the USB bridge is in the Technisat device, nor the exact tuner module employed. Patrick might recall though -- 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: [Bulk] Re: POLL: for/against dropping support for kernels 2.6.22
Andy Walls wrote: On Sun, 2009-02-22 at 14:12 -0500, CityK wrote: The V4L-DVB is lacking in strategic direction. Yesterday was the time to adopt one; so lets pick up one today! CityK, I see you've been reading (or channeling) my blathering: http://www.linuxtv.org/irc/v4l/index.php?date=2009-02-20 ([19:42] to [20:21]) Regards, Andy Rabble Rabble Rabble! ( http://www.urbandictionary.com/define.php?term=RABBLE RABBLE RABBLE! ) -- 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] Add Sony PlayTV to dibcom driver
Mauro Carvalho Chehab wrote: On Sun, 22 Feb 2009 15:04:13 -0500 CityK ci...@rogers.com wrote: I don't think the Patchwork tool picked it up, as I don't see it in the queue :( http://patchwork.kernel.org/project/linux-media/list/ I'm wondering it the quotations in the subject line are enough to throw the script off. Mauro, any ideas? In general those tools to pick and work with scripts don't like very much inlined patches, although it generally works. Also, it requires that the patch is not line wrapped. In this specific case, the patch is line-wrapped: --- v4l-dvb-359d95e1d541-vanilla/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 13:49:37.0 +0100 +++ v4l-dvb-359d95e1d541/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 23:45:43.0 +0100 instead of: --- v4l-dvb-359d95e1d541-vanilla/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 13:49:37.0 +0100 +++ v4l-dvb-359d95e1d541/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-02-18 23:45:43.0 +0100 So, it doesn't apply as a patch and patchwork discards it. Ahh, thanks for the explanation. Its strange that they are not tailored for inline patches, given that that is precisely the preferred and prescribed submission method! -- 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: ASUS My Cinema-PHC3-100/NAQ/FM/AV/RC Support?
U. Artie Eoff wrote: I recently purchased a ASUS My Cinema-PHC3-100/NAQ/FM/AV/RC ATSC tv tuner card. I've done some searching to see what kind of support is available for using it under Linux. There is nothing out there that mentions it will work or how to get it to work. And it does not appear that my Fedora OS detects it installed. Could someone start me off with some steps on getting it configured (i.e. drivers, detecting, loading, configuring, etc.). I consider myself a somewhat advanced user of Linux, but have never done any direct work with tuner cards or general low-level hardware configuration under Linux. So, don't hesitate to explain in technical terms if it is easier. suscipio lackius -- a technical term, derived from Coyote and Road Runner Latin, which literally translates into support lacking or, from a contemporary perspective, not supported. Sorry. Hopefully the humour eased the pain. Anyway, here is the product link for my card: http://www.asus.com/products.aspx?l1=18l2=83l3=794 ...and product image: http://www.asus.com/prog_content/middle_enlargement.aspx?model=2524 From your provided link, it is apparent that this is another variation of the ViXS Puretv reference design(s). Up to this point, in PCI flavour, I had only seen a half height card design. Examples: - Vista View Saber DA-1N1-I (http://www.vistaview.tv/saber-da-1n1-i.html) - Samsung Combo-210 (http://www.geeks.com/details.asp?invtid=COMBO-210-BULKcat=VID) - ViXS PureTV-U 48A3 ( http://www.linuxtv.org/wiki/index.php/ViXS_PureTV-U_48A3) As I've seen a couple of other PureTV-U model numbers listed (without actually having seen the cards), it is likely that your full height PCI card is the equivalent of one of them. I would go a step further and call your card pretty much a PCI hybrid of the Samsung type PCIe design; have a look at: - Vista View Saber DA-1N1-E (http://www.vistaview.tv/content/view/51/116/) - Samsung Combo-210E (http://tekgems.com/Products/et-46138-vid-combo-210e-bulk.htm) Note that with the Vista View PCIe card, it looks like the LG demod is on the front face. (In the half height PCI design, the LG demod is on the back side of the card). In the Samsung PCIe card, there is a much smaller chip in the spot where the LG demod resides on the Vista View PCIe version. Similarly, your card also appears to copy the Samsung layout/componentrywith the minor exceptions related to the difference in interface I suggest contacting ViXS and inquire as to whether they intend to provide Linux support for their chip; there is some evidence that suggests that they may very well be interested (http://www.vixs.com/sections/careers/job_software_driver_engineer.htm). Other then that, I suspect that the other components used by the card already have driver support, or are presently being worked upon (i.e. saa7136) in conjunction for other projects. Once those individual items are all supported, device level support would certainly be feasible to obtain. -- 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: Kworld 315U and SAA7113?
Franklin Meng wrote: As far as I can tell, the Kworld 315U is the only board that uses this combination of parts.. Thomson tuner, LG demod, and SAA7113. I don't think any other device has used the SAA7113 together with a digital demod. Most products seem to only have the SAA711X on an analog only board. Since I don't have any other USB adapters with the SAA chip I was unable to do any further testing on the SAA code changes. IIRC, a couple of the Sasem/OnAir devices use a saa7113 together with a digital demod. I seem to also recall something else, though maybe I'm mistaken. -- 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: Should I see a videoN and audioN in /dev/dvb/adapterN??
Peter Brouwer wrote: I am using a S460 Tevii ( Cx88) and a nova T 500 card. I see three adapter directories ( T 500 is dual tuner). Each has demux0 frontend0 net0 and dvr0 Should I not see a video0 and audio0 in each of them too? I see one /dev/video0 and one /dev/vbi0 that seems to belong to the S460 card See here: http://www.linuxtv.org/wiki/index.php/Device_nodes -- 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: problem building v4l2-spec from docbook source
Mauro Carvalho Chehab wrote: Em Sun, 6 Sep 2009 22:25:25 -0300 Mauro Carvalho Chehab mche...@infradead.org escreveu: Em Sat, 05 Sep 2009 18:54:27 +0100 Peter Brouwer pb.mailli...@googlemail.com escreveu: Is it possible to create a link on the linuxtv.org website to the latest dvb and v4l spec in pdf? For dvb the v3 is still on the documentation page. The pdf version of V4L2 spec is currently broken: several tables and graphics don't fit at the page size. If you (or someone else) is interested on fixing it, I'll add a pointer at linuxtv.org for the updated version, and improve the script to auto-generate it. In the case of the DVB spec, the version of the current document is version 3. Patrick's ISDB-T patch series are increasing version to 5.1, but there are still some missing parts when comparing with the current API. In order to make easier for people to maintain the DVB API and to allow people of just using just one language and document generation tools, I've converted the DVB API specs to DocBook as well. I'll add it to the tree soon. It is yet a work undergoing, but it would be nice if people could review it and improve. After having some review and porting the ISDB-T changes to it, IMO, the better is to deprecate the LaTex version using the DocBooc version one instead. I've updated the Documentation page at linuxtv.org to warn people to not trust at V4L2 spec pdf file, while nobody fixes it. I also added there a link to the dvbapi spec generated via the newly DocBook port of the docs that I posted at: http://linuxtv.org/hg/~mchehab/dvb-specs This way, it will be easier for people to double check if nothing were lost during the format conversion. IMHO, one of the biggest advantage of the html generated from DocBook is that the chapter/section numbering is preserved, while, with the LaTex version, they are shown only at the pdf doc. It should be noticed that, as no styles are applied to the tables, that they are not nicely displayed at the DocBook version. We've got too many entry points/links to things -- which lends itself to becoming a maintenance nightmare (not blaming anyone, just pointing out the obvious). For example: although the updated info was applied here: http://www.linuxtv.org/docs.php, we have other avenues such as http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/ (as linked to by, for example, from here :http://www.linuxtv.org/wiki/index.php/Development:_Video4Linux_APIs) that do not reflect those changes, and hence we have inconsistent info across the board. Same goes with mailing lists and #irc channels -- we've got too many of them! ... /trails off mumbling about this and thatmumble mumble mumble grumble -- 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: xf86-video-v4l
Stefan Sassenberg wrote: Hello, what does the xf86-video-v4l driver do? I think I know the purpose of xf86-video-graphics_card drivers, but I don't know what the -v4l does. How is it used? Regards Stefan Hi, please note that this mailing list is pretty much deprecated in favour of the Linux-Media Mailing List (LMML) -- many key individuals have already left the building (i.e. unsubscribed and participate only on LMML nowadays). Anyway, in answer to your question: * from the command line, type man v4l Then supplement that info with the following points taken from the V4L2 API (http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html): * http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#id3069581 ** http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#ftn.id3069581 * http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#xvideo -- 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: Question on video device in /dev for S460 card cx88
Peter Brouwer wrote: Hello Quick question regarding video devices that show up when using a cx88 base S460 (tevii) DVB-S2 card. I see two devices in /dev /dev/video0 and /dev/vbi0 related to the cx88 based dvb-s2 card. What are those devices, is the video0 the video out of the card after the demuxer? If so, should that device not show up in /dev/dvb/adapterN ?? What is the /dev/vbi0 device? Regards I heavily modified/updated my previous link/answer I provided to this question you posted earlier. A more thorough answer can be found here: http://www.linuxtv.org/wiki/index.php/Device_nodes_and_character_devices Please review that, as it should make clear the answers to your questions. -- 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: NTSC/ATSC device recommendation
Ben Swartzlander wrote: rra...@comcast.net wrote: I would like to purchase a NTSC/ATSC device that is functional under Linux MY only requirement is receiving FTA broadcast Would y'all recommend a USB device or better to stick with a pci device I have followed this list and have only become more confused Thanks Richard I have 2 Hauppauge WinTV-HVR-850 USB sticks in my MythTV box (Ubuntu 8.04). USB is preferable to PCI for all kinds of reasons. I bought mine here: http://www.newegg.com/Product/Product.aspx?Item=N82E16815116031 Note that if you go with this device, you'll need to manually add the firmware to your /lib/firmware directory. You can get the firmware here: http://www.steventoth.net/linux/xc5000/ There are plenty of other supported devices though. When I was doing my research, this page was an extremely useful resource for Linux ATSC hardware: http://www.linuxtv.org/wiki/index.php/ATSC_Devices That last comment made me happy to know. Anyway, please note that this mailing list is pretty much deprecated in favour of the LMML (which I've cc'ed in this reply). -- 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: LinuxTV firmware blocks all wireless connections / traffic
Aleksandr V. Piskunov wrote: I'm getting closer to pinpointing the real problem and so far everything points to AMD SB700 chipset driver. Google says it has quite some hardware bugs and several workarounds in linux drivers... If your googling didn't turn them up already, here's some more threads: http://www.mail-archive.com/search?q=SB700+l=linux-media%40vger.kernel.org -- 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] Linuxtv wiki needs email notification/more email-ready users
H. Langos wrote: Hi there, after a while I decided to come back to the linuxtv wiki to finish organizing the bazillion dvb-t usb devices in a way that helps a) normal users to find out if a certain device is supported and b) developers to update information on the drivers they manage. Some preview of this can be seen on my playground page: http://www.linuxtv.org/wiki/index.php/HLPlayground2 As this is a more complicated way of storing the information than just plain tables, I'd like to keep an eye on changes. Not because of fear of vandalisim but because changes to the templates/date potentially have effects on a lot of pages. There are some people who day by day put a lot of effort and work into the wiki and I'd like to thank them all for their continuing effort. I myself have only occasionaly time to update information there and I miss a lot of changes, even to the pages I watch, because the watchlist and recent cahnges reaches only seven days back. Manually going through the pages on my watchlist (currently 57) is not what I'd call good use of resources. It would be great if it was possible to get (immediate/daily/weekly?) change notifications by email in order not to lose track of what is happening to the pages that I care about. (I bet this is standard functionality of mediawiki or at least one of the more common extentions.) Also I'd like to encourage new and existing users to add their email address to their profile AND to check the Enable e-mail from other users box. Maybe we could change the default to enable that box? That way it is possible to ask for missing details if somebody adds a new device, or to send hints if somebody writes in an article that a certain device doesn't work. Or to simply write a short note when removing some information like Hey dude, I just removed some information that you added to article X because it is already contained in article Y. Instead I've added a link to Y. Thank you for your help and keep up the good work!... Also developers could ask people who are interested in a device's driver to check out a new version as soon as it is ready. All in all it would improve the user experience and the quality of information on the wiki as feedback would not have to go through the discussion pages. I went that way when talking to some other wiki admins about my efforts to unify the usb dvb-t data and the experience shows that wiki's are not a good medium for serious discussions. cheers -henrik (I've cc'ed the LMML to reach the wider audience nowadays) These are good suggestions that Henrik has made. I would encourage others to also step up and try to find ways to implement them (along with any other improvements that can be made to the wiki and other sources of V4L-DVB documentation and website -- the website, in particular, really could stand for an overhaul). (Note - at present I do not have time to take on further work, nor do I personally really want the responsibility of being the point man for such changes ... as it stands, I'm interested only in finishing off ventures I commenced long ago ... or introducing changes that are personally enjoyable to myself to make) I also note that from prior discussions with Henrik and Jim (and Henrik is absolutely correct that discussing things from within the wiki quickly becomes difficult to follow), and from prior times with Micheal and Devin on irc, that we were touching upon the idea of a database. One such example that I recently came across, and that is worth further investigation by someone (and, again, that someone does not include me), is that model used by dd-wrt for their supported hardware (i would link, but it appears that their server is down at the moment). -- 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: [Bulk] V4L-DVB Summit Day 3
Hans Verkuil wrote: I made the following list: - We created a new mc mailinglist: linux...@googlegroups.com This is a temporary mailinglist where we can post and review patches during prototyping of the mc API. We don't want to flood the linux-media list with those patches since that is already quite high-volume. The mailinglist should be active, although I couldn't find it yet from www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did something wrong. I'm scratching my head on this one. Seems the last thing that is needed is YET another mailing list. Further, it - fractures the development community. - persons unaware of the decision, and whom might be interested, would never find it . i.e. alienation - disinterested parties can simply hit the delete key and not bother with the message - blah blah blah .. PS. In regards to yesterday's business announcements, I hope your new forthcoming overlords are as kind to you as your last -- 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