[RFC] Probing ttys by default

[Dan Williams]

On Fri, 2014-03-21 at 14:51 +0100, Lars Knudsen wrote:
> If we take a step back and think how users will be best served by the
> mechanism, I think there are several things we could consider as components:
> 
> *  Could ModemManager perhaps wait X seconds before trying to grab a device
> (allowing others to have "first pick")?

This doesn't play well with users plugging in a modem and then waiting
for it to appear on the system.  It's already long enough with
modeswitch and probing.  I believe most of the problems we have are
already adequately handled by the existing blacklisting and greylisting
that MM does via udev rules.

> *  Could it be possible that if someone plugs in a modem, there may (most
> often) be so big human interaction actions already happening that an
> interactive mode - potentially with a "remember decision" functionality
> would be prefectly fine.  It's very seldom that a modem just does a
> plug'n'play and connect without at least some interaction.

This could be possible, but I don't believe it provides a great user
experience.  Many devices are plug & play these days, or at least have
the capability to be so, and we'd really like to be able to
auto-provision these devices.  Furthermore, CDMA-only devices don't need
much provisioning at all (eg, no APN required) and they are pretty much
ready-to-go.  We want to move in the direction of *less* heavy
user-interaction, not more.

We also don't want the Windows-style behavior of every time you plug a
modem into a different USB port, it gets re-detected and drivers
re-installed, so mechanisms that would "remember" details about the
device and save them later wouldn't be good either.

> *  (already mentioned) - CDC descriptors to be used for detection - at
> least having a combination that knowledgable developers can use to 100%
> tell ModemManager to either white- or blacklist on the fly?

If drivers provide hints, like you've suggested, this would improve the
situation.  However, the problem is with devices that do not conform to
the specifications; those devices are out there and must be supported as
well.  One solution like this would be to have MM automatically greylist
any cdc-acm device that does not appear to be a modem, though we'd have
to do this carefully to avoid breaking existing devices that don't
follow the specs.

Dan




> - Lars
> 
> 
> On Fri, Mar 21, 2014 at 2:36 PM, Bjørn Mork <bjorn at mork.no> wrote:
> 
> > Sven Köhler <sven.koehler at gmail.com> writes:
> >
> > > The value of ATTR{bmCapabilities} you find below may be from the CDC ACM
> > > descriptor instead of the CDC Call Management descriptor.
> > > At least for my UMTS card that is true, and I see a value of 7 instead
> > > of 3. My best guess is, that udev doesn't handle it very well if there
> > > are two fields of the same name in different descriptors of the same
> > device.
> >
> > Ah, you're right.  Thanks for clearing that up.  Then it's not going to
> > be that simple to write a rule processing the CDC Call Management
> > bmCapabilities.
> >
> > This doesn't really have much to do with udev.  It's the driver that
> > parses the descriptors and export some functional descriptor fields as
> > sysfs attributes.
> >
> > The code making this appear in sysfs/udev is:
> >
> > static ssize_t show_caps
> > (struct device *dev, struct device_attribute *attr, char *buf)
> > {
> >         struct usb_interface *intf = to_usb_interface(dev);
> >         struct acm *acm = usb_get_intfdata(intf);
> >
> >         return sprintf(buf, "%d", acm->ctrl_caps);
> > }
> > static DEVICE_ATTR(bmCapabilities, S_IRUGO, show_caps, NULL);
> >
> > ..
> >                 case USB_CDC_ACM_TYPE:
> >                         ac_management_function = buffer[3];
> >                         break;
> >                 case USB_CDC_CALL_MANAGEMENT_TYPE:
> >                         call_management_function = buffer[3];
> >                         call_interface_num = buffer[4];
> >                         if ((quirks & NOT_A_MODEM) == 0 &&
> > (call_management_function & 3) != 3)
> >                                 dev_err(&intf->dev, "This device cannot do
> > calls on its own. It is not a modem.\n");
> >                         break;
> > ..
> >
> >         acm->ctrl_caps = ac_management_function;
> >         if (quirks & NO_CAP_LINE)
> >                 acm->ctrl_caps &= ~USB_CDC_CAP_LINE;
> >
> >
> >
> > So the driver parse and use USB_CDC_CALL_MANAGEMENT_TYPE descriptor, but
> > it doesn't export any of it.  If MM or other userspace tools want to
> > inspect it, then the only option is to parse it again out of either the
> > "descriptors" sysfs field or the /dev/bus/usb character device.
> >
> >
> > Bjørn
> >
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel