| Message ID | 20090910152510.6970f8ab@glory.loctelecom.ru (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com> wrote: > Hi All > > This is my next patch. > > Changes: > 1. By default charge pump is ON > 2. For radio mode charge pump set to OFF > 3. Set correct AGC value in radio mode > 4. Add control gain of AGC. > 5. New function simple_get_tv_gain and simple_set_tv_gain for read/write gain of AGC. > 6. Add some code for control gain from saa7134 part. By default this control is OFF 7. When TV card can > manipulate this control, enable it. > > Main changes is control value of AGC TOP in .initdata = tua603x_agc112 array. Use this value for set AGC TOP after set freq of TV. > > I don't understand how to correct call new function for read/write value of AGC TOP. > > What you think about it?? > [patch snipped] > > > With my best regards, Dmitry. Dmitry, The direct usage of .initdata and .sleepdata is probably unnecessary here -- If you trace how the tuner-simple driver works, you'll find that simply having these fields defined will cause these bytes to be written at the appropriate moment. However, for the actual sake of setting this gain value, I'm not sure that initdata / sleep data is the right place for it either. (I know that I recommended something like this at first, but at the time I didn't realize that there is a range of six acceptable values for this field) What I would still like to understand is: Who will be changing this value? I see that you've added a control to the saa7134 driver -- is this to be manipulated from userspace? Under what conditions will somebody want to change this value? How will users know that they need to alter this gain value? Apologies for the late response. Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 14 Sep 2009 08:55:22 -0400 Michael Krufky <mkrufky@kernellabs.com> wrote: > On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com> > wrote: > > Hi All > > > > This is my next patch. > > > > Changes: > > 1. By default charge pump is ON > > 2. For radio mode charge pump set to OFF > > 3. Set correct AGC value in radio mode > > 4. Add control gain of AGC. > > 5. New function simple_get_tv_gain and simple_set_tv_gain for > > read/write gain of AGC. 6. Add some code for control gain from > > saa7134 part. By default this control is OFF 7. When TV card can > > manipulate this control, enable it. > > > > Main changes is control value of AGC TOP in .initdata = > > tua603x_agc112 array. Use this value for set AGC TOP after set freq > > of TV. > > > > I don't understand how to correct call new function for read/write > > value of AGC TOP. > > > > What you think about it?? > > > > [patch snipped] > > > > > > > With my best regards, Dmitry. > > Dmitry, > > The direct usage of .initdata and .sleepdata is probably unnecessary > here -- If you trace how the tuner-simple driver works, you'll find > that simply having these fields defined will cause these bytes to be > written at the appropriate moment. > > However, for the actual sake of setting this gain value, I'm not sure > that initdata / sleep data is the right place for it either. (I know > that I recommended something like this at first, but at the time I > didn't realize that there is a range of six acceptable values for this > field) > > What I would still like to understand is: Who will be changing this > value? I see that you've added a control to the saa7134 driver -- is > this to be manipulated from userspace? Yes > Under what conditions will somebody want to change this value? for SECAM with strong signal we have wide white crap on the screen. Need reduce value of AGC TOP. For weak signal need increase value of AGC TOP Ajust value of AGC TOP can get more better image quality. > How will users know that they need to alter this gain value? By default use value from .initdata v4l2-ctl can modify this value or via some plugins for TV wach programm. End-user programm for watch TV IMHO now is very poor. With my best regards, Dmitry. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote: > On Mon, 14 Sep 2009 08:55:22 -0400 > Michael Krufky <mkrufky@kernellabs.com> wrote: > >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com> >> wrote: >> > Hi All >> > >> > This is my next patch. >> > >> > Changes: >> > 1. By default charge pump is ON >> > 2. For radio mode charge pump set to OFF >> > 3. Set correct AGC value in radio mode >> > 4. Add control gain of AGC. >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for >> > read/write gain of AGC. 6. Add some code for control gain from >> > saa7134 part. By default this control is OFF 7. When TV card can >> > manipulate this control, enable it. >> > >> > Main changes is control value of AGC TOP in .initdata = >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq >> > of TV. >> > >> > I don't understand how to correct call new function for read/write >> > value of AGC TOP. >> > >> > What you think about it?? >> > >> >> [patch snipped] >> >> > >> > >> > With my best regards, Dmitry. >> >> Dmitry, >> >> The direct usage of .initdata and .sleepdata is probably unnecessary >> here -- Â If you trace how the tuner-simple driver works, you'll find >> that simply having these fields defined will cause these bytes to be >> written at the appropriate moment. >> >> However, for the actual sake of setting this gain value, I'm not sure >> that initdata / sleep data is the right place for it either. Â (I know >> that I recommended something like this at first, but at the time I >> didn't realize that there is a range of six acceptable values for this >> field) >> >> What I would still like to understand is: Â Who will be changing this >> value? Â I see that you've added a control to the saa7134 driver -- is >> this to be manipulated from userspace? > > Yes > >> Under what conditions will somebody want to change this value? > > for SECAM with strong signal we have wide white crap on the screen. > Need reduce value of AGC TOP. > > For weak signal need increase value of AGC TOP > Ajust value of AGC TOP can get more better image quality. > >> How will users know that they need to alter this gain value? > > By default use value from .initdata > v4l2-ctl can modify this value or via some plugins for TV wach programm. > > End-user programm for watch TV IMHO now is very poor. > > With my best regards, Dmitry. > I have to admit that I am not familiar enough with SECAM myself to see this kind of trouble. For NTSC and PAL, tvtime is a great application -- the only shortcoming that bothers me about tvtime is lack of audio support. One must rely on a separate mechanism to hear audio, whether it's a patch cable from the tv tuner to the sound board, or a separate application decoding DMA audio. ...but that is not what this email thread is about. As far as simple tuning and analog television viewing goes, tvtime rocks. Is it really that difficult for SECAM users? In summary, you are telling us that we need to add userspace controls to handle gain control, for tuning SECAM. I am going to have to ask for help on this topic from those cc'd on this email. (Adding Hans Verkuil, as I value his opinion for controls and dealing with video standards in high regard) Personally, I don't quite understand why we would need to add such controls NOW, while we've supported this video standard for years already. I am not arguing against this in any way, but I dont feel like I'm qualified to accept this addition without hearing the opinions of others first. Can somebody help to shed some light? Cheers, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky: > On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote: > > On Mon, 14 Sep 2009 08:55:22 -0400 > > Michael Krufky <mkrufky@kernellabs.com> wrote: > > > >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com> > >> wrote: > >> > Hi All > >> > > >> > This is my next patch. > >> > > >> > Changes: > >> > 1. By default charge pump is ON > >> > 2. For radio mode charge pump set to OFF > >> > 3. Set correct AGC value in radio mode > >> > 4. Add control gain of AGC. > >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for > >> > read/write gain of AGC. 6. Add some code for control gain from > >> > saa7134 part. By default this control is OFF 7. When TV card can > >> > manipulate this control, enable it. > >> > > >> > Main changes is control value of AGC TOP in .initdata = > >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq > >> > of TV. > >> > > >> > I don't understand how to correct call new function for read/write > >> > value of AGC TOP. > >> > > >> > What you think about it?? > >> > > >> > >> [patch snipped] > >> > >> > > >> > > >> > With my best regards, Dmitry. > >> > >> Dmitry, > >> > >> The direct usage of .initdata and .sleepdata is probably unnecessary > >> here -- If you trace how the tuner-simple driver works, you'll find > >> that simply having these fields defined will cause these bytes to be > >> written at the appropriate moment. > >> > >> However, for the actual sake of setting this gain value, I'm not sure > >> that initdata / sleep data is the right place for it either. (I know > >> that I recommended something like this at first, but at the time I > >> didn't realize that there is a range of six acceptable values for this > >> field) > >> > >> What I would still like to understand is: Who will be changing this > >> value? I see that you've added a control to the saa7134 driver -- is > >> this to be manipulated from userspace? > > > > Yes > > > >> Under what conditions will somebody want to change this value? > > > > for SECAM with strong signal we have wide white crap on the screen. > > Need reduce value of AGC TOP. > > > > For weak signal need increase value of AGC TOP > > Ajust value of AGC TOP can get more better image quality. > > > >> How will users know that they need to alter this gain value? > > > > By default use value from .initdata > > v4l2-ctl can modify this value or via some plugins for TV wach programm. > > > > End-user programm for watch TV IMHO now is very poor. > > > > With my best regards, Dmitry. > > > > I have to admit that I am not familiar enough with SECAM myself to see > this kind of trouble. For NTSC and PAL, tvtime is a great application > -- the only shortcoming that bothers me about tvtime is lack of audio > support. One must rely on a separate mechanism to hear audio, whether > it's a patch cable from the tv tuner to the sound board, or a separate > application decoding DMA audio. ...but that is not what this email > thread is about. > > As far as simple tuning and analog television viewing goes, tvtime > rocks. Is it really that difficult for SECAM users? > > In summary, you are telling us that we need to add userspace controls > to handle gain control, for tuning SECAM. I am going to have to ask > for help on this topic from those cc'd on this email. (Adding Hans > Verkuil, as I value his opinion for controls and dealing with video > standards in high regard) > > Personally, I don't quite understand why we would need to add such > controls NOW, while we've supported this video standard for years > already. I am not arguing against this in any way, but I dont feel > like I'm qualified to accept this addition without hearing the > opinions of others first. > > Can somebody help to shed some light? > > Cheers, > > Mike Mike, i did discuss this with Dmitri a lot on the list previously. I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in China, to convince him not to do that for the original Philips tuners. Andy was also pretty active on it, thanks for your help. However, it is for now only about that TCL MK3, using different filters than the original Philips stuff, and their labs have clear results, that they can improve SECAM-DK this way for their users. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 15, 2009 at 12:43 AM, hermann pitton <hermann-pitton@arcor.de> wrote: > > Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky: >> On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote: >> > On Mon, 14 Sep 2009 08:55:22 -0400 >> > Michael Krufky <mkrufky@kernellabs.com> wrote: >> > >> >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com> >> >> wrote: >> >> > Hi All >> >> > >> >> > This is my next patch. >> >> > >> >> > Changes: >> >> > 1. By default charge pump is ON >> >> > 2. For radio mode charge pump set to OFF >> >> > 3. Set correct AGC value in radio mode >> >> > 4. Add control gain of AGC. >> >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for >> >> > read/write gain of AGC. 6. Add some code for control gain from >> >> > saa7134 part. By default this control is OFF 7. When TV card can >> >> > manipulate this control, enable it. >> >> > >> >> > Main changes is control value of AGC TOP in .initdata = >> >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq >> >> > of TV. >> >> > >> >> > I don't understand how to correct call new function for read/write >> >> > value of AGC TOP. >> >> > >> >> > What you think about it?? >> >> > >> >> >> >> [patch snipped] >> >> >> >> > >> >> > >> >> > With my best regards, Dmitry. >> >> >> >> Dmitry, >> >> >> >> The direct usage of .initdata and .sleepdata is probably unnecessary >> >> here -- Â If you trace how the tuner-simple driver works, you'll find >> >> that simply having these fields defined will cause these bytes to be >> >> written at the appropriate moment. >> >> >> >> However, for the actual sake of setting this gain value, I'm not sure >> >> that initdata / sleep data is the right place for it either. Â (I know >> >> that I recommended something like this at first, but at the time I >> >> didn't realize that there is a range of six acceptable values for this >> >> field) >> >> >> >> What I would still like to understand is: Â Who will be changing this >> >> value? Â I see that you've added a control to the saa7134 driver -- is >> >> this to be manipulated from userspace? >> > >> > Yes >> > >> >> Under what conditions will somebody want to change this value? >> > >> > for SECAM with strong signal we have wide white crap on the screen. >> > Need reduce value of AGC TOP. >> > >> > For weak signal need increase value of AGC TOP >> > Ajust value of AGC TOP can get more better image quality. >> > >> >> How will users know that they need to alter this gain value? >> > >> > By default use value from .initdata >> > v4l2-ctl can modify this value or via some plugins for TV wach programm. >> > >> > End-user programm for watch TV IMHO now is very poor. >> > >> > With my best regards, Dmitry. >> > >> >> I have to admit that I am not familiar enough with SECAM myself to see >> this kind of trouble. Â For NTSC and PAL, tvtime is a great application >> -- the only shortcoming that bothers me about tvtime is lack of audio >> support. Â One must rely on a separate mechanism to hear audio, whether >> it's a patch cable from the tv tuner to the sound board, or a separate >> application decoding DMA audio. Â ...but that is not what this email >> thread is about. >> >> As far as simple tuning and analog television viewing goes, tvtime >> rocks. Â Is it really that difficult for SECAM users? >> >> In summary, you are telling us that we need to add userspace controls >> to handle gain control, for tuning SECAM. Â I am going to have to ask >> for help on this topic from those cc'd on this email. Â (Adding Hans >> Verkuil, as I value his opinion for controls and dealing with video >> standards in high regard) >> >> Personally, I don't quite understand why we would need to add such >> controls NOW, while we've supported this video standard for years >> already. Â I am not arguing against this in any way, but I dont feel >> like I'm qualified to accept this addition without hearing the >> opinions of others first. >> >> Can somebody help to shed some light? >> >> Cheers, >> >> Mike > > Mike, > > i did discuss this with Dmitri a lot on the list previously. > > I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in > China, to convince him not to do that for the original Philips tuners. > > Andy was also pretty active on it, thanks for your help. > > However, it is for now only about that TCL MK3, using different filters > than the original Philips stuff, and their labs have clear results, that > they can improve SECAM-DK this way for their users. Thanks for the comment, Hermann. Do you think there is any way that we can automate this without having to expose an additional user control? If you believe that it's necessary, I am fine with adding this, but I will need Mauro to agree on it as well -- that's why I'm asking for some argument points. Some questions that he might ask -- why do we need this in the saa7134 driver but not the other drivers? Is this specific to this TCL MK3 only? Could doing this help to improve SECAM support for users of other tuners? Cheers, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Am Dienstag, den 15.09.2009, 00:55 -0400 schrieb Michael Krufky: > On Tue, Sep 15, 2009 at 12:43 AM, hermann pitton > <hermann-pitton@arcor.de> wrote: > > > > Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky: > >> On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote: > >> > On Mon, 14 Sep 2009 08:55:22 -0400 > >> > Michael Krufky <mkrufky@kernellabs.com> wrote: > >> > > >> >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com> > >> >> wrote: > >> >> > Hi All > >> >> > > >> >> > This is my next patch. > >> >> > > >> >> > Changes: > >> >> > 1. By default charge pump is ON > >> >> > 2. For radio mode charge pump set to OFF > >> >> > 3. Set correct AGC value in radio mode > >> >> > 4. Add control gain of AGC. > >> >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for > >> >> > read/write gain of AGC. 6. Add some code for control gain from > >> >> > saa7134 part. By default this control is OFF 7. When TV card can > >> >> > manipulate this control, enable it. > >> >> > > >> >> > Main changes is control value of AGC TOP in .initdata = > >> >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq > >> >> > of TV. > >> >> > > >> >> > I don't understand how to correct call new function for read/write > >> >> > value of AGC TOP. > >> >> > > >> >> > What you think about it?? > >> >> > > >> >> > >> >> [patch snipped] > >> >> > >> >> > > >> >> > > >> >> > With my best regards, Dmitry. > >> >> > >> >> Dmitry, > >> >> > >> >> The direct usage of .initdata and .sleepdata is probably unnecessary > >> >> here -- If you trace how the tuner-simple driver works, you'll find > >> >> that simply having these fields defined will cause these bytes to be > >> >> written at the appropriate moment. > >> >> > >> >> However, for the actual sake of setting this gain value, I'm not sure > >> >> that initdata / sleep data is the right place for it either. (I know > >> >> that I recommended something like this at first, but at the time I > >> >> didn't realize that there is a range of six acceptable values for this > >> >> field) > >> >> > >> >> What I would still like to understand is: Who will be changing this > >> >> value? I see that you've added a control to the saa7134 driver -- is > >> >> this to be manipulated from userspace? > >> > > >> > Yes > >> > > >> >> Under what conditions will somebody want to change this value? > >> > > >> > for SECAM with strong signal we have wide white crap on the screen. > >> > Need reduce value of AGC TOP. > >> > > >> > For weak signal need increase value of AGC TOP > >> > Ajust value of AGC TOP can get more better image quality. > >> > > >> >> How will users know that they need to alter this gain value? > >> > > >> > By default use value from .initdata > >> > v4l2-ctl can modify this value or via some plugins for TV wach programm. > >> > > >> > End-user programm for watch TV IMHO now is very poor. > >> > > >> > With my best regards, Dmitry. > >> > > >> > >> I have to admit that I am not familiar enough with SECAM myself to see > >> this kind of trouble. For NTSC and PAL, tvtime is a great application > >> -- the only shortcoming that bothers me about tvtime is lack of audio > >> support. One must rely on a separate mechanism to hear audio, whether > >> it's a patch cable from the tv tuner to the sound board, or a separate > >> application decoding DMA audio. ...but that is not what this email > >> thread is about. > >> > >> As far as simple tuning and analog television viewing goes, tvtime > >> rocks. Is it really that difficult for SECAM users? > >> > >> In summary, you are telling us that we need to add userspace controls > >> to handle gain control, for tuning SECAM. I am going to have to ask > >> for help on this topic from those cc'd on this email. (Adding Hans > >> Verkuil, as I value his opinion for controls and dealing with video > >> standards in high regard) > >> > >> Personally, I don't quite understand why we would need to add such > >> controls NOW, while we've supported this video standard for years > >> already. I am not arguing against this in any way, but I dont feel > >> like I'm qualified to accept this addition without hearing the > >> opinions of others first. > >> > >> Can somebody help to shed some light? > >> > >> Cheers, > >> > >> Mike > > > > Mike, > > > > i did discuss this with Dmitri a lot on the list previously. > > > > I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in > > China, to convince him not to do that for the original Philips tuners. > > > > Andy was also pretty active on it, thanks for your help. > > > > However, it is for now only about that TCL MK3, using different filters > > than the original Philips stuff, and their labs have clear results, that > > they can improve SECAM-DK this way for their users. > > Thanks for the comment, Hermann. > > Do you think there is any way that we can automate this without having > to expose an additional user control? > > If you believe that it's necessary, I am fine with adding this, but I > will need Mauro to agree on it as well -- that's why I'm asking for > some argument points. We can automate this. Just ignore Chinese tuners ... Don't forget, Hauppauge is still leading on that. Likely we support hundreds already, since main chips are the same and they have to fight on the discrets to get some cent out per device. > Some questions that he might ask -- why do we need this in the saa7134 > driver but not the other drivers? Is this specific to this TCL MK3 > only? Could doing this help to improve SECAM support for users of > other tuners? I don't fear Mauro's questions ;), but those not aware off, including me. Simple answer. I'm not on any SECAM-DK and can't tell _at all_. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 15 September 2009 06:18:55 Michael Krufky wrote: > On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote: > > On Mon, 14 Sep 2009 08:55:22 -0400 > > Michael Krufky <mkrufky@kernellabs.com> wrote: > > > >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com> > >> wrote: > >> > Hi All > >> > > >> > This is my next patch. > >> > > >> > Changes: > >> > 1. By default charge pump is ON > >> > 2. For radio mode charge pump set to OFF > >> > 3. Set correct AGC value in radio mode > >> > 4. Add control gain of AGC. > >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for > >> > read/write gain of AGC. 6. Add some code for control gain from > >> > saa7134 part. By default this control is OFF 7. When TV card can > >> > manipulate this control, enable it. > >> > > >> > Main changes is control value of AGC TOP in .initdata = > >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq > >> > of TV. > >> > > >> > I don't understand how to correct call new function for read/write > >> > value of AGC TOP. > >> > > >> > What you think about it?? > >> > > >> > >> [patch snipped] > >> > >> > > >> > > >> > With my best regards, Dmitry. > >> > >> Dmitry, > >> > >> The direct usage of .initdata and .sleepdata is probably unnecessary > >> here -- Â If you trace how the tuner-simple driver works, you'll find > >> that simply having these fields defined will cause these bytes to be > >> written at the appropriate moment. > >> > >> However, for the actual sake of setting this gain value, I'm not sure > >> that initdata / sleep data is the right place for it either. Â (I know > >> that I recommended something like this at first, but at the time I > >> didn't realize that there is a range of six acceptable values for this > >> field) > >> > >> What I would still like to understand is: Â Who will be changing this > >> value? Â I see that you've added a control to the saa7134 driver -- is > >> this to be manipulated from userspace? > > > > Yes > > > >> Under what conditions will somebody want to change this value? > > > > for SECAM with strong signal we have wide white crap on the screen. > > Need reduce value of AGC TOP. > > > > For weak signal need increase value of AGC TOP > > Ajust value of AGC TOP can get more better image quality. > > > >> How will users know that they need to alter this gain value? > > > > By default use value from .initdata > > v4l2-ctl can modify this value or via some plugins for TV wach programm. > > > > End-user programm for watch TV IMHO now is very poor. > > > > With my best regards, Dmitry. > > > > I have to admit that I am not familiar enough with SECAM myself to see > this kind of trouble. For NTSC and PAL, tvtime is a great application > -- the only shortcoming that bothers me about tvtime is lack of audio > support. One must rely on a separate mechanism to hear audio, whether > it's a patch cable from the tv tuner to the sound board, or a separate > application decoding DMA audio. ...but that is not what this email > thread is about. > > As far as simple tuning and analog television viewing goes, tvtime > rocks. Is it really that difficult for SECAM users? > > In summary, you are telling us that we need to add userspace controls > to handle gain control, for tuning SECAM. I am going to have to ask > for help on this topic from those cc'd on this email. (Adding Hans > Verkuil, as I value his opinion for controls and dealing with video > standards in high regard) > > Personally, I don't quite understand why we would need to add such > controls NOW, while we've supported this video standard for years > already. I am not arguing against this in any way, but I dont feel > like I'm qualified to accept this addition without hearing the > opinions of others first. > > Can somebody help to shed some light? It's the first time I've heard about SECAM and AGC-TOP problems. I do know that the TOP value is standard-dependent, although the datasheets recommend different SECAM-L values only. So I can imagine that in some cases you would like to adjust the TOP value a bit. The problem is that end-users will have no idea what to do with a control like that. It falls into the category of 'advanced controls' that might be nice to add but is only for very advanced users or applications. The proposed media controller actually gives you a way of implementing that as tuner-specific controls that do not show up in the regular /dev/videoX control list. I have no problems adding an AGC-TOP control as a tuner-specific control, but adding it as a generic control is a bad idea IMHO. Regards, Hans
On Tue, 2009-09-15 at 08:26 +0200, Hans Verkuil wrote: > On Tuesday 15 September 2009 06:18:55 Michael Krufky wrote: > > On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote: > > Personally, I don't quite understand why we would need to add such > > controls NOW, while we've supported this video standard for years > > already. I am not arguing against this in any way, but I dont feel > > like I'm qualified to accept this addition without hearing the > > opinions of others first. > > > > Can somebody help to shed some light? > > It's the first time I've heard about SECAM and AGC-TOP problems. I do know > that the TOP value is standard-dependent, although the datasheets recommend > different SECAM-L values only. So I can imagine that in some cases you would > like to adjust the TOP value a bit. > > The problem is that end-users will have no idea what to do with a control like > that. It falls into the category of 'advanced controls' that might be nice to > add but is only for very advanced users or applications. The AGC Take Over Point (TOP) is the signal level at which the 2nd stage of the amplifier chain (after the IF filter) takes over gain control from the 1st stage in the amplifier chain. The idea is to maximize overall noise figure by boosting small signals as needed, but avoiding hittng amplifer non-linearities that generate intermodulation products (i.e. spectral "splatter"). The TOP setting depends on the TV standard *and* the attenuation through the IF filter. I'm fairly sure, it is something that one probably should not change to a value different from the manufacturer's recommendation for a particular TV standard, unless you are dealing with input signals in a very controlled, known range aor you have taken measurments inside the tuner and precisely know the loss through the IF filter. If the user doesn't understand how the AGC-TOP setting will affect his overall system noise figure, for all inoming signal strengths, then the user shouldn't change it. (IMO) > The proposed media controller actually gives you a way of implementing that > as tuner-specific controls that do not show up in the regular /dev/videoX > control list. I have no problems adding an AGC-TOP control as a tuner-specific > control, but adding it as a generic control is a bad idea IMHO. If needed, it should be an advanced control or, dare I say, a tunable via sysfs. Setting the TOP wrong will simply degrade reception for the the general case of an unknown incoming signal level. The tuner-sumple code has initialization values for TOP. Also there are some module options for the user to fix TOP to a value, IIRC. Both are rather inflexible for someone who does want to manipulate the TOP in an environment where the incoming RF signal levels are controlled. Regards, Andy > Regards, > > Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2009-09-15 at 00:55 -0400, Michael Krufky wrote: > On Tue, Sep 15, 2009 at 12:43 AM, hermann pitton > <hermann-pitton@arcor.de> wrote: > > > > Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky: > >> On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote: > >> > On Mon, 14 Sep 2009 08:55:22 -0400 > >> > Michael Krufky <mkrufky@kernellabs.com> wrote: > >> > > >> >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com> > >> >> wrote: > >> >> > Hi All > >> >> > > >> >> > This is my next patch. > >> >> > > >> >> > Changes: > >> >> > 1. By default charge pump is ON > >> >> > 2. For radio mode charge pump set to OFF > >> >> > 3. Set correct AGC value in radio mode > >> >> > 4. Add control gain of AGC. > >> >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for > >> >> > read/write gain of AGC. 6. Add some code for control gain from > >> >> > saa7134 part. By default this control is OFF 7. When TV card can > >> >> > manipulate this control, enable it. > >> >> > > >> >> > Main changes is control value of AGC TOP in .initdata = > >> >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq > >> >> > of TV. > >> >> > > >> >> > I don't understand how to correct call new function for read/write > >> >> > value of AGC TOP. > >> >> > > >> >> > What you think about it?? > >> >> > > >> >> > >> >> [patch snipped] > >> >> > >> >> > > >> >> > > >> >> > With my best regards, Dmitry. > >> >> > >> >> Dmitry, > >> >> > >> >> The direct usage of .initdata and .sleepdata is probably unnecessary > >> >> here -- If you trace how the tuner-simple driver works, you'll find > >> >> that simply having these fields defined will cause these bytes to be > >> >> written at the appropriate moment. > >> >> > >> >> However, for the actual sake of setting this gain value, I'm not sure > >> >> that initdata / sleep data is the right place for it either. (I know > >> >> that I recommended something like this at first, but at the time I > >> >> didn't realize that there is a range of six acceptable values for this > >> >> field) > >> >> > >> >> What I would still like to understand is: Who will be changing this > >> >> value? I see that you've added a control to the saa7134 driver -- is > >> >> this to be manipulated from userspace? > >> > > >> > Yes > >> > > >> >> Under what conditions will somebody want to change this value? > >> > > >> > for SECAM with strong signal we have wide white crap on the screen. > >> > Need reduce value of AGC TOP. > >> > > >> > For weak signal need increase value of AGC TOP > >> > Ajust value of AGC TOP can get more better image quality. > >> > > >> >> How will users know that they need to alter this gain value? > >> > > >> > By default use value from .initdata > >> > v4l2-ctl can modify this value or via some plugins for TV wach programm. > >> > > >> > End-user programm for watch TV IMHO now is very poor. > >> > > >> > With my best regards, Dmitry. > >> > > >> > >> I have to admit that I am not familiar enough with SECAM myself to see > >> this kind of trouble. For NTSC and PAL, tvtime is a great application > >> -- the only shortcoming that bothers me about tvtime is lack of audio > >> support. One must rely on a separate mechanism to hear audio, whether > >> it's a patch cable from the tv tuner to the sound board, or a separate > >> application decoding DMA audio. ...but that is not what this email > >> thread is about. > >> > >> As far as simple tuning and analog television viewing goes, tvtime > >> rocks. Is it really that difficult for SECAM users? > >> > >> In summary, you are telling us that we need to add userspace controls > >> to handle gain control, for tuning SECAM. I am going to have to ask > >> for help on this topic from those cc'd on this email. (Adding Hans > >> Verkuil, as I value his opinion for controls and dealing with video > >> standards in high regard) > >> > >> Personally, I don't quite understand why we would need to add such > >> controls NOW, while we've supported this video standard for years > >> already. I am not arguing against this in any way, but I dont feel > >> like I'm qualified to accept this addition without hearing the > >> opinions of others first. > >> > >> Can somebody help to shed some light? > >> > >> Cheers, > >> > >> Mike > > > > Mike, > > > > i did discuss this with Dmitri a lot on the list previously. > > > > I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in > > China, to convince him not to do that for the original Philips tuners. > > > > Andy was also pretty active on it, thanks for your help. > > > > However, it is for now only about that TCL MK3, using different filters > > than the original Philips stuff, and their labs have clear results, that > > they can improve SECAM-DK this way for their users. > > Thanks for the comment, Hermann. > > Do you think there is any way that we can automate this without having > to expose an additional user control? We should automate this. 1. The user will generally be incapable of setting it properly for a number of reasons. 2. The tuner modules/subdevs are aware of the standards changes via .s_std calls, so they should be able to set the TOP when needed. 3. The TOP also needs to be set for FM radio mode on tuners that support FM. Problems with proper automation of this feature: 1. We have many overloaded tuner definitions: a single definition is used for multiple tuner models of varying types. These tuners *may* need slightly different TOP settings; thus requiring splitting out to separate tuner definitions. Maybe many won't. 2. Only the manufacturer has the engineering design data to say what the proper TOP should be. That's hard to get for Leading suppliers. I have no idea how much harder it would be for the knockoffs and clones. Forget getting the proper values for counterfits. 3. A manufacturer like Dmitry's company can take measurments on specimens that have been opened up, but it requires going through a range of video input signal levels and a test on a single device from a production run may not be representative of the worst case in that tuner assembly's design. 4. Analog OTA is DEAD in the US; cable will follow in 2 years or so. My personal level of caring about analog RF tuners is low. > If you believe that it's necessary, I am fine with adding this, but I > will need Mauro to agree on it as well -- that's why I'm asking for > some argument points. > Some questions that he might ask -- why do we need this in the saa7134 > driver but not the other drivers? Is this specific to this TCL MK3 > only? Could doing this help to improve SECAM support for users of > other tuners? This is about optimizing receiver system nosie figure under a range of RF signal levels. The losses before the first gain stage dominate the noise figure, and the gain of the first stage mitigates the noise contributions of the components behind it. The higher the gain you can maintain in the first stage without clipping/distortion, the better your overall receiver noise figure, and the better your SNR. The worst thing that can happen is a strong signal coming in and the TOP being set to high (I think - I'm tired), so that the signal experiences non-linear distortion in the first stage (Osc/Mixer and IF amplifier). Here's a quick tutorial on the concept: http://www.comsec.com/usrp/microtune/NF_tutorial.pdf This is sometimes a problem that's *not* solvable with TOP settings for some tuners, as the AGC signal from the sencond stage (IF demodulator) is not fed to the first stage's AGC. It all depends on how the manufacturer wired up the tuner internals. Regards, Andy > Cheers, > > Mike > -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, den 15.09.2009, 11:17 -0400 schrieb Gene Heskett: > On Tuesday 15 September 2009, Andy Walls wrote: > >On Tue, 2009-09-15 at 08:26 +0200, Hans Verkuil wrote: > >> On Tuesday 15 September 2009 06:18:55 Michael Krufky wrote: > >> > On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> > >> > wrote: > >> > > >> > Personally, I don't quite understand why we would need to add such > >> > controls NOW, while we've supported this video standard for years > >> > already. I am not arguing against this in any way, but I dont feel > >> > like I'm qualified to accept this addition without hearing the > >> > opinions of others first. > >> > > >> > Can somebody help to shed some light? > >> > >> It's the first time I've heard about SECAM and AGC-TOP problems. I do > >> know that the TOP value is standard-dependent, although the datasheets > >> recommend different SECAM-L values only. So I can imagine that in some > >> cases you would like to adjust the TOP value a bit. > >> > >> The problem is that end-users will have no idea what to do with a control > >> like that. It falls into the category of 'advanced controls' that might > >> be nice to add but is only for very advanced users or applications. > > > >The AGC Take Over Point (TOP) is the signal level at which the 2nd stage > >of the amplifier chain (after the IF filter) takes over gain control > >from the 1st stage in the amplifier chain. The idea is to maximize > >overall noise figure by boosting small signals as needed, but avoiding > >hittng amplifer non-linearities that generate intermodulation products > >(i.e. spectral "splatter"). > > > >The TOP setting depends on the TV standard *and* the attenuation through > >the IF filter. I'm fairly sure, it is something that one probably > >should not change to a value different from the manufacturer's > >recommendation for a particular TV standard, unless you are dealing with > >input signals in a very controlled, known range aor you have taken > >measurments inside the tuner and precisely know the loss through the IF > >filter. If the user doesn't understand how the AGC-TOP setting will > >affect his overall system noise figure, for all inoming signal > >strengths, then the user shouldn't change it. (IMO) > > As a retired broadcast engineer, I can say that generally speaking, this is a > knob that shouldn't be enabled. It may in some cases be able to get a db's > worth of improvement, but the potential for worsening it by many db, by > someone who doesn't understand the interactions, is much too high. Given a > knob, it will be tweaked, usually detrimentally. you likely get more readers on linux-media@vger.kernel.org these days, which was considered the right thing to change to next, but, unlike the dvb ML, video4linux still does not give any advice to the users to change over to vger. The Beholder Labs initially planed to introduce it to all tuners around, including all Multi Europe Philips FM1216ME MK3. We previously had separate tuners for Russia, maybe only caused by the different radio bandwidth, but the point when that changed, and it did, is still not fully investigated. The case here now is, that we eventually have to deal with at least two issues. One is known as "Secam fire" ... No such complaints on the original Philips tuners during the last four years so far. The other one is, that believed _one to one_ Chinese clones of the original Philips tuners, still using the same Philips chips, have different SAW filters. My assumption so far is, that they are not as linear as claimed over the covered (uncovered ;) frequency ranges, some ups and downs, and that is what Dmitry tries to compensate in software. And least their labs have good results for that ... ;) The Russian border to China is very long, Dmitry told they can tweak those tuners to receive, maybe somehow limited, even Chinese broadcast. We have some special case here, so I don't tell just ignore it per se, but we are also not forced to please some undocumented, maybe wrong documented, hardware. Cheers, Hermann > >> The proposed media controller actually gives you a way of implementing > >> that as tuner-specific controls that do not show up in the regular > >> /dev/videoX control list. I have no problems adding an AGC-TOP control as > >> a tuner-specific control, but adding it as a generic control is a bad > >> idea IMHO. > > > >If needed, it should be an advanced control or, dare I say, a tunable > >via sysfs. Setting the TOP wrong will simply degrade reception for the > >the general case of an unknown incoming signal level. > > > >The tuner-sumple code has initialization values for TOP. Also there are > >some module options for the user to fix TOP to a value, IIRC. Both are > >rather inflexible for someone who does want to manipulate the TOP in an > >environment where the incoming RF signal levels are controlled. > > > >Regards, > >Andy > > > >> Regards, > >> > >> Hans > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff -r 3f7e382dfae5 linux/drivers/media/common/tuners/tuner-simple.c --- a/linux/drivers/media/common/tuners/tuner-simple.c Sun Aug 16 21:53:17 2009 -0300 +++ b/linux/drivers/media/common/tuners/tuner-simple.c Thu Sep 10 06:05:49 2009 +1000 @@ -144,6 +144,7 @@ case TUNER_PHILIPS_FM1256_IH3: case TUNER_LG_NTSC_TAPE: case TUNER_TCL_MF02GIP_5N: + case TUNER_TCL_MFPE05_2: return ((status & TUNER_SIGNAL) == TUNER_STEREO_MK3); default: return status & TUNER_STEREO; @@ -491,6 +492,18 @@ "(should be 4)\n", rc); break; } + case TUNER_TCL_MFPE05_2: + { + + printk("posttune TCL_MFPE05_2\r\n"); + + if (priv->tun->initdata) { + printk("write AUX byte = 0x%X",priv->tun->initdata[2]); + simple_set_aux_byte(fe, config, priv->tun->initdata[2]); + } + + break; + } } return 0; @@ -499,6 +512,7 @@ static int simple_radio_bandswitch(struct dvb_frontend *fe, u8 *buffer) { struct tuner_simple_priv *priv = fe->tuner_priv; + u8 rc; switch (priv->type) { case TUNER_TENA_9533_DI: @@ -513,6 +527,11 @@ case TUNER_LG_NTSC_TAPE: case TUNER_PHILIPS_FM1256_IH3: case TUNER_TCL_MF02GIP_5N: + buffer[3] = 0x19; + break; + case TUNER_TCL_MFPE05_2: + rc = buffer[2]&0xbf; + buffer[2] = rc; /* Switch OFF Charge Pump */ buffer[3] = 0x19; break; case TUNER_TNF_5335MF: @@ -754,7 +773,53 @@ if (4 != rc) tuner_warn("i2c i/o error: rc == %d (should be 4)\n", rc); + /* Write AUX byte */ + switch (priv->type) { + case TUNER_TCL_MFPE05_2: + printk("write AUX byte\n"); + simple_set_aux_byte(fe, 0x98, 0x20); + break; + } + return 0; +} + +static int simple_set_tv_gain(struct dvb_frontend *fe, + u8 tvgain) +{ + struct tuner_simple_priv *priv = fe->tuner_priv; + int ret = -EINVAL; + + switch (priv->type) { + case TUNER_TCL_MFPE05_2: + if (priv->tun->initdata) { + priv->tun->initdata[2] = tvgain; + printk("set AUX byte = 0x%X",priv->tun->initdata[2]); + ret = 0; + } + break; + } /* switch (priv->type) */ + + return ret; +} + +static int simple_get_tv_gain(struct dvb_frontend *fe, + u8 *tvgain) +{ + struct tuner_simple_priv *priv = fe->tuner_priv; + int ret = -EINVAL; + + switch (priv->type) { + case TUNER_TCL_MFPE05_2: + if (priv->tun->initdata) { + *tvgain = priv->tun->initdata[2]; + printk("read AUX byte = 0x%X",priv->tun->initdata[2]); + ret = 0; + } + break; + } /* switch (priv->type) */ + + return ret; } static int simple_set_params(struct dvb_frontend *fe, diff -r 3f7e382dfae5 linux/drivers/media/common/tuners/tuner-types.c --- a/linux/drivers/media/common/tuners/tuner-types.c Sun Aug 16 21:53:17 2009 -0300 +++ b/linux/drivers/media/common/tuners/tuner-types.c Thu Sep 10 06:05:49 2009 +1000 @@ -1321,6 +1321,31 @@ }, }; +/* ------------ TUNER_TCL_MFPE05_2 - TCL MFPE05-2 ALL ------------ */ + +static struct tuner_range tuner_tcl_mfpe05_2_all_ranges[] = { + { 16 * 158.00 /*MHz*/, 0xc6, 0x01, }, + { 16 * 441.00 /*MHz*/, 0xc6, 0x02, }, + { 16 * 864.00 , 0xc6, 0x04, }, +}; + +static struct tuner_params tuner_tcl_mfpe05_2_all_params[] = { + { + .type = TUNER_PARAM_TYPE_PAL, + .ranges = tuner_tcl_mfpe05_2_all_ranges, + .count = ARRAY_SIZE(tuner_tcl_mfpe05_2_all_ranges), + .cb_first_if_lower_freq = 1, + .has_tda9887 = 1, + .port1_active = 1, + .port2_active = 1, + .port2_invert_for_secam_lc = 1, + .port1_fm_high_sensitivity = 1, + .default_top_mid = -2, + .default_top_secam_mid = -2, + .default_top_secam_high = -2, + }, +}; + /* --------------------------------------------------------------------- */ struct tunertype tuners[] = { @@ -1779,6 +1804,14 @@ .params = tuner_partsnic_pti_5nf05_params, .count = ARRAY_SIZE(tuner_partsnic_pti_5nf05_params), }, + + [TUNER_TCL_MFPE05_2] = { /* TCL ALL */ + .name = "TCL MFPE05-2 MK3 PAL/SECAM multi (Beholder Lab)", + .params = tuner_tcl_mfpe05_2_all_params, + .count = ARRAY_SIZE(tuner_tcl_mfpe05_2_all_params), + .initdata = tua603x_agc112, + .sleepdata = (u8[]){ 4, 0x9c, 0x60, 0x85, 0x54 }, + }, }; EXPORT_SYMBOL(tuners); diff -r 3f7e382dfae5 linux/drivers/media/video/saa7134/saa7134-cards.c --- a/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Aug 16 21:53:17 2009 -0300 +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Sep 10 06:05:49 2009 +1000 @@ -4500,7 +4500,7 @@ /* Alexey Osipov <lion-simba@pridelands.ru> */ .name = "Beholder BeholdTV M6", .audio_clock = 0x00187de7, - .tuner_type = TUNER_PHILIPS_FM1216ME_MK3, + .tuner_type = TUNER_TCL_MFPE05_2, .radio_type = UNSET, .tuner_addr = ADDR_UNSET, .radio_addr = ADDR_UNSET, @@ -4537,7 +4537,7 @@ /* Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com> */ .name = "Beholder BeholdTV M63", .audio_clock = 0x00187de7, - .tuner_type = TUNER_PHILIPS_FM1216ME_MK3, + .tuner_type = TUNER_TCL_MFPE05_2, .radio_type = UNSET, .tuner_addr = ADDR_UNSET, .radio_addr = ADDR_UNSET, @@ -7099,6 +7099,18 @@ } break; } + case SAA7134_BOARD_BEHOLD_M6: + case SAA7134_BOARD_BEHOLD_M63: + { + struct v4l2_queryctrl* ctl; + struct saa7134_fh *fh; + struct file *fl; + + ctl->id = V4L2_CID_GAIN; + if (saa7134_queryctrl(fl,fh,ctl)==0){ + ctl->flags &= ~(V4L2_CTRL_FLAG_DISABLED); /* enable this control */ + } + } } /* switch() */ /* initialize tuner */ diff -r 3f7e382dfae5 linux/drivers/media/video/saa7134/saa7134-video.c --- a/linux/drivers/media/video/saa7134/saa7134-video.c Sun Aug 16 21:53:17 2009 -0300 +++ b/linux/drivers/media/video/saa7134/saa7134-video.c Thu Sep 10 06:05:49 2009 +1000 @@ -413,6 +413,15 @@ .step = 1, .default_value = 0, .type = V4L2_CTRL_TYPE_INTEGER, + },{ + .id = V4L2_CID_GAIN, + .name = "Gain", + .minimum = 0, + .maximum = 6, + .step = 1, + .default_value = 3, + .type = V4L2_CTRL_TYPE_INTEGER, + .flags = V4L2_CTRL_FLAG_DISABLED, },{ .id = V4L2_CID_HFLIP, .name = "Mirror", @@ -1128,6 +1137,9 @@ case V4L2_CID_HUE: c->value = dev->ctl_hue; break; + case V4L2_CID_GAIN: + c->value = dev->ctl_gain; + break; case V4L2_CID_CONTRAST: c->value = dev->ctl_contrast; break; @@ -1175,6 +1187,7 @@ unsigned long flags; int restart_overlay = 0; int err; + unsigned char tgain; /* When called from the empress code fh == NULL. That needs to be fixed somehow, but for now this is @@ -1214,6 +1227,38 @@ dev->ctl_hue = c->value; saa_writeb(SAA7134_DEC_CHROMA_HUE, dev->ctl_hue); break; + case V4L2_CID_GAIN: + dev->ctl_gain = c->value; + + switch (c->value) { + case 0: + tgain = 0x80|0x50; /* TOP = 103dB, ATC = OFF */ + break; + case 1: + tgain = 0x80|0x40; /* TOP = 106dB, ATC = OFF */ + break; + case 2: + tgain = 0x80|0x30; /* TOP = 109dB, ATC = OFF */ + break; + case 3: + tgain = 0x80|0x20; /* TOP = 112dB, ATC = OFF */ + break; + case 4: + tgain = 0x80|0x10; /* TOP = 115dB, ATC = OFF */ + break; + case 5: + tgain = 0x80|0x00; /* TOP = 118dB, ATC = OFF */ + break; + case 6: + tgain = 0x80|0x60; /* TOP = External AGC, ATC = OFF */ + break; + default: + tgain = 0x80|0x20; + break; + } + /* call simple set AUX byte here */ + /* simple_set_v_gain(); */ + break; case V4L2_CID_CONTRAST: dev->ctl_contrast = c->value; saa_writeb(SAA7134_DEC_LUMA_CONTRAST, @@ -2534,6 +2579,7 @@ dev->ctl_bright = ctrl_by_id(V4L2_CID_BRIGHTNESS)->default_value; dev->ctl_contrast = ctrl_by_id(V4L2_CID_CONTRAST)->default_value; dev->ctl_hue = ctrl_by_id(V4L2_CID_HUE)->default_value; + dev->ctl_gain = ctrl_by_id(V4L2_CID_GAIN)->default_value; dev->ctl_saturation = ctrl_by_id(V4L2_CID_SATURATION)->default_value; dev->ctl_volume = ctrl_by_id(V4L2_CID_AUDIO_VOLUME)->default_value; dev->ctl_mute = 1; // ctrl_by_id(V4L2_CID_AUDIO_MUTE)->default_value; diff -r 3f7e382dfae5 linux/drivers/media/video/saa7134/saa7134.h --- a/linux/drivers/media/video/saa7134/saa7134.h Sun Aug 16 21:53:17 2009 -0300 +++ b/linux/drivers/media/video/saa7134/saa7134.h Thu Sep 10 06:05:49 2009 +1000 @@ -565,6 +565,7 @@ int ctl_bright; int ctl_contrast; int ctl_hue; + int ctl_gain; /* gain */ int ctl_saturation; int ctl_freq; int ctl_mute; /* audio */ diff -r 3f7e382dfae5 linux/include/media/tuner.h --- a/linux/include/media/tuner.h Sun Aug 16 21:53:17 2009 -0300 +++ b/linux/include/media/tuner.h Thu Sep 10 06:05:49 2009 +1000 @@ -127,6 +127,7 @@ #define TUNER_PHILIPS_FM1216MK5 79 #define TUNER_PHILIPS_FQ1216LME_MK3 80 /* Active loopthrough, no FM */ #define TUNER_PARTSNIC_PTI_5NF05 81 +#define TUNER_TCL_MFPE05_2 82 /* TCL clone of the Philips FM1216ME_MK3 */ /* tv card specific */ #define TDA9887_PRESENT (1<<0)