From: Dan Williams <dcbw@redhat.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: modem-modeswitch versus usb-modeswitch aka future of Mobile
Date: Thu, 25 Feb 2010 18:24:18 +0000 [thread overview]
Message-ID: <1267122258.15124.2.camel@localhost.localdomain> (raw)
In-Reply-To: <b97f4ee41002250205s59a09f84na8777b90e3d6e3c6@mail.gmail.com>
On Thu, 2010-02-25 at 06:58 -0800, Dan Nicholson wrote:
> On Thu, Feb 25, 2010 at 2:05 AM, Peteris Krisjanis <pecisk@gmail.com> wrote:
> > Hi there!
> >
> > I am Peteris Krisjanis, and I'm doing testing and debbuging Ubuntu
> > distro - apps, hardware, translations, etc. As very regular Linux user
> > and practical advocate and migration specialist for 9 years, I am
> > quite interested for getting hardware "just work". I know it is
> > neverending story, but it shouldn't keep me and us from trying :)
> >
> > Anyway, I am posting my first post to this list to get more clear
> > picture about what's happening with mobile broadband modems within
> > Linux environment. Current situation is (as far as I understand):
> >
> > * We have some modeswitching stuff in kernel, but everyone would happy
> > to see it go to userspace, which is quite understandable;
> > * We have modem-modeswitch app in udev rules, which handles only few
> > manufacturers. With some tweaking it can automagically work with other
> > dongles, but it is not a right way to do it. It is also abandoned;
Yes, usb_modeswitch should be used instead. The only piece of
modem-modeswitch which is not available in usb_modeswitch already is for
the MobileAction phone cables. But not too many people have those
(besides me).
> > * And finally we have usb-modeswitch app, which is independent tool to
> > do a switching and is very widely used and and actively maintained by
> > Josua Dietze
> >
> > As a user and someone of Ubuntu community, I would like to know what
> > Linux hotplug/udev people think about usb-modeswitch direction, is it
> > right and "blessed" way to do it? So far it seems only *working*
> > effort to support mode switching for mobile broadband modems, which
> > are very widely used. This answer is important, as Ubuntu devs are
> > looking to include it by default in distro, so we can get user's
> > mobile broadband dongles working out of box in most situations.
As far as I'm concerned, usb_modeswitch is currently the best way to
accomplish this task. I believe that the usb_modeswitch developers have
addressed all my concerns with out-of-the-box support via udev rules.
It makes sense to do all this in one place, and usb_modeswitch is the
best place to do that right now.
Dan
prev parent reply other threads:[~2010-02-25 18:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-25 10:05 modem-modeswitch versus usb-modeswitch aka future of Mobile broadband Peteris Krisjanis
2010-02-25 10:26 ` modem-modeswitch versus usb-modeswitch aka future of Mobile Marco d'Itri
2010-02-25 14:58 ` Dan Nicholson
2010-02-25 16:16 ` Greg KH
2010-02-25 16:34 ` Peteris Krisjanis
2010-02-25 16:47 ` Greg KH
2010-02-25 18:24 ` Dan Williams [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1267122258.15124.2.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).