Re: GrabBee-HD
On Fri, Oct 17, 2014 at 3:29 AM, Dave Kimble dave.kim...@riseup.net wrote: Thanks for your reply. Your feeling that VB-WinXP would be the problem sent me back to that. So I found that VB picking up USB 2.0 devices requires the Extension Pack installed with ehci controller enabled , and that cured that problem, and the device now finds it's XP driver. Ahh good to know, thanks for the feedback. I generally don't use VB, I go with VMWare on multiple platforms. The grabber software loads OK and asks for the signal information. Since the software goes with this particular device, I am surprised at this - it should know it already, shouldn't it? Yes. Although the software's input is the device's output, it also seems to depend on the device's input, i.e. the HDMI stream.This stream comes via satellite dish and decoder box, and is picking up Freeview channels in Australia. Almost all of the options produce the error: Sigma Designs USB Device device does not active or error ! [sic] The best combination of options produces a good picture, but it moves very slowly and after a few seconds freezes. XP cannot then terminate the process, and neither can VB Close. So I have to VB Reset Then Ubuntu loses the device from lsusb and it needs too be unplugged and plugged in again, and VB-WinXP started again. Urgh. Any assistance would be welcome - as you can probably tell, I really don't know what I'm doing. Probably best to validate the hardware and software on its intended platform and check that everything functions properly. Who knows, maybe you've got a buggy build or a flakey stick. You may be confusing one set of problems for VB related when in fact they're something else. - Steve Dave On 17/10/14 07:40, Steven Toth wrote: Ok, no nobody jumped in the first time around. my turn I guess... :) Comments below. On Thu, Oct 16, 2014 at 5:18 PM, Dave Kimbledave.kim...@riseup.net wrote: I have just bought an HDMI to USB-2.0 grabber called GrabBee-HD. http://www.greada.com/grabbeex-hd.html Motherboard photo:http://www.davekimble.org.au/computers/GrabBee-HD.jpg Inside it has chips labelled Sigma PL330B-CPE3 and iTE IT6604E. Note that it compresses the video with H.264 . I've worked on drivers for those two chips in the past. I have a large amount of experience with these parts. I knew it probably wouldn't have drivers for Linux, but it does have Windows drivers on CD, so since I run Ubuntu-VirtualBox-WinXP I thought it might well work one way or another. Correct, no Linux drivers. On Ubuntu 14.04, the USB device is picked up: $ lsusb -v -d 0658:1100 snip but it is not recognised as a video capture device by VLC. /dev/dvb/ , /dev/v4l/ , /dev/video0 do not exist. Correct. Linux has no support for that device. :( So I fired up VB-WinXP and installed the Windows drivers and software, and restarted. Then plugged in the device, which should connect the device to the driver, but it didn't. That's odd. It suggests an (off topic) windows related driver problem, or a virtual machine issue. Starting the Grabbee-HD software gives No video capture device is connected! Then I realised the USB device has to be passed through the VB interface, VB-Manager USB Add no devices available. So because Ubuntu doesn't properly recognise the device, it can't pass it on to VB and XP. I don't think the virtual machines work that way, at least not in my experience. I've always been able to do what you want to do on various platforms. Sorry, I can't really help you debug Windows / Virtual machine issues. Is there any chance of getting this going on Ubuntu 14.04 natively? Unlikely. Sigma are generally GPL unfriendly. I've done drivers for this chip on OSX before, mostly as a RD exercise, so I'm highly familiar with it. The chip is a monster to write for, kinda nasty to be honest - not very straightforward. I think you're out of luck. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: GrabBee-HD
So I think this is going to be a very poor toy. Its the kind of thing I usually like to throw into my collection for the long winter nights. If you can give me a url that I can purchase this from then I may pick a unit for future tweakery. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GrabBee-HD
Ok, no nobody jumped in the first time around. my turn I guess... :) Comments below. On Thu, Oct 16, 2014 at 5:18 PM, Dave Kimble dave.kim...@riseup.net wrote: I have just bought an HDMI to USB-2.0 grabber called GrabBee-HD. http://www.greada.com/grabbeex-hd.html Motherboard photo: http://www.davekimble.org.au/computers/GrabBee-HD.jpg Inside it has chips labelled Sigma PL330B-CPE3 and iTE IT6604E. Note that it compresses the video with H.264 . I've worked on drivers for those two chips in the past. I have a large amount of experience with these parts. I knew it probably wouldn't have drivers for Linux, but it does have Windows drivers on CD, so since I run Ubuntu-VirtualBox-WinXP I thought it might well work one way or another. Correct, no Linux drivers. On Ubuntu 14.04, the USB device is picked up: $ lsusb -v -d 0658:1100 snip but it is not recognised as a video capture device by VLC. /dev/dvb/ , /dev/v4l/ , /dev/video0 do not exist. Correct. Linux has no support for that device. :( So I fired up VB-WinXP and installed the Windows drivers and software, and restarted. Then plugged in the device, which should connect the device to the driver, but it didn't. That's odd. It suggests an (off topic) windows related driver problem, or a virtual machine issue. Starting the Grabbee-HD software gives No video capture device is connected! Then I realised the USB device has to be passed through the VB interface, VB-Manager USB Add no devices available. So because Ubuntu doesn't properly recognise the device, it can't pass it on to VB and XP. I don't think the virtual machines work that way, at least not in my experience. I've always been able to do what you want to do on various platforms. Sorry, I can't really help you debug Windows / Virtual machine issues. Is there any chance of getting this going on Ubuntu 14.04 natively? Unlikely. Sigma are generally GPL unfriendly. I've done drivers for this chip on OSX before, mostly as a RD exercise, so I'm highly familiar with it. The chip is a monster to write for, kinda nasty to be honest - not very straightforward. I think you're out of luck. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-2200 (saa7164) problems (on Linux Mint 17)
Please keep the discussion on the mailing list at all times. I couldn't figure out how to apply the patch using the patch file, so I manually edited the file (drivers/media/pci/saa7164/saa7164-fw.c), but I kept getting the image corrupt message. That's probably the issue. Assuming you have the patch applied and are using the firmware it will work for you. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/5] saa7164: convert to seq_hex_dump()
On Wed, Jul 9, 2014 at 11:24 AM, Andy Shevchenko andriy.shevche...@linux.intel.com wrote: Instead of custom approach let's use recently added seq_hex_dump() helper. Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com ack Reviewed-by: Steven Toth st...@kernellabs.com -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Best way to add subdev that doesn't use I2C or SPI?
Any suggestions welcome (and in particular if you can point me to an example case where this is already being done). I'm not aware of any subdevs of that type. Depending on the nature of the registers in the sub-dev silicon, and its mode of operation, it may fit into a virtual i2c device model pretty easily. Convert the usb control messages into i2c read writes in the implementation of the subdev, and implement a virtual i2c master in the bridge, converting the register reads/writes back into direct bridge dependent messages. Use i2c as a bus abstraction. The subdev looks like an i2c device. The bridge translates. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pvrusb2 has a new device (wintv-hvr-1955)
On Fri, Jun 20, 2014 at 1:48 AM, Matthew Thode prometheanf...@gentoo.org wrote: Just bought a wintv-hvr-1955 (sold as a wintv-hvr-1950) 160111 LF Rev B1|7 Talk to Hauppauge, they've already announced that they have a working Linux driver. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pvrusb2 has a new device (wintv-hvr-1955)
Just bought a wintv-hvr-1955 (sold as a wintv-hvr-1950) 160111 LF Rev B1|7 Talk to Hauppauge, they've already announced that they have a working Linux driver. I talked to them and they did say that the driver hasn't been upstreamed, also gave me some hardware info. They wouldn't give me a driver/firmware that worked though and offered to RMA for an older device. They'd previously announced publicly that the driver was available under NDA for a superset product (HVR-1975): Slashgear picked up the PR. http://www.slashgear.com/hauppauge-wintv-hvr-1975-usb-tv-receiver-offers-multi-format-support-27318809/ There are both 32-bit and 64-bit drivers for wider computer support, and for Linux users, driver support is provided under an NDA. ^^^ I suggest you ask them, they do have a solution. The demodulator is a Si2177, can't find anything about it in the kernel though. Correct. They also mentioned a LG3306a, wasn't able to find anything on it (might have misheard a character). LGDT3306 - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: am i in the right list?
On Tue, May 27, 2014 at 8:18 PM, Michael Durkin kc7...@gmail.com wrote: what's the process tree like when its looked at? 1d5c:2000 On Thu, May 22, 2014 at 8:44 AM, Steven Toth st...@kernellabs.com wrote: Should i email Hans Verkuil or would he see this already ? Fresco Logic FL2000 USB to VGA adapter He would have seen this already. I'm not sure I understand your question but let me take a shot at what I think you mean. I think you mean, how does a developer someone go about creating a driver for a new product? 1. They announce their intensions on the mailing-list (here), just to check that no other developer is actively working the same driver. This isn't mandatory, but can often avoid cases where multiple people are working on the same end-goal. 2. Wait a week, anyone interested will likely comment very quickly, if they are already working on something. If you get little or no feedback then nobody is working in that area. 3. Assuming nobody is working on it (as in your case), go ahead and start development - or hire someone to engineer the driver on your behalf. :) -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: am i in the right list?
Should i email Hans Verkuil or would he see this already ? Fresco Logic FL2000 USB to VGA adapter He would have seen this already. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am i in the right list?
Im looking for support for a Fresco logic FL2000 USB to VGA adapter ... Is any one already working on this or am i in the wrong list? Mike, This is the right list. I'm not aware of anyone working on drivers for that chipset. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Support for Elgato Game Capture HD / MStar MST3367CMK
On Thu, May 8, 2014 at 9:48 PM, Tolga Cakir to...@cevel.net wrote: Hello everyone! Hi Tolga! Over the past weeks, I've been busy capturing USB packets between the Elgato Game Capture HD and my PC. It's using the MStar MST3367CMK chip, which seems to have proprietary Linux support available only for hardware vendors in form of an SDK. Problem is, that this SDK is strictly kept under an NDA, making it kinda impossible for us to get our hands on. Thanks for raising the subject. While your comment is true, it would have been more appropriate to the development community to say that it truly uses the Fujitsu USB encoder, a fujitsu USB API along with a series of smaller subsystems for HDMI receivers and transmitters. Your capture logs indicate (largely) interaction with the Fujitsu USB bridge + integral encoder. The distinction is important. We outlined the architecture of the device (along with the brief tear down) here: http://www.kernellabs.com/blog/?p=1959 So, I got my hands dirty and have found some very good stuff! First of all, in contrast to many sources, the Elgato Game Capture HD outputs compressed video and audio via USB! It's already encoded, so there is no need for reencoding, this will save CPU power. For testing purposes, I've only tried capturing 720p data for now, but this should be more than enough. Have you posted any source code? I don't see any in the zips or on github. Paging through a 600MB usb capture to find an occasional comment (assuming you have inserted them) doesn't encourage me to contribute. Basically, we need to read raw USB traffic, write an MPEG-TS file header, put in the raw USB data and close the file. I'm not super experienced in C / kernel development (especially V4L), but I'll give my best to get this project forward. My next step is getting a prototype working with libusb in userland; after that's done, I'll try porting it over to kernel / V4L Project page can be found here: https://github.com/tolga9009/elgato-gchd I must be missing something. your repo contains a LICENSE file and README. Did you forget to checking a homebrew datasheet or working sample source code? USB logs and docs: v1.0 as 7zip: https://docs.google.com/file/d/0B29z6-xPIPLEQVBMTWZHbUswYjg v1.0 as rar: https://docs.google.com/file/d/0B29z6-xPIPLEcENMWnh1MklPdTQ v1.0 as zip: https://docs.google.com/file/d/0B29z6-xPIPLEQWtibWk3T3AtVjA Ahh, thank you for circulating the datasheets and images from our blog post, you are most welcome! The internet is a wonderful thing, I'm glad you found them useful. Is anyone interested in getting involved / taking over? Overall, it seems doable and not too complex. I'd be happy about any help! Also, if you need more information, just ask me. I'll provide you everything I have about this little device. How about instead of some usb dumps, pictures and pdfs, a working program and a description of the device protocol? This would help. I spent a few days late 2012 with the usb analyzer and brought together a primitive collection of personal notes on the API. Sadly I'm struggling to locate them currently. From memory, the device has an odd protocol which isn't exactly obvious. Its firmware like, not i2c based. You don't appear to control the HDMI rx/tx silicon by hand, the fijutsu firmware does this via firmware APIs. you would think, YAY! firmware API, easy, surprisingly not. A lot of byte guess to be done. If you have any significant homebrew documentation on the byte sequences that control the device, this would help. Part of the problem is that the device also streams (with the windows/osx drivers I was using) permanently on, making it difficult to see the wood from the noise. So, even when you are not 'using it', its streaming payload via USB to the host. Urgh. I hope they've fixed this. The device outputs native ISO13818 TS packets which are easily playable in VLC as is. I don't even think you need to add a header, unless you are electing to create an updated PMT. I have datasheets and/or source on everything except the fujitsu encoder, sorry - I can't share. Keep going with your project, this should be a fun to follow. libusb is easy to work with, you should have the device running in no time. If you can make the device run at both 720p and 1080i then you should find enough variance in the protocol bytes, build that into your app, to be useful for some people. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Comparisons of images between Dazzle DVC100, EasyCap stk1160 and Hauppauge ImapctVCB-e in Linux.
Doh, HTML cause vger to drop it. Resending. On Fri, Apr 25, 2014 at 8:47 AM, Steven Toth st...@kernellabs.com wrote: On Fri, Apr 25, 2014 at 8:19 AM, Steve Cookson i...@sca-uk.com wrote: Hi Guys, Hello again. (I'm copying Ezequial on this because of the work he has done on the stk1160). My colleague (a Doctor) had this to say on the medical images I posted earlier (see below): The impactVCB-e image is redder and less clear. The dvc100 and easycap seem similar to me and both of them are not as good as the original one. So I have to ask how is it that the cheap little EasyCap is performing at the same level as the Dazzle DVC100 and better than the ImpactVCB-e? Its usually either because the Linux engineers simply aren't focused on improving quality for the last 'mile', or that the ADC/Video digitizer differers between products. 'Redder' isn't usually a differentiation between video digitizer silicon, its miss-configuration - for example. It seems to me that the more complex and expensive DVC100 and ImpactVCB-e should perform well and that the EasyCap should be the runner up. Not necessarily, but I can understand why you may think that. The reality is - you are measuring the work of individuals who we're not paid to create these Linux drivers. They work well enough for their needs, they scratched their own itch, then they moved on, more than likely this is the case. So, you are seeing a mixture of different silicon, different attention to detail, different default values and different levels of commitment in the driver developers. If the DVC100 and ImpactVCB-e had had the same love and attention that Ezequial has shown the EasyCap would they outperform it? Hard to say. With my experience working for Hauppauge, directly in their engineering team, having worked on literally hundreds of products, lots of different video digitizer, they're all fairly close quality wise in general, with good signals, with the right drivers. What makes a good video digitizer stand out from a poor one, it how it performs in very poor signal conditions. The ImpactVCB-e is easier to use internally and the Dazzle is external. Does the fact that the ImpactVCB-e has a PCI-e connector help it at all? Invariably not. Otherwise I should just focus on EasyCap for my raw SD capture and move on. You need to make that judgement call. If you are building a business around medical imaging and have no engineering capability to improve drivers, go with what your gut says and what's available to you today. You shouldn't rely on the good will of Linux engineers to fix your business requirements in their spare time, in the coming weeks or months. Or, hire a consultant to improve the drivers for you and the rest of the Linux community. This what everyone else does. - Steve Thanks, Steve On 23/04/14 16:22, Steve Cookson wrote: Hi Guys, I would be interested in your views of the comparisons of these images. The still is the image of a duodenum taken during an endoscopy and recorded to a DVD player (via an s-video or composite cable). Although the endoscope is an HD endoscope, the DVD recorder isn't and the resulting video is 720x480i59.94. Here are further details of the video:- Format : MPEG Video v2 Format profile : Main@Main Format settings, BVOP : Yes, Matrix : Custom, GOP : M=3, N=15 Bit rate mode : Variable Bit rate : 4 566 Kbps Maximum bit rate : 10 000 Kbps Width : 720 pixels Height : 480 pixels Display aspect ratio : 4:3 Frame rate : 29.970 fps Standard : NTSC Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Top Field First Compression mode : Lossy Bits/(Pixel*Frame) : 0.441 The video was played through Dragon Player and the video signal has exited through a mini-VGA port defined as 640x480 and passed through a VGA-S-Video converter to an s-video cable. The cable has in turn been connected in turn to a Dazzle DVC100, an EasyCap stk1160 and a Hauppauge ImapctVCB-e. Each setting (eg brightness and contrast etc) has as near as possible to mid-range and a screengrab taken. The results are shown here: Original: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcMrgmD6gSf74Ih4l5k2TGxc Dazzle DVC100: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcMaOf4QTsIefYh4l5k2TGxc ImpactVCB-e: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcM7i72IqGujuIh4l5k2TGxc STK1160: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcPO7kmQk/IS94h4l5k2TGxc I would be grateful for your views on the quality of the images. Is one of materially higher quality than the others, or can I adjust the settings to improve the quality of one of them more. It seems to me that the Hauppauge is marginally better than the others. What do you think? Can I improve the test? Regards Steve. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord
Re: [PATCH] cx23885: add support for Hauppauge ImpactVCB-e
Hi Hans, While I do get audio it is very choppy. It is not clear whether that is a general cx23885 driver problem or specific to this board. If it is specific to the board, then I might have missed something. Steven (Toth, not Cookson ;-) ), do you have an idea what it might be? Nothing comes to mind, I'm not aware of any audio issues with the other '885/7/8 boards. A board issue or driver regression would be my guess. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge ImpactVCB-e 01385
When I plug in my 01385 I get the same old stuff in dmseg, ie: cx23885 driver version 0.0.3 loaded [ 8.921390] cx23885[0]: Your board isn't known (yet) to the driver. [ 8.921390] cx23885[0]: Try to pick one of the existing card configs via [ 8.921390] cx23885[0]: card=n insmod option. Updating to the latest [ 8.921390] cx23885[0]: version might help as well. [ 8.921393] cx23885[0]: Here is a list of valid choices for the card=n insmod option: Etc. Does anyone have any idea of the issue here? Sure. The issue is nobody cares enough to update the driver to support your card and make it work out of the box. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge ImpactVCB-e 01385
Hi Steve, Well not nobody because I do. How do I do it? If you would guide me through, I will happily update it. I seem to recall Kernel Labs offered you some commercial help with this product in the past and you declined, you apparently wanted to tackle it on your own. How's it coming along? The mailing list will welcome any patches you choose to submit. Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kworld PlusTV All in One PI610 - need help
DVB_ATTACH. Each demodulator usually lets you configure serial vs parallel digital interfacing, and various polarity settings for the SOP and VALID lines. If you get the polarity wrong then the DVB-T bytes can be reliably moved between the demodulator and the PCI 7131. Uou'd expect either a) a complete loss of packets - which is what the dsp is reporting above or b) mangled and junk being received. dvbtraffic lets you 'see' the packets. Ideally you will see a list of pids and counts increasing, if the pids# column varies then most likely the mpeg interface is incorrectly configured. Other aspects come into play which can prevent the demodulator MPEG output from being received by the 7131, for example a gpio driven muxes can often cause problems, by routing altering the MPEG electrical routing Focus on tzap and getting the demodulator to report successful LOCK first. Please ensure ensure any replies include the mailing list. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FireDTV / w_scan / no data from NIT(actual)
But I guess demuxing is necessary to get the NIT(actual) table, isn't it ? Generally speaking applications configure the demux to pass all pids, so yes - the demux is typically mandatory. Data is received from the dvr0 device. Assuming the card is tuning and delivering complete unfiltered transport payload reliably, then if no NIT is appearing then I can only assume either the application isn't waiting long enough, or it doesn't existing on that frequency. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FireDTV / w_scan / no data from NIT(actual)
Only is goes already wrong with the init scan I only get: Info: no data from NIT(actual) I suspect either their isn't a NIT(actual) table on your frequency, or the tool isn't waiting long enough for the NIT table to arrive. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] media mini-summit on May, 2 in San Jose
Devin and myself will be in San Jose all week, although we do have existing plans for May 2nd. If we can fit the mini-summit in then we will, or we'll catch up with individual people during the conference itself. Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com On Wed, Mar 19, 2014 at 3:02 PM, Mauro Carvalho Chehab m.che...@samsung.com wrote: As discussed on our IRC #v4l channels, most of the core developers will be in San Jose - CA - USA for the Embedded Linux Conference. There are several subjects that we've been discussing those days that require a face to face meeting. So, We'll be doing a media mini-summit on May, 2 (Friday) at Marriott San Jose. Eventually, we may also schedule some BoFs during the week, if needed. In order to properly organize the event, I need the name of the developers interested on joining us, plus the themes proposed for discussions. As usual, we'll be using the media-works...@linuxtv.org ML for specific discussions about that, so the ones interested on participate are requested to subscribe it. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Video capture in FPGA -- simple hardware to emulate?
On Thu, Feb 13, 2014 at 2:52 PM, Pavel Machek pa...@ucw.cz wrote: Hi! I'm working on project that will need doing video capture from FPGA. That means I can define interface between kernel and hardware. Is there suitable, simple hardware we should emulate in the FPGA? I took a look, and pxa_camera seems to be one of the simple ones... Thats actually a pretty open-ended question. You might get better advice if you describe your hardware platform in a little more detail. Are you using a USB or PCIe controller to talk to the fpga, or does the fpga contain embedded IP cores for USB or PCIe? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Video capture in FPGA -- simple hardware to emulate?
Are you using a USB or PCIe controller to talk to the fpga, or does the fpga contain embedded IP cores for USB or PCIe? There should be no USB/PCIe involved. How are you planning to connect the FPGA memory space to your host cpu kernel memory space? Soft CPU directly inside the fpga as a platform device? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
On Fri, Feb 7, 2014 at 1:23 PM, The Bit Pit thebit...@earthlink.net wrote: Last May I started writing a driver for a KWorld UB435Q Version 3 tuner. I was able to make the kernel recognize the device, light it's LED, and try to enable the decoder and tuner. Slightly related I added support for the KWorld UB445-U2 ATSC/Analog stick the other day. It uses the cx231xx bridge, LG3305 and TDA18272 tuner. It was fairly simple to get running. Analog and digital TV work OK, the baseband inputs and alsa are running. No great shakes. Manu has a TDA18272 Linux tree if you google a little. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
If you need, I can push the 7231 tree up as well for upstream merge. That would be great Manu! Yes please. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver for KWorld UB435Q Version 3 (ATSC) USB id: 1b80:e34c
Thanks steve, You are very welcome. Found it. Its the same files I found at a different place. I don't understand the way to do things. Last time I simply edited the kernel tree and supplied patches to get my changes in. The source for tda18272 is not in the kernel tree I 'git' following the instructions at linuxtv.org. It is in Manu's tree, but the directory structure is slightly different. That's ok. Anything that gets submitted for upstream merge (by manu for example) would be moved into the correct directories by the developer. It's not unusual to see personal development trees with odd file placements. I don't understand the current development process. Are the instructions at linuxtv.org out of date? No, last I checked they were correct. In which tree should I edit the following and supply patches against: usb/em28xx/em28xx-cards.c usb/em28xx/em28xx-dvb.c usb/em28xx/em28xx.h http://git.linuxtv.org/media_tree.git - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help wanted patching saa7164 driver to work with Compro E900F
On Tue, Feb 4, 2014 at 5:29 AM, Daniel Playfair Cal daniel.playfair@gmail.com wrote: Hello all, I've been working on patching the saa7164 driver to work with the Compro Videomate Vista E900F. This is a PCI-e tuner card that seems to be almost identical to the Hauppauge HVR-2200, many versions of which are supported. I've had some success but there are a few problems Hey Daniel, Thanks for showing an interest in the driver. I've been trying to source one of these cards for quite a while, occasionally checking amazon etc. I can't seem to find anything in retail on amazon or on ebay. Where did you purchase the card? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help wanted patching saa7164 driver to work with Compro E900F
Where did you purchase the card? Hi Steve It is a pleasure, I'm finding it very interesting, and it would certainly be satisfying if I did get it working. Thankyou for writing the driver! You are welcome! I bought it from either msy.com.au or skycomp.com.au quite a few years ago, but I don't see it listed anywhere now in Australia except here (http://www.foxcomp.com.au/ProductDetail.asp?ID=10591, http://www.ht.com.au/part/AF826-Compro-VideoMate-Vista-E900F-DVB-T-HDTV-receiver-analogue-TV-radio-tuner-video-input-adapter-PCIe/detail.hts). I can't see many tv tuners for sale anymore. Crazy prices, a sign that its generally no longer available in quantity. HVR2200 is still a good option and generally available worldwide. I did find a E900F available in the UK (amazon - roughly $40 USD) but they won't ship it overseas. Grrr. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Developers blogs
Hi, http://www.kernellabs.com/blog/?page_id=2066 Antti does some good stuff and he's always worth reading. We do an incredible amount of Linux / V4L Driver video work at Kernel Labs, often on very specialized hardware. We dig deep into the hardware, bootloaders, embedded systems, fpgas, bus analyzers, CableCard, logic analyzers etc. I wish we had more time in our day to discuss and write about some of the projects we've worked on, or are working on. This in fact was one of our original goals. I guess this is my way of saying, sorry - I wish we had more time to help develop the newbies into the V4L community. That being said, thanks for mentioning our work. Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upstreaming SAA716x driver to the media_tree
On Mon, Jan 13, 2014 at 10:35 PM, Manu Abraham abraham.m...@gmail.com wrote: On Tue, Jan 14, 2014 at 12:20 AM, Steven Toth st...@kernellabs.com wrote: Manu, do you see any inconvenience in sending your driver to the linux_media tree? I'm available to place some effort on this task. I can push the 716x driver and whatever additional changes that I have later on this weekend, if that's okay with you. I never saw a push. Spliiting and cleaning up the patches took up more time than expected. Please wait a few days. Any news on this? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem getting sensible video out of Hauppauge HVR-1100 composite
It doesn't have a MPEG hardware compressor like the 350, you are reading raw pixel data (160Mbps) from the device node. Use an application that renders raw video data, such as TVTime. Ah, OK, thanks, I managed to miss that. I can get a picture out of it by using vlc's open-device. So it's working. But, flip me, it's spewing 800 MB+ for a minute's worth of video. That'd be ~48GB for an hour's TV (the intention is to use this for a MythTV PVR). Am I likely to be able to do anything about that? Even with post-transcoding that's going to be an excessive amount of filing to deal with :-( Generally not a good idea to do what you're doing. Generally a good idea to use a card with hardware compression features for a myth DVR. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem getting sensible video out of Hauppauge HVR-1100 composite
S-video requirements are a dying breed, unfortunately. Don't suppose you know of any? I see the Hauppauge HVR-2200 does, but it looks like the drivers for that are a bit too “fresh” for me to be able to risk another blind purchase (and may require kernel 3.2+, where I'm on SL6 with 2.6.~32). I'd backport the HVR2200 driver into 2.6.32 (it may already exist with analog features in .32 btw) and go with a 2200. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE EXPERIMENTAL] PCTV 80e driver
The result is at: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j-new That's excellent news. Well done. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem getting sensible video out of Hauppauge HVR-1100 composite
I set everything I know of up OK, but when I access /dev/video0 I get a garbled pink MPEG file (cat to a file, then mplayer to test). The DVB-T aspect of is works fine (tested using vlc). It doesn't have a MPEG hardware compressor like the 350, you are reading raw pixel data (160Mbps) from the device node. Use an application that renders raw video data, such as TVTime. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1800/1850 aka CX23885
I know the HVR-1850-MCE had working fm radio in Vista and that dmesg shows linux as seeing the radio. Analog support for the HVR-1850 in Linux was added late. It would not surprise me if FM radio support in that driver didn't exist or was not tested at all. I have not looked at that driver lately. Bob, the last time I worked on the driver the FM radio was not functional. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: avermedia A306 / PCIe-minicard (laptop) / CX23885
Hello
Hello Remi!
Thank you for looking at the Avercard with the CX23885 driver.
Antti, redirected me toward you,
What exactly is your question?
And
If it's at the least at the same stage as the HC81 , I think it deserve's to
be listed in cards.h
Possibly. Tell us again 1) what you have working reliably 2) what
isn't working but the driver is exposing and 3) what the driver is
exposing but has not been tested.
So people will know right away, that this card has been identified by the V4L
community, and dont have
Anyone working on that card would arrive here on the mailing list, I
don't think that's going to be an issue. I suggest you focus on
getting feature of the card working reliably, produce a patchset and
I'm sure it will get reviewed, refined then eventually merged.
Other comments below.
+ [CX23885_BOARD_AVERMEDIA_A306] = {
+.name = AVerTV Hybrid Minicard PCIe A306,
+.tuner_type = TUNER_XC2028,
+.tuner_addr = 0x61, /* 0xc2 1 */
+.tuner_bus = 1,
+.porta = CX23885_ANALOG_VIDEO,
+ .portb = CX23885_MPEG_ENCODER,
+.input = {{
+.type = CX23885_VMUX_TELEVISION,
+.vmux = CX25840_VIN2_CH1 |
+ CX25840_VIN5_CH2 |
+ CX25840_NONE0_CH3 |
+ CX25840_NONE1_CH3,
+.amux = CX25840_AUDIO8,
+}, {
+.type = CX23885_VMUX_SVIDEO,
+.vmux = CX25840_VIN8_CH1 |
+ CX25840_NONE_CH2 |
+ CX25840_VIN7_CH3 |
+ CX25840_SVIDEO_ON,
+.amux = CX25840_AUDIO6,
+}, {
+.type = CX23885_VMUX_COMPONENT,
+.vmux = CX25840_VIN1_CH1 |
+ CX25840_NONE_CH2 |
+ CX25840_NONE0_CH3 |
+ CX25840_NONE1_CH3,
+.amux = CX25840_AUDIO6,
+}},
+
+ }
Does the card have a MPEG2 hardware compressor and is it functioning
properly? (/dev/video1)
Are both svideo and component inputs working correctly in tvtime?
What about audio inputs? Does the card have any audio inputs and is
the driver acting and exposing those features correctly?
If not then please remove any of these sections.
+case CX23885_BOARD_AVERMEDIA_A306:
+cx_clear(MC417_CTL, 1);
+/* GPIO-0,1,2 setup direction as output */
+cx_set(GP0_IO, 0x0007);
+mdelay(10);
+/* AF9013 demod reset */
+cx_set(GP0_IO, 0x00010001);
+mdelay(10);
+cx_clear(GP0_IO, 0x00010001);
+mdelay(10);
+cx_set(GP0_IO, 0x00010001);
+mdelay(10);
+/* demod tune? */
+cx_clear(GP0_IO, 0x00030003);
+mdelay(10);
+cx_set(GP0_IO, 0x00020002);
+mdelay(10);
+cx_set(GP0_IO, 0x00010001);
+mdelay(10);
+cx_clear(GP0_IO, 0x00020002);
+/* XC3028L tuner reset */
+cx_set(GP0_IO, 0x00040004);
+cx_clear(GP0_IO, 0x00040004);
+cx_set(GP0_IO, 0x00040004);
+mdelay(60);
+break;
You're setting and clearing the GPIO direction enable registers (upper
16 bits), this isn't a good idea.
If you want to drive a GPIO in a specific direction (lower 8 bits),
perhaps for a reset, instead do this:
/* AF9013 demod reset */
cx_set(GP0_IO, 0x00010001); /* Establish the direction of the GPIO and
it's signal level)
mdelay(10);
cx_clear(GP0_IO, 0x0001); /* change the signal level, drive to low */
mdelay(10);
cx_set(GP0_IO, 0x0001); /* back to high */
mdelay(10);
Repeat this example for other other 'demod tune' and 3028 resets you
are doing, don't toggle the upper 16bits, else you leave the GPIO
floating, a bad idea.
- Steve
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: avermedia A306 / PCIe-minicard (laptop) / CX23885
Hello :) Thnx for the reply ! You are welcome. Well, I do not have the cables ... it's a laptop card, orginally for a Dell, I am doing my tests on an Acer, So you don't have a valid signal to test your changes with? The Video0 dev , composite/s-video is showing an analog signal, i guess a noise picture because not hooked-up, Hmm. Possibly, or possible the video decoder and video patch is not configured. but bottom half is sometimes green . So you haven't seen ANY stable video from any analog input? Analog scanning/reception = NULL , I might have to check again the antenna connexion, OK. For the Mpeg, negative, it's a 9013 chip, I still have to discecte the 9015 driver and pull-out the 9013 spcific data , iguess . OK. No mpeg either. So you don't have anything working so far, that's my reading of your current state. What I need the most, Is a big picture of the V4L API , like an organigram of what is where ( initialising this or that, linuxtv.org handeling setups - and controls) V4L2 Specification at linuxtv.org I there a dummy /test driver for PCIe cards I can study ? CX23885 is a good place to start. It's fully functional and matches the hardware you have to experiment with. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
I tried to apply the dvbsky-linux-3.9-hps-v2.diff to media_build.git (used do_patches.sh from http://www.selasky.org/hans_petter/distfiles/webcamd-3.10.0.7.tar.bz2), but I was not able to compile it. I already changed some includes, but then I got the next error. I just wanted to test if the si2168 module will work with si2165, but as I don't expect it to work I stopped trying to compile the si2168. I don't see a si2165 driver in the tarball. Did I miss something? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
FYI: The Si2168 driver is available from dvbsky-linux-3.9-hps-v2.diff inside. Maybe the Si2165 is similar? Excellent. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FW: lgdt3304
Carl, Thanks for writing. Please CC the mailing list at all times. Comments below. On Thu, Jul 11, 2013 at 12:48 AM, Carl-Fredrik Sundstrom c...@blueflowamericas.com wrote: I don't know what happened to the dmeg log formatting when I pasted it I cleaned it up below. I can't see anything obvious that fail when scanning, it just starts on the next frequency after getting a lock Ignore scan for now, use the azap tools with the -r arg and dvbtraffic tools in two different terminal sessions. azap -r FOX, will tune fox reliably for you, as your log messages below indicate tuner and demodulator lock. This is good. This implies the tuner and demodulator are most likely configured for RF reception, this is a big part of the problem solved. dvbtraffic will show all/any transmitter data coming from the demodulator and entering the kernel. The display is a breakdown pid by pid on how much data 'per pid' is being received by the kernel (from the card). In your case the answer will be zero, or occasional junk. Normal conditions shows 10-25 lines of stable text, show Mbp/s per pid. (Goal being 19.2) for stable reception. Probably will give up un this and get that other card. You're close, don't give up. Better yet, finish the work, publish it _THEN_ buy the other card, it's a little better in my opinion ;) Thanks /// Carl [ 4806.292479] lgdt3305_read_status: SIGNALEXIST INLOCK SYNCLOCK NOFECERR SNRGOOD [ 4806.292481] lgdt3305_read_reg: reg: 0x011d [ 4806.292957] lgdt3305_read_cr_lock_status: (1) CLOCKVSB [ 4807.448098] lgdt3305_get_tune_settings: tridentsx@tridentsx-P5K-E:~/.kde/share/apps/kaffeine$ azap FOX using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 599028615 Hz video pid 0x0031, audio pid 0x0034 status 01 | signal | snr | ber | unc ca8b | status 1f | signal 8e53 | snr 00c4 | ber | unc | FE_HAS_LOCK status 1f | signal 907a | snr 00c5 | ber | unc 0165 | FE_HAS_LOCK status 1f | signal 8dc8 | snr 00c4 | ber | unc | FE_HAS_LOCK status 1f | signal 8d3f | snr 00c1 | ber | unc | FE_HAS_LOCK This is very good. The tuner and demodulator are locked to FOX and your error counts are well within acceptable ranges. Congratulations. However when I try to view or scan channels in mplayer or kaffeine it can't find them and there are some timeouts Similar to the ones I got in scan utility. This is invariably because the electrical interface between the LG demod and the host controller (PCIe or USB - whatever your card is) has been incorrectly configured, or not configured at all. I don't know the specifics of that card so I need to talk generally here. 1. Demodulators and host controllers usually transmit data over either a serial or parallel data bus. Each bus has slightly different control lines to indicate such things as CLOCK, START_OF_PACKET, TSVAL, TSERR, along with the data lines. The control lines help the demod tell the host controller about the state of the data on the bus. 2. The demod and the host controller need to be configured identically else the host controller won't receive any data from the demod, or best case will receive garbage. Linux drivers can vary in respect to windows drivers here in terms of how the bus is configured, somewhat, but some hard and fast rules still apply. a) Assuming both the host controller and the LG support both serial and parallel (I haven't checked) you'll need to configure that option correctly to match the card. You can't just 'pick one and hope', you have to pick the right mode. Visual inspection of the PCB helps, or knowing their either end of the bus can only be serial due to the nature of the silicon implementation also helps. Or simply, try all combinations. b) Control lines such as TSVALID, TSERR, START_OF_PACKET usually have polarities HIGH or LOW. These can vary between Windows and Linux, it doesn't matter if they do, as long as each end matches correctly. I personally like to match windows by probing the bus visually with either a logic analyzer or a scope on pads in/around the demodulator. Trial and error changing these configuration settings at one end (usually the demodulator) should very quickly start to show garbage or real data in dvbtraffic. In my experience both ends have their own defaults and they never match. Leave the host controller alone and adjust the demodulator unless the demodulator in questions simply cannot be controlled (highly unusual). Don't look at scan until dvbtraffic shows real and stable pid data that doesn't jump about the screen and look like junk. Expect dvbtraffic to show you between 10-25 lines of stable data, constantly updating at roughly 19.2Mbps total throughput. Review the card, determine whether its a serial or parallel bus (or guess), then review the control line polarities. This should help. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: lgdt3304
On Tue, Jul 9, 2013 at 9:40 PM, Carl-Fredrik Sundstrom c...@blueflowamericas.com wrote: I don't have digital cable only over the air ATSC. No one else on this list has this card ? You are very welcome, thank you. We generally recommend Linux users purchase cards that are already supported (or semi supported), such as the HVR2250. If you're keen enough to tackle adding support for a new board then that's great news, but very few people usually have experience with hardware not yet supported. The channels.conf is capable of support digital cable and ATSC, simply change the modulation scheme and your target frequency and try again. A quick google for an equivalent ATSC channels.conf provides a lot of useful information. Create your channels.conf to match your target frequencies in Hz and use azap to debug. Eg. KPAX-CW:177028615:8VSB:65:68:2 Thanks /// Carl -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Steven Toth Sent: Tuesday, July 09, 2013 9:54 AM To: Carl-Fredrik Sundstrom Cc: Devin Heitmueller; linux-media@vger.kernel.org Subject: Re: lgdt3304 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tune to: 57028615:8VSB WARNING: tuning failed!!! tune to: 57028615:8VSB (tuning failed) I don't have a box in front of me but that's usually a sign that the frequency details you are passing in are bogus, so the tuner driver is rejecting it. Check your command line tuning tools and args. Here's a one line channels.conf for azap (US digital cable) that works fine, and the azap console output: ch86:59700:QAM_256:0:0:101 stoth@mythbackend:~/.azap$ azap ch86 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 59700 Hz video pid 0x, audio pid 0x status 00 | signal | snr b770 | ber | unc | status 1f | signal 0154 | snr 0154 | ber 00ad | unc 00ad | FE_HAS_LOCK status 1f | signal 0156 | snr 0156 | ber | unc | FE_HAS_LOCK -- Steven Toth - Kernel Labs http://www.kernellabs.com -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lgdt3304
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tune to: 57028615:8VSB WARNING: tuning failed!!! tune to: 57028615:8VSB (tuning failed) I don't have a box in front of me but that's usually a sign that the frequency details you are passing in are bogus, so the tuner driver is rejecting it. Check your command line tuning tools and args. Here's a one line channels.conf for azap (US digital cable) that works fine, and the azap console output: ch86:59700:QAM_256:0:0:101 stoth@mythbackend:~/.azap$ azap ch86 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 59700 Hz video pid 0x, audio pid 0x status 00 | signal | snr b770 | ber | unc | status 1f | signal 0154 | snr 0154 | ber 00ad | unc 00ad | FE_HAS_LOCK status 1f | signal 0156 | snr 0156 | ber | unc | FE_HAS_LOCK -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lgdt3304
On Thu, Jun 27, 2013 at 11:00 PM, Carl-Fredrik Sundstrom c...@blueflowamericas.com wrote: I am able to detect two lgdt3304 one on each i2c bus now. As you suspected I had to set GPIO pin 17 for them to come alive. Now to my next question, how do I attach two front ends I have two lgdt3304 and two TDA18271HD/C2 Is there a good driver I can look at where they do that ? The SAA7164 driver (amongst others) demonstrates how to expose multiple tuners on a single card via multiple adapters, /dev/dvb/adapterX. The cx88 driver demonstrates how to expose multiple tuners/demods via a single transport bus, via a single dvb adapter. /dev/dvb/adapter0/frontendX - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lgdt3304
I get so far that I can load a basic driver by modifying the existing saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect the LGDT3304 when attaching it using the 3305 driver. A GPIO holding the 3304 in reset? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HD Capture Card (HDMI and Component) output raw pixels
You are right. According to your numbers, this card can't work. So why would BlackMagic design an HDMI capture card with only one PCIe lane if it can't possibly work? It must work somehow. I must be missing some crucial piece of information. Blackmagic's Intensity card doesn't support 1080p. None of the raw video HD cards I've ever worked on do 1080p over pcie x1. 1080i max and it's 8 or 10bit colorspace, not 24bit (IIRC). -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ViewCast O820E capture support added
Mauro, please read below, a new set of patches I'm submitting for merge. On Thu, Aug 16, 2012 at 2:49 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Thu August 16 2012 19:39:51 Steven Toth wrote: So, I've ran v4l2-compliance and it pointed out a few things that I've fixed, but it also does a few things that (for some reason) I can't seem to catch. One particular test is on (iirc) s_fmt. It attempts to set ATSC but by ioctl callback never receives ATSC in the norm/id arg, it actually receives 0x0. This feels more like a bug in the test. Either way, I have some if (std ATSC) return -EINVAL, but it still appears to fail the test. Oddly enough. If I set tvnorms to something valid, then compliance passes but gstreamer fails to run, looks like some kind of confusion about either the current established norm, or a failure to establish a norm. For the time being I've set tvnorms to 0 (with a comment) and removed current_norm. Well, this needs to be sorted, because something is clearly amiss. Agreed. I just can't see what's wrong. I may need your advise / eyeballs on this. I'd be willing to provide logs that show gstreamer accessing the driver and exiting. It needs fixed, I've tried, I just can't see why gstreamer fails. On the main topic of merge As promised, I spent quite a bit of time this week reworking the code based on the feedback. I also flattened all of these patches into a single patchset and upgraded to the latest re-org tree. The source notes describe in a little more detail the major changes: http://git.kernellabs.com/?p=stoth/media_tree.git;a=commit;h=f295dd63e2f7027e327daad730eb86f2c17e3b2c Mauro, so, I hereby submit for your review/merge again, the updated patchset. *** Please comment. *** The following changes since commit 9b78c5a3007e10a172d4e83bea18509fdff2e8e3: [media] b2c2: export b2c2_flexcop_debug symbol (2012-08-17 11:09:19 -0300) are available in the git repository at: git://git.kernellabs.com/stoth/media_tree.git o820e Steven Toth (4): [media] adv7441a: Adding limited support for a new video decoder. [media] adv7441a: Adding the module author macro [media] pcm3052: Adding support for a new ADC. [media] vc8x0: Adding support for the ViewCast O820E Capture Card. drivers/media/i2c/Kconfig | 18 + drivers/media/i2c/Makefile|2 + drivers/media/i2c/adv7441a.c | 4258 + drivers/media/i2c/pcm3052.c | 248 ++ drivers/media/pci/Kconfig |1 + drivers/media/pci/Makefile|1 + drivers/media/pci/vc8x0/Kconfig | 15 + drivers/media/pci/vc8x0/Makefile |9 + drivers/media/pci/vc8x0/vc8x0-audio.c | 741 + drivers/media/pci/vc8x0/vc8x0-buffer.c| 338 +++ drivers/media/pci/vc8x0/vc8x0-cards.c | 138 + drivers/media/pci/vc8x0/vc8x0-channel.c | 805 ++ drivers/media/pci/vc8x0/vc8x0-core.c | 678 + drivers/media/pci/vc8x0/vc8x0-display.c | 1359 + drivers/media/pci/vc8x0/vc8x0-dma.c | 2677 ++ drivers/media/pci/vc8x0/vc8x0-fw.c| 466 drivers/media/pci/vc8x0/vc8x0-i2c.c | 368 +++ drivers/media/pci/vc8x0/vc8x0-reg.h | 214 ++ drivers/media/pci/vc8x0/vc8x0-timestamp.c | 156 ++ drivers/media/pci/vc8x0/vc8x0-video.c | 2796 +++ drivers/media/pci/vc8x0/vc8x0.h | 732 + include/media/adv7441a.h | 88 + include/media/v4l2-chip-ident.h |6 + 23 files changed, 16114 insertions(+), 0 deletions(-) create mode 100644 drivers/media/i2c/adv7441a.c create mode 100644 drivers/media/i2c/pcm3052.c create mode 100644 drivers/media/pci/vc8x0/Kconfig create mode 100644 drivers/media/pci/vc8x0/Makefile create mode 100644 drivers/media/pci/vc8x0/vc8x0-audio.c create mode 100644 drivers/media/pci/vc8x0/vc8x0-buffer.c create mode 100644 drivers/media/pci/vc8x0/vc8x0-cards.c create mode 100644 drivers/media/pci/vc8x0/vc8x0-channel.c create mode 100644 drivers/media/pci/vc8x0/vc8x0-core.c create mode 100644 drivers/media/pci/vc8x0/vc8x0-display.c create mode 100644 drivers/media/pci/vc8x0/vc8x0-dma.c create mode 100644 drivers/media/pci/vc8x0/vc8x0-fw.c create mode 100644 drivers/media/pci/vc8x0/vc8x0-i2c.c create mode 100644 drivers/media/pci/vc8x0/vc8x0-reg.h create mode 100644 drivers/media/pci/vc8x0/vc8x0-timestamp.c create mode 100644 drivers/media/pci/vc8x0/vc8x0-video.c create mode 100644 drivers/media/pci/vc8x0/vc8x0.h create mode 100644 include/media/adv7441a.h Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ViewCast O820E capture support added
, to the adv7604 and ad9389b. Agreed. On the one hand, there is just too much identical code to justify two fully independent drivers, but on the other hand there are too many differences as well. I think it is possible to refactor out clearly common parts that do not directly touch on registers. I don't know for certain yet, though. It's tough. I air on the side of keeping the code reasonable and readable, easy to digest and support - even if it means small amounts of duplication. If the goal of LinuxTV is to welcome less experience video kernel developers then it's off-putting to have very abstract, scientific driver creations that can only be maintained by one or two people. I don't know the 7604 or the 9389 but I'd suggest simple is better (for the rest of the group), unless they're 99% identical (unlikely). As always, I do welcome and appreciate your comments and thoughts, no flames from me. I do find the 'MANDATORY' comments worthy of discussion, or perhaps I've miss-understood something. No, you understood it perfectly :-) Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ViewCast O820E capture support added
not triggering. Format ioctls: fail: v4l2-test-formats.cpp(252): duplicate format 56595559 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL ^^^ This is don't get. The compliance code implies you should never have a duplicate pixel format. Perhaps because I have multiple identical width/height formats with differing framerates and this confuses things. test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: Not Supported test VIDIOC_G_FMT: OK fail: v4l2-test-formats.cpp(549): VBI Capture is valid, but no TRY_FMT was implemented test VIDIOC_TRY_FMT: FAIL fail: v4l2-test-formats.cpp(600): Video Capture is valid, but no S_FMT was implemented test VIDIOC_S_FMT: FAIL test VIDIOC_G_SLICED_VBI_CAP: Not Supported ^^^ I've looked at the S_FMT many many times and tried a few workaround. effectively the compliance tool sets the struct to FF, passed ANY_FIELD and sets set. I refuse the call in the driver, which I think it's bogus. The Spec is unclear what to do but the compliance tool still fails. If you have thoughts on this then I'd appreciate it. Buffer ioctls: fail: v4l2-test-buffers.cpp(76): can_stream !mmap_valid !userptr_valid test VIDIOC_REQBUFS/CREATE_BUFS: FAIL test read/write: test read/write: OK The tool shows: fail_on_test(can_stream !mmap_valid !userptr_valid); I'm drawing a blank on this failure. I don't deal with either of these, they're deep in video buf. A bogus error, or something I've overlooked in videobuf1? Total: 36, Succeeded: 29, Failed: 7, Warnings: 0 (VBI compliance has a couple more failures I'll take care of this afternoon). Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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 Hauppauge Nova-S-Plus.
And regarding 2 hours, normally it's about 2 or 3 days before fails. Sometimes it's some hours later. Totally random. For example today I restarted this morning, and no failure for the moment on any of both transponders. The problem is really very strange. Hmm. I don't know then. Other Hauppauge commercial customers are using those cards 7x24 with no problem, although I don't know with which kernel and or/driver version. My guess is that the the PCI reset which occurs during a reboot is fixing or resolving some issue with either an internal CX23883 issue (unlikely) or more likely, the tuner/demod/LNB power block becomes unstable, is not reset by reloading the driver (as it should be) and the only course of action is a full reboot. I just don't know why other users would not be seeing that. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ViewCast O820E capture support added
On Mon, Aug 13, 2012 at 1:36 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 13-08-2012 12:49, Hans Verkuil escreveu: On Mon August 13 2012 16:46:45 Steven Toth wrote: Hans, Thanks for your feedback. Oh dear. I don't think you're going to like my response, but I think we know each other well enough to realize that neither of us are trying to antagonize or upset either other. We're simply stating our positions. Please read on. I didn't think you'd like my response either :-) You probably won't like my answer too, yet I'm also simply stating my positions. Hans / Mauro, thank you for your comments and review, very good feedback and technical discussion. Truly, thank you. :) While I don't necessarily agree with Mauro that adoption of subdev is MANDATORY (in the larger sense of the kernel driver development - and common practices throughout the entire source base), I do hear and value your comments and concerns from a peer review perspective. 1) A handful of simple improvements have been suggested, Eg. ioctl_unlocked, double-checking v4l2-compliance, try_fmt, /proc removal, firmware loading etc Ack. I have no objections. Items like this are fairly trivial, easy to address, I can absorb this and provide new patches quickly and easily. I'll go back over the detailed comments this weekend and prepare additional patches (and retest). 2) ... and some larger discussion items have been raised, Eg. Absorbing more of the V4L2 kernel infrastructure into the vc8x0 driver vs a fairly self-contained driver with very limited opportunities for future breakage. Are you really willing to say that all drivers, with unique and new pieces of silicon, need to be split out into independent modules, adopting a subdev type interfaces or mainline merge is refused? It's not that I'm asking you to merge duplicate functionality, duplicate driver code, replicating functionality for new hardware or for an existing modules (tuner/demod/whatever). (Like has already happened in the past - 18271 for example). If the answer is Yes, then my second questions is: Assuming the comments / issues mentioned in #1 are addressed, are you really willing to stand up in front of the world-wide Kernel development community and justify why a driver that passes user-facing v4l2-compliance tests, is fairly clean, passes 99% of the reasonable checkpatch rules, is fully operational, cannot be merged? Really? Is this truly an illegal or inappropriate driver implementation that would prohibit mainline merge? The ViewCast 820 is a (circa) $1800 video capture card. It's not the kind of hardware that everyone has laying around for regression testing purposes. If I 1) split this up and people begin to absorb ad7441 functionality into other designs, and start patching it and 2) adopt the subdev framework for that matter... then nobody is able to regression test the impact to the 820. That puts an incredible amount of burden on me. I'm attempting to mitigate all of this risk, but also provide a GPL driver so everyone can benefit - without creating a future maintenance / regression problem, by relying on subsystems the driver simply doesn't need. As always, I do welcome and appreciate your comments and thoughts, no flames from me. I do find the 'MANDATORY' comments worthy of discussion, or perhaps I've miss-understood something. Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question Hauppauge Nova-S-Plus.
I've been working for some time with those devices, and recently I have a problem which I've never seen before. The point is that I tune properly frequency and I start watching all channels, but after some time one or 2 tuners stops, and you cannot tune again any frequency until you reboot all server. Interesting. If it was previously working fine, and very reliably, then what has changed in your software stack or environment? What happens if you rmmod and modprobe the driver? Does this help? One thing very strange there is that always are the same tuners which fails. Signal is OK. Do you mean it's always the same physical card that fails, or any of your nova-s-plus cards fail in the same way? I don't have any error on syslog nor dmesg. And once you reboot it works again. Have anyone seen this problem before and can help me please? I haven't seen this before. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ViewCast O820E capture support added
agree. It can probably be removed altogether. - Using videobuf2 is very much recommended. I went with what I know to be honest. I neither agree nor disagree with your comments. If videobuf2 is supported on 2.6.3x then this is good news. - Please run v4l2-compliance and fix any reported issues! It's a pretty big driver, so I only looked skimmed the patch, but these are IMHO fairly major issues. As it stands it is only suitable to be merged in drivers/staging/media. I'm not sure I agree. I think I don't agree in general that subdev and the control framework is mandatory for any driver. I think they are accelerator frameworks designed to help. I my case I don't think they do. So I avoided using them. I guess Mauro has the final decision. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question Hauppauge Nova-S-Plus.
The problem is cronic, is allways there. And the only recover solution that I found is to reboot server. And if you reboot the server, and immediately re-use the failed card, it works reliably again for another 2 hours? In other words, it's not heat / environment related? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ViewCast O820E capture support added
Hi Mauro, A new PCIe bridge driver below. It was released a couple of months ago to the public, probably about time we got this into the request queue. I'll review the linux-firmware additions shortly, I have a firmware blob and flexible license for the distros. The following changes since commit da2cd767f537082be0a02d83f87e0da4270e25b2: [media] ttpci: add support for Omicom S2 PCI (2012-08-12 14:41:26 -0300) are available in the git repository at: git://git.kernellabs.com/stoth/media_tree.git o820e Steven Toth (1): [media] vc8x0: Add support for the ViewCast O820E card. drivers/media/video/Kconfig |2 + drivers/media/video/Makefile|1 + drivers/media/video/vc8x0/Kconfig | 14 + drivers/media/video/vc8x0/Makefile | 10 + drivers/media/video/vc8x0/vc8x0-ad7441.c| 3057 +++ drivers/media/video/vc8x0/vc8x0-audio.c | 736 +++ drivers/media/video/vc8x0/vc8x0-buffer.c| 338 +++ drivers/media/video/vc8x0/vc8x0-cards.c | 138 ++ drivers/media/video/vc8x0/vc8x0-channel.c | 934 drivers/media/video/vc8x0/vc8x0-core.c | 887 drivers/media/video/vc8x0/vc8x0-display.c | 1359 drivers/media/video/vc8x0/vc8x0-dma.c | 2677 +++ drivers/media/video/vc8x0/vc8x0-eeprom.c| 71 + drivers/media/video/vc8x0/vc8x0-fw.c| 429 drivers/media/video/vc8x0/vc8x0-i2c.c | 290 +++ drivers/media/video/vc8x0/vc8x0-pcm3052.c | 192 ++ drivers/media/video/vc8x0/vc8x0-reg.h | 214 ++ drivers/media/video/vc8x0/vc8x0-timestamp.c | 156 ++ drivers/media/video/vc8x0/vc8x0-vga.c | 430 drivers/media/video/vc8x0/vc8x0-video.c | 2650 +++ drivers/media/video/vc8x0/vc8x0.h | 995 + 21 files changed, 15580 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/vc8x0/Kconfig create mode 100644 drivers/media/video/vc8x0/Makefile create mode 100644 drivers/media/video/vc8x0/vc8x0-ad7441.c create mode 100644 drivers/media/video/vc8x0/vc8x0-audio.c create mode 100644 drivers/media/video/vc8x0/vc8x0-buffer.c create mode 100644 drivers/media/video/vc8x0/vc8x0-cards.c create mode 100644 drivers/media/video/vc8x0/vc8x0-channel.c create mode 100644 drivers/media/video/vc8x0/vc8x0-core.c create mode 100644 drivers/media/video/vc8x0/vc8x0-display.c create mode 100644 drivers/media/video/vc8x0/vc8x0-dma.c create mode 100644 drivers/media/video/vc8x0/vc8x0-eeprom.c create mode 100644 drivers/media/video/vc8x0/vc8x0-fw.c create mode 100644 drivers/media/video/vc8x0/vc8x0-i2c.c create mode 100644 drivers/media/video/vc8x0/vc8x0-pcm3052.c create mode 100644 drivers/media/video/vc8x0/vc8x0-reg.h create mode 100644 drivers/media/video/vc8x0/vc8x0-timestamp.c create mode 100644 drivers/media/video/vc8x0/vc8x0-vga.c create mode 100644 drivers/media/video/vc8x0/vc8x0-video.c create mode 100644 drivers/media/video/vc8x0/vc8x0.h Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL / Firmware] O820E firmware release
Mauro, The firmware related to the O820 driver addition below. I'm not sure how you deal with this but here's the license and firmware blob. I don't see a direct git repo for linux-firmware on linuxtv.org, so this comes from kernel.org dwmw2/linux-firmware.git The following changes since commit 7560108a2c94a62056fa82d912282b901aa0904f: Add syscfg (different frequency) and patch for AR3002 2.2.1. (2012-07-19 04:02:52 +0100) are available in the git repository at: git://git.kernellabs.com/stoth/linux-firmware.git master Steven Toth (1): [media] vc8x0: Adding the firmware for the FPGA LICENSE.vc8x0 | 18 ++ v4l-osprey-820e-firmware-v1.5.0.rom | Bin 0 - 1932760 bytes 2 files changed, 18 insertions(+), 0 deletions(-) create mode 100644 LICENSE.vc8x0 create mode 100644 v4l-osprey-820e-firmware-v1.5.0.rom Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
As we did in 2012, we're planning to do a media summit again at KS/2012. Excellent. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'm interested. I like the idea of some cross-subsystem pollination, talking with the ALSA people for example ... and given that ARM is growing, I'd like to catch up and understand where ARM silicon is heading in terms of embedded video decoding and any support for hardware specific features we may / may not have / need. ... and of course, if we have anyone from Intel then we should be asking if/when their Intel Media SDK (hardware H264 encoding) is going to become a reality, or possibly kickstart that process. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tips is OOPSing with basic v4l2 controls - Major breakage
On Sun, Jul 15, 2012 at 6:43 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Sun July 15 2012 01:12:02 Steven Toth wrote: Tip is oopsing the moment the V4L2 API is exercised, Eg. v4l2-ctl or tvtime. Its unusable at this point. It's fixed here: https://patchwork.kernel.org/patch/1168931/ We're all waiting for Mauro to return from vacation :-) Thanks Hans. :) - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
staging/for_v3.6 is currently broken
Looks like the new union in v4l2_ioctl_info breaks things.
-bash-4.1$ make -j6
make[1]: Nothing to be done for `all'.
CHK include/linux/version.h
CHK include/generated/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
CC drivers/media/video/v4l2-ioctl.o
drivers/media/video/v4l2-ioctl.c:1848:517: error: unknown field ‘func’
specified in initializer
drivers/media/video/v4l2-ioctl.c:1848:517: warning: missing braces
around initializer
drivers/media/video/v4l2-ioctl.c:1848:517: warning: (near
initialization for ‘v4l2_ioctls[0].anonymous’)
drivers/media/video/v4l2-ioctl.c:1848:517: warning: initialization
makes integer from pointer without a cast
drivers/media/video/v4l2-ioctl.c:1849:644: error: unknown field ‘func’
specified in initializer
drivers/media/video/v4l2-ioctl.c:1849:644: warning: initialization
makes integer from pointer without a cast
Removing the union and the code compiles, although that probably
wasn't the original authors intension.
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 70e0efb..1f090c4 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1802,11 +1802,9 @@ struct v4l2_ioctl_info {
unsigned int ioctl;
u32 flags;
const char * const name;
- union {
u32 offset;
int (*func)(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *p);
- };
void (*debug)(const void *arg, bool write_only);
};
FYI
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: staging/for_v3.6 is currently broken
On Sat, Jul 14, 2012 at 6:36 PM, Andy Walls awa...@md.metrocast.net wrote: Steven Toth st...@kernellabs.com wrote: Looks like the new union in v4l2_ioctl_info breaks things. I think Hans fixed it another way: http://www.spinics.net/lists/linux-media/msg50234.html Thanks Andy. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tips is OOPSing with basic v4l2 controls - Major breakage
Tip is oopsing the moment the V4L2 API is exercised, Eg. v4l2-ctl or tvtime. Its unusable at this point. Verified with two different drivers (cx23885 and SAA7164), same oops. [ 120.255980] BUG: unable to handle kernel NULL pointer dereference at 0016 [ 120.255992] IP: [c074efd6] v4l2_queryctrl+0x21/0x105 [ 120.256000] *pdpt = 10de8001 *pde = [ 120.256005] Oops: [#1] SMP [ 120.256009] Modules linked in: mt2131 s5h1409 tda8290 tuner cx25840 cx23885 videobuf_dma_sg altera_stapl cx2341x tda18271 videobuf_dvb videobuf_core v4l2_common altera_ci btcx_risc tveeprom fuse nouveau ttm drm_kms_helper drm i2c_algo_bit video nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc ipv6 cpufreq_ondemand acpi_cpufreq mperf uinput pl2303 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd coretemp r8169 iTCO_wdt soundcore i2c_i801 crc32c_intel iTCO_vendor_support snd_page_alloc usbserial i2c_core mii microcode serio_raw pcspkr mxm_wmi floppy wmi [last unloaded: scsi_wait_scan] [ 120.256077] [ 120.256080] Pid: 2659, comm: tvtime Not tainted 3.4.0-rc7+ #2 Gigabyte Technology Co., Ltd. P67A-UD4-B3/P67A-UD4-B3 [ 120.256088] EIP: 0060:[c074efd6] EFLAGS: 00010202 CPU: 0 [ 120.256092] EIP is at v4l2_queryctrl+0x21/0x105 [ 120.256095] EAX: ffea EBX: 0002 ECX: d1565c00 EDX: 00980900 [ 120.256099] ESI: d17d7e58 EDI: e0f8191c EBP: d17d7db8 ESP: d17d7da4 [ 120.256103] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 120.256106] CR0: 80050033 CR2: 0016 CR3: 10de6000 CR4: 000407f0 [ 120.256110] DR0: DR1: DR2: DR3: [ 120.256114] DR6: 0ff0 DR7: 0400 [ 120.256117] Process tvtime (pid: 2659, ti=d17d6000 task=d27dcb60 task.ti=d17d6000) [ 120.256121] Stack: [ 120.256123] 0020 d04d11cc d04e0300 d0da3c00 e0f8191c d17d7dd0 c074b4a3 d17d7e58 [ 120.256134] c0aaaba0 d1565c00 d17d7e2c c074b989 d17d7e58 d04d11cc cfee0840 [ 120.256344] d0da3c00 d04e0300 e0f8191c d17d7e58 00459196 c0aaaba0[ 120.256353] Call Trace: [ 120.256357] [c074b4a3] v4l_queryctrl+0x40/0x5f [ 120.256361] [c074b989] __video_do_ioctl+0x199/0x29c [ 120.256368] [c0445624] ? prepare_signal+0x72/0x169 [ 120.256373] [c0604848] ? _copy_from_user+0x3e/0x52 [ 120.256377] [c074bcdd] video_usercopy+0x251/0x30b [ 120.256381] [c074b7f0] ? v4l2_is_known_ioctl+0x22/0x22 [ 120.256386] [c0445624] ? prepare_signal+0x72/0x169 [ 120.256392] [c04de360] ? handle_pte_fault+0x32f/0x8d0 [ 120.256397] [c0459184] ? need_resched+0x14/0x1e [ 120.256401] [c074bdae] video_ioctl2+0x17/0x19 [ 120.256405] [c074b7f0] ? v4l2_is_known_ioctl+0x22/0x22 [ 120.256411] [c074805d] v4l2_ioctl+0xc1/0xdd [ 120.256415] [c0445624] ? prepare_signal+0x72/0x169 [ 120.256420] [c0747f9c] ? v4l2_open+0xf2/0xf2 [ 120.256425] [c050bbb4] do_vfs_ioctl+0x491/0x4c7 [ 120.256431] [c08470ee] ? do_page_fault+0x2ce/0x32b [ 120.256436] [c045ec09] ? sched_clock_cpu+0x42/0x14d [ 120.256444] [c0476284] ? tick_program_event+0x29/0x2d [ 120.256996] [c04e1c49] ? do_munmap+0x201/0x218 [ 120.257438] [c0445624] ? prepare_signal+0x72/0x169 [ 120.257892] [c050bc32] sys_ioctl+0x48/0x6a [ 120.258351] [c0426c5d] ? smp_apic_timer_interrupt+0x69/0x76 [ 120.258819] [c0849c1f] sysenter_do_call+0x12/0x28 [ 120.259290] [c0445624] ? prepare_signal+0x72/0x169 (gdb) list *(v4l2_queryctrl + 0x21) 0xc074efd6 is in v4l2_queryctrl (drivers/media/video/v4l2-ctrls.c:1917). 1912struct v4l2_ctrl *ctrl; 1913 1914if (hdl == NULL) 1915return -EINVAL; 1916 1917mutex_lock(hdl-lock); 1918 1919/* Try to find it */ 1920ref = find_ref(hdl, id); 1921 (gdb) FYI -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPIO interface between DVB sub-drivers (bridge, demod, tuner)
There is set_property() and get_property() callbacks defined for FE already. But those are not used. My opinion is that those callbacks should be changed to deliver data for demodulator and for tuner too instead of current method - which is common huge properties cache structure shared between all sub-drivers. I don't like it all as it is stupid to add stuff that common structure for every standard we has. Lets take example device that supports DVB-C and other device supports ISDB-T. How many common parameters we has? I think only one - frequency. All the others are just waste. When we did DVB V5 for S2 we added set/get property for the demodulators, from memory I had some cx24116 S2 specifics that I was passing, and I expected other demod drivers to adopt the same mechanism. It was fairly obvious at the time that we needed a much more generic way to pass internel controls around from the core to the demods. The cache was to support backwards compatible V3 interfaces and demods, amongst other things. No reason why a new demod today could not support get/set only for configuration. What I think I am going to make new RFC which changes that so every parameter from userspace is passed to the demodulator driver (using set_property() - change it current functionality) and not cached to the common cache at all. Shortly: change current common cache based parameter transmission to happen set parameter to demodulator one by one. The other reason for the common cache was to allow sets of parameters to be pushed into the kernel from apps then, at the most appropriate time, tuned. The order of operations becomes irrelevant, so the cache is highly useful, else you end up with demods caching all of their own parameters anyway, many drivers duplicating a frequency field in their provate contexts, for example. It's hard to imaging how not using the cache today. What did you ever decide about the enable/disable of the LNA? And, how would the bridge do that in your proposed solution? Via the proposed GPIO interface? I sent PATCH RFC for DVB API to add LNA support yesterday. It is new API Understood, thanks for the note. -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: GPIO interface between DVB sub-drivers (bridge, demod, tuner)
Resend in plaintext, it got bounced from vger. On Thu, Jul 12, 2012 at 4:49 PM, Steven Toth st...@kernellabs.com wrote: Is there anyone who could say straight now what is best approach and where to look example? I don't have an answer but the topic does interest me. :) Nobody understands the relationship between the bridge and the sub-component as well as the bridge driver. The current interfaces are limiting in many ways. We solve that today with rather ugly 'attach' structures that are inflexible, for example to set gpios to a default state. Then, once that interface is attached, the bridge effectively loses most of the control to the tuner and/or demod. The result is a large disconnect between the bridge and subcomponents. Why limit any interface extension to GPIOs? Why not make something a little more flexible so we can pass custom messages around? get(int parm, *value) and set(int parm, value) Bridges and demods can define whatever parmid's they like in their attach headers. (Like we do for callbacks currently). For example, some tuners have temperature sensors, I have no ability to read that today from the bridge, other than via I2C - then I'm pulling i2c device specific logic into the bridge. :( It would be nice to be able to demod/tunerptr-get(XC5000_PARAM_TEMP, value), for example. Get/Set I/F is a bit of a classic, between tuners and video decoders. This (at least a while ago) was poorly handled, or not at all. Only the bridge really knows how to deal with odd component configurations like this, yet it has little or no control. I'd want to see a list of 4 or 5 good get/set use cases though, with some unusual parms, before I'd really believe a generic get/set is more appropriate than a strongly typed set of additional function pointers. What did you ever decide about the enable/disable of the LNA? And, how would the bridge do that in your proposed solution? Via the proposed GPIO interface? Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: ViXS XCode 2100 Series TV NTSC/ATSC FM Tuner Card
It's not supported by Linux and last I checked no technical documentation is available for the silicon. -- Steven Toth - Kernel Labs http://www.kernellabs.com On Fri, Mar 23, 2012 at 3:17 PM, Vikas N Kumar vikasnku...@users.sourceforge.net wrote: Hi I am interested to know if there exists any support for the ViXS XCode 2100 Series cards ? I have looked and not found any viable support for the card chipset except for some forums mentioning ivtv as a driver. If there is anyone working on this or if there is some guidance I would like to help out and provide support for this TV tuner card. Below are the full details of the card that I have. Any help or information is appreciated ? Thanks. # lspci -vv -d 1745: 02:00.0 Multimedia controller: ViXS Systems, Inc. XCode 2100 Series Subsystem: ASUSTeK Computer Inc. Device 48b0 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: 64 bytes Interrupt: pin A routed to IRQ 10 Region 0: Memory at fdf0 (64-bit, prefetchable) [size=1M] Region 2: Memory at feaf (32-bit, non-prefetchable) [size=64K] Region 4: I/O ports at unassigned Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [60] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 128ns, L1 2us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 4us, L1 64us ClockPM- Surprise- 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: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [140 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- -- http://www.vikaskumar.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 -- 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: cx25840: improve audio for cx2388x drivers
Miroslav, what cards did you test with? 2012/1/14 Miroslav Slugeň thunder@gmail.com: Searching for testers, this patch is big one, it was more then week of work and testing, so i appriciate any comments and recommendations. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)
The Nanostick works fine for between 5 and 25 minutes and then without any error messages cuts out. The TS drops to a tiny stream of non-TS data. It seems to contain a lot of 0x00s and 0xffs. What does femon show for demodulator statistics? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] git://git.kernellabs.com/stoth/cx23885-hvr1850-fixups.git
Mauro, Some changes to allow the querying of the NO_SIGNAL status feature on the cx25840 video decoder. The following changes since commit 45447e1e18131590203dba83f9044d6c48448e54: [media] cx25840: Added g_std support to the video decoder driver (2012-01-04 19:16:15 -0500) are available in the git repository at: git://git.kernellabs.com/stoth/cx23885-hvr1850-fixups.git staging/for_v3.3 Steven Toth (2): [media] cx25840: Add support for g_input_status [media] cx23885: Query the CX25840 during enum_input for status drivers/media/video/cx23885/cx23885-video.c | 9 + drivers/media/video/cx25840/cx25840-core.c | 16 2 files changed, 25 insertions(+), 0 deletions(-) Many thanks, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: subdev support for querying struct v4l2_input *
In the cx23885 driver as part of vidioc_enum_input call, I have a need to return V4L2_IN_ST_NO_SIGNAL in the status field as part of struct v4l2_input. Thus, when no signal is detected by the video decoder it can be signalled to the calling application. v4l2_subdev_video_ops-g_input_status I'm blind. That will work, thanks Scott. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] git://git.kernellabs.com/stoth/cx23885-hvr1850.git media-master branch
Mauro, I've been adding support to the CX23885 and CX25840 drivers for the Hauppauge HVR1850 card. These patches enable the use of raw video, audio and/or the mpeg encoder, via all video and audio inputs. Support for the HVR1850 is now in pretty good shape. The card uses the CX23888 PCIe bridge which brings its own complexities and additional code to the CX25840. I've tested these patches against the HVR1700, HVR1800 and HVR1850, everything appears to be working correctly. These also fix a small regression in the HVR1800 driver related to the work done during October 2010 on the subdev conversion. Given that nobody has noticed in the last 12 months it's not too important. Tree is at git://git.kernellabs.com/stoth/cx23885-hvr1850.git media-master branch. Patch series viewable at: http://git.kernellabs.com/?p=stoth/cx23885-hvr1850.git;a=shortlog;h=refs/heads/media-master [media] cx25840: Added g_std support to the video decoder driver [media] cx25840: Hauppauge HVR1850 Analog driver support (patch#4) [media] cx25840: Add a flag to enable the CX23888 DIF to be enabled or not. [media] cx23885: Hauppauge HVR1850 Analog driver support (patch#3) [media] cx23885: Hauppauge HVR1850 Analog driver support (patch#2) [media] cx23885: Hauppauge HVR1850 Analog driver support (patch#1) [media] cx23885: Bugfix /sys/class/video4linux/videoX/name truncation [media] cx23885: Control cleanup on the MPEG Encoder [media] cx23885: Configure the MPEG encoder early to avoid jerky video [media] cx23885: Ensure the MPEG encoder height is configured from the norm [media] cx23885: Cleanup MPEG encoder GPIO handling [media] cx25840 / cx23885: Fixing audio/volume regression b/drivers/media/video/cx23885/cx23885-417.c |4 b/drivers/media/video/cx23885/cx23885-cards.c | 28 b/drivers/media/video/cx23885/cx23885-core.c | 24 b/drivers/media/video/cx23885/cx23885-dvb.c | 14 b/drivers/media/video/cx23885/cx23885-video.c | 153 + b/drivers/media/video/cx23885/cx23885.h | 12 b/drivers/media/video/cx25840/cx25840-audio.c | 10 b/drivers/media/video/cx25840/cx25840-core.c | 36 b/include/media/cx25840.h |1 drivers/media/video/cx23885/cx23885-417.c | 137 - drivers/media/video/cx23885/cx23885-video.c | 10 drivers/media/video/cx25840/cx25840-core.c| 3188 +- 12 files changed, 3487 insertions(+), 130 deletions(-) Thanks, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.3] [media] cx25840 / cx23885: Fixing audio/volume regression
Mauro,
My mistake, I've corrected the issue:
The following changes since commit 9c9c3d078b0dd81a74e5f531aa1efa30add5b419:
[media] cx23885: Configure the MPEG encoder early to avoid jerky
video (2012-01-04 20:51:18 -0200)
are available in the git repository at:
git://git.kernellabs.com/stoth/cx23885-hvr1850-fixups.git staging/for_v3.3
Steven Toth (6):
[media] cx25840: Add a flag to enable the CX23888 DIF to be
enabled or not.
[media] cx23885: Hauppauge HVR1850 Analog driver support
[media] cx23885: Control cleanup on the MPEG Encoder
[media] cx23885: Bugfix /sys/class/video4linux/videoX/name truncation
[media] cx25840: Hauppauge HVR1850 Analog driver support (patch2)
[media] cx25840: Added g_std support to the video decoder driver
drivers/media/video/cx23885/cx23885-417.c | 105 +-
drivers/media/video/cx23885/cx23885-cards.c | 28 +-
drivers/media/video/cx23885/cx23885-core.c | 24 +-
drivers/media/video/cx23885/cx23885-dvb.c | 14 +
drivers/media/video/cx23885/cx23885-video.c | 157 ++-
drivers/media/video/cx23885/cx23885.h | 12 +
drivers/media/video/cx25840/cx25840-core.c | 3224 ++-
include/media/cx25840.h |1 +
8 files changed, 3454 insertions(+), 111 deletions(-)
Thanks,
- Steve
On Wed, Jan 4, 2012 at 5:47 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] cx25840 / cx23885: Fixing audio/volume regression
Author: Steven Toth st...@kernellabs.com
Date: Wed Jan 4 10:47:57 2012 -0300
Since the conversion to subdev in Oct 2010 the audio controls have
not functioned correctly in the cx23885 driver. Passing values of
0-3f did not translate into meaningfull register writes. I've
converted the cx23885 driver to match the cx25840 volume control
definition and now audio is working reliably again.
Signed-off-by: Steven Toth st...@kernellabs.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
drivers/media/video/cx23885/cx23885-video.c | 6 +++---
drivers/media/video/cx25840/cx25840-audio.c | 10 +-
2 files changed, 4 insertions(+), 12 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=4c3764d15050f91a76cede6f24402cd2701e73ef
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 7415524..7f3b973 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -253,9 +253,9 @@ static struct cx23885_ctrl cx23885_ctls[] = {
.id = V4L2_CID_AUDIO_VOLUME,
.name = Volume,
.minimum = 0,
- .maximum = 0x3f,
- .step = 1,
- .default_value = 0x3f,
+ .maximum = 65535,
+ .step = 65535 / 100,
+ .default_value = 65535,
.type = V4L2_CTRL_TYPE_INTEGER,
},
.reg = PATH1_VOL_CTL,
diff --git a/drivers/media/video/cx25840/cx25840-audio.c
b/drivers/media/video/cx25840/cx25840-audio.c
index 005f110..34b96c7 100644
--- a/drivers/media/video/cx25840/cx25840-audio.c
+++ b/drivers/media/video/cx25840/cx25840-audio.c
@@ -480,7 +480,6 @@ void cx25840_audio_set_path(struct i2c_client *client)
static void set_volume(struct i2c_client *client, int volume)
{
- struct cx25840_state *state = to_state(i2c_get_clientdata(client));
int vol;
/* Convert the volume to msp3400 values (0-127) */
@@ -496,14 +495,7 @@ static void set_volume(struct i2c_client *client, int
volume)
}
/* PATH1_VOLUME */
- if (is_cx2388x(state)) {
- /* for cx23885 volume doesn't work,
- * the calculation always results in
- * e4 regardless.
- */
- cx25840_write(client, 0x8d4, volume);
- } else
- cx25840_write(client, 0x8d4, 228 - (vol * 2));
+ cx25840_write(client, 0x8d4, 228 - (vol * 2));
}
static void set_balance(struct i2c_client *client, int balance)
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
+1.646.355.8490
--
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] git://git.kernellabs.com/stoth/cx23885-hvr1850.git media-master branch
There's something wrong on this patch. It breaks compilation: Mauro, My mistake, I've corrected the issue: The following changes since commit 9c9c3d078b0dd81a74e5f531aa1efa30add5b419: [media] cx23885: Configure the MPEG encoder early to avoid jerky video (2012-01-04 20:51:18 -0200) are available in the git repository at: git://git.kernellabs.com/stoth/cx23885-hvr1850-fixups.git staging/for_v3.3 Steven Toth (6): [media] cx25840: Add a flag to enable the CX23888 DIF to be enabled or not. [media] cx23885: Hauppauge HVR1850 Analog driver support [media] cx23885: Control cleanup on the MPEG Encoder [media] cx23885: Bugfix /sys/class/video4linux/videoX/name truncation [media] cx25840: Hauppauge HVR1850 Analog driver support (patch2) [media] cx25840: Added g_std support to the video decoder driver drivers/media/video/cx23885/cx23885-417.c | 105 +- drivers/media/video/cx23885/cx23885-cards.c | 28 +- drivers/media/video/cx23885/cx23885-core.c | 24 +- drivers/media/video/cx23885/cx23885-dvb.c | 14 + drivers/media/video/cx23885/cx23885-video.c | 157 ++- drivers/media/video/cx23885/cx23885.h | 12 + drivers/media/video/cx25840/cx25840-core.c | 3224 ++- include/media/cx25840.h |1 + 8 files changed, 3454 insertions(+), 111 deletions(-) Thanks, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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
subdev support for querying struct v4l2_input *
Hans, In the cx23885 driver as part of vidioc_enum_input call, I have a need to return V4L2_IN_ST_NO_SIGNAL in the status field as part of struct v4l2_input. Thus, when no signal is detected by the video decoder it can be signalled to the calling application. I looks like subdev_core_ops doesn't currently support this, or have I miss-understood something? The patch below is a snippet from a larger patch I have which: 1. Adds this support to struct v4l2_subdev_core_ops 2. Adds support to the cx25840 and cx23885 drivers and makes the feature available. Do you have any comments or thoughts on the subdev_ops patch below? Regards, - Steve Index: v4l-dvb/include/media/v4l2-subdev.h === --- v4l-dvb.orig/include/media/v4l2-subdev.h2012-01-03 17:44:24.337826817 -0500 +++ v4l-dvb/include/media/v4l2-subdev.h 2012-01-03 17:44:54.729826263 -0500 @@ -172,6 +172,7 @@ struct v4l2_event_subscription *sub); int (*unsubscribe_event)(struct v4l2_subdev *sd, struct v4l2_fh *fh, struct v4l2_event_subscription *sub); + int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input *i); }; -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV ported to Windows
The point I'm trying to make: Someone made a presumably nice open source port to a new platform and the first thing you're doing is to play the GPL-has-been-violated-card, even though you're admitting that you don't know whether any right is being violated or not. Please don't do that. It's not very encouraging to someone who just announced free software. Thanks for pointing this out. I would have reacted similarly to Devin, not to discourage Abylay from working on this interesting project, but to warn him that there might be legal issues (I think we would all prefer early notifications from the community than late notifications from unfriendly lawyers :-)). You understanding this as an attack shows that we need to be more careful in the way we word our messages on license-related issues. I've been silent as I wanted to see how the thread evolved. This is a response in general to the group - not any individual. Speaking as the maintainer and copyright owner I can say that it would have been nice if someone had contacted me privately re the matter, before hand. Not to assert any legal right, not for any approval, simply as a courtesy and a perhaps a small 'Thank You'. NetUp could have happily had my personal blessing on their project. My first concern is that this only benefits NetUp on Windows, no other company benefits on windows - as they all already have legal access to the Conexant source reference driver. The Windows GPL driver could/will evolve much faster than the Linux driver and that will suit NetUp commercially and nobody else. Time will not be taken to backport changes into the Linux driver and that's bad for the Linux community. (Or, for commercial reasons, the backports will take longer than expected) My second concern is that NetUp have made it very simply for the hundreds of no-name third party far-east companies (with zero legitimate access to the Conexant windows source reference driver), to take the windows driver, close source it, not distribute their changes and compete against the few legitimate TVTuner companies left in the world. If/when the one or two remaining TVTuner companies die because their bread and butter Windows sales are being eroded to zero - how does this help this community? It doesn't, it only helps NetUp. I embrace open source, I welcome new developers, debate and growth I just think if you are going to get my 18 year old daughter pregnant then it's courtesy to knock on my door and introduce yourself first - regardless of my opinion or your legal rights. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV ported to Windows
Speaking as the maintainer and copyright owner I can say that it would have been nice if someone had contacted me privately re the matter, before hand. Not to assert any legal right, not for any approval, simply as a courtesy and a perhaps a small 'Thank You'. NetUp could have happily had my personal blessing on their project. you could have said thank you for porting the driver as well: The port enlarges the user base, is likely to uncover bugs and you might even receive fixes to those bugs for free (unless the ranting goes on). I care not for a windows port, it's of no interest to me. I'm sure NetUp Windows customers will find it useful. My first concern is that this only benefits NetUp on Windows, no other company benefits on windows - as they all already have legal access to the Conexant source reference driver. Are you implying that a) it's not the users who benefit most? b) other companies won't be able to use this driver? c) NetUp doesn't have legal access to the reference driver? I was simply stating my opinion, it not a list of points I wish to debate with you or anyone else. Please don't take this comment personally. You are welcome to your own opinion and draw your own conclusions on how I feel about the matter. The Windows GPL driver could/will evolve much faster than the Linux driver and that will suit NetUp commercially and nobody else. Time will not be taken to backport changes into the Linux driver and that's bad for the Linux community. (Or, for commercial reasons, the backports will take longer than expected) Why don't you do the backports yourself? You want NetUp to do the work for you? The code is published in a Git repository. You can easily track any changes. Yes, I could, thanks to github. My second concern is that NetUp have made it very simply for the hundreds of no-name third party far-east companies (with zero legitimate access to the Conexant windows source reference driver), to take the windows driver, close source it, not distribute their changes and compete against the few legitimate TVTuner companies left in the world. If/when the one or two remaining TVTuner companies die because their bread and butter Windows sales are being eroded to zero - how does this help this community? It doesn't, it only helps NetUp. Any company doing that could use any existing binary driver as well. Besides that, I'm sure it's no problem for them to get access to any reference driver they want. I think I respectfully disagree with you. I embrace open source, I welcome new developers, debate and growth I just think if you are going to get my 18 year old daughter pregnant then it's courtesy to knock on my door and introduce yourself first - regardless of my opinion or your legal rights. A very compelling analogy. Best wishes, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.2] cx23885 alsa cleaned and prepaired
It's been a long time since cx23885-alsa pull was requested. To speed things up I created a git branch where I put the patches. are available in the git repository at: ... git://linuxtv.org/liplianin/media_tree.git cx23885-alsa-clean-2 Thank you for working on this Igor. I most certainly have some additional patches that will probably no longer apply cleanly. However, given that you've gone to the trouble of building a new tree, assuming we can get these merged, then I'll rebase and regenerate any patches I have to match the current cx23885 driver. -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: Cypress EZ-USB FX2 firmware development
Hi Antti, I would like to made own firmware for Cypress FX2 based DVB device. Is there any sample to look example? I've done multiple FX2 firmware projects in the past, including DVB-T. The technical reference manual for the FX2 explains the GPIF waveform sampling engine very well. It also shows sample firmware listings for operating the fifo engine in the different input or output modes. You'll find it via google. If you have specific questions then I'd be happy to answer them on the mailing-list. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included
map = std_map-atv_dk; Simon, I've been chewing on this for a day or so and it reminded me partly why I stopped working on combined PAL/NTSC support for the saa7164 hardware family, it's been bugging me for a reason - now I understand why. Essentially, I had a long discussion with Mike Krufky about a year ago related to I/F's for analog TV output. The SAA7164 analog demod IF (as best as I can tell) are not configurable. I have no good set_if() interface I can call on the tuner to select a different I/F as the bridge driver needs. I was fairly unhappy about that. bah, such is life. The TDA18271 driver on linux DOES NOT use the same I/F's that the windows driver uses. Reason? Mike Decided to follow the data sheet and NOT use the Hauppauge specifically select IFs. His advise to me, at the time, which I think will work nicely for you and probably a better patch, is to have the HVR-1110 define a better I/F map for the atv_dk case. This way at least you would not pollute the 18271 driver in it's core and effect other DK users (potentially), instead, for the HVR1110 18271 attach, define the I/F maps for each country/modulation and simple change the DK version by your desired offset. That may be a cleaner fix and accepted for merge. (Note to self: Now that I recall the conversation with Mike I may actually go ahead and fix my saa7164 Pal issue.) -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for v3.2] [media] saa7164: Adding support for HVR2200 card id 0x8953
Hi Mauro, Please pull 92aa36f8f9d19b7c47ad3daca15aa0932254246b from git://git.kernellabs.com/stoth/saa7164-dev.git Another SAA7164 HVR220 card profile. http://git.kernellabs.com/?p=stoth/saa7164-dev.git;a=commit;h=92aa36f8f9d19b7c47ad3daca15aa0932254246b drivers/media/video/saa7164/saa7164-cards.c | 62 +++ drivers/media/video/saa7164/saa7164-dvb.c |1 + drivers/media/video/saa7164/saa7164.h |1 + Thanks, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trident TV Master (TM5600/TM6000) information
If you google for tv master technical reference (with quotes), the first result is a PDF with fairly detailed info on the TV Master chips including register names. Thank you Mark, its appreciated. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recursive locking problem
Can any one shed some light on this? I appreciate it's not a linux or indeed linux-media specific issue as the hardware itself is designed this way. i2c gates exist to isolate the downstream components from any spurious RF noise generated by noisy components on the i2c bus. You don't want to couple demod noise into the tuner by default. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recursive locking problem
I would take Steven Toth's explanation as more authoritative than mine any day of the week. It's possible that I may have been misinformed regarding the rationale for why the gate is required. In general, complete bus isolation lowers noise levels, whether through RF coupling or needless interrupt servicing related. Either rationale is valid and varies between designs. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for v3.2] saa7164: Add support for another HVR2200 hardware revision
Mauro, I've been sitting on this patch for a while It adds a new card profile to the existing driver. Please pull from git://git.kernellabs.com/stoth/saa7164-stable.git Commit 87e0c0378bf2068df5d0c43acd66aea9ba71bd89 http://git.kernellabs.com/?p=stoth/saa7164-stable.git;a=commit;h=87e0c0378bf2068df5d0c43acd66aea9ba71bd89 saa7164: Add support for another HVR2200 hardware revision Thanks, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to git and build HVR-2200 drivers from Kernel labs ?
Eg should I use the source from git clone git://kernellabs.com/stoth/saa7164- dev.git or do you recommend something else that might be more stable ? pull a snapshot: http://www.kernellabs.com/gitweb/?p=stoth/saa7164-stable.git;a=snapshot;h=87e0c0378bf2068df5d0c43acd66aea9ba71bd89;sf=tgz I've now got my card working with the saa7164 driver from the 87e0c0378bf2068df5d0c43acd66aea9ba71bd89 commit. Many thanks for your help. Thanks for the followup Declan. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to git and build HVR-2200 drivers from Kernel labs ?
Eg should I use the source from git clone git://kernellabs.com/stoth/saa7164- dev.git or do you recommend something else that might be more stable ? pull a snapshot: http://www.kernellabs.com/gitweb/?p=stoth/saa7164-stable.git;a=snapshot;h=87e0c0378bf2068df5d0c43acd66aea9ba71bd89;sf=tgz -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to git and build HVR-2200 drivers from Kernel labs ?
So how do I get a 8940 edition of a HVR-2200 working with Ubuntu ? Hello Declan, You'll need to install the entire new kernel and all of its modules, you should avoid cherry picking small pieces. Incidentally, I've had confirmation from another user that the tree works and automatically detects type 9 cards. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Mauro, My comments for your review: I've spoken on this topic many times, it's bad news for the LinuxTV eco-system and it will eventually lead to binary only drivers that ultimately diminishes all of the good work that me any my fellow developers have poured into Linux over the last 5-10 years. I repeat my message from 2 years ago when the subject was raised: and this is (paraphrase) I can say with great certainty that if we allow API's that permit closed source drivers then silicon vendors and board manufacturers will take advantage of that, they will only delivery (at best) closed source drivers. If closed source drivers is what the community wants then this is a way to achieve this. I don't want to see user-space drivers happen through LinuxDVB or V4L2 API's. I politely and respectfully nack this idea. Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CX24116 i2c patch
Mauro, Subject: [media] cx24116: add config option to split firmware download Author: Antti Palosaari cr...@iki.fi Date: Wed Apr 27 21:03:07 2011 -0300 It is very rare I2C adapter hardware which can provide 32kB I2C write as one write. Add .i2c_wr_max option to set desired max packet size. Split transaction to smaller pieces according to that option. This is none-sense. I'm naking this patch, please unqueue, regress or whatever. The entire point of the i2c message send is that the i2c drivers know nothing about the host i2c implementation, and they should not need to. I2C SEND and RECEIVE are abstract and require no knowledge of the hardware. This is dangerous and generates non-atomic register writes. You cannot guarantee that another thread isn't reading/writing to other registers in the part - breaking the driver. Please fix the host controller to split the i2c messages accordingly (and thus keeping the entire transaction atomic). This is the second time I've seen the 'fix' to a problem by patching the i2c driver. Fix the i2c bridge else we'll see this behavior spreading to multiple i2c driver. It's just wrong. Best, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl
Good work, thanks Hans. I've made an inventory of all drivers that still use .ioctl and I am looking for volunteers to tackle one or more drivers. cx23885 (Steve Toth) cx88 I'll take care of these and also the saa7164 driver. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-2200 analog
On 12/14/10 12:23 PM, Julian Scheel wrote: Is there any reason, why the additional card-information found here: http://www.kernellabs.com/hg/~stoth/saa7164-dev/ is not yet in the kernel tree? On my todo list. I validate each board before I add its profile to the core tree. If certain boards are missing then its because that board is considered experimental or is pending testing and merge. PAL encoder support is broken in the current tree and it currently getting my love and attention. Point me at the specific boards you think are missing and I'll also add these to my todo list, they'll likely get merged at the same time. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
On 12/6/10 3:09 PM, Alexey Chernov wrote: Another version of my patch without DVB code. Some comments: 1. Everything initialize properly except radio. 2. All analog inputs (TV, composite, S-Video) are tested by myself in several TV norms (SECAM-D, PAL, NTSC), everything work fine. So the patch adds general support/detection of the card with working analog part, DVB part is not supported for now. Thank you Alexey. Signed-off-by: Alexey Chernov 4er...@gmail.com Here's my sign-off Reviewed-By: Steven Toth st...@kernellabs.com -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
So the patch adds general support/detection of the card with working analog part and hopefully working (untested) DVB part. I hope it will be useful. Excellent, another card profile. Thanks Alexey! Hmm, we generally don't add code to the kernel that hasn't been tested. For this reason I need to nak your patch. Either have someone test the code and report success to this mailing list or consider removing the untested code. Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
So I think I was mistaken that the code itself is untested. I hope it's possible to add full of this patch. Has the DVB related change proven that it enables digital TV streaming? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] git://kernellabs.com/stoth/saa7164-dev.git
Mauro, Please pull the following changes. The following changes since commit 5ed5d45da807a6d0d1d06bfe45b3623f97ce2797: Steven Toth (1): [media] saa7164: Checkpatch compliance cleanup are available in the git repository at: git://kernellabs.com/stoth/saa7164-dev.git master gitweb access here: http://www.kernellabs.com/gitweb/?p=stoth/saa7164-dev.git Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bounty for the first Open Source driver for Kinect
On 11/10/10 10:54 AM, Antonio Ospite wrote: On Wed, 10 Nov 2010 15:20:40 +0100 Mohamed Ikbel Boulabiar boulab...@gmail.com wrote: MS Kinect interfacing via libusb released http://www.youtube.com/watch?v=rKhW-cvpkks http://git.marcansoft.com/?p=libfreenect.git Good, if anyone is willing to provide the hardware I think I can help with a proper gspca driver (I helped with the PS3 Eye already). Are there other RGB-Depth cams supported in linux? Are they usually exposed just as two distinct cameras? Antonio, Excellent! If you are willing to donate your personal time freely to Linux then Kernel Labs are willing to assist by shipping a Kinect unit to you. Let me be clear, Kernel Labs have no commercial interest in this project. We simply like to encourage Linux media projects where possible. Projects like this are good for Linux and thus good for the community. My only requirement is that you post regular project status emails to this mailing list so we can all benefit from your thoughts, rants, any problems or comments on the project! :) Drop me a private email if you're interested. Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx23885 module
On 10/22/10 9:02 AM, Daniel Lee Kim wrote: Steve, [ 3072.621974] MT2131: successfully identified at address 0x60 Would the above message indicate that the tuner has been taken out of reset mode? Yes. It's probably the I/F (intermediate frequency) between the MT2131 and the LG3305 is incorrect, so the demod does not see the RF correctly from the tuner. Try stepping the LG I/F through it's various combination (see the LG header .h file) then repeat the test with spectral inversion inverted. Use azap to tune during each test and watch for status bits 0x1f (meaning the demod is locked). If no lock, adjust the I/F and/or spectral inversion and try again. - Steve Are you suggesting that the above test might resolve the issue of not being able to tune using the MT2131? I'll take a look at the LG header though I'm using the LGDT330X driver since mine is the 3303 chip. Yes. How do I know that the tuner is working? The modprobe i2c_scan=1 returned a fatal error, not found. Is there another way to test it? If the MT2131 was detected then it's probably working. modprobe cx23885 i2c_scan=1 should work and show a tuner at address 0xC0, 2 or 4 etc. One more question, is there a place I can go to learn how to compile just the cx23885.ko module? I am not able to compile only that module and so I have to wait until it compiles all the modules. I apologize as this is my first time tweaking a driver module. I've searched all over the net but have not found anyone who wrote about this. Thanks, The wiki at linuxtv.org should contain everything you need for compiling, modifying and submitting patches. Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx23885 module
On 10/20/10 12:19 PM, Daniel Lee Kim wrote: Thank you, Steve, for introducing me to the mailing list and showing me the protocol. I have taken a look at your questions and comments. My responses are interspersed in the email below You are welcome. cut However, running dmesg, I get the following: [ 3072.274680] cx23885 driver version 0.0.2 loaded [ 3072.274752] cx23885 :04:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 3072.274970] CORE cx23885[0]: subsystem: 1461:d439, board: AVermedia M791 [card=29,autodetected] [ 3072.605134] cx23885_dvb_register() allocating 1 frontend(s) [ 3072.605189] cx23885[0]: cx23885 based dvb card [ 3072.621974] MT2131: successfully identified at address 0x60 [ 3072.621981] DVB: registering new adapter (cx23885[0]) [ 3072.621986] DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3303 VSB/QAM Frontend)... [ 3072.622519] cx23885_dev_checkrevision() Hardware revision = 0xb1 [ 3072.622529] cx23885[0]/0: found at :04:00.0, rev: 15, irq: 19, latency: 0, mmio: 0xea00 [ 3072.622540] cx23885 :04:00.0: setting latency timer to 64 [ 3072.622546] IRQ 19/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs so it does look like it has identified MT2131 as the tuner but is unable to work it. Any further help would be greatly appreciated. If the drivers are now loading (which sounds like progress) then the GPIOs (in whatever form you have them) are probably OK. Double check this by doing a cold boot without booting into windows first, does the tuner still attach? It's never wise to drive a GPIO regardless unless you know what you are doing, you could be sinking current into a part for long periods of time that doesn't like it (or applying/removing write protection from eeproms etc). At this stage I'd probably guess when you say the 'tuner is unable to work' that it's not locking when testing with azap (and a correctly configured channels.conf). It's probably the I/F (intermediate frequency) between the MT2131 and the LG3305 is incorrect, so the demod does not see the RF correctly from the tuner. Try stepping the LG I/F through it's various combination (see the LG header .h file) then repeat the test with spectral inversion inverted. Use azap to tune during each test and watch for status bits 0x1f (meaning the demod is locked). If no lock, adjust the I/F and/or spectral inversion and try again. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx23885 module
Hi Dan, Thanks for writing. I can't do one-on-one end user support without copying in the Linux Media mailing list. I'm taking the liberty of doing so. Please reply-all when discussing this issue - so everyone can benefit. [Dan is having issues being up an AverMedia board with a LG demod and a MT2131 tuner via the cx23885 driver] However, I am having some trouble getting the tuner to be recognized. I was It's the GPIO probably holding the tuner in reset, I suspect your gpio configuration is wrong. That's my first guess. What makes you think the gpio settings in your patch are correct? hoping that you might be willing to look over the code a bit to see what I am missing. I have altered the following 3 files: cx23885.h, cx23885-cards.c, and cx23885-dvb.c. I am attaching the 3 files in this email. I have been trying to do 3 things. First, to have the module auto-detect my card which was successful. Second, I wanted to attach the LGDT330X as my frontend which was successful. Third, I wanted to attach the MT2131 tuner. This third step is where I am having my troubles. I feel so close but I am not there yet. I know that you wrote the code a while back but if you would be willing to help me, I'd really appreciate it. Some folks have gotten the ngene module to work with the M780 board which Yeah, I worked on the ngene with Devin as part of our KernelLabs.com projects, we brought up the digital side of the card as a pre-test while investigating ngene analog support. If the 2131 isn't attaching then it's because you think it's on a different I2C bus, or the LG demod has it's I2C gate closed (unlikely) or the tuner is not responding because it's being held in reset. Do you see the tuner if you perform and I2C scan (modprobe i2c_scan=1)? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PULL] http://kernellabs.com/hg/~stoth/saa7164-v4l
Sorry, SOB On Thu, Oct 14, 2010 at 12:36 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi Steven, I'm still missing your SOB for the three patches from Gavin. Please reply to this thread publicly with your SOB, and I'll add both SOB's on my tree. Thanks, Mauro Sorry, a mix of travel and time away from email. For all three patches by Gavin: Signed-off-by: Steven Toth st...@kernellabs.com Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7164 analog driver crash
On 8/26/10 11:23 AM, James Crow wrote: First of all I would like to thank Steven Toth for working on the driver for the HVR-2250 cards. I bought one some time ago as an eventual replacement for mt PVR-500 and it seems that time may be approaching. I noticed that analog support had been added and wanted to try it out. Second, I hope this is the correct list for problems with this driver. Thanks for the bug report James. I've got a couple of issues on the 7164 todo list, I'll add your email to the mix. I hope to get back to the driver shortly. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~stoth/cx23885-mpx
On 7/31/10 2:28 PM, Andy Walls wrote:
On Sat, 2010-07-31 at 12:31 -0400, Steven Toth wrote:
Mauro,
Please pull from http://www.kernellabs.com/hg/~stoth/cx23885-mpx
A pretty large patch set which adds a number of important features to
the cx23885 driver.
I have a few cx25840 related comments:
1. Please don't abuse CX25840_AUDIOn and make it mean something other
than its current usage of specifying which input the SIF audio is coming
in on. The cx25840 module has enough confusion in it already. Let's
not overload the current enumerations.
Also the current cx25840 keys off of CX25840_AUDIOn vs
CX25840_AUDIO_SERIAL to set up a number of things: sample rate
convertors and the Baseband Path 1 routing for the CX23885 family at
least.
It would be better to add new enumaerated values for CX23885_AUDIO_LR1,
or whatever, to achieve your desired audio input configuration tasks.
Noted. Thanks for the feedback Andy.
2. The raw VBI startup you added in the cx25840 module is not going to
serve you well. It is true that it is harmless to existing
non-CX2388[578] boards. However, any app action that causes
cx25840_std_setup() to be called will change register 0x474 to probably
something you are not expecting.
It's held up very well in testing. With ntsc-zv-vbi and mencoder I'm not seeing
any issues. It could be that the API sequence is working in the customer favor
but non-the-less I don't have any open bugs against VBI.
It should be made clear that VBI never previous worked on the cx23885, for any
cards.
It would be better for you, in the long run, to fix up
cx25840_std_setup() and cx25840_s_raw_fmt() to suit your needs, rather
than a one off setting in the init function..
(I will admit the setup of the vblank, voffset, etc. in the cx25840 is
not trivial, due to the way the ivtv driver likes to capture raw vbi
lines and sliced vbi as if it were raw vbi data. I puzzled most of it
out and fixed it up in the cx18 driver to be more sensible. It took a
bit of staring at the BT878 data sheet to figure out the timing of the
VBI slicer too, since the data is missing from later data sheets.)
Ack. VBI via the cx25840 is a mess generally.
However, the cx25840 driver is close enough to the avcore that doing a
cx23885-avcore.c and largely closing all of the source code from cx25840 is an
exercise in growing the linuxtv tree for little value.
3. This caught my eye:
8 + if (is_cx2388x(state)) {
9 + /* for cx23885 volume doesn't work,
10 + * the calculation always results in
11 + * e4 regardless.
12 + */
13 + cx25840_write(client, 0x8d4, volume);
14 + } else
15 + cx25840_write(client, 0x8d4, 228 - (vol * 2));
Why is the result always 0xe4? Is that what the register always reads
back?
Yes.
Note that your change won't have an intuitive effect, because you
dropped the '-' sign in front of the volume. The user's slider control
will likely work in reverse: up is soft, down is loud.
This is a mistake on my end, although it represents no known regression given
that 0xe4 note and the lact of audio support in the kernel prior to this
patchset for the cx23885.
I can say the V4L2 control to cx25840 volume scale mapping is a little
funny. Here is documentation on the mapping from V4L2 volume control
values to dB to cx25840 register values:
http://linuxtv.org/hg/v4l-dvb/file/9652f85e688a/linux/drivers/media/video/cx18/cx18-alsa-mixer.c#l38
Thanks.
It is non-linear at the bottom end with a reg value of 228 = 0xe4 for
3/16ths of the entire range. This is due to the cx25840 module's desire
to keep volume levels at the same perceptible level between the MSP400
and the CX2584x chips for users with multiple ivtv cards in their
machine. (Yet another ivtv legacy.)
You ought to look at what values are coming from the V4L2 volume control
slider and see what's wrong. A V4L2 volume control value in the range
0xee00-0xeeff should correspond to 0 dB gain.
It's been a while but form memory I added debug to the function and passed the
volume control and found the register values (and calculations to be way off),
certainly not what I expected. I figured this was an issue outside of the realm
of the cx23885 and thus isolated my change to the cx23885 only, not effecting
any other products.
Regards,
- Steve
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.kernellabs.com/hg/~stoth/cx23885-mpx
Mauro, Please pull from http://www.kernellabs.com/hg/~stoth/cx23885-mpx - cx23885: prepare the cx23885 makefile for alsa support - cx23885: merge mijhail's header changes for alsa - cx23885: ALSA support - cx23885: core changes requireed for ALSA - cx23885: add definitions for HVR1500 to support audio - cx23885: correct the contrast, saturation and hue controls - cx23885: hooks the alsa changes into the video subsystem - cx23885: convert call clients into subdevices - cx23885: replaced spinlock with mutex - cx23885: minor function renaming to ensure uniformity - cx23885: setup the dma mapping for raw audio support - cx23885: mute the audio during channel change - cx23885: add two additional defines to simplify VBI register bitmap handling - cx23885: initial support for VBI with the cx23885 - cx23885: initialize VBI support in the core, add IRQ support, register vbi device - cx23885: minor printk cleanups and device registration - cx25840: enable raw cc processing only for the cx23885 hardware - cx23885: vbi line window adjustments - cx23885: add vbi buffer formatting, window changes and video core changes - cx23885: Ensure the VBI pixel format is established correctly. - cx23885: convert from snd_card_new() to snd_card_create() - cx23885: ensure video is streaming before allowing vbi to stream - cx23885: vbi related codingstyle cleanups - cx23885: removal of VBI and earlier VBI printk debugging - cx23885: removal of redundant code, this is no longer required. - cx23885: remove channel dump diagnostics when a vbi buffer times out. - cx23885: Ensure VBI buffers timeout quickly - bugfix for vbi hangs during streaming. - cx23885: coding style violation cleanups - cx23885: Convert a mutex back to a spinlock - cx23885: Name an internal i2c part and declare a bitfield by name - cx25840: Enable support for non-tuner LR1/LR2 audio inputs - cx23885: Allow the audio mux config to be specified on a per input basis. - cx23885: remove a line of debug - cx23885: Enable audio line in support from the back panel - cx25840: Ensure AUDIO6 and AUDIO7 trigger line-in baseband use. - cx23885: Initial support for the MPX-885 mini-card - cx23885: fixes related to maximum number of inputs and range checking - cx23885: add generic functions for dealing with audio input selection - cx23885: hook the audio selection functions into the main driver - cx23885: v4l2 api compliance, set the audioset field correctly - cx23885: Removed a spurious function cx23885_set_scale(). - cx23885: Avoid stopping the risc engine during buffer timeout. - cx23885: Avoid incorrect error handling and reporting - cx23885: Stop the risc video fifo before reconfiguring it. b/linux/drivers/media/video/cx23885/cx23885-alsa.c | 542 + linux/Documentation/video4linux/CARDLIST.cx23885 |1 linux/drivers/media/video/cx23885/Makefile |2 linux/drivers/media/video/cx23885/cx23885-alsa.c | 28 linux/drivers/media/video/cx23885/cx23885-cards.c | 53 linux/drivers/media/video/cx23885/cx23885-core.c | 127 +- linux/drivers/media/video/cx23885/cx23885-i2c.c|1 linux/drivers/media/video/cx23885/cx23885-reg.h|3 linux/drivers/media/video/cx23885/cx23885-vbi.c| 96 + linux/drivers/media/video/cx23885/cx23885-video.c | 556 ++ linux/drivers/media/video/cx23885/cx23885.h| 65 + linux/drivers/media/video/cx25840/cx25840-audio.c |9 linux/drivers/media/video/cx25840/cx25840-core.c | 21 13 files changed, 1257 insertions(+), 247 deletions(-) A pretty large patch set which adds a number of important features to the cx23885 driver. Some early patches for the HVR1500 with add support for analog audio (very rough, much rework on these). The University of California sponsored work for the HVR1800 and HVR1850 and raw video and raw audio and VBI support. The Belac Group sponsored changes related to the MPX cx23885 8 input design, adding raw video and audio support. Mencoder now works correctly with the raw video and audio portions of the driver. GStreamer now works correctly using the v4l interfaces from the driver, live video and audio viewing are now possible. NTSC-ZZ-VBI now works correctly for RAW VBI decoding (although TVTime still refuses to work correctly - tvtime bug) Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~stoth/saa7164-v4l
Mauro, Analog Encoder and VBI support in the SAA7164 tree, for the HVR2200 and HVR2250 cards. Please pull from http://www.kernellabs.com/hg/~stoth/saa7164-v4l - saa7164: basic definitions for -encoder.c - saa7164: Add some encoder firmwares message types and structs - saa7164: convert buffering structs to be more generic - saa7164: add various encoder message functions - saa7164: Implement encoder irq handling in a deferred work queue. - saa7164: command dequeue fixup to clean the bus after error. - saa7164: allow the encoder GOP structure to be configured - saa7164: generate a fixed kernel warning if the irq is 'late' - saa7164: add support for encoder CBR and VBR optionally. - saa7164: allow the IBP reference distance to be configurable - saa7164: implement encoder peak bitrate feature - saa7164: allow encoder output format to be user configurable - saa7164: allow variable length GOP sizes and switch encoder default to CBR - saa7164: patches to monitor TS payload for inconsistencies - saa7164: allow the number of encoder buffers to be user configurable - saa7164: measure via histograms various irq and queue latencies - saa7164: add guard bytes around critical buffers to detect failure. - saa7164: buffer crc checks and ensure we use the correct PCIe IO memcpy func - saa7164: adjust the PS pack size handling to fill buffers 100% - saa7164: Implement resolution control firmware command - saa7164: mundane buffer debugging changes to track issues - saa7164: irqhandler cleanup and helper function added - saa7164: code cleanup - saa7164: allow DMA engin buffers to vary in size between analog and digital - saa7164: New firmware changes, new size, new filename - saa7164: Avoid spurious error after firmware starts - saa7164: rename a structure for readability - saa7164: add NTSC VBI support - saa7164: add firmware debug message collection and procfs changes - saa7164: VBI irq cleanup and V4L VBI raw pitch adjustments - saa7164: Monitor the command bus and check for inconsistencies - saa7164: enforce the march 10th firmware is used. - saa7164: collect/show the firmware debugging via a thread - saa7164: monitor the RISC cpu load via a thread - saa7164: video_is_registered() func change - saa7164: change debug to saa_debug - saa7164: Add missing saa7164-vbi.c file. - saa7164: fix vbi compiler warnings - saa7164: if 0/1 cleanups b/linux/drivers/media/video/saa7164/saa7164-encoder.c | 23 b/linux/drivers/media/video/saa7164/saa7164-vbi.c | 1459 ++ linux/drivers/media/video/saa7164/Makefile|4 linux/drivers/media/video/saa7164/saa7164-api.c | 1143 - linux/drivers/media/video/saa7164/saa7164-buffer.c| 204 linux/drivers/media/video/saa7164/saa7164-bus.c | 231 - linux/drivers/media/video/saa7164/saa7164-cards.c | 56 linux/drivers/media/video/saa7164/saa7164-cmd.c | 21 linux/drivers/media/video/saa7164/saa7164-core.c | 2103 ++ linux/drivers/media/video/saa7164/saa7164-dvb.c | 109 linux/drivers/media/video/saa7164/saa7164-encoder.c | 1872 linux/drivers/media/video/saa7164/saa7164-fw.c| 35 linux/drivers/media/video/saa7164/saa7164-i2c.c |2 linux/drivers/media/video/saa7164/saa7164-reg.h | 70 linux/drivers/media/video/saa7164/saa7164-types.h | 183 linux/drivers/media/video/saa7164/saa7164-vbi.c | 53 linux/drivers/media/video/saa7164/saa7164.h | 328 + 17 files changed, 6421 insertions(+), 1475 deletions(-) Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
