On Mon, 2012-03-26 at 13:27 -0400, Paul Fox wrote: > 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, fors...@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?
NetworkManager/modem-manager > does it announce the connection sequence via dbus? They should but I'm unsure or what signals are. > powerd-dbus is already listening for > connection status to prevent sleep during wifi association -- perhaps > that mechanism can be leveraged. > That would be the best way. > > > > > 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. > Think there needs to be a consensus on what should be in powerd and which activities need to prevent suspend. > 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. Sure untick the box in the applet is a good workaround, like for a usb modem. ;) Jerry _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel