On 01/07/2013 10:13 PM, Malcolm Priestley wrote:
On Mon, 2013-01-07 at 21:37 +0200, Antti Palosaari wrote:
On 10/06/2012 06:40 PM, Mauro Carvalho Chehab wrote:
Em Mon, 01 Oct 2012 14:21:34 +0300
Antti Palosaari <cr...@iki.fi> escreveu:
On 10/01/2012 02:15 PM, Mauro Carvalho Chehab wrote:
Em Sun, 30 Sep 2012 19:36:50 +0200
Damien Bally <bir...@free.fr> escreveu:
Le 29/09/2012 19:33, Mauro Carvalho Chehab a écrit :
It seems that the it931x variant has bcdDevice equal to 2.00,
from Damien's email:
idVendor 0x0ccd TerraTec Electronic GmbH
idProduct 0x0099
bcdDevice 2.00
iManufacturer 1 ITE Technologies, Inc.
iProduct 2 DVB-T TV Stick
iSerial 0
If the af9015 variant uses another bcdDevice, the fix should be simple.
Alas, according to
http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_T_USB_Dual_RC the
af9015 variant appears to have the same bcdDevice. I join both lsusb
outputs for comparison.
Well, then the alternative is to let both drivers to handle this USB ID,
and add a code there on each of them that will check if the device is the
right one, perhaps by looking at iProduct string. If the driver doesn't
recognize it, it should return -ENODEV at .probe() time. The USB core will
call the second driver.
It is the easiest solution, but there should be very careful. Those
strings could change from device to device. I used earlier af9015 eeprom
hash (those string as coming from the eeprom) to map TerraTec dual
remote controller and git bug report quite soon as it didn't worked.
After I looked the reason I found out they was changed some not
meaningful value.
Yeah, those strings can change, especially when vendors don't care enough
to use a different USB ID/bcdDevice for different models. Yet, seems to
be the cleaner approach, among the alternatives.
Damien, care to test?
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tuner
I split tuner out from IT9135 driver and due to that AF9035 driver
supports IT9135 too (difference between AF9035 and IT9135 is integrated
RF-tuner). I added iManufacturer based checks for both AF9015 and AF9035
drivers
I can't see the point of adding this to the af9035/af9033 driver. It is
going to turn into one enormous blob.
Stop speaking bullshit! It increases AF9035/AF9033 driver size
marginally. I could guess total binary size of AF9035+AF9033+IT913X
(IT913X == that new tuner driver) is smaller than size of your IT9135 blob.
The it913x is a stable driver and has it own entity moving forward.
The only thing that needs to happen is the id is added to it913x driver
and if it doesn't apply drop it.
Nack.
If you remember about year back when IT9135 was mainlined I reviewed
that stuff and criticized it wasn't split correctly. I also pointed out
all what is needed is new RF-tuner driver as AF9035/AF9033 is just same
silicon, but without a integrated tuner. You said on one mail something
like it is too much different than AF9035 family, I didn't cared to
start stupid yes/no discussion on that time.
You don't have any technical reason to NACK it. Last time I was
"discussing" with DS3000+TS2020 split with you and you were against.
Same happens now. I ask you to look driver guidelines [1] and stop
speaking BS, instead start fixing your own stuff and you will never end
up situation like that.
[1] http://lwn.net/Articles/529490/
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
