Re: QtMoko and FSO (was: qtmoko v33)
Gennady Kupava, Mar. 09, 2011, 22:48 +0300: > 1. qt stack has richer functionalily, better performance, and less bugs > than that FSO dbus/vala thing (don't throw rotten tomatoes to me plese) > 2. qt has it's own resource management, FSO - it's own, rewriting qt one > to FSO one is worthless effort OK, I'd like to ask one question now. Is there a reasonable technical way to *control* qt-stack-managed Freerunner without GUI? This means sending SMS from CLI and all these small things. In other words, I'm interested in command-line interface instead of programming interface. I believe the latter is up and running, but is the former implemented? Frankly, I do not know what the answer is. And yes, in case it is like "You just invoke this function from this library with proper arguments", I think I'll go and write a simple CLI wrapper, for this is just what makes Unix-like systems so usable. But if the only correct implementation lives deep in the code of qt stack, then we'd better try and separate it. Generally speaking, I guess it's convenient and powerful interfaces, rather than compatibility with existing applications, that matter more just here. -- Dmitry Chistikov ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: bug: sd card not unmounting
Here's a way to work around this problem which from discussion effects only a nand install and must be (I think) a kernel bug. Save this as clean_shutdown.sh and follow the commented instructions:- _ #!/bin/bash #put this in /opt/qtmoko/bin/, make executable then:- #ln -s /opt/qtmoko/bin/clean_shutdown.sh /opt/qtmoko/bin/halt #ln -s /opt/qtmoko/bin/clean_shutdown.sh /opt/qtmoko/bin/reboot #ln -s /opt/qtmoko/bin/clean_shutdown.sh /opt/qtmoko/bin/shutdown COMMAND=`basename $0` if [ "$COMMAND" == "shutdown" ];then ARG0=$1 ARG1=$2 fi grep /media/card /proc/mounts > /dev/null if [ $? -eq 0 ];then umount -f /media/card fi /sbin/$COMMAND $ARG0 $ARG1 _ I've tested this by halt/reboot from the neo's terminal and using the gui. It will not work (unadapted) if you are logged in via ssh as /opt/qtmoko/bin is then not in your PATH; from the neo's gui it is first in the PATH, so that ensures the halt/reboot commands get filtered by this script before passing to the real commands in /sbin. Obviously, as is, this is qtmoko only, but there is probably a possible similar strategy on SHR >To summarize my experience:- >qtmoko v26 - this problem does not happen >SHR testing - I first see this issue >back to qtmoko v26 - problem goes away >qtmoko v33 -the same problem comes back -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QTMoko] Battery running low on v33
Hi List, I have been using QTMoko v33 for the last few days. One of the things that bother me, is that the battery drains much faster than I am used to, _even_ if it's connected to USB with force-fast-charge. Checking Neotool, the battery status is charging (and changes to discharging on disconnect, not charging on connecting and then charging after a few seconds). The current is around 14(?) when not connected, and from 6000 to 9000 when connected. Modem and Bluetooth are turned on, GPS (and, as far as I can tell) wifi are turned off (never turned on since turning on the device from no-battery-no-cables-cold-boot)) Am I being fooled by the thin red line in the battery-drawing (and the beeps and messages "low power") and is the battery actually being recharged? How can I figure out whether fast-chare is really enforced? Thanks in advance! Boudewijn ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
