Re: RFCv2: Media controller proposal
On Friday 11 September 2009 08:16:34 Hiremath, Vaibhav wrote: > > > -Original Message- > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > ow...@vger.kernel.org] On Behalf Of Hans Verkuil > > Sent: Thursday, September 10, 2009 12:43 PM > > To: linux-media@vger.kernel.org > > Subject: RFCv2: Media controller proposal > > > > Hi all, > > > > Here is the new Media Controller RFC. It is completely rewritten > > from the > > original RFC. This original RFC can be found here: > > > > http://www.archivum.info/video4linux-list%40redhat.com/2008- > > 07/00371/RFC:_Add_support_to_query_and_change_connections_inside_a_m > > edia_device > > > [Hiremath, Vaibhav] I could see implementation has changed/evolved a lot here > from last RFC. Yes it has. The global idea remains the same, but at the time we didn't have sub-devices and that is (not entirely accidentally) a perfect match for what we need here. > I added some quick comments below, try to provide more during weekend. > > > This document will be the basis of the discussions during the > > Plumbers > > Conference in two weeks time. > > > > Open issue #3 is the main unresolved item, but I hope to come up > > with something > > during the weekend. > > > > Regards, > > > > Hans > > > > > > RFC: Media controller proposal > > > > Version 2.0 > > > > Background > > == > > > > This RFC is a new version of the original RFC that was written in > > cooperation > > with and on behalf of Texas Instruments about a year ago. > > > > Much work has been done in the past year to put the foundation in > > place to > > be able to implement a media controller and now it is time for this > > updated > > version. The intention is to discuss this in more detail during this > > years > > Plumbers Conference. > > > > Although the high-level concepts are the same as in the original > > RFC, many > > of the details have changed based on what was learned over the past > > year. > > > > This RFC is based on the original discussions with Manjunath Hadli > > from TI > > last year, on discussions during a recent meeting between Laurent > > Pinchart, > > Guennadi Liakhovetski and myself, and on recent discussions with > > Nokia. > > Thanks to Sakari Ailus for doing an initial review of this RFC. > > > > One note regarding terminology: a 'board' is the name I use for the > > SoC, > > PCI or USB device that contains the video hardware. Each board has > > its own > > driver instance and its own v4l2_device struct. Originally I called > > it > > 'device', but that name is already used in too many places. > > > > > > What is a media controller? > > === > > > > In a nutshell: a media controller is a new v4l device node that can > > be used > > to discover and modify the topology of the board and to give access > > to the > > low-level nodes (such as previewers, resizers, color space > > converters, etc.) > > that are part of the topology. > > > > It does not do any streaming, that is the exclusive domain of video > > nodes. > > It is meant purely for controlling a board as a whole. > > > > > > Why do we need one? > > === > > > > There are currently several problems that are impossible to solve > > within the > > current V4L2 API: > > > > 1) Discovering the various device nodes that are typically created > > by a video > > board, such as: video nodes, vbi nodes, dvb nodes, alsa nodes, > > framebuffer > > nodes, input nodes (for e.g. webcam button events or IR remotes). > > > > It would be very handy if an application can just open an > > /dev/v4l/mc0 node > > and be able to figure out where all the nodes are, and to be able to > > figure > > out what the capabilities of the board are (e.g. does it support > > DVB, is the > > audio going through a loopback cable or is there an alsa device, can > > it do > > compressed MPEG video, etc. etc.). Currently the end-user has no > > choice but to > > supply the device nodes manually. > > > [Hiremath, Vaibhav] I am still confused here, Can we take one common use > case, for example say video board has one /de/fb0 and /dev/video0 along with > that we have one node for media controller /dev/v4l/mc0 > > How are we interacting or talking to /dev/fb0 through media controller node? > > I looked into your presentation you created for LPC I guess, but still I am > not clear on this. The media controller will just tell the application that there is a framebuffer device and where that node can be found in /dev. In addition, it will show how it is connected to some sub-device and possibly you can dynamically connect it to another sub-device instead. To access the actual framebuffer you still need to go to fbX. That will never change. The media controller provides the high-level control you need to hook an OSD up to different outputs for example. This also means that the v4l driver should have knowledge of (and probably implement) the OSD. See also the RFC thread with Murali. > >
How to capture the whole TS
Hi All. I have a DVB-C PCI card (Technotrend Premium C-2300). Now I am trying to write an application that will capture TS and write it to disk for future analysis. The problem is that Linux DVB API demands the usage of PID filter (DMX_SET_FILTER or DMX_SET_PES_FILTER in ioctl call), and I need to capture the whole TS, packet by packet, exactly in the order they come. I tried to use PID 0x2000 as a PID to be filtered, but have an EINVAL. I saw some posts in the Internet where people were complaining about some DVB cards that cannot give the ability to capture TS without filtering explicitly specified PIDs, and I want to know: am I able to use Technotrend Premium C-2300 card to capture the whole TS, and if yes then how to do this. Maybe I have to load dvb_ttpci module with some specific parameter set to enable the feature that I need? Just in case, here is the parameter list of this driver module: parm: ir_protocol:Infrared protocol: 0 RC5, 1 RCMM (default) (array of int) parm: ir_inversion:Inversion of infrared signal: 0 not inverted (default), 1 inverted (array of int) parm: ir_device_mask:Bitmask of infrared devices: bit 0..31 = device 0..31 (default: all) (array of uint) parm: debug:debug level (bitmask, default 0) (int) parm: vidmode:analog video out: 0 off, 1 CVBS+RGB (default), 2 CVBS+YC, 3 YC (int) parm: pids_off:clear video/audio/PCR PID filters when demux is closed (int) parm: adac:audio DAC type: 0 TI, 1 CRYSTAL, 2 MSP (use if autodetection fails) (int) parm: hw_sections:0 use software section filter, 1 use hardware (int) parm: rgb_on:For Siemens DVB-C cards only: Enable RGB control signal on SCART pin 16 to switch SCART video mode from CVBS to RGB (int) parm: volume:initial volume: default 255 (range 0-255) (int) parm: budgetpatch:use budget-patch hardware modification: default 0 (0 no, 1 autodetect, 2 always) (int) parm: full_ts:enable code for full-ts hardware modification: 0 disable (default), 1 enable (int) parm: wss_cfg_4_3:WSS 4:3 - default 0x4008 - bit 15: disable, 14: burst mode, 13..0: wss data (int) parm: wss_cfg_16_9:WSS 16:9 - default 0x0007 - bit 15: disable, 14: burst mode, 13..0: wss data (int) parm: tv_standard:TV standard: 0 PAL (default), 1 NTSC (int) parm: adapter_nr:DVB adapter numbers (array of short) I have already used these parameters (in combination and apart) but have no result: full_ts=1, budgetpatch=2, hw_sections=0. I am not sure what exactly they mean. $ uname -r 2.6.27-std-def-alt16 (ALT Linux, if it does matter) Thanks in advance. Sergey Kudriavtsev. -- 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: RFCv2: Media controller proposal
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Hans Verkuil > Sent: Friday, September 11, 2009 11:51 AM > To: Karicheri, Muralidharan > Cc: Patrick Boettcher; Linux Media Mailing List > Subject: Re: RFCv2: Media controller proposal > > On Friday 11 September 2009 01:08:30 Karicheri, Muralidharan wrote: > > > > Hans, > > > > Thanks for your reply.. > > >> > > >> > > > > Right. That case (2 above) is easily taken care by v4l2 device > driver. We used FBDev driver to drive OSD Layer because that way > VPBE can be used by user space applications like x-windows? What is > the alternative for this? > > Is there a example v4l2 device using OSD like hardware and running > x-windows or other traditional graphics application? I am not aware > of any and the solution seems to be the right one here. > > > > So the solution we used (case 3)involves FBDev to drive the OSD > layers and V4L2 to drive the video layer. > > As usual, ivtv is doing all that. The ivtv driver is the main > controller of > the hardware. The ivtvfb driver provides the FB API towards the OSD. > The > X driver for the OSD is available here: > > http://dl.ivtvdriver.org/xf86-video-ivtv/archive/1.0.x/xf86-video- > ivtv-1.0.2.tar.gz > > This is the way to handle it. > > > > > > > > >This is very similar to the ivtv and ivtvfb drivers: if the > framebuffer is > > >in > > >use, then you cannot change the output standard (you'll get an > EBUSY error) > > >through a video device node. > > > > > > > Does the ivtvfb and ivtv works with the same set of v4l2 sub > devices for output? In our case, VPBE can work with any sub device > that can accept a BT.656/BT1120/RGB bus interface. So the FBDev > device and V4L2 device( either as standalone device or as co- > existent device) should work with the same set of sub devices. So > the question is, how both these bridge device can work on the same > sub device? If both can work with the same sub device, then what you > say is true and can be handled. That is the reason we used the > sysfs/Encoder manager as explained in my earlier email. > > Look at ivtvfb.c (it's in media/video/ivtv). The ivtvfb_init > function will just [Hiremath, Vaibhav] I think our mail crossed each other. Interesting, and is something new for me. Let me understand the implementation here first then I can provide some comments on this. Thanks, Vaibhav > find any ivtv driver instances and register itself with them. Most > of the > hard work is actually done by ivtv and ivtvfb is just the front-end > that > implements the FB API. The video and OSD hardware is usually if not > always > so intertwined that it should be controlled by one driver, not two. > > This way ivtv keeps full control over the sub-devices as well and > all output > changes will go to the same encoder, regardless of whether they > originated > from the fb or a video device node. > > > > > >That's exactly what you would expect. If the framebuffer isn't > used, then > > >you > > >can just use the normal V4L2 API to change the output standard. > > > > > >In practice, I think that you can only change the resolution in > the FB API. > > >Not things like the framerate, let alone precise pixelclock, > porch and sync > > >widths. > > > > > > There are 3 use cases > > > > 1) Pure FBDev device driving graphics to VPBE OSD layers -> sub > devices -> Display (LCD/TV) > > > > This would require FBDev loading a required v4l2 the sub > device (Not sure if FBDev community like this approach) and using it > to drive the output. We will not be able to change the output. But > output resolutions and timing can be controlled through fbset > command which allow you to change pixel clock, porch, sync etc. > > Bad idea. The fb API and framework is not really able to deal with > the > complexity of combined video and OSD devices. The v4l2 framework can > (esp. > when we have a media controller). > > > 2)Pure V4L2 device driving video to VPBE video layers -> sub > devices > > ->Display (LCD/TV) > > - No issues here > > > > 3)v4l2 and FBDev nodes co-exists. V4l2 drives video and FBDev > drives OSD layers and the combined out ->VPBE ->sub devices -> > Display (LCD/TV) > > - Not sure which bridge device should load up and manage the > sub devices. If V4l2 manages the sub devices, how FBDev driver can > set the timings in the current sub device since it has no knowledge > of the v4l2 device and the sub device it owns/manages. > > You should not attempt to artificially separate the two. You can't > since both > v4l and fb share the same hardware. You need one v4l driver that > will take > care of both and the FB driver just delegates the core OSD low-level > work to > the v4l driver. > > > > > > > > >Much better to let the two cooperate: you can use both APIs, but > you can't > > >change the resolution in the fb if streaming is going on, and you > can't > > >change the output standard of a vide
RE: RFCv2: Media controller proposal
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Hans Verkuil > Sent: Friday, September 11, 2009 1:57 AM > To: Karicheri, Muralidharan > Cc: Patrick Boettcher; Linux Media Mailing List > Subject: Re: RFCv2: Media controller proposal > > On Thursday 10 September 2009 21:19:25 Karicheri, Muralidharan > wrote: > > Hans, > > > > I haven't gone through the RFC, but thought will respond to the > below comment. > > > > Murali Karicheri > > Software Design Engineer > > Texas Instruments Inc. > > Germantown, MD 20874 > > new phone: 301-407-9583 > > Old Phone : 301-515-3736 (will be deprecated) > > email: m-kariche...@ti.com > > > > >>> > > >>> I may be mistaken, but I don't believe soundcards have this > same > > >>> complexity are media board. > > >> > > >> When I launch alsa-mixer I see 4 input devices where I can > select 4 > > >> difference sources. This gives 16 combinations which is enough > for me to > > >> call it 'complex' . > > >> > > Could entities not be completely addressed (configuration > ioctls) > > through > > the mc-node? > > >>> > > >>> Not sure what you mean. > > >> > > >> Instead of having a device node for each entity, the ioctls for > each > > >> entities are done on the media controller-node address an > entity by ID. > > > > > >I definitely don't want to go there. Use device nodes (video, fb, > alsa, > > >dvb, etc) for streaming the actual media as we always did and use > the > > >media controller for controlling the board. It keeps everything > nicely > > >separate and clean. > > > > > > > > > What you mean by controlling the board? > > In general: the media controller can do anything except streaming. > However, > that is an extreme position and in practice all the usual ioctls > should > remain supported by the video device nodes. > > > We have currently ported DMxxx VPBE display drivers to 2.6.31 (Not > submitted yet to mainline). In our current implementation, the > output and standard/mode are controlled through sysfs because it is > a common functionality affecting both v4l and FBDev framebuffer > devices. Traditional applications such x-windows should be able to > stream video/graphics to VPBE output. V4l2 applications should be > able to stream video. Both these devices needs to know the display > parameters such as frame buffer resolution, field etc that are to be > configured in the video or osd layers in VPBE to output frames to > the encoder that is driving the output. So to stream, first the > output and mode/standard are selected using sysfs command and then > the application is started. Following scenarios are supported by > VPBE display drivers in our internal release:- > > > > 1)Traditional FBDev applications (x-window) can be run using OSD > device. Allows changing mode/standards at the output using fbset > command. > > > > 2)v4l2 driver doesn't provide s_output/s_std support since it is > done through sysfs. > > > > 3)Applications that requires to stream both graphics and video to > the output uses both FBDev and V4l2 devices. So these application > first set the output and mode/standard using sysfs, before doing io > operations with these devices. > > I don't understand this approach. I'm no expert on the fb API but as > far as I > know the V4L2 API allows a lot more precision over the video timings > (esp. with > the new API you are working on). Furthermore, I assume it is > possible to use > the DMxxx without an OSD, right? > > This is very similar to the ivtv and ivtvfb drivers: if the > framebuffer is in > use, then you cannot change the output standard (you'll get an EBUSY > error) > through a video device node. > [Hiremath, Vaibhav] Framebuffer always be in use till the point you don't call FBIO_BLANK ioctl. > That's exactly what you would expect. If the framebuffer isn't used, > then you > can just use the normal V4L2 API to change the output standard. > > In practice, I think that you can only change the resolution in the > FB API. > Not things like the framerate, let alone precise pixelclock, porch > and sync > widths. > > Much better to let the two cooperate: you can use both APIs, but you > can't > change the resolution in the fb if streaming is going on, and you > can't > change the output standard of a video device node if that changes > the > resolution while the framebuffer is in used. > [Hiremath, Vaibhav] To overcome this we brought in or rely on SYSFS interface, same is applicable to OMAP devices. We are using SYSFS interface for all common features like Standard/output selection, etc... I believe media controller will play some role here. Thanks, Vaibhav > No need for additional sysfs entries. > > > > > There is an encoder manager to which all available encoders > registers (using internally developed interface) and based on > commands received at Fbdev/sysfs interfaces, the current encoder is > selected by the encoder manager and curren
Re: RFCv2: Media controller proposal
On Friday 11 September 2009 01:08:30 Karicheri, Muralidharan wrote: > > Hans, > > Thanks for your reply.. > >> > >> > >> What you mean by controlling the board? > > > >In general: the media controller can do anything except streaming. However, > >that is an extreme position and in practice all the usual ioctls should > >remain supported by the video device nodes. > > > >> We have currently ported DMxxx VPBE display drivers to 2.6.31 (Not > >submitted yet to mainline). In our current implementation, the output and > >standard/mode are controlled through sysfs because it is a common > >functionality affecting both v4l and FBDev framebuffer devices. Traditional > >applications such x-windows should be able to stream video/graphics to VPBE > >output. V4l2 applications should be able to stream video. Both these > >devices needs to know the display parameters such as frame buffer > >resolution, field etc that are to be configured in the video or osd layers > >in VPBE to output frames to the encoder that is driving the output. So to > >stream, first the output and mode/standard are selected using sysfs command > >and then the application is started. Following scenarios are supported by > >VPBE display drivers in our internal release:- > >> > >> 1)Traditional FBDev applications (x-window) can be run using OSD device. > >Allows changing mode/standards at the output using fbset command. > >> > >> 2)v4l2 driver doesn't provide s_output/s_std support since it is done > >through sysfs. > >> > >> 3)Applications that requires to stream both graphics and video to the > >output uses both FBDev and V4l2 devices. So these application first set the > >output and mode/standard using sysfs, before doing io operations with these > >devices. > > > >I don't understand this approach. I'm no expert on the fb API but as far as > >I > >know the V4L2 API allows a lot more precision over the video timings (esp. > >with > >the new API you are working on). Furthermore, I assume it is possible to > >use > >the DMxxx without an OSD, right? > > > Right. That case (2 above) is easily taken care by v4l2 device driver. We > used FBDev driver to drive OSD Layer because that way VPBE can be used by > user space applications like x-windows? What is the alternative for this? > Is there a example v4l2 device using OSD like hardware and running x-windows > or other traditional graphics application? I am not aware of any and the > solution seems to be the right one here. > > So the solution we used (case 3)involves FBDev to drive the OSD layers and > V4L2 to drive the video layer. As usual, ivtv is doing all that. The ivtv driver is the main controller of the hardware. The ivtvfb driver provides the FB API towards the OSD. The X driver for the OSD is available here: http://dl.ivtvdriver.org/xf86-video-ivtv/archive/1.0.x/xf86-video-ivtv-1.0.2.tar.gz This is the way to handle it. > > > > >This is very similar to the ivtv and ivtvfb drivers: if the framebuffer is > >in > >use, then you cannot change the output standard (you'll get an EBUSY error) > >through a video device node. > > > > Does the ivtvfb and ivtv works with the same set of v4l2 sub devices for > output? In our case, VPBE can work with any sub device that can accept a > BT.656/BT1120/RGB bus interface. So the FBDev device and V4L2 device( either > as standalone device or as co-existent device) should work with the same set > of sub devices. So the question is, how both these bridge device can work on > the same sub device? If both can work with the same sub device, then what you > say is true and can be handled. That is the reason we used the sysfs/Encoder > manager as explained in my earlier email. Look at ivtvfb.c (it's in media/video/ivtv). The ivtvfb_init function will just find any ivtv driver instances and register itself with them. Most of the hard work is actually done by ivtv and ivtvfb is just the front-end that implements the FB API. The video and OSD hardware is usually if not always so intertwined that it should be controlled by one driver, not two. This way ivtv keeps full control over the sub-devices as well and all output changes will go to the same encoder, regardless of whether they originated from the fb or a video device node. > > >That's exactly what you would expect. If the framebuffer isn't used, then > >you > >can just use the normal V4L2 API to change the output standard. > > > >In practice, I think that you can only change the resolution in the FB API. > >Not things like the framerate, let alone precise pixelclock, porch and sync > >widths. > > > There are 3 use cases > > 1) Pure FBDev device driving graphics to VPBE OSD layers -> sub devices -> > Display (LCD/TV) > > This would require FBDev loading a required v4l2 the sub device (Not > sure if FBDev community like this approach) and using it to drive the output. > We will not be able to change the output. But output resolutions and timing > can be controlled through fbset
RE: RFCv2: Media controller proposal
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Hans Verkuil > Sent: Thursday, September 10, 2009 12:43 PM > To: linux-media@vger.kernel.org > Subject: RFCv2: Media controller proposal > > Hi all, > > Here is the new Media Controller RFC. It is completely rewritten > from the > original RFC. This original RFC can be found here: > > http://www.archivum.info/video4linux-list%40redhat.com/2008- > 07/00371/RFC:_Add_support_to_query_and_change_connections_inside_a_m > edia_device > [Hiremath, Vaibhav] I could see implementation has changed/evolved a lot here from last RFC. I added some quick comments below, try to provide more during weekend. > This document will be the basis of the discussions during the > Plumbers > Conference in two weeks time. > > Open issue #3 is the main unresolved item, but I hope to come up > with something > during the weekend. > > Regards, > > Hans > > > RFC: Media controller proposal > > Version 2.0 > > Background > == > > This RFC is a new version of the original RFC that was written in > cooperation > with and on behalf of Texas Instruments about a year ago. > > Much work has been done in the past year to put the foundation in > place to > be able to implement a media controller and now it is time for this > updated > version. The intention is to discuss this in more detail during this > years > Plumbers Conference. > > Although the high-level concepts are the same as in the original > RFC, many > of the details have changed based on what was learned over the past > year. > > This RFC is based on the original discussions with Manjunath Hadli > from TI > last year, on discussions during a recent meeting between Laurent > Pinchart, > Guennadi Liakhovetski and myself, and on recent discussions with > Nokia. > Thanks to Sakari Ailus for doing an initial review of this RFC. > > One note regarding terminology: a 'board' is the name I use for the > SoC, > PCI or USB device that contains the video hardware. Each board has > its own > driver instance and its own v4l2_device struct. Originally I called > it > 'device', but that name is already used in too many places. > > > What is a media controller? > === > > In a nutshell: a media controller is a new v4l device node that can > be used > to discover and modify the topology of the board and to give access > to the > low-level nodes (such as previewers, resizers, color space > converters, etc.) > that are part of the topology. > > It does not do any streaming, that is the exclusive domain of video > nodes. > It is meant purely for controlling a board as a whole. > > > Why do we need one? > === > > There are currently several problems that are impossible to solve > within the > current V4L2 API: > > 1) Discovering the various device nodes that are typically created > by a video > board, such as: video nodes, vbi nodes, dvb nodes, alsa nodes, > framebuffer > nodes, input nodes (for e.g. webcam button events or IR remotes). > > It would be very handy if an application can just open an > /dev/v4l/mc0 node > and be able to figure out where all the nodes are, and to be able to > figure > out what the capabilities of the board are (e.g. does it support > DVB, is the > audio going through a loopback cable or is there an alsa device, can > it do > compressed MPEG video, etc. etc.). Currently the end-user has no > choice but to > supply the device nodes manually. > [Hiremath, Vaibhav] I am still confused here, Can we take one common use case, for example say video board has one /de/fb0 and /dev/video0 along with that we have one node for media controller /dev/v4l/mc0 How are we interacting or talking to /dev/fb0 through media controller node? I looked into your presentation you created for LPC I guess, but still I am not clear on this. > 2) Some of the newer SoC devices can connect or disconnect internal > components > dynamically. As an example, the omap3 can either connect a sensor > output to a > CCDC module to a previewer module to a resizer module and finally to > a capture > device node. But it is also possible to capture the sensor output > directly > after the CCDC module. The previewer can get its input from another > video > device node and output either to the resizer or to another video > capture > device node. The same is true for the resizer, that too can get its > input from > a device node. > > So there are lots of connections here that can be modified at will > depending > on what the application wants. And in real life there are even more > links than > I mentioned here. And it will only get more complicated in the > future. > > All this requires that there has to be a way to connect and > disconnect parts > of the internal topology of a video board at will. > > 3) There is increasing demand to be able to control e.g. sensors or > video > encoders/decoders at a much more precise manner. Cur
Re: Azurewave AD-CP400 (Twinhan VP-2040 DVB-C)
Magnus Nilsson wrote: MartinG wrote: On Wed, Aug 26, 2009 at 6:21 PM, Magnus Nilsson wrote: Nevermind this for the time being...all is pointing to open-sasc-ng being the culprit here... Just to add a datapoint - I have the same problem: I can't seem to successfully scan for channels. I've taken open-sasc-ng out of the equation by simply not loading the loopback device and scan directly on the true frontend. These are my bits: Terratec Cinergy C HD PCI kernel 2.6.29.6-217.2.16.fc11.x86_64 s2-liplianin from http://mercurial.intuxication.org/hg/s2-liplianin Currently: changeset: 12465:096aa4559b71 tag: tip user:Igor M. Liplianin date:Sat Sep 05 20:26:33 2009 +0300 dmesg when "modprobe mantis" Sep 6 22:33:52 localhost kernel: Mantis :04:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Sep 6 22:33:52 localhost kernel: irq: 16, latency: 64 Sep 6 22:33:52 localhost kernel: memory: 0xfdfff000, mmio: 0xc20023906000 Sep 6 22:33:52 localhost kernel: found a VP-2040 PCI DVB-C device on (04:00.0), Sep 6 22:33:52 localhost kernel:Mantis Rev 1 [153b:1178], irq: 16, latency: 64 Sep 6 22:33:52 localhost kernel:memory: 0xfdfff000, mmio: 0xc20023906000 Sep 6 22:33:52 localhost kernel:MAC Address=[00:08:ca:1d:bd:a6] Sep 6 22:33:52 localhost kernel: mantis_alloc_buffers (0): DMA=0xcc0d cpu=0x8800cc0d size=65536 Sep 6 22:33:52 localhost kernel: mantis_alloc_buffers (0): RISC=0xa85ce000 cpu=0x8800a85ce000 size=1000 Sep 6 22:33:52 localhost kernel: DVB: registering new adapter (Mantis dvb adapter) Sep 6 22:33:52 localhost kernel: mantis_frontend_init (0): Probing for CU1216 (DVB-C) Sep 6 22:33:52 localhost kernel: TDA10023: i2c-addr = 0x0c, id = 0x7d Sep 6 22:33:52 localhost kernel: mantis_frontend_init (0): found Philips CU1216 DVB-C frontend (TDA10023) @ 0x0c Sep 6 22:33:52 localhost kernel: mantis_frontend_init (0): Mantis DVB-C Philips CU1216 frontend attach success Sep 6 22:33:52 localhost kernel: DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... Sep 6 22:33:52 localhost kernel: mantis_ca_init (0): Registering EN50221 device Sep 6 22:33:52 localhost kernel: mantis_ca_init (0): Registered EN50221 device Sep 6 22:33:52 localhost kernel: mantis_hif_init (0): Adapter(0) Initializing Mantis Host Interface Sep 6 22:33:52 localhost kernel: input: Mantis VP-2040 IR Receiver as /devices/virtual/input/input11 Sep 6 22:33:53 localhost kernel: Mantis VP-2040 IR Receiver: unknown key: key=0x00 raw=0x00 down=1 Sep 6 22:33:53 localhost kernel: Mantis VP-2040 IR Receiver: unknown key: key=0x00 raw=0x00 down=0 lspci -v 04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01) Subsystem: TERRATEC Electronic GmbH Device 1178 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at fdfff000 (32-bit, prefetchable) [size=4K] Kernel driver in use: Mantis Kernel modules: mantis I have also tried the mantis module from v4l-dvb without success. The card is then recognized as TDA10021 instead of TDA10023, just as you describe. Typically, I have to do "modprobe -r mantis;modprobe mantis" right before I try to scan (with w_scan, scandvb og mythtv) in order to get any channels at all. But the joy doesn't last for long, and I get stuff like kernel: mantis_ack_wait (0): Slave RACK Fail ! in /var/log/messages. I guess the problems mentioned in the following post are related: Subject: Terratec Cinergy C HD tuning problems Date: 2009-08-19 21:10:56 GMT Hope we can find a solution to this! best, MartinG I actually found what my problem was. It seems that open-sasc-ng has a weird bug, which means you can't tell it to log to a logfile by using the --log argument. If I remove the '--log /var/log/open-sasc-ng.log' argument and instead lets it log directly to syslog, it works fine. I'm using syslog-ng, so it's not a problem directing all open-sasc-ng log traffic to a specific logfile anyway. //Magnus -- 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 Hi, I have the same problem with Slave RACK Fail on my Azurewave AP-SP400 (VP-1041). Do you really mean that to don't get theese problems when turning off the log from open-sasc-ng or was the problem on open-sasc-ng? I have turned off the log completely for a long time since it was problems in open-sasc-ng but I still have problems with Slave RACK Fail. I'm using the same drivers with Ubuntu server x86_64 2.6.28-13-generic kernel. Have you done anything else to work properly, like patching open-sasc-ng or the driver? From my experience it really starts to fail when using MythTV, otherwise I can tune channels for several days straight without any problems. But when doing a complete channels scan it can make the driver fail so I would not
[PULL] http://kernellabs.com/hg/~dheitmueller/em28xx-vbi3
Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/em28xx-vbi3 for the following em28xx: better describe vinctrl registers em28xx: make video isoc stream work when VBI is enabled em28xx: add raw VBI support for NTSC em28xx: fix mmap_mapper with vbi em28xx: restructure fh/dev locking to handle both video and vbi em28xx: remove unreferenced variable em28xx: do not create /dev/vbiX device if VBI not supported em28xx: only advertise VBI capability if supported em28xx: implement g_std v4l call em28xx: remove unneeded code that set VINCTRL register em28xx: fix unused variable warning Note: the support currently only works for NTSC. I will be getting PAL support working in the next couple of weeks as I get an environment setup for testing. Special thanks go out to EyeMagnet Limited for sponsoring this work. Thanks, 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
RE: v4l2 driver seems to be capturing frames too slow!
Hi Guilherme, (I'm removing the old mailing list and add CC the current one) -Original Message- From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-boun...@redhat.com] On Behalf Of Guilherme Raymo Longo Sent: Friday, September 11, 2009 10:17 AM To: video4linux-l...@redhat.com Subject: v4l2 driver seems to be capturing frames too slow! Hi mates. Plz, could I get some help from here. This is my first attempt of creating a v4l2 app and I am a bit confused about few things even after reading the WIKI. 1 - I am using mmap to map the memory in the device. In the example I have, there is only 1 QBUF and 1 DQBUF, so I presume that all the 4 buffers are been queued and dequeued when those functions are called. Am I committing a mistake here or that is correct? Here you can see the code: http://pastebin.com/m367448b8 Yes, I suppose you are getting right. 2 - If you notice, right after the buffers been dequeued the program calls a function "process_image (buffers[buf.index].start);" that I also presume been all the 4 buffers "buffer[start] to buffer[3]". Each buffer is 8byte long so I have 64bits of memory mapped. The compression I am using is RGB32 that stores each RGBA pixels in 4 bytes (1 for each color + 1 for alpha): If this is true and I am capturing a image 640x480 I am gonna have 307.200 pixel and a necessary space of 1.228.8 bytes to store each frame. What means approximately 1.23MB per frame. Is that correct or I am calculating it improperly Correct, and you can get the actual data size value from bytesused in v4l2_buffer on DQBUF. 3 - And the last question is, that function I mentioned earlier process_image (buffers[buf.index].start) prints approximately 6 dots per second wich means (taking in account that each buffer has 8bytes and I have them all filled with data) 6 x 8bytes read to process the image. Not even close to be a complete frame. the full program can be seen here: http://pastebin.com/m43801a5e I recognize that code. Similar thing can be found in v4l2 spec document. But I prefer to use memcpy() the image data to frame buffer rather than printing every single pixel at a time. Try to figure out to copy the whole single image frame to the frame buffer. It should be faster. You can copy exact amount of data based on bytesused value :) Cheers, Nate = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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 with Pinnacle 310i (saa7134) and recent kernels
Hi Avl, Am Donnerstag, den 10.09.2009, 21:51 + schrieb Avl Jawrowski: > hermann pitton arcor.de> writes: > > > If it seems to deliver stable results now, you can even try to re-flash > > it with rewrite_eeprom.pl in v4l2-apps/util. Read the instructions on > > top of it. > > With 2.6.30 it's stable. I've reflashed the eeprom and now the card is > autodetected: because of other obligations I do only follow loosely what happens on the list. Don't expect me at latest. > saa7130/34: v4l2 driver version 0.2.15 loaded > saa7133[0]: found at :01:02.0, rev: 209, irq: 22, latency: 32, mmio: > 0xcfddf800 > saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i > [card=101,autodetected] > saa7133[0]: board init: gpio is 600e000 > IRQ 22/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs > saa7133[0]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 > saa7133[0]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2e 15 13 ff ff > saa7133[0]: i2c eeprom 20: 01 2c 01 23 23 01 04 30 98 ff 00 e7 ff 21 00 c2 > saa7133[0]: i2c eeprom 30: 96 10 03 32 15 20 ff 15 0e 6c a3 eb 03 c5 e8 9d > saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > i2c-adapter i2c-0: Invalid 7-bit address 0x7a > tuner 0-004b: chip found @ 0x96 (saa7133[0]) > tda829x 0-004b: setting tuner address to 61 > tda829x 0-004b: type set to tda8290+75a > saa7133[0]: registered device video0 [v4l2] > saa7133[0]: registered device vbi0 > saa7133[0]: registered device radio0 > dvb_init() allocating 1 frontend > DVB: registering new adapter (saa7133[0]) > DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... > tda1004x: setting up plls for 48MHz sampling clock > tda1004x: found firmware revision 29 -- ok It is important to reflash it with your _original_ eeprom stuff on the long run, for now it does not matter. I see at least three different eeprom contents for now, might make a difference for LNA activation or for external voltage to an active antenna, also seven different remotes are listed, one marked as dysfunctional currently on the m$ driver ... > However it works still only with Kaffeine and w_scan. > dvbscan (last mercurial) give: Off hand I can't tell, but try with "scan". I did not use "dvbscan" since years and can't tell the status. > Unable to query frontend status > > And with 2.6.31 (same configuration) appears this new error: > > i2c-adapter i2c-0: Invalid 7-bit address 0x7a > > It can be a problem? No, it is only related to the first i2c remote on the Upmost Purple TV. It is unlikely that anybody is on the list with such a card currently. Likely it means we should shift it >> 1. 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: RFCv2: Media controller proposal
Hans, Thanks for your reply.. >> >> >> What you mean by controlling the board? > >In general: the media controller can do anything except streaming. However, >that is an extreme position and in practice all the usual ioctls should >remain supported by the video device nodes. > >> We have currently ported DMxxx VPBE display drivers to 2.6.31 (Not >submitted yet to mainline). In our current implementation, the output and >standard/mode are controlled through sysfs because it is a common >functionality affecting both v4l and FBDev framebuffer devices. Traditional >applications such x-windows should be able to stream video/graphics to VPBE >output. V4l2 applications should be able to stream video. Both these >devices needs to know the display parameters such as frame buffer >resolution, field etc that are to be configured in the video or osd layers >in VPBE to output frames to the encoder that is driving the output. So to >stream, first the output and mode/standard are selected using sysfs command >and then the application is started. Following scenarios are supported by >VPBE display drivers in our internal release:- >> >> 1)Traditional FBDev applications (x-window) can be run using OSD device. >Allows changing mode/standards at the output using fbset command. >> >> 2)v4l2 driver doesn't provide s_output/s_std support since it is done >through sysfs. >> >> 3)Applications that requires to stream both graphics and video to the >output uses both FBDev and V4l2 devices. So these application first set the >output and mode/standard using sysfs, before doing io operations with these >devices. > >I don't understand this approach. I'm no expert on the fb API but as far as >I >know the V4L2 API allows a lot more precision over the video timings (esp. >with >the new API you are working on). Furthermore, I assume it is possible to >use >the DMxxx without an OSD, right? Right. That case (2 above) is easily taken care by v4l2 device driver. We used FBDev driver to drive OSD Layer because that way VPBE can be used by user space applications like x-windows? What is the alternative for this? Is there a example v4l2 device using OSD like hardware and running x-windows or other traditional graphics application? I am not aware of any and the solution seems to be the right one here. So the solution we used (case 3)involves FBDev to drive the OSD layers and V4L2 to drive the video layer. > >This is very similar to the ivtv and ivtvfb drivers: if the framebuffer is >in >use, then you cannot change the output standard (you'll get an EBUSY error) >through a video device node. > Does the ivtvfb and ivtv works with the same set of v4l2 sub devices for output? In our case, VPBE can work with any sub device that can accept a BT.656/BT1120/RGB bus interface. So the FBDev device and V4L2 device( either as standalone device or as co-existent device) should work with the same set of sub devices. So the question is, how both these bridge device can work on the same sub device? If both can work with the same sub device, then what you say is true and can be handled. That is the reason we used the sysfs/Encoder manager as explained in my earlier email. >That's exactly what you would expect. If the framebuffer isn't used, then >you >can just use the normal V4L2 API to change the output standard. > >In practice, I think that you can only change the resolution in the FB API. >Not things like the framerate, let alone precise pixelclock, porch and sync >widths. There are 3 use cases 1) Pure FBDev device driving graphics to VPBE OSD layers -> sub devices -> Display (LCD/TV) This would require FBDev loading a required v4l2 the sub device (Not sure if FBDev community like this approach) and using it to drive the output. We will not be able to change the output. But output resolutions and timing can be controlled through fbset command which allow you to change pixel clock, porch, sync etc. 2)Pure V4L2 device driving video to VPBE video layers -> sub devices ->Display (LCD/TV) - No issues here 3)v4l2 and FBDev nodes co-exists. V4l2 drives video and FBDev drives OSD layers and the combined out ->VPBE ->sub devices -> Display (LCD/TV) - Not sure which bridge device should load up and manage the sub devices. If V4l2 manages the sub devices, how FBDev driver can set the timings in the current sub device since it has no knowledge of the v4l2 device and the sub device it owns/manages. > >Much better to let the two cooperate: you can use both APIs, but you can't >change the resolution in the fb if streaming is going on, and you can't >change the output standard of a video device node if that changes the >resolution while the framebuffer is in used. That is what I mean by use case 3). We can live with the restriction. But sub device model currently is v4l2 specific and I am not sure if there is a way same sub device can be accessed by both bridge devices. Any help here is appreciated. > >No
Re: RFCv2: Media controller proposal
On Thursday 10 September 2009 23:28:40 Guennadi Liakhovetski wrote: > Hi Hans > > a couple of comments / questions from the first glance > > On Thu, 10 Sep 2009, Hans Verkuil wrote: > > [snip] > > > Topology > > > > > > The topology is represented by entities. Each entity has 0 or more inputs > > and > > 0 or more outputs. Each input or output can be linked to 0 or more possible > > outputs or inputs from other entities. This is either mutually exclusive > > (i.e. an input/output can be connected to only one output/input at a time) > > or it can be connected to multiple inputs/outputs at the same time. > > > > A device node is a special kind of entity with just one input (capture node) > > or output (video node). It may have both if it does some in-place operation. > > > > Each entity has a unique numerical ID (unique for the board). Each input or > > output has a unique numerical ID as well, but that ID is only unique to the > > entity. To specify a particular input or output of an entity one would give > > an tuple. > > > > When enumerating over entities you will need to retrieve at least the > > following information: > > > > - type (subdev or device node) > > - entity ID > > - entity description (can be quite long) > > - subtype (what sort of device node or subdev is it?) > > - capabilities (what can the entity do? Specific to the subtype and more > > precise than the v4l2_capability struct which only deals with the board > > capabilities) > > - addition subtype-specific data (union) > > - number of inputs and outputs. The input IDs should probably just be a > > value > > of 0 - (#inputs - 1) (ditto for output IDs). > > > > Another ioctl is needed to obtain the list of possible links that can be > > made > > for each input and output. > > Shall we not just let the user try? and return an error if the requested > connection is impossible? Remember, media-controller users are > board-tailored, so, they will not be very dynamic. True, but it will be sooo nice to make a GUI that will visualize all these connections and allow the developer to change then dynamically. And I expect this to be nothing more than simple static const arrays. What I didn't mention in the RFC, but probably should, is that my intention is that the driver will just pass some data structure to the v4l core with all these connections, and that the core will handle all the enumerations etc. Only making or breaking links will involve a call to the driver (probably through v4l2_device). > > It is good to realize that most applications will just enumerate e.g. > > capture > > device nodes. Few applications will do a full scan of the whole topology. > > Instead they will just specify the unique entity ID and if needed the > > input/output ID as well. These IDs are declared in the board or sub-device > > specific header. > > > > A full enumeration will typically only be done by some sort of generic > > application like v4l2-ctl. > > Well, is this the reason why you wanted to enumerate possible connections? > Should v4l2-ctrl be able to manipulate those connections? What is it for > actually? Yes, v4l2-ctl should be able to change connections. > > In addition, most entities will have only one or two inputs/outputs at most. > > So we might optimize the data structures for this. We probably will have to > > see how it goes when we implement it. > > > > We obviously need ioctls to make and break links between entities. It > > shouldn't be hard to do this. > > > > Access to sub-devices > > - > > > > What is a bit trickier is how to select a sub-device as the target for > > ioctls. > > Normally ioctls like S_CTRL are sent to a /dev/v4l/videoX node and the > > driver > > will figure out which sub-device (or possibly the bridge itself) will > > receive > > it. There is no way of hijacking this mechanism to e.g. specify a specific > > entity ID without also having to modify most of the v4l2 structs by adding > > such an ID field. But with the media controller we can at least create an > > ioctl that specifies a 'target entity' that will receive any non-media > > controller ioctl. Note that for now we only support sub-devices as the > > target > > entity. > > > > The idea is this: > > > > // Select a particular target entity > > ioctl(mc, VIDIOC_S_SUBDEV, &entityID); > > // Send S_FMT directly to that entity > > ioctl(mc, VIDIOC_S_FMT, &fmt); > > is this really a "mc" fd or the respective video-devive fd? It's a filehandle to the media controller. I've added an explicit open() to make this clear. > > // Send a custom ioctl to that entity > > ioctl(mc, VIDIOC_OMAP3_G_HISTOGRAM, &hist); > > > > This requires no API changes and is very easy to implement. One problem is > > that this is not thread-safe. We can either supply some sort of locking > > mechanism, or just tell the application programmer to do the locking in the > > application. I'm not sure what is the correct approach here
Re: Problems with Pinnacle 310i (saa7134) and recent kernels
hermann pitton arcor.de> writes: > If it seems to deliver stable results now, you can even try to re-flash > it with rewrite_eeprom.pl in v4l2-apps/util. Read the instructions on > top of it. With 2.6.30 it's stable. I've reflashed the eeprom and now the card is autodetected: saa7130/34: v4l2 driver version 0.2.15 loaded saa7133[0]: found at :01:02.0, rev: 209, irq: 22, latency: 32, mmio: 0xcfddf800 saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected] saa7133[0]: board init: gpio is 600e000 IRQ 22/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2e 15 13 ff ff saa7133[0]: i2c eeprom 20: 01 2c 01 23 23 01 04 30 98 ff 00 e7 ff 21 00 c2 saa7133[0]: i2c eeprom 30: 96 10 03 32 15 20 ff 15 0e 6c a3 eb 03 c5 e8 9d saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff i2c-adapter i2c-0: Invalid 7-bit address 0x7a tuner 0-004b: chip found @ 0x96 (saa7133[0]) tda829x 0-004b: setting tuner address to 61 tda829x 0-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[0]) DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: found firmware revision 29 -- ok However it works still only with Kaffeine and w_scan. dvbscan (last mercurial) give: Unable to query frontend status And with 2.6.31 (same configuration) appears this new error: i2c-adapter i2c-0: Invalid 7-bit address 0x7a It can be a problem? > Cheers, > Hermann Thank you! -- 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: RFCv2: Media controller proposal
On Thursday 10 September 2009 22:20:13 Mauro Carvalho Chehab wrote:
> Hi Hans,
>
> Hi Hans,
>
> Em Thu, 10 Sep 2009 09:13:09 +0200
> Hans Verkuil escreveu:
>
> First of all, a generic comment: you enumerated on your RFC several needs that
> you expect to be solved with a media controller, but you didn't mention what
> userspace API will be used to solve it (e. g. what ioctls, sysfs interfaces,
> etc). As this is missing, I'm adding a few notes about how this can be
> implemented. For example, as I've already pointed when you sent the first
> proposal and at LPC, sysfs is the proper kernel API for enumerating things.
I hate sysfs with a passion. All of the V4L2 API is designed around ioctls,
and so is the media controller.
Note that I did not go into too much implementation detail in this RFC. The
best way to do that is by trying to implement it. Only after implementing it
for a few drivers will you get a real feel of what works and what doesn't.
Of course, whether to use sysfs or ioctls is something that has to be designed
beforehand.
>
> > Why do we need one?
> > ===
> >
> > There are currently several problems that are impossible to solve within the
> > current V4L2 API:
> >
> > 1) Discovering the various device nodes that are typically created by a
> > video
> > board, such as: video nodes, vbi nodes, dvb nodes, alsa nodes, framebuffer
> > nodes, input nodes (for e.g. webcam button events or IR remotes).
>
> In fact, this can already be done by using the sysfs interface. the current
> version of v4l2-sysfs-path.c already enumerates the associated nodes to
> a /dev/video device, by just navigating at the already existing device
> description nodes at sysfs. I hadn't tried yet, but I bet that a similar kind
> of topology can be obtained from a dvb device (probably, we need to do some
> adjustments).
sysfs is crap. It's a poorly documented public API that is hell to use. Take
a device node entity as enumerated by the media controller: I want to provide
the application with information like the sort of node (alsa, fb, v4l, etc),
how to access it (alsa card nr or major/minor), a description ("Captured MPEG
stream"), possibly some capabilities and addition data. With an ENUM ioctl
you can just call it. With sysfs you have to open/read/close files for each of
these properties, walk through the tree to find related alsa/v4l/fb devices,
and in drivers you must write a hell of a lot of code just to make those sysfs
nodes. It's an uncontrollable mess.
Basically you're just writing a lot of bloat for no reason. And even worse is
that this would introduce a completely different type of API compared to what
we already have.
> The big missing component is an userspace library that will properly return
> the
> device components to the applications. Maybe we need to do also some
> adjustments at the sysfs nodes to represent all that it is needed.
So we write a userspace library that collects all that information? So that
has to:
1) walk through the sysfs tree trying to find all the related parts of the
media board.
2) open the property that we are interested in.
3) attempt to read the property's value.
4) the driver will then copy that value into a buffer that is returned to the
application, usually through a sprintf() call.
5) the library than uses atol() to convert the string back to an integer and
stores the result in a struct.
6) repeat for all properties.
Isn't that the same as calling an enum ioctl() with a struct pointer? Except
a zillion times slower and more obfuscated?
There are certain areas where sysfs is suitable, but this isn't one of them.
>
> > It would be very handy if an application can just open an /dev/v4l/mc0 node
> > and be able to figure out where all the nodes are, and to be able to figure
> > out what the capabilities of the board are (e.g. does it support DVB, is the
> > audio going through a loopback cable or is there an alsa device, can it do
> > compressed MPEG video, etc. etc.). Currently the end-user has no choice but
> > to
> > supply the device nodes manually.
>
> The better would be to create a /sys/class/media node, and having the
> media controllers above that struct. So, mc0 will be at /sys/class/media/mc0.
Why? It's a device. Devices belong in /dev. That's where applications and users
look for devices. Not in sysfs. You should be able to use this even without
sysfs being mounted (on e.g. an embedded system). Another reason BTW not to use
sysfs, BTW.
>
> > 2) Some of the newer SoC devices can connect or disconnect internal
> > components
> > dynamically. As an example, the omap3 can either connect a sensor output to
> > a
> > CCDC module to a previewer module to a resizer module and finally to a
> > capture
> > device node. But it is also possible to capture the sensor output directly
> > after the CCDC module. The previewer can get its input from another video
> > device node and output either to the resizer or to another video capture
Re: RFCv2: Media controller proposal
Hi Hans a couple of comments / questions from the first glance On Thu, 10 Sep 2009, Hans Verkuil wrote: [snip] > Topology > > > The topology is represented by entities. Each entity has 0 or more inputs and > 0 or more outputs. Each input or output can be linked to 0 or more possible > outputs or inputs from other entities. This is either mutually exclusive > (i.e. an input/output can be connected to only one output/input at a time) > or it can be connected to multiple inputs/outputs at the same time. > > A device node is a special kind of entity with just one input (capture node) > or output (video node). It may have both if it does some in-place operation. > > Each entity has a unique numerical ID (unique for the board). Each input or > output has a unique numerical ID as well, but that ID is only unique to the > entity. To specify a particular input or output of an entity one would give > an tuple. > > When enumerating over entities you will need to retrieve at least the > following information: > > - type (subdev or device node) > - entity ID > - entity description (can be quite long) > - subtype (what sort of device node or subdev is it?) > - capabilities (what can the entity do? Specific to the subtype and more > precise than the v4l2_capability struct which only deals with the board > capabilities) > - addition subtype-specific data (union) > - number of inputs and outputs. The input IDs should probably just be a value > of 0 - (#inputs - 1) (ditto for output IDs). > > Another ioctl is needed to obtain the list of possible links that can be made > for each input and output. Shall we not just let the user try? and return an error if the requested connection is impossible? Remember, media-controller users are board-tailored, so, they will not be very dynamic. > It is good to realize that most applications will just enumerate e.g. capture > device nodes. Few applications will do a full scan of the whole topology. > Instead they will just specify the unique entity ID and if needed the > input/output ID as well. These IDs are declared in the board or sub-device > specific header. > > A full enumeration will typically only be done by some sort of generic > application like v4l2-ctl. Well, is this the reason why you wanted to enumerate possible connections? Should v4l2-ctrl be able to manipulate those connections? What is it for actually? > In addition, most entities will have only one or two inputs/outputs at most. > So we might optimize the data structures for this. We probably will have to > see how it goes when we implement it. > > We obviously need ioctls to make and break links between entities. It > shouldn't be hard to do this. > > Access to sub-devices > - > > What is a bit trickier is how to select a sub-device as the target for ioctls. > Normally ioctls like S_CTRL are sent to a /dev/v4l/videoX node and the driver > will figure out which sub-device (or possibly the bridge itself) will receive > it. There is no way of hijacking this mechanism to e.g. specify a specific > entity ID without also having to modify most of the v4l2 structs by adding > such an ID field. But with the media controller we can at least create an > ioctl that specifies a 'target entity' that will receive any non-media > controller ioctl. Note that for now we only support sub-devices as the target > entity. > > The idea is this: > > // Select a particular target entity > ioctl(mc, VIDIOC_S_SUBDEV, &entityID); > // Send S_FMT directly to that entity > ioctl(mc, VIDIOC_S_FMT, &fmt); is this really a "mc" fd or the respective video-devive fd? > // Send a custom ioctl to that entity > ioctl(mc, VIDIOC_OMAP3_G_HISTOGRAM, &hist); > > This requires no API changes and is very easy to implement. One problem is > that this is not thread-safe. We can either supply some sort of locking > mechanism, or just tell the application programmer to do the locking in the > application. I'm not sure what is the correct approach here. A reasonable > compromise would be to store the target entity as part of the filehandle. > So you can open the media controller multiple times and each handle can set > its own target entity. > > This also has the advantage that you can have a filehandle 'targeted' at a > resizer and a filehandle 'targeted' at the previewer, etc. If you want to use > the same filehandle from multiple threads, then you have to implement locking > yourself. You mean the driver should only care about internal consistency, and the user is allowed to otherwise shoot herself in the foot? Makes sense to me:-) > > > Open issues > === > > In no particular order: > > 1) How to tell the application that this board uses an audio loopback cable > to the PC's audio input? > > 2) There can be a lot of device nodes in complicated boards. One suggestion > is to only register them when they are linked to an entity (i.e. can be > active). Should we do this or not? Really a lot
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 4:29 PM, Antti Palosaari wrote: > Eh, not all needed, but we need some kind of rule of thumb which URB size is > suitable for bandwidth used. 512, 8k, 16k etc. It is not wise at all set it > to only 512 bytes when streaming whole TS example 22Mbit/sec. I have tested > Anysee (Cypress FX2), AF9015, CE6230, RTL2831U and all those allowed to set > URB rather freely. If you want to pick bridges that are important to you and take the time to optimize them better, by all means be my guest. This is the sort of thing that would have to be discussed with the individual maintainers of those bridges, so you can understand what logic was used in making the original decision (ensuring the original logic was not done to work around some bug, etc). > I haven't seen yet device which forces to use just one > size - though it is possible there is. Well, it depends on the chip. Selecting too small a value can result in packets getting dropped (this was a problem on em28xx until I fixed it a few months ago). > And no datasheet even needed, you can > see from debug log or error code if URB is not suitable. Well, this assumes the bridge fails gracefully, returning a failure. Take Patrick's example, where the device returns success but then proceed to not send back any URBs. > Why not set it some good value when possible? And also adding module > parameter which overrides driver default is not hard to add, just look value > user gives as param and round it to nearest suitable one. Frankly, I'm not really confident this provides much value. End-users should not really be playing around with these sorts of settings. If the values are wrong, a patch should be submitted and the maintainer should fix the driver. Cheers, 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
TeVii S650 DVB-S2 USB und s2-liplianin drivers
Hi, I tried today s2-liplianin drivers with tevii s650 and vdr cant lock any channels with this error msg: <---snip> <6>stv0900_search: <7><6>Search Fail stv0900_read_status: <7>DEMOD LOCK FAIL stv0900_read_status: <7>DEMOD LOCK FAIL <6>stb0900_set_property(..) <6>stv0900_set_tone: On <---snip---> Then i found from old installation compiled drivers from rev12458 and installed it and everything work fine (s2-liplianin-hg-12458-1-i686.pkg.tar.gz). I am on archlinux x86 with 2.6.30.5-1 kernel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On 09/10/2009 08:17 PM, Devin Heitmueller wrote: On Thu, Sep 10, 2009 at 12:48 PM, Antti Palosaari wrote: Yes thats just what I tried to say for. Look my previous thread where all currently sizes are listed. We need to define suitable values that are used. For example USB2.0 DVB-C, DVB-T, ATSC and same values for USB1.1 too. And stream size can vary much depending used transmission parameters too but I think such kind resolution logic is not needed. Currently there is almost everything between 512 to 65k used for DVB-T that makes huge difference to load device causing. Does anyone know if there is some table which says what are good USB transmission parameters for each bandwidth needed? The problem is that there cannot be any single set of rules that apply to all devices. For each chip, the rules are different and either need to be reverse engineered by the maintainer or someone has to refer to the datasheet if available. Eh, not all needed, but we need some kind of rule of thumb which URB size is suitable for bandwidth used. 512, 8k, 16k etc. It is not wise at all set it to only 512 bytes when streaming whole TS example 22Mbit/sec. I have tested Anysee (Cypress FX2), AF9015, CE6230, RTL2831U and all those allowed to set URB rather freely. I haven't seen yet device which forces to use just one size - though it is possible there is. And no datasheet even needed, you can see from debug log or error code if URB is not suitable. Why not set it some good value when possible? And also adding module parameter which overrides driver default is not hard to add, just look value user gives as param and round it to nearest suitable one. It comes as no surprise that there is a huge variation on the URB sizes chosen, and there is almost certainly an opportunity for improvement on most bridges. I suspect the logic applied by most of the people who wrote the bridge drivers was to find the first value that "works" and then not do any subsequent tuning/optimization. Like the situation with power management or tuning time, this just doesn't seem to have been a priority. And given how few developers we have actually fixing bugs, adding support for new boards, and writing new drivers, I can hardly blame them. Of course it is easiest to set as small as possible, 512 or 188 usually and it is working. wakeups are then very high but not much buffers needed. Unfortunately, with limited resources, we have to pick our battles - which is more important: having a slightly more optimal allocation that produces fewer wakeups? Or getting new product XYZ to work and fixing bugs that are highly visible to end-users? Devin Antti -- http://palosaari.fi/ -- 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: RFCv2: Media controller proposal
On Thu, Sep 10, 2009 at 4:20 PM, Mauro Carvalho Chehab wrote: > In fact, this can already be done by using the sysfs interface. the current > version of v4l2-sysfs-path.c already enumerates the associated nodes to > a /dev/video device, by just navigating at the already existing device > description nodes at sysfs. I hadn't tried yet, but I bet that a similar kind > of topology can be obtained from a dvb device (probably, we need to do some > adjustments). For the audio case, I did some digging into this a bit and It's worth noting that this behavior varies by driver (at least on USB). In some cases, the parent points to the USB device, in other cases it points to the USB interface. My original thought was to pick one or the other and make the various drivers consistent, but even that is a challenge since in some cases the audio device was provided by snd-usb-audio (which has no knowledge of the v4l subsystem). 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
Re: RFCv2: Media controller proposal
On Thursday 10 September 2009 21:19:25 Karicheri, Muralidharan wrote: > Hans, > > I haven't gone through the RFC, but thought will respond to the below comment. > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > new phone: 301-407-9583 > Old Phone : 301-515-3736 (will be deprecated) > email: m-kariche...@ti.com > > >>> > >>> I may be mistaken, but I don't believe soundcards have this same > >>> complexity are media board. > >> > >> When I launch alsa-mixer I see 4 input devices where I can select 4 > >> difference sources. This gives 16 combinations which is enough for me to > >> call it 'complex' . > >> > Could entities not be completely addressed (configuration ioctls) > through > the mc-node? > >>> > >>> Not sure what you mean. > >> > >> Instead of having a device node for each entity, the ioctls for each > >> entities are done on the media controller-node address an entity by ID. > > > >I definitely don't want to go there. Use device nodes (video, fb, alsa, > >dvb, etc) for streaming the actual media as we always did and use the > >media controller for controlling the board. It keeps everything nicely > >separate and clean. > > > > > What you mean by controlling the board? In general: the media controller can do anything except streaming. However, that is an extreme position and in practice all the usual ioctls should remain supported by the video device nodes. > We have currently ported DMxxx VPBE display drivers to 2.6.31 (Not submitted > yet to mainline). In our current implementation, the output and standard/mode > are controlled through sysfs because it is a common functionality affecting > both v4l and FBDev framebuffer devices. Traditional applications such > x-windows should be able to stream video/graphics to VPBE output. V4l2 > applications should be able to stream video. Both these devices needs to know > the display parameters such as frame buffer resolution, field etc that are to > be configured in the video or osd layers in VPBE to output frames to the > encoder that is driving the output. So to stream, first the output and > mode/standard are selected using sysfs command and then the application is > started. Following scenarios are supported by VPBE display drivers in our > internal release:- > > 1)Traditional FBDev applications (x-window) can be run using OSD device. > Allows changing mode/standards at the output using fbset command. > > 2)v4l2 driver doesn't provide s_output/s_std support since it is done through > sysfs. > > 3)Applications that requires to stream both graphics and video to the output > uses both FBDev and V4l2 devices. So these application first set the output > and mode/standard using sysfs, before doing io operations with these devices. I don't understand this approach. I'm no expert on the fb API but as far as I know the V4L2 API allows a lot more precision over the video timings (esp. with the new API you are working on). Furthermore, I assume it is possible to use the DMxxx without an OSD, right? This is very similar to the ivtv and ivtvfb drivers: if the framebuffer is in use, then you cannot change the output standard (you'll get an EBUSY error) through a video device node. That's exactly what you would expect. If the framebuffer isn't used, then you can just use the normal V4L2 API to change the output standard. In practice, I think that you can only change the resolution in the FB API. Not things like the framerate, let alone precise pixelclock, porch and sync widths. Much better to let the two cooperate: you can use both APIs, but you can't change the resolution in the fb if streaming is going on, and you can't change the output standard of a video device node if that changes the resolution while the framebuffer is in used. No need for additional sysfs entries. > > There is an encoder manager to which all available encoders registers (using > internally developed interface) and based on commands received at Fbdev/sysfs > interfaces, the current encoder is selected by the encoder manager and > current standard is selected. The encoder manager provides API to retrieve > current timing information from the current encoder. FBDev and V4L2 drivers > uses this API to configure OSD/video layers for streaming. > > As you can see, controlling output/mode is a common function required for > both v4l2 and FBDev devices. > > One way to do this to modify the encoder manager such that it load up the > encoder sub devices. This will allow our customers to migrate to this driver > on GIT kernel with minimum effort. If v4l2 display bridge driver load up the > sub devices, it will make FBDev driver useless unless media controller has > some way to handle this scenario. Any idea if media controller RFC address > this? I will go over the RFC in details, but if you have a ready answer, let > me know. I don't think this has anything to do with the media controller. It
Re: RFCv2: Media controller proposal
Hi Hans, Hi Hans, Em Thu, 10 Sep 2009 09:13:09 +0200 Hans Verkuil escreveu: First of all, a generic comment: you enumerated on your RFC several needs that you expect to be solved with a media controller, but you didn't mention what userspace API will be used to solve it (e. g. what ioctls, sysfs interfaces, etc). As this is missing, I'm adding a few notes about how this can be implemented. For example, as I've already pointed when you sent the first proposal and at LPC, sysfs is the proper kernel API for enumerating things. > Why do we need one? > === > > There are currently several problems that are impossible to solve within the > current V4L2 API: > > 1) Discovering the various device nodes that are typically created by a video > board, such as: video nodes, vbi nodes, dvb nodes, alsa nodes, framebuffer > nodes, input nodes (for e.g. webcam button events or IR remotes). In fact, this can already be done by using the sysfs interface. the current version of v4l2-sysfs-path.c already enumerates the associated nodes to a /dev/video device, by just navigating at the already existing device description nodes at sysfs. I hadn't tried yet, but I bet that a similar kind of topology can be obtained from a dvb device (probably, we need to do some adjustments). The big missing component is an userspace library that will properly return the device components to the applications. Maybe we need to do also some adjustments at the sysfs nodes to represent all that it is needed. > It would be very handy if an application can just open an /dev/v4l/mc0 node > and be able to figure out where all the nodes are, and to be able to figure > out what the capabilities of the board are (e.g. does it support DVB, is the > audio going through a loopback cable or is there an alsa device, can it do > compressed MPEG video, etc. etc.). Currently the end-user has no choice but to > supply the device nodes manually. The better would be to create a /sys/class/media node, and having the media controllers above that struct. So, mc0 will be at /sys/class/media/mc0. > 2) Some of the newer SoC devices can connect or disconnect internal components > dynamically. As an example, the omap3 can either connect a sensor output to a > CCDC module to a previewer module to a resizer module and finally to a capture > device node. But it is also possible to capture the sensor output directly > after the CCDC module. The previewer can get its input from another video > device node and output either to the resizer or to another video capture > device node. The same is true for the resizer, that too can get its input from > a device node. > > So there are lots of connections here that can be modified at will depending > on what the application wants. And in real life there are even more links than > I mentioned here. And it will only get more complicated in the future. > > All this requires that there has to be a way to connect and disconnect parts > of the internal topology of a video board at will. We should design this with care, since each change at the internal topology may create/delete devices. If you do such changes at topology, udev will need to delete the old devices and create the new ones. This will happen on separate threads and may cause locking issues at the device, especially since you can be modifying several components at the same time (being even possible to do it on separate threads). I've seen some high-end core network routers that implements topology changes on an interesting way: any changes done are not immediately applied at the node, but are stored into a file, where the configuration that can be changed anytime. However, the topology changes only happen after giving a commit command. After commit, it validates the new config and apply them atomically (e. g. or all changes are applied or none), to avoid bad effects that intermediate changes could cause. As we are at kernelspace, we need to take care to not create a very complex interface. Yet, the idea of applying the new topology atomically seems interesting. Alsa is facing a similar problem with pinup quirks needed with HD-audio boards. They are proposing a firmware like interface: http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-09/msg03198.html On their case, they are just using request_firmware() for it, at board probing time. IMO, the same approach can be used here. > 3) There is increasing demand to be able to control e.g. sensors or video > encoders/decoders at a much more precise manner. Currently the V4L2 API > provides only limited support in the form of a set of controls. But when > building a high-end camera the developer of the application controlling it > needs very detailed control of the sensor and image processing devices. > On the other hand, you do not want to have all this polluting the V4L2 API > since there is absolutely no sense in exporting this as part of the existing > controls, or to allow for a large nu
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote: > On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote: > > On 09/10/2009 04:47 PM, Antti Palosaari wrote: > >> Aleksandr V. Piskunov wrote: > >>> On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote: > Aleksandr V. Piskunov wrote: > >> Here is a test case: > >> Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. > >> Different tuners, > > Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 > Those both uses currently too small bulk urbs, only 512 bytes. I have > asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but > no-one have answered yet (search ml back week or two). I think will > increase those to the 8k to reduce load. > > >>> > >>> Nice, I'm ready to test if such change helps. > >> > >> OK, I will make test version in couple of hours. > > > > Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. > > Now powertop shows only about 220 wakeups on my computer for the both > > sticks. > > Please test and tell what powertop says: > > http://linuxtv.org/hg/~anttip/urb_size/ > > > > I wonder if we can decide what URB size DVB USB drivers should follow > > and even add new module param for overriding driver default. > > Thanks, Antti! > > Tested your branch on affected system. > > Load definitely went down, from ~7000 wakeups to ~250 for each tuner > according to powertop. > Both tuners still working ok if not used simultaneously or if used the > same time on different USB controllers. > > Bad news are that original problem still persists: putting both tuners > on same USB controller and zapping simultaneously corrupts stream. > Interesting observation: no matter in what sequence tuners are connected > (i.e. become adapter0 or adapter1), af9015 stream always gets heavily > distorted, visually mplayer picture becomes like 80% corrupted with > random color blocks and pixels, sound becomes a mess. At the same time > ce6230 gets slight corruption, a few discolored blocks at the time and > sound hickups. > > Anyway, will try to do a few more tests: > 1) Two usb flash drives on same controller calculating md5sum of > big .iso file, to check if it is/isn't dvb-usb problem. > 2) Will see if same issue persists on another PC with same motherboard > (slightly different revision) to rule out hardware issues. If I manage > to wire antenna there, that is... Ok, two USB flash drives on same controller, no problem when bulk reading from both at the same time, no speed drops, no corruption. Now if I plug ce6230 tuner, zap to channel and then start reading from flash drive: * slightly corrupted TS stream * flash drive read getting starved on bandwidth, speed drops from 10 MB/s to ~7 MB/s If I plug af9015 tuner, zap and read from flash * heavy corruption of TS stream * flash drive read speed drops from 10 MB/s to 2(!) MB/s Now I don't really know the USB protocol under-the-hood details, all the different types of bandwidth, reservation and so on. But shouldn't one 480 Mbit/sec controller handle rather large number of digital tuners, each pushing 20-25 Mbit/sec max, even considering all the overhead? -- 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: RFCv2: Media controller proposal
Hans, I haven't gone through the RFC, but thought will respond to the below comment. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com >>> >>> I may be mistaken, but I don't believe soundcards have this same >>> complexity are media board. >> >> When I launch alsa-mixer I see 4 input devices where I can select 4 >> difference sources. This gives 16 combinations which is enough for me to >> call it 'complex' . >> Could entities not be completely addressed (configuration ioctls) through the mc-node? >>> >>> Not sure what you mean. >> >> Instead of having a device node for each entity, the ioctls for each >> entities are done on the media controller-node address an entity by ID. > >I definitely don't want to go there. Use device nodes (video, fb, alsa, >dvb, etc) for streaming the actual media as we always did and use the >media controller for controlling the board. It keeps everything nicely >separate and clean. > What you mean by controlling the board? We have currently ported DMxxx VPBE display drivers to 2.6.31 (Not submitted yet to mainline). In our current implementation, the output and standard/mode are controlled through sysfs because it is a common functionality affecting both v4l and FBDev framebuffer devices. Traditional applications such x-windows should be able to stream video/graphics to VPBE output. V4l2 applications should be able to stream video. Both these devices needs to know the display parameters such as frame buffer resolution, field etc that are to be configured in the video or osd layers in VPBE to output frames to the encoder that is driving the output. So to stream, first the output and mode/standard are selected using sysfs command and then the application is started. Following scenarios are supported by VPBE display drivers in our internal release:- 1)Traditional FBDev applications (x-window) can be run using OSD device. Allows changing mode/standards at the output using fbset command. 2)v4l2 driver doesn't provide s_output/s_std support since it is done through sysfs. 3)Applications that requires to stream both graphics and video to the output uses both FBDev and V4l2 devices. So these application first set the output and mode/standard using sysfs, before doing io operations with these devices. There is an encoder manager to which all available encoders registers (using internally developed interface) and based on commands received at Fbdev/sysfs interfaces, the current encoder is selected by the encoder manager and current standard is selected. The encoder manager provides API to retrieve current timing information from the current encoder. FBDev and V4L2 drivers uses this API to configure OSD/video layers for streaming. As you can see, controlling output/mode is a common function required for both v4l2 and FBDev devices. One way to do this to modify the encoder manager such that it load up the encoder sub devices. This will allow our customers to migrate to this driver on GIT kernel with minimum effort. If v4l2 display bridge driver load up the sub devices, it will make FBDev driver useless unless media controller has some way to handle this scenario. Any idea if media controller RFC address this? I will go over the RFC in details, but if you have a ready answer, let me know. Thanks >To unsubscribe from this list: send the line "unsubscribe linux-media" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] fix lock imbalances in /drivers/media/video/cafe_ccic.c
On Thu, Sep 10, 2009 at 09:30:03AM -0600, Jonathan Corbet wrote: > On Thu, 10 Sep 2009 18:37:34 + > iceberg wrote: > > > In ./drivers/media/video/cafe_ccic.c, in function cafe_pci_probe: > > Mutex must be unlocked before exit > > 1. On paths starting with mutex lock in line 1912, then continuing in > > lines: > > 1929, 1936 (goto unreg) and 1940 (goto iounmap) . > > 2. On path starting in line 1971 mutex lock, and then continuing in > > line 1978 > > (goto out_smbus) mutex. > > That's a definite bug, but I hate all those unlocks in the error > branches. As it happens, we don't really need the mutex until the > device has been exposed to the rest of the kernel, so I propose the > following as a better patch. > > Thanks for pointing this out, Actually, for something like this, I would put the mutex_unlock in the error path, and just add a local variable to tell that it is locked. int is_locked = 0; [...] mutex_lock(&cam->s_mutex); is_locked = 1; [...] mutex_unlock(&cam->s_mutex); is_locked = 0; [...] out_iounmap: pci_iounmap(pdev, cam->regs); if (is_locked) mutex_unlock(&cam->s_mutex); out_free: [...] Or something similar. I hate the multiple unlocks too. -- Steve > > jon > > --- > Fix a mutex leak > > Certain error exits from cafe_pci_probe() can leave the camera mutex > locked. For much of the time, we didn't need the mutex anyway; take it out > and add an unlock in the path where it is needed. > > Reported-by: Alexander Strakh > Signed-off-by: Jonathan Corbet > --- > drivers/media/video/cafe_ccic.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c > index c4d181d..0f62b5e 100644 > --- a/drivers/media/video/cafe_ccic.c > +++ b/drivers/media/video/cafe_ccic.c > @@ -1909,7 +1909,6 @@ static int cafe_pci_probe(struct pci_dev *pdev, > goto out_free; > > mutex_init(&cam->s_mutex); > - mutex_lock(&cam->s_mutex); > spin_lock_init(&cam->dev_lock); > cam->state = S_NOTREADY; > cafe_set_config_needed(cam, 1); > @@ -1949,7 +1948,6 @@ static int cafe_pci_probe(struct pci_dev *pdev, >* because the sensor could attach in this call chain, leading to >* unsightly deadlocks. >*/ > - mutex_unlock(&cam->s_mutex); /* attach can deadlock */ > ret = cafe_smbus_setup(cam); > if (ret) > goto out_freeirq; > @@ -1991,6 +1989,7 @@ static int cafe_pci_probe(struct pci_dev *pdev, > return 0; > > out_smbus: > + mutex_unlock(&cam->s_mutex); > cafe_smbus_shutdown(cam); > out_freeirq: > cafe_ctlr_power_down(cam); > -- > 1.6.2.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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.linuxtv.org/hg/~hverkuil/v4l-dvb-go7007-new
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-go7007-new for the following: - v4l: Merge drivers/staging/go7007 in v4l-dvb. - go7007: semaphore -> mutex conversion This moves the maintenance of the go7007 driver into v4l-dvb. The intention is that Sensoray will work on this driver to hopefully make it possible to move it from staging to media/video by 2.6.33. Pete, Dean, I know you mailed me patches some months ago but as far as I know these were not applied to my tree due to compilation errors. I would suggest that you redo them against the v4l-dvb repository and post them to the mailinglist. Thanks, Hans diffstat: b/linux/drivers/staging/go7007/Kconfig | 37 b/linux/drivers/staging/go7007/Makefile | 27 b/linux/drivers/staging/go7007/README | 11 b/linux/drivers/staging/go7007/go7007-driver.c | 682 b/linux/drivers/staging/go7007/go7007-fw.c | 1638 b/linux/drivers/staging/go7007/go7007-i2c.c | 225 ++ b/linux/drivers/staging/go7007/go7007-priv.h| 282 +++ b/linux/drivers/staging/go7007/go7007-usb.c | 1287 b/linux/drivers/staging/go7007/go7007-v4l2.c| 1876 b/linux/drivers/staging/go7007/go7007.h | 114 + b/linux/drivers/staging/go7007/go7007.txt | 481 ++ b/linux/drivers/staging/go7007/s2250-board.c| 622 +++ b/linux/drivers/staging/go7007/s2250-loader.c | 189 ++ b/linux/drivers/staging/go7007/s2250-loader.h | 24 b/linux/drivers/staging/go7007/saa7134-go7007.c | 532 ++ b/linux/drivers/staging/go7007/snd-go7007.c | 305 +++ b/linux/drivers/staging/go7007/wis-i2c.h| 47 b/linux/drivers/staging/go7007/wis-ov7640.c | 107 + b/linux/drivers/staging/go7007/wis-saa7113.c| 335 b/linux/drivers/staging/go7007/wis-saa7115.c| 468 + b/linux/drivers/staging/go7007/wis-sony-tuner.c | 719 + b/linux/drivers/staging/go7007/wis-tw2804.c | 358 b/linux/drivers/staging/go7007/wis-tw9903.c | 339 b/linux/drivers/staging/go7007/wis-uda1342.c| 113 + b/v4l/Kconfig.staging | 66 b/v4l/Makefile.staging | 39 linux/drivers/staging/go7007/go7007-driver.c| 12 linux/drivers/staging/go7007/go7007-i2c.c | 12 linux/drivers/staging/go7007/go7007-priv.h |6 linux/drivers/staging/go7007/go7007-usb.c | 10 linux/drivers/staging/go7007/go7007-v4l2.c | 66 linux/drivers/staging/go7007/go7007.txt |4 linux/drivers/staging/go7007/s2250-board.c | 18 linux/drivers/staging/go7007/s2250-loader.c |8 linux/drivers/staging/go7007/snd-go7007.c |2 v4l/Makefile|2 v4l/scripts/make_kconfig.pl |1 37 files changed, 10994 insertions(+), 70 deletions(-) -- 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Sep 10 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12711:13c47deee3b1 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-armv5: OK linux-2.6.31-armv5-davinci: ERRORS 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-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-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS 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-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: OK 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: WARNINGS linux-2.6.19.5-x86_64: OK 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/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
Re: Volunteer for V4L2+Audio at Plumbers Conference?
On Thu, Sep 10, 2009 at 1:12 PM, Hans Verkuil wrote: > Devin, > > If we have a media controller framework, then we might be able to use that as > an alternative way to get timestamps. See note 4 at the end of the RFC that > I posted today. If it turns out that there is no decent way of handling this > in alsa, then we have at least a way out. > > Regards, > > Hans Hello Hans, I was starting to give such an idea some thought. My concern with such an approach would be the latency between the ioctl and the read() operation. Admittedly, I'm not sure though what alternative we have if we cannot provide the data in-band. One thought I had was to treat the timestamp functionality as some sort of "advanced capability" not available with the read/write interface, but that obviously doesn't solve the ALSA problem. 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
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 12:48 PM, Antti Palosaari wrote: > Yes thats just what I tried to say for. Look my previous thread where all > currently sizes are listed. We need to define suitable values that are used. > For example USB2.0 DVB-C, DVB-T, ATSC and same values for USB1.1 too. And > stream size can vary much depending used transmission parameters too but I > think such kind resolution logic is not needed. > > Currently there is almost everything between 512 to 65k used for DVB-T that > makes huge difference to load device causing. > > Does anyone know if there is some table which says what are good USB > transmission parameters for each bandwidth needed? The problem is that there cannot be any single set of rules that apply to all devices. For each chip, the rules are different and either need to be reverse engineered by the maintainer or someone has to refer to the datasheet if available. It comes as no surprise that there is a huge variation on the URB sizes chosen, and there is almost certainly an opportunity for improvement on most bridges. I suspect the logic applied by most of the people who wrote the bridge drivers was to find the first value that "works" and then not do any subsequent tuning/optimization. Like the situation with power management or tuning time, this just doesn't seem to have been a priority. And given how few developers we have actually fixing bugs, adding support for new boards, and writing new drivers, I can hardly blame them. Unfortunately, with limited resources, we have to pick our battles - which is more important: having a slightly more optimal allocation that produces fewer wakeups? Or getting new product XYZ to work and fixing bugs that are highly visible to end-users? 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
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote: > On 09/10/2009 04:47 PM, Antti Palosaari wrote: >> Aleksandr V. Piskunov wrote: >>> On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: >> Here is a test case: >> Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. >> Different tuners, > Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 Those both uses currently too small bulk urbs, only 512 bytes. I have asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one have answered yet (search ml back week or two). I think will increase those to the 8k to reduce load. >>> >>> Nice, I'm ready to test if such change helps. >> >> OK, I will make test version in couple of hours. > > Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. > Now powertop shows only about 220 wakeups on my computer for the both > sticks. > Please test and tell what powertop says: > http://linuxtv.org/hg/~anttip/urb_size/ > > I wonder if we can decide what URB size DVB USB drivers should follow > and even add new module param for overriding driver default. Thanks, Antti! Tested your branch on affected system. Load definitely went down, from ~7000 wakeups to ~250 for each tuner according to powertop. Both tuners still working ok if not used simultaneously or if used the same time on different USB controllers. Bad news are that original problem still persists: putting both tuners on same USB controller and zapping simultaneously corrupts stream. Interesting observation: no matter in what sequence tuners are connected (i.e. become adapter0 or adapter1), af9015 stream always gets heavily distorted, visually mplayer picture becomes like 80% corrupted with random color blocks and pixels, sound becomes a mess. At the same time ce6230 gets slight corruption, a few discolored blocks at the time and sound hickups. Anyway, will try to do a few more tests: 1) Two usb flash drives on same controller calculating md5sum of big .iso file, to check if it is/isn't dvb-usb problem. 2) Will see if same issue persists on another PC with same motherboard (slightly different revision) to rule out hardware issues. If I manage to wire antenna there, that is... -- 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: Volunteer for V4L2+Audio at Plumbers Conference?
On Tuesday 08 September 2009 15:41:38 Devin Heitmueller wrote: > On Tue, Sep 8, 2009 at 2:37 AM, Hans Verkuil wrote: > > Hi all, > > > > I'm looking for a v4l-dvb developer who is at the Plumbers Conference to > > attend the audio miniconference on Wednesday morning (see schedule here: > > http://linuxplumbersconf.org/2009/schedule/) and to discuss ways of > > synchronizing video and audio. > > > > I won't have time for that myself, and I also know very little about alsa. > > But this is an open topic that we need to do something about and this > > conference is a good place for that. > > > > Regards, > > > > Hans > > Hello Hans, > > I will be attending the audio seminars, since I have a keen interest > in finally getting the audio and video streams properly associated for > raw analog video (so that applications such as tvtime will work > out-of-the-box). > > I would be happy to meet up with you afterward and share my notes. Devin, If we have a media controller framework, then we might be able to use that as an alternative way to get timestamps. See note 4 at the end of the RFC that I posted today. If it turns out that there is no decent way of handling this in alsa, then we have at least a way out. 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: LinuxTV firmware blocks all wireless connections / traffic
Devin Heitmueller wrote: On Thu, Sep 10, 2009 at 11:55 AM, Antti Palosaari wrote: Devin Heitmueller wrote: The URB size is something that varies on a device-by-device basis, depending on the bridge chipset. There really is no "one-size-fits-all" value you can assume. I doubt no. I tested last week rather many USB chips and all I tested allowed to set it as x188 or x512 bytes. If it is set something than chip does not like it will give errors or packets that are not as large as requested. You can test that easily, look dvb-usb module debug uxfer and use powertop. I usually take a look at a USB trace of the device under Windows, and then use the same value. I have seen logs where different sizes of urbs used even same chip. Yes, the URB size can change depending on who wrote the driver, or what the required throughput is. For example, the em28xx has a different URB size depending on whether the target application is 19Mbps ATSC or 38Mbps QAM. That just reinforces what I'm saying - the size selected in many cases is determined by the requirements of the chipset. Yes thats just what I tried to say for. Look my previous thread where all currently sizes are listed. We need to define suitable values that are used. For example USB2.0 DVB-C, DVB-T, ATSC and same values for USB1.1 too. And stream size can vary much depending used transmission parameters too but I think such kind resolution logic is not needed. Currently there is almost everything between 512 to 65k used for DVB-T that makes huge difference to load device causing. Does anyone know if there is some table which says what are good USB transmission parameters for each bandwidth needed? Making it some multiple of 188 for DVB is logical since that's the MPEG packet size. That seems pretty common in the bridges I have worked with. Devin Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] NetUP Dual DVB-T/C-CI RF PCI-E x1
Christian Wattengård wrote: This sounds promising. I hope you are not going to price yourselves completely out as a few other DVB-C suppliers have done. If the price is right (around the same as a normal DVB-T tuner ~$65), it definitely sounds interesting. When you say it supports two transponders, is this also true on DVB-C only... As in DVB-C + DVB-C channel... If this is the case then I only need 3 cards to cover all the interesting channels in my cable network ;) I CAN TIMESHIFT THE WORLD!!! MUHAHAHAhaha... *cough* But seriously... This sounds very interesting. Christian from Norway... On Wed, Sep 9, 2009 at 4:51 PM, Abylai Ospan wrote: Hello, We have designed NetUP Dual NetUP Dual DVB-T/C-CI RF PCI-E x1 card. A short description is available in wiki - http://linuxtv.org/wiki/index.php/NetUP_Dual_DVB_T_C_CI_RF Features: * PCI-e x1 * Supports two DVB-T/DVB-C transponders simultaneously * Supports two analog audio/video channels simultaneously * Independent descrambling of two transponders * Hardware PID filtering Now we have started the work on the driver for Linux. The following components used in this card already have their code for Linux published: * Conexant CX23885, CX25840 * Xceive XC5000 silicon TV tuner We are working on the code for the following components: * STM STV0367 low-power and ultra-compact combo DVB-T/C single-chip receiver * Altera FPGA for Common Interafce. We have developed FPGA firmware for CI (according to PCMCIA/en50221). Also we are doing "hardware" PID filtering. It's fast and very flexible. JTAG is used for firmware uploading into FPGA - this part contains "JAM player" from Altera for processing JAM STAPL Byte-Code (.jbc files). The resulting code will be published under GPL after receiving permissions from IC vendors. -- Abylai Ospan NetUP Inc. P.S. We will show this card at the upcoming IBC exhibition ( stand IP402 ). The Netup dual DVB-S2 card was around $1000, I doubt the Dual DVB-T will be an order of magnitude less expensive. I'd be interested to know how many they've sold, it seems overpriced to me. BRs, Lou -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 11:55 AM, Antti Palosaari wrote: > Devin Heitmueller wrote: >> >> The URB size is something that varies on a device-by-device basis, >> depending on the bridge chipset. There really is no >> "one-size-fits-all" value you can assume. > > I doubt no. I tested last week rather many USB chips and all I tested > allowed to set it as x188 or x512 bytes. If it is set something than chip > does not like it will give errors or packets that are not as large as > requested. You can test that easily, look dvb-usb module debug uxfer and use > powertop. > >> I usually take a look at a USB trace of the device under Windows, and >> then use the same value. > > I have seen logs where different sizes of urbs used even same chip. Yes, the URB size can change depending on who wrote the driver, or what the required throughput is. For example, the em28xx has a different URB size depending on whether the target application is 19Mbps ATSC or 38Mbps QAM. That just reinforces what I'm saying - the size selected in many cases is determined by the requirements of the chipset. Making it some multiple of 188 for DVB is logical since that's the MPEG packet size. That seems pretty common in the bridges I have worked with. 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
Re: LinuxTV firmware blocks all wireless connections / traffic
Devin Heitmueller wrote: The URB size is something that varies on a device-by-device basis, depending on the bridge chipset. There really is no "one-size-fits-all" value you can assume. I doubt no. I tested last week rather many USB chips and all I tested allowed to set it as x188 or x512 bytes. If it is set something than chip does not like it will give errors or packets that are not as large as requested. You can test that easily, look dvb-usb module debug uxfer and use powertop. I usually take a look at a USB trace of the device under Windows, and then use the same value. I have seen logs where different sizes of urbs used even same chip. regards Antti -- http://palosaari.fi/ -- 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: DVB USB stream parameters
Hi Antti, sorry for answering with delay. On Sat, 5 Sep 2009, Antti Palosaari wrote: What are preferred BULK stream parameters, .count and .buffersize? for USB2.0? for USB1.1? buffersize, which is URB size, have great effect to system load. For example 512 bytes generates about 10x more wakeups than 5120. It is quite clear that 512 is too small for whole DVB stream. I did some test and looks like all USB2.0 devices I have here allow x512 or x188 sizes. Heinrich Langos did some measurements and results can be seen here: http://www.linuxtv.org/wiki/index.php/User:Hlangos In my understanding we should found some balance between URB size and transferred stream bandwidth. For example DVB-T stream, when common transmission parameters are used, is more than 20Mbit/sec. There is also USB bridge chips which does have two or more different standard frontends needed different stream bandwidths. Should we add new module param for override module default? a800BULK 7x 4096= 28672 af9005 BULK 10x 4096= 40960 USB1.1 BUGFIX: x512=>x188 af9015 BULK 6x 3072= 3072 BUGFIX: x512=>x188 anysee BULK 8x 512= 4096 ce6230 BULK 6x 512= 3072 cinergyT2 BULK 5x 512= 2560 cxusb BULK 5x 8192= 40960 cxusb BULK 7x 4096= 28672 dib0700 BULK 4x39480=157920 210x188 !!HUGE!! dibusb-mb BULK 7x 4096= 28672 56x512 dibusb-mc BULK 7x 4096= 28672 digitv BULK 7x 4096= 28672 dtt200u BULK 7x 4096= 28672 dtv5100 BULK 8x 4096= 32768 dw2102 BULK 8x 4096= 32768 gl861 BULK 7x 512= 3584 gp8psk BULK 7x 8192= 57344 m920x BULK 8x 512= 4096 m920x BULK 8x16384=131072 256x512 !!HUGE!! nova-t-usb2 BULK 7x 4096= 28672 opera1 BULK 10x 4096= 40960 umt-010 BULK 10x 512= 5120 vp702x BULK 10x 4096= 40960 vp7045 BULK 7x 4096= 28672 au6610 ISOC 5 frames 40 size 942 ttusb2 ISOC 5 frames 4 size 942 I don't know exactly why (the USB/HW background for that is not present in my brain), but at some point having less than 39480B for one (high-level) URB for the dib0700 resulted in never having any URB returning from the USB stack. I chose 4 of them because .. I don't remember. It seems even 1 is working. I remember someone telling me that this is due to something in the firmware. I need to wait for some people to be back from whereever they are to know exactly what's going on (that's why I haven't responded yet). -- Patrick 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] fix lock imbalances in /drivers/media/video/cafe_ccic.c
On Thu, 10 Sep 2009 18:37:34 + iceberg wrote: > In ./drivers/media/video/cafe_ccic.c, in function cafe_pci_probe: > Mutex must be unlocked before exit > 1. On paths starting with mutex lock in line 1912, then continuing in > lines: > 1929, 1936 (goto unreg) and 1940 (goto iounmap) . > 2. On path starting in line 1971 mutex lock, and then continuing in > line 1978 > (goto out_smbus) mutex. That's a definite bug, but I hate all those unlocks in the error branches. As it happens, we don't really need the mutex until the device has been exposed to the rest of the kernel, so I propose the following as a better patch. Thanks for pointing this out, jon --- Fix a mutex leak Certain error exits from cafe_pci_probe() can leave the camera mutex locked. For much of the time, we didn't need the mutex anyway; take it out and add an unlock in the path where it is needed. Reported-by: Alexander Strakh Signed-off-by: Jonathan Corbet --- drivers/media/video/cafe_ccic.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c index c4d181d..0f62b5e 100644 --- a/drivers/media/video/cafe_ccic.c +++ b/drivers/media/video/cafe_ccic.c @@ -1909,7 +1909,6 @@ static int cafe_pci_probe(struct pci_dev *pdev, goto out_free; mutex_init(&cam->s_mutex); - mutex_lock(&cam->s_mutex); spin_lock_init(&cam->dev_lock); cam->state = S_NOTREADY; cafe_set_config_needed(cam, 1); @@ -1949,7 +1948,6 @@ static int cafe_pci_probe(struct pci_dev *pdev, * because the sensor could attach in this call chain, leading to * unsightly deadlocks. */ - mutex_unlock(&cam->s_mutex); /* attach can deadlock */ ret = cafe_smbus_setup(cam); if (ret) goto out_freeirq; @@ -1991,6 +1989,7 @@ static int cafe_pci_probe(struct pci_dev *pdev, return 0; out_smbus: + mutex_unlock(&cam->s_mutex); cafe_smbus_shutdown(cam); out_freeirq: cafe_ctlr_power_down(cam); -- 1.6.2.5 -- 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: [PATCH] fix lock imbalances in /drivers/media/video/cafe_ccic.c
In ./drivers/media/video/cafe_ccic.c, in function cafe_pci_probe:
Mutex must be unlocked before exit
1. On paths starting with mutex lock in line 1912, then continuing in
lines:
1929, 1936 (goto unreg) and 1940 (goto iounmap) .
2. On path starting in line 1971 mutex lock, and then continuing in
line 1978
(goto out_smbus) mutex.
Fix lock imbalances in function cafe_pci_probe.
Found by Linux Driver Verification project.
Signed-off-by: Alexander Strakh
---
diff --git a/./a/drivers/media/video/cafe_ccic.c
b/./b/drivers/media/video/cafe_ccic.c
index c4d181d..2987433 100644
--- a/./a/drivers/media/video/cafe_ccic.c
+++ b/./b/drivers/media/video/cafe_ccic.c
@@ -1925,19 +1925,24 @@ static int cafe_pci_probe(struct pci_dev *pdev,
* Get set up on the PCI bus.
*/
ret = pci_enable_device(pdev);
- if (ret)
+ if (ret) {
+ mutex_unlock(&cam->s_mutex);
goto out_unreg;
+ }
pci_set_master(pdev);
ret = -EIO;
cam->regs = pci_iomap(pdev, 0, 0);
if (! cam->regs) {
printk(KERN_ERR "Unable to ioremap cafe-ccic regs\n");
+ mutex_unlock(&cam->s_mutex);
goto out_unreg;
}
ret = request_irq(pdev->irq, cafe_irq, IRQF_SHARED, "cafe-ccic", cam);
- if (ret)
+ if (ret) {
+ mutex_unlock(&cam->s_mutex);
goto out_iounmap;
+ }
/*
* Initialize the controller and leave it powered up. It will
* stay that way until the sensor driver shows up.
@@ -1974,8 +1979,10 @@ static int cafe_pci_probe(struct pci_dev *pdev,
/* cam->vdev.debug = V4L2_DEBUG_IOCTL_ARG;*/
cam->vdev.v4l2_dev = &cam->v4l2_dev;
ret = video_register_device(&cam->vdev, VFL_TYPE_GRABBER, -1);
- if (ret)
+ if (ret) {
+ mutex_unlock(&cam->s_mutex);
goto out_smbus;
+ }
video_set_drvdata(&cam->vdev, cam);
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 10:48 AM, Antti Palosaari wrote: > Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. > Now powertop shows only about 220 wakeups on my computer for the both > sticks. > Please test and tell what powertop says: > http://linuxtv.org/hg/~anttip/urb_size/ > > I wonder if we can decide what URB size DVB USB drivers should follow and > even add new module param for overriding driver default. > > Antti > -- > http://palosaari.fi/ > Hello Antti, The URB size is something that varies on a device-by-device basis, depending on the bridge chipset. There really is no "one-size-fits-all" value you can assume. I usually take a look at a USB trace of the device under Windows, and then use the same value. Cheers, 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
Re: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support, no idea what to try.
from cx88-input.c
case CX88_BOARD_ADSTECH_DVB_T_PCI:
ir_codes = ir_codes_adstech_dvb_t_pci;
ir->gpio_addr = MO_GP1_IO;
ir->mask_keycode = 0xbf;
ir->mask_keyup = 0x40;
ir->polling = 50; /* ms */
break;
I'm not sure how much of the adstech instant tv dvb-t pci can be copied
for the non dvb-t one but could the solution be something along the
lines of that "ir->gpio_addr" thing ? or is that specific to the cx88
driver ?
Morvan Le Meut a écrit :
Still rambling about it :)
i was just comparing the instant TV dvb-t pci keymap with what i got
for the instant tv pci :
dvb-t
{ 0x4d, KEY_0 },
{ 0x57, KEY_1 },
{ 0x4f, KEY_2 },
{ 0x53, KEY_3 },
{ 0x56, KEY_4 },
{ 0x4e, KEY_5 },
{ 0x5e, KEY_6 },
{ 0x54, KEY_7 },
{ 0x4c, KEY_8 },
{ 0x5c, KEY_9 },
pci
{ 0xd, KEY_0 },
{ 0x17, KEY_1 },
{ 0xf, KEY_2 },
{ 0x13, KEY_3 },
{ 0x16, KEY_4 },
{ 0xe, KEY_5 },
{ 0x1e, KEY_6 },
{ 0x14, KEY_7 },
{ 0xc, KEY_8 },
{ 0x1c, KEY_9 },
if manufacturers are half as lazy as i am, and since the remote is the
same ( or at least looks the same ), it looks like i am indeed missing
part of the gpio. ( no mark, got the output with ir_debug=1 )
now for the rest of the keys :
dvb-t
{ 0x5b, KEY_POWER },
{ 0x5f, KEY_MUTE },
{ 0x55, KEY_GOTO },
{ 0x5d, KEY_SEARCH },
{ 0x17, KEY_EPG },/* Guide */
{ 0x1f, KEY_MENU },
{ 0x0f, KEY_UP },
{ 0x46, KEY_DOWN },
{ 0x16, KEY_LEFT },
{ 0x1e, KEY_RIGHT },
{ 0x0e, KEY_SELECT },/* Enter */
{ 0x5a, KEY_INFO },
{ 0x52, KEY_EXIT },
{ 0x59, KEY_PREVIOUS },
{ 0x51, KEY_NEXT },
{ 0x58, KEY_REWIND },
{ 0x50, KEY_FORWARD },
{ 0x44, KEY_PLAYPAUSE },
{ 0x07, KEY_STOP },
{ 0x1b, KEY_RECORD },
{ 0x13, KEY_TUNER },/* Live */
{ 0x0a, KEY_A },
{ 0x12, KEY_B },
{ 0x03, KEY_PROG1 },/* 1 */
{ 0x01, KEY_PROG2 },/* 2 */
{ 0x00, KEY_PROG3 },/* 3 */
{ 0x06, KEY_DVD },
{ 0x48, KEY_AUX },/* Photo */
{ 0x40, KEY_VIDEO },
{ 0x19, KEY_AUDIO },/* Music */
{ 0x0b, KEY_CHANNELUP },
{ 0x08, KEY_CHANNELDOWN },
{ 0x15, KEY_VOLUMEUP },
{ 0x1c, KEY_VOLUMEDOWN },
pci
{ 0x1b, KEY_POWER },
{ 0x1f, KEY_MUTE },
{ 0x15, KEY_GOTO },
{ 0x1d, KEY_SEARCH },
{ 0x17, KEY_EPG },/* Guide */
{ 0x1f, KEY_MENU },
{ 0x0f, KEY_UP },
{ 0x6, KEY_DOWN },
{ 0x16, KEY_LEFT },
{ 0x1e, KEY_RIGHT },
{ 0x0e, KEY_SELECT },/* Enter */
{ 0x1a, KEY_INFO },
{ 0x12, KEY_EXIT },
{ 0x19, KEY_PREVIOUS },
{ 0x11, KEY_NEXT },
{ 0x18, KEY_REWIND },
{ 0x10, KEY_FORWARD },
{ 0x4, KEY_PLAYPAUSE },
{ 0x07, KEY_STOP },
{ 0x1b, KEY_RECORD },
{ 0x13, KEY_TUNER },/* Live */
{ 0x0a, KEY_A },
{ 0x12, KEY_B },
{ 0x03, KEY_PROG1 },/* 1 */
{ 0x01, KEY_PROG2 },/* 2 */
{ 0x00, KEY_PROG3 },/* 3 */
{ 0x06, KEY_DVD },
{ 0x8, KEY_AUX },/* Photo */
{ 0x0, KEY_VIDEO },
{ 0x19, KEY_AUDIO },/* Music */
{ 0x0b, KEY_CHANNELUP },
{ 0x08, KEY_CHANNELDOWN },
{ 0x15, KEY_VOLUMEUP },
{ 0x1c, KEY_VOLUMEDOWN },
as you can see, for most of the keycodes, i am missing 0x40, which
mean i am missing one bit.
And i don't even know where i should start looking to solve that problem.
thanks for any help/solution.
--
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] fix lock imbalances in /drivers/media/video/cafe_ccic.c
In ./drivers/media/video/cafe_ccic.c, in function cafe_pci_probe:
Mutex must be unlocked before exit
1. On paths starting with mutex lock in line 1912, then continuing in
lines:
1929, 1936 (goto unreg) and 1940 (goto iounmap) .
2. On path starting in line 1971 mutex lock, and then continuing in
line 1978
(goto out_smbus) mutex.
Fix lock imbalances in function cafe_pci_probe.
Found by Linux Driver Verification project.
Signed-off-by: Alexander Strakh
---
diff --git a/./a/drivers/media/video/cafe_ccic.c
b/./b/drivers/media/video/cafe_ccic.c
index c4d181d..2987433 100644
--- a/./a/drivers/media/video/cafe_ccic.c
+++ b/./b/drivers/media/video/cafe_ccic.c
@@ -1925,19 +1925,24 @@ static int cafe_pci_probe(struct pci_dev *pdev,
* Get set up on the PCI bus.
*/
ret = pci_enable_device(pdev);
- if (ret)
+ if (ret) {
+ mutex_unlock(&cam->s_mutex);
goto out_unreg;
+ }
pci_set_master(pdev);
ret = -EIO;
cam->regs = pci_iomap(pdev, 0, 0);
if (! cam->regs) {
printk(KERN_ERR "Unable to ioremap cafe-ccic regs\n");
+ mutex_unlock(&cam->s_mutex);
goto out_unreg;
}
ret = request_irq(pdev->irq, cafe_irq, IRQF_SHARED, "cafe-ccic", cam);
- if (ret)
+ if (ret) {
+ mutex_unlock(&cam->s_mutex);
goto out_iounmap;
+ }
/*
* Initialize the controller and leave it powered up. It will
* stay that way until the sensor driver shows up.
@@ -1974,8 +1979,10 @@ static int cafe_pci_probe(struct pci_dev *pdev,
/* cam->vdev.debug = V4L2_DEBUG_IOCTL_ARG;*/
cam->vdev.v4l2_dev = &cam->v4l2_dev;
ret = video_register_device(&cam->vdev, VFL_TYPE_GRABBER, -1);
- if (ret)
+ if (ret) {
+ mutex_unlock(&cam->s_mutex);
goto out_smbus;
+ }
video_set_drvdata(&cam->vdev, cam);
/*
--
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: RFCv2: Media controller proposal
> On Thu, 10 Sep 2009, Hans Verkuil wrote: >> Now that this is in we can continue with the next phase and actually >> think >> on how it should be implemented. > > Sounds logic. > >>> Hmm... I'm seeing this idea covering other stream-oriented devices. >>> Like >>> sound-cards (*ouch*). >> >> I may be mistaken, but I don't believe soundcards have this same >> complexity are media board. > > When I launch alsa-mixer I see 4 input devices where I can select 4 > difference sources. This gives 16 combinations which is enough for me to > call it 'complex' . > >>> Could entities not be completely addressed (configuration ioctls) >>> through >>> the mc-node? >> >> Not sure what you mean. > > Instead of having a device node for each entity, the ioctls for each > entities are done on the media controller-node address an entity by ID. I definitely don't want to go there. Use device nodes (video, fb, alsa, dvb, etc) for streaming the actual media as we always did and use the media controller for controlling the board. It keeps everything nicely separate and clean. > >>> Only entities who have an output/input with is of type >>> 'user-space-interface' are actually having a node where the user (in >>> user-space) can read from/write to? >> >> Yes, each device node (i.e. that can be read from or written to) is >> represented by an entity. That makes sense as well, since there usually >> is >> a DMA engine associated with this, which definitely qualifies as >> something >> more than 'just' an input or output from some other block. You may even >> want to control this in someway through the media controller (setting up >> DMA parameters?). >> >> Inputs and outputs are not meant to represent anything complex. They >> just >> represent pins or busses. > > Or DMA-engines. > > When I say bus I meant something which transfer data from a to b, so a bus > covers DMA engines. Thus a DMA engine or a real bus represents a > connection of an output and an input. Not quite: a DMA engine transfers the media to or from memory over some bus. The crucial bit is 'memory'. Anyway, device nodes is where an application can finally get hold of the data and you need a way to tell the app where to find those devices and what properties they have. And that's what a device node entity does. > >> Not really a datastream bus, more the DMA engine (or something similar) >> associated with a datastream bus. It's really the place where data is >> passed to/from userspace. I.e. the bus between a sensor and a resizer is >> not an entity. It's probably what you meant in any case. > > Yes. > >>> 2) What is today a dvb_frontend could become several entities: I'm >>> seeing >>> tuner, demodulator, channel-decoder, amplifiers. >> >> In practice every i2c device will be an entity. If the main bridge IC >> contains integrated tuners, demods, etc., then the driver can divide >> them >> up in sub-devices at will. >> >> I have actually thought of sub-sub-devices. Some i2c devices can be >> very, >> very complex. It's possible to do and we should probably allow for this >> to >> happen in the future. Although we shouldn't implement this initially. > > Yes, for me i2c-bus-client-device is not necessarily one media_subdevice. It is currently, but I agree, that's something that we may want to make more generic in the future. > > Even the term i2c is not terminal. Meaning that more and more devices will > use SPI or SDIO or other busses for communication between components in > the future. Or at least there will be some. That's no problem, v4l2_subdev is bus-agnostic. > > Also: If we sub-bus is implemented as a subdev other devices are attached > to that bus can be normal subdevs. > > Why is it important to have all devices on one bus? Because of the > propagation of ioctl? If so, the sub-bus-subdev from above can simply > forward the ioctls on its bus to it's attached subdevs. No need of > sub-sub-devs ;) . Sub-devices are registered with the v4l2_device. And that's really all you need. In the end it is a design issue how many sub-devices you create. > >>> I really, really like this approach as it gives flexibily to user-space >>> applications which will ultimatetly improve the quality of the >>> supported >>> devices, but I think it has to be assisted by a user-space library and >>> the >>> access has to be done exclusively by that library. I'm aware that this >>> library-idea could be a hot discussion point. >> >> I do not see how you can make any generic library for this. You can make >> libraries for each specific board (I'm talking SoCs here mostly) that >> provide a slightly higher level of abstraction, but making something >> generic? I don't see how. You could perhaps do something for specific >> use-cases, though. > > Not a 100% generic library, but a library which has some models inside for > different types of media controllers. Of course the model of a webcam is > different as the model of a DTV-device. > > Maybe model is not the right word, let'
Re: LinuxTV firmware blocks all wireless connections / traffic
On 09/10/2009 04:47 PM, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: Here is a test case: Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 Those both uses currently too small bulk urbs, only 512 bytes. I have asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one have answered yet (search ml back week or two). I think will increase those to the 8k to reduce load. Nice, I'm ready to test if such change helps. OK, I will make test version in couple of hours. Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. Now powertop shows only about 220 wakeups on my computer for the both sticks. Please test and tell what powertop says: http://linuxtv.org/hg/~anttip/urb_size/ I wonder if we can decide what URB size DVB USB drivers should follow and even add new module param for overriding driver default. Antti -- http://palosaari.fi/ -- 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] fix lock imbalances in /drivers/media/video/cafe_ccic.c
On Thu, 2009-09-10 at 18:37 +, iceberg wrote: > In ./drivers/media/video/cafe_ccic.c, in function cafe_pci_probe: > Mutex must be unlocked before exit > 1. On paths starting with mutex lock in line 1912, then continuing in > lines: > 1929, 1936 (goto unreg) and 1940 (goto iounmap) . > 2. On path starting in line 1971 mutex lock, and then continuing in > line 1978 > (goto out_smbus) mutex. > > Fix lock imbalances in function cafe_pci_probe. > Found by Linux Driver Verification project. Could you run this through checkpatch and fix any issues you find? It looks like you need to use tabs for indentation in a couple places. Daniel -- 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: RFCv2: Media controller proposal
On Thu, 10 Sep 2009, Hans Verkuil wrote: Now that this is in we can continue with the next phase and actually think on how it should be implemented. Sounds logic. Hmm... I'm seeing this idea covering other stream-oriented devices. Like sound-cards (*ouch*). I may be mistaken, but I don't believe soundcards have this same complexity are media board. When I launch alsa-mixer I see 4 input devices where I can select 4 difference sources. This gives 16 combinations which is enough for me to call it 'complex' . Could entities not be completely addressed (configuration ioctls) through the mc-node? Not sure what you mean. Instead of having a device node for each entity, the ioctls for each entities are done on the media controller-node address an entity by ID. Only entities who have an output/input with is of type 'user-space-interface' are actually having a node where the user (in user-space) can read from/write to? Yes, each device node (i.e. that can be read from or written to) is represented by an entity. That makes sense as well, since there usually is a DMA engine associated with this, which definitely qualifies as something more than 'just' an input or output from some other block. You may even want to control this in someway through the media controller (setting up DMA parameters?). Inputs and outputs are not meant to represent anything complex. They just represent pins or busses. Or DMA-engines. When I say bus I meant something which transfer data from a to b, so a bus covers DMA engines. Thus a DMA engine or a real bus represents a connection of an output and an input. Not really a datastream bus, more the DMA engine (or something similar) associated with a datastream bus. It's really the place where data is passed to/from userspace. I.e. the bus between a sensor and a resizer is not an entity. It's probably what you meant in any case. Yes. 2) What is today a dvb_frontend could become several entities: I'm seeing tuner, demodulator, channel-decoder, amplifiers. In practice every i2c device will be an entity. If the main bridge IC contains integrated tuners, demods, etc., then the driver can divide them up in sub-devices at will. I have actually thought of sub-sub-devices. Some i2c devices can be very, very complex. It's possible to do and we should probably allow for this to happen in the future. Although we shouldn't implement this initially. Yes, for me i2c-bus-client-device is not necessarily one media_subdevice. Even the term i2c is not terminal. Meaning that more and more devices will use SPI or SDIO or other busses for communication between components in the future. Or at least there will be some. Also: If we sub-bus is implemented as a subdev other devices are attached to that bus can be normal subdevs. Why is it important to have all devices on one bus? Because of the propagation of ioctl? If so, the sub-bus-subdev from above can simply forward the ioctls on its bus to it's attached subdevs. No need of sub-sub-devs ;) . I really, really like this approach as it gives flexibily to user-space applications which will ultimatetly improve the quality of the supported devices, but I think it has to be assisted by a user-space library and the access has to be done exclusively by that library. I'm aware that this library-idea could be a hot discussion point. I do not see how you can make any generic library for this. You can make libraries for each specific board (I'm talking SoCs here mostly) that provide a slightly higher level of abstraction, but making something generic? I don't see how. You could perhaps do something for specific use-cases, though. Not a 100% generic library, but a library which has some models inside for different types of media controllers. Of course the model of a webcam is different as the model of a DTV-device. Maybe model is not the right word, let's call it template. A template defines a possible chain of certain types of entities which provide a media-stream at their output. I would love to see that happen. But then dvb should first migrate to the standard i2c API, and then integrate that into v4l2_subdev (by that time we should probably rename it to media_subdev). Not a trivial job, but it would truly integrate the two parts. As you state in your initial approach, existing APIs are not broken, so it's all about future development. -- Patrick 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: RFCv2: Media controller proposal
Hi Patrick, > Hello Hans, > > > On Thu, 10 Sep 2009, Hans Verkuil wrote: >> Here is the new Media Controller RFC. It is completely rewritten from >> the >> original RFC. This original RFC can be found here: >> >> http://www.archivum.info/video4linux-list%40redhat.com/2008-07/00371/RFC:_Add_support_to_query_and_change_connections_inside_a_media_device >> >> This document will be the basis of the discussions during the Plumbers >> Conference in two weeks time. > > I wasn't following this RFC during the past year, though I heard you > talking about this idea at LPC 2008. There were no follow-ups for this RFC in the past year. All the work was concentrated on the new framework (v4l2_device and v4l2_subdev) which was in any case needed before we could even think of continuing with this RFC. Now that this is in we can continue with the next phase and actually think on how it should be implemented. > > I will add some things to discussion (see below) I have in my mind > regarding similar difficulties we face today with some pure-DTV devices. > > From a first look, it seems media controller could not only unify v4l and > DVB device abstraction layers, but also a missing features to DTV devices > which are not present right now. Yes, that's the idea. Currently I am concentrating exclusively on v4l since we really, really need it there asap. But it is a very generic idea that makes no assumptions on the hardware. It just gives you an abstract view of the board and a way to access it. > >> [..] >> >> Topology >> >> >> The topology is represented by entities. Each entity has 0 or more >> inputs and >> 0 or more outputs. Each input or output can be linked to 0 or more >> possible >> outputs or inputs from other entities. This is either mutually exclusive >> (i.e. an input/output can be connected to only one output/input at a >> time) >> or it can be connected to multiple inputs/outputs at the same time. >> >> A device node is a special kind of entity with just one input (capture >> node) >> or output (video node). It may have both if it does some in-place >> operation. >> >> Each entity has a unique numerical ID (unique for the board). Each input >> or >> output has a unique numerical ID as well, but that ID is only unique to >> the >> entity. To specify a particular input or output of an entity one would >> give >> an tuple. >> >> When enumerating over entities you will need to retrieve at least the >> following information: >> >> - type (subdev or device node) >> - entity ID >> - entity description (can be quite long) >> - subtype (what sort of device node or subdev is it?) >> - capabilities (what can the entity do? Specific to the subtype and more >> precise than the v4l2_capability struct which only deals with the board >> capabilities) >> - addition subtype-specific data (union) >> - number of inputs and outputs. The input IDs should probably just be a >> value >> of 0 - (#inputs - 1) (ditto for output IDs). >> >> Another ioctl is needed to obtain the list of possible links that can be >> made >> for each input and output. >> >> It is good to realize that most applications will just enumerate e.g. >> capture >> device nodes. Few applications will do a full scan of the whole >> topology. >> Instead they will just specify the unique entity ID and if needed the >> input/output ID as well. These IDs are declared in the board or >> sub-device >> specific header. > > Very good this topology-idea! > > I can even see this to be continued in user-space in a very smart > application/library: A software MPEG decoder/rescaler whatever would be > such an entity for example. True, but in practice it will be very hard to make such an app for generic hardware. You can hide some of the hardware-specific code behind a library, but the whole point of giving access is to optimally utilize all the hw-specific bits. On the other hand, having a library that tries to do a 'best effort' job might be quite feasible. >> A full enumeration will typically only be done by some sort of generic >> application like v4l2-ctl. > > Hmm... I'm seeing this idea covering other stream-oriented devices. Like > sound-cards (*ouch*). I may be mistaken, but I don't believe soundcards have this same complexity are media board. > >> [..] >> >> Open issues >> === >> >> In no particular order: >> >> 1) How to tell the application that this board uses an audio loopback >> cable >> to the PC's audio input? >> >> 2) There can be a lot of device nodes in complicated boards. One >> suggestion >> is to only register them when they are linked to an entity (i.e. can be >> active). Should we do this or not? > > Could entities not be completely addressed (configuration ioctls) through > the mc-node? Not sure what you mean. > Only entities who have an output/input with is of type > 'user-space-interface' are actually having a node where the user (in > user-space) can read from/write to? Yes, each device node (i.e. that can be read from or wr
Re: LinuxTV firmware blocks all wireless connections / traffic
Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: Here is a test case: Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 Those both uses currently too small bulk urbs, only 512 bytes. I have asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one have answered yet (search ml back week or two). I think will increase those to the 8k to reduce load. Nice, I'm ready to test if such change helps. OK, I will make test version in couple of hours. Does USB subsystem provide any way to monitor current raw USB data transfer rate? I don't if there is tool for raw data analysis, but for DVB devices you can use dvbtraffic tool. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote: > Aleksandr V. Piskunov wrote: >>> Here is a test case: >>> Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, >> >> Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 > > Those both uses currently too small bulk urbs, only 512 bytes. I have > asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one > have answered yet (search ml back week or two). I think will increase > those to the 8k to reduce load. > Nice, I'm ready to test if such change helps. Does USB subsystem provide any way to monitor current raw USB data transfer rate? -- 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 with Haupauge WinTV-HVR 900
2009/9/10 Martin Feuersänger : > Hi list, > > I own the above TV USB stick (the 2040:6500 version, which is revision 1 > of the model)since a while now but didn't use it for several months (and > kernel versions) now. It used to work in previous kernel versions. > > I guess that quite some things have changed in the kernel modules since > last time I used the stick. From my previous usage I still had the > xc3023_*.i2c.fw files hanging around in /lib/firmware but they seem > obsolete now. So I followed the firmware extraction information (which was > new to me) at http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028 > where it is claimed that the extracted firmware should "work with a large > number of boards from different manufacturers." > > However, I seem to have problems. Right now I'm running > 2.6.30-4.slh.2-sidux-686 kernel version (provided by the sidux team) and > when plugging in the stick I get > > xc2028 0-0061: creating new instance > xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner > i2c-adapter i2c-0: firmware: requesting xc3028-v27.fw > xc2028 0-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 > firmware, > ver 2.7 > xc2028 0-0061: Loading firmware for type=BASE MTS (5), id . > xc2028 0-0061: Loading firmware for type=MTS (4), id . > xc2028 0-0061: attaching existing instance > xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner > > (Full dmesg output can be seen at http://pastebin.com/f148257f6) > > When I try to do something with the stick I get error messages saying > "Incorrect readback of firmware version." > > From googleing I found that other people with the same device for the > type=MTS have a line with a different id, i.e. > > xc2028 0-0061: Loading firmware for type=MTS (4), id b700. > > I hope that someone on this list can identify what problem I have/what I > do wrong. > > Thanks in advance! > > Martin Hello Martin, There was a regression with the HVR-900 that exhibited this behavior, for which my fix was merged on July 15th. Please update to the latest v4l-dvb code and that should address your issue. Instructions below: http://linuxtv.org/repo Cheers, 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
Problems with Haupauge WinTV-HVR 900
Hi list, I own the above TV USB stick (the 2040:6500 version, which is revision 1 of the model)since a while now but didn't use it for several months (and kernel versions) now. It used to work in previous kernel versions. I guess that quite some things have changed in the kernel modules since last time I used the stick. From my previous usage I still had the xc3023_*.i2c.fw files hanging around in /lib/firmware but they seem obsolete now. So I followed the firmware extraction information (which was new to me) at http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028 where it is claimed that the extracted firmware should "work with a large number of boards from different manufacturers." However, I seem to have problems. Right now I'm running 2.6.30-4.slh.2-sidux-686 kernel version (provided by the sidux team) and when plugging in the stick I get xc2028 0-0061: creating new instance xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner i2c-adapter i2c-0: firmware: requesting xc3028-v27.fw xc2028 0-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 0-0061: Loading firmware for type=BASE MTS (5), id . xc2028 0-0061: Loading firmware for type=MTS (4), id . xc2028 0-0061: attaching existing instance xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner (Full dmesg output can be seen at http://pastebin.com/f148257f6) When I try to do something with the stick I get error messages saying "Incorrect readback of firmware version." >From googleing I found that other people with the same device for the type=MTS have a line with a different id, i.e. xc2028 0-0061: Loading firmware for type=MTS (4), id b700. I hope that someone on this list can identify what problem I have/what I do wrong. Thanks in advance! Martin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
Aleksandr V. Piskunov wrote: Here is a test case: Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 Those both uses currently too small bulk urbs, only 512 bytes. I have asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one have answered yet (search ml back week or two). I think will increase those to the 8k to reduce load. Antti -- http://palosaari.fi/ -- 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: RFCv2: Media controller proposal
Hello Hans, On Thu, 10 Sep 2009, Hans Verkuil wrote: Here is the new Media Controller RFC. It is completely rewritten from the original RFC. This original RFC can be found here: http://www.archivum.info/video4linux-list%40redhat.com/2008-07/00371/RFC:_Add_support_to_query_and_change_connections_inside_a_media_device This document will be the basis of the discussions during the Plumbers Conference in two weeks time. I wasn't following this RFC during the past year, though I heard you talking about this idea at LPC 2008. I will add some things to discussion (see below) I have in my mind regarding similar difficulties we face today with some pure-DTV devices. From a first look, it seems media controller could not only unify v4l and DVB device abstraction layers, but also a missing features to DTV devices which are not present right now. [..] Topology The topology is represented by entities. Each entity has 0 or more inputs and 0 or more outputs. Each input or output can be linked to 0 or more possible outputs or inputs from other entities. This is either mutually exclusive (i.e. an input/output can be connected to only one output/input at a time) or it can be connected to multiple inputs/outputs at the same time. A device node is a special kind of entity with just one input (capture node) or output (video node). It may have both if it does some in-place operation. Each entity has a unique numerical ID (unique for the board). Each input or output has a unique numerical ID as well, but that ID is only unique to the entity. To specify a particular input or output of an entity one would give an tuple. When enumerating over entities you will need to retrieve at least the following information: - type (subdev or device node) - entity ID - entity description (can be quite long) - subtype (what sort of device node or subdev is it?) - capabilities (what can the entity do? Specific to the subtype and more precise than the v4l2_capability struct which only deals with the board capabilities) - addition subtype-specific data (union) - number of inputs and outputs. The input IDs should probably just be a value of 0 - (#inputs - 1) (ditto for output IDs). Another ioctl is needed to obtain the list of possible links that can be made for each input and output. It is good to realize that most applications will just enumerate e.g. capture device nodes. Few applications will do a full scan of the whole topology. Instead they will just specify the unique entity ID and if needed the input/output ID as well. These IDs are declared in the board or sub-device specific header. Very good this topology-idea! I can even see this to be continued in user-space in a very smart application/library: A software MPEG decoder/rescaler whatever would be such an entity for example. A full enumeration will typically only be done by some sort of generic application like v4l2-ctl. Hmm... I'm seeing this idea covering other stream-oriented devices. Like sound-cards (*ouch*). [..] Open issues === In no particular order: 1) How to tell the application that this board uses an audio loopback cable to the PC's audio input? 2) There can be a lot of device nodes in complicated boards. One suggestion is to only register them when they are linked to an entity (i.e. can be active). Should we do this or not? Could entities not be completely addressed (configuration ioctls) through the mc-node? Only entities who have an output/input with is of type 'user-space-interface' are actually having a node where the user (in user-space) can read from/write to? 3) Format and bus configuration and enumeration. Sub-devices are connected together by a bus. These busses can have different configurations that will influence the list of possible formats that can be received or sent from device nodes. This was always pretty straightforward, but if you have several sub-devices such as scalers and colorspace converters in a pipeline then this becomes very complex indeed. This is already a problem with soc-camera, but that is only the tip of the iceberg. How to solve this problem is something that requires a lot more thought. For me the entities (components) you're describing are having 2 basic bus-types: one control bus (which gives register access) and one or more data-stream buses. In your topology I understood that the inputs/outputs are exactly representing the data-stream buses. Depending on the main-type of the media controller a library could give some basic-models of how all entities can be connected together. EG: (I have no clue about webcams, that why I use this as an example :) ): Webcam: sensor + resize + filtering = picture WEBCAM model X provides: 2 sensor-types + 3 resizers + 5 filters one of each of it provides a pictures. By default this first one of each is taken. [..] My additional comments for DTV 1) In DTV as of today we can't handle a feature which becomes more and
Re: LinuxTV firmware blocks all wireless connections / traffic
> > Here is a test case: > Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 -- 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.linuxtv.org/hg/~hverkuil/v4l-dvb-core
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core for the following: - v4l2-dev: replace 'kernel number' by 'device node number'. - ivtv/cx18: replace 'kernel number' with 'device node number'. - v4l2-dev: add simple wrapper functions around the devnode numbers - v4l: warn when desired devnodenr is in use & add _no_warn function These four patches fix some known confusing parts of the v4l core. They are easily reviewable and are for the most part trivial. I have another patch pending that cleans up more code, but I do not know whether I will have time to get that into shape before the 2.6.32 merge window closes. I didn't want to wait for that, so I'm pushing this out now. Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt | 28 -- drivers/media/video/cx18/cx18-driver.c |2 drivers/media/video/cx18/cx18-streams.c |4 drivers/media/video/ivtv/ivtv-driver.c |2 drivers/media/video/ivtv/ivtv-streams.c |4 drivers/media/video/v4l2-dev.c | 113 +-- include/media/v4l2-dev.h |4 7 files changed, 117 insertions(+), 40 deletions(-) -- 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: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 12:58:07PM +0200, Markus Rechberger wrote: > On Thu, Sep 10, 2009 at 11:14 AM, Aleksandr V. Piskunov > wrote: > > On Wed, Sep 09, 2009 at 05:59:07PM -0400, Devin Heitmueller wrote: > >> On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyer > >> wrote: > >> > Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC > >> > OTA TV. > >> > > >> > Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE > >> > 3.5.10, kernel 2.6.27-1-mepis-smp > >> > > >> > All three machines now have wireless blocked, either do not connect or > >> > all packets dropped/blocked if a connection is made. > >> > > >> > Used the resources from LinuxTV (dot) org > >> > > >> > to get it working, they are referenced and posted as follows: > >> > linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware > >> > > >> > *** ** > >> > Quote: > >> > In order to use the LinuxTV driver, you need to download and install > >> > the firmware for the xc5000. > >> > > >> > Quote: > >> > wget ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip > >> > wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh > >> > sh extract (dot) sh > >> > cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware > >> > :Unquote > >> > > >> > Note: Though the usual directory location in which the firmware file > >> > is placed is /lib/firmware, this may differ in the case of some > >> > distros; consult your distro's documentation for the appropriate > >> > location. > >> > > >> > The firmware will be added lazily (on-demand) when you first use the > >> > driver. > >> > Drivers > >> > > >> > The xc5000 driver needed for this WinTV-HVR-950Q is already part of > >> > the latest Linux kernel (part of v4l-dvb drivers). > >> > > >> > Analog support was merged into the mainline v4l-dvb tree on March 18, > >> > 2009. > >> > :Unquote > >> > *** ** *** ** > >> > So on Saturday I got this up and running... and Sunday morning > >> > recorded one show successfully that had set up on a timer. > >> > > >> > Then set up three consecutive shows for the afternoon. > >> > They were all part of a series on the same channel. Here are the results: > >> > > >> > * Show A, 2.5 hours long, 13.2gb file size, appears to be OK. > >> > * Show B, 2.0 hours long, 3.7gb file size, appears to be OK. > >> > * Show C, supposed to be 2.0 hours long, result was 2.7gb file > >> > size, about the first hour is missing. > >> > > >> > At about this point, I lost wireless internet connectivity on TV > >> > recording laptop. Machine sees the access point, but won't connect. > >> > > >> > Went to my main desktop where i had first worked with this Hauppauge > >> > WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost > >> > internet, even though it was right next to AP and got a very good > >> > signal. > >> > > >> > Thought it was maybe the AP, so switched it out for a working spare. > >> > Same results. > >> > Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD > >> > and an 8.06 Live USB stick and hit the road to go to a reliable high > >> > speed wifi spot. > >> > Same results... changins ISPs resulted in the same issues. > >> > Also same ting happened with the spare laptop, an IBM T43 Thinkpad I > >> > had also done the "wget ... steventoth (dot) > >> > net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip" > >> > firmware thing to. > >> > > >> > Was able to get one machine, while running a LIVE USB session, to > >> > connect, but zero packets received.. ALL were blocked. The connection > >> > information said ALL packets were dropped. > >> > None of the two other machines connected to wireless on a LiveCD or > >> > LiveUSB thing too > >> > Three machines. All different brands (HP, Dell, and IBM) with > >> > different wifi cards. All three see the access point ESSID, but none > >> > connect. > >> > > >> > This does not *feel* good. What got flashed? Can this be resolved? > >> > > >> > Came home. No difference. Grabbed a laptop that i had NOT done the > >> > firmware thing to and that is what I am using to write this. Hooked > >> > right up to the AP. > >> > > >> > Please help... that is too much hardware disabled for me to think calmly. > >> > I'd really like to make the USB tv tuner work... what a great way to > >> > PVR / DVR, but I need wireless. > >> > > >> > Can provide any details requested to drive this towards a fix! > >> > > >> > Thank you, > >> > Clinton > >> > -- > >> > 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 > >> > > >> > >> Hello Clinton, > >> > >> That is indeed curious. It's hard to imagine how there could be > >> interference between the V4L subsystem and the wireless subsystem, > >> short of hitting some sort of timing condition on crappy wireless >
[RESEND PULL] http://kernellabs.com/hg/~mkrufky/tda18271-standby
Mauro, I have some other pull requests that depend on this being merged first. (Zolid saa7134 support, DTV1000S, etc) I am waiting for these to be merged first so as to avoid a patch clash. Please merge this tree so that I can go ahead and prepare the others for merge next. Please note, these changesets are crucial for multiple instance / hybrid devices that use the tda18271 tuner. Please pull from: http://kernellabs.com/hg/~mkrufky/tda18271-standby for the following changesets: - tda18271: add support for additional low-power standby modes - tda18271: add debug to show which standby mode is in use - tda18271: add new standby mode: slave tuner output / loop thru on - tda18271: change output feature configuration to a bitmask - tda18271: move tda18271_sleep directly below tda18271_init - tda18271: move small_i2c assignment to the state config block - tda18271: ensure that configuration options are set for multiple instances - tda18271: improve error log in function tda18271_write_regs - tda18271: fix comments and make tda18271_agc debug less verbose - merge: ~mkrufky/tda18271 - saa7134: disable tda18271 slave tuner output / loop thru in standby mode - pvrusb2: disable tda18271 slave tuner output / loop thru in standby mode - cx23885: disable tda18271 slave tuner output / loop thru in standby mode common/tuners/tda18271-common.c |6 common/tuners/tda18271-fe.c | 226 +--- common/tuners/tda18271-priv.h | 22 + common/tuners/tda18271.h| 55 +++- video/cx23885/cx23885-dvb.c |4 video/pvrusb2/pvrusb2-devattr.c |2 video/saa7134/saa7134-dvb.c |1 7 files changed, 218 insertions(+), 98 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
[PATCH] add support for IR on FlyDVB Trio (saa7134)
Hi all, here is patch for driver saa7134, that add support for IR reciever
on card LifeView FlyDVB Trio.
I tested it on kernel 2.6.30
Signed-off-by: Lukas Karas
diff -uprN video.13c47deee3b1/ir-kbd-i2c.c video/ir-kbd-i2c.c
--- video.13c47deee3b1/ir-kbd-i2c.c 2009-09-07 15:38:46.0 +0200
+++ video/ir-kbd-i2c.c 2009-09-08 22:23:34.0 +0200
@@ -438,6 +438,7 @@ static int ir_probe(struct i2c_client *c
ir_type = IR_TYPE_RC5;
ir_codes= &ir_codes_fusionhdtv_mce_table;
break;
+ case 0x0b:
case 0x7a:
case 0x47:
case 0x71:
@@ -467,7 +468,7 @@ static int ir_probe(struct i2c_client *c
ir_codes= &ir_codes_avermedia_cardbus_table;
break;
default:
- dprintk(1, DEVNAME ": Unsupported i2c address 0x%02x\n", addr);
+ dprintk(1, "Unsupported i2c address 0x%02x\n", addr);
err = -ENODEV;
goto err_out_free;
}
@@ -514,7 +515,7 @@ static int ir_probe(struct i2c_client *c
/* Make sure we are all setup before going on */
if (!name || !ir->get_key || !ir_codes) {
- dprintk(1, DEVNAME ": Unsupported device at address 0x%02x\n",
+ dprintk(1, "Unsupported device at address 0x%02x\n",
addr);
err = -ENODEV;
goto err_out_free;
@@ -722,6 +723,30 @@ static int ir_probe(struct i2c_adapter *
ir_attach(adap, msg[0].addr, 0, 0);
}
+ /* special case for LifeView FlyDVB Trio */
+ if (adap->id == I2C_HW_SAA7134) {
+ u8 temp = 0;
+ msg.buf = &temp;
+ msg.addr = 0x0b;
+ msg.len = 1;
+ msg.flags = 0;
+
+ /* send weak up message to pic16C505 chip @ LifeView FlyDVB
Trio */
+ if (1 != i2c_transfer(adap,&msg,1)) {
+ dprintk(1,"send wake up byte to pic16C505 failed\n");
+ }else{
+ msg.flags = I2C_M_RD;
+ rc = i2c_transfer(adap, &msg, 1);
+ dprintk(1, "probe 0x%02x @ %s: %s\n",
+ msg.addr, adap->name,
+ (1 == rc) ? "yes" : "no");
+ if (1 == rc)
+ ir_attach(adap, msg.addr, 0, 0);
+ }
+ msg.len = 0;
+ msg.flags = I2C_M_RD;
+ }
+
return 0;
}
#else
diff -uprN video.13c47deee3b1/saa7134/saa7134-cards.c video/saa7134/saa7134-
cards.c
--- video.13c47deee3b1/saa7134/saa7134-cards.c 2009-09-07 15:38:46.0
+0200
+++ video/saa7134/saa7134-cards.c 2009-09-09 00:45:09.0 +0200
@@ -7212,9 +7212,27 @@ int saa7134_board_init2(struct saa7134_d
}
case SAA7134_BOARD_FLYDVB_TRIO:
{
+ u8 temp = 0;
+ int rc;
u8 data[] = { 0x3c, 0x33, 0x62};
struct i2c_msg msg = {.addr=0x09, .flags=0, .buf=data, .len =
sizeof(data)};
i2c_transfer(&dev->i2c_adap, &msg, 1);
+
+ /* send weak up message to pic16C505 chip @ LifeView FlyDVB
Trio */
+ msg.buf = &temp;
+ msg.addr = 0x0b;
+ msg.len = 1;
+ if (1 != i2c_transfer(&dev->i2c_adap,&msg,1)) {
+ printk(KERN_WARNING "%s: send wake up byte to pic16C505
+ (IR chip) failed\n", dev->name);
+ }else{
+ msg.flags = I2C_M_RD;
+ rc = i2c_transfer(&dev->i2c_adap, &msg, 1);
+ printk(KERN_INFO "%s: probe IR chip @ i2c 0x%02x: %s\n",
+ dev->name, msg.addr,(1 == rc) ? "yes" :
"no");
+ if (rc == 1)
+ dev->has_remote = SAA7134_REMOTE_I2C;
+ }
break;
}
case SAA7134_BOARD_ADS_DUO_CARDBUS_PTV331:
diff -uprN video.13c47deee3b1/saa7134/saa7134-input.c video/saa7134/saa7134-
input.c
--- video.13c47deee3b1/saa7134/saa7134-input.c 2009-09-07 15:38:46.0
+0200
+++ video/saa7134/saa7134-input.c 2009-09-08 22:56:02.0 +0200
@@ -132,6 +132,72 @@ static int build_key(struct saa7134_dev
/* - Chip specific I2C key builders - */
+static int get_key_flydvb_trio(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
+{
+ int gpio;
+ int attempt = 0;
+ unsigned char b;
+
+ /* We need this to access GPI Used by the saa_readl macro. */
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 30)
+ struct saa7134_dev *dev = ir->c.adapter->algo_data;
+#else
+ struct saa7134_dev *dev = ir->c->adapter->algo_data;
+#endif
+
+ if (dev == NULL) {
+ d
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 11:14 AM, Aleksandr V. Piskunov wrote: > On Wed, Sep 09, 2009 at 05:59:07PM -0400, Devin Heitmueller wrote: >> On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyer >> wrote: >> > Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC >> > OTA TV. >> > >> > Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE >> > 3.5.10, kernel 2.6.27-1-mepis-smp >> > >> > All three machines now have wireless blocked, either do not connect or >> > all packets dropped/blocked if a connection is made. >> > >> > Used the resources from LinuxTV (dot) org >> > >> > to get it working, they are referenced and posted as follows: >> > linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware >> > >> > *** ** >> > Quote: >> > In order to use the LinuxTV driver, you need to download and install >> > the firmware for the xc5000. >> > >> > Quote: >> > wget ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip >> > wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh >> > sh extract (dot) sh >> > cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware >> > :Unquote >> > >> > Note: Though the usual directory location in which the firmware file >> > is placed is /lib/firmware, this may differ in the case of some >> > distros; consult your distro's documentation for the appropriate >> > location. >> > >> > The firmware will be added lazily (on-demand) when you first use the >> > driver. >> > Drivers >> > >> > The xc5000 driver needed for this WinTV-HVR-950Q is already part of >> > the latest Linux kernel (part of v4l-dvb drivers). >> > >> > Analog support was merged into the mainline v4l-dvb tree on March 18, 2009. >> > :Unquote >> > *** ** *** ** >> > So on Saturday I got this up and running... and Sunday morning >> > recorded one show successfully that had set up on a timer. >> > >> > Then set up three consecutive shows for the afternoon. >> > They were all part of a series on the same channel. Here are the results: >> > >> > * Show A, 2.5 hours long, 13.2gb file size, appears to be OK. >> > * Show B, 2.0 hours long, 3.7gb file size, appears to be OK. >> > * Show C, supposed to be 2.0 hours long, result was 2.7gb file >> > size, about the first hour is missing. >> > >> > At about this point, I lost wireless internet connectivity on TV >> > recording laptop. Machine sees the access point, but won't connect. >> > >> > Went to my main desktop where i had first worked with this Hauppauge >> > WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost >> > internet, even though it was right next to AP and got a very good >> > signal. >> > >> > Thought it was maybe the AP, so switched it out for a working spare. >> > Same results. >> > Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD >> > and an 8.06 Live USB stick and hit the road to go to a reliable high >> > speed wifi spot. >> > Same results... changins ISPs resulted in the same issues. >> > Also same ting happened with the spare laptop, an IBM T43 Thinkpad I >> > had also done the "wget ... steventoth (dot) >> > net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip" >> > firmware thing to. >> > >> > Was able to get one machine, while running a LIVE USB session, to >> > connect, but zero packets received.. ALL were blocked. The connection >> > information said ALL packets were dropped. >> > None of the two other machines connected to wireless on a LiveCD or >> > LiveUSB thing too >> > Three machines. All different brands (HP, Dell, and IBM) with >> > different wifi cards. All three see the access point ESSID, but none >> > connect. >> > >> > This does not *feel* good. What got flashed? Can this be resolved? >> > >> > Came home. No difference. Grabbed a laptop that i had NOT done the >> > firmware thing to and that is what I am using to write this. Hooked >> > right up to the AP. >> > >> > Please help... that is too much hardware disabled for me to think calmly. >> > I'd really like to make the USB tv tuner work... what a great way to >> > PVR / DVR, but I need wireless. >> > >> > Can provide any details requested to drive this towards a fix! >> > >> > Thank you, >> > Clinton >> > -- >> > 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 >> > >> >> Hello Clinton, >> >> That is indeed curious. It's hard to imagine how there could be >> interference between the V4L subsystem and the wireless subsystem, >> short of hitting some sort of timing condition on crappy wireless >> drivers. >> >> Here are a few questions: >> >> 1. You specified you followed the instructions for the firmware, but >> are you running the current v4l-dvb code, or are you just using >> whatever came with your Debian kernel? If you're actually using the >> 1.1 Xceive firmware, I'm assuming
Re: Nova-T 500 Dual DVB-T and h.264
2009/9/10 Lou Otway : > Eduard Huguet wrote: >> >> 2009/9/10 Lou Otway : >>> >>> Eduard Huguet wrote: 2009/9/10 Lou Otway : > > Eduard Huguet wrote: >> >> Lou Otway nildram.co.uk> writes: >> >>> Hi, >>> >>> Does anyone have experience of using the Hauppuage Nova-T 500 with >>> DVB-T >>> broadcasts with h.264 and AAC audio? >>> >>> DTT in New Zealand uses these formats and I'm seeing poor performance >>> from the Nova-T card. My thinking is that it was probably not >>> conceived >>> for >>> dealing with dual h264 streams. >>> >>> Has the PCIe HVR-2200 been tested with dual h.264? I was wondering if >>> this card might have better performance. >>> >>> Thanks, >>> >>> Lou >> >> Hi,AFAIK the card just tunes to the desired frequency, applies >> configured >> filters (to select the desired station through its PID number), and >> handles the >> received transport stream to the calling application. It's up to the >> lastest to >> properly decode it. Check that the software you are using is properly >> capable of >> decoding this kind of content. >> >> Best regards, Eduard Huguet > > Hi, > > the problem isn't to do with playback as I have another type of adapter > card > that creates a TS, from the same mux, that is played back with no > problem. > > It seems that the problem only happens when using the Nova-T card. > > DTT in NZ has services with 1080i video format, I'm not sure that there > are > many other places in the world where 1080i h.264 content is broadcast > using > DVB-T, hence I was thinking that this combination may not have been > well > tested. > > Thanks, > > Lou > I don't know how this it works in NZ. Here in Spain there is at least one station (TVC's 3HD) emitting HD content through TDT, and it works flawlessly with a Nova-T 500 (as I have one). I'm not sure if contents are 1080 or 720, though. There were some problems watching these channels through MythTV, but they were definitely decoding related. With current MythTV trunk they are fine. Anyway, as I said before, theoretically a DVB card doesn't know what kind of streams contains the signal it tunes. Decoding & parsing is handled by the app. Best regards, Eduard Huguet -- >>> >>> I'm not using MythTV or any other type of Media playing application. >>> >>> In any case, I see very different performance between the two different >>> types of card, when presented with the same input. >>> >>> I'll gather some more data, if I can draw any new conclusions I'll update >>> the list. >>> >>> Best, >>> >>> Lou >>> >>> >>> >> >> Maybe it's a problem of tuner sensibility. Is the low noise amplifier >> (LNA) activated for the Nova-T card? >> regards >> Eduard >> -- > > That's something I hadn't considered. I'll check but I thought that the LNA > was only applicable to the Nova-TD 500 (which has 2xRF inputs)? > > Does the Nova-T 500, with only a single RF input have the LNA? > > Thanks, > > Lou > I don't know about the TD, but the regular Nova-T 500 definitely has a LNA that must be activated, that's for sure :D... Best regards, Eduard -- 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: Nova-T 500 Dual DVB-T and h.264
Eduard Huguet wrote: 2009/9/10 Lou Otway : Eduard Huguet wrote: 2009/9/10 Lou Otway : Eduard Huguet wrote: Lou Otway nildram.co.uk> writes: Hi, Does anyone have experience of using the Hauppuage Nova-T 500 with DVB-T broadcasts with h.264 and AAC audio? DTT in New Zealand uses these formats and I'm seeing poor performance from the Nova-T card. My thinking is that it was probably not conceived for dealing with dual h264 streams. Has the PCIe HVR-2200 been tested with dual h.264? I was wondering if this card might have better performance. Thanks, Lou Hi,AFAIK the card just tunes to the desired frequency, applies configured filters (to select the desired station through its PID number), and handles the received transport stream to the calling application. It's up to the lastest to properly decode it. Check that the software you are using is properly capable of decoding this kind of content. Best regards, Eduard Huguet Hi, the problem isn't to do with playback as I have another type of adapter card that creates a TS, from the same mux, that is played back with no problem. It seems that the problem only happens when using the Nova-T card. DTT in NZ has services with 1080i video format, I'm not sure that there are many other places in the world where 1080i h.264 content is broadcast using DVB-T, hence I was thinking that this combination may not have been well tested. Thanks, Lou I don't know how this it works in NZ. Here in Spain there is at least one station (TVC's 3HD) emitting HD content through TDT, and it works flawlessly with a Nova-T 500 (as I have one). I'm not sure if contents are 1080 or 720, though. There were some problems watching these channels through MythTV, but they were definitely decoding related. With current MythTV trunk they are fine. Anyway, as I said before, theoretically a DVB card doesn't know what kind of streams contains the signal it tunes. Decoding & parsing is handled by the app. Best regards, Eduard Huguet -- I'm not using MythTV or any other type of Media playing application. In any case, I see very different performance between the two different types of card, when presented with the same input. I'll gather some more data, if I can draw any new conclusions I'll update the list. Best, Lou Maybe it's a problem of tuner sensibility. Is the low noise amplifier (LNA) activated for the Nova-T card? regards Eduard -- That's something I hadn't considered. I'll check but I thought that the LNA was only applicable to the Nova-TD 500 (which has 2xRF inputs)? Does the Nova-T 500, with only a single RF input have the LNA? Thanks, Lou -- 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: Nova-T 500 Dual DVB-T and h.264
2009/9/10 Lou Otway : > Eduard Huguet wrote: >> >> 2009/9/10 Lou Otway : >>> >>> Eduard Huguet wrote: Lou Otway nildram.co.uk> writes: > Hi, > > Does anyone have experience of using the Hauppuage Nova-T 500 with > DVB-T > broadcasts with h.264 and AAC audio? > > DTT in New Zealand uses these formats and I'm seeing poor performance > from the Nova-T card. My thinking is that it was probably not conceived > for > dealing with dual h264 streams. > > Has the PCIe HVR-2200 been tested with dual h.264? I was wondering if > this card might have better performance. > > Thanks, > > Lou Hi,AFAIK the card just tunes to the desired frequency, applies configured filters (to select the desired station through its PID number), and handles the received transport stream to the calling application. It's up to the lastest to properly decode it. Check that the software you are using is properly capable of decoding this kind of content. Best regards, Eduard Huguet >>> >>> Hi, >>> >>> the problem isn't to do with playback as I have another type of adapter >>> card >>> that creates a TS, from the same mux, that is played back with no >>> problem. >>> >>> It seems that the problem only happens when using the Nova-T card. >>> >>> DTT in NZ has services with 1080i video format, I'm not sure that there >>> are >>> many other places in the world where 1080i h.264 content is broadcast >>> using >>> DVB-T, hence I was thinking that this combination may not have been well >>> tested. >>> >>> Thanks, >>> >>> Lou >>> >> >> I don't know how this it works in NZ. Here in Spain there is at least >> one station (TVC's 3HD) emitting HD content through TDT, and it works >> flawlessly with a Nova-T 500 (as I have one). I'm not sure if contents >> are 1080 or 720, though. >> >> There were some problems watching these channels through MythTV, but >> they were definitely decoding related. With current MythTV trunk they >> are fine. >> >> Anyway, as I said before, theoretically a DVB card doesn't know what >> kind of streams contains the signal it tunes. Decoding & parsing is >> handled by the app. >> >> Best regards, >> Eduard Huguet >> -- > > I'm not using MythTV or any other type of Media playing application. > > In any case, I see very different performance between the two different > types of card, when presented with the same input. > > I'll gather some more data, if I can draw any new conclusions I'll update > the list. > > Best, > > Lou > > > Maybe it's a problem of tuner sensibility. Is the low noise amplifier (LNA) activated for the Nova-T card? regards Eduard -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Wed, Sep 09, 2009 at 05:59:07PM -0400, Devin Heitmueller wrote: > On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyer wrote: > > Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC > > OTA TV. > > > > Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE > > 3.5.10, kernel 2.6.27-1-mepis-smp > > > > All three machines now have wireless blocked, either do not connect or > > all packets dropped/blocked if a connection is made. > > > > Used the resources from LinuxTV (dot) org > > > > to get it working, they are referenced and posted as follows: > > linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware > > > > *** ** > > Quote: > > In order to use the LinuxTV driver, you need to download and install > > the firmware for the xc5000. > > > > Quote: > > wget ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip > > wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh > > sh extract (dot) sh > > cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware > > :Unquote > > > > Note: Though the usual directory location in which the firmware file > > is placed is /lib/firmware, this may differ in the case of some > > distros; consult your distro's documentation for the appropriate > > location. > > > > The firmware will be added lazily (on-demand) when you first use the driver. > > Drivers > > > > The xc5000 driver needed for this WinTV-HVR-950Q is already part of > > the latest Linux kernel (part of v4l-dvb drivers). > > > > Analog support was merged into the mainline v4l-dvb tree on March 18, 2009. > > :Unquote > > *** ** *** ** > > So on Saturday I got this up and running... and Sunday morning > > recorded one show successfully that had set up on a timer. > > > > Then set up three consecutive shows for the afternoon. > > They were all part of a series on the same channel. Here are the results: > > > > * Show A, 2.5 hours long, 13.2gb file size, appears to be OK. > > * Show B, 2.0 hours long, 3.7gb file size, appears to be OK. > > * Show C, supposed to be 2.0 hours long, result was 2.7gb file > > size, about the first hour is missing. > > > > At about this point, I lost wireless internet connectivity on TV > > recording laptop. Machine sees the access point, but won't connect. > > > > Went to my main desktop where i had first worked with this Hauppauge > > WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost > > internet, even though it was right next to AP and got a very good > > signal. > > > > Thought it was maybe the AP, so switched it out for a working spare. > > Same results. > > Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD > > and an 8.06 Live USB stick and hit the road to go to a reliable high > > speed wifi spot. > > Same results... changins ISPs resulted in the same issues. > > Also same ting happened with the spare laptop, an IBM T43 Thinkpad I > > had also done the "wget ... steventoth (dot) > > net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip" > > firmware thing to. > > > > Was able to get one machine, while running a LIVE USB session, to > > connect, but zero packets received.. ALL were blocked. The connection > > information said ALL packets were dropped. > > None of the two other machines connected to wireless on a LiveCD or > > LiveUSB thing too > > Three machines. All different brands (HP, Dell, and IBM) with > > different wifi cards. All three see the access point ESSID, but none > > connect. > > > > This does not *feel* good. What got flashed? Can this be resolved? > > > > Came home. No difference. Grabbed a laptop that i had NOT done the > > firmware thing to and that is what I am using to write this. Hooked > > right up to the AP. > > > > Please help... that is too much hardware disabled for me to think calmly. > > I'd really like to make the USB tv tuner work... what a great way to > > PVR / DVR, but I need wireless. > > > > Can provide any details requested to drive this towards a fix! > > > > Thank you, > > Clinton > > -- > > 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 > > > > Hello Clinton, > > That is indeed curious. It's hard to imagine how there could be > interference between the V4L subsystem and the wireless subsystem, > short of hitting some sort of timing condition on crappy wireless > drivers. > > Here are a few questions: > > 1. You specified you followed the instructions for the firmware, but > are you running the current v4l-dvb code, or are you just using > whatever came with your Debian kernel? If you're actually using the > 1.1 Xceive firmware, I'm assuming you're still using the old code. > > 2. How reproducible is this? Does it occur even if the device is > connected but you do not attempt any capturing with the device? Does > it alw
Re: Nova-T 500 Dual DVB-T and h.264
Eduard Huguet wrote: 2009/9/10 Lou Otway : Eduard Huguet wrote: Lou Otway nildram.co.uk> writes: Hi, Does anyone have experience of using the Hauppuage Nova-T 500 with DVB-T broadcasts with h.264 and AAC audio? DTT in New Zealand uses these formats and I'm seeing poor performance from the Nova-T card. My thinking is that it was probably not conceived for dealing with dual h264 streams. Has the PCIe HVR-2200 been tested with dual h.264? I was wondering if this card might have better performance. Thanks, Lou Hi,AFAIK the card just tunes to the desired frequency, applies configured filters (to select the desired station through its PID number), and handles the received transport stream to the calling application. It's up to the lastest to properly decode it. Check that the software you are using is properly capable of decoding this kind of content. Best regards, Eduard Huguet Hi, the problem isn't to do with playback as I have another type of adapter card that creates a TS, from the same mux, that is played back with no problem. It seems that the problem only happens when using the Nova-T card. DTT in NZ has services with 1080i video format, I'm not sure that there are many other places in the world where 1080i h.264 content is broadcast using DVB-T, hence I was thinking that this combination may not have been well tested. Thanks, Lou I don't know how this it works in NZ. Here in Spain there is at least one station (TVC's 3HD) emitting HD content through TDT, and it works flawlessly with a Nova-T 500 (as I have one). I'm not sure if contents are 1080 or 720, though. There were some problems watching these channels through MythTV, but they were definitely decoding related. With current MythTV trunk they are fine. Anyway, as I said before, theoretically a DVB card doesn't know what kind of streams contains the signal it tunes. Decoding & parsing is handled by the app. Best regards, Eduard Huguet -- I'm not using MythTV or any other type of Media playing application. In any case, I see very different performance between the two different types of card, when presented with the same input. I'll gather some more data, if I can draw any new conclusions I'll update the list. Best, Lou -- 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: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support
Still rambling about it :)
i was just comparing the instant TV dvb-t pci keymap with what i got
for the instant tv pci :
dvb-t
{ 0x4d, KEY_0 },
{ 0x57, KEY_1 },
{ 0x4f, KEY_2 },
{ 0x53, KEY_3 },
{ 0x56, KEY_4 },
{ 0x4e, KEY_5 },
{ 0x5e, KEY_6 },
{ 0x54, KEY_7 },
{ 0x4c, KEY_8 },
{ 0x5c, KEY_9 },
pci
{ 0xd, KEY_0 },
{ 0x17, KEY_1 },
{ 0xf, KEY_2 },
{ 0x13, KEY_3 },
{ 0x16, KEY_4 },
{ 0xe, KEY_5 },
{ 0x1e, KEY_6 },
{ 0x14, KEY_7 },
{ 0xc, KEY_8 },
{ 0x1c, KEY_9 },
if manufacturers are half as lazy as i am, and since the remote is the
same ( or at least looks the same ), it looks like i am indeed missing
part of the gpio. ( no mark, got the output with ir_debug=1 )
now for the rest of the keys :
dvb-t
{ 0x5b, KEY_POWER },
{ 0x5f, KEY_MUTE },
{ 0x55, KEY_GOTO },
{ 0x5d, KEY_SEARCH },
{ 0x17, KEY_EPG },/* Guide */
{ 0x1f, KEY_MENU },
{ 0x0f, KEY_UP },
{ 0x46, KEY_DOWN },
{ 0x16, KEY_LEFT },
{ 0x1e, KEY_RIGHT },
{ 0x0e, KEY_SELECT },/* Enter */
{ 0x5a, KEY_INFO },
{ 0x52, KEY_EXIT },
{ 0x59, KEY_PREVIOUS },
{ 0x51, KEY_NEXT },
{ 0x58, KEY_REWIND },
{ 0x50, KEY_FORWARD },
{ 0x44, KEY_PLAYPAUSE },
{ 0x07, KEY_STOP },
{ 0x1b, KEY_RECORD },
{ 0x13, KEY_TUNER },/* Live */
{ 0x0a, KEY_A },
{ 0x12, KEY_B },
{ 0x03, KEY_PROG1 },/* 1 */
{ 0x01, KEY_PROG2 },/* 2 */
{ 0x00, KEY_PROG3 },/* 3 */
{ 0x06, KEY_DVD },
{ 0x48, KEY_AUX },/* Photo */
{ 0x40, KEY_VIDEO },
{ 0x19, KEY_AUDIO },/* Music */
{ 0x0b, KEY_CHANNELUP },
{ 0x08, KEY_CHANNELDOWN },
{ 0x15, KEY_VOLUMEUP },
{ 0x1c, KEY_VOLUMEDOWN },
pci
{ 0x1b, KEY_POWER },
{ 0x1f, KEY_MUTE },
{ 0x15, KEY_GOTO },
{ 0x1d, KEY_SEARCH },
{ 0x17, KEY_EPG },/* Guide */
{ 0x1f, KEY_MENU },
{ 0x0f, KEY_UP },
{ 0x6, KEY_DOWN },
{ 0x16, KEY_LEFT },
{ 0x1e, KEY_RIGHT },
{ 0x0e, KEY_SELECT },/* Enter */
{ 0x1a, KEY_INFO },
{ 0x12, KEY_EXIT },
{ 0x19, KEY_PREVIOUS },
{ 0x11, KEY_NEXT },
{ 0x18, KEY_REWIND },
{ 0x10, KEY_FORWARD },
{ 0x4, KEY_PLAYPAUSE },
{ 0x07, KEY_STOP },
{ 0x1b, KEY_RECORD },
{ 0x13, KEY_TUNER },/* Live */
{ 0x0a, KEY_A },
{ 0x12, KEY_B },
{ 0x03, KEY_PROG1 },/* 1 */
{ 0x01, KEY_PROG2 },/* 2 */
{ 0x00, KEY_PROG3 },/* 3 */
{ 0x06, KEY_DVD },
{ 0x8, KEY_AUX },/* Photo */
{ 0x0, KEY_VIDEO },
{ 0x19, KEY_AUDIO },/* Music */
{ 0x0b, KEY_CHANNELUP },
{ 0x08, KEY_CHANNELDOWN },
{ 0x15, KEY_VOLUMEUP },
{ 0x1c, KEY_VOLUMEDOWN },
as you can see, for most of the keycodes, i am missing 0x40, which mean
i am missing one bit.
And i don't even know where i should start looking to solve that problem.
thanks for any help/solution.
Morvan Le Meut a écrit :
I don't know if i mentioned it before but something i find strange is
" saa7134 IR (ADS Tech Instant TV: unknown key: key=0x00 raw=0x00
down=1" as soon as the module is loaded.
--
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: Nova-T 500 Dual DVB-T and h.264
2009/9/10 Lou Otway : > Eduard Huguet wrote: >> >> Lou Otway nildram.co.uk> writes: >> >>> Hi, >>> >>> Does anyone have experience of using the Hauppuage Nova-T 500 with DVB-T >>> broadcasts with h.264 and AAC audio? >>> >>> DTT in New Zealand uses these formats and I'm seeing poor performance >>> from the Nova-T card. My thinking is that it was probably not conceived for >>> dealing with dual h264 streams. >>> >>> Has the PCIe HVR-2200 been tested with dual h.264? I was wondering if >>> this card might have better performance. >>> >>> Thanks, >>> >>> Lou >> >> >> Hi,AFAIK the card just tunes to the desired frequency, applies >> configured >> filters (to select the desired station through its PID number), and >> handles the >> received transport stream to the calling application. It's up to the >> lastest to >> properly decode it. Check that the software you are using is properly >> capable of >> decoding this kind of content. >> >> Best regards, Eduard Huguet > > > Hi, > > the problem isn't to do with playback as I have another type of adapter card > that creates a TS, from the same mux, that is played back with no problem. > > It seems that the problem only happens when using the Nova-T card. > > DTT in NZ has services with 1080i video format, I'm not sure that there are > many other places in the world where 1080i h.264 content is broadcast using > DVB-T, hence I was thinking that this combination may not have been well > tested. > > Thanks, > > Lou > > > > > I don't know how this it works in NZ. Here in Spain there is at least one station (TVC's 3HD) emitting HD content through TDT, and it works flawlessly with a Nova-T 500 (as I have one). I'm not sure if contents are 1080 or 720, though. There were some problems watching these channels through MythTV, but they were definitely decoding related. With current MythTV trunk they are fine. Anyway, as I said before, theoretically a DVB card doesn't know what kind of streams contains the signal it tunes. Decoding & parsing is handled by the app. Best regards, Eduard Huguet -- 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: Nova-T 500 Dual DVB-T and h.264
Eduard Huguet wrote: Lou Otway nildram.co.uk> writes: Hi, Does anyone have experience of using the Hauppuage Nova-T 500 with DVB-T broadcasts with h.264 and AAC audio? DTT in New Zealand uses these formats and I'm seeing poor performance from the Nova-T card. My thinking is that it was probably not conceived for dealing with dual h264 streams. Has the PCIe HVR-2200 been tested with dual h.264? I was wondering if this card might have better performance. Thanks, Lou Hi, AFAIK the card just tunes to the desired frequency, applies configured filters (to select the desired station through its PID number), and handles the received transport stream to the calling application. It's up to the lastest to properly decode it. Check that the software you are using is properly capable of decoding this kind of content. Best regards, Eduard Huguet Hi, the problem isn't to do with playback as I have another type of adapter card that creates a TS, from the same mux, that is played back with no problem. It seems that the problem only happens when using the Nova-T card. DTT in NZ has services with 1080i video format, I'm not sure that there are many other places in the world where 1080i h.264 content is broadcast using DVB-T, hence I was thinking that this combination may not have been well tested. Thanks, Lou -- 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 2/2] stv06xx webcams with HDCS 1xxx sensors
2009/9/9 James Blanford :
> Quickcam Express 046d:0840 and maybe others
>
> Driver version: v 2.60 from 2.6.31-rc7
>
> Due to rounding and clipping, exposure and gain settings do not map to
> unique register values. Rather than read the registers and report gain
> and exposure that may be different than the values that were set, just
> cache the latest values that were set and report them. Reduce exposure
> range from 0-65535 to 0-255 so libv4l's autogain doesn't take forever.
> Remove vestiges of driver signal processing that is now handled by
> libv4l.
>
> Signed-off-by: James Blanford
> diff -upr a/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c
> b/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c
> --- a/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c 2009-09-09
> 14:59:35.0 -0400
> +++ b/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c 2009-09-09
> 16:30:08.0 -0400
> @@ -37,7 +37,7 @@ static const struct ctrl hdcs1x00_ctrl[]
> .type = V4L2_CTRL_TYPE_INTEGER,
> .name = "exposure",
> .minimum = 0x00,
> - .maximum = 0x,
> + .maximum = 0xff,
> .step = 0x1,
> .default_value = HDCS_DEFAULT_EXPOSURE,
> .flags = V4L2_CTRL_FLAG_SLIDER
> @@ -120,6 +120,7 @@ struct hdcs {
> } exp;
>
> int psmp;
> + u8 exp_cache, gain_cache;
> };
>
> static int hdcs_reg_write_seq(struct sd *sd, u8 reg, u8 *vals, u8 len)
> @@ -205,34 +206,8 @@ static int hdcs_get_exposure(struct gspc
> struct sd *sd = (struct sd *) gspca_dev;
> struct hdcs *hdcs = sd->sensor_priv;
>
> - /* Column time period */
> - int ct;
> - /* Column processing period */
> - int cp;
> - /* Row processing period */
> - int rp;
> - int cycles;
> - int err;
> - int rowexp;
> - u16 data[2];
> -
> - err = stv06xx_read_sensor(sd, HDCS_ROWEXPL, &data[0]);
> - if (err < 0)
> - return err;
> -
> - err = stv06xx_read_sensor(sd, HDCS_ROWEXPH, &data[1]);
> - if (err < 0)
> - return err;
> -
> - rowexp = (data[1] << 8) | data[0];
> + *val = hdcs->exp_cache;
>
> - ct = hdcs->exp.cto + hdcs->psmp + (HDCS_ADC_START_SIG_DUR + 2);
> - cp = hdcs->exp.cto + (hdcs->w * ct / 2);
> - rp = hdcs->exp.rs + cp;
> -
> - cycles = rp * rowexp;
> - *val = cycles / HDCS_CLK_FREQ_MHZ;
> - PDEBUG(D_V4L2, "Read exposure %d", *val);
> return 0;
> }
>
> @@ -254,7 +229,10 @@ static int hdcs_set_exposure(struct gspc
> int cycles, err;
> u8 exp[14];
>
> - cycles = val * HDCS_CLK_FREQ_MHZ;
> + val &= 0xff;
> + hdcs->exp_cache = val;
> +
> + cycles = val * HDCS_CLK_FREQ_MHZ * 257;
Why 257 here? I guess it is some kind of expansion factor.
>
> ct = hdcs->exp.cto + hdcs->psmp + (HDCS_ADC_START_SIG_DUR + 2);
> cp = hdcs->exp.cto + (hdcs->w * ct / 2);
> @@ -325,49 +303,42 @@ static int hdcs_set_exposure(struct gspc
> return err;
> }
>
> -static int hdcs_set_gains(struct sd *sd, u8 r, u8 g, u8 b)
> +static int hdcs_set_gains(struct sd *sd, u8 g)
> {
> + struct hdcs *hdcs = sd->sensor_priv;
> + int err;
> u8 gains[4];
>
> + hdcs->gain_cache = g;
> +
> /* the voltage gain Av = (1 + 19 * val / 127) * (1 + bit7) */
> - if (r > 127)
> - r = 0x80 | (r / 2);
> if (g > 127)
> g = 0x80 | (g / 2);
> - if (b > 127)
> - b = 0x80 | (b / 2);
>
> gains[0] = g;
> - gains[1] = r;
> - gains[2] = b;
> + gains[1] = g;
> + gains[2] = g;
> gains[3] = g;
>
> - return hdcs_reg_write_seq(sd, HDCS_ERECPGA, gains, 4);
> + err = hdcs_reg_write_seq(sd, HDCS_ERECPGA, gains, 4);
> + return err;
> }
>
> static int hdcs_get_gain(struct gspca_dev *gspca_dev, __s32 *val)
> {
> struct sd *sd = (struct sd *) gspca_dev;
> - int err;
> - u16 data;
> + struct hdcs *hdcs = sd->sensor_priv;
>
> - err = stv06xx_read_sensor(sd, HDCS_ERECPGA, &data);
> + *val = hdcs->gain_cache;
>
> - /* Bit 7 doubles the gain */
> - if (data & 0x80)
> - *val = (data & 0x7f) * 2;
> - else
> - *val = data;
> -
> - PDEBUG(D_V4L2, "Read gain %d", *val);
> - return err;
> + return 0;
> }
>
> static int hdcs_set_gain(struct gspca_dev *gspca_dev, __s32 val)
> {
> PDEBUG(D_V4L2, "Writing gain %d", val);
> return hdcs_set_gains((struct sd *) gspca_dev,
> - val & 0xff, val & 0xff, val & 0xff);
> + val & 0xff);
> }
>
> static int hdcs_set_size(struct sd *sd,
> @@ -585,8 +556,7 @@ static int hdcs_init(struct sd *sd)
Re: [Patch 1/2] stv06xx webcams with HDCS 1xxx sensors
2009/9/9 James Blanford :
> Quickcam Express 046d:0840 and maybe others
>
> Driver version: v 2.60 from 2.6.31-rc7
>
> Initialize image size before it's used to initialize exposure.
> Work around lack of exposure set hardware latch with a sequence of
> register writes in a single I2C command packet.
>
> Signed-off-by: James Blanford
> --- a/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c 2009-09-01
> 09:45:42.0 -0400
> +++ b/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c 2009-09-09
> 14:59:35.0 -0400
> @@ -252,7 +252,7 @@ static int hdcs_set_exposure(struct gspc
> within the column processing period */
> int mnct;
> int cycles, err;
> - u8 exp[4];
> + u8 exp[14];
>
> cycles = val * HDCS_CLK_FREQ_MHZ;
>
> @@ -288,24 +288,37 @@ static int hdcs_set_exposure(struct gspc
> srowexp = max_srowexp;
>
> if (IS_1020(sd)) {
> - exp[0] = rowexp & 0xff;
> - exp[1] = rowexp >> 8;
> - exp[2] = (srowexp >> 2) & 0xff;
> - /* this clears exposure error flag */
> - exp[3] = 0x1;
> - err = hdcs_reg_write_seq(sd, HDCS_ROWEXPL, exp, 4);
> + exp[0] = HDCS20_CONTROL;
> + exp[1] = 0x00; /* Stop streaming */
> + exp[2] = HDCS_ROWEXPL;
> + exp[3] = rowexp & 0xff;
> + exp[4] = HDCS_ROWEXPH;
> + exp[5] = rowexp >> 8;
> + exp[6] = HDCS20_SROWEXP;
> + exp[7] = (srowexp >> 2) & 0xff;
> + exp[8] = HDCS20_ERROR;
> + exp[9] = 0x10; /* Clear exposure error flag*/
> + exp[10] = HDCS20_CONTROL;
> + exp[11] = 0x04; /* Restart streaming */
> + err = stv06xx_write_sensor_bytes(sd, exp, 6);
> } else {
> - exp[0] = rowexp & 0xff;
> - exp[1] = rowexp >> 8;
> - exp[2] = srowexp & 0xff;
> - exp[3] = srowexp >> 8;
> - err = hdcs_reg_write_seq(sd, HDCS_ROWEXPL, exp, 4);
> + exp[0] = HDCS00_CONTROL;
> + exp[1] = 0x00; /* Stop streaming */
> + exp[2] = HDCS_ROWEXPL;
> + exp[3] = rowexp & 0xff;
> + exp[4] = HDCS_ROWEXPH;
> + exp[5] = rowexp >> 8;
> + exp[6] = HDCS00_SROWEXPL;
> + exp[7] = srowexp & 0xff;
> + exp[8] = HDCS00_SROWEXPH;
> + exp[9] = srowexp >> 8;
> + exp[10] = HDCS_STATUS;
> + exp[11] = 0x10; /* Clear exposure error flag*/
> + exp[12] = HDCS00_CONTROL;
> + exp[13] = 0x04; /* Restart streaming */
> + err = stv06xx_write_sensor_bytes(sd, exp, 7);
> if (err < 0)
> return err;
> -
> - /* clear exposure error flag */
> - err = stv06xx_write_sensor(sd,
> - HDCS_STATUS, BIT(4));
> }
> PDEBUG(D_V4L2, "Writing exposure %d, rowexp %d, srowexp %d",
> val, rowexp, srowexp);
> @@ -577,11 +590,11 @@ static int hdcs_init(struct sd *sd)
> if (err < 0)
> return err;
>
> - err = hdcs_set_exposure(&sd->gspca_dev, HDCS_DEFAULT_EXPOSURE);
> + err = hdcs_set_size(sd, hdcs->array.width, hdcs->array.height);
> if (err < 0)
> return err;
>
> - err = hdcs_set_size(sd, hdcs->array.width, hdcs->array.height);
> + err = hdcs_set_exposure(&sd->gspca_dev, HDCS_DEFAULT_EXPOSURE);
> return err;
> }
>
>
I don't have the hardware to test this, but looks good to me.
Thanks,
Acked-by: Erik Andrén
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] NetUP Dual DVB-T/C-CI RF PCI-E x1
This sounds promising. I hope you are not going to price yourselves completely out as a few other DVB-C suppliers have done. If the price is right (around the same as a normal DVB-T tuner ~$65), it definitely sounds interesting. When you say it supports two transponders, is this also true on DVB-C only... As in DVB-C + DVB-C channel... If this is the case then I only need 3 cards to cover all the interesting channels in my cable network ;) I CAN TIMESHIFT THE WORLD!!! MUHAHAHAhaha... *cough* But seriously... This sounds very interesting. Christian from Norway... On Wed, Sep 9, 2009 at 4:51 PM, Abylai Ospan wrote: > Hello, > > We have designed NetUP Dual NetUP Dual DVB-T/C-CI RF PCI-E x1 card. A short > description is available in wiki - > http://linuxtv.org/wiki/index.php/NetUP_Dual_DVB_T_C_CI_RF > > Features: > * PCI-e x1 > * Supports two DVB-T/DVB-C transponders simultaneously > * Supports two analog audio/video channels simultaneously > * Independent descrambling of two transponders > * Hardware PID filtering > > Now we have started the work on the driver for Linux. The following > components used in this card already have their code for Linux published: > * Conexant CX23885, CX25840 > * Xceive XC5000 silicon TV tuner > > We are working on the code for the following components: > * STM STV0367 low-power and ultra-compact combo DVB-T/C single-chip receiver > * Altera FPGA for Common Interafce. > > We have developed FPGA firmware for CI (according to PCMCIA/en50221). Also we > are doing "hardware" PID filtering. It's fast and very flexible. JTAG is used > for firmware uploading into FPGA - > this part contains "JAM player" from Altera for processing JAM STAPL > Byte-Code (.jbc files). > > The resulting code will be published under GPL after receiving permissions > from IC vendors. > > -- > Abylai Ospan > NetUP Inc. > > P.S. > We will show this card at the upcoming IBC exhibition ( stand IP402 ). > > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > -- 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
RFCv2: Media controller proposal
Hi all, Here is the new Media Controller RFC. It is completely rewritten from the original RFC. This original RFC can be found here: http://www.archivum.info/video4linux-list%40redhat.com/2008-07/00371/RFC:_Add_support_to_query_and_change_connections_inside_a_media_device This document will be the basis of the discussions during the Plumbers Conference in two weeks time. Open issue #3 is the main unresolved item, but I hope to come up with something during the weekend. Regards, Hans RFC: Media controller proposal Version 2.0 Background == This RFC is a new version of the original RFC that was written in cooperation with and on behalf of Texas Instruments about a year ago. Much work has been done in the past year to put the foundation in place to be able to implement a media controller and now it is time for this updated version. The intention is to discuss this in more detail during this years Plumbers Conference. Although the high-level concepts are the same as in the original RFC, many of the details have changed based on what was learned over the past year. This RFC is based on the original discussions with Manjunath Hadli from TI last year, on discussions during a recent meeting between Laurent Pinchart, Guennadi Liakhovetski and myself, and on recent discussions with Nokia. Thanks to Sakari Ailus for doing an initial review of this RFC. One note regarding terminology: a 'board' is the name I use for the SoC, PCI or USB device that contains the video hardware. Each board has its own driver instance and its own v4l2_device struct. Originally I called it 'device', but that name is already used in too many places. What is a media controller? === In a nutshell: a media controller is a new v4l device node that can be used to discover and modify the topology of the board and to give access to the low-level nodes (such as previewers, resizers, color space converters, etc.) that are part of the topology. It does not do any streaming, that is the exclusive domain of video nodes. It is meant purely for controlling a board as a whole. Why do we need one? === There are currently several problems that are impossible to solve within the current V4L2 API: 1) Discovering the various device nodes that are typically created by a video board, such as: video nodes, vbi nodes, dvb nodes, alsa nodes, framebuffer nodes, input nodes (for e.g. webcam button events or IR remotes). It would be very handy if an application can just open an /dev/v4l/mc0 node and be able to figure out where all the nodes are, and to be able to figure out what the capabilities of the board are (e.g. does it support DVB, is the audio going through a loopback cable or is there an alsa device, can it do compressed MPEG video, etc. etc.). Currently the end-user has no choice but to supply the device nodes manually. 2) Some of the newer SoC devices can connect or disconnect internal components dynamically. As an example, the omap3 can either connect a sensor output to a CCDC module to a previewer module to a resizer module and finally to a capture device node. But it is also possible to capture the sensor output directly after the CCDC module. The previewer can get its input from another video device node and output either to the resizer or to another video capture device node. The same is true for the resizer, that too can get its input from a device node. So there are lots of connections here that can be modified at will depending on what the application wants. And in real life there are even more links than I mentioned here. And it will only get more complicated in the future. All this requires that there has to be a way to connect and disconnect parts of the internal topology of a video board at will. 3) There is increasing demand to be able to control e.g. sensors or video encoders/decoders at a much more precise manner. Currently the V4L2 API provides only limited support in the form of a set of controls. But when building a high-end camera the developer of the application controlling it needs very detailed control of the sensor and image processing devices. On the other hand, you do not want to have all this polluting the V4L2 API since there is absolutely no sense in exporting this as part of the existing controls, or to allow for a large number of private ioctls. What would be a good solution is to give access to the various components of the board and allow the application to send component-specific ioctls or controls to it. Any application that will do this is by default tailored to that board. In addition, none of these new controls or commands will pollute the namespace of V4L2. A media controller can solve all these problems: it will provide a window into the architecture of the board and all its device nodes. Since it is already enumerating the nodes and components of the board and how they are linked up, it is only a small step to also use it to change
Re: saa7134 doesn't work after warm-reboot
I've seen computer act strangely after such short power outage ( especially when that outage take a few ms ). Usually, the culprit is a low quality power supply, and i solve it by using a better quality one plus a surge protector (when i can't convice to buy a small UPS, at least :) ). Beyond that suggestion i can't help you. David Whyte a écrit : Further info, the power outage was for about 10 seconds in the latest incident. Also, there is no need to unplug the PC power from the wall and press the power button etc to recover, you just need to leave the machine powered down for a short while. Sounds a lot like the issues I have read about where the firmware remains in the tuner card but is corrupt or something. The only way is to clear the firmware and re-upload it, generally by powering down for sometime but I am hoping that you can do this by unloading then loading the modules. Is this possible? Anyone know which modules in this instance? Regards, Whytey -- 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
