dcbw at redhat.com
Mon Jun 2 07:50:35 PDT 2008
On Thu, 2008-05-29 at 17:48 -0400, Dan Williams wrote:
> 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...
FYI, one of these is the Novatel XU870, apparently.
> > 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.
> hal mailing list
> hal at lists.freedesktop.org
More information about the hal