Re: [PATCH] af9035: add several new USB IDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04.04.2012 15:40, Gianluca Gennari wrote:
Il 04/04/2012 13:59, Antti Palosaari ha scritto:
On 04.04.2012 14:47, Gianluca Gennari wrote:
Add several new USB IDs extracted from the Windows and Linux drivers
published
by the manufacturers (Terratec and AVerMedia).
+    [AF9035_07CA_0867] = {
+        USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_0867)},
       [AF9035_07CA_1867] = {
           USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_1867)},
+    [AF9035_07CA_3867] = {
+        USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_3867)},
       [AF9035_07CA_A867] = {
           USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A867)},
+    [AF9035_07CA_B867] = {
+        USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_B867)},

It have been common practise to use product names for USB PID
definitions instead of USB ID numbers. I vote to continue that practise.

Also, I am not very sure if it is wise to add new IDs without any
testing. Likely those are just reference design and will work, but
sometimes there is also some changes done for schematic wiring.
Especially for Avermedia, see hacks needed some AF9015 Avermedia
devices. They have put invalid data to eeprom and thus hacks are needed
for overriding tuner IDs etc.
Not to mention, driver supports also dynamic IDs and even device ID is
missing user can load driver using dynamic ID and report it working or
non-working.

Anyone else any thoughts about adding IDs without testing ?

regards
Antti

Regarding the USB PID definition naming, there is no problem for me.
Actually, some product names were used in the modified versions of your
old driver, so I converted them to the format above just for
convenience. The only problem is that there are so many variations of
the Avermedia sticks that it's hard to give them proper names.

Some of this IDs are already tested (if we include the several
modifications of your old driver).

In particular:
AF9035_0CCD_00AA : confirmed working on Ubuntu.it forum with the old
driver (don't have the link);
AF9035_07CA_0825 : confirmed working on OpenPli forum with the old
driver (see link above);

Others comes from the official Windows drivers so they should be just
little variations of the retail products:
AF9035_07CA_A825, AF9035_07CA_0835, AF9035_07CA_3867.

This IDs are can be the more problematic:
AF9035_15A4_1000, AF9035_15A4_1002, AF9035_15A4_1003,
AF9035_07CA_A333, AF9035_07CA_0337, AF9035_07CA_F337
since there is little or no information about this products.

Anyway, this patch can be a reference for users willing to test the new
driver.

I mean those definitions that goes to common file named: dvb-usb-ids.h. Those are named as a USB_PID_<VENDOR_NAME>_<PRODUCT_NAME>

PIDs inside af9035.c (enum af9035_id_entry) are used only for generating table index. Before it was used plain index numbers but that causes in past few times problems when people added new device IDs between then the table. Meaning of that enum is only keep index in order automatically - and it is just fine as it is short unique name as currently AF9035_<VID>_<PID>.

Add those IDs you know working and sent patch. Lets add more IDs when those are confirmed to work. And as I said I added dynamic ID support for that driver, so even there is no USB ID defined inside driver, it can be still used without compiling whole Kernel.

regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux