[Sugar-devel] Patch: Mobile dongles

[Paul Fox]

jerry wrote:
 > On Mon, 2012-03-26 at 11:54 -0400, Paul Fox wrote:
 > > jerry wrote:
 > >  > On Mon, 2012-03-26 at 16:44 +1100, forster at ozonline.com.au wrote:
 > >  > > David
 > >  > > 
 > >  > > This message was sent with a gsm dongle on an xo-1
 > >  > >  
 > >  > >  modem:Huawei E160E
 > >  > >  carrier:Locked to Dodo (an Optus reseller)
 > >  > >  XO-1
 > >  > >  OS31 development which is same as os884 signed
 > >  > >  
 > >  > >  in my settings, enter username, password, leave *99# unaltered, dodolns1, blank, blank
 > >  > >  
 > >  > >  turn off power management, because XO looses connection in sleep mode
 > >  > 
 > >  > I have an enhancements to powerd to inhibit suspend for that issue. The
 > >  > attached proof of concept patch is heavy on tracing, should apply, maybe
 > >  > with an offset, and needs /etc/powerd/flags/modules-inhibits created
 > >  > containing usb_wwan. Once usb_wwan is inserted in the kernel, it remains
 > >  > in memory you can have NM dispatcher or pppd remove the module when the
 > >  > connection is torn down to restore normal power management operation.
 > >  > These features are in testable with au210. Sorry 4g images only, with no
 > >  > firmware in the image. http://build.laptop.org.au/xo/os/latest/
 > > 
 > > is presence of the module really the best way to do this?  is it
 > > possible to look for the presence of the network interface, or maybe
 > > simply network traffic, or something similar?  
 > 
 > In the field test reports are saying the modem is getting reset upon
 > suspend while the trying to connect. Think the 15 second, 5 second if
 > your in suspend and don't have any other user activity, sleep loop may
 > not allow enough time to have the modem complete the pppd handshake and
 > bring up the interface. 

who manages the connection?  network manager?  does it announce the
connection sequence via dbus?  powerd-dbus is already listening for
connection status to prevent sleep during wifi association -- perhaps
that mechanism can be leveraged.

 > 
 > > i assume using the
 > > existing usb-inhibits is impractical because of the variety of
 > > devices, is that right?
 > >   
 > Yes, that is the reason. We want a one-size-fits-all fix where the user
 > doesn't have to populate any files. 
 > 
 > > i guess it would be too much to ask for all
 > > GSM devices to be in the same USB class.  :-/
 > > 
 > What would be the appropriate USB class? Mine comes up as usb-storage at
 > first and usb_modeswitch has to act on it adding time to the connection
 > routine. 
 > 
 > > (maybe the module presence check is okay -- it just doesn't feel right.)
 > > 
 > I think this could be used for other devices also like wedo or usb2vga
 > maybe.

perhaps.

wedo is readily identifiable by vendor, i think -- and why would one
want it to inhibit suspend?  that seems more like it should be under
the activity's control.

i'd think (but don't know) that usb2vga would be used seldom enough
that you could either inhibit suspend manually, or change the config
so it doesn't suspend when plugged in -- i can't imagine using usb2vga
when you don't have plenty of power available.

paul
=---------------------
 paul fox, pgf at laptop.org