10-modem.fdi

[Alex Kanavin]

2008/5/29 Antti Kaijanmäki <antti at kaijanmaki.net>:
> I'm going to local home electronics store next Monday to gather some
> mobile phone USB IDs for 10-modem.fdi . I have few questions about the
> elements in the file. It would not be nice if I had to go there for
> second time just because I missed some crucial information :)
>
> Looking at the file it's clear that I must collect the usb.vendor_id and
> usb.product_id pairs, but I'm not sure what to do about
> usb.interface.number and modem.command_sets .

If the phones are CDC ACM USB class-compliant (and it's very likely
that they are), this is not necessary. There is already an entry for
such phones in 10-modem.fdi:

 282       <!-- Communication Device Class Abstract Control Model (CDC
ACM) modems,
 283            typically provided by GSM/CDMA phones -->
 284       <match key="@info.parent:usb.interface.class" int="0x02">
 285         <match key="@info.parent:usb.interface.subclass" int="0x02">
 286           <append key="info.capabilities" type="strlist">modem</append>
 287           <append key="modem.command_sets" type="strlist">V.250</append>
 288         </match>
 289       </match>

and a probe code for determining command sets is currently in review.
Besides, adding vendor/product id for each of Nokia's or whoever's new
models would be a logistics nightmare.

If you submit entries, they should come with lsusb -v output for that
particular model to make sure they aren't covered by a USB
class/subclass.

-- 
Alexander