[SHR-t] Some glitches
I just tried the latest SHR-t version (from early-march). Works like a charm, but there are a few glitches/questions that might be worth mentionning : * with previous versions, I used to disable the lock screen by setting the lock timeout to more than the suspend one (like 55 seconds for lock when there's only 30 for suspend). That kind of thing might be a bad idea in the first place, but what would be the best way to disable it? * GPRS works ... to a point. I can connect through the SettingsConnectivity panel, and it works like a charm. But once disconnected, I can't connect back unless I reboot. When I return to SettingsConnectivity, the GPRS Connection status is UNKNOWN and the Connect/Disconnect button shows the same UNKNOWN string. * I read somewhere that it's not a bug, but is there a way to re-enable the power-button to suspend-menu behaviour? Because on my phone, the power button is now only used to un-suspend, and that looks suboptimal to me. Just for the records, my phone is a buzz-fixed Freerunner, and the whole SHR-t 'lite' was installed on the SD card. Are there other known problems on that version? -- Olivier ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [NEW DISTRIBUTION] Announcing NEOPhysis
On Wed, Mar 10, 2010 at 11:28 AM, Aditya Gandhi aditya...@gmail.com wrote: Why don't we really combine all efforts instead of making a huge and heavy fso which is indeed short of a good phone into something more specific and quicker. IIRC, FSO is pretty quick to start...most of the time spent is for X, wm, etc (may be udev also plays a role there...I've never I think it's falling nicely into place. bit by bit the big python based framework is being replaced by smaller fast lightweight vala based daemons, the latest reports of running fso-gsmd are very encouraging - fast, small memory footprint... thanks to Mickey's effort. Sidetracking a bit, but imho i am not so much looking to the stable party as i am really looking forward to have fso-gsmd and new opimd (have since yesterday) running in my phone. i hope to see increase of speed and performance especially during startup, but not only. And i think yes, the FSO team is open to patches... :) my 2cents only... Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-t] Some glitches
On Wed, 10 Mar 2010 09:29:27 +0100 Olivier Migeot larry...@gmail.com (OM) wrote: I just tried the latest SHR-t version (from early-march). Works like a great :) * with previous versions, I used to disable the lock screen by setting the lock timeout to more than the suspend one (like 55 seconds for lock when there's only 30 for suspend). That kind of thing might be a bad idea in the first place, but what would be the best way to disable it? http://wiki.openmoko.org/wiki/SHR_User_Manual#idle_screen * GPRS works ... to a point. I can connect through the SettingsConnectivity panel, and it works like a charm. But once disconnected, I can't connect back unless I reboot. When I return to SettingsConnectivity, the GPRS Connection status is UNKNOWN and the Connect/Disconnect button shows the same UNKNOWN string. this is an race condition in FSO and will be (hopefully) gone after the fso-gsmd is in place. * I read somewhere that it's not a bug, but is there a way to re-enable the power-button to suspend-menu behaviour? Because on my phone, the power button is now only used to un-suspend, and that looks suboptimal to me. http://wiki.openmoko.org/wiki/SHR_User_Manual#Power_Button cheers Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] New poll about OS
The poll will be closed monday 8 march 2010, 07:00 UTC+01:00 This date has passed. What about the results? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [NEW DISTRIBUTION] Announcing NEOPhysis
On 10 March 2010 05:58, Aditya Gandhi aditya...@gmail.com wrote: Why don't we really combine all efforts instead of making a huge and heavy fso As others have replied, I don't think it's true that FSO is huge and heavy - at least, not in a practical sense, because it is nicely divided into separate functions, and you can disable any parts of it that you don't want. For example, my personal intuitions are that opimd shouldn't be middleware, and maybe not oeventsd and opreferencesd either; and that ogpsd and otimed should be just gpsd and ntpd. But that's all fine, because I can just disable those pieces (as and when I sort out my thinking and any replacements that are needed). What does that leave? ogsmd, odeviced and ousaged - which are all crucial, and I have no reason to believe that they're unnecessarily heavy. IIUC, Neophysis uses odeviced and ousaged (or the fso* equivalents), and just replaces [fs]ogsmd with ofono. on speed and reliability of operations we do. I don't think I would like to use a phone which takes 5 min to boot up, 3 min to start an app and crashes very frequently. FWIW, that doesn't sound like my FSO-based phone. I would love to start from scratch and clean up all the mess. I don't think these guys have anything against fso but I'm sure they felt the same as many other Freerunner users. I don't mean to ridicule your efforts on fso all I want to say is it can be quicker and better if you don't plan on supporting everything possible (qt,gtk,enlightenment) even if you do not everything all together , different flavors of fso might help better. I think this is all just FUD, isn't it? If there's a specific point in here, please point it out. In particular, note that the FSO API has nothing to do with what desktop environment you're using. I really wish fso reaches its goal but still while giving usable images as it goes. Me too. It already does enough to make me a happy phone user. Of course there are remaining issues, but progress is being made on those, and I would be very surprised if the oFono stack is able to catch up and overtake FSO, because it is inevitable that oFono will encounter difficult issues too. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
