10-modem.fdi

[Dan Williams]

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:

1) fdi files have rules to run the prober for specific devices (either
based on the USB class or the "linux.driver" or whatever).  We don't
necessarily want to run the prober for platform serial ports for
example.

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