Re: [PATCH] em28xx: enable usb audio for plextor px-tv100u
On Wednesday 29 July 2009 06:57:30 Mauro Carvalho Chehab wrote: > Em Tue, 28 Jul 2009 20:07:53 -0400 > > ac...@fastmail.fm escreveu: > > On Mon, Jul 27, 2009 at 09:28:11PM -0300, Mauro Carvalho Chehab wrote: > > > Hi Acano, > > > > Tested-by: Angelo Cano > > > > works great > > Good! > > > > > + /*FIXME hack to unmute usb audio stream */ > > > > + em28xx_set_ctrl(dev, ctrl); > > > > > > Hmm... this function were removed. In thesis, you shouldn't need to > > > do anything to unmute. > > > > I still need it, see attachment. > > > > > Could you please try the enclosed patch and see if this is enough to > > > fix for Plextor? If so, please send me a Tested-by: tag for me to add > > > it at 2.6.31 fix patches. > > > > Like I said the patch works great, and also solves my audio volume > > problem. With your patch the volume is set to a sane value > > (presumably 0db) and the distortion/clipping is gone. > > > > Thanks man. The volume problem was driving me crazy. > > Ah, yes, there's a missing mute/unmute issue there. Instead of using your > code, I opted to duplicate part of ac97_set_ctrl code there. > > I opted to have a small duplicated code, but, IMO, it is now clearer to > see why we still need to call em28xx_audio_analog_set(). You will notice > that I've rearranged the place where I update volume and mute. The > rationale is that v4l2_device_call_all() might eventually change a value > for volume/mute. > > Another reason is that, IMO, v4l2_device_call_all() should return values. > In the specific case of volume/mute, if the user tries to specify a value > outside the range, the -ERANGE should be returned. > > I've already committed the patches at the tree. Please double-check. > > Hans, > > we need to fix the returned error value for v4l2_device_call_all(). I > know that this is an old issue that weren't changed by v4l dev/subdev > conversion, but now it is easier for us to fix. The idea here is to be > sure that, if a sub-driver with a proper handling for a function returns > an error value, this would be returned by v4l2_device_call_all(). Maybe > we'll need to adjust some things at the sub-drivers. Use v4l2_device_call_until_err instead of v4l2_device_call_all. That macro checks for errors returned from the subdevs. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: Kaiser Baas ExpressCard Dual HD Tuner
Hello, James On Wed, Jul 29, 2009 at 4:19 AM, James A Webb wrote: > Hi. > > I'm new to the list - please bear with me. > > I've spent some time getting a recently purchased Kaiser Baas > ExpressCard Dual HD Tuner working with MythTV. I ended up patching some > of the dib0700 work. I'd like to submit the patches back to the > community. Please always send your "Signed-off-by" label with your patches. It's good to send one more letter replying to your initial letter with your sign. -- Best regards, Klimov Alexey -- 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: Terratec Cinergy HibridT XS
On Wed, Jul 29, 2009 at 4:28 AM, hermann pitton wrote: > Hi, > > Am Dienstag, den 28.07.2009, 20:44 -0400 schrieb Devin Heitmueller: >> On Tue, Jul 28, 2009 at 7:32 PM, Valerio Messina wrote: >> > hi all, >> > >> > I own a Terratec Cinergy HibridT XS >> > with lsusb ID: >> > Bus 001 Device 007: >> > ID 0ccd:0042 TerraTec Electronic GmbH Cinergy Hybrid T XS >> > >> > With past kernel and a patch as suggested here: >> > http://www.linuxtv.org/wiki/index.php/TerraTec >> > that link to: >> > http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_Hybrid_T_USB_XS >> > that link to: >> > http://mcentral.de/wiki/index.php5/Main_Page >> > and some troubles for Ubuntu kernel that I solved here: >> > https://bugs.launchpad.net/bugs/322732 >> > worked well for a year or more. >> > >> > With last Ubuntu 9.04, kernel 2.6.28-13 seems have native support for the >> > tuner, but from dmesg a file is missing: xc3028-v27.fw >> > (maybe manage I2C for IR?) >> > I found it on a web site, copied in /lib/firmware >> > and now Kaffeine work, but ... no more IR remote command work. >> > >> > More bad now: >> > http://mcentral.de/wiki/index.php5/Installation_Guide >> > sell TV tuner, and do not support anymore the Terratec tuner, the source >> > repository is disappeared, and install instruction is a commercial. > > all in all it is really funny. > >> > Any chanches? >> > >> > thanks in advace, >> > Valerio >> >> That device, including full support for the IR, is now supported in >> the mainline v4l-dvb tree (and will appear in kernel 2.6.31). Just >> follow the directions here to get the code: >> >> http://linuxtv.org/repo >> >> Devin >> > > Hopefully nobody is mad enough to buy for such prices. > compared with other drivers it has some big advantages, eg. automatic audio routing (supports OSS/Alsa/reading audio external) - as tvtime doesn't support audio at all our solution automatically enables audio with it, installation works within a few seconds (everywhere, any distribution, eg eeepc, acer aspire one, ubuntu, redhat, suse..), kernel independent, more or less unix operating system independent as well. There's nothing comparable available, and it has full support from the chipdesign companies, just about anyone who doesn't know much about linux can easily handle it without the knowledge how to set up a development system. CI Support is on the roadmap as well for DVB-C. While all of that it is still compatible to existing kernel drivers. Updates will also affect all systems at once and won't need a particular kernel versions. So it is more like a question if someone wants a prebuilt, working car which has guaranteed support, or wants to build his own car both is doable of course. Best Regards, Markus -- 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 save number of times using memcpy?
Hi Laurent, 2009/7/28 Laurent Pinchart : > On Tuesday 28 July 2009 08:54:12 Hans Verkuil wrote: >> On Tuesday 28 July 2009 02:56:05 Dongsoo, Nathaniel Kim wrote: > [snip] >> > And the other one is about how to handle the buffer used between >> > couple of multimedia devices. >> > Let me take an example of a camcorder scenario which takes series of >> > pictures and encode them in some sort of multimedia encoded format. >> > And let's assume that we are using a device of a SoC H/W which has >> > it's own camera and multimedia encoder device as well. >> > >> > The scenario might be going like following order ordinarily. >> > 1. User application: open camera device node and tries to mmap >> > buffer(A) to be used. >> > 2. Camera interface: try to allocate memory in kernel space and creates >> > mapping. >> >> Wrong, this should have been point 1 because by this time it's pretty >> unlikely you can allocate the buffers needed due to memory fragmentation. >> >> > 3. User application: open encoder device node and tries to mmap >> > buffer(B) as input buffer and buffer(C) as output buffer to be used. >> > 4. Start streaming >> > 5. Camera interface: fetch data from external camera module and writes >> > to the allocated buffer in kernel space and give back the memory >> > address to user application through dqbuf >> > 6. User application: memcpy(1st) returned buffer(A) to frame buffer >> > therefore we can see as preview >> >> Unavoidable memcpy, unless there is some sort of hardware support to DMA >> directly into the framebuffer. > > Or unless you use the USERPTR method instead of MMAP, providing your graphics > hardware provides some sort of video display capabilities (similar to Xv for > instance). You can then allocate a video buffer and ask the camera driver to > DMA data directly to that buffer. This requires > > 1. the video buffer to be contiguous in virtual memory (no stride) > 2. the video buffer to be contiguous in physical memory, OR the camera DMA to > support scatter-gather. > Actually me and other engineers are not used to use USERPTR than MMAP. But one thing obvious is the H/W we are working on is able to send data directly from camera interface to frame buffer through FIFO pipeline. With this way no memcpy necessary to display preview. >> > 7. User application: memcpy(2nd) returned buffer(A) to buffer(B) of >> > encoder device. >> >> So this is copying between two v4l2 video nodes, right? > > Does your hardware allow chaining the camera and codec directly without going > through memory buffers ? > Unfortunately no. Direct path is supported just between camera and frame buffer. It should be better if it is supported between them but I suppose that H/W designer wanted to make the codec device system wide one. >> > 7. Encoder device: encodes the data copied into buffer(B) and returns >> > to user application through buffer(C) >> > 8. User application: memcpy(3nd) encoded data from buffer(C) and save as >> > file >> > 9. do loop from 5 to 8 as long as you want to keep recording >> > >> > As you see above, at least three times of memcpy per frame are >> > necessary to make the recording and preview happened. Of course I took >> > a worst case for example because we can even take in-place thing for >> > encoder buffer, but I jut wanted to consider of drivers not capable to >> > take care of in-place algorithm for some reasons. >> > >> > Now let's imagine that we are recording 1920*1080 sized frame. can you >> > draw the picture in your mind how it might be inefficient? >> > >> > So, my second question is "Is V4L2 covering the best practice of video >> > recording for embedded system?" >> > As you know, embedded systems are running out of memories..and don't >> > have much enough memory bandwidth either. >> > I'm not seeing any standard way for "device to device" buffer handling >> > in V4L2 documents. If nobody has been considering this issue, can I >> > bring it on the table for make it in a unified way, therefor we can >> > make any improvement in opensource multimedia middlewares and drivers >> > as well. >> >> It's been considered, see this RFC: >> >> http://www.archivum.info/video4linux-list%40redhat.com/2008-07/msg00371.html >> >> A lot of the work done in the past year was actually to lay the foundation >> for implementing media controllers and media processors. >> >> But with a framework like this it should be possible to tell the v4l2 >> driver to link the output of the camera module to the input of the encoder. >> Functionality like that is currently missing in the API. > > There are two different use cases. The first one covers embedded hardware that > provide a direct camera -> codec link without requiring any intervention of > the CPU for data transfer. This is the most efficient solution if your > hardware is clever enough. It would require additions to the v4l2 API to > configure the links dynamically. > > The second one covers less clever embedded hardware, where video data has to
Re: [PATCH] em28xx: enable usb audio for plextor px-tv100u
Em Tue, 28 Jul 2009 20:07:53 -0400 ac...@fastmail.fm escreveu: > On Mon, Jul 27, 2009 at 09:28:11PM -0300, Mauro Carvalho Chehab wrote: > > Hi Acano, > > Tested-by: Angelo Cano > > works great Good! > > > + /*FIXME hack to unmute usb audio stream */ > > > + em28xx_set_ctrl(dev, ctrl); > > > > Hmm... this function were removed. In thesis, you shouldn't need to > > do anything to unmute. > > > > I still need it, see attachment. > > > > > Could you please try the enclosed patch and see if this is enough to fix for > > Plextor? If so, please send me a Tested-by: tag for me to add it at > > 2.6.31 fix patches. > > > > Like I said the patch works great, and also solves my audio volume > problem. With your patch the volume is set to a sane value > (presumably 0db) and the distortion/clipping is gone. > > Thanks man. The volume problem was driving me crazy. Ah, yes, there's a missing mute/unmute issue there. Instead of using your code, I opted to duplicate part of ac97_set_ctrl code there. I opted to have a small duplicated code, but, IMO, it is now clearer to see why we still need to call em28xx_audio_analog_set(). You will notice that I've rearranged the place where I update volume and mute. The rationale is that v4l2_device_call_all() might eventually change a value for volume/mute. Another reason is that, IMO, v4l2_device_call_all() should return values. In the specific case of volume/mute, if the user tries to specify a value outside the range, the -ERANGE should be returned. I've already committed the patches at the tree. Please double-check. Hans, we need to fix the returned error value for v4l2_device_call_all(). I know that this is an old issue that weren't changed by v4l dev/subdev conversion, but now it is easier for us to fix. The idea here is to be sure that, if a sub-driver with a proper handling for a function returns an error value, this would be returned by v4l2_device_call_all(). Maybe we'll need to adjust some things at the sub-drivers. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to save number of times using memcpy?
Hi Hans, On Tue, Jul 28, 2009 at 3:54 PM, Hans Verkuil wrote: > On Tuesday 28 July 2009 02:56:05 Dongsoo, Nathaniel Kim wrote: >> Hello everyone, >> >> What I'm gonna ask might be quite a bit tough couple of questions, but >> definitely necessary in multimedia device driver area. >> >> My first question is "Is any driver using using continuous physical >> memory has any chance to be adopted in main line kernel?" >> Because I'm afraid what I'm talking about is all about multimedia, >> which is consuming plenty of memory. >> But please note that in this case all the drivers I take care of are >> ARM SoC's peripheral device drivers.(ie. camera interface driver in >> Samsung CPU). And whenever we choose to use continuous physical >> memory, then current videobuf cannot be used in those kind of device >> drivers because of the io-remapping. > > Why not? This happens all the time, including in the new omap and davinci > drivers from TI. > > What typically happens is that the memory is allocated when the v4l driver > is loaded and not at first use. Due to memory fragmentation it becomes > almost impossible to allocate these buffers later so it has to be done as > early as possible. > Sorry I forgot to mention that I'm gonna reserve continuous physical memory on machine initializing exclusively for multimedia devices. I know that's an ugly way of approach but for now it's a strategy of my boss. >> >> >> And the other one is about how to handle the buffer used between >> couple of multimedia devices. >> Let me take an example of a camcorder scenario which takes series of >> pictures and encode them in some sort of multimedia encoded format. >> And let's assume that we are using a device of a SoC H/W which has >> it's own camera and multimedia encoder device as well. >> >> The scenario might be going like following order ordinarily. >> 1. User application: open camera device node and tries to mmap >> buffer(A) to be used. >> 2. Camera interface: try to allocate memory in kernel space and creates >> mapping. > > Wrong, this should have been point 1 because by this time it's pretty > unlikely you can allocate the buffers needed due to memory fragmentation. > >> 3. User application: open encoder device node and tries to mmap >> buffer(B) as input buffer and buffer(C) as output buffer to be used. >> 4. Start streaming >> 5. Camera interface: fetch data from external camera module and writes >> to the allocated buffer in kernel space and give back the memory >> address to user application through dqbuf >> 6. User application: memcpy(1st) returned buffer(A) to frame buffer >> therefore we can see as preview > > Unavoidable memcpy, unless there is some sort of hardware support to DMA > directly into the framebuffer. > Yes you are right. I was considering a worst case for some H/W not supporting this. >> 7. User application: memcpy(2nd) returned buffer(A) to buffer(B) of >> encoder device. > > So this is copying between two v4l2 video nodes, right? Correct. Each V4L2 drivers are made to work for system wide use. > >> 7. Encoder device: encodes the data copied into buffer(B) and returns >> to user application through buffer(C) >> 8. User application: memcpy(3nd) encoded data from buffer(C) and save as >> file >> 9. do loop from 5 to 8 as long as you want to keep recording >> >> As you see above, at least three times of memcpy per frame are >> necessary to make the recording and preview happened. Of course I took >> a worst case for example because we can even take in-place thing for >> encoder buffer, but I jut wanted to consider of drivers not capable to >> take care of in-place algorithm for some reasons. >> >> Now let's imagine that we are recording 1920*1080 sized frame. can you >> draw the picture in your mind how it might be inefficient? >> >> >> So, my second question is "Is V4L2 covering the best practice of video >> recording for embedded system?" >> As you know, embedded systems are running out of memories..and don't >> have much enough memory bandwidth either. >> I'm not seeing any standard way for "device to device" buffer handling >> in V4L2 documents. If nobody has been considering this issue, can I >> bring it on the table for make it in a unified way, therefor we can >> make any improvement in opensource multimedia middlewares and drivers >> as well. > > It's been considered, see this RFC: > > http://www.archivum.info/video4linux-list%40redhat.com/2008-07/msg00371.html > > A lot of the work done in the past year was actually to lay the foundation > for implementing media controllers and media processors. > > But with a framework like this it should be possible to tell the v4l2 driver > to link the output of the camera module to the input of the encoder. > Functionality like that is currently missing in the API. > I'm investigating your RFC. How could I miss that? BTW, it seems that I need much more time to understand whole of it. > I plan on reworking this RFC during this year's Plumbers conferen
Re: How to save number of times using memcpy?
Em Wed, 29 Jul 2009 12:30:19 +0900 "Dongsoo, Nathaniel Kim" escreveu: > Sorry my bad. I missed something very important to explain my issue clear. > The thing is, I want to reserve specific amount of continuous physical > memory on machine initializing time. Therefor some multimedia > peripherals can be using this memory area exclusively. > That's what I was afraid of could not being adopted in main line kernel. In the past, some drivers used to do that, but this is also a source of problems, especially with general-purpose machines, where you're loosing memory that could otherwise be used by something else. I never tried to get the details, but I think the strategy were to pass a parameter during kernel boot, for it to reserve some amount of memory that would later be claimed by the V4L device. > And if I use reserved memory on purpose, I might have problem using > videobuf because it uses dma_alloc_coherent() anyway. It is a matter of testing and adjusting it, if needed. Feel free to propose improvements on it as needed. > > There's also an special type of transfer called overlay mode. On the overlay > > mode, the DMA transfers are mapped directly into the output device. > > > > In general, the drivers that implement overlay mode also mmap(), but this is > > done, on those drivers, via a separate DMA transfer. > > > > The applications that benefit with overlay mode, uses overlay for display > > and > > mmap for record, and may have different resolutions on each mode. > > > > Yes I think if I'm getting right, I have similar feature which is > transferring data from camera interface to frame buffer with FIFO > pipeline. > And I consider this as an overlay feature. It seems so. By using overlay, you'll avoid memcpy the data. > I hope I could participate in cutting edge Linux technology with my works. > As far as I know, there are plenty of areas need to be improved for > camera devices in Linux kernel. Welcome to the team! For sure there are lots of work, especially when looking at embedded hardware needs. For a long time, most of V4L work were focused only on PC running at i386 architecture. Over the last years, some work is done to make it more generic and to enhance V4L to better support other architectures. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to save number of times using memcpy?
Hi Mauro, On Tue, Jul 28, 2009 at 12:35 PM, Mauro Carvalho Chehab wrote: > Hi Dongsoo, > > Em Tue, 28 Jul 2009 09:56:05 +0900 > "Dongsoo, Nathaniel Kim" escreveu: > >> Hello everyone, >> >> What I'm gonna ask might be quite a bit tough couple of questions, but >> definitely necessary in multimedia device driver area. >> >> My first question is "Is any driver using using continuous physical >> memory has any chance to be adopted in main line kernel?" >> Because I'm afraid what I'm talking about is all about multimedia, >> which is consuming plenty of memory. >> But please note that in this case all the drivers I take care of are >> ARM SoC's peripheral device drivers.(ie. camera interface driver in >> Samsung CPU). And whenever we choose to use continuous physical >> memory, then current videobuf cannot be used in those kind of device >> drivers because of the io-remapping. >> >> >> And the other one is about how to handle the buffer used between >> couple of multimedia devices. >> Let me take an example of a camcorder scenario which takes series of >> pictures and encode them in some sort of multimedia encoded format. >> And let's assume that we are using a device of a SoC H/W which has >> it's own camera and multimedia encoder device as well. >> >> The scenario might be going like following order ordinarily. >> 1. User application: open camera device node and tries to mmap >> buffer(A) to be used. >> 2. Camera interface: try to allocate memory in kernel space and creates >> mapping. >> 3. User application: open encoder device node and tries to mmap >> buffer(B) as input buffer and buffer(C) as output buffer to be used. >> 4. Start streaming >> 5. Camera interface: fetch data from external camera module and writes >> to the allocated buffer in kernel space and give back the memory >> address to user application through dqbuf >> 6. User application: memcpy(1st) returned buffer(A) to frame buffer >> therefore we can see as preview >> 7. User application: memcpy(2nd) returned buffer(A) to buffer(B) of >> encoder device. >> 7. Encoder device: encodes the data copied into buffer(B) and returns >> to user application through buffer(C) >> 8. User application: memcpy(3nd) encoded data from buffer(C) and save as file >> 9. do loop from 5 to 8 as long as you want to keep recording >> >> As you see above, at least three times of memcpy per frame are >> necessary to make the recording and preview happened. Of course I took >> a worst case for example because we can even take in-place thing for >> encoder buffer, but I jut wanted to consider of drivers not capable to >> take care of in-place algorithm for some reasons. >> >> Now let's imagine that we are recording 1920*1080 sized frame. can you >> draw the picture in your mind how it might be inefficient? >> > > I'm not sure if I understood your problem. Videobuf consists of 2 separate > parts: > a common core part, responsible for controlling the buffers; > a memory allocation specific part. > > There are currently 3 different implementations for the memory-specific one: > - dma scatter/gather buffers; > - dma contiguous buffer; > - vmalloc buffer. > > The first two are currently used by PCI devices (although they probably work > with other buses), while the third one is used on USB devices, where we need > to > remove the USB transport data from the stream, so, data needs to be copied. > > If you use one of the dma implementations, a stream is received from the > capture device, and can be directly mapped at the userspace application, via > mmap() ioctl. In this case, there's no memory copy between userspace and > kernelspace. The application will directly see the data. > Sorry my bad. I missed something very important to explain my issue clear. The thing is, I want to reserve specific amount of continuous physical memory on machine initializing time. Therefor some multimedia peripherals can be using this memory area exclusively. That's what I was afraid of could not being adopted in main line kernel. And if I use reserved memory on purpose, I might have problem using videobuf because it uses dma_alloc_coherent() anyway. > There's also an special type of transfer called overlay mode. On the overlay > mode, the DMA transfers are mapped directly into the output device. > > In general, the drivers that implement overlay mode also mmap(), but this is > done, on those drivers, via a separate DMA transfer. > > The applications that benefit with overlay mode, uses overlay for display and > mmap for record, and may have different resolutions on each mode. > Yes I think if I'm getting right, I have similar feature which is transferring data from camera interface to frame buffer with FIFO pipeline. And I consider this as an overlay feature. >> >> So, my second question is "Is V4L2 covering the best practice of video >> recording for embedded system?" >> As you know, embedded systems are running out of memories..and don't >> have mu
Re: Terratec Cinergy HibridT XS
Hi, Am Dienstag, den 28.07.2009, 20:44 -0400 schrieb Devin Heitmueller: > On Tue, Jul 28, 2009 at 7:32 PM, Valerio Messina wrote: > > hi all, > > > > I own a Terratec Cinergy HibridT XS > > with lsusb ID: > > Bus 001 Device 007: > > ID 0ccd:0042 TerraTec Electronic GmbH Cinergy Hybrid T XS > > > > With past kernel and a patch as suggested here: > > http://www.linuxtv.org/wiki/index.php/TerraTec > > that link to: > > http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_Hybrid_T_USB_XS > > that link to: > > http://mcentral.de/wiki/index.php5/Main_Page > > and some troubles for Ubuntu kernel that I solved here: > > https://bugs.launchpad.net/bugs/322732 > > worked well for a year or more. > > > > With last Ubuntu 9.04, kernel 2.6.28-13 seems have native support for the > > tuner, but from dmesg a file is missing: xc3028-v27.fw > > (maybe manage I2C for IR?) > > I found it on a web site, copied in /lib/firmware > > and now Kaffeine work, but ... no more IR remote command work. > > > > More bad now: > > http://mcentral.de/wiki/index.php5/Installation_Guide > > sell TV tuner, and do not support anymore the Terratec tuner, the source > > repository is disappeared, and install instruction is a commercial. all in all it is really funny. > > Any chanches? > > > > thanks in advace, > > Valerio > > That device, including full support for the IR, is now supported in > the mainline v4l-dvb tree (and will appear in kernel 2.6.31). Just > follow the directions here to get the code: > > http://linuxtv.org/repo > > Devin > Hopefully nobody is mad enough to buy for such prices. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy HibridT XS
On Tue, Jul 28, 2009 at 7:32 PM, Valerio Messina wrote: > hi all, > > I own a Terratec Cinergy HibridT XS > with lsusb ID: > Bus 001 Device 007: > ID 0ccd:0042 TerraTec Electronic GmbH Cinergy Hybrid T XS > > With past kernel and a patch as suggested here: > http://www.linuxtv.org/wiki/index.php/TerraTec > that link to: > http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_Hybrid_T_USB_XS > that link to: > http://mcentral.de/wiki/index.php5/Main_Page > and some troubles for Ubuntu kernel that I solved here: > https://bugs.launchpad.net/bugs/322732 > worked well for a year or more. > > With last Ubuntu 9.04, kernel 2.6.28-13 seems have native support for the > tuner, but from dmesg a file is missing: xc3028-v27.fw > (maybe manage I2C for IR?) > I found it on a web site, copied in /lib/firmware > and now Kaffeine work, but ... no more IR remote command work. > > More bad now: > http://mcentral.de/wiki/index.php5/Installation_Guide > sell TV tuner, and do not support anymore the Terratec tuner, the source > repository is disappeared, and install instruction is a commercial. > > > Any chanches? > > thanks in advace, > Valerio That device, including full support for the IR, is now supported in the mainline v4l-dvb tree (and will appear in kernel 2.6.31). Just follow the directions here to get the code: http://linuxtv.org/repo Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch: Kaiser Baas ExpressCard Dual HD Tuner
Hi.
I'm new to the list - please bear with me.
I've spent some time getting a recently purchased Kaiser Baas
ExpressCard Dual HD Tuner working with MythTV. I ended up patching some
of the dib0700 work. I'd like to submit the patches back to the
community.
Cheers.
--
James A Webb
Ph. +61 (3) 9015 780710 Dickens St, Blackburn
Ph. +64 (9) 889 0807 Victoria 3130
Mob. +61 (40) 525 7807 Australia
--- linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-07-25 07:47:51.0 +1000
+++ dib0700_devices.c 2009-07-28 16:31:47.053327159 +1000
@@ -1456,6 +1456,7 @@
USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY) },
{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_TD_STICK) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK7700D) },
+{ USB_DEVICE(USB_VID_YUAN, USB_PID_DIBCOM_STK7700DY) },
/* 15 */{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK7070P) },
{ USB_DEVICE(USB_VID_PINNACLE, USB_PID_PINNACLE_PCTV_DVB_T_FLASH) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK7070PD) },
usb 1-2: new high speed USB device using ehci_hcd and address 4
usb 1-2: New USB device found, idVendor=1164, idProduct=1e8c
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: STK7700D
usb 1-2: Manufacturer: YUANRD
usb 1-2: SerialNumber: 01
usb 1-2: configuration #1 chosen from 1 choice
dib0700: loaded with support for 9 different device-types
dvb-usb: found a 'DiBcom STK7070P reference design' in cold state, will try to
load a firmware
usb 1-2: firmware: requesting dvb-usb-dib0700-1.20.fw
dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
dib0700: firmware started successfully.
dvb-usb: found a 'DiBcom STK7070P reference design' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (DiBcom STK7070P reference design)
DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)...
DiB0070: successfully identified
input: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:1a.7/usb1/1-2/input/input17
dvb-usb: schedule remote query interval to 50 msecs.
dvb-usb: DiBcom STK7070P reference design successfully initialized and
connected.
usbcore: registered new interface driver dvb_usb_dib0700
--- linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-07-25 07:47:51.0 +1000
+++ dvb-usb-ids.h 2009-07-28 16:31:47.066282516 +1000
@@ -90,6 +90,7 @@
#define USB_PID_DIBCOM_STK7700P 0x1e14
#define USB_PID_DIBCOM_STK7700P_PC 0x1e78
#define USB_PID_DIBCOM_STK7700D 0x1ef0
+#define USB_PID_DIBCOM_STK7700DY0x1e8c
#define USB_PID_DIBCOM_STK7700_U70000x7001
#define USB_PID_DIBCOM_STK7070P 0x1ebc
#define USB_PID_DIBCOM_STK7070PD0x1ebe
Bus 001 Device 004: ID 1164:1e8c YUAN High-Tech Development Co., Ltd
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x1164 YUAN High-Tech Development Co., Ltd
idProduct 0x1e8c
bcdDevice1.00
iManufacturer 1 YUANRD
iProduct2 STK7700D
iSerial 3 01
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Re: [PATCH] em28xx: enable usb audio for plextor px-tv100u
On Mon, Jul 27, 2009 at 09:28:11PM -0300, Mauro Carvalho Chehab wrote:
> Hi Acano,
Tested-by: Angelo Cano
works great
> > + /*FIXME hack to unmute usb audio stream */
> > + em28xx_set_ctrl(dev, ctrl);
>
> Hmm... this function were removed. In thesis, you shouldn't need to
> do anything to unmute.
>
I still need it, see attachment.
>
> Could you please try the enclosed patch and see if this is enough to fix for
> Plextor? If so, please send me a Tested-by: tag for me to add it at
> 2.6.31 fix patches.
>
Like I said the patch works great, and also solves my audio volume
problem. With your patch the volume is set to a sane value
(presumably 0db) and the distortion/clipping is gone.
Thanks man. The volume problem was driving me crazy.
diff -r fd96af63f79b linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Fri Jun 19 19:56:56 2009 +
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Tue Jul 28 19:26:58 2009 -0400
@@ -639,22 +639,27 @@ struct em28xx_board em28xx_boards[] = {
},
[EM2861_BOARD_PLEXTOR_PX_TV100U] = {
.name = "Plextor ConvertX PX-TV100U",
- .valid= EM28XX_BOARD_NOT_VALIDATED,
.tuner_type = TUNER_TNF_5335MF,
+ .xclk = EM28XX_XCLK_I2S_MSB_TIMING |
+EM28XX_XCLK_FREQUENCY_12MHZ,
.tda9887_conf = TDA9887_PRESENT,
.decoder = EM28XX_TVP5150,
+ .has_msp34xx = 1,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
.amux = EM28XX_AMUX_LINE_IN,
+ .gpio = pinnacle_hybrid_pro_analog,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = TVP5150_COMPOSITE1,
.amux = EM28XX_AMUX_LINE_IN,
+ .gpio = pinnacle_hybrid_pro_analog,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = TVP5150_SVIDEO,
.amux = EM28XX_AMUX_LINE_IN,
+ .gpio = pinnacle_hybrid_pro_analog,
} },
},
@@ -1948,9 +1953,8 @@ void em28xx_pre_card_setup(struct em28xx
/* request some modules */
switch (dev->model) {
case EM2861_BOARD_PLEXTOR_PX_TV100U:
- /* FIXME guess */
- /* Turn on analog audio output */
- em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd);
+ /* Sets the msp34xx I2S speed */
+ dev->i2s_speed = 2048000;
break;
case EM2861_BOARD_KWORLD_PVRTV_300U:
case EM2880_BOARD_KWORLD_DVB_305U:
diff -r fd96af63f79b linux/drivers/media/video/em28xx/em28xx-video.c
--- a/linux/drivers/media/video/em28xx/em28xx-video.c Fri Jun 19 19:56:56 2009 +
+++ b/linux/drivers/media/video/em28xx/em28xx-video.c Tue Jul 28 19:26:58 2009 -0400
@@ -1123,8 +1123,32 @@ static int vidioc_s_ctrl(struct file *fi
else
rc = 1;
- /* It were not an AC97 control. Sends it to the v4l2 dev interface */
+ /* It we're not an AC97 control. Sends it to the v4l2 dev interface */
if (rc == 1) {
+ /* hack ac97_set_ctrl() call to unmute usb audio for Plextor ConvertX
+ * PX-TV100U
+ *
+ * need to eventually reach em28xx_audio_analog_set()
+ *
+ * and:
+ *
+ * xclk = dev->board.xclk & 0x7f;
+ * if (!dev->mute)
+ * xclk |= EM28XX_XCLK_AUDIO_UNMUTE;
+ *
+ * ret = em28xx_write_reg(dev, EM28XX_R0F_XCLK, xclk);
+ * if (ret < 0)
+ * return ret;
+ * msleep(10);
+ *
+ *
+ * included here as a simple call ac97_set_ctrl() since the path to
+ * em28xx_audio_analog_set() has the necessary conditional checks
+ * which I don't want to bother duplicating, and in case I needed
+ * something else besides unmuting.
+ */
+ ac97_set_ctrl(dev, ctrl);
+
v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_ctrl, ctrl);
/* FIXME: should be returning a meaninful value */
rc = 0;
Terratec Cinergy HibridT XS
hi all, I own a Terratec Cinergy HibridT XS with lsusb ID: Bus 001 Device 007: ID 0ccd:0042 TerraTec Electronic GmbH Cinergy Hybrid T XS With past kernel and a patch as suggested here: http://www.linuxtv.org/wiki/index.php/TerraTec that link to: http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_Hybrid_T_USB_XS that link to: http://mcentral.de/wiki/index.php5/Main_Page and some troubles for Ubuntu kernel that I solved here: https://bugs.launchpad.net/bugs/322732 worked well for a year or more. With last Ubuntu 9.04, kernel 2.6.28-13 seems have native support for the tuner, but from dmesg a file is missing: xc3028-v27.fw (maybe manage I2C for IR?) I found it on a web site, copied in /lib/firmware and now Kaffeine work, but ... no more IR remote command work. More bad now: http://mcentral.de/wiki/index.php5/Installation_Guide sell TV tuner, and do not support anymore the Terratec tuner, the source repository is disappeared, and install instruction is a commercial. Any chanches? thanks in advace, Valerio -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] saa7134: fix the radio on Avermedia GO 007 FM
We have support for radio on saa7133/35/31e cards with tda8290/8275(a)
and 5.5MHz ceramic filter on the bridge chips since a while.
It was previously not tested, if this card supports it too, but the old
"ghost" radio with wrong filters doesn't work anymore.
Thanks go to Pham Thanh Nam and Laszlo Kustan for reporting it working
on that input.
Signed-off-by: hermann pitton
diff -r fd96af63f79b linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Jun 19 19:56:56
2009 +
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Tue Jul 28 22:16:52
2009 +0200
@@ -1633,7 +1633,7 @@
}},
.radio = {
.name = name_radio,
- .amux = LINE1,
+ .amux = TV,
.gpio = 0x0031,
},
.mute = {
diff -r fd96af63f79b linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Jun 19 19:56:56 2009 +
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Tue Jul 28 22:16:52 2009 +0200
@@ -1633,7 +1633,7 @@
}},
.radio = {
.name = name_radio,
- .amux = LINE1,
+ .amux = TV,
.gpio = 0x0031,
},
.mute = {
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Jul 28 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12343:fd96af63f79b gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc3-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-rc3-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-rc3-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-i686: WARNINGS linux-2.6.31-rc3-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc3-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc3-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: OK linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc3-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc3-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx
Mauro, Changeset 0842e3bae660 thoroughly breaks all of the Hauppauge devices that use the sms1xxx driver. This changeset adds device specific changes that affect Hauppauge devices, ONLY. It added no value to the driver, and only broke its functionality. I specifically nack'd this particular changeset, but it was merged anyway. I believe this was done in error, since it was one patch in the middle of many others sent in from Uri at that point in time. This change breaks the Hauppauge devices in such a way that prevents normal device operation. The entire concept of board events in this driver is thoroughly broken, and the only devices currently using it are the Hauppauge devices. The patchset removes the board event usage from the Hauppauge-specific device configuration, replacing with the older mechanism to handle board events. The event functions being called in smsdvb.c call into sms-cards.c -- if the device configuration does not have functionality defined for that event, the driver will simply do nothing and return control back to the smsdvb.c driver. These functions are a no-op for non-hauppauge devices. Under no circumstances will they cause any harm or any breakage to any devices supported by this driver. Personally, I would like to see this board event mechanism within the driver repaired, so that the Hauppauge devices can use the new mechanism that Siano has created. Until that mechanism functions properly, we will use the older mechanism. Not doing so would be a regression, since all of this functionality worked in previous kernels. These two changesets must be merged ASAP and sent to Linus for the 2.6.31 kernel. Please pull from: http://kernellabs.com/hg/~mkrufky/sms1xxx for the following fixes: - sms1xxx: fix broken Hauppauge devices - sms1xxx: restore GPIO functionality for all Hauppauge devices sms-cards.c | 100 smsdvb.c| 44 + 2 files changed, 44 insertions(+), 100 deletions(-) Cheers, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - saa7134: fix lock imbalancedefault tip - af9015: Fix for crash in dvb-usb-af9015 - v4l doc: fix cqcam source code path - stv680: kfree called before usb_kill_urb - ir-kbd-i2c: Add support for Z8F0811/Hauppage IR transceivers - cx18: Add i2c initialization for Z8F0811/Hauppage IR transceivers - ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type - ir-kbd-i2c: Remove superfulous inlines - ir-kbd-i2c: fix spaces - gspca - sn9c20x: Fix up i2c_r functions Thanks, Douglas -- 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: Philips SPC230NC: wrong colors / image format?
Hi,
On 07/17/2009 06:28 PM, Andi Drebes wrote:
Hi!
I tried to find a mailing list for the v4l compatibility library, but I
didn't find any.
You can use "Linux Media Mailing List ", guess
I should put that in the README.
This is why I'm sending this email directly to you.
No problem.
Some weeks ago I bought a Philips SPC230NC webcam. It seems that the
camera is supported by the pac7311 driver. In order to use the cam in some
older applications, I tried out the compatibility library. It almost
works; the only problem is that the video is distorted and that the colors
are not right. Here's what a keyboard looks like in camorama:
http://drebesium.org/~hackbert/Webcam-1247846047.png
Ah that is a bug in camorama, I've attached a patch which fixes this. I've also
added a patch which make camorama use libv4l directly so you do not need todo
the LD_PRELOAD thingie.
Regards,
Hans
I'm using a 2.6.30.1 kernel on debian lenny. I tried out libv4l-0.6.0 and
libv4l-0.6.1-test. They both provide the same results. As far as the
hardware is concerned, lsusb tells me:
093a:262c Pixart Imaging, Inc.
Dmesg does not show any errors:
[ 3216.124322] gspca: main v2.5.0 registered
[ 3216.128254] gspca: probing 093a:262c
[ 3216.145196] gspca: probe ok
I used the following command to start camorama:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/src/libv4l-0.6.0/libv4l1/:/usr/src/libv4l-0.6.0/libv4l2/:/usr/src/libv4l-0.6.0/libv4lconvert/
LD_PRELOAD=/usr/src/libv4l-0.6.0/libv4l1/v4l1compat.so camorama
Do you have any idea what might be wrong? Again, sorry to bug you directly
with this. If there's any mailinglist or something, I would be glad if you
could indicate me the address. In that case, feel free to ignore the
content of this mail.
Thanks in advance,
Andi
--- camorama-0.19/src/callbacks.c 2007-09-16 15:36:55.0 +0200
+++ camorama-0.19.new/src/callbacks.c 2008-06-29 22:22:44.0 +0200
@@ -387,9 +387,6 @@
}
}
-cam->pixmap = gdk_pixmap_new (NULL, cam->x, cam->y, cam->desk_depth);
-gtk_widget_set_size_request (glade_xml_get_widget (cam->xml, "da"),
- cam->x, cam->y);
/*
* if(cam->read == FALSE) {
@@ -441,6 +438,11 @@
* * }
*/
get_win_info (cam);
+
+cam->pixmap = gdk_pixmap_new (NULL, cam->x, cam->y, cam->desk_depth);
+gtk_widget_set_size_request (glade_xml_get_widget (cam->xml, "da"),
+ cam->x, cam->y);
+
frame = 0;
gtk_window_resize (GTK_WINDOW
(glade_xml_get_widget (cam->xml, "main_window")), 320,
@@ -520,8 +522,14 @@
gtk_widget_show (about);
}
+void
+camorama_filter_color_filter(void* filter, guchar *image, int x, int y, int
depth);
+
static void
apply_filters(cam* cam) {
+ /* v4l has reverse rgb order from what camora expect so call the color
+ filter to fix things up before running the user selected filters */
+ camorama_filter_color_filter(NULL, cam->pic_buf, cam->x, cam->y,
cam->depth);
camorama_filter_chain_apply(cam->filter_chain, cam->pic_buf, cam->x,
cam->y, cam->depth);
#warning "FIXME: enable the threshold channel filter"
// if((effect_mask & CAMORAMA_FILTER_THRESHOLD_CHANNEL) != 0)
--- camorama-0.19/src/filter.c 2007-09-16 14:48:50.0 +0200
+++ camorama-0.19.new/src/filter.c 2008-06-29 22:11:42.0 +0200
@@ -151,12 +151,12 @@
static void
camorama_filter_color_init(CamoramaFilterColor* self) {}
-static void
+void
camorama_filter_color_filter(CamoramaFilterColor* filter, guchar *image, int
x, int y, int depth) {
int i;
char tmp;
i = x * y;
- while (--i) {
+ while (i--) {
tmp = image[0];
image[0] = image[2];
image[2] = tmp;
--- camorama-0.19/src/main.c2007-09-16 15:36:55.0 +0200
+++ camorama-0.19.new/src/main.c2008-06-29 22:20:04.0 +0200
@@ -224,8 +224,7 @@
/* get picture attributes */
get_pic_info (cam);
-// set_pic_info(cam);
-/* set_pic_info(cam); */
+set_pic_info (cam);
cam->contrast = cam->vid_pic.contrast;
cam->brightness = cam->vid_pic.brightness;
cam->colour = cam->vid_pic.colour;
--- camorama-0.19/src/v4l.c 2007-09-16 14:48:05.0 +0200
+++ camorama-0.19.new/src/v4l.c 2008-06-29 22:20:23.0 +0200
@@ -158,8 +158,8 @@
if(cam->debug) {
g_message("SET PIC");
}
- //cam->vid_pic.palette = VIDEO_PALETTE_RGB24;
- //cam->vid_pic.depth = 24;
+ cam->vid_pic.palette = VIDEO_PALETTE_RGB24;
+ cam->vid_pic.depth = 24;
//cam->vid_pic.palette = VIDEO_PALETTE_YUV420P;
if(ioctl(cam->dev, VIDIOCSPICT, &cam->vid_pic) == -1) {
if(cam->debug) {
@@ -232,6 +232,8 @@
exit(0);
}
+ cam->x = cam->vid_win.width;
+ cam->y = cam->vid_win.height;
}
Re: [PULL] http://linuxtv.org/hg/~dougsland/video4linux
Hello Andy, On Tue, 28 Jul 2009 07:40:24 -0400 Andy Walls wrote: > On Mon, 2009-07-27 at 22:28 -0300, Douglas Schilling Landgraf wrote: > > Hello Mauro, > > > > Please pull from http://linuxtv.org/hg/~dougsland/video4linux for > > the following: > > > > - saa7134: fix lock imbalance > > - Fix for crash in dvb-usb-af9015 > > - v4l doc: fix cqcam source code path > > - stv680: kfree called before usb_kill_urb > > - ir-kbd-i2c: Add support for Z8F0811/Hauppage IR transceivers > > - cx18: Add i2c initialization for Z8F0811/Hauppage IR transceivers > > Hi, > > Looking through the web interface, this "#define" looks like it might > have been imported with a problem: > > http://linuxtv.org/hg/~dougsland/video4linux/rev/81939abc76b1#l2.23 > > please ensure there is a space or tab between the symbol and the open > parenthesis: > > #define CX18_HW_Z8F0811_IR_HAUP (CX18_HW_Z8F0811_IR_RX_HAUP | \ >CX18_HW_Z8F0811_IR_TX_HAUP) > > This might just be a web interface rendering problem. Weird thing, all patches applied clean as usually I do. Anyway, you are right and I am going to create a new tree. Thanks for pointing that. Mauro: Please *do not* pull from this tree. Cheers, Douglas > Thanks, > Andy > > > > - ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and > > set ir_type > > - ir-kbd-i2c: Remove superfulous inlines > > - gspca - sn9c20x: Fix up i2c_r functions > > > > Thanks, > > Douglas > > -- > > 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: [PULL] http://linuxtv.org/hg/~dougsland/video4linux
On Mon, 2009-07-27 at 22:28 -0300, Douglas Schilling Landgraf wrote: > Hello Mauro, > > Please pull from http://linuxtv.org/hg/~dougsland/video4linux for the > following: > > - saa7134: fix lock imbalance > - Fix for crash in dvb-usb-af9015 > - v4l doc: fix cqcam source code path > - stv680: kfree called before usb_kill_urb > - ir-kbd-i2c: Add support for Z8F0811/Hauppage IR transceivers > - cx18: Add i2c initialization for Z8F0811/Hauppage IR transceivers Hi, Looking through the web interface, this "#define" looks like it might have been imported with a problem: http://linuxtv.org/hg/~dougsland/video4linux/rev/81939abc76b1#l2.23 please ensure there is a space or tab between the symbol and the open parenthesis: #define CX18_HW_Z8F0811_IR_HAUP (CX18_HW_Z8F0811_IR_RX_HAUP | \ CX18_HW_Z8F0811_IR_TX_HAUP) This might just be a web interface rendering problem. Thanks, Andy > - ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type > - ir-kbd-i2c: Remove superfulous inlines > - gspca - sn9c20x: Fix up i2c_r functions > > Thanks, > Douglas > -- > 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
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 8 changesets: 01/08: gspca - sn9c20x: Misc fixes. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=d34d547d159b 02/08: gspca - vc032x: Fix mi1310_soc preview and LED. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=49966c5f2052 03/08: gspca - vc032x: Add the 1280x960 resolution for sensor mi1310_soc. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=c9c025650ce7 04/08: gspca - vc032x: H and V flip controls added for mi13x0_soc sensors. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=266dc538f544 05/08: gspca - vc032x: Cleanup source. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=a9c0f8857acc 06/08: gspca - sonixj: Webcam 0c45:6148 added. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=0db8e7ea7899 07/08: gspca - tv8532: Bad ISOC packet scan. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=5745cd8bb0f3 08/08: gspca - main: Memorize the current alt before setting it. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=0a809605b502 Documentation/video4linux/gspca.txt |1 drivers/media/video/gspca/gspca.c |2 drivers/media/video/gspca/sn9c20x.c | 38 - drivers/media/video/gspca/sonixj.c |8 drivers/media/video/gspca/tv8532.c |2 drivers/media/video/gspca/vc032x.c | 875 6 files changed, 520 insertions(+), 406 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pinnacle 3010ix and SAA716x drivers
I have a Pinnacle 3010ix which I am trying to get to work under Linux. The chips it uses are the SAA7162 video decoder/analog demodulator/PCI-E controller, TDA8265A TV tuner (x2) and TDA10046A DVB-T demodulator (x2). So far I have managed to load the driver for this card (vendor 1131, product 7162, subsystem vendor 11bd, subsystem product 100), which is saa716x, compiled from http://www.jusst.de/hg/saa716x/. The current problem is that the TDA10046A driver (tda1004x) is reporting "Invalid tda1004x ID = 0xff. Can't proceed", which seems to indicate either a firmware problem (I am using the latest available firmware from the get-dvb-firmware script), or some kind of driver issue. The SAA7162 seems to be functional, and /dev/dvb shows adapter0 and adapter1, under which are demux0, dvr0 and net0, but notably not frontend0, which suggests, as one might expect, that the frontend failed to initialise. Pertinent dmesg output as follows: [ 3163.548084] SAA716x Hybrid :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 3163.548093] SAA716x Hybrid :01:00.0: setting latency timer to 64 [ 3163.605331] DVB: registering new adapter (SAA716x dvb adapter) [ 3163.713096] Invalid tda1004x ID = 0xff. Can't proceed [ 3163.713104] DVB: registering new adapter (SAA716x dvb adapter) [ 3163.824165] Invalid tda1004x ID = 0xff. Can't proceed Any advice on getting the TDA1004A to work? Regards, Nick Spooner -- 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
KWorld Plus TV 380UR DVB-T USB
Hi All I'm trying to determine if the KWorld Plus TV 380UR DVB-T USB is supported. I've done a comprehensive search of the net and the mailing lists and tried about everything. I can get the v4l drivers to register the device at /dev/video1 and /dev/vbi0 but can't get the dvb at /dev/dvb etc I'm using FC8 with kernel as follows: #uname - a #Linux localhost.localdomain 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 19:19:45 EST 2008 i686 i686 i386 GNU/Linux Here's what I've done to date: *When I first plugged in the device I got the following from dmesg usb 1-1: New USB device found, idVendor=eb1a, idProduct=e359 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB 2870 Device *lsusb gave Bus 001 Device 005: ID eb1a:e359 eMPIA Technology, Inc. *Googling this vendor and product id got me on to the v4l-dvb wiki *Downloaded, compiled and installed v4l-dvb *Determined that this is a em28xx device *On reboot was able to load the drivers using modprobe *Plugging in device gave same dmesg output (nothing new) *After finding an obscure Estonian reference to changing v4l-dvb/linux/drivers/media/video/em28xx/em28xx-cards.c to include reference to eb1a:e359 as a KWORLD_355U, made the required change to em28xx-cards.c then did a make rminstall, make distclean and recompiled the drivers. *After reboot and then reinserting the device got the following dmesg output usb 1-1: new high speed USB device using ehci_hcd and address 4 usb 1-1: configuration #1 chosen from 1 choice em28xx: New device USB 2870 Device @ 480 Mbps (eb1a:e359, interface 0, class 0) em28xx #0: Identified as Kworld 355 U DVB-T (card=42) em28xx #0: chip ID is em2870 em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 59 e3 c0 12 62 40 6a 22 00 00 em28xx #0: i2c eeprom 10: 00 00 04 57 60 0d 00 00 60 00 00 00 02 00 00 00 em28xx #0: i2c eeprom 20: 54 00 00 00 f0 10 01 00 00 00 00 00 5b 00 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 37 00 30 00 20 00 44 00 em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xa4317302 em28xx #0: EEPROM info: em28xx #0: No audio on board. em28xx #0: 500mA max power em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x em28xx #0: em28xx #0: The support for this board weren't valid yet. em28xx #0: Please send a report of having this working em28xx #0: not to V4L mailing list (and/or to other addresses) tuner 0-0062: chip found @ 0xc4 (em28xx #0) tuner 0-0062: tuner type not set em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 device registered as /dev/video1 and /dev/vbi0 *This results in the device nodes /dev/video1 and /dev/vbi0 being created but stops short of giving me /dev/dvb/adapter etc Any advice or help you can provide is greatly appreciated. I can provide Windows drivers from the install disk if required. Thanks in advance larowlan Contact at rowlands dash bcs dot 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 save number of times using memcpy?
On Tuesday 28 July 2009 08:54:12 Hans Verkuil wrote: > On Tuesday 28 July 2009 02:56:05 Dongsoo, Nathaniel Kim wrote: [snip] > > And the other one is about how to handle the buffer used between > > couple of multimedia devices. > > Let me take an example of a camcorder scenario which takes series of > > pictures and encode them in some sort of multimedia encoded format. > > And let's assume that we are using a device of a SoC H/W which has > > it's own camera and multimedia encoder device as well. > > > > The scenario might be going like following order ordinarily. > > 1. User application: open camera device node and tries to mmap > > buffer(A) to be used. > > 2. Camera interface: try to allocate memory in kernel space and creates > > mapping. > > Wrong, this should have been point 1 because by this time it's pretty > unlikely you can allocate the buffers needed due to memory fragmentation. > > > 3. User application: open encoder device node and tries to mmap > > buffer(B) as input buffer and buffer(C) as output buffer to be used. > > 4. Start streaming > > 5. Camera interface: fetch data from external camera module and writes > > to the allocated buffer in kernel space and give back the memory > > address to user application through dqbuf > > 6. User application: memcpy(1st) returned buffer(A) to frame buffer > > therefore we can see as preview > > Unavoidable memcpy, unless there is some sort of hardware support to DMA > directly into the framebuffer. Or unless you use the USERPTR method instead of MMAP, providing your graphics hardware provides some sort of video display capabilities (similar to Xv for instance). You can then allocate a video buffer and ask the camera driver to DMA data directly to that buffer. This requires 1. the video buffer to be contiguous in virtual memory (no stride) 2. the video buffer to be contiguous in physical memory, OR the camera DMA to support scatter-gather. > > 7. User application: memcpy(2nd) returned buffer(A) to buffer(B) of > > encoder device. > > So this is copying between two v4l2 video nodes, right? Does your hardware allow chaining the camera and codec directly without going through memory buffers ? > > 7. Encoder device: encodes the data copied into buffer(B) and returns > > to user application through buffer(C) > > 8. User application: memcpy(3nd) encoded data from buffer(C) and save as > > file > > 9. do loop from 5 to 8 as long as you want to keep recording > > > > As you see above, at least three times of memcpy per frame are > > necessary to make the recording and preview happened. Of course I took > > a worst case for example because we can even take in-place thing for > > encoder buffer, but I jut wanted to consider of drivers not capable to > > take care of in-place algorithm for some reasons. > > > > Now let's imagine that we are recording 1920*1080 sized frame. can you > > draw the picture in your mind how it might be inefficient? > > > > So, my second question is "Is V4L2 covering the best practice of video > > recording for embedded system?" > > As you know, embedded systems are running out of memories..and don't > > have much enough memory bandwidth either. > > I'm not seeing any standard way for "device to device" buffer handling > > in V4L2 documents. If nobody has been considering this issue, can I > > bring it on the table for make it in a unified way, therefor we can > > make any improvement in opensource multimedia middlewares and drivers > > as well. > > It's been considered, see this RFC: > > http://www.archivum.info/video4linux-list%40redhat.com/2008-07/msg00371.html > > A lot of the work done in the past year was actually to lay the foundation > for implementing media controllers and media processors. > > But with a framework like this it should be possible to tell the v4l2 > driver to link the output of the camera module to the input of the encoder. > Functionality like that is currently missing in the API. There are two different use cases. The first one covers embedded hardware that provide a direct camera -> codec link without requiring any intervention of the CPU for data transfer. This is the most efficient solution if your hardware is clever enough. It would require additions to the v4l2 API to configure the links dynamically. The second one covers less clever embedded hardware, where video data has to go to a memory buffer between the camera interface and the codec. In that case it could be useful to allocate v4l2 buffers shared between the camera and codec v4l2 devices. This is not handled by v4l2 at the moment either. > I plan on reworking this RFC during this year's Plumbers conference in > September (http://linuxplumbersconf.org/2009/). You should consider > attending if you want to join these discussions. It would be very valuable > to have your input. > > > By the way.. among the examples above I mentioned, I took an example > > of codec device. right? How far are we with codec devices in V4L2 > > communi
Re: lsmod path hardcoded in v4l/Makefile
On Mon, 27 Jul 2009, Mauro Carvalho Chehab wrote: > Em Tue, 21 Jul 2009 09:14:36 +0200 > Matthias Schwarzott escreveu: > It is not a good idea to run as root. Most people compile everything > with a normal user and then use "sudo" command to install/remove/insert > modules. Unfortunately, depending on the distribution, sudo inherits PATH from > the normal user, instead of root. Due to that, if you replace it for just > lsmod, it will fail for people that don't use gentoo. > > Maybe good solution is to test if lsmod (and other similar tools) are at /sbin > or /usr/sbin. > > Alternatively, we can try to replace lsmod by something like (untested): > > v4l_modules := $(shell PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin lsmod|cut > -d' ' -f1 ) $(patsubst %.ko,%,$(inst-m)) Check my patch again, we can just delete the v4l_modules line as nothing uses it. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
