10-modem.fdi

[Dan Williams]

On Wed, 2008-06-11 at 07:03 +0200, Trond Husø wrote:
> > To: Matthew Garrett <mjg at redhat.com>
> 
> > On Thu, 2008-05-29 at 23:45 +0100, Matthew Garrett wrote:
> > > On Thu, May 29, 2008 at 05:48:23PM -0400, Dan Williams wrote:
> > > 
> > > > 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...
> > > 
> > > The prober can be re-run after the desktop application has prompted for 
> > > the PIN. It's easy enough to stick a callout method on USB modem devices 
> > > to do that. The advantage of that is that hal can act as a cache of the 
> > > data, rather than requiring every application that may want to use the 
> > > device to perform its own probing on every open.
> > 
> > Right.  So what we should do is:
> > 
> 
> > 2) If the prober fails because the device needs a PIN or whatever, it
> > sets a key on the device like "prober.failed_count = 1"
> > 
> > 3) Something that cares (NM, whatever) notices prober.failed_count > 1
> > and tries to send the right PIN to the device.  If that succeeds, it
> > executes a D-Bus method call on the HAL device to re-probe
> > 
> > 4) If the prober succeeds, the device will acquire the right
> > modem.command_sets, and everything is happy, NM notices the new
> > capabilities and manages the device
> > 
> > 5) If the prober still fails, it increases prober.failed_count and NM
> > (or whatever) can decide whether to try probing again
> > 
> > thoughts?
> > 
> > Dan
> > 
> > 
> The AT+CPIN? command will return either PIN, PIN2, PUK and PUK2, so you
> would need some code that can pick up these return codes. 
> 
> There are AT-commands that will return PIN, PIN2 and also PUK-codes. I
> have an on board umts-card that I have to send a PIN-code to every time
> I connect. For some reasons I've had to write the PUK-code two times
> now. So your 10-modem.fdi should in some way return the return the value
> of the AT+CPIN? command. 

Yeah, might be good to include the failure count and also the error
returned by the last failure.  Maybe we just return that to the tool
that does the probing in the D-Bus method call that the tool (NM or
whatever) executes, maybe we stuff that into the device object.

> There are also AT+ commands that will return the signal-strength of the
> card.

Yeah, that's not something HAL should be doing though, that's left to
upper level tools that have UI.

> I'm currently thinking of writing an application sort of similar to the
> one that comes with Dell on Windows for this card. This so that I don't
> have to run Shell-commands all the time, and have more control over
> state of signals and such.

There's a bunch of these, like NetworkManager, VMC, etc.

Dan