[Copying this mail to openmoko-devel as well to raise awareness] Hello list,
most of the FSO team is now in Taipei and yesterday we collected items we want to discuss/work on in the three weeks we will be here. Here's the preliminary list of problems we want to tackle. If you have any comments or questions please ask! * Power management * Inter subsystem communication * layering & means * Rules * reconsidering yaml * granularity * Preferences (-> OM 2008 integration?) * Documentation and examples * Tests acquiring current time (and timezone) * Alarm/Wakeup * GSoC integration * PIM * remoko * gestures * odeviced * ... * VoIP * Networking wrt FSO * Merging vala & python in frameworkd * security (SELinux and running frameworkd as non-root user) * How do profiles and rules play together? * Location (awareness) * Probably shouldn't be in ogpsd, but higher level * EnterArea/LeaveArea * reuse (parts of) diversity-daemon? * PDU handling (PB + CB + testing) * Correct font for zhone (with CJK support) * Enhancing SMS DBus API * TP-UDH (SMS Header) support * FSO Consumer * improve ogpsd (Gypsy) DBus API * Milestone4 roadmap We already talked a bit about power management and inter subsystem communication/dependencies yesterday and came to the conclusion that different resources (e.g. GSM) will Register/Unregister with ousaged and provide a object path where that resource implements the interface org.freesmartphone.Resource with methods Suspend, Resume, Enable, Disable. When ousaged finds it should enable or disable a device (based on the policy and users requesting the resource) it will call the Enable/Disable methods of the resource and that will take care of saving state, initializing the resource and controlling power. For complex resources like GPS and GSM we'll stop using odeviced calls zu turn the device off or on, but for simple resources odeviced will take care of everything (registering with ousaged, providing the Resource interface, ...). Suspend and Resume will take care of the necessary steps before and after suspend. ogpsd will implement the Start and Stop methods from gypsy and request/release the resource accordingly so programs only implementing the gypsy API will still be able to turn GPS on and off. The whole usage tracking and resource management design is starting to look awfully like an event based init system with dbus interface. We should look out for improvements in that area and see if we can achieve the same thing without reinventing our own mini init system. Enabling the GSM resource should just power on the modem and initialize it (+CFUN=4), keeping radio off. This is useful for airplane mode where you want to browse your SIM contacts/messages. Resources that ousaged should (could) control are: * BT, Wifi, GPS, GSM, CPU, Display, Network The idea is that requesting the resource - CPU prevents the system from suspending - Display prevents the system from dimming the screen - Network tries to get a network connection (this will probably need more info about how expensive it can be) I think that was all. Regards, Daniel Willmann
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
