Re: How to handle independent CA devices
On 18 September 2010 01:47, rjkm r...@metzlerbros.de wrote: Manu Abraham writes: You still need a mechanism to decide which tuner gets it. First one which opens its own ca device? Sharing the CI (multi-stream decoding) in such an automatic way would also be complicated. I think I will only add such a feature if there is very high demand and rather look into the separate API solution. It would be advantageous, if we do have just a simple input path, where it is not restricted for CA/CI alone. I have some hardware over here, where it has a DMA_TO_DEVICE channel (other than for the SG table), where it can write a TS to any post-processor connected to it, such as a CA/CI device, or even a decoder, for example. In short, it could be anything, to put short. In this case, the device can accept processed stream (muxed TS for multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You can flip some registers for the device, for it to read from userspace, or for that DMA channel to read from the hardware page tables of another DMA channel which is coming from the tuner. Maybe, we just need a simple mechanism/ioctl to select the CA/CI input for the stream to the bridge. ie like a MUX: a 1:n select per adapter, where the CA/CI device has 1 input and there are 'n' sources. It would be nice to have a more general output device. But I have currently no plans to support something like transparent streaming from one input to the output and back inside the driver. Could it be handled as a transcode step? Record the encrypted mux from the DVB card to disk first. Then do the decrypt step offline or during playback. During playback, you only wish to watch one channel at a time, and the CAM will handle that. Contra to what people think, most CAMs can decrypt the stream some considerably time after the broadcast of the stream. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: control framework enhancements
Hi all, This weekend I started converting drivers to the new control framework. While doing that I realized that the control framework needs a few enhancements. The first one is missing functionality: some drivers use different subdevs for different inputs. The vino driver is one of those (it uses either the indycam subdev or the saa7191 subdev). Changing input means that the controls also change. This functionality is part of the V4L2 spec, in fact. If it was just the very old vino driver, then I might have ignored this, but I know that the TI dm6467 evaluation board has similar behavior. So we need a way to enable or disable controls. Changing inputs would then just disable all the controls of the subdev controlling the old input and enable all controls of the subdev controlling the new input. Since both subdevs may have identical controls (e.g. both may have a brightness control), the control framework needs to be able to handle that as well. In order to support this functionality I've added the following two functions: /** v4l2_ctrl_enable() - Mark the control as enabled or disabled. * @ctrl: The control to en/disable. * @enabled: True if the control should become enabled. * * Enable/disable a control. * Does nothing if @ctrl == NULL. * Usually called if controls are to be enabled or disabled when changing * to a different input or output. * * When a control is disabled, then it will no longer show up in the * application. * * This function can be called regardless of whether the control handler * is locked or not. */ void v4l2_ctrl_enable(struct v4l2_ctrl *ctrl, bool enabled); /** v4l2_ctrl_handler_enable() - Mark the controls in the handler as enabled or disabled. * @hdl: The control handler. * @enabled: True if the controls should become enabled. * * Enable/disable the controls owned by the handler. * Does nothing if @hdl == NULL. * Usually called if controls are to be enabled or disabled when changing * to a different input or output. * * When a control is disabled, then it will no longer show up in the * application. */ void v4l2_ctrl_handler_enable(struct v4l2_ctrl_handler *hdl, bool enabled); And internally I allow for duplicate control references. The first enabled control will win. If no one objects, then I want to merge this for 2.6.37. The second enhancement is one I am not sure about. It concerns private controls. The basic guideline for drivers is that private controls need to be added to videodev2.h and documented in the spec. So private controls are well defined, and their control ID is fixed so they can set directly by an application. However, there are a few cases where the ability to have the framework generate control IDs for you is actually quite useful. Of course, if you do this then you can never set controls directly since you do not know the control ID. I have identified four use-cases for this: - Initial development and testing: it is quite handy to generate the ID while you are still developing your driver. - In vivi I want to create test controls to use as a test-bed for testing the control framework. Such test controls really do not belong in videodev2.h. - Legacy drivers: do we really want to add the private controls of e.g. indycam.c to videodev2.h and the spec? It is a lot of work for little gain. - Drivers like UVC where controls can be generated. The way I have implemented this is that when you create the control you pass a special control ID: #define V4L2_CID_USER_AUTO (V4L2_CTRL_CLASS_USER | 0xf000) #define V4L2_CID_MPEG_AUTO (V4L2_CTRL_CLASS_MPEG | 0xf000) #define V4L2_CID_CAMERA_AUTO(V4L2_CTRL_CLASS_CAMERA | 0xf000) #define V4L2_CID_FM_TX_AUTO (V4L2_CTRL_CLASS_FM_TX | 0xf000) The framework will then automatically generate a new ID. I'm undecided about this one. It definitely has advantages, but it also requires extra care when reviewing drivers since this functionality shouldn't be abused. The patches are available in my tree: http://git.linuxtv.org/hverkuil/v4l-dvb.git?a=shortlog;h=refs/heads/ctrlfw See the vivi patch for an example of auto-generated control IDs. Comments? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR 1600 Distortion
On Fri, 2010-09-17 at 18:23 -0400, Josh Borke wrote: Thanks for the response! Replies are in line. On Thu, Sep 16, 2010 at 6:48 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-09-15 at 22:54 -0400, Josh Borke wrote: I've recently noticed some distortion coming from my hvr1600 when viewing analog channels. It happens to all analog channels with some slightly better than others. I am running Fedora 12 linux with kernel version 2.6.32.21-166. I know I need to include more information but I'm not sure what to include. Any help would be appreciated. 1. Would you say the distortion is something you would possibly encounter on an analog television set, or does it look uniquely digital? On systems with a long uptime and lots of usage, MPEG encoder firmware could wind up in a screwed up state giving weird output image. Simple solution in this case is to reboot. I'm not sure if I would classify it as uniquely digital. The distortion happens across most of the screen with it being concentrated in the top third. Additionally shows that include black bars the top black bar is seemingly stretched and the image seems like the colors are over-saturated where they colors are brighter. Rebooting had no effect :( OK. 2. Have you ensured your cable plant isn't affecting signal integrity? http://ivtvdriver.org/index.php/Howto:Improve_signal_quality The cable plant hasn't changed the signal strength or integrity as far as I know. OK. Keep it in the back of your mind though. 3. Does this happen with only the RF tuner or only CVBS or only SVideo or more than one of them? If the problem is only with RF, then it could be an incoming signal distortion problem. Do you have cable or an over the air antenna for analog RF? I only have input for the RF tuner. I have cable for analog RF. Please try and test the output of a VCR or DVD play plugged into the HVR-1600. (We don't need sound, just the video.) This will tell us if the problem happens before the CX23418 chip's analog front end (i.e. in the RF and analog tuner) or not. $ v4l2-ctl -d /dev/video0 -n (List of possible inputs displayed) $ v4l2-ctl -d /dev/video0 -i 2 Video input set to 2 (Composite 1) # v4l2-ctl -d /dev/video0 -s ntsc-m Standard set to 1000 $ cat /dev/video0 foo.mpg ^C 4. What does v4l2-ctl --log-status show as your analog tuner? Not sure what you mean so I've included the full output: # v4l2-ctl -d /dev/hvr1600 --log-status Status Log: cx18-0: = START STATUS CARD #0 = cx18-0: Version: 1.2.0 Card: Hauppauge HVR-1600 tveeprom 3-0050: Hauppauge model 74041, rev C6B2, serial# 898361 tveeprom 3-0050: MAC address is 00-0D-FE-0D-B5-39 tveeprom 3-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) ^^ OK. You have a board with the same tuner as I have. All I have for an analog RF source is a DTV STB, so a very clean channel 3 is all I have to try and duplicate the problem. tveeprom 3-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 3-0050: audio processor is CX23418 (idx 38) tveeprom 3-0050: decoder processor is CX23418 (idx 31) tveeprom 3-0050: has no radio, has IR receiver, has IR transmitter cx18-0 843: Video signal: present cx18-0 843: Detected format: NTSC-M cx18-0 843: Specified standard:NTSC-M cx18-0 843: Specified video input: Composite 7 cx18-0 843: Specified audioclock freq: 48000 Hz cx18-0 843: Detected audio mode: mono cx18-0 843: Detected audio standard: BTSC cx18-0 843: Audio muted: no cx18-0 843: Audio microcontroller: running cx18-0 843: Configured audio standard: automatic detection cx18-0 843: Configured audio system: BTSC cx18-0 843: Specified audio input: Tuner (In8) cx18-0 843: Preferred audio mode: stereo cx18-0 gpio-reset-ctrl: GPIO: direction 0x3001, value 0x3001 tuner 4-0061: Tuner mode: analog TV tuner 4-0061: Frequency: 175.25 MHz ^^ This is the freq for both US Broadcast and US Cable channel 7 BTW. tuner 4-0061: Standard:0xb000 cs5345 3-004c: Input: 1 cs5345 3-004c: Volume: 0 dB cx18-0: Video Input: Tuner 1 cx18-0: Audio Input: Tuner 1 cx18-0: GPIO: direction 0x3001, value 0x3001 cx18-0: Tuner: TV cx18-0: Stream: MPEG-2 Program Stream cx18-0: VBI Format: Private packet, IVTV format cx18-0: Video: 720x480, 30 fps cx18-0: Video: MPEG-2, 4x3, Variable Bitrate, 660, Peak 660 cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 384 kbps, Stereo, No Emphasis, No CRC cx18-0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0 cx18-0: Temporal Filter: Manual, 8 cx18-0:
Re: How to handle independent CA devices
On Sat, Sep 18, 2010 at 6:17 AM, rjkm r...@metzlerbros.de wrote: Manu Abraham writes: You still need a mechanism to decide which tuner gets it. First one which opens its own ca device? Sharing the CI (multi-stream decoding) in such an automatic way would also be complicated. I think I will only add such a feature if there is very high demand and rather look into the separate API solution. It would be advantageous, if we do have just a simple input path, where it is not restricted for CA/CI alone. I have some hardware over here, where it has a DMA_TO_DEVICE channel (other than for the SG table), where it can write a TS to any post-processor connected to it, such as a CA/CI device, or even a decoder, for example. In short, it could be anything, to put short. In this case, the device can accept processed stream (muxed TS for multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You can flip some registers for the device, for it to read from userspace, or for that DMA channel to read from the hardware page tables of another DMA channel which is coming from the tuner. Maybe, we just need a simple mechanism/ioctl to select the CA/CI input for the stream to the bridge. ie like a MUX: a 1:n select per adapter, where the CA/CI device has 1 input and there are 'n' sources. It would be nice to have a more general output device. But I have currently no plans to support something like transparent streaming from one input to the output and back inside the driver. Maybe it wasn't very clear ... (Streaming from one input to the output and back inside the driver what you are implementing is not what I had in mind.) Currently for any independant CA device what you need is a stream to the bridge where it can route the same to the CI slot. For a generic device capable of doing any other gimmicks also, what you need is an input to the bridge. So, what I was trying to say is that, let's not limit the input path to CA alone. For explanation sale let's term in as TS_IN The TS_In interface is a simple interface where an application can just write to the TS_IN interface, which goes to the DVB_ringbuffer and hence to the bridge. I think, this is all what it should do. We have 3 application uses cases here, based on different hardware types. 1. Bridge is reading from TS_IN (from a user space application, streams from a single TS) for sending stream to CA, the normal way (All things are fine) 2. Bridge is reading from TS_IN (from a user space application, streams from multiple TS's) for sending to CA. This is also same as (1) but just that the user space application is writing a remuxed stream to TS_IN 3. Bridge is reading from TS_IN (from a userspace application) The bridge has multiple DMA channels. The bridge driver can load page tables from another channel, whereby the bridge is routing to another interface itself completely. This is a hardware feature, so we don't need to get data manually in software from one interface to the other. All this just needs the input path to be generic. An input interface such as TS_IN can feed the stream to an onboard decoder or any other post-processor as described with (3) Only in the case of (2) the application really needs to do some thing in real life, ie to Remux. But you can omit out the application to handle (2). Where somebody can implement it any later stage of time, if there's any interest. I guess nGene can do (1) and (2) So, I wonder whether we should name the interface CA itself, where otherwise it can suit other application use cases as well. In such a case it becomes not limited to CA alone, to put short. Implementing a simple buffering alone (the rest of the necessities with the driver), will make the interface generic. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: control framework enhancements
On Sat, 2010-09-18 at 14:19 +0200, Hans Verkuil wrote: Hi all, This weekend I started converting drivers to the new control framework. While doing that I realized that the control framework needs a few enhancements. Since both subdevs may have identical controls (e.g. both may have a brightness control), the control framework needs to be able to handle that as well. Is it ever the case that a bridge chip and a subdev also have identical controls (CX23880 and WM8739 maybe)? Does your change handle that? In order to support this functionality I've added the following two functions: /** v4l2_ctrl_enable() - Mark the control as enabled or disabled. * @ctrl: The control to en/disable. * @enabled: True if the control should become enabled. * * Enable/disable a control. * Does nothing if @ctrl == NULL. * Usually called if controls are to be enabled or disabled when changing * to a different input or output. * * When a control is disabled, then it will no longer show up in the * application. * * This function can be called regardless of whether the control handler * is locked or not. */ void v4l2_ctrl_enable(struct v4l2_ctrl *ctrl, bool enabled); /** v4l2_ctrl_handler_enable() - Mark the controls in the handler as enabled or disabled. * @hdl: The control handler. * @enabled: True if the controls should become enabled. * * Enable/disable the controls owned by the handler. * Does nothing if @hdl == NULL. * Usually called if controls are to be enabled or disabled when changing * to a different input or output. * * When a control is disabled, then it will no longer show up in the * application. */ void v4l2_ctrl_handler_enable(struct v4l2_ctrl_handler *hdl, bool enabled); And internally I allow for duplicate control references. The first enabled control will win. By duplicate reference do you mean in a list of V4L2 control objects, the first enabled one in the list, matching the desired V4L2_CID, wins? I can also offer a case where having two volume controls is useful: WM8775 (IIRC) connected in front of a CX25841 on an ivtv board. Due to the way the board is wired, audio nosie performance is terrible, if only manipulating the volume control in the CX25841. By manipulating the volume control in the WM8775, the audio system noise figure can be improved. (Highest gain setting without clipping in the WM8775 with the CX25841 volume control to attenuate down to a pleasant listening level.) I don't know, maybe something like that takes us down the path of recreating the ALSA mixer interface. So in the case of volume controls it may be better just to create an ALSA API interface for ivtv. The same sort of noise figure improvement mechanism can be applicable to other signals going through a multistage process with gain controls or clamping controls. If no one objects, then I want to merge this for 2.6.37. The second enhancement is one I am not sure about. It concerns private controls. The basic guideline for drivers is that private controls need to be added to videodev2.h and documented in the spec. So private controls are well defined, and their control ID is fixed so they can set directly by an application. Maybe that guideline needs revision, regardless of new control framework changes. A better guideline may be that applications should make every effort to avoid hard-coding private control IDs, and to discover private controls instead. (I used the language make every effort to allow for the case of applications designed around a specific driver.) The whole purpose of non-private V4L2_CIDs is that they need not be discovered, always have a well defined/understood effect, and can always be hard-coded by general purpose video applications. So a private controls should not be required to meet all of those conditions - otherwise it is a standard control. Of course all statically defined controls, public or private, should be documented -- says the person who doesn't plan to backfill the documentation. ;) However, there are a few cases where the ability to have the framework generate control IDs for you is actually quite useful. It seems like it would be useful for developers. Would it ever be used by non-test/non-debug applications? In your cases below, I think UVC cam applications are the only example. Of course, if you do this then you can never set controls directly since you do not know the control ID. I have identified four use-cases for this: - Initial development and testing: it is quite handy to generate the ID while you are still developing your driver. Yes. - In vivi I want to create test controls to use as a test-bed for testing the control framework. Such test controls really do not belong in videodev2.h. Hmmm. I thought the vivi driver was intended to be a learning tool and example. I'd suggest heavy documentation and dire warnings in
Afatech AF9015 MaxLinear MXL5007T dual tuner 2
Hi There, Device: Hardware based on Afatech AF9015 USB bridge AF9013 demodulators MaxLinear MXL5007T tuners: Not Only TV/LifeView DUAL DVB-T USB LV52T equivalent to TerraTec Cinergy T Stick Dual RC Problem: Boot from G2 (S5) aka Soft Off or Resume from G1 - S3 aka Suspend to RAM tuner #2 nonfunctional lsusb: Bus 002 Device 002: ID 15a4:9016 Afatech Technologies, Inc. AF9015 DVB-T USB2.0 stick uname: 2.6.35.4-12.el6.i686.PAE Ref. modprobe.conf: options dvb-core frontend_debug=1 debug=1 dvbdev_debug=1 options dvb-usb debug=511 options dvb_usb_af9015 debug=1 options af9013 debug=1 options mxl5007t debug=1 dmesg: ... usb 2-1: new high speed USB device using ehci_hcd and address 2 psmouse serio1: ID: 10 00 64 usb 2-1: New USB device found, idVendor=15a4, idProduct=9016 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1: Product: DVB-T 2 usb 2-1: Manufacturer: Afatech usb 2-1: SerialNumber: 01010101061 Afatech DVB-T 2: Fixing fullspeed to highspeed interval: 10 - 7 input: Afatech DVB-T 2 as /devices/pci:00/:00:04.1/usb2/2-1/2-1:1.1/input/input3 generic-usb 0003:15A4:9016.0001: input,hidraw0: USB HID v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:04.1-1/input1 ... af9015_usb_probe: interface:0 : 2b a5 9b 0b 00 00 00 00 a4 15 16 90 00 02 01 02 +... 0010: 03 80 00 fa fa 0a 40 ef 01 30 31 30 31 30 39 32 ..@..0101092 0020: 31 30 39 30 30 30 30 31 ff ff ff ff ff ff ff ff 1091 0030: 00 01 3a 01 00 08 02 00 da 11 00 00 b1 ff ff ff ..:. 0040: ff ff ff ff ff 08 02 00 da 11 c4 04 b1 ff ff ff 0050: ff ff ff ff 10 26 00 00 04 03 09 04 10 03 41 00 .A. 0060: 66 00 61 00 74 00 65 00 63 00 68 00 10 03 44 00 f.a.t.e.c.h...D. 0070: 56 00 42 00 2d 00 54 00 20 00 32 00 20 03 30 00 V.B.-.T. .2. .0. 0080: 31 00 30 00 31 00 30 00 31 00 30 00 31 00 30 00 1.0.1.0.1.0.1.0. 0090: 36 00 30 00 30 00 30 00 30 00 31 00 00 ff ff ff 6.0.0.0.0.1. 00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff af9015_eeprom_hash: eeprom sum=403c71e6 af9015_read_config: IR mode:1 af9015_read_config: TS mode:1 af9015_read_config: [0] xtal:2 set adc_clock:28000 af9015_read_config: [0] IF1:4570 af9015_read_config: [0] MT2060 IF1:0 af9015_read_config: [0] tuner id:177 af9015_read_config: [1] xtal:2 set adc_clock:28000 af9015_read_config: [1] IF1:4570 af9015_read_config: [1] MT2060 IF1:1220 af9015_read_config: [1] tuner id:177 check for cold 15a4 9015 check for cold 15a4 9016 af9015_identify_state: reply:02 dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. power control: 1 dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. all in all I will use 98136 bytes for streaming allocating buffer 0 buffer 0: f4dd8000 (dma: 886931456) allocating buffer 1 buffer 1: f4da8000 (dma: 886734848) allocating buffer 2 buffer 2: f4dac000 (dma: 886751232) allocating buffer 3 buffer 3: f4dd (dma: 886898688) allocating buffer 4 buffer 4: f4dd4000 (dma: 886915072) allocating buffer 5 buffer 5: f4de (dma: 886964224) allocation successful DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) DVB: register adapter0/demux0 @ minor: 0 (0x00) DVB: register adapter0/dvr0 @ minor: 1 (0x01) DVB: register adapter0/net0 @ minor: 2 (0x02) af9015_af9013_frontend_attach: init I2C af9015_i2c_init: af9013_attach: chip version:1 ROM version:1.0 af9013: firmware version:5.1.0.0 af9013_set_gpio: gpio:0 gpioval:07 af9013_set_gpio: gpio:1 gpioval:00 af9013_set_gpio: gpio:2 gpioval:00 af9013_set_gpio: gpio:3 gpioval:03 dvb_register_frontend DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... DVB: register adapter0/frontend0 @ minor: 3 (0x03) af9015_tuner_attach: mxl5007t 2-00c0: creating new instance af9013_i2c_gate_ctrl: enable:1 mxl5007t_get_chip_id: unknown rev (3f) mxl5007t_get_chip_id: MxL5007T detected @ 2-00c0 af9013_i2c_gate_ctrl: enable:0 dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. all in all I will use 98136 bytes for streaming allocating buffer 0 buffer 0: f4dcc000 (dma: 886882304) allocating buffer 1 buffer 1: f4de4000 (dma: 886980608) allocating buffer 2 buffer 2: f4de8000 (dma: 886996992) allocating buffer 3 buffer 3: f4dec000 (dma: 887013376) allocating buffer 4 buffer 4: f4df (dma: 887029760) allocating buffer 5 buffer 5: f4df4000 (dma: 887046144) allocation successful DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) DVB: register adapter1/demux0 @ minor: 4 (0x04) DVB: register
Re: RFC: control framework enhancements
On Saturday, September 18, 2010 15:44:37 Andy Walls wrote: On Sat, 2010-09-18 at 14:19 +0200, Hans Verkuil wrote: Hi all, This weekend I started converting drivers to the new control framework. While doing that I realized that the control framework needs a few enhancements. Since both subdevs may have identical controls (e.g. both may have a brightness control), the control framework needs to be able to handle that as well. Is it ever the case that a bridge chip and a subdev also have identical controls (CX23880 and WM8739 maybe)? Does your change handle that? Yes, that is definitely possible. Right now the first created control 'wins'. So if the cx23880 has a volume control and wm8739 has one as well, then the cx23880 is always the one that is used. Once we have device nodes to access subdevs as well, then the wm8739 would become available through that device node. With the new enable/disable functionality it becomes possible to let the cx23880 driver disable its own volume control in favor of the wm8739. It can be toggled at will. In order to support this functionality I've added the following two functions: /** v4l2_ctrl_enable() - Mark the control as enabled or disabled. * @ctrl: The control to en/disable. * @enabled: True if the control should become enabled. * * Enable/disable a control. * Does nothing if @ctrl == NULL. * Usually called if controls are to be enabled or disabled when changing * to a different input or output. * * When a control is disabled, then it will no longer show up in the * application. * * This function can be called regardless of whether the control handler * is locked or not. */ void v4l2_ctrl_enable(struct v4l2_ctrl *ctrl, bool enabled); /** v4l2_ctrl_handler_enable() - Mark the controls in the handler as enabled or disabled. * @hdl: The control handler. * @enabled: True if the controls should become enabled. * * Enable/disable the controls owned by the handler. * Does nothing if @hdl == NULL. * Usually called if controls are to be enabled or disabled when changing * to a different input or output. * * When a control is disabled, then it will no longer show up in the * application. */ void v4l2_ctrl_handler_enable(struct v4l2_ctrl_handler *hdl, bool enabled); And internally I allow for duplicate control references. The first enabled control will win. By duplicate reference do you mean in a list of V4L2 control objects, the first enabled one in the list, matching the desired V4L2_CID, wins? Right. I can also offer a case where having two volume controls is useful: WM8775 (IIRC) connected in front of a CX25841 on an ivtv board. Due to the way the board is wired, audio nosie performance is terrible, if only manipulating the volume control in the CX25841. By manipulating the volume control in the WM8775, the audio system noise figure can be improved. (Highest gain setting without clipping in the WM8775 with the CX25841 volume control to attenuate down to a pleasant listening level.) I don't know, maybe something like that takes us down the path of recreating the ALSA mixer interface. So in the case of volume controls it may be better just to create an ALSA API interface for ivtv. The same sort of noise figure improvement mechanism can be applicable to other signals going through a multistage process with gain controls or clamping controls. I don't think this new feature will help much with this case. You either have a smarter ivtv volume handling algorithm where ivtv implements a volume control whose implementation manipulated both the cx25841 and wm8775 volume controls in turn, or you let the user do it manually using the subdev device node once that becomes available. But the latter is hardly user friendly. If no one objects, then I want to merge this for 2.6.37. The second enhancement is one I am not sure about. It concerns private controls. The basic guideline for drivers is that private controls need to be added to videodev2.h and documented in the spec. So private controls are well defined, and their control ID is fixed so they can set directly by an application. Maybe that guideline needs revision, regardless of new control framework changes. A better guideline may be that applications should make every effort to avoid hard-coding private control IDs, and to discover private controls instead. (I used the language make every effort to allow for the case of applications designed around a specific driver.) That depends. The cx2341x MPEG private controls definitely need to be hardcoded. It makes perfect sense to make a custom application that controls all these MPEG settings directly. The same will be true for control handling in embedded systems. The problem is perhaps with the naming. Instead of calling it 'private' the name
Re: Afatech AF9015 MaxLinear MXL5007T dual tuner 2
On 09/18/2010 04:44 PM, poma wrote: Problem: Boot from G2 (S5) aka Soft Off or Resume from G1 - S3 aka Suspend to RAM tuner #2 nonfunctional p.p.s. Boot from G2 (S5) aka Soft Off or Resume from G1 - S3 aka Suspend to RAM tuner #1 and tuner #2 functional WITH module option: dvb-core dvb_powerdown_on_sleep=0 namely dvb_powerdown_on_sleep: 0: do not power down, 1: turn LNB voltage off on sleep (default) (int) Antti, is this the same case with TerraTec Cinergy T Stick Dual RC and is this the only solution, to keep the tuners on with dvb-core dvb_powerdown_on_sleep=0? I think so. Must be GPIO problem. One of the last problematic part is GPIOs - feel free to reimplement. 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
dvb-c usb device
Hello all, Every couple of months I scan this mailing list for the keywords usb and dvb-c, hoping that some new device has shown up that is supported under Linux. My request for information a couple of years ago turned up a few older devices that don't work well or are not sold anymore. And a closed source device. Neither was really a way to go. So I would like to check again if any one knows of a device that is supported or developments in that direction. With the announcement of Broadcom on their network driver, one keeps hoping that Micronas one day may turn around on their decision wrt a drx-k driver. It seems most (if not all) dvb-c usb devices out there are depending on this one. Regards, Bert Haverkamp -- To unsubscribe from this list: send the line unsubscribe 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: ibmcam (xrilink_cit) and konica webcam driver porting to gspca update
On Mon, Sep 13, 2010 at 2:02 PM, David Ellingsworth da...@identd.dyndns.org wrote: On Sun, Sep 5, 2010 at 4:58 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 08/31/2010 11:43 PM, David Ellingsworth wrote: Hans, I haven't had any success with this driver as of yet. My camera is shown here: http://www.amazon.com/IBM-Net-Camera-Pro-camera/dp/B0009MH25U The part number listed on the bottom is 22P5086. It's also labeled as being an IBM Net Camera Pro. Ah ok, so you have the same one as I have, that model was never supported by the old ibmcam driver, so I take it you never had it working with the old ibmcam driver ? When I plug the camera in, it is detected by the driver but it does not seem to function in this mode. Every attempt to obtain video from it using qv4l2 results in a black or green image. If I use the ibm_netcam_pro module option Given that is the same camera as I have using the ibm_netcam_pro module option is definitely the right thing to do. I noticed in your lsusb -v output that you're doing this from within vmware? Correct I was using vmware workstation's usb pass through to test the camera. I think that is the cause of things not working. This camera will not even work when connected through a real hub, let alone through a virtual one. The only way this camera works for me is when it is connected to a usb port directly on the motherboard, running Linux directly on the hardware, can you please try that ? Unfortunately, I'm unable to test with real hardware at the moment. My laptop, which has Linux installed on it is currently out of commission until I can find time to repair it's power adapter. Once I get it fixed, I'll try to retest and we'll go from there. I just tested this driver with my camera using real hardware and it works wonderfully. Thanks for all the hard work. The only thing left to do with this camera is to reverse engineer the compressed video stream in order to improve the frame rate at higher resolutions. Regards, David Ellingsworth -- To unsubscribe from this list: send the line unsubscribe 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.26 and up: 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:Sat Sep 18 19:00:11 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15160:60edc4bd92b7 git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: 991403c594f666a2ed46297c592c60c3b9f4e1e2 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-rc2-i686: ERRORS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec: ERRORS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-c usb device
Bert Haverkamp b...@bertenselena.net writes: Every couple of months I scan this mailing list for the keywords usb and dvb-c, hoping that some new device has shown up that is supported under Linux. It probably isn't much consolation, but you aren't the only one... I currently use a FireDTV DVB-C device, but it isn't all that reliable at least with hts-tvheadend. The only possible replacement I have found is the Anysee E30 Plus series. I don't have one, so I can't say whether they are any good. /Benny -- To unsubscribe from this list: send the line unsubscribe 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 -hg] Warn user that driver is backported and might not work as expected
snip --- a/v4l/scripts/make_kconfig.pl Sun Jun 27 17:17:06 2010 -0300 +++ b/v4l/scripts/make_kconfig.pl Fri Sep 17 11:49:02 2010 -0300 @@ -671,4 +671,13 @@ EOF2 } +print EOF3; +WARNING: This is the V4L/DVB backport tree, with experimental drivers + backported to run on legacy kernels from the development tree at: + http://git.linuxtv.org/media-tree.git. + It is generally safe to use it for testing a new driver or + feature, but its usage on production environments is risky. + Don't use it at production. You've being warned. The last line should read: Don't use it in production. You've been warned. +EOF3 + sleep 5; } -- Regards, David Ellingsworth -- To unsubscribe from this list: send the line unsubscribe 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-c usb device
On 09/18/2010 09:23 PM, Bert Haverkamp wrote: Every couple of months I scan this mailing list for the keywords usb and dvb-c, hoping that some new device has shown up that is supported Currently there is Anysee E30C Plus and Technotrend CT-3650. About Technotrend I am not 100% sure, but I have seen patch for adding DVB-C support for that device. There is many DRX-K devices, but no drivers yet. Also there is TDA10024 based Reddo available in Finland, but I haven't looked it. Thus only reliable one is Anysee. 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: HVR 1600 Distortion
On Sat, Sep 18, 2010 at 8:20 AM, Andy Walls awa...@md.metrocast.net wrote: On Fri, 2010-09-17 at 18:23 -0400, Josh Borke wrote: Thanks for the response! Replies are in line. On Thu, Sep 16, 2010 at 6:48 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-09-15 at 22:54 -0400, Josh Borke wrote: I've recently noticed some distortion coming from my hvr1600 when viewing analog channels. It happens to all analog channels with some slightly better than others. I am running Fedora 12 linux with kernel version 2.6.32.21-166. I know I need to include more information but I'm not sure what to include. Any help would be appreciated. 1. Would you say the distortion is something you would possibly encounter on an analog television set, or does it look uniquely digital? On systems with a long uptime and lots of usage, MPEG encoder firmware could wind up in a screwed up state giving weird output image. Simple solution in this case is to reboot. I'm not sure if I would classify it as uniquely digital. The distortion happens across most of the screen with it being concentrated in the top third. Additionally shows that include black bars the top black bar is seemingly stretched and the image seems like the colors are over-saturated where they colors are brighter. Rebooting had no effect :( OK. 2. Have you ensured your cable plant isn't affecting signal integrity? http://ivtvdriver.org/index.php/Howto:Improve_signal_quality The cable plant hasn't changed the signal strength or integrity as far as I know. OK. Keep it in the back of your mind though. 3. Does this happen with only the RF tuner or only CVBS or only SVideo or more than one of them? If the problem is only with RF, then it could be an incoming signal distortion problem. Do you have cable or an over the air antenna for analog RF? I only have input for the RF tuner. I have cable for analog RF. Please try and test the output of a VCR or DVD play plugged into the HVR-1600. (We don't need sound, just the video.) This will tell us if the problem happens before the CX23418 chip's analog front end (i.e. in the RF and analog tuner) or not. $ v4l2-ctl -d /dev/video0 -n (List of possible inputs displayed) $ v4l2-ctl -d /dev/video0 -i 2 Video input set to 2 (Composite 1) # v4l2-ctl -d /dev/video0 -s ntsc-m Standard set to 1000 $ cat /dev/video0 foo.mpg ^C I only have S-Video but doing this produced a perfect picture. 4. What does v4l2-ctl --log-status show as your analog tuner? Not sure what you mean so I've included the full output: # v4l2-ctl -d /dev/hvr1600 --log-status Status Log: cx18-0: = START STATUS CARD #0 = cx18-0: Version: 1.2.0 Card: Hauppauge HVR-1600 tveeprom 3-0050: Hauppauge model 74041, rev C6B2, serial# 898361 tveeprom 3-0050: MAC address is 00-0D-FE-0D-B5-39 tveeprom 3-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) ^^ OK. You have a board with the same tuner as I have. All I have for an analog RF source is a DTV STB, so a very clean channel 3 is all I have to try and duplicate the problem. tveeprom 3-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 3-0050: audio processor is CX23418 (idx 38) tveeprom 3-0050: decoder processor is CX23418 (idx 31) tveeprom 3-0050: has no radio, has IR receiver, has IR transmitter cx18-0 843: Video signal: present cx18-0 843: Detected format: NTSC-M cx18-0 843: Specified standard: NTSC-M cx18-0 843: Specified video input: Composite 7 cx18-0 843: Specified audioclock freq: 48000 Hz cx18-0 843: Detected audio mode: mono cx18-0 843: Detected audio standard: BTSC cx18-0 843: Audio muted: no cx18-0 843: Audio microcontroller: running cx18-0 843: Configured audio standard: automatic detection cx18-0 843: Configured audio system: BTSC cx18-0 843: Specified audio input: Tuner (In8) cx18-0 843: Preferred audio mode: stereo cx18-0 gpio-reset-ctrl: GPIO: direction 0x3001, value 0x3001 tuner 4-0061: Tuner mode: analog TV tuner 4-0061: Frequency: 175.25 MHz ^^ This is the freq for both US Broadcast and US Cable channel 7 BTW. tuner 4-0061: Standard: 0xb000 cs5345 3-004c: Input: 1 cs5345 3-004c: Volume: 0 dB cx18-0: Video Input: Tuner 1 cx18-0: Audio Input: Tuner 1 cx18-0: GPIO: direction 0x3001, value 0x3001 cx18-0: Tuner: TV cx18-0: Stream: MPEG-2 Program Stream cx18-0: VBI Format: Private packet, IVTV format cx18-0: Video: 720x480, 30 fps cx18-0: Video: MPEG-2, 4x3, Variable Bitrate, 660, Peak 660 cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 384 kbps, Stereo, No
Re: HVR 1600 Distortion
On Sat, Sep 18, 2010 at 8:42 PM, Josh Borke joshbo...@gmail.com wrote: On Sat, Sep 18, 2010 at 8:20 AM, Andy Walls awa...@md.metrocast.net wrote: On Fri, 2010-09-17 at 18:23 -0400, Josh Borke wrote: Thanks for the response! Replies are in line. On Thu, Sep 16, 2010 at 6:48 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-09-15 at 22:54 -0400, Josh Borke wrote: I've recently noticed some distortion coming from my hvr1600 when viewing analog channels. It happens to all analog channels with some slightly better than others. I am running Fedora 12 linux with kernel version 2.6.32.21-166. I know I need to include more information but I'm not sure what to include. Any help would be appreciated. 1. Would you say the distortion is something you would possibly encounter on an analog television set, or does it look uniquely digital? On systems with a long uptime and lots of usage, MPEG encoder firmware could wind up in a screwed up state giving weird output image. Simple solution in this case is to reboot. I'm not sure if I would classify it as uniquely digital. The distortion happens across most of the screen with it being concentrated in the top third. Additionally shows that include black bars the top black bar is seemingly stretched and the image seems like the colors are over-saturated where they colors are brighter. Rebooting had no effect :( OK. 2. Have you ensured your cable plant isn't affecting signal integrity? http://ivtvdriver.org/index.php/Howto:Improve_signal_quality The cable plant hasn't changed the signal strength or integrity as far as I know. OK. Keep it in the back of your mind though. 3. Does this happen with only the RF tuner or only CVBS or only SVideo or more than one of them? If the problem is only with RF, then it could be an incoming signal distortion problem. Do you have cable or an over the air antenna for analog RF? I only have input for the RF tuner. I have cable for analog RF. Please try and test the output of a VCR or DVD play plugged into the HVR-1600. (We don't need sound, just the video.) This will tell us if the problem happens before the CX23418 chip's analog front end (i.e. in the RF and analog tuner) or not. $ v4l2-ctl -d /dev/video0 -n (List of possible inputs displayed) $ v4l2-ctl -d /dev/video0 -i 2 Video input set to 2 (Composite 1) # v4l2-ctl -d /dev/video0 -s ntsc-m Standard set to 1000 $ cat /dev/video0 foo.mpg ^C I only have S-Video but doing this produced a perfect picture. Before debugging any further, it might make sense to install the tuner into a Windows box and make sure it's not just a hardware failure in the can tuner. 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: HVR 1600 Distortion
On Sat, Sep 18, 2010 at 8:58 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sat, Sep 18, 2010 at 8:42 PM, Josh Borke joshbo...@gmail.com wrote: On Sat, Sep 18, 2010 at 8:20 AM, Andy Walls awa...@md.metrocast.net wrote: On Fri, 2010-09-17 at 18:23 -0400, Josh Borke wrote: Thanks for the response! Replies are in line. On Thu, Sep 16, 2010 at 6:48 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-09-15 at 22:54 -0400, Josh Borke wrote: I've recently noticed some distortion coming from my hvr1600 when viewing analog channels. It happens to all analog channels with some slightly better than others. I am running Fedora 12 linux with kernel version 2.6.32.21-166. I know I need to include more information but I'm not sure what to include. Any help would be appreciated. 1. Would you say the distortion is something you would possibly encounter on an analog television set, or does it look uniquely digital? On systems with a long uptime and lots of usage, MPEG encoder firmware could wind up in a screwed up state giving weird output image. Simple solution in this case is to reboot. I'm not sure if I would classify it as uniquely digital. The distortion happens across most of the screen with it being concentrated in the top third. Additionally shows that include black bars the top black bar is seemingly stretched and the image seems like the colors are over-saturated where they colors are brighter. Rebooting had no effect :( OK. 2. Have you ensured your cable plant isn't affecting signal integrity? http://ivtvdriver.org/index.php/Howto:Improve_signal_quality The cable plant hasn't changed the signal strength or integrity as far as I know. OK. Keep it in the back of your mind though. 3. Does this happen with only the RF tuner or only CVBS or only SVideo or more than one of them? If the problem is only with RF, then it could be an incoming signal distortion problem. Do you have cable or an over the air antenna for analog RF? I only have input for the RF tuner. I have cable for analog RF. Please try and test the output of a VCR or DVD play plugged into the HVR-1600. (We don't need sound, just the video.) This will tell us if the problem happens before the CX23418 chip's analog front end (i.e. in the RF and analog tuner) or not. $ v4l2-ctl -d /dev/video0 -n (List of possible inputs displayed) $ v4l2-ctl -d /dev/video0 -i 2 Video input set to 2 (Composite 1) # v4l2-ctl -d /dev/video0 -s ntsc-m Standard set to 1000 $ cat /dev/video0 foo.mpg ^C I only have S-Video but doing this produced a perfect picture. Before debugging any further, it might make sense to install the tuner into a Windows box and make sure it's not just a hardware failure in the can tuner. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com It could be the tuner card, it is over 2 years old...Why would the analog tuner stop functioning while the digital tuner continues to work? Is it because the analog portion goes through a different set of chips? Thanks, -josh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle independent CA devices
On Saturday 18 September 2010 14:23:29 Manu Abraham wrote: On Sat, Sep 18, 2010 at 6:17 AM, rjkm r...@metzlerbros.de wrote: Manu Abraham writes: You still need a mechanism to decide which tuner gets it. First one which opens its own ca device? Sharing the CI (multi-stream decoding) in such an automatic way would also be complicated. I think I will only add such a feature if there is very high demand and rather look into the separate API solution. It would be advantageous, if we do have just a simple input path, where it is not restricted for CA/CI alone. I have some hardware over here, where it has a DMA_TO_DEVICE channel (other than for the SG table), where it can write a TS to any post-processor connected to it, such as a CA/CI device, or even a decoder, for example. In short, it could be anything, to put short. In this case, the device can accept processed stream (muxed TS for multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You can flip some registers for the device, for it to read from userspace, or for that DMA channel to read from the hardware page tables of another DMA channel which is coming from the tuner. Maybe, we just need a simple mechanism/ioctl to select the CA/CI input for the stream to the bridge. ie like a MUX: a 1:n select per adapter, where the CA/CI device has 1 input and there are 'n' sources. It would be nice to have a more general output device. But I have currently no plans to support something like transparent streaming from one input to the output and back inside the driver. Maybe it wasn't very clear ... (Streaming from one input to the output and back inside the driver what you are implementing is not what I had in mind.) Currently for any independant CA device what you need is a stream to the bridge where it can route the same to the CI slot. For a generic device capable of doing any other gimmicks also, what you need is an input to the bridge. So, what I was trying to say is that, let's not limit the input path to CA alone. For explanation sale let's term in as TS_IN The TS_In interface is a simple interface where an application can just write to the TS_IN interface, which goes to the DVB_ringbuffer and hence to the bridge. I think, this is all what it should do. We have 3 application uses cases here, based on different hardware types. 1. Bridge is reading from TS_IN (from a user space application, streams from a single TS) for sending stream to CA, the normal way (All things are fine) 2. Bridge is reading from TS_IN (from a user space application, streams from multiple TS's) for sending to CA. This is also same as (1) but just that the user space application is writing a remuxed stream to TS_IN 3. Bridge is reading from TS_IN (from a userspace application) The bridge has multiple DMA channels. The bridge driver can load page tables from another channel, whereby the bridge is routing to another interface itself completely. This is a hardware feature, so we don't need to get data manually in software from one interface to the other. All this just needs the input path to be generic. An input interface such as TS_IN can feed the stream to an onboard decoder or any other post-processor as described with (3) Only in the case of (2) the application really needs to do some thing in real life, ie to Remux. But you can omit out the application to handle (2). Where somebody can implement it any later stage of time, if there's any interest. I guess nGene can do (1) and (2) So, I wonder whether we should name the interface CA itself, where otherwise it can suit other application use cases as well. In such a case it becomes not limited to CA alone, to put short. Implementing a simple buffering alone (the rest of the necessities with the driver), will make the interface generic. There is already an implementation for some kind of TS input: dvb-apps/test/test_dvr_play.c can be used to write a TS stream to the decoder of the old full-featured card (ttpci driver) through the dvr device. Wouldn't it make sense to use this feature for TS input? CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR 1600 Distortion
Yes it does. Which is nice actually: capture both digital and RF analog at the
same time. :)
Josh Borke joshbo...@gmail.com wrote:
On Sat, Sep 18, 2010 at 8:58 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
On Sat, Sep 18, 2010 at 8:42 PM, Josh Borke joshbo...@gmail.com wrote:
On Sat, Sep 18, 2010 at 8:20 AM, Andy Walls awa...@md.metrocast.net wrote:
On Fri, 2010-09-17 at 18:23 -0400, Josh Borke wrote:
Thanks for the response! Replies are in line.
On Thu, Sep 16, 2010 at 6:48 PM, Andy Walls awa...@md.metrocast.net
wrote:
On Wed, 2010-09-15 at 22:54 -0400, Josh Borke wrote:
I've recently noticed some distortion coming from my hvr1600 when
viewing analog channels. It happens to all analog channels with some
slightly better than others. I am running Fedora 12 linux with kernel
version 2.6.32.21-166.
I know I need to include more information but I'm not sure what to
include. Any help would be appreciated.
1. Would you say the distortion is something you would possibly
encounter on an analog television set, or does it look uniquely
digital? On systems with a long uptime and lots of usage, MPEG encoder
firmware could wind up in a screwed up state giving weird output image.
Simple solution in this case is to reboot.
I'm not sure if I would classify it as uniquely digital. The
distortion happens across most of the screen with it being
concentrated in the top third. Additionally shows that include black
bars the top black bar is seemingly stretched and the image seems like
the colors are over-saturated where they colors are brighter.
Rebooting had no effect :(
OK.
2. Have you ensured your cable plant isn't affecting signal integrity?
http://ivtvdriver.org/index.php/Howto:Improve_signal_quality
The cable plant hasn't changed the signal strength or integrity as far
as I know.
OK. Keep it in the back of your mind though.
3. Does this happen with only the RF tuner or only CVBS or only SVideo
or more than one of them? If the problem is only with RF, then it could
be an incoming signal distortion problem. Do you have cable or an over
the air antenna for analog RF?
I only have input for the RF tuner. I have cable for analog RF.
Please try and test the output of a VCR or DVD play plugged into the
HVR-1600. (We don't need sound, just the video.)
This will tell us if the problem happens before the CX23418 chip's
analog front end (i.e. in the RF and analog tuner) or not.
$ v4l2-ctl -d /dev/video0 -n
(List of possible inputs displayed)
$ v4l2-ctl -d /dev/video0 -i 2
Video input set to 2 (Composite 1)
# v4l2-ctl -d /dev/video0 -s ntsc-m
Standard set to 1000
$ cat /dev/video0 foo.mpg
^C
I only have S-Video but doing this produced a perfect picture.
Before debugging any further, it might make sense to install the tuner
into a Windows box and make sure it's not just a hardware failure in
the can tuner.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
It could be the tuner card, it is over 2 years old...Why would the
analog tuner stop functioning while the digital tuner continues to
work? Is it because the analog portion goes through a different set
of chips?
Thanks,
-josh
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: HVR 1600 Distortion
On Sat, Sep 18, 2010 at 9:09 PM, Josh Borke joshbo...@gmail.com wrote: It could be the tuner card, it is over 2 years old...Why would the analog tuner stop functioning while the digital tuner continues to work? Is it because the analog portion goes through a different set of chips? Yes, the analog portion of the card has a completely separate tuner and demodulator. Don't get me wrong, it's possible that this is a driver issue, but given Andy has the exact same can tuner on his board it probably makes sense for you to do a sanity test of the hardware before any more time is spent investigating the software. 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: [PATCH -hg] Warn user that driver is backported and might not work as expected
Hi, Mauro Carvalho Chehab wrote: Since the migration to -git, less developers are using the -hg tree. Also, some changes are happening upstream that would require much more than just compiling the tree with an older version, to be sure that the backport won't break anything, like the removal of BKL. As normal users might not be aware of those issues, and bug reports may be sent based on a backported tree, add some messages to warn about the usage of a backported experimental (unsupported) tree. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Applied, thanks! Cheers Douglas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -hg] Warn user that driver is backported and might not work as expected
Hi, David Ellingsworth wrote: snip --- a/v4l/scripts/make_kconfig.pl Sun Jun 27 17:17:06 2010 -0300 +++ b/v4l/scripts/make_kconfig.pl Fri Sep 17 11:49:02 2010 -0300 @@ -671,4 +671,13 @@ EOF2 } +print EOF3; +WARNING: This is the V4L/DVB backport tree, with experimental drivers +backported to run on legacy kernels from the development tree at: + http://git.linuxtv.org/media-tree.git. +It is generally safe to use it for testing a new driver or +feature, but its usage on production environments is risky. +Don't use it at production. You've being warned. The last line should read: Don't use it in production. You've been warned. Fixed thanks! Cheers Douglas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
