On Monday, June 04, 2012 09:38:17 AM Neil Jerram wrote: > I wonder if it would be a generally useful idea to catch and show qpe's > output in cases like this, and then give the user the choice of > restarting or powering off? I think that might be less alarming that > seeing the UI restarting repeatedly. When this restarting last happened > to me, I was worried if it would be safe to force the phone to power off > - so it would be nice to have an explicit option for that. > > Alternatively, the top level loop could measure how quickly qpe is > restarting, and power off automatically if it restarts twice in less > than 1 minute. In that case it might also pop up a notice/explanation, > with a reference to where to look (on the SD card) to see qpe's output. > > What do you think? Are either of those worthwhile?
In this case it's quite obvious bug - qtmoko should not segfault when bluetooth is not working. The bluetooth stuff needs to be done much better. The bluez bindings should be autogenrated from .xml dbus files - like it's done for FSO and oFono and they should handle the case when bluetooth is not working correctly. But if you'd like to implement this logic i wont have problem including it - if it's not too much complex. E.g. redirecting qpe output to /dev/tty0 in case it crashes should not be too hard. Regards Radek _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community