10-modem.fdi

[Dan Williams]

On Thu, 2008-05-29 at 23:00 +0300, Alex Kanavin wrote:
> 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.

Yeah, though we do now have reports of cards/phones that don't respond
to anything until given a PIN.  Not just from Marcel either.  In that
case, there's nothing the prober can do...

Dan

> 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.
>