Re: [Tinkerphones] Fwd: [Gta04-owner] QtMoko: a dream comes true :)
On 23/02/18 11:58, H. Nikolaus Schaller wrote: Am 23.02.2018 um 12:52 schrieb joerg Reisenweber : On Fri 23 February 2018 12:43:08 H. Nikolaus Schaller wrote: And the page http://git.goldelico.com/?p=gta04-qtmoko.git lists it in the "URL" section as g...@github.com:goldelico/gta04-qtmoko.git which is a verbatim quote and AIUI no correctly formed URL AFAIK git automatically adds a git: prefix if you say git clone g...@github.com:goldelico/gta04-qtmoko.git The git@ URL will only work for people who have write access to that repo. The https:// URL should work for everyone (for reading/cloning). Neil BR, Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: latest Openmoko/GTA04 tinkering: wireless charger
That is awesome! Original Message From: H. Nikolaus Schaller Sent: Saturday, 31 December 2016 16:39 To: Tinkerphones Community Reply To: List for Openmoko community discussion Cc: List for Openmoko community discussion Subject: latest Openmoko/GTA04 tinkering: wireless charger Hi, I spent some time to develop a Qi charger for the GTA01/02/04 devices and here its is: https://www.youtube.com/watch?v=LsSdDYHx7d4 Enjoy and happy new year, Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Welcome to the Tinkerphones community
Agreed - I think the new name is exactly right. Neil -Original Message- From: community [mailto:community-boun...@lists.openmoko.org] On Behalf Of joerg Reisenweber Sent: 01 July 2016 08:12 To: community@lists.openmoko.org; OpenPhoenux Community Subject: Re: Welcome to the Tinkerphones community Congrats! This was overdue and the new name is absolutely to the point and has quite some appeal. The definition of what is / is not a tinkerphone is very helpful and should go to the frontpage at http://www.tinkerphones.org I like it very much. What about icons etc, generally the complete "corporate identity"? Has it been discussed what will change (beyond the obviously pending overhaul of http://www.tinkerphones.org artwork/design), and are there already tasks assigned to experts? Maybe even new logos etc established and available? Many thanks, Nikolaus - and whoever else been involved! :-) cheers jOERG On Fri 01 July 2016 08:29:39 H. Nikolaus Schaller wrote: > Hi, > after several years of running the OpenPhoenux community, we thought > that it is time to refresh it a little and replace the awkward name > "OpenPhoenux" (it was always difficult to spell and pronounce) with > something new, self-explaining, that your mom understands. > > "OpenPhoneux" was originally coined in ca. 2009 as the name of an > initiative, when it became clear that the Openmoko company would stop > to develop a successor of the Openmoko Freerunner. It finally brought > the GTA04 device to life. > > Back then, this was a motivating allusion to the situation of building > something new on the remains of Openmoko, but nowadays probably only > some core members of our community are able to understand this > background. > > Therefore we discussed in a small circle what the core of Openmoko and > Openphoenux is. > > It was easy to find what it is not: > * it is not a 100% fair phone (we don't have the resources to track > components - it is enough challenge to have it working and being > produced) > * it is not a 100% open phone (we have not found a feasible solution > for WLAN and GPU) > * it is not a 100% secure phone (we can't do security audits of every > component) > * it is not a cutting edge phone (we do not get the latest and greatest > chips as mainstream manufacturers do) > * it is not a geeks (only) phone (we want everybody to be able to use > it) > > But then we found what the common denominator of all Openmoko > activities was and is: > > It is a device that allows you to tinker with it, i.e. find out how it > works, to replace software and even hardware components for smaller or > bigger improvements and even repairs. It is designed in a way to > enable such changes instead of stopping you (e.g. by protected boot > loaders, undocumented code etc.). > > All this is facilitated by being open (as far as NDAs and other > limitations > allow) and using open source technology (e.g. GNU/Linux, Debian). > > Here is a definition of what "tinkering" is [1]: > > "tinker or tinker around to make small changes to something in order > to improve or repair it" "tinker with: He spends hours tinkering > around with car engines." > > So we are now happy to tell the world that we are members of "the > Tinkerphone community" :) > > There is a new web domain representing this change: > > <http://www.tinkerphones.org> > > I hope you will agree with us and stay here, contribute and share your > ideas and achievements. And invite new tinkerers to participate. > > Happy tinkering, > Nikolaus > > PS: it will need your help to update the documentation pages... > > [1]: <http://www.macmillandictionary.com/dictionary/british/tinker_1> > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- () ascii ribbon campaign /\ against html e-mail - against proprietary attachments http://www.georgedillon.com/web/html_email_is_evil.shtml http://www.nonhtmlmail.org/campaign.html http://www.georgedillon.com/web/html_email_is_evil_still.shtml http://www.gerstbach.at/2004/ascii/ (German) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2016
I will be there on Sunday afternoon. Focussed in the SDN/NFV DevRoom, but would love to meet up. Neil Original Message From: Boudewijn Sent: Sunday, 24 January 2016 21:59 To: List for communicating with real GTA04 owners; List for Openmoko community discussion Reply To: List for Openmoko community discussion Subject: FOSDEM2016 Hi lists, Do any of you intend to visit Brussels for FOSDEM, next weekend? I have been terribly inactive, with hardly enough time to lurk the mailinglist, let alone participate in anything. This year I can make it to FOSDEM, it would be nice to meet if there's a chance to. Best regards, Boudewijn ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: State of FreeCalypso
A non-technical comment that you can take or leave - but it is my genuine response to your writings... I'm impressed by your dedication and detail, and I partly enjoy reading your updates; but I find it hard to forget the unacceptably violent threats that you've made in the past (on this list) towards particular people. I wonder if you might now consider retracting and apologising for those, and undertake not to repeat similar in future? Viva la humanidad! Neil Original Message From: Spacefalcon the Outlaw Sent: Saturday, 18 April 2015 07:29 To: community@lists.openmoko.org Reply To: List for Openmoko community discussion Subject: State of FreeCalypso Hello community, This periodic post is a summary of the goals of the FreeCalypso family of projects and the high-level status toward their achievement. Goals = The overall end goals of the project are, in no particular order: 1. Produce a standalone realization of Openmoko's modem. I have had occasion to work with various GSM modems and phones acting as modems (presenting an AT command interface) since A.D. 2000, and the modem in the Freerunner is by far the nicest I've ever touched. TI's implementation of the GSM specs is the richest in terms of functionality (contrast with the lack of CSD support in most 3G+ USB "stick" modems), and thanks to the Leonardo semi-src find, we now have full visibility into its inner workings. But it's a shame that this awesome GSM+GPRS modem is currently tucked away in the guts of the Freerunner, inaccessible to anyone besides the tiny handful of active FR owners/users - and even when one does have a Freerunner, it is not possible to take the FR's AP subsystem out of the picture and use the modem directly from an external host; one has to go through the AP instead, severely limiting the ability to use this modem outside of the FR. Hence I would like to build a modem just like Om's, but brought out on a board by itself, with external connections for power and the two UARTs. And throw in a quadband RFFE and a higher capacity flash+pSRAM chip while at it. 2. Produce a practically usable phone that runs practically free firmware, i.e., fw whose source every user is empowered to study and improve or otherwise modify. Note the emphasis on practical usability. I hear from FR owners that the practical usability of the FR as a phone is rather poor, and because there is absolutely nothing wrong with the modem (hw or fw), the defects in usability must be the result of some flaw(s) in the AP subsystem - a subsystem which from my PoV is nothing but unwanted complexity. And I would never be able to use my FR as a personal phone because it would require running something like QtMoko, and that stuff is far too complex for my old peasant mind. Free software which is far too complex for me to understand and work with comfortably is little different from proprietary sw from the purely practical standpoint - it's a impenetrable black box in practical terms. Therefore, the only way for me to have a practically usable phone that runs practically free firmware is to produce a non-smart phone, a plain phone with no AP subsystem. The long-term solution is to build my own handset hardware, but in the short term it would be OK to use not-quite-fitting but already existing hardware like Pirelli and Motorola phones. 3. Produce a FreeCalypso modem module that could be used in the place of off-the-shelf proprietary ones by free smartphone projects like Neo900. I would like to buy a couple of Neo900 units for two of my family members, but cannot do so for as long as the product includes a modem module from an immoral vendor who withholds source code and documentation and imposes restricted boot barriers to alternative firmware implementations. To the person who emailed me off-list and asked if I could design my FreeCalypso modem in the form factor matching Gemalto's so it could be a drop-in replacement: yes, I still like that idea very much and would like to do it, but I'm unsure whether I can manage such a task by myself, so we may need to work on it together. I also think that it would be easier if I prove my basic design first on a non-form-factor-constrained board, and then go through the form factor gymnastics as a second step. So the above 3 are the overall goals of the FreeCalypso family of projects. Out of those, goal 2 (practically usable non-smart phone running free fw) has been my main focus because it is the one that would improve my own quality of life: I am sick and tired of dealing with Pirelli's proprietary fw (I use a Pirelli DP-L10 as my personal daily phone, running its original proprietary fw as nothing better exists yet - better as in more free *and* practically usable), and I really, really, really want to replace it with my own free firmware. Firmware subproject === The firmware subproject of FreeCalypso is le
Re: Qx and QtMoko v58 in GTA04
On 2014-06-09 22:12, Maelvon HAWK wrote: Can I run a Qt application on the Lxde distribution in a backup solution? Yes. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qx and QtMoko v58 in GTA04
On 2014-06-09 05:36, Radek Polak wrote: On Sunday, June 08, 2014 00:00:27 Maelvon HAWK wrote: Is Qx working with GTA04 in QtMoko? IIRC it worked. Maybe you will need to use Xorg instead of Xfbdev. You can try uninstall Xfbdev and QX could again ask to install and configure Xorg for you. If Xorg is always better, it would be good to remove the choice of installing Xfbdev (at least for GTA04). There might be another problem that xserver-xorg-input-tslib was removed from debian wheezy, so you must use xserver-xorg-input-evdev for input. Now i am not sure which one is the GTA04 frinedly one... Does the QtMoko GTA04 kernel include Nikolaus's patch for dejittering in the kernel? If it does, it should be fine to use evdev. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qx and QtMoko v58 in GTA04
On 2014-06-07 23:00, Maelvon HAWK wrote: I launch the application in Qx, but the application interface's button doesn't respond to any touch on the screen. I'm in Qx with Xfbdev. Is Qx working with GTA04 in QtMoko? I've personally found it unreliable and difficult to use. However I remember seeing reports from several others saying that it worked for them. So maybe I was doing something wrong or using a less good QtMoko version, or had somehow messed things up with my own patches. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qx and QtMoko v58 in GTA04
On 2014-06-06 15:57, Maelvon HAWK wrote: I have a GTA04 and want to run an application in Qtmoko with Qx, but I've no mouse pointer at all. Is that normal? I think it is normal. How would a visible mouse pointer help you? - given that nothing will happen until you touch the screen, and then it will be the position of your touch that controls what happens. I've tested Qx with I see some threads talking about tslib and evdev but I do not see much on the list (http://lists.openmoko.org/pipermail/community/2013-January/068137.html) And as the application have a Qt4 GUI, I'm asking myself if I can run it directly in Qtmoko, but I don't known how! Unfortunately, no, because the Qt4 application is still probably expecting to output to an X server, and native QtMoko uses a different display server. To run directly in QtMoko, at least a rebuild will be needed, within the QtMoko build environment, and possibly a little porting work too. Thanks in advance, Maelvon HAWK Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko GTA06
On 2014-04-01 10:26, shamsul hassan wrote: April Fool :) On Tue, Apr 1, 2014 at 9:49 AM, Dr. H. Nikolaus Schaller wrote: Hi all, I have received a rumor that somebody is working on a truly free and open phone with the following specs: * Quad-Core Intel Z3770D (1.5 - 2.5 GHz) * 4GB RAM * 128 GB eMMC * LTE with free and open baseband * 5 inch full HD display * <100g * 4000 mAh battery * runs any x86 OS (i.e. Linux, Windows, Hackintosh, ...) * shall cost less than Nexus 5 Looks like some "dream machine" :) Since I don't know how to validate: does anyone know more details? Nice one. I was fooled. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] customizing aux/power button or adding button to home screen
robin writes:
> Hi,
>
> I would like to be able to access some programs in qtmoko faster, so my
> question is: Is there either a way to
>
> to run an app directly when you press the aux button
>
> and if so, how can I distinguish the length of a press (I know that the
> old android version did start three different processes depending on the
> length of time you pressed the power button (very short, ~2sec, ~4secs).
I'm afraid I can't remember this, even though I know I have looked at it
in the past. I think QtMoko just supports two press durations: short
and long.
> and if this is all not possible, could someone point me to where I should
> start reading to be able to change/extend the homescreen, to add any icon
> with a call of that application I want to run.
I've attached two patches that maybe will give a small clue here.
> and even more advanced is there any chance of bind the this process somehow
> to a single icon:
> -> Application -> QX -> Select Navit -> Click upArrow in Menu -> Click Launch
Sorry, no idea - although this is certainly something I've wanted to.
Regards,
Neil
>From 2f559f5893d2f150479d96e5926532d3462e569d Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Thu, 6 Dec 2012 21:23:30 +
Subject: [PATCH 1/2] themedhomescreen: Support TaskManager/showRunningTasks()
as an action
TaskManager/showRunningTasks() pops up a window with 4 tabs: Favorites,
Recent, Frequent and Running, with the Running tab showing initially.
I think this is more useful than the Favorites/select() action, which
only provides the content of the Favorites tab, and would like to bind
my home page Star icon to it. Step 1 for that is to make it
available as a bindable action.
---
src/server/phone/homescreen/themed/themedhomescreen.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/server/phone/homescreen/themed/themedhomescreen.cpp b/src/server/phone/homescreen/themed/themedhomescreen.cpp
index d70e52e..2acb47d 100644
--- a/src/server/phone/homescreen/themed/themedhomescreen.cpp
+++ b/src/server/phone/homescreen/themed/themedhomescreen.cpp
@@ -349,6 +349,9 @@ void ThemedHomeScreen::themeItemClicked(ThemeItem *item)
} else if (in == "favorites") {
QtopiaServiceRequest e( "Favorites", "select()" );
e.send();
+} else if (in == "taskmanager") {
+QtopiaServiceRequest e( "TaskManager", "showRunningTasks()" );
+e.send();
} else if (in == "contacts") {
QtopiaIpcEnvelope e("QPE/Application/addressbook", "raise()");
} else if( in == "dialer" ) {
--
1.8.5.3
>From 2768568c4cdfd7f9fa0151c91e7928d5148ce7b8 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Thu, 6 Dec 2012 21:23:30 +
Subject: [PATCH 2/2] Map Star on the home page to whole task manager, not just
Favorites tab
---
etc/themes/mokofaen/home.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/etc/themes/mokofaen/home.xml b/etc/themes/mokofaen/home.xml
index 1380bc2..36d808c 100755
--- a/etc/themes/mokofaen/home.xml
+++ b/etc/themes/mokofaen/home.xml
@@ -113,7 +113,7 @@
-
+
--
1.8.5.3
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko mail reader doesn't display multi-part messages
On 2014-02-19 16:39, Adrien Dorsaz wrote: Hi Neil, It seems that the "mail->partCount()" function give me always '0' and so it's never been able to display my mail. Ah, OK, sorry for barking up a wrong tree. Is there perhaps something odd about GitHub emails? Missing or malformed Content-Type header, strange or misused boundary string, maybe (etc.) ? Something like that might be confusing QtMoko's parser. Incidentally, does QtMoko have its own implementation of RFC822/MIME parsing? Surely there must be a standard Linux library for doing this, which is probably more field hardened than any QtMoko-specific code - I wonder if that could be dropped in and used instead? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko mail reader doesn't display multi-part messages
On 2014-02-19 14:40, Adrien Dorsaz wrote: Hello! I've finally detected the issue of the mail reader in QtMoko : it doesn't find the different parts of multi-part mail messages. So it can displays one-part messages, but not multi-part messages. I've began my investigations here : https://github.com/Trim/qtmoko/issues/1 Unfortunately, I'm stuck and I can't find how to fix the issue : the mail browser seems to be correct, the mail storage seems good (database is consistent and messages are well written on device), but it seems that the same function of the mail storage can retrieve one-part messages correctly, but not multi-part messages (data aren't fetched). I'm stuck because the SQLite connection function is really cryptic for me and I can't retrieve the "mailfile" information from the database which I could use to force to create the mailmessage from the original mailfile. Could someone help me into debbuging the qtopiamail application ? Hi Adrien, Are you sure this is a storage problem, as opposed to a display problem? I've previously looked at some cases of failing to display multipart messages, and all the cases that I looked at were just display problems. Here's my fix for one such case: https://github.com/radekp/qtmoko/commit/021826e12c09edaf806977bc79f810d54cd0e81d. If you review this, you'll see the code files that you (probably) need to look at improving further - I am sure that there are remaining multipart hierarchy cases to fix. Also I might still have some work-in-progress here that I haven't considered ready for pushing to Radek - I'll check for that and let you know this evening. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 Screen broken..
Πρεκατές Αλέξανδρος writes: > > After my baby came into the world chaos is visiting my workroom more frequent > and entropy's level is critical :-) > > Trying to move a mouse's cable created a cascade effect to a dozen of other > cables behind my tower including the usb cable connected to my beloved GTA02. > > You can see the result in the attached pictures. > > The fall was half a meter. I'm sorry to hear that. I've had a few similar falls, usually when I forget that the USB cable is still plugged into my laptop. But so far I've been lucky not to end up with a fracture. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTmoko] Qx problems
Radek Polak writes: > Maybe after installing it from sid it would work better. Well, it appears that tslib is dead and that evdev is the consensus future. But there seems to be no mainstream Linux discussion of whether / how to add filtering into the evdev stack. (I did see an Android-context discussion, which seems to confirm that something is needed.) > I also think that we need some touchscreen filtering - maybe use the > filters from 2.6.28 Freerunner's image - they were really good. Can you point me more precisely to the relevant code? I'll take a look at it. Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTmoko] Qx problems
Radek Polak writes: > you have to try more hard ;-) First explore the "Favourites" menu item. That > way you can add installed X applications and configure them. There are many > options that you can configure - e.g. for xterm it's important to enable > window > manager and virtual keyboard. I recommend also checking "use matchbox". What X server and config are you using? With Xfbdev, I find that I don't have mouse/touchscreen input at all. With Xorg, I do have mouse/touchscreen input, using evdev, but it's quite inaccurate and jumpy. Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTmoko] Qx problems
Rainer Glaschick writes: > Tried to use Qx, installed xglamo, and got only trouble: > > Lauching xterm gives "press AUX to leave" in the middle, > takes some time, then a terminal in the middle. > But no keyboard to enter anything. > The done button still visible, but does not work. > Only way to get rid of it is using AUX twice and stop instead of resume. > > Anybody out who has a useful application for Qx? > > xclock works, but overlaps with the top status line. > > > Trying a python script (xgps) just shows the boot console output > for a while, then a message tells that Qx terminated due to application error. > Starting Qx from the command line then give the reason for fail. > > Seems to me that Qx is nothing for normal use, > only for debug, and thus should be removed from > the normal applist and go either to the system debug menu, > or should be, even better, started from the command line only > to see the error messages that are likely to occur. I would really like QX to work well, because I think it would cool to be able to seamlessly run X and Gtk applications as well as Qt. At the moment, however, my observations (in my case on GTA04) are broadly similar to yours, i.e. it doesn't really work. I'm planning to work a bit on this, but time for it is limited so please don't hold your breath. In terms of overall structure, I'd prefer if a QX-requiring application could be launched normally from the app (or games) menu - instead of specially via the QX application - and also that the business of any required installation or configuration was separated out from simply running a particular application. Does anyone have thoughts on that? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko IMAP sync patch
Hi Radek,
Please would you consider the patch below? It's a minor IMAP sync
optimization, or more precisely quite a significant optimization but for
a scenario that I would guess is pretty rare. I've written more about
it in the commit message.
Regards,
Neil
>From ee6e35eaa7a9d848e3f84d2a970fe17e938e31f3 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Fri, 28 Dec 2012 11:52:46 +
Subject: [PATCH] Optimise 'Removed' flagging of messages deleted from the
IMAP server
On each IMAP server sync, if there are messages that exist on the
phone but have since been deleted from the IMAP server, or moved to a
different folder on the IMAP server, QtMoko adds the
QMailMessage::Removed flag to those messages. Note that we don't
automatically delete those messages from the phone.
I once - not using QtMoko - moved several thousand older messages to
an "OLD" folder on my IMAP server. After that I found that each
QtMoko IMAP server sync operation would take a lot of time and CPU,
and discovered this was because it was reflagging all of those moved
messages every time. If we optimize the process by skipping messages
that already have the 'Removed' flag, it goes massively faster.
---
src/tools/messageserver/imapclient.cpp | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/src/tools/messageserver/imapclient.cpp b/src/tools/messageserver/imapclient.cpp
index 25536d0..9f10f5b 100644
--- a/src/tools/messageserver/imapclient.cpp
+++ b/src/tools/messageserver/imapclient.cpp
@@ -601,8 +601,15 @@ void ImapClient::searchCompleted()
QMailAccount account(accountId);
QStringList readElsewhereUids = account.serverUids(boxId, QMailMessage::ReadElsewhere);
QStringList unreadElsewhereUids = account.serverUids(boxId, QMailMessage::ReadElsewhere, false);
+
+// "deleted" here means messages that have been deleted from the
+// phone (i.e. from the Qtopia database) but may still exist on
+// the IMAP server. Code below will delete these from the IMAP
+// server too.
QStringList deletedUids = account.deletedMessages(boxId);
+// The following generates a list of all the UIDs that have ever
+// previously been seen on the phone.
QStringList storedUids = readElsewhereUids + unreadElsewhereUids + deletedUids;
// New messages reported by the server that we don't yet have
@@ -623,8 +630,20 @@ void ImapClient::searchCompleted()
// Messages marked read locally that the server reports are unseen
_readUids = inFirstAndSecond(account.serverUids(boxId, QMailMessage::Read), _unseenUids);
-// Report any messages that are no longer returned by the server
-foreach (const QString &uid, inFirstButNotSecond(storedUids, reportedUids))
+// If there are messages that exist on the phone but have
+// since been deleted from the IMAP server, add the
+// QMailMessage::Removed flag to those messages. Note that we
+// don't automatically delete those messages from the phone.
+ //
+ // Optimize this a bit by skipping phone messages that already
+ // have the QMailMessage::Removed flag. Otherwise, in a
+ // scenario where a lot of messages are deleted from the IMAP
+ // server - but still exist on the phone - all of those
+ // messages are reprocessed every time we sync with the IMAP
+ // server, and that can take significant time and CPU.
+foreach (const QString &uid,
+ inFirstButNotSecond(inFirstButNotSecond(storedUids, reportedUids),
+ account.serverUids(boxId, QMailMessage::Removed)))
emit nonexistentMessage(uid, Client::Removed);
// Update any messages that are reported read-elsewhere, that we didn't previously know about
--
1.7.10.4
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 act as gps mouse?
Fox Mulder writes: > Hi, > > is it possible to use my gta02 as a gps mouse for another computer? > > I got a cheap tablet without integrated gps and thought it would be > great, if i could use my gta02 as an external gps receiver and pair it > over bluetooth with my tablet. But therefor i need some special program > or script which i have to run on my gta02 that it acts as a standard > bluetooth gps mouse. > > So does anybody know a way to do this? :) Do you mean this? http://www.handheldshell.com/software/bluetooth.php Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko partition size
For people thinking of repartitioning or preparing a new SD card... My current QtMoko is on a 1Gb partition and I've recently been bumping up against that limit a lot, so I'd now recommend 1.5Gb or 2Gb. (The excellent SDL-based games need a bit of room, and personally I'm now getting interested in installing more non-Qt-based apps under QX.) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
Neil Jerram writes: > I had an unsuccessful call this evening; it was an incoming one. The > gsm-voice-routing log for it is below; I plan to analyse this more > myself to see if there's a repeating pattern of overruns and underruns, > but thought it worth posting in case someone else sees and understands > the pattern first. Well the pattern is clear enough, and persists in exactly the same form throughout the whole call. r_mod (capture from the modem) gets an overrun every 4 loop iterations. p_ear and p_mod (playback to the earpiece and to the modem) get an underrun every 8 iterations. r_mic (capture from the microphone) doesn't get any overruns at all. For context, here's a representation of the gsm-voice-routing main loop. +---+ +---+ +---+ +---+ .->| Read |--+->| Read |--+->| Write |>| Write |--. / | r_mic | | | r_mod | | | p_ear | | p_mod | \ /+---+ | +---+ | +---+ +---+\ \ (if overrun) (if overrun)/ \ / / / '-<-'---<-'---<-<---' I had two ideas for explaining the observed over/underruns, but neither of them makes complete sense when we look at the full detail. #1 was that the modem sound card was running slightly faster than the main sound card. (In theory they should both be at 8kHz.) However I think that is disproved by the fact that I got _exactly_ the same underrun pattern for p_ear and p_mod. I think that means that the rates of the two sound cards must differ by less than 1 period over the 16s duration of the call that I logged, i.e. by less than 0.2%. (The period - i.e. how much audio data is read or written in each block shown above - is 32ms.) #2 was that gsm-voice-routing might not be getting enough CPU. The period time is 32ms; let's call that P. Also note that gsm-voice-routing uses hardware buffers that have room for 4P. Now suppose that the average time for gsm-voice-routing to iterate round its main loop is more than P, say 1.9P. After 4 iterations, the capture devices have captured 7.6P, but gsm-voice-routing has only read 4P from them - so they have 3.6P still available and are close to overrunning. The loop always reads r_mic first, so manages to do that before r_mic overruns, reducing its remaining data to 2.6P. But that took a bit of time, and that was long enough for r_mod to fill from 3.6P to 4P, so that 'Read r_mod' reports an overrun. r_mod's buffer is now reset to empty and the main loop does a 'continue', which means that it skips the 'Write's and loops back to reading r_mic again. For p_ear and p_mod, the underrun every 8 iterations is roughly explained by the fact that they have a start threshold of 4 periods. Hence, after an underrun, it takes some iterations for the playback buffers to fill up to their start threshold, then 4 and a bit iterations at 1.9P each for them to be emptied (faster than the loop can keep them filled) and eventually see another underrun. But there are several problems with this explanation. - It doesn't actually explain why we never see r_mic overruns. After an r_mod overrun, r_mod's buffer is reset to 0 but r_mic's buffer is left unchanged. So now r_mic is ahead of r_mod, and we ought to see an r_mic overrun before the next r_mod overrun... - If the loop time was nearly 2P, it should take only 2 and a bit iterations for p_ear and p_mod to fill to their start threshold. Plus 4 iterations to empty again, and that only makes 6 (and a bit), not 8. - The log shows 519 loop iterations, and QtMoko recorded the call duration as 17s, so the average loop iteration time was 32.8ms, i.e. almost exactly P as it should be, and nowhere near 2P. So the head scratching continues. Any ideas? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Mokofaen red signal strength icon
francesco.dev...@mailoo.org writes: > Il 28/01/2013 01:32, Neil Jerram ha scritto: >> >> Do you have the .svg source for the signal strength icons? There's a >> signal.svg in the QtMoko repository but it doesn't match the >> signal.png. I had a go myself at changing the colour of the .png >> (attached), but it wasn't a very nice job. >> >> Regards, >> Neil > What a coincidence, just yesterday I started to work to update MokoFaen > And here it is the reworked signal icon. That's great, thanks! There are also a few Mokofaen fixes that have gone recently into the QtMoko repository; please see https://github.com/radekp/qtmoko/commits/master/etc/themes/mokofaen. And then there is one more that I haven't sent anywhere yet, but which you may like to consider, attached. >From dcee42a5186e87ff54d0e48ccc32acc9da1a2287 Mon Sep 17 00:00:00 2001 From: Neil Jerram Date: Tue, 20 Nov 2012 22:53:00 + Subject: [PATCH 1/2] Avoid "QString::arg: Argument missing" logs Specifically these: Nov 20 22:09:04 neo Qtopia: QString::arg: Argument missing: "1 missed", @/Communications/Calls/MissedCalls Nov 20 22:09:04 neo Qtopia: QString::arg: Argument missing: "1 new", @/Communications/Messages/NewMessages These arise because the "faen"-derived themes have special cases for 1 missed call and 1 new message - presumably for translation into languages where the 1 case is different from N != 1. All those places have an unnecessary , which causes the logs, and which this commit removes. --- etc/themes/faenqo/home.xml |2 +- etc/themes/faenqomod/home.xml|2 +- etc/themes/mokofaen/home.xml |2 +- etc/themes/mokofaen/home_classic.xml |2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/etc/themes/faenqo/home.xml b/etc/themes/faenqo/home.xml index 1be7db7..a511d48 100644 --- a/etc/themes/faenqo/home.xml +++ b/etc/themes/faenqo/home.xml @@ -60,7 +60,7 @@ -1 new@/Communications/Messages/NewMessages +1 new %1 new@/Communications/Messages/NewMessages diff --git a/etc/themes/faenqomod/home.xml b/etc/themes/faenqomod/home.xml index 68d4dab..8590b3b 100644 --- a/etc/themes/faenqomod/home.xml +++ b/etc/themes/faenqomod/home.xml @@ -95,7 +95,7 @@ -1 new@/Communications/Messages/NewMessages +1 new %1 new@/Communications/Messages/NewMessages diff --git a/etc/themes/mokofaen/home.xml b/etc/themes/mokofaen/home.xml index 1380bc2..6fd654f 100755 --- a/etc/themes/mokofaen/home.xml +++ b/etc/themes/mokofaen/home.xml @@ -85,7 +85,7 @@ -1 new@/Communications/Messages/NewMessages +1 new %1 new@/Communications/Messages/NewMessages diff --git a/etc/themes/mokofaen/home_classic.xml b/etc/themes/mokofaen/home_classic.xml index 5f4eaaf..439771a 100755 --- a/etc/themes/mokofaen/home_classic.xml +++ b/etc/themes/mokofaen/home_classic.xml @@ -98,7 +98,7 @@ -1 new@/Communications/Messages/NewMessages +1 new %1 new@/Communications/Messages/NewMessages -- 1.7.10.4 This is a simple bug fix and, I believe, uncontroversial. Sorry for making your release work a bit bigger. Mokofaen for me is part of the everyday happiness of using a free phone. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Mokofaen red signal strength icon
Neil Jerram writes: > francesco.dev...@mailoo.org writes: > >> Thanks for the suggestion. It's not a difficult work to do but I'm >> really busy, so it is on the todo list for a next release. > > Thanks, it's much appreciated whenever you get time for this. > > Neil Do you have the .svg source for the signal strength icons? There's a signal.svg in the QtMoko repository but it doesn't match the signal.png. I had a go myself at changing the colour of the .png (attached), but it wasn't a very nice job. Regards, Neil <>___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
Neil Jerram writes: > I'm pretty sure I saw some voice routing problems on a few occasions > even with pasuspender. > > However, since moving back to gta04-gsm-voice-routing, and adding Neil > Brown's change to start the 2 capture streams at the same time, I've had > a few successful calls and no problems. For the moment, therefore, > things are all working for me. I had an unsuccessful call this evening; it was an incoming one. The gsm-voice-routing log for it is below; I plan to analyse this more myself to see if there's a repeating pattern of overruns and underruns, but thought it worth posting in case someone else sees and understands the pattern first. I've also made some minor patches to gta04-gsm-voice-routing and have attached those here. Of course it's possible that it could be one of those that is the problem... Thanks in advance for any insight! Neil gsm-voice-routing started opened p_mod stream opened r_mod stream opened p_ear stream opened r_mic stream voice routing started [2] r_mod: overrun occured: Broken pipe 0 frames available [6] r_mod: overrun occured: Broken pipe 0 frames available [7] p_ear: underrun occured: Broken pipe [7] p_mod: underrun occured: Broken pipe [10] r_mod: overrun occured: Broken pipe 0 frames available [14] r_mod: overrun occured: Broken pipe 0 frames available [15] p_ear: underrun occured: Broken pipe [15] p_mod: underrun occured: Broken pipe [18] r_mod: overrun occured: Broken pipe 0 frames available [22] r_mod: overrun occured: Broken pipe 0 frames available [23] p_ear: underrun occured: Broken pipe [23] p_mod: underrun occured: Broken pipe [26] r_mod: overrun occured: Broken pipe 0 frames available [30] r_mod: overrun occured: Broken pipe 0 frames available [31] p_ear: underrun occured: Broken pipe [31] p_mod: underrun occured: Broken pipe [34] r_mod: overrun occured: Broken pipe 0 frames available [38] r_mod: overrun occured: Broken pipe 0 frames available [39] p_ear: underrun occured: Broken pipe [39] p_mod: underrun occured: Broken pipe [42] r_mod: overrun occured: Broken pipe 0 frames available [46] r_mod: overrun occured: Broken pipe 0 frames available [47] p_ear: underrun occured: Broken pipe [47] p_mod: underrun occured: Broken pipe [50] r_mod: overrun occured: Broken pipe 0 frames available [54] r_mod: overrun occured: Broken pipe 0 frames available [55] p_ear: underrun occured: Broken pipe [55] p_mod: underrun occured: Broken pipe [58] r_mod: overrun occured: Broken pipe 0 frames available [62] r_mod: overrun occured: Broken pipe 0 frames available [63] p_ear: underrun occured: Broken pipe [63] p_mod: underrun occured: Broken pipe [66] r_mod: overrun occured: Broken pipe 0 frames available [70] r_mod: overrun occured: Broken pipe 0 frames available [71] p_ear: underrun occured: Broken pipe [71] p_mod: underrun occured: Broken pipe [74] r_mod: overrun occured: Broken pipe 0 frames available [78] r_mod: overrun occured: Broken pipe 0 frames available [79] p_ear: underrun occured: Broken pipe [79] p_mod: underrun occured: Broken pipe [82] r_mod: overrun occured: Broken pipe 0 frames available [86] r_mod: overrun occured: Broken pipe 0 frames available [87] p_ear: underrun occured: Broken pipe [87] p_mod: underrun occured: Broken pipe [90] r_mod: overrun occured: Broken pipe 0 frames available [94] r_mod: overrun occured: Broken pipe 0 frames available [95] p_ear: underrun occured: Broken pipe [95] p_mod: underrun occured: Broken pipe [98] r_mod: overrun occured: Broken pipe 0 frames available [102] r_mod: overrun occured: Broken pipe 0 frames available [103] p_ear: underrun occured: Broken pipe [103] p_mod: underrun occured: Broken pipe [106] r_mod: overrun occured: Broken pipe 0 frames available [110] r_mod: overrun occured: Broken pipe 0 frames available [111] p_ear: underrun occured: Broken pipe [111] p_mod: underrun occured: Broken pipe [114] r_mod: overrun occured: Broken pipe 0 frames available [118] r_mod: overrun occured: Broken pipe 0 frames available [119] p_ear: underrun occured: Broken pipe [119] p_mod: underrun occured: Broken pipe [122] r_mod: overrun occured: Broken pipe 0 frames available [126] r_mod: overrun occured: Broken pipe 0 frames available [127] p_ear: underrun occured: Broken pipe [127] p_mod: underrun occured: Broken pipe [130] r_mod: overrun occured: Broken pipe 0 frames available [134] r_mod: overrun occured: Broken pipe 0 frames available [135] p_ear: underrun occured: Broken pipe [135] p_mod: underrun occured: Broken pipe [138] r_mod: overrun occured: Broken pipe 0 frames available [142] r_mod: overrun occured: Broken pipe 0 frames available [143] p_ear: underrun occured: Broken pipe [143] p_mod: underrun occured: Broken pipe [146] r_mod: overrun occured: Broken pipe 0 frames available [150] r_mod: overrun occured: Broken pipe 0 frames available [151] p_ear: underrun occured: Broken pipe [151] p_mod: underrun occured: Broken pipe [154] r_mod: overrun
Re: QtMoko and X applicatiions
Radek Polak writes:
> On Friday, January 25, 2013 04:37:05 PM Iain B. Findleton wrote:
>
>> Thanks for the hint.
>>
>> When I start QM from the qtmoko menu, I get nothing but a blank screen
>> and an input for an application. I have updated the files in
>> /opt/qtmoko/etc/qm as described in the Openmoko wiki, but the menu items
>> for favourites shows nothing. Is there any other updated documentation?
>> Need I install something?
>
> Install your favourite X application - e.g. foxtrotgps and then select
> "Favourites" from context menu. The application should appear there (if it
> has
> .desktop file in /usr/share/applications). Then you can also configure it
> some
> more - like fullscreen, virtiual keyboard...
It seems to me that there are a couple of problems here; please see the
attached patches.
>From 2764304b0a4ad50e608f57bb00ecc1388217b9fc Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Sat, 26 Jan 2013 00:23:34 +
Subject: [PATCH 1/3] qx - fix setting of DISPLAY variable
---
src/3rdparty/applications/qx/qx.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/3rdparty/applications/qx/qx.cpp b/src/3rdparty/applications/qx/qx.cpp
index 6c22ba1..65a651e 100644
--- a/src/3rdparty/applications/qx/qx.cpp
+++ b/src/3rdparty/applications/qx/qx.cpp
@@ -172,7 +172,7 @@ QX::QX(QWidget *parent, Qt::WFlags f)
screen = QX::ScreenMain;
if(getenv("DISPLAY") == NULL)
-setenv("DISPLAY", "0:0", true);
+setenv("DISPLAY", ":0.0", true);
#if QTOPIA
powerConstraint = QtopiaApplication::Disable;
--
1.7.10.4
>From f2b60da8feb85ff28b1653a7e2c626fcee332db2 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Sat, 26 Jan 2013 01:08:55 +
Subject: [PATCH 3/3] qx - fix Xfbdev invocation
It wants "-nocursor", not "-hide-cursor".
---
src/3rdparty/applications/qx/qx.cpp |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/3rdparty/applications/qx/qx.cpp b/src/3rdparty/applications/qx/qx.cpp
index 65a651e..bdc01c0 100644
--- a/src/3rdparty/applications/qx/qx.cpp
+++ b/src/3rdparty/applications/qx/qx.cpp
@@ -438,12 +438,15 @@ void QX::runApp(QString filename, QString applabel, bool rotate)
}
else
{
+#ifdef QT_QWS_NEO
args.append("-hide-cursor");
args.append("-dpi");
args.append("128");
-#ifdef QT_QWS_NEO
xprocess->start("/usr/bin/Xglamo", args);
#else
+args.append("-nocursor");
+args.append("-dpi");
+args.append("128");
xprocess->start("/usr/bin/Xfbdev", args);
#endif
}
--
1.7.10.4
Possibly these affect GTA04 only though; I'm not sure.
Also, for GTA04 I think the installed xorg.conf has the wrong
/dev/input/event numbers. For GTA04 I believe it should be
touchscreen = 0
Power = 2
AUX = 5
although I suppose even better would be to use the symlinks
/dev/input/touchscreen
/dev/input/power
/dev/input/aux
Are those symlinks created on Freerunner too? If so, that's the best
overall solution.
Also what's the latest thinking on which is best for GTA04, out of Xorg
and Xfbdev? I currently have Xfbdev installed, but I don't remember why
I made that choice.
Regards,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Upgrading QtMoko kernel
On Friday, January 25, 2013 10:38:08, Adrien Dorsaz wrote: > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > Radek has another repository on github called linux-2.6, and that has several branches beginning with v3.7. Probably you can work out which of those is the right one. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
Radek Polak writes: >> I've now reimplemented the GTA04 neoaudioplugin.cpp code so that it >> moves between audio states by changing those 7 switches, instead of >> using ALSA state files, and that seems to work well (including for >> PhoneHeadset, subject to A3 software routing trouble). > > Nice, imo that's the way how it should work. Alsa states were easiest > solution > - that's why i used it. Your code could work much better. You can see that change at https://github.com/neiljerram/qtmoko/commit/f8a040e352bf6158baa508b1d7bfdb7e42aa32d0, and if you like try it out on your A4 too. It works nicely for me on A3. For A4 I've added code to set the 'Voice route' control correctly, which should be equivalent to your recent 5mA saving change (84fb56e), but I don't know if I've got it exactly right because that code isn't executed on my A3. Also for A4 it might be necessary to switch the 'Codec Operation Mode' control between 'Option 1 (audio)' and 'Option 2 (voice/audio)', but I haven't written any code for that yet, because - the last email discussion about that didn't seem completely definitive about whether it is really needed - the "Phone*.state" files in devices/gta04/src/plugins/audiohardware/neo/a4 were inconsistent on this point, i.e. PhoneEarpiece.state had 'Option 2 (voice/audio)' but PhoneSpeaker.state and PhoneHeadset.state had 'Option 1 (audio)' - if we _do_ need to switch 'Codec Operation Mode', we probably need to do that inside pasuspender, so that would make it a bit trickier than the other controls. Therefore it would be nice to know if my change works on A4. >> One detail, >> which is nice but slightly worrying, is that I used to always to get a >> very audible click about 1s before, e.g., hearing the new message >> arrival sound; and with the reimplementation I no longer get that click. >> I _think_ the explanation for that was using pasuspender, and that I no >> longer get it because I no longer need to use pasuspender > > pasuspender will still have to be used on A4 when switching to earpiece, > because you cant switch if some other program has sound card open. Do you mean the switching of 'Codec Operation Mode' here? Is that actually needed for earpiece but not for speaker or headset? If so that would explain what I've described above as "inconsistent". >> - but it's slightly worrying in case that's wrong, and in particular >> in case it's because I'm leaving some circuit on more than before, >> and hence drawing more current. (I haven't seen any evidence for >> drawing extra current.) > > Maybe it can be measured during suspend. Since having this change in place, I've been seeing the same average suspend currents as before. >> The simplicity of >> gta04-gsm-voice-routing is appealing, but I know from previous >> experience that it sometimes fails completely. > > For me the problem was that some other program had soundcard open and gta04- > gsm-voice-routing couldnt open it. If all programs use pulseadio then it can > be solved with pasuspender, but i wish that alsa had the same functionality. > Then we could get rid of pulseaudio. Maybe something like this could be > achieved using alsa plugins. I'm pretty sure I saw some voice routing problems on a few occasions even with pasuspender. However, since moving back to gta04-gsm-voice-routing, and adding Neil Brown's change to start the 2 capture streams at the same time, I've had a few successful calls and no problems. For the moment, therefore, things are all working for me. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
On Thursday, January 17, 2013 12:49:04, Radek Polak wrote: > On Thursday, January 17, 2013 01:52:57 AM Neil Jerram wrote: > > > (In general, for some reason, it appears that the floating point code > > in Pulseaudio and its dependencies doesn't run any better on armhf > > than it does on armel.) > > Hi Neil, > do you have also armhf compiled kernel? I had armel kernel + armhf rootfs and > it was even slower then pure armel. Ah, interesting. After I managed to build QtMoko for armhf, I installed it in the experimental wheezy/armhf rootfs that you released a few months ago. So it depends what the kernel in that rootfs was. > Btw i am using armhf for a few weeks now > and i think i could make a release - just few apps are missing. Nice! I am looking forward to that. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] QtMoko audio state work
On Thursday, January 17, 2013 01:37:58, NeilBrown wrote: > On Thu, 17 Jan 2013 00:52:57 +0000 Neil Jerram > wrote: > > > > The upshot of all that is that I'm now inclined to look more again at > > the other possible solutions, i.e. gta04-gsm-voice-routing (by Radek) > > and alsaloop (as used in SHR). The simplicity of > > gta04-gsm-voice-routing is appealing, but I know from previous > > experience that it sometimes fails completely. > > The only problems that I've had with gta04-gsm-voice-routing is when the > program that plays the alert sound holds on to the audio port for some reason > and thus blocks voice-routing from accessing it. I could probably fix that > with certainty by a well-placed 'kill' at the start of voice-routing but I > want to work out why it is going wrong first (this is a little program of QtMoko tries to cover that by running "pasuspender -- gsm-voice-routing" instead of just "gsm-voice-routing". I think that means that voice routing only starts once pulseaudio has let go of the sound card. > mine ... I think it might be confused by getting signals at bad time - I hate > programming with signals). :-) I guess that's also why you don't want to fix the problem by adding a "kill". > > alsaloop in comparison > > has a drastically different and more complex design. I'm wondering if > > gta04-gsm-voice-routing is unstable _because_ its design is overly > > simple, and if something more like alsaloop is fundamentally needed - > > but I haven't yet worked out even how to start analysing that; any ideas > > would be most welcome. Also, if we did go with alsaloop, I've no idea > > yet how we might try to add in echo cancellation. > > alsaloop is 923 lines while gsm-voice-routing is 673 lines. That isn't > drastically more complex. > The main value-add seems to be sample-rate matching which doesn't seem to be > a big problem in practice (if you need it but don't have it you get > occasional clicks. I don't get any clicks). There's also the big difference - at least to me - that alsaloop is select-driven, so reads from capture into alsaloop's buffer happen independently of writes from the buffer to playback. > > What sort of stability problems do/did you experience with gsm-voice-routing? On several occasions, on receipt of a real incoming call, I've just got a kind of distorted quiet growling noise instead of proper audio from the far end. On the other hand, whenever I'm just testing, the audio almost always works. I wonder if the rest of the phone is using more CPU for a real incoming call than when I'm testing, and if that affects how gsm-voice-routing starts up. Well, you've encouraged me to try more with gsm-voice-routing. I think I need to understand more about _how_ it fails, when it does, and I should be able to discover that by adding more logging. Can I just check: is your gsm-voice-routing code the same as in QtMoko? Many thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
I wanted to write a bit of an update on my recent GTA04/QtMoko work, and would appreciate people's thoughts. This is still focussed on audio handling, because with my A3 I still haven't reached a point of having fully reliable phone calls. (As usual, for the sake of avoiding any possible negative marketing, I should point out that the main problems here are A3-specific. I hope, and believe to be the case, that phone calls are already reliable on A4.) With Neil Brown's helpful input, I've reviewed and improved my understanding of all the ALSA state files and controls. This was prompted specifically by the PhoneHeadset state not working (because it was completely wrong) but more generally it bothers me that we use such an over-general system as ALSA state files when there are really only a handful (in fact, 7 switches and 1 volume control) of independent things that we ever need to change when moving between audio states. Also it has bothered me that we don't have a uniform and persistent way of changing overall volume. I've now reimplemented the GTA04 neoaudioplugin.cpp code so that it moves between audio states by changing those 7 switches, instead of using ALSA state files, and that seems to work well (including for PhoneHeadset, subject to A3 software routing trouble). One detail, which is nice but slightly worrying, is that I used to always to get a very audible click about 1s before, e.g., hearing the new message arrival sound; and with the reimplementation I no longer get that click. I _think_ the explanation for that was using pasuspender, and that I no longer get it because I no longer need to use pasuspender - but it's slightly worrying in case that's wrong, and in particular in case it's because I'm leaving some circuit on more than before, and hence drawing more current. (I haven't seen any evidence for drawing extra current.) Overall phone volume is controlled by the addition of the three DAC2 Gain controls, and the new state change implementation never touches those, which means that it's now possible for a volume control widget to change those controls independently, and for that setting to persist. I haven't implemented that yet though. Next up is the A3 software audio routing. I announced a while ago that I had that working with pulseaudio's module-loopback instead of Radek's gta04-gsm-voice-routing program, and I thought that pulseaudio would be the way to go. Since then I've tried to add in echo cancellation, and tried running on an wheezy/armhf system instead of squeeze/armel - which is believed to be advantageous because of better floating point performance, but I've hit various problems. - Just plain loopback, with module-loopback, appears to use a lot (~50%) of CPU, even when running at just 8000Hz, without any resampling, and without asking for particularly low latency. I don't recall how much CPU gta04-gsm-voice-routing takes, but I don't think it was that much. - Pulseaudio needs to be run without RT scheduling, in order to avoid being killed (because of tight-looping) during the initial window between when a call is started and when the GSM capture device becomes readable. But running without RT scheduling reduces the quality of media playback. - Pulseaudio loopback exhibits some odd artefacts. During that initial window (of maybe a second or two) it cyclically replays whatever was last in the device's playback buffer. It audibly does this for what is played through the earpiece/speaker/headset; I wonder if it might do it a bit in the other direction too, i.e. to the other end of the call? It also seems to cause occasional short sound repeats _during_ a call. I think one possible cause of this is divergence between the two sound cards' clocks, hence the buffers being used up at different rates, and at some point Pulseaudio has to choose some strategy for filling in some missing data (to avoid an underrun). I've also frequently noticed that a DTMF tone pressed by me seems to have an effect on the other end as though I had pressed the key twice instead of once, and I wonder if that might be related to repeating or echoing in the audio stream going to the other end. - Despite the WebRTC echo cancellation's apparent good reputation, I haven't been able to get either it or Speex to work effectively. Also CPU usage when trying to do loopback with echo cancellation is 80-90%, even on armhf. (In general, for some reason, it appears that the floating point code in Pulseaudio and its dependencies doesn't run any better on armhf than it does on armel.) The upshot of all that is that I'm now inclined to look more again at the other possible solutions, i.e. gta04-gsm-voice-routing (by Radek) and alsaloop (as used in SHR). The simplicity of gta04-gsm-voice-routing is appealing, bu
Re: looking for used (or broken) GTA02 (whole or PCB) to purchase
Dmitry Shalnoff writes: > Hi list! > > Is there anybody have broken screen GTA02 for sale? > or maybe intact PCB after upgrade to GTA04? > > I'll be appreciate for reasonable price or maybe somebody just could > give it for free (almost free) after upgrade. Sure, you can have my GTA02 PCB. I haven't used it now for over a year, so can't guarantee that it is perfectly working - but it was working (as far as the software allowed) before I got my GTA04, and I'm not aware of any damage since then. If you'd like that, I guess you should let me know your address. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (=> shutdown/restart menu) handled?
Radek Polak writes: > On Thursday, December 06, 2012 08:25:36 PM Neil Jerram wrote: > >> Neil Jerram writes: >> > Radek Polak writes: >> >> Could people who use GTA04 as phone report contents of the file? This >> >> could help us better to monitor the situation. >> > >> > Here's mine: >> > >> > Sun Nov 18 21:18:30 GMT 2012 modem reenumerated >> >> On reflection, though, I'm confused. What now calls >> fix-modem-reenumerate.sh (apart from the >> restart-when-modem-stops-working, if that is installed)? > > It's called only from serial port class when restart-when-modem-stops- > working.patch is applied. Ah, OK, I think I understand now. You apply restart-when-modem-stops-working.patch to your tree when building for a QtMoko release - right? - which means that the reenumeration ability is included in QtMoko releases. But I lost that reenumeration ability as soon as I did and installed my own build - probably shortly after November 18th. It also means that the high CPU state that I described can only be observed by people who do their own builds, and hence won't have affected most people. I'll include restart-when-modem-stops-working.patch in my build from now on. I think I've been seeing the high CPU state about once every 1-2 days, so I guess I should now see modem reenumeration with similar frequency. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (=> shutdown/restart menu) handled?
Neil Jerram writes: > Radek Polak writes: > >> Could people who use GTA04 as phone report contents of the file? This could >> help us better to monitor the situation. > > Here's mine: > > Sun Nov 18 21:18:30 GMT 2012 modem reenumerated On reflection, though, I'm confused. What now calls fix-modem-reenumerate.sh (apart from the restart-when-modem-stops-working, if that is installed)? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (=> shutdown/restart menu) handled?
Radek Polak writes: > Could people who use GTA04 as phone report contents of the file? This could > help us better to monitor the situation. Here's mine: Sun Nov 18 21:18:30 GMT 2012 modem reenumerated ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (=> shutdown/restart menu) handled?
Radek Polak writes: > On Wednesday, December 05, 2012 01:36:56 PM Neil Jerram wrote: > >> My guesses: >> >> - the recent kernel fix for invalid serial state notifications >> unfortunately isn't quite right, or isn't a complete fix. > > I saw one modem dissappear even with the kernel fix, so the problem is still > not completely solved - although it might work now better. Well I've reviewed the old "Modem crashing?" thread, and in fact Nikolaus wrote back in February: > But that has nothing to do with the usb failing/re-enumeration. (http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html) Therefore I doubt that adopting the serial state kernel fix was a good reason for removing "AT_OPSYS=0,2", and I think that people who don't want "AT_OPSYS=0,2" (such as me) might be better advised to keep installing restart-when-modem-stops-working.patch. It's probably better to restart QtMoko, even though that might lose some application state, than to leave the phone not working and draining lots of power. Or have I misunderstood some part of this? BTW, did we ever establish that "AT_OPSYS=0,2" 100% avoids reenumerations? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (=> shutdown/restart menu) handled?
On Saturday, December 1, 2012 11:56:37, Neil Jerram wrote: > Sometimes my GTA04 gets into a state where the long Power key press is > no longer recognised. I've tried to investigate this, but I can't see > anything in the codebase that makes a link between a long Power key > press and showing the shutdown/restart menu. Does anyone know how that > happens? > > (This is running QtMoko git HEAD code, with Qt 4.8, so this problem > might not affect any releases yet.) > > Thanks, > Neil > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > I just discovered a bit more about the state where a long Power key press does not work. My GTA04 was hot in my pocket even though it should have been suspended. I looked at it and connected over SSH and found that: - it was not suspended - long Power key press did not work - top showed qpe constantly using around 95% CPU. Then: - strace on the qpe PID showed that it was continually reading fd 16, but not getting any data - /proc showed that fd16 was /dev/ttyHS3, i.e. the modem. This is all consistent with other recent occasions when I've noticed high CPU usage, or that the modem has stopped working, and I think also with two other UI symptoms: - scrolling stops being kinetic - when using the keyboard, the pressed key pops up but doesn't pop down again until I press the next key. My guesses: - the recent kernel fix for invalid serial state notifications unfortunately isn't quite right, or isn't a complete fix. - This is also related to recent reports of faster than expected battery drainage. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to access the modem in QtMoko
Neil Jerram writes: > robin writes: > >> I tried the excuting >> >> root@neo:~# /opt/qtmoko/bin/vsexplorer >> /opt/qtmoko/bin/vsexplorer: error while loading shared libraries: >> libqtopiagfx.so.4: cannot open shared object file: No such file or directory >> >> I searched for qtopia but did not find anything specific for libqtopiagfx. > > Do > > . /opt/qtmoko/qpe/env > > before that, then it should work. > > Neil Oops, I meant (for the record): . /opt/qtmoko/qpe.env (Which includes the LD_LIBRARY_PATH change that worked for you.) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (=> shutdown/restart menu) handled?
robin writes: > I quite like being able to bring the phone back from suspend with a quick > press on the powerbutton, checking what time it is and then sending it back > to suspend with another quick press on the power button (but this is the > standard way qtmoko does it if I am not being mistaken, or in which state > does qtmoko turn if I just do a quick press on the power button; I thought > it goes to suspend?!?). > As the freerunner has only two hardware buttons and the aux button is > reported to break sometimes, it might be a good idea to have three press > duration specific settings for the power button. One idea could also be > to have something like this as standard: > > a) <1s -> suspend > b) >1s <4s -> show shutdown/reboot dialog > c) >4s -> show shutdown/reboot dialog > > and this behaviour being read from a text config file. so anyone who needs > the b) slot to do something differently could just change it to fit his/her > needs. I think that's a bit complex, and 4s is a long time to press a button for any requirement. Also I doubt that the infrastructure supports 2 different long key press times - at the moment the config file has "PressedAction" fields and "HeldAction" fields, and there's no apparent way to specify 2 difference hold times. My preference would be: a) Power key pressed -> show Home page b) Power key held -> show shutdown/reboot dialog c) Change the Star icon on the Home page so that it does what a Power key press currently does: i.e. it brings up a page with Favorites, Recent, Frequent and Running tabs, instead of just the Favorites page. This is because when I use the Power key, it's almost always because I want to go back to the Home page in order to do some new thing (while the application that I was in still running). Then we'd have: - for quick suspend: Power key, Lock icon - for Home page: Power key - for Favorites: Power key, Star icon - for running programs: Power key, Star icon, Running tab. Thoughts? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to access the modem in QtMoko
robin writes: > I tried the excuting > > root@neo:~# /opt/qtmoko/bin/vsexplorer > /opt/qtmoko/bin/vsexplorer: error while loading shared libraries: > libqtopiagfx.so.4: cannot open shared object file: No such file or directory > > I searched for qtopia but did not find anything specific for libqtopiagfx. Do . /opt/qtmoko/qpe/env before that, then it should work. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
Radek Polak writes: > Yup it looks ok, will test it later but it's alreaady pulled in my git. Thanks. Given that, I think it's worth me writing a bit more about where/how my work is going, and there's one bugfix below that you should cherry-pick: please look for "While doing that I noticed a bug". Apart from that bugfix I don't want to make any assumptions about what time you have to consider this, so please feel free to leave the rest of this hanging for now. But if you do have time and thoughts I'm sure those would be useful, and in any case it's helpful for me to lay out my thoughts. Firstly, I've just pushed some more commits to https://github.com/neiljerram/qtmoko/commits/nj. These are mostly NOT suitable for your Git master, so please don't pull them, but they may help show what I'm doing. First, my previous set of commits _didn't_ make audio in calls any more reliable. My initial tests were just lucky, and in the days after that I had some calls with no audio, the same as before my cleanups. (In fact that was as expected, because the 'cleanups' didn't really fix anything.) Then I looked for a while at the gta04-gsm-voice-routing code. Empirically, - this code often works - giving clear audio - but sometimes fails catastrophically and gives no audio at all - it seems to fail more often when an incoming call causes the phone to wake up from suspend. My guess is that there is an instability in that code which is more likely to strike when other things on the phone are using CPU - such as just after waking from suspend. Perhaps it could something like this: - CPU load causes gta04-gsm-voice-routing to be slow to read the capture devices, so they report overruns - that may cause the code to loop round and try reading those devices again - which now blocks until time has passed to allow more data to be there - when the code eventually gets to the playback devices, too much time has passed, so they report underrun and don't actually play any data - etc. Then I looked at the alsaloop code and my first impression there was how much more complex it is... Putting everything together, my feeling is that this (loopback) is trickier than it looks to get right, and that gta04-gsm-voice-routing sometimes fails because it doesn't cover all the possible variations. So then I looked at pulseaudio, found Neil Brown's old suggestion, upgraded to the testing version, and eventually stumbled across the resampler method change that makes that work (per other email). I've now integrated that in my code: https://github.com/neiljerram/qtmoko/commit/9f78985e8119961cc520e4d050c88bf1e589b879 I then had to make another change to /etc/pulse/daemon.conf: -; realtime-scheduling = yes + realtime-scheduling = no to avoid pulseaudio being killed by the kernel just after starting the loopback. I guess this is the same basic problem as SHR had with alsaloop here: http://lists.goldelico.com/pipermail/gta04-owner/2012-May/002383.html and ideally the fix would be in pulseaudio to initially spin more slowly. But the realtime-scheduling change works too and doesn't impact general media playback too badly (for my taste). But after that, the integrated pulseaudio in-call audio routing seems to work. Of course I'll be more confident about it if I can have a week of it working every time... While doing that I noticed a bug in my previous "Rework ALSA state / QAudioState handling" commit: it will call gsmVoiceStart() and gsmVoiceStop() even for A4 devices. That's fixed by https://github.com/neiljerram/qtmoko/commit/a362c431531d6b75fcb1894c60e021588ea50d44 so that's one commit that you _should_ cherry-pick. Next what I'd like to do is to make everything louder! There are 3 things that aren't loud enough at the moment: a) the ringtone b) the in-call audio that I hear from the other person c) the in-call audio that the other person hears from me. (b) and (c) depend on good echo cancellation, and I'm hoping pulseaudio's module-echo-cancel will do that for me. I think I can test that, without needing lots of phone calls, simply by playing something (from file) through the earpiece or speaker and simultaneously recording from the microphone. If that works well, we can then just increase all the volumes in the state files. (BTW I think that the Speex echo cancellation in gta04-gsm-voice-routing was less effective because of the playback buffer being 4 times the frame size. This means that when the code sends frame X to ALSA for playback, frame X doesn't actually start playing until 3 cycles later. Therefore we can't immediately use frame X to cancel echo in the microphone sound that we're capturing _now_. I wonder if there was a time when the code had buffer size = frame size, and the buffer size was later increased?) Finally, if
Re: How to access the modem in QtMoko
robin writes: > dear neil, > > thanks for your answer. the reason I wanted to try sending commands to the > modem directly is that I have problems setting up my gprs connection with > qtmoko. Now I have found one site http://www.gsmsite.de/gprs.htm where > they state the AT-commands for manual modem configuration. So I wanted to > try those out. Is this with a Freerunner? Do other Freerunner users have GPRS working? If so I'd suggest logging and comparing your log with theirs. > be explained by your answer: there can be only one for modem access... On the > other hand I think that the openbmap logger and cellhunter allow to scan > your main cell and neighbour cells and allow you to make calls as well, whilst > they run (even though they might not do their scanning during the call). Are openbmap and cellhunter implemented yet for QtMoko? I thought they were implemented for FSO-based distributions only - i.e. SHR and FSO-based Debian - and in that case the access to the modem is managed by FSO. > Generally speaking I would like to > a) turn the modem off completely if I want to do GPS tracking only to save >power Yes, that would be a useful feature. > b) scan main and neighbour cells and still be able to receive calls to bring >my little progress on gsm-location also to qtmoko (works kind of in >shr) I think there are pieces of QtMoko that do that scanning, so the question would be how to connect those with your work. I'll try to look into that a bit more. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (=> shutdown/restart menu) handled?
robin writes: > this would be nice to know so maybe something like > > short press -> suspend We already have the lock icon for lock and suspend, so I'm not sure why we need this on the power key as well. Perhaps because you're thinking of wanting to suspend when looking at some application, and aren't on the home page? > medium press -> ??? eg favourite program > long press -> shutdown/menu Those are what we already have. Personally I'm not sure I could reliably distinguish between 3 press lengths... Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (=> shutdown/restart menu) handled?
Radek Polak writes: > On Saturday, December 01, 2012 12:56:37 PM Neil Jerram wrote: > >> Sometimes my GTA04 gets into a state where the long Power key press is >> no longer recognised. I've tried to investigate this, but I can't see >> anything in the codebase that makes a link between a long Power key >> press and showing the shutdown/restart menu. Does anyone know how that >> happens? > > Hi Neil, > is this what you need? > > https://github.com/radekp/qtmoko/blob/master/devices/gta04/src/libraries/qtopiabase/etc/defaultbuttons.conf Yes, indeed, many thanks. My grep for "shutdown" didn't find this, because of how it's encoded here: HeldActionArgs=@ByteArray(\0\0\0\x1\0\0\0\n\0\0\0\0\x10\0s\0h\0u\0t\0\x64\0o\0w\0n) > Radek > > PS: hope i will have some minutes now for your patches.. Thanks! Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko: how is long Power key press (=> shutdown/restart menu) handled?
Sometimes my GTA04 gets into a state where the long Power key press is
no longer recognised. I've tried to investigate this, but I can't see
anything in the codebase that makes a link between a long Power key
press and showing the shutdown/restart menu. Does anyone know how that
happens?
(This is running QtMoko git HEAD code, with Qt 4.8, so this problem
might not affect any releases yet.)
Thanks,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: How to access the modem in QtMoko
robin writes: > how do I communicate directly with the modem on /dev/ttySAC0? I'm not sure that question makes sense. When you're running QtMoko, there's a component somewhere inside QtMoko whose job it is to communicate with the modem, and it would be either impossible (because of locking) or unwise for some other code to try to communicate with the modem in parallel with that. If you switch QtMoko off (/etc/init.d/qtmoko stop), then you're left with a plain Debian squeeze system, and you can use any Debian squeeze tools you like to communicate with /dev/ttySAC0. > For the direct acces I tried cu -l /dev/ttySAC0 as it is stated on the > openmoko wiki site but I get 'cu command not found'. does anyone know which > package I have to install and if it is still necessary to do > chown uucp.uucp /dev/ttySAC0 to be able to access the modem? I don't know, but I typically investigate such questions by a combination of 'apt-cache search ' and searching. E.g. maybe searching for 'modem' or 'serial' at packages.debian.org would help. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Qt 4.8 "Draft Message" problem
Radek Polak writes: > On Thursday, November 22, 2012 07:55:31 PM Neil Jerram wrote: > >> By the way, I am also making gradual progress on the "Draft Message" >> problem, which is to do with the QMailMessage::Incoming flag being >> incorrectly reset on some messages. It affects email as well as SMS, >> and I think it's timing dependent because it doesn't every incoming >> message. > > For me it triggered when i received SMS on v49 rootfs and rebooted to rootfs > with 4.8.3 Qt. Maybe this will help you. FYI I've narrowed this down to a QtSql/sqlite problem. - By logging all the SQL operations from QMailStore, I can see that QMailStore always sets the status field for newly received messages to a value that includes the QMailMessage::Incoming flag. But if I copy the database to my laptop and look at it with sqlitebrowser, I see newly received messages with status = 0. The missing QMailMessage::Incoming flag then accounts for SMSs being shown as "Draft Message" and for emails being listed with the name of the recipient instead of the sender. - If I revert just qtopiacore/qt/src/sql and qtopiacore/qt/src/3rdparty/sqlite back to v4.7.4-qtmoko-v46, but keep the rest of Qt at v4.8.3-qtmoko-v49, the problem disappears. - If I move qtopiacore/qt/src/sql and qtopiacore/qt/src/3rdparty/sqlite forward to e2e62bc, the problem comes back again. e2e62bc is just after the sqlite code was upgraded to 3.7.7.1. There's still a way to go on this, but I thought worth sharing in case you or anyone else sees problems that might be SQL-related. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
Radek Polak writes: > Hi Neil, > thanks for the patches, i'll take a look at them in a few days. I am going to > have a busy weeks at paid work probably until the Christmas so i have to slow > down on QtMoko side a bit... No problem, and thanks. I hope that other work goes well! Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko audio state work
Hi Radek, After a day yesterday where the A3 audio didn't work for me in several calls, I decided to take a closer look at the QtMoko audio code. That led to a sequence of small (I think) cleanups, and a reworking of the audio state handling code, and I'd appreciate hearing what you think about that. I've pushed my work-in-progress branch to https://github.com/neiljerram/qtmoko/commits/nj, and the relevant commits are those from https://github.com/neiljerram/qtmoko/commit/0062faf815f5b1ede6624acac08bf3b8ec7040bd to https://github.com/neiljerram/qtmoko/commit/958212671741685ae05de9e2564ea45272f985d6 inclusive, excluding https://github.com/neiljerram/qtmoko/commit/18404194e37b85a315a64ae23b3ac97e7dab3256. In summary, these changes: - remove code that I believe has no effect on the GTA04 - simply so as to make the audio-related code overall easier to understand - simplify and clarify the *AudioState classes and related code in neoaudioplugin.cpp - allow for different ALSA state files for A3 and A4 - rename the state files to match the QtMoko domain (Phone/Media) and profile (Headset/Speaker/Earpiece/Bluetooth) names - make the set of A3 state files more consistent with each other. Apart from the last point, all these changes should just be cleanups and have no practical effect. In particular, on A4 there should be no change at all. On A3 the last point may have a practical effect, if the previous switching of 'AVADC Clock Priority' and 'Voice route' values was sometimes causing a problem. I did a load of test calls this morning and had good audio on all of them. That might just be good luck - or it might indicate that that last point really does make a difference for A3. I guess I'll know better after a bit more experience. Anyway, I'd appreciate hearing if you think this line of work looks worthwhile, or any other thoughts you or others have about it. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko media playback progress?
Neil Jerram writes:
> Radek Polak writes:
>
>> On Wednesday, November 21, 2012 11:29:35 PM Neil Jerram wrote:
>>
>>> Hi Radek,
>>>
>>> With current git master (well, actually 052d8d852), I don't see the
>>> progress bar moving when I play a piece of music in the media player.
>>> Do you?
>>
>> I dont either. The gstreamer looks quite unfinished yet. But it shouldnt be
>> that hard. You can take insipration how to do it in phonon - it does nearly
>> the same that we do, e.g. qwidgetvideosink.cpp is nearly the same as our
>> gstreamerqtopiavideosink.cpp etc..
>>
>> If you would like to take a look at it, it would be nice.
>
> Sure, I will do that.
The attached patch fixes this.
Regards,
Neil
>From 033c9473a840cdfdc9171cae27a204c853efc5aa Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Fri, 23 Nov 2012 23:10:23 +
Subject: [PATCH] gstreamer: generate periodic indication of media playback
position
---
.../mediaengines/gstreamer/gstreamerbushelper.cpp | 22
1 file changed, 22 insertions(+)
diff --git a/src/plugins/mediaengines/gstreamer/gstreamerbushelper.cpp b/src/plugins/mediaengines/gstreamer/gstreamerbushelper.cpp
index b22dbb8..af358d6 100644
--- a/src/plugins/mediaengines/gstreamer/gstreamerbushelper.cpp
+++ b/src/plugins/mediaengines/gstreamer/gstreamerbushelper.cpp
@@ -37,12 +37,14 @@ public:
this->m_helper = helper;
setParent(helper);
m_tag = gst_bus_add_watch_full(bus, 0, busCallback, this, NULL);
+ m_intervalTimer->start();
}
void removeWatch(BusHelper* helper)
{
Q_UNUSED(helper);
g_source_remove(m_tag);
+ m_intervalTimer->stop();
}
static BusHelperPrivate* instance()
@@ -50,7 +52,26 @@ public:
return new BusHelperPrivate;
}
+private slots:
+void interval()
+{
+emit m_helper->message(Message());
+}
+
private:
+BusHelperPrivate()
+{
+m_intervalTimer = new QTimer(this);
+m_intervalTimer->setInterval(250);
+
+connect(m_intervalTimer, SIGNAL(timeout()), SLOT(interval()));
+}
+
+~BusHelperPrivate()
+{
+delete m_intervalTimer;
+}
+
void processMessage(GstBus* bus, GstMessage* message)
{
Q_UNUSED(bus);
@@ -65,6 +86,7 @@ private:
guint m_tag;
BusHelper* m_helper;
+QTimer* m_intervalTimer;
};
#else
--
1.7.10.4
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
QtMoko email composition patch
If you compose or forward email, on the recipients/subject page, you can
click on the CC entry field to type in an email address, but you can't
do that with the To entry field. The attached patch fixes that.
Thanks,
Neil
>From 424743d249ae098a0dc405adcee030d1b0e74e88 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Tue, 16 Oct 2012 19:42:50 +0100
Subject: [PATCH] Enable typing in the To field, when sending an email
---
src/libraries/qtopiamail/detailspage.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libraries/qtopiamail/detailspage.cpp b/src/libraries/qtopiamail/detailspage.cpp
index 40f035c..5c46902 100644
--- a/src/libraries/qtopiamail/detailspage.cpp
+++ b/src/libraries/qtopiamail/detailspage.cpp
@@ -371,7 +371,7 @@ DetailsPage::DetailsPage( QWidget *parent, const char *name )
m_toFieldLabel->setText( tr( "To" ) );
m_toBox = new QHBoxLayout( );
m_toField = new RecipientEdit( this );
-setFocusProxy(m_toField);
+//setFocusProxy(m_toField);
m_toBox->addWidget( m_toField );
m_toFieldLabel->setBuddy(m_toField);
connect( m_toField, SIGNAL(textChanged(QString)), this, SIGNAL(changed()) );
--
1.7.10.4
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko pulseaudio patches
Gilles Filippini writes:
> Hi Neil,
>
> Neil Jerram a écrit , Le 22/11/2012 20:09:
>> diff --git a/debian/control b/debian/control
>> index 61f4a62..3904775 100644
>> --- a/debian/control
>> +++ b/debian/control
>> @@ -2,7 +2,7 @@ Source: qtmoko
>> Section: comm
>> Priority: optional
>> Maintainer: Radek Polak
>> -Build-Depends: debhelper (>= 7.0.50~), libxext-dev, libasound2-dev,
>> libdbus-1-dev, libssl-dev, libts-dev, libbluetooth-dev, libxtst-dev,
>> libpng12-dev, libv4l-dev, libspeexdsp-dev, libglib2.0-dev, libsqlite3-dev,
>> libgstreamer-plugins-base0.10-dev, libtiff4-dev, libmng-dev, quilt,
>> libvorbis-dev
>> +Build-Depends: debhelper (>= 7.0.50~), libxext-dev, libasound2-dev,
>> libdbus-1-dev, libssl-dev, libts-dev, libbluetooth-dev, libxtst-dev,
>> libpng12-dev, libv4l-dev, libspeexdsp-dev, libglib2.0-dev, libsqlite3-dev,
>> libgstreamer-plugins-base0.10-dev, libtiff4-dev, libmng-dev, quilt,
>> libvorbis-dev, libpulse-dev
>> Standards-Version: 3.9.2
>> Homepage: http://www.qtmoko.org
>> Vcs-Git: git://github.com/radekp/qtmoko.git
>
> This hunk is not needed: debian/control is a generated file, from
> debian/control-src and debian/control-{gta04,neo,pc}. See debian/rules.
>
> The build dependencies in debian/control-src already have libpulse-dev.
Ah thanks. I suspected something like that, but hadn't worked out the
details. A revised patch is attached without that hunk.
Regards,
Neil
>From a6231bf384a7fb1b6016e2ea164262c02b0359b4 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Sun, 18 Nov 2012 22:47:05 +
Subject: [PATCH] Add libpulse-dev as build-dep for qt
---
scripts/qtmoko-chroot.sh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/qtmoko-chroot.sh b/scripts/qtmoko-chroot.sh
index 8dce56f..f0eb0b8 100755
--- a/scripts/qtmoko-chroot.sh
+++ b/scripts/qtmoko-chroot.sh
@@ -34,7 +34,7 @@ then
fi
echo "Installing chroot packages"
-until cdebootstrap --flavour=minimal --include=build-essential,git,openssh-client,ccache,locales,procps,psmisc,libxext-dev,libasound2-dev,libdbus-1-dev,libssl-dev,libts-dev,libbluetooth-dev,libxtst-dev,libpng12-dev,libjpeg8-dev,libv4l-dev,libspeexdsp-dev,libglib2.0-dev,libsqlite3-dev,quilt,libgstreamer0.10-dev,libgstreamer-plugins-base0.10-dev squeeze ../qtmoko-chroot http://cdn.debian.net/debian/; do
+until cdebootstrap --flavour=minimal --include=build-essential,git,openssh-client,ccache,locales,procps,psmisc,libxext-dev,libasound2-dev,libdbus-1-dev,libssl-dev,libts-dev,libbluetooth-dev,libxtst-dev,libpng12-dev,libjpeg8-dev,libv4l-dev,libspeexdsp-dev,libglib2.0-dev,libsqlite3-dev,quilt,libgstreamer0.10-dev,libgstreamer-plugins-base0.10-dev,libpulse-dev squeeze ../qtmoko-chroot http://cdn.debian.net/debian/; do
:
done
fi
@@ -80,7 +80,7 @@ apt-get install g++-4.4-arm-linux-gnueabi
echo "Installing xapt and ARM qtmoko dependencies"
apt-get install xapt
-xapt -a armel -m libxext-dev libasound2-dev libdbus-1-dev libssl-dev libts-dev libbluetooth-dev libxtst-dev libpng12-dev libjpeg8-dev libv4l-dev libspeexdsp-dev libglib2.0-dev libsqlite3-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libvorbis-dev
+xapt -a armel -m libxext-dev libasound2-dev libdbus-1-dev libssl-dev libts-dev libbluetooth-dev libxtst-dev libpng12-dev libjpeg8-dev libv4l-dev libspeexdsp-dev libglib2.0-dev libsqlite3-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libvorbis-dev libpulse-dev
echo "export PATH=/usr/lib/ccache:\$PATH" >> /root/.bashrc
echo "PS1='qtmoko-chroot:\w\\\$ '" >> /root/.bashrc
--
1.7.10.4
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
"dmatthews.org" writes: > Hi Neil > >> 1. it wants to mount and unmount the device (/media/card) where backups >> are stored, whereas QtMoko wants /media/card mounted the whole time > > That's not the case. You can configure it to backup to a directory on the > same device as the one you're backing up. > >> 2. it wants to use symbolic links on the backup device, which FAT >> doesn't support. >> > > You could make a ext2/3 partition on the card and have that mounted on > /media/card with a backup directory. > > Although I'm not wanting to do this myself, I've no doubt it's doable. I'm a > long term backup2l user - I fell in love with it after reimaging a foobarred > server and having everything back up exactly as it was within an hour. > > IMO backup2l is an unsung gem It is a very nice tool for its job, but I'm thinking now that that job is not exactly what we need for QtMoko, and that we'd be better off with a QtMoko-specific tool. - For QtMoko we only want a one-off, user-initiated full user data backup immediately prior to each upgrade. We don't need the automatic cron-based backing up and backup levels (i.e. full + incremental levels) that backup2l provides. - For QtMoko I think the restore operation, or at least some of it, ideally needs to happen immediately after unpacking the new rootfs, i.e. before the new QtMoko has had any chance to run. One might not even be running on Linux at that point. Therefore that step should be as minimal as possible - ideally just unpacking a tarball of user data. - We will probably want other not-just-backup operations for QtMoko, such as exporting contacts to a file and later reimporting them, or reinstalling additional packages in the upgraded system. Probably backup2l has hooks for these kinds of things, but I suspect it could become harder to maintain a combined backup2l + hook script system than just to write a QtMoko-specific script. My first stab at that is attached below. Comments welcome! Radek, it's pretty alpha and incomplete, but would it perhaps be worth committing already to the repository, so as to have something to build from? Regards, Neil >From 41eb4dc2912e7efc5aab16559a4bcb27d026c35b Mon Sep 17 00:00:00 2001 From: Neil Jerram Date: Sun, 18 Nov 2012 21:04:12 + Subject: [PATCH] Backing up settings before an upgrade - first stab --- src/module_essentials.pri |1 + src/settings/backup/backup.svg | 115 src/settings/backup/desktop/backup.desktop |9 +++ src/settings/backup/qbuild.pro | 15 src/settings/backup/scripts/backup.sh | 77 +++ 5 files changed, 217 insertions(+) create mode 100644 src/settings/backup/backup.svg create mode 100644 src/settings/backup/desktop/backup.desktop create mode 100644 src/settings/backup/qbuild.pro create mode 100755 src/settings/backup/scripts/backup.sh diff --git a/src/module_essentials.pri b/src/module_essentials.pri index 9eeb26e..71df725 100644 --- a/src/module_essentials.pri +++ b/src/module_essentials.pri @@ -5,6 +5,7 @@ PROJECTS*=\ 3rdparty/applications/qx \ 3rdparty/applications/screenshot \ 3rdparty/applications/qterminal \ +settings/backup \ settings/light-and-power \ settings/security \ applications/calculator \ diff --git a/src/settings/backup/backup.svg b/src/settings/backup/backup.svg new file mode 100644 index 000..f4ae7be --- /dev/null +++ b/src/settings/backup/backup.svg @@ -0,0 +1,115 @@ + + +http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"; [ + http://www.w3.org/2000/svg";> + http://www.w3.org/1999/xlink";> +]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/settings/backup/desktop/backup.desktop b/src/settings/backup/desktop/backup.desktop new file mode 100644 index 000..ec0e437 --- /dev/null +++ b/src/settings/backup/desktop/backup.desktop @@ -0,0 +1,9 @@ +[Translation] +File=QtopiaApplications +Context=PowerManagerServices +[Desktop Entry] +Comment[]=Backup settings before an upgrade +Exec=backup.sh +Icon=backup/backup +Type=ConsoleApplication +Name[]=Backup Settings diff --git a/src/settings/backup/qbuild.pro b/src/settings/backup/qbuild.pro new file mode 100644 index 000..a361038 --- /dev/null +++ b/src/settings/backup/qbuild.pro @@ -0,0 +1,15 @@ +script.files=scripts/* +script.path=/bin +script.hint=script +INSTALLS+=script + +desktop.files+=desktop/backup.desktop + +desktop.path=/apps/Settings +desktop.hint=desktop +INSTALLS+=desktop + +
QtMoko logging/theme patch
Hi Radek, Another random small patch here. I've been noticing logs like the following on every restart, and the patch fixes that. Nov 20 22:09:04 neo Qtopia: QString::arg: Argument missing: "1 missed", @/Communications/Calls/MissedCalls Nov 20 22:09:04 neo Qtopia: QString::arg: Argument missing: "1 new", @/Communications/Messages/NewMessages Regards, Neil >From 9b28cb19a53592ab1b8b37fe6a3136b7e18f2276 Mon Sep 17 00:00:00 2001 From: Neil Jerram Date: Tue, 20 Nov 2012 22:53:00 + Subject: [PATCH 09/13] Avoid "QString::arg: Argument missing" logs Specifically these: Nov 20 22:09:04 neo Qtopia: QString::arg: Argument missing: "1 missed", @/Communications/Calls/MissedCalls Nov 20 22:09:04 neo Qtopia: QString::arg: Argument missing: "1 new", @/Communications/Messages/NewMessages These arise because the "faen"-derived themes have special cases for 1 missed call and 1 new message - presumably for translation into languages where the 1 case is different from N != 1. All those places have an unnecessary , which causes the logs, and which this commit removes. --- etc/themes/faenqo/home.xml |4 ++-- etc/themes/faenqomod/home.xml|4 ++-- etc/themes/mokofaen/home.xml |4 ++-- etc/themes/mokofaen/home_classic.xml |4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/etc/themes/faenqo/home.xml b/etc/themes/faenqo/home.xml index 51cc841..a511d48 100644 --- a/etc/themes/faenqo/home.xml +++ b/etc/themes/faenqo/home.xml @@ -38,7 +38,7 @@ - 1 missed@/Communications/Calls/MissedCalls + 1 missed @@ -60,7 +60,7 @@ -1 new@/Communications/Messages/NewMessages +1 new %1 new@/Communications/Messages/NewMessages diff --git a/etc/themes/faenqomod/home.xml b/etc/themes/faenqomod/home.xml index 385de0d..8590b3b 100644 --- a/etc/themes/faenqomod/home.xml +++ b/etc/themes/faenqomod/home.xml @@ -73,7 +73,7 @@ - 1 missed@/Communications/Calls/MissedCalls + 1 missed @@ -95,7 +95,7 @@ -1 new@/Communications/Messages/NewMessages +1 new %1 new@/Communications/Messages/NewMessages diff --git a/etc/themes/mokofaen/home.xml b/etc/themes/mokofaen/home.xml index 279a45d..6fd654f 100755 --- a/etc/themes/mokofaen/home.xml +++ b/etc/themes/mokofaen/home.xml @@ -63,7 +63,7 @@ - 1 missed@/Communications/Calls/MissedCalls + 1 missed @@ -85,7 +85,7 @@ -1 new@/Communications/Messages/NewMessages +1 new %1 new@/Communications/Messages/NewMessages diff --git a/etc/themes/mokofaen/home_classic.xml b/etc/themes/mokofaen/home_classic.xml index 96285a5..439771a 100755 --- a/etc/themes/mokofaen/home_classic.xml +++ b/etc/themes/mokofaen/home_classic.xml @@ -76,7 +76,7 @@ - 1 missed@/Communications/Calls/MissedCalls + 1 missed @@ -98,7 +98,7 @@ -1 new@/Communications/Messages/NewMessages +1 new %1 new@/Communications/Messages/NewMessages -- 1.7.10.4 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko pulseaudio patches
Hi Radek,
Here are some minor patches related to pulseaudio, for your
consideration.
The first one may not be quite right, because my impression from Gilles'
recent change is that perhaps debian/control should now be generated
from some other file? (or perhaps the same change should be made in
other places?) So please either tweak or bounce that back to me for
revision.
The other two are straightforward, I believe.
Regards,
Neil
>From b96f37d7614f13bee2bd25682360e71b302f4d4a Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Sun, 18 Nov 2012 22:47:05 +
Subject: [PATCH 08/13] Add libpulse-dev as build-dep for qt
---
debian/control |2 +-
scripts/qtmoko-chroot.sh |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 61f4a62..3904775 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: qtmoko
Section: comm
Priority: optional
Maintainer: Radek Polak
-Build-Depends: debhelper (>= 7.0.50~), libxext-dev, libasound2-dev, libdbus-1-dev, libssl-dev, libts-dev, libbluetooth-dev, libxtst-dev, libpng12-dev, libv4l-dev, libspeexdsp-dev, libglib2.0-dev, libsqlite3-dev, libgstreamer-plugins-base0.10-dev, libtiff4-dev, libmng-dev, quilt, libvorbis-dev
+Build-Depends: debhelper (>= 7.0.50~), libxext-dev, libasound2-dev, libdbus-1-dev, libssl-dev, libts-dev, libbluetooth-dev, libxtst-dev, libpng12-dev, libv4l-dev, libspeexdsp-dev, libglib2.0-dev, libsqlite3-dev, libgstreamer-plugins-base0.10-dev, libtiff4-dev, libmng-dev, quilt, libvorbis-dev, libpulse-dev
Standards-Version: 3.9.2
Homepage: http://www.qtmoko.org
Vcs-Git: git://github.com/radekp/qtmoko.git
diff --git a/scripts/qtmoko-chroot.sh b/scripts/qtmoko-chroot.sh
index 8dce56f..f0eb0b8 100755
--- a/scripts/qtmoko-chroot.sh
+++ b/scripts/qtmoko-chroot.sh
@@ -34,7 +34,7 @@ then
fi
echo "Installing chroot packages"
-until cdebootstrap --flavour=minimal --include=build-essential,git,openssh-client,ccache,locales,procps,psmisc,libxext-dev,libasound2-dev,libdbus-1-dev,libssl-dev,libts-dev,libbluetooth-dev,libxtst-dev,libpng12-dev,libjpeg8-dev,libv4l-dev,libspeexdsp-dev,libglib2.0-dev,libsqlite3-dev,quilt,libgstreamer0.10-dev,libgstreamer-plugins-base0.10-dev squeeze ../qtmoko-chroot http://cdn.debian.net/debian/; do
+until cdebootstrap --flavour=minimal --include=build-essential,git,openssh-client,ccache,locales,procps,psmisc,libxext-dev,libasound2-dev,libdbus-1-dev,libssl-dev,libts-dev,libbluetooth-dev,libxtst-dev,libpng12-dev,libjpeg8-dev,libv4l-dev,libspeexdsp-dev,libglib2.0-dev,libsqlite3-dev,quilt,libgstreamer0.10-dev,libgstreamer-plugins-base0.10-dev,libpulse-dev squeeze ../qtmoko-chroot http://cdn.debian.net/debian/; do
:
done
fi
@@ -80,7 +80,7 @@ apt-get install g++-4.4-arm-linux-gnueabi
echo "Installing xapt and ARM qtmoko dependencies"
apt-get install xapt
-xapt -a armel -m libxext-dev libasound2-dev libdbus-1-dev libssl-dev libts-dev libbluetooth-dev libxtst-dev libpng12-dev libjpeg8-dev libv4l-dev libspeexdsp-dev libglib2.0-dev libsqlite3-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libvorbis-dev
+xapt -a armel -m libxext-dev libasound2-dev libdbus-1-dev libssl-dev libts-dev libbluetooth-dev libxtst-dev libpng12-dev libjpeg8-dev libv4l-dev libspeexdsp-dev libglib2.0-dev libsqlite3-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libvorbis-dev libpulse-dev
echo "export PATH=/usr/lib/ccache:\$PATH" >> /root/.bashrc
echo "PS1='qtmoko-chroot:\w\\\$ '" >> /root/.bashrc
--
1.7.10.4
>From 333b1f301fdc1d3a590546db013a466693b6c23c Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Tue, 20 Nov 2012 22:54:13 +
Subject: [PATCH 10/13] Kill pulse.sh and pulseaudio when stopping QtMoko
Otherwise there are two copies of pulse.sh when QtMoko is started up
again.
---
debian/qtmoko-gta04.init |2 ++
debian/qtmoko-neo.init |2 ++
debian/qtmoko-pc.init|2 ++
3 files changed, 6 insertions(+)
diff --git a/debian/qtmoko-gta04.init b/debian/qtmoko-gta04.init
index 90fe4c6..f67ba2e 100644
--- a/debian/qtmoko-gta04.init
+++ b/debian/qtmoko-gta04.init
@@ -47,6 +47,8 @@ do_stop()
{
rm -f /tmp/restart-qtopia
killall -q qpe atd quicklauncher mediaserver mediaplayer sipagent telepathyagent
+killall -q pulse.sh
+killall -q pulseaudio
return 0
}
diff --git a/debian/qtmoko-neo.init b/debian/qtmoko-neo.init
index 90fe4c6..f67ba2e 100644
--- a/debian/qtmoko-neo.init
+++ b/debian/qtmoko-neo.init
@@ -47,6 +47,8 @@ do_stop()
{
rm -f /tmp/restart-qtopia
killall -q qpe atd quicklauncher mediaserver mediaplayer sipagent telepathyagent
+killall -q pulse.sh
+killall -q pulseaudio
return 0
}
diff --git a/debian/qtmoko-pc.init b/debian/qtmoko-pc.init
index 90fe4c6..f67ba2e 100644
--- a/debian/qtmoko-pc.init
+++ b/debian/qtmoko-pc.init
@@ -47,6 +47,8 @@ do_stop()
{
Re: QtMoko media playback progress?
Radek Polak writes: > On Wednesday, November 21, 2012 11:29:35 PM Neil Jerram wrote: > >> Hi Radek, >> >> With current git master (well, actually 052d8d852), I don't see the >> progress bar moving when I play a piece of music in the media player. >> Do you? > > I dont either. The gstreamer looks quite unfinished yet. But it shouldnt be > that hard. You can take insipration how to do it in phonon - it does nearly > the same that we do, e.g. qwidgetvideosink.cpp is nearly the same as our > gstreamerqtopiavideosink.cpp etc.. > > If you would like to take a look at it, it would be nice. Sure, I will do that. >> I wondered if this might be connected with using the '#ifndef >> QT_NO_GLIB' implementation of gstreamerbushelper.cpp. The '#ifdef >> QT_NO_GLIB' appears to have support for reporting progress, by emitting >> the message() signal with a null message, but I don't see any equivalent >> of that in the '#ifndef QT_NO_GLIB' implementation. > > It's very likely that the gstreamer was tested and implement for the > QT_NO_GLIB variant. > > We are now using glib event loop (same as X11-qt) - this is needed e.g. for > html5 videos. If there is simple way to add this to our glib ifdef then it > would be great. Thanks, that's good to know. By the way, I am also making gradual progress on the "Draft Message" problem, which is to do with the QMailMessage::Incoming flag being incorrectly reset on some messages. It affects email as well as SMS, and I think it's timing dependent because it doesn't every incoming message. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko media playback progress?
Hi Radek, With current git master (well, actually 052d8d852), I don't see the progress bar moving when I play a piece of music in the media player. Do you? I wondered if this might be connected with using the '#ifndef QT_NO_GLIB' implementation of gstreamerbushelper.cpp. The '#ifdef QT_NO_GLIB' appears to have support for reporting progress, by emitting the message() signal with a null message, but I don't see any equivalent of that in the '#ifndef QT_NO_GLIB' implementation. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Community] [Gta04-owner] QtMoko v49
Radek Polak writes: > Hi, > can you please try: > > killall pulse.sh > killall pulseaudio > . /opt/qtmoko/qpe.env > pulseaudio > > Does it start? My output is like this: > > root@neo:/root# killall pulse.sh > root@neo:/root# killall pulseaudio > root@neo:/root# . /opt/qtmoko/qpe.env > root@neo:/root# pulseaudio > W: main.c: This program is not intended to be run as root (unless --system is > specified). > W: main.c: Unable to contact D-Bus: > org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated > abnormally with the following error: Autolaunch error: X11 initialization > failed. > W: ratelimit.c: 15 events suppressed root@neo:~# /etc/init.d/sysklogd start Starting system log daemon root@neo:~# tail -f /var/log/messages Nov 18 15:11:43 neo pulse.sh: E: main.c: Module load failed. Nov 18 15:11:43 neo pulse.sh: E: main.c: Failed to initialize daemon. Nov 18 15:11:43 neo pulse.sh: Starting pulseaudio Nov 18 15:11:43 neo pulse.sh: W: main.c: This program is not intended to be run as root (unless --system is specified). Nov 18 15:11:44 neo pulse.sh: E: module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success Nov 18 15:11:44 neo pulse.sh: E: module.c: Failed to load module "module-console-kit" (argument: ""): initialization failed. Nov 18 15:11:44 neo pulse.sh: E: main.c: Module load failed. Nov 18 15:11:44 neo pulse.sh: E: main.c: Failed to initialize daemon. Nov 18 15:11:44 neo pulse.sh: Starting pulseaudio Nov 18 15:11:44 neo pulse.sh: W: main.c: This program is not intended to be run as root (unless --system is specified). Nov 18 15:11:44 neo pulse.sh: E: module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success Nov 18 15:11:44 neo pulse.sh: E: module.c: Failed to load module "module-console-kit" (argument: ""): initialization failed. Nov 18 15:11:44 neo pulse.sh: E: main.c: Module load failed. Nov 18 15:11:44 neo pulse.sh: E: main.c: Failed to initialize daemon. Nov 18 15:11:44 neo pulse.sh: Starting pulseaudio Nov 18 15:11:45 neo pulse.sh: W: main.c: This program is not intended to be run as root (unless --system is specified). Nov 18 15:11:45 neo pulse.sh: E: module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success Nov 18 15:11:45 neo pulse.sh: E: module.c: Failed to load module "module-console-kit" (argument: ""): initialization failed. Nov 18 15:11:45 neo pulse.sh: E: main.c: Module load failed. Nov 18 15:11:45 neo pulse.sh: E: main.c: Failed to initialize daemon. Nov 18 15:11:45 neo pulse.sh: Starting pulseaudio Nov 18 15:11:45 neo pulse.sh: W: main.c: This program is not intended to be run as root (unless --system is specified). Nov 18 15:11:46 neo pulse.sh: E: module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success Nov 18 15:11:46 neo pulse.sh: E: module.c: Failed to load module "module-console-kit" (argument: ""): initialization failed. Nov 18 15:11:46 neo pulse.sh: E: main.c: Module load failed. Nov 18 15:11:46 neo pulse.sh: E: main.c: Failed to initialize daemon. Nov 18 15:11:46 neo pulse.sh: Starting pulseaudio ^C root@neo:~# killall pulse.sh root@neo:~# killall pulseaudio pulseaudio: no process found root@neo:~# ps wuax | grep pulse root 2755 0.0 0.1 1864 580 pts/0S+ 15:12 0:00 grep pulse root@neo:~# . /opt/qtmoko/qpe.env root@neo:/root# pulseaudio W: main.c: This program is not intended to be run as root (unless --system is specified). E: module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success E: module.c: Failed to load module "module-console-kit" (argument: ""): initialization failed. E: main.c: Module load failed. E: main.c: Failed to initialize daemon. root@neo:/root# > I see the difference is in "E: module-console-kit.c". Can you try comment out > the line "load-module module-console-kit" in /etc/pulse/default.pa? root@neo:/root# nano /etc/pulse/default.pa root@neo:/root# pulseaudio W: main.c: This program is not intended to be run as root (unless --system is specified). W: main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally with the following error: Autolaunch error: X1
Re: [Gta04-owner] QtMoko v49
Radek Polak writes: > Hi, > QtMoko v49 for GTA04 is now available [1]. There have been really many > changes > this time so be careful :) For me, after installing this, pulseaudio fails to start up. The log has repeating messages log this: ... Jan 1 00:50:10 neo pulse.sh: Starting pulseaudio Jan 1 00:50:11 neo pulse.sh: W: main.c: This program is not intended to be run as root (unless --system is specified). Jan 1 00:50:11 neo pulse.sh: E: module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success Jan 1 00:50:11 neo pulse.sh: E: module.c: Failed to load module "module-console-kit" (argument: ""): initialization failed. Jan 1 00:50:11 neo pulse.sh: E: main.c: Module load failed. Jan 1 00:50:11 neo pulse.sh: E: main.c: Failed to initialize daemon. Jan 1 00:50:11 neo pulse.sh: Starting pulseaudio Jan 1 00:50:11 neo pulse.sh: W: main.c: This program is not intended to be run as root (unless --system is specified). Jan 1 00:50:12 neo pulse.sh: E: module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success Jan 1 00:50:12 neo pulse.sh: E: module.c: Failed to load module "module-console-kit" (argument: ""): initialization failed. Jan 1 00:50:12 neo pulse.sh: E: main.c: Module load failed. Jan 1 00:50:12 neo pulse.sh: E: main.c: Failed to initialize daemon. ... and average load (according to top) is about 1.3, which makes other UI operations on the phone sluggish. This is after a real vanilla installation with a newly downloaded v49 tarball. After unpacking the tarball I did restore a few things under /etc/ssh and /home/root (per the backup/restore thread), but I doubt that those would be the cause of this pulseaudio startup problem. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
Boudewijn writes: > Is it not FAT, so that it can be exported as "mass storage"? The rationale > being, that most host operating systems would have FAT drivers on board? > > > > I think that for many of us, the systems we connect to via USB already have > drivers for other file systems than FAT. > > > > Do you have an idea of the general area in the QtMoko sources, where there > might be a check on the FS type? I can try to have a look if I can get > anywhere > with some pointers. Or is there a mass storage standard, that does not allow > for other FS than FAT? I'm afraid I haven't yet looked into or thought about the question of why we use FAT for /media/card, or if FAT is really required. (I just followed the partitioning instructions that said FAT, but that was many moons ago and I can't even quickly find now where those instructions live.) I certainly agree with you that probably everyone in our community would be able to mount a non-FAT filesystem. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
Neil Jerram writes: > backup2l looks pretty nice; thanks for the suggestion. Two problems though: 1. it wants to mount and unmount the device (/media/card) where backups are stored, whereas QtMoko wants /media/card mounted the whole time 2. it wants to use symbolic links on the backup device, which FAT doesn't support. (1) feels fixable, but (2) feels tricky to work around. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel panic on Freerunner QtMoko boot
I'm afraid I can't help much, but... Harry Prevor writes: > [5.12] UBIFS error (pid 1): ubifs_get_sb: cannot open > "ubi0:om-gta02-rootfs", error -19 This is obviously the key problem. Is "ubi0:om-gta02-rootfs" a valid specification of the device/partition where the rootfs is? Googling the error message leads to http://lists.openmoko.org/pipermail/community/2011-April/064811.html, which (in my interpretation): - suggests that ubifs may not yet be completely reliable - points to another thread that might have clues for you. Of course, in order to have a working phone, I guess you could install on SD instead. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
"dmatthews.org" writes: > Hi Neil >> >> - It should be pretty quick and easy to write scripts to do this. A GUI >> would be nice, but that can come later. >> >> Thoughts? Does anyone already have such scripts? >> > > backup2l? > > The best documentation is here:- > > http://symbiosis.bytemark.co.uk/squeeze/docs/symbiosis.html#ch-backup-reference > > nb symbiosis is a debian based "easy hosting" system that includes backup2l; > since backup2l is basically a shell script it doesn't care what sort of linux > it's running on. There are debian paclages. backup2l looks pretty nice; thanks for the suggestion. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko backup/restore
I wonder if anyone is already thinking about or working on backup and restore for QtMoko when upgrading - i.e. to maintain all your settings and data across an upgrade? My thoughts so far on this: - Most non-system data lives in a separate partition, /media/card, and doesn't need handling because an upgrade won't touch that partition. - For the same reason, /media/card is a good place for backing up anything that does need handling. - Stuff that does need backup and restore is under /home/root: settings, email/SMS messages, spectemu ROMs, web browser stuff, and so on. Unfortunately this is a mixture of genuine user data and application-generated runtime state, and I think it would be better to let the new distribution regenerate the latter. So possibly that means that we can't just save and restore the whole of /home/root. But maybe the algorithm can be "save and restore the whole of /home/root except for a manageably small number of exceptions". - Maybe also backup and restore /etc/ssh/*key*, to avoid having to delete the old key on SSH clients? - It should be pretty quick and easy to write scripts to do this. A GUI would be nice, but that can come later. Thoughts? Does anyone already have such scripts? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QWSLock errors
Radek Polak writes:
> On Thursday, November 08, 2012 09:12:40 AM Neil Jerram wrote:
>
>> With current QtMoko git I'm seeing a lot of QWSLock errors in my log,
[...]
>
> To me it looked that the semaphore was closed by the other process or thread.
> The logging and some other stuff was added there in Qt 4.8.
I believe I've understood and fixed this - please see the attached
patch. I've been running with this change for a week and a bit now,
with no apparent bad consequences, so I guess it's OK to go into the
main repository.
Regards,
Neil
>From 52c34001bad85c3032618070b1d6b2a3c6880715 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Thu, 8 Nov 2012 08:18:32 +
Subject: [PATCH] Fix QWSLock "invalid argument" logs
There was no known actual problem associated with these logs, but they
were spamming the log, so I thought it worth trying to understand and
fix them.
The confusion is that there are two different ways of creating QWSLock
objects. "QWSLock()" creates an object that creates a new set of
semaphores, whereas "QWSLock(id)" creates an object that aliases the
existing set of semaphores with ID id. What seems to happen is that
each application creates a semaphore set scoped to that
application (QWSDisplay::Data::clientLock in qapplication_qws.cpp),
then this semaphore set is passed by complex means to
places (QWSClientPrivate and QWSMemorySurface) that use the semaphores
for a short period and then delete their QWSLock objects.
The problem was that the QWSLock destructor always destroyed the
semaphore set, even when that QWSLock hadn't create the semaphores
itself, hence making the semaphores invalid for other QWSLock objects
still referencing the same set.
Clearly a QWSLock object shouldn't destroy the semaphore set if it
didn't create it itself, and that is confirmed by the fact that one of
the implementations inside QWSLock already implements this logic, with
the 'owned' flag. The fix is to implement this for the #ifndef
QT_POSIX_IPC case - which is what is used in QtMoko - just as is
already implemented for the #ifdef QT_POSIX_IPC case.
---
src/gui/embedded/qwindowsystem_qws.cpp |3 +++
src/gui/embedded/qwslock.cpp| 17 +
src/gui/embedded/qwslock_p.h|2 +-
src/gui/kernel/qapplication_qws.cpp |2 ++
src/gui/painting/qwindowsurface_qws.cpp |2 ++
5 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/src/gui/embedded/qwindowsystem_qws.cpp b/src/gui/embedded/qwindowsystem_qws.cpp
index a1c613d..1ed8b6d 100644
--- a/src/gui/embedded/qwindowsystem_qws.cpp
+++ b/src/gui/embedded/qwindowsystem_qws.cpp
@@ -680,6 +680,7 @@ QWSClientPrivate::QWSClientPrivate()
QWSClientPrivate::~QWSClientPrivate()
{
#ifndef QT_NO_QWS_MULTIPROCESS
+//qDebug("QWSClientPrivate::~QWSClientPrivate()");
delete clientLock;
#endif
}
@@ -689,7 +690,9 @@ void QWSClientPrivate::setLockId(int id)
#ifdef QT_NO_QWS_MULTIPROCESS
Q_UNUSED(id);
#else
+//qDebug("QWSClientPrivate::setLockId(%d)", id);
clientLock = new QWSLock(id);
+//qDebug("=> %p", clientLock);
#endif
}
diff --git a/src/gui/embedded/qwslock.cpp b/src/gui/embedded/qwslock.cpp
index 9914a24..1055785 100644
--- a/src/gui/embedded/qwslock.cpp
+++ b/src/gui/embedded/qwslock.cpp
@@ -83,9 +83,13 @@ QWSLock::QWSLock(int id) : semId(id)
QWSSignalHandler::instance()->addWSLock(this);
#endif
+owned = false;
+
#ifndef QT_POSIX_IPC
if (semId == -1) {
semId = semget(IPC_PRIVATE, 3, IPC_CREAT | 0666);
+owned = true;
+ //qDebug("QWSLock::QWSLock(): %p, %d", this, (int)semId);
if (semId == -1) {
perror("QWSLock::QWSLock");
qFatal("Unable to create semaphore");
@@ -100,7 +104,6 @@ QWSLock::QWSLock(int id) : semId(id)
}
#else
sems[0] = sems[1] = sems[2] = SEM_FAILED;
-owned = false;
if (semId == -1) {
// ### generate really unique IDs
@@ -134,9 +137,12 @@ QWSLock::~QWSLock()
if (semId != -1) {
#ifndef QT_POSIX_IPC
-qt_semun semval;
-semval.val = 0;
-semctl(semId, 0, IPC_RMID, semval);
+ if (owned) {
+ qt_semun semval;
+ semval.val = 0;
+ semctl(semId, 0, IPC_RMID, semval);
+ }
+ //qDebug("QWSLock::~QWSLock(): %p, %d", this, (int)semId);
semId = -1;
#else
// emulate the SEM_UNDO behavior for the BackingStore lock
@@ -170,8 +176,10 @@ bool QWSLock::up(unsigned short semNum)
if (semNum == BackingStore)
sops.sem_flg |= SEM_UNDO;
+//qDebug("QWSLock::up(): %p, semop(%d, %d)", this, (int)semId, (int)semNum);
EINTR_LOOP(ret, semop(semId, &sops, 1));
#else
+//qDebug("QWSLock::up(): %p, sem_post(%d)", this, (int)(sems[semNum]));
ret = sem_post(sems[semNum]);
#endif
if (ret ==
Re: [QtMoko] Mokofaen red signal strength icon
francesco.dev...@mailoo.org writes: > Thanks for the suggestion. It's not a difficult work to do but I'm > really busy, so it is on the todo list for a next release. Thanks, it's much appreciated whenever you get time for this. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Where is the design and electric scheme of gta04?
Nadav Vinik writes: > Hello Hi! > Where is the design and electric scheme of gta04? > > > Also, Is there any guide how to open the case of new freerunner? > I open the two screws of the case and it still not open Both questions are answered by the system manual at http://projects.goldelico.com/p/gta04-main/downloads/. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QtMoko] Mokofaen red signal strength icon
I've been wondering for some time what it means when the GSM signal strength icon goes red, and whether/how that's different from the icon disappearing altogether, and whether/how either of those are related to modem crashes. After consulting the code, I see that: - disappeared completely => 0% signal strength - all red => 1-20% signal strength - 1 blue bar => 21-40% - 2 blue bars => 41-60% - 3 blue bars => 61-80% - 4 blue bars => 81-100% Now that I know that, I suggest that the all red icon is quite unintuitive, and that it would be more intuitive if changed to the same grey colour as used in the blue bar icons. Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Missing icons in current QtMoko git build
Radek Polak writes: > On Wednesday, November 07, 2012 10:47:51 PM Neil Jerram wrote: > >> If you're thinking of a release soon, I have a couple of safe (I >> believe) things that you might want to include in that. First, the >> support for Arora to provide the "WebAccess" service, which makes it >> work to click on URLs in emails and other places - this is a patch for >> the Arora submodule. Second, a tweak to the Mokofaen theme so that it >> has room for displaying >=10 satellites in the title bar. I've attached >> those below. > > Both are applied, thanks! There are 2 new files in the Arora patch that I think haven't yet been added to the Git repository... Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QWSLock errors
With current QtMoko git I'm seeing a lot of QWSLock errors in my log, e.g.: root@neo:~# tail -f /var/log/messages Nov 8 08:01:05 neo Qtopia: QWSLock::down(): Invalid argument Nov 8 08:01:05 neo Qtopia: QWSLock::down(): Invalid argument Nov 8 08:01:05 neo Qtopia: QWSLock::up(): Invalid argument Nov 8 08:01:05 neo Qtopia: QWSLock::down(): Invalid argument Nov 8 08:01:05 neo last message repeated 3 times Nov 8 08:01:05 neo Qtopia: QWSLock::up(): Invalid argument Nov 8 08:01:35 neo last message repeated 4 times Nov 8 08:01:35 neo Qtopia: QWSLock::down(): Invalid argument Nov 8 08:01:36 neo Qtopia: QWSLock::up(): Invalid argument Are you getting those too? If so, perhaps this is something to understand before making a new release. I'm investigating by adding more logging to QWSLock::up() - I hope to be able to say more this evening. (For some reason a simple 'make', or even '../qtmoko/configure -device gta04 && make', doesn't rebuild qwslock.c and the QtGui library. So I've kicked off a full rebuild.) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Missing icons in current QtMoko git build
Neil Jerram writes: > Radek Polak writes: > >> It seems that it's again QFileInfo problem. They have refactored it during >> 4.7->4.8 cycle and that broke our resource system. It's clearly a regression >> in their public API, but all my bugs (even with patch) are ignored in Qt bug >> tracker. >> >> I tried simple fix for QFileInfo::suffix() which works for resources, but >> does >> not work for regular files now. >> >> Attached is attempt to make it working for both cases, but it's untested. I >> guess i will have to go through qfileinfo.cpp commits and check if this fix >> is >> really correct. > > Thanks. I'm rebuilding with this now, and will report. That build has completed and installed fine, and now all the expected icons are there when QtMoko restarts. So the latest QFileInfo fix looks good. > I'm hoping that it might also fix my email - which I think broke at the > same time as I moved my codebase to Qt 4.8. My log has "the server > certificate is untrusted" errors, and I guess that might be to do with > incorrectly handling file names in /etc/ssl/certs. (I don't know any more about this yet.) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Missing icons in current QtMoko git build
EdorFaus writes: > On 11/07/2012 11:01 PM, Neil Jerram wrote: >> Neil Jerram writes: >> >>> If you're thinking of a release soon, I have a couple of safe (I >>> believe) things that you might want to include in that. First, the >>> support for Arora to provide the "WebAccess" service, which makes it >>> work to click on URLs in emails and other places - this is a patch for >>> the Arora submodule. Second, a tweak to the Mokofaen theme so that it >>> has room for displaying >=10 satellites in the title bar. I've attached >>> those below. >> >> Hmm, something odd happened there. Apparently the two attachments were >> stripped off, and then appeared in my sent items as two separate patch >> emails. Here's another attempt to attach them... > > That's something odd on your end then - on my end, it appeared as a > single email with two attached patches. This email also showed up that > way, perfectly fine. Ah, thanks. I saw that the attachments were missing at http://lists.openmoko.org/pipermail/community/2012-November/067744.html, and incorrectly concluded that they'd been removed before the email left my network. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Missing icons in current QtMoko git build
EdorFaus writes: > On 11/07/2012 11:01 PM, Neil Jerram wrote: >> Neil Jerram writes: >> >>> If you're thinking of a release soon, I have a couple of safe (I >>> believe) things that you might want to include in that. First, the >>> support for Arora to provide the "WebAccess" service, which makes it >>> work to click on URLs in emails and other places - this is a patch for >>> the Arora submodule. Second, a tweak to the Mokofaen theme so that it >>> has room for displaying >=10 satellites in the title bar. I've attached >>> those below. >> >> Hmm, something odd happened there. Apparently the two attachments were >> stripped off, and then appeared in my sent items as two separate patch >> emails. Here's another attempt to attach them... > > That's something odd on your end then - on my end, it appeared as a > single email with two attached patches. This email also showed up that > way, perfectly fine. Ah, thanks. I saw that the attachments were missing at http://lists.openmoko.org/pipermail/community/2012-November/067744.html, and incorrectly concluded that they'd been removed before the email left my network. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Missing icons in current QtMoko git build
Neil Jerram writes:
> If you're thinking of a release soon, I have a couple of safe (I
> believe) things that you might want to include in that. First, the
> support for Arora to provide the "WebAccess" service, which makes it
> work to click on URLs in emails and other places - this is a patch for
> the Arora submodule. Second, a tweak to the Mokofaen theme so that it
> has room for displaying >=10 satellites in the title bar. I've attached
> those below.
Hmm, something odd happened there. Apparently the two attachments were
stripped off, and then appeared in my sent items as two separate patch
emails. Here's another attempt to attach them...
>From a3784d5e4107cbc460139bc3ded8fe0cde76b9ec Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Sun, 16 Sep 2012 23:42:19 +0100
Subject: [PATCH] arora - Provide the Qtopia "WebAccess" service
This makes clicking on links in email work - both when Arora is
already running, and when there isn't already any web browser
running (in which case Arora is started automatically).
---
.gitignore |2 +-
src/browserapplication.cpp | 29 +
src/qbuild.pro |6 ++
src/services/WebAccess/arora |2 ++
src/webservice.h | 37 +
5 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 src/services/WebAccess/arora
create mode 100644 src/webservice.h
diff --git a/.gitignore b/.gitignore
index b101154..a8bea3c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,4 @@
-arora
+/arora
Arora.app
Makefile
.DS_Store
diff --git a/src/browserapplication.cpp b/src/browserapplication.cpp
index cc8bd1f..5585971 100644
--- a/src/browserapplication.cpp
+++ b/src/browserapplication.cpp
@@ -83,9 +83,23 @@
#include
#include
+#include
#include
+#include "webservice.h"
+
+void WebAccessService::openURL(QString url)
+{
+emit openUrl(url);
+}
+
+void WebAccessService::openSecureURL(QString url)
+{
+// XXX make sure this is a secure url
+emit openUrl(url);
+}
+
DownloadManager *BrowserApplication::s_downloadManager = 0;
HistoryManager *BrowserApplication::s_historyManager = 0;
NetworkAccessManager *BrowserApplication::s_networkAccessManager = 0;
@@ -152,6 +166,10 @@ BrowserApplication::BrowserApplication(int &argc, char **argv)
this, SLOT(lastWindowClosed()));
#endif
+QObject *service = new WebAccessService(this);
+connect(service, SIGNAL(openUrl(const QString &)),
+ this, SLOT(messageRecieved(const QString &)));
+
#ifndef AUTOTESTS
QTimer::singleShot(0, this, SLOT(postLaunch()));
#endif
@@ -455,6 +473,17 @@ BrowserMainWindow *BrowserApplication::newMainWindow()
m_mainWindows.prepend(browser);
setMainWidget(browser); //
showMainWidget();
+
+// Calling showMainWidget() a second time is the magic sauce that
+// is needed for Qtopia not to kill Arora after it has processed a
+// request for the WebAccess service. When servicing a
+// QtopiaServiceRequest requires _launching_ a new application -
+// i.e. because a suitable application isn't already running -
+// Qtopia's default behaviour is to close the launched application
+// again as soon as it appears to have processed that request.
+// For a web browser, we clearly don't want that.
+showMainWidget();
+
//browser->show();
return browser;
}
diff --git a/src/qbuild.pro b/src/qbuild.pro
index 4db82b6..7e39289 100644
--- a/src/qbuild.pro
+++ b/src/qbuild.pro
@@ -93,6 +93,7 @@ HEADERS += \
tabwidget.h \
toolbarsearch.h \
webactionmapper.h \
+webservice.h \
webview.h \
webviewsearch.h \
xbel.h
@@ -151,3 +152,8 @@ SOURCES += \
utils/rotate.cpp
#---
+
+# Install service registration
+service.files=services/WebAccess/arora
+service.path=/services/WebAccess
+INSTALLS+=service
diff --git a/src/services/WebAccess/arora b/src/services/WebAccess/arora
new file mode 100644
index 000..f99c0fd
--- /dev/null
+++ b/src/services/WebAccess/arora
@@ -0,0 +1,2 @@
+[Standard]
+Version=100
diff --git a/src/webservice.h b/src/webservice.h
new file mode 100644
index 000..d164a68
--- /dev/null
+++ b/src/webservice.h
@@ -0,0 +1,37 @@
+/
+**
+** This file was largely copied from examples/webviewer/webviewer.cpp
+** in the QtMoko distribution. But given that it has so few lines of
+** code, and that that code simply implements what standard Qtopia
+** documentation says for a Qtopia service, I don't think it has to
+** inherit that file's copyright and license. For the same reasons,
+** we don't declare any specific copyright and license for this file.
+**
+**
Re: Missing icons in current QtMoko git build
Radek Polak writes:
> It seems that it's again QFileInfo problem. They have refactored it during
> 4.7->4.8 cycle and that broke our resource system. It's clearly a regression
> in their public API, but all my bugs (even with patch) are ignored in Qt bug
> tracker.
>
> I tried simple fix for QFileInfo::suffix() which works for resources, but
> does
> not work for regular files now.
>
> Attached is attempt to make it working for both cases, but it's untested. I
> guess i will have to go through qfileinfo.cpp commits and check if this fix
> is
> really correct.
Thanks. I'm rebuilding with this now, and will report.
I'm hoping that it might also fix my email - which I think broke at the
same time as I moved my codebase to Qt 4.8. My log has "the server
certificate is untrusted" errors, and I guess that might be to do with
incorrectly handling file names in /etc/ssl/certs.
If you're thinking of a release soon, I have a couple of safe (I
believe) things that you might want to include in that. First, the
support for Arora to provide the "WebAccess" service, which makes it
work to click on URLs in emails and other places - this is a patch for
the Arora submodule. Second, a tweak to the Mokofaen theme so that it
has room for displaying >=10 satellites in the title bar. I've attached
those below.
Regards,
Neil
>From a3784d5e4107cbc460139bc3ded8fe0cde76b9ec Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Sun, 16 Sep 2012 23:42:19 +0100
Subject: [PATCH] arora - Provide the Qtopia "WebAccess" service
This makes clicking on links in email work - both when Arora is
already running, and when there isn't already any web browser
running (in which case Arora is started automatically).
---
.gitignore |2 +-
src/browserapplication.cpp | 29 +
src/qbuild.pro |6 ++
src/services/WebAccess/arora |2 ++
src/webservice.h | 37 +
5 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 src/services/WebAccess/arora
create mode 100644 src/webservice.h
diff --git a/.gitignore b/.gitignore
index b101154..a8bea3c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,4 @@
-arora
+/arora
Arora.app
Makefile
.DS_Store
diff --git a/src/browserapplication.cpp b/src/browserapplication.cpp
index cc8bd1f..5585971 100644
--- a/src/browserapplication.cpp
+++ b/src/browserapplication.cpp
@@ -83,9 +83,23 @@
#include
#include
+#include
#include
+#include "webservice.h"
+
+void WebAccessService::openURL(QString url)
+{
+emit openUrl(url);
+}
+
+void WebAccessService::openSecureURL(QString url)
+{
+// XXX make sure this is a secure url
+emit openUrl(url);
+}
+
DownloadManager *BrowserApplication::s_downloadManager = 0;
HistoryManager *BrowserApplication::s_historyManager = 0;
NetworkAccessManager *BrowserApplication::s_networkAccessManager = 0;
@@ -152,6 +166,10 @@ BrowserApplication::BrowserApplication(int &argc, char **argv)
this, SLOT(lastWindowClosed()));
#endif
+QObject *service = new WebAccessService(this);
+connect(service, SIGNAL(openUrl(const QString &)),
+ this, SLOT(messageRecieved(const QString &)));
+
#ifndef AUTOTESTS
QTimer::singleShot(0, this, SLOT(postLaunch()));
#endif
@@ -455,6 +473,17 @@ BrowserMainWindow *BrowserApplication::newMainWindow()
m_mainWindows.prepend(browser);
setMainWidget(browser); //
showMainWidget();
+
+// Calling showMainWidget() a second time is the magic sauce that
+// is needed for Qtopia not to kill Arora after it has processed a
+// request for the WebAccess service. When servicing a
+// QtopiaServiceRequest requires _launching_ a new application -
+// i.e. because a suitable application isn't already running -
+// Qtopia's default behaviour is to close the launched application
+// again as soon as it appears to have processed that request.
+// For a web browser, we clearly don't want that.
+showMainWidget();
+
//browser->show();
return browser;
}
diff --git a/src/qbuild.pro b/src/qbuild.pro
index 4db82b6..7e39289 100644
--- a/src/qbuild.pro
+++ b/src/qbuild.pro
@@ -93,6 +93,7 @@ HEADERS += \
tabwidget.h \
toolbarsearch.h \
webactionmapper.h \
+webservice.h \
webview.h \
webviewsearch.h \
xbel.h
@@ -151,3 +152,8 @@ SOURCES += \
utils/rotate.cpp
#---
+
+# Install service registration
+service.files=services/WebAccess/arora
+service.path=/services/WebAccess
+INSTALLS+=service
diff --git a/src/services/WebAccess/arora b/src/services/WebAccess/arora
new file mode 100644
index 000..f99c0fd
--- /dev/null
+++ b/src/services/WebAccess/arora
@@ -0,0 +1,2 @@
+[Standard
Re: Help needed with GSM Geolocation without GPS
robin writes:
> I guess one could split the whole thing in three parts so it would be
> adaptable
> to both qtmoko and shr. I can only program in python and may add a sqlite data
> base. having read a bit more about triangulation, the task will be much more
> difficult than I though, but one will see. the three parts of the program
> could
> be somewhat like:
>
> 1) get cell id and neighbour cell ids
>SHR) via FSO
> QtMoko) ?
You should be able to get the "/" string - i.e. the same as
displayed on the QtMoko home page - using code like this:
QValueSpaceItem *lac_cell_id = new
QValueSpaceItem("/Telephony/Status/CellLocation");
qLog() << "/ is " << lac_cell_id->value().toString();
Regards,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Missing icons in current QtMoko git build
Radek wrote at https://github.com/radekp/qtmoko/commit/871fe7f2bd712311ff88f2ef9042eb3112d65b1a: > + * Currently there is bug when generating qtopia_db.sqlite. As a result you > + will se no icons in the application menu. As a workaround copy that db from > + some older release: > + > +cp good_old_release/opt/qtmoko/qtopia_db.sqlite /opt/qtmoko/qtopia_db.sqlite Hooray, thanks, I have all my icons back again now. Can I help with fixing that bug? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help needed with GSM Geolocation without GPS
robin writes: >> Sounds good. I wonder what the trade-off is between implementing >> something like this from scratch for GTA04, and trying to integrate an >> existing partial solution such as GeoClue? > > hi neil, > > as far as I understand geoclue comprises a communication between a provider > and your phone, so that would mean data transfer via the modem. This would > certainly be one solution, but it would be nice if the user could choose > between: > > a) GSM -> Provider -> Location > b) GSM -> offline database -> Location (saves money and battery(?)) > > I don't know if geoclue can be easily extended to use the cells.txt.gz file > as an alternative input. That would be nice, because then one could actually > choose between a) and b). Last time I looked, my impression was that the geoclue architecture should support offline - but I'm not sure. > Could you point me in the right direction on how to extract the cell and > neighbouring cell ids/signal strengths in qtmoko. I believe the code that sources this information is src/libraries/qtopiaphone/qnetworkregistration.cpp: look for the lines in that file that say "emit locationChanged". Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help needed with GSM Geolocation without GPS
robin writes: > Hi, > > I wanted to give the GSM location a try. So what I would like to acchieve in > the end is: > > 0. GPS off > 1. GSM Cells are detected > 2. Triangulation takes place (I don't know yet if eg signal strength is used) > 3. Look-up in the OpenCellID offline (!) text database > 4. Position being shown in NeronGPS as in eg in the Whereabouts-Mappingdemo > shown on the QtMokoDev Page [1] Sounds good. I wonder what the trade-off is between implementing something like this from scratch for GTA04, and trying to integrate an existing partial solution such as GeoClue? > So I started with step 1 and I am a bit stuck. The numbers for the location > that the Mokofaen theme displays somehow do not match any of the cell towers > my phone is most likely to be connected to: > Most likely I am connected to > mcc 262; mnc 3; lac 40096 and cellid 137380532 [2] How do you get those numbers? They look like UMTS ones (which are bigger than GSM). > which has nowhere the numbers I get on my home screen: > 296/25326 Those numbers look like GSM. Are you actually connected by GSM or by UMTS? (Some background on the GSM/UMTS difference is here: http://lists.goldelico.com/pipermail/gta04-owner/2012-September/002923.html) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Error compiling on wheezy
Radek Polak writes: > i have now updated the build instructions. After many problems with wheezy as > host i have decided that the recommended way to install qtmoko is now chroot. > > It should avoid the problem with different packages/versions on the hosts - > and also the build HOWTO is a lot easier: > > https://github.com/radekp/qtmoko/blob/master/README > > I can now build the image in the chroot, but still there are some problems > when i run it on GTA04. I'll investigate what is wrong. > > You can try yourself and report if it worked. Starting from efdad160239fca2e192553ee85b2da47851d3a90, I needed the attached patch to get a successful build (exactly following the README instructions). >From 70619ca91f15f2dabfaaeaa9d941ee71674e5518 Mon Sep 17 00:00:00 2001 From: Neil Jerram Date: Sun, 4 Nov 2012 12:03:07 + Subject: [PATCH 1/9] Successful chroot building --- scripts/qtmoko-chroot.sh |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/scripts/qtmoko-chroot.sh b/scripts/qtmoko-chroot.sh index f4b812d..62d9c8f 100755 --- a/scripts/qtmoko-chroot.sh +++ b/scripts/qtmoko-chroot.sh @@ -34,7 +34,9 @@ then fi echo "Installing chroot packages" -cdebootstrap --flavour=minimal --include=build-essential,git,openssh-client,ccache,locales,procps,psmisc,libxext-dev,libasound2-dev,libdbus-1-dev,libssl-dev,libts-dev,libbluetooth-dev,libxtst-dev,libpng12-dev,libjpeg8-dev,libv4l-dev,libspeexdsp-dev,libglib2.0-dev,libsqlite3-dev,quilt squeeze ../qtmoko-chroot http://cdn.debian.net/debian/ +until cdebootstrap --flavour=minimal --include=build-essential,git,openssh-client,ccache,locales,procps,psmisc,libxext-dev,libasound2-dev,libdbus-1-dev,libssl-dev,libts-dev,libbluetooth-dev,libxtst-dev,libpng12-dev,libjpeg8-dev,libv4l-dev,libspeexdsp-dev,libglib2.0-dev,libsqlite3-dev,quilt,libgstreamer0.10-dev,libgstreamer-plugins-base0.10-dev squeeze ../qtmoko-chroot http://cdn.debian.net/debian/; do + : +done fi if [ ! -d ../qtmoko-chroot/proc/bus ] -- 1.7.10.4 After that I found that qpe.sh didn't start up at all on the phone, with messages indicating not being able to find libgstapp-0.10.so.0. Doing 'apt-get install gstreamer0.10-plugins-base' appears to have fixed that. Next, I found that the theme had reverted to Finxi, but for some reason even Finxi isn't fully installed: if I click the icon for the main menu, only the Games, Apps and Docs icons are there; the other grid positions are either empty or generic grey file icons with a ?. Then I did s/finxi/mokofaen/g in /opt/qtmoko/etc/default/Trolltech/qpe.conf, and restarted the phone. This successfully switched the theme to Mokofaen, but I still have missing icons as described above. Also I don't think it's just an icon problem, because if I click on the place where the Message icon normally is, I get an error popup saying "No application is defined for this document". Any thoughts/ideas? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
"dmatthews.org" writes: > I gave this another go after reading Robin's report of success and > (embarassed face) I managed to send an email using the fastmail smtp service That's good news. > No idea what was different; all I can think is I hit on some > permutation I didn't try before - I am using different encryption type > and authentication methods. > > Apologies to Neil if I diverted much energy away from something more > productive, I'm trying to find a palatable hat (to eat) Hey, not at all! I think I learned some useful stuff, about both encryption and QtMoko, while looking into things. Also, amusingly, my own email has now _stopped_ working for no apparent reason. Apparently there's a fundamental physical law of conservation of non-working email :-). (I'm hoping it'll come back to life again as soon as I can have a successful QtMoko build again...) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
Boudewijn writes: > On Wednesday 24 October 2012 14:21:23 David Matthews wrote: >> >It would be good to have some more data points. Can anyone else report >> >success/failure with QtMoko v48 email, on >> > >> >- Freerunner >> >- GTA04 on 2G-only (the default) >> >- GTA04 on 3G (requires patching to change "AT_OPSYS=0,2" >> >> Yes :-) I'd particularly like to hear if other neo users have found the >> same as me. > I was also wondering, but hadn't found the mail application till now. Thanks > to you two persevering, I got mail on my phone now. Thanks :-) > > Setting up the account was straightforward thanks to all fields having labels > that say clear enough what they mean. I first started the initial "get folder > structure" before realizing I had no connection whatsoever. I canceled that, > connected some-G network and started initial download. It seems to work > immediately: after a couple of seconds the directory structure was copied, > and > the first headers came in. After a couple of minutes it is at some 800 > message > headers. > > I actually have no idea which generation of network I'm using at the moment. > The network-cell-status got a GSM- and a UMTS-cell code. Energy usage is at > switching between 25mA and 96-to-104mA. It sounds like the GSM/UMTS difference is a red herring anyway, but if you're on 2G (GSM) you'll have a "G" at the left hand side of your title bar, whereas with 3G (UMTS) you'll have a "3". > Is the location of the config file mentioned in the thread? I searched the > file system, found some configs that got "mail" in it, but nothing that > resembles an account configuration. Or are those settings in some database > file? It's at /home/root/Settings/Trolltech/qtopiamail.conf > I tested with an xs4all.nl-account, imap on port 993, with SSL. I'll give > Yahoo a try later, so we can exchange settings for a service that's available > to all of us (Yahoo Asia includes IMAP, as opposed to "default" Yahoo, in > case > you're about to try). > > Time allowing I'll install QtMoko 48 on my Freerunner to give that a run as > well. Thanks! Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
David Matthews writes: >> >>I didn't investigate the details very closely, but perhaps this is a >>clue - i.e. that the email problem you see with v48 on Freerunner is >>to do with the low 2G data rate. >> > > Neil, nope. all the testing I did was using my home adsl either by wifi or > routing through the desktop machine over usb Ah, OK, thanks for eliminating that possibility. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
David Matthews writes:
> You say that you can't duplicate the issue - by that do you mean you *can*
> send
> email from a freerunner on qtmoko v48? - I had the impression you were more
> involved on the GTA04 and may not have a freerunner any longer.
FYI I was running my GTA04 on 2G-only yesterday and found that email
didn't work properly for me - whereas normally I'm on 3G, and email
works fine.
I didn't investigate the details very closely, but perhaps this is a
clue - i.e. that the email problem you see with v48 on Freerunner is
to do with the low 2G data rate.
It would be good to have some more data points. Can anyone else report
success/failure with QtMoko v48 email, on
- Freerunner
- GTA04 on 2G-only (the default)
- GTA04 on 3G (requires patching to change "AT_OPSYS=0,2"
to "AT_OPSYS=3,2")
?
Regards,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf
Gilles Filippini writes: >>From what I understand, the emdebian repository had its toolchains > upgraded on the 23/10/2012 [1]. It may be broken at the moment: it's now > impossible to create a pdebuild chroot with my scripts :( > > [1] <http://emdebian.org/debian/pool/main/g/> > > I'll have a deeper look this evening. > > Thanks, Thanks; I'm happy to have discovered a real problem and not just PEBKAC. :-) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf
Neil Jerram writes: > Gilles Filippini writes: > >> The orig.tar.gz tarball has to be created before-hand, using the >> 'get-orig-source' target of debian/rules: >> $ ./debian/rules get-orig-source > > Thanks, my build seems to be chugging along nicely now. I spoke a bit too soon... neil@neil-laptop:~/qtv46/qtmoko$ CROSSARCH=armhf CROSSVERS=4.7 DIST=wheezy QTMOKO_DEVICES=gta04 pdebuild-cross ... dpkg: warning: downgrading libgomp1-armhf-cross from 4.7.2-4 to 4.7.1-7 Preparing to replace libgomp1-armhf-cross 4.7.2-4 (using .../libgomp1-armhf-cross_4.7.1-7_all.deb) ... ... dpkg: warning: downgrading libstdc++6-armhf-cross from 4.7.2-4 to 4.7.1-7 Preparing to replace libstdc++6-armhf-cross 4.7.2-4 (using .../libstdc++6-armhf-cross_4.7.1-7_all.deb) ... ... dpkg: warning: downgrading linux-libc-dev-armhf-cross from 3.2.30-1 to 3.2.23-1 Preparing to replace linux-libc-dev-armhf-cross 3.2.30-1 (using .../linux-libc-dev-armhf-cross_3.2.23-1_all.deb) ... ... Setting up libqt4-declarative-armhf-cross (4:4.8.2+dfsg-2) ... Setting up libqt4-designer-armhf-cross (4:4.8.2+dfsg-2) ... Setting up libqt4-help-armhf-cross (4:4.8.2+dfsg-2) ... Setting up libqt4-qt3support-armhf-cross (4:4.8.2+dfsg-2) ... Setting up libqt4-scripttools-armhf-cross (4:4.8.2+dfsg-2) ... Setting up libqt4-svg-armhf-cross (4:4.8.2+dfsg-2) ... Setting up libqt4-dev-bin-armhf-cross (4:4.8.2+dfsg-2) ... Setting up libqt4-dev-armhf-cross (4:4.8.2+dfsg-2) ... Reading package lists... Building dependency tree... Reading state information... Correcting dependencies... Done The following extra packages will be installed: libgcc1-armhf-cross libgomp1-armhf-cross libstdc++6-armhf-cross The following packages will be upgraded: libgcc1-armhf-cross libgomp1-armhf-cross libstdc++6-armhf-cross 3 upgraded, 0 newly installed, 0 to remove and 3 not upgraded. Need to get 332 kB of archives. After this operation, 886 kB of additional disk space will be used. Do you want to continue [Y/n]? Abort. E: pbuilder-satisfydepends failed. I: Copying back the cached apt archive contents I: unmounting dev/pts filesystem I: unmounting proc filesystem I: cleaning the build env I: removing directory /var/lib/pdebuild-cross/build//15252 and its subdirectories neil@neil-laptop:~/qtv46/qtmoko$ Do you know the reason for that 'Abort'? As the transcript shows, the problematic packages appear to be those that were previously flagged as being downgraded. I tried a second time (i.e. 'CROSSARCH=armhf CROSSVERS=4.7 DIST=wheezy QTMOKO_DEVICES=gta04 pdebuild-cross' again) in case it was something random, but I got exactly the same output again. Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf
Gilles Filippini writes: > The orig.tar.gz tarball has to be created before-hand, using the > 'get-orig-source' target of debian/rules: > $ ./debian/rules get-orig-source Thanks, my build seems to be chugging along nicely now. It looks like building this way will use the 4.8.2 versions of libqt* packages already in wheezy/armhf. Is that right? (That should save lots of build time, as the building of QtWebkit always seems to take ages, so I hope it's right!) Also, assuming this method of building is successful, can I safely remote the xapt and *-cross packages that I have in my normal (i.e. non-chroot) wheezy rootfs? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf
Neil Jerram writes:
> Gilles Filippini writes:
>
>> Hi,
>>
>> Neil Jerram a écrit , Le 05/10/2012 19:36:
>>> Could you also outline how to build QtMoko for armhf? Presumably another
>>> toolchain is needed.
>>
>> Not sure about which method Radek uses, but there are some directions in
>> debian/README.source to build with pdebuild-cross.
>
> Thanks, I'll try that.
I've followed the instructions in debian/README.source. There were a
couple of things I had to infer - possibly wrongly - and the last step
in the recommended workflow doesn't get very far at all for me - so I'd
appreciate if you could review the following.
First, I guessed that all the example workflow steps should be run in
the root of the QtMoko tree. Is that right?
Second, I found that the pdebuild-cross-create step created an armel
chroot. I then copied debian/pdebuild-cross/pdebuild-cross.rc to
/etc/pdebuild-cross/ and debian/pdebuild-cross/multistrap-* to
/etc/multistrap/ and reran the pdebuild-cross-create step, and it looked
better:
...
Multistrap system installed successfully in /var/lib/pdebuild-cross/build/.
Compressing multistrap system in '/var/lib/pdebuild-cross/build/' to a
tarball called: 'pdebuild-cross-armhf-wheezy-4.7.tar.gz'.
Removing build directory: '/var/lib/pdebuild-cross/build/'
Multistrap system packaged successfully as
'/var/lib/pdebuild-cross/pdebuild-cross-armhf-wheezy-4.7.tar.gz'.
Was installing those configs the right thing to do?
Next the fix-pdebuild-cross step, which looked fine apart from these
warnings:
...
W: /root/.pbuilderrc does not exist
...
dpkg-architecture: warning: specified GNU system type arm-linux-gnueabihf
does not match gcc system type i486-linux-gnu, try setting a correct CC
environment variable
...
Do those indicate that I missed something?
Next the QtMoko build step as per README.source:
neil@neil-laptop:~/qtv46/qtmoko$ CROSSARCH=armhf CROSSVERS=4.7 DIST=sid
QTMOKO_DEVICES=gta04 pdebuild-cross
Need to create a new pbuilder crossbuilding chroot first.
Use pdebuild-cross-create to create one.
I guessed that the 'sid' here might be a typo, and so tried 'wheezy'
instead, but it still didn't get very far:
neil@neil-laptop:~/qtv46/qtmoko$ CROSSARCH=armhf CROSSVERS=4.7 DIST=wheezy
QTMOKO_DEVICES=gta04 pdebuild-cross
W: /home/neil/.pbuilderrc does not exist
dpkg-checkbuilddeps: Unmet build dependencies: libts-dev libspeexdsp-dev quilt
W: Unmet build-dependency in source
dpkg-buildpackage: source package qtmoko
dpkg-buildpackage: source version 48-1
dpkg-buildpackage: source changed by Radek Polak
dpkg-architecture: warning: specified GNU system type arm-linux-gnueabihf
does not match gcc system type i486-linux-gnu, try setting a correct CC
environment variable
dpkg-source --before-build qtmoko
fakeroot debian/rules clean
cp debian/control-src debian/control
for device in gta04; do \
cat debian/control-$device >> debian/control; \
done
dh clean
dh_testdir
debian/rules override_dh_auto_clean
make[1]: Entering directory `/home/neil/qtv46/qtmoko'
# If needed, revert QT_VERSION specific patches
if [ "$(basename "$(readlink -f debian/patches/series)")" != "series-main" ];
then \
if quilt app; then \
quilt pop -a; \
fi; \
ln -fs series-main debian/patches/series; \
fi
for device in gta04; do \
[ ! -f
devices/$device/mkspecs/qws/linux-native-g++/qmake.conf.orig ] || mv
devices/$device/mkspecs/qws/linux-native-g++/qmake.conf.orig
devices/$device/mkspecs/qws/linux-native-g++/qmake.conf; \
rm -fr ../build-$device; \
done
rm -f sdk/LICENSE.QtopiaGPL
make[1]: Leaving directory `/home/neil/qtv46/qtmoko'
dh_clean
dpkg-source -b qtmoko
dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream
tarball found at ../qtmoko_48.orig.tar.{bz2,gz,lzma,xz}
dpkg-buildpackage: error: dpkg-source -b qtmoko gave error exit status 255
Do you know what is going wrong here? I can provide the complete
transcript if it's needed.
Many thanks,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
"dmatthews.org" writes: > The nub is that from v2x up to v35 - that's all it ever required - > minimal fiddling at the most. I'm pretty sure this is not a PEBKAC - > there's some change somtime since v35 that has introduced a problem > :-) Fair enough. What would you like to try next? Since I can't reproduce any of these problems myself, I guess we can only proceed by trying things step by step on your FR; but that might be time-consuming. What do you think? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
> "dmatthews.org" writes: >> Sep 24 20:26:18 neo Qtopia: SMTP : Auth: sent: AUTH LOGIN >> Sep 24 20:26:18 neo Qtopia: SMTP : response: "334 VXNlcm5hbWU6" >> Sep 24 20:26:18 neo Qtopia: SMTP : AuthUser: sent: >> "ZG1hdHRoZXdzQGluYm94Lmx2" I notice (by decoding this) that you've configured your ID as "dmatth...@inbox.lv". But http://help.inbox.lv/help/question/100/37 says: Inbox users must set an authorization to outgoing mail server. - In the next window “Account name” You must write in your username, for example, if your e-mail address is supp...@inbox.lv then Your “Account name” will be “support”. Could that be the problem? I.e. your ID should be just "dmatthews"? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
il.inbox.lv might also say "authentication failure" for other reasons, e.g. - it's configured not to accept any authentication on an insecure channel, i.e. without TLS being set up first - could there be specific client IP addresses associated with your account, and the problem is that your phone doesn't have one of those addresses? > With no encryption on port 25:- Actually there was no encryption in the previous example either. The only difference in the following is "PLAIN" authentication instead of "LOGIN". > Sep 24 20:28:50 neo Qtopia: SMTP : Init: sent: EHLO qtopia-messageserver > Sep 24 20:28:50 neo Qtopia: SMTP : response: "250-mail.inbox.lv^M > Sep 24 20:28:50 neo Qtopia: 250-PIPELINING^M > Sep 24 20:28:50 neo Qtopia: 250-SIZE 5990^M > Sep 24 20:28:50 neo Qtopia: 250-VRFY^M > Sep 24 20:28:50 neo Qtopia: 250-ETRN^M > Sep 24 20:28:50 neo Qtopia: 250-STARTTLS^M > Sep 24 20:28:50 neo Qtopia: 250-AUTH LOGIN PLAIN^M > Sep 24 20:28:50 neo Qtopia: 250-ENHANCEDSTATUSCODES^M > Sep 24 20:28:50 neo Qtopia: 250-8BITMIME^M > Sep 24 20:28:50 neo Qtopia: 250 DSN" > Sep 24 20:28:50 neo Qtopia: SMTP : Auth: sent: AUTH PLAIN username/password hidden> > Sep 24 20:28:54 neo Qtopia: SMTP : response: "535 5.7.8 Error: > authentication failed: authentication failure" > Sep 24 20:28:54 neo Qtopia: SMTP : Closed connection Same interpretation as for the previous case. > Similar result if I try login authentication except the difference > does get logged. I'm *definitely* configuring the gui with the correct > username and password and that shows up correctly to the > qtopiamail.conf. Why do the logs report STARTTLS when I've not > configured that? "250-STARTTLS" is the server saying that it _supports_ TLS. It doesn't mean that it is actually being used. If you're really sure about your ID and password, - can you send email via mail.inbox.lv from other clients? - perhaps you need to contact their support to ask why your auth is being rejected. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf
Neil Jerram writes:
> Radek Polak writes:
>
>> Some things are working, some not
>
> Here's a log for one of the not working things, GPRS:
[...]
> I guess that's because "ifconfig" isn't installed, and we need whatever
> is the modern equivalent of that. ("ip ..." ?)
That's fixed by "apt-get install net-tools". (i.e. GPRS then works.)
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf
Gilles Filippini writes: > Hi, > > Neil Jerram a écrit , Le 05/10/2012 19:36: >> Could you also outline how to build QtMoko for armhf? Presumably another >> toolchain is needed. > > Not sure about which method Radek uses, but there are some directions in > debian/README.source to build with pdebuild-cross. Thanks, I'll try that. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf
Radek Polak writes:
> Some things are working, some not
Here's a log for one of the not working things, GPRS:
Oct 5 20:51:29 neo Qtopia: Network : QN: Found
("/home/root/Applications/Network/config/hso0.conf")
Oct 5 20:51:29 neo Qtopia: Network : QN::loadPLugin() : plugin found, loaded
and new interface instanciated
Oct 5 20:51:29 neo Qtopia: Network : new Option3gPlugin interface instance
requested -> "/home/root/Applications/Network/config/hso0.conf"
Oct 5 20:51:29 neo Qtopia: Network : Creating HsoInterface instance
Oct 5 20:51:39 neo Qtopia: AtChat : N : "_OSIGQ: 30,0"
Oct 5 20:51:43 neo Qtopia: Network : Starting interface ->
"/home/root/Applications/Network/config/hso0.conf"
Oct 5 20:51:43 neo Qtopia: Network : QN: Found
("/home/root/Applications/Network/config/hso0.conf")
Oct 5 20:51:43 neo Qtopia: Network : QNS::startInterface: starting
"/home/root/Applications/Network/config/hso0.conf"
Oct 5 20:51:43 neo Qtopia: AtChat : T :
"AT+CGDCONT=1,"IP","general.t-mobile.uk""
Oct 5 20:51:43 neo Qtopia: Network : Creating network session for "netsetup"
on "/home/root/Applications/Network/config/hso0.conf"
Oct 5 20:51:43 neo Qtopia: AtChat : F :
"AT+CGDCONT=1,"IP","general.t-mobile.uk""
Oct 5 20:51:43 neo Qtopia: AtChat : F : "OK"
Oct 5 20:51:43 neo Qtopia: AtChat : T : "AT_OWANCALL=1,1,1"
Oct 5 20:51:43 neo Qtopia: AtChat : F : "AT_OWANCALL=1,1,1"
Oct 5 20:51:43 neo Qtopia: AtChat : F : "OK"
Oct 5 20:51:43 neo Qtopia: AtChat : T : "AT_OWANDATA?"
Oct 5 20:51:43 neo Qtopia: AtChat : F : "AT_OWANDATA?"
Oct 5 20:51:43 neo Qtopia: AtChat : F : "OK"
Oct 5 20:51:44 neo Qtopia: Network : QN: Found
("/home/root/Applications/Network/config/hso0.conf")
Oct 5 20:51:44 neo Qtopia: Network : **
"/home/root/Applications/Network/config/hso0.conf" "Interface hasn't been
initialized yet." ""
Oct 5 20:51:44 neo Qtopia: Network : Setting extended life time for
"/home/root/Applications/Network/config/hso0.conf" to true
Oct 5 20:51:44 neo Qtopia: AtChat : T : "AT_OWANDATA?"
Oct 5 20:51:44 neo Qtopia: AtChat : N : "_OWANCALL: 1, 1"
Oct 5 20:51:44 neo Qtopia: AtChat : F : "AT_OWANDATA?"
Oct 5 20:51:44 neo Qtopia: Network : hso wan call ip= "31.114.15.145" , dns1=
"149.254.230.7" , dns2= "149.254.192.126"
Oct 5 20:51:44 neo Qtopia: hso: ifconfig failed with -2
Oct 5 20:51:44 neo Qtopia: AtChat : N : "_OWANDATA: 1, 31.114.15.145,
0.0.0.0, 149.254.230.7, 149.254.192.126, 0.0.0.0, 0.0.0.0,144000"
Oct 5 20:51:44 neo Qtopia: Network : Obsolete network session detected on
"/home/root/Applications/Network/config/hso0.conf"
Oct 5 20:51:44 neo Qtopia: Network : Obsolete session had extended life time
Oct 5 20:51:44 neo Qtopia: Network : QN: Found
("/home/root/Applications/Network/config/hso0.conf")
Oct 5 20:51:44 neo Qtopia: Network : **
"/home/root/Applications/Network/config/hso0.conf" "Interface hasn't been
initialized yet." ""
I guess that's because "ifconfig" isn't installed, and we need whatever
is the modern equivalent of that. ("ip ..." ?)
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf
On Friday, October 5, 2012 12:44:51, Radek Polak wrote: > Hi, > i am now playing with armhf/wheezy debian and i have first working QtMoko > image > based on it. You can download it here [1]. > > Some things are working, some not - so it's probably good just for > experimenting, but it's definitely the direction i'd like to go. Armhf will > help us utilize fpu unit which helps a lot when playing media. I can play now > even bigger movies now without encoding that were crawling on armel. Btw this > is now my config [2] > > Regards > > Radek > > [1] http://sourceforge.net/projects/qtmoko/files/Experimental/ > > # cat /home/root/.mplayer/config > > vo=fbdev2 > ao=alsa > [default] > afm=ffmpeg > vfm=ffmpeg > vf=scale=640:480,rotate=1 > sws=0 > framedrop=1 > ___ > Gta04-owner mailing list > gta04-ow...@goldelico.com > http://lists.goldelico.com/mailman/listinfo/gta04-owner > Amazing, thanks, I am looking forward to trying this out. Could you also outline how to build QtMoko for armhf? Presumably another toolchain is needed. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QTMoko website
Radek Polak writes: > On Tuesday, October 02, 2012 08:01:03 PM Neil Jerram wrote: > >> Attached is a patch to make QtMoko's GPS framework (Q*Whereabouts) use >> gpsd instead of reading directly from /dev/ttyO1. The benefit of that >> is that multiple clients, both Qt and non-Qt, can all use GPS at the >> same time. > > Nice, i was trying to do something like this too, but without any results. > > But I wonder how much is gpsd useful for us now. We have lightweight > Whereabouts framework which now works good on GTA02 and GTA04. On GTA02 it > even handles supplying AGPS data. > > I wonder what GPSD can do for us. Well, I've been using it because I'd like to export GPS from my GTA04 to another device, over Bluetooth, at the same time as running NeronGPS on the GTA04. I believe there are two problems with using NeoGpsPlugin+QNmeaWhereabouts for that, both of which are solved by using gpsd instead (with the patch that I posted). 1. If two applications each use NeoGpsPlugin+QNmeaWhereabouts to access GPS, there will be two instances of NeoGpsPlugin, and they will both try to open /dev/ttyO1, which (for me) hangs the whole system. Therefore, even if we modify every GPS application to use QWhereabouts, we still can't run more than one of those applications at the same time. 2. For Bluetooth export I need the NMEA stream, and QWhereabouts doesn't provide that. To get the NMEA stream I need either to read /dev/ttyO1 directly - which means I can't run any other GPS application at the same time - or to use gpsd and gpspipe. > It's another program running in background eating system resources. I haven't done any measurements, but it doesn't seem that bad. I believe it doesn't do anything at all - even access /dev/ttyO1 - until an application connects to its port, and I didn't notice any impact while actually using GPS. > The programs that will use GPSD will be poorly integrated in QtMoko - > i.e. not showing the fix status in title bar, no blinking with LED to > indicated NMEA activity, no AGPS. With my patch, you still get all that for applications like NeronGPS that use QWhereabouts - except I don't know about AGPS, because we don't yet have that on GTA04. I agree you wouldn't get it if, say, the Bluetooth GPS export function was running on its own. That wouldn't be a problem for me, though, because the device that I'm trying to export GPS to has it own good UI for showing fix status, satellites and so on. Also in practice I expect that I'll usually be running NeronGPS at the same time, and that will activate QWhereabouts and so give me all those UI indications on the GTA04. > And one more thing - i hate GPSD because they are breaking API compatibility > and we have no control of it. I want now to do some wheezy/armhf experimental > release for GTA04 and if wheezy/sqeeze gpsd are not compatible then it's > quite > problem... I agree that's annoying - for example because it prevents me from trying out the QGpsdWhereabouts code - but I don't understand how it might affect your wheezy/armhf experiment. As long as there's a version of gpspipe that matches the version of gpsd, I don't think we need anything else. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
"dmatthews.org" writes: > Here's some more smtp debugging - I'm now using the mail.inbox.lv server > which supports unencrypted and TLS access > > Trying port 587 with TLS:- > > Sep 24 20:01:37 neo Qtopia: 250-STARTTLS^M > Sep 24 20:01:37 neo Qtopia: 250-AUTH LOGIN PLAIN^M > Sep 24 20:01:37 neo Qtopia: 250-ENHANCEDSTATUSCODES^M > Sep 24 20:01:37 neo Qtopia: 250-8BITMIME^M > Sep 24 20:01:37 neo Qtopia: 250 DSN" > Sep 24 20:01:37 neo Qtopia: SMTP : StartTLS: sent: STARTTLS > Sep 24 20:01:37 neo Qtopia: SMTP : response: "220 2.0.0 Ready to start TLS" > Sep 24 20:01:38 neo Qtopia: Encrypted connect warnings: "'The root > certificate of the certificate chain is self-signed, and untrusted'" > Sep 24 20:01:38 neo Qtopia: SMTP : Closed connection > Sep 24 20:01:38 neo Qtopia: socketError: 13 : "The root certificate of the > certificate chain is self-signed, and untrusted" Hi David, I was just looking again at your reports about SMTP. I think there are several different factors for the different cases, and I haven't understood most of them yet. But I wonder if one relevant factor, for some of the "untrusted" cases, is that the QtMoko v48 rootfs doesn't include any CA certificates. I suddenly remembered that I also get lots of SSL error popups when using Arora. But after doing an "apt-get install ca-certificates", I don't see those anymore, so presumably they were caused by the lack of any CA certificates. Also an odd thing about about those popups is that they don't indicate the actual problem, i.e. that the root certificate is untrusted. Instead they typically just say No Error No Error No Error :-) That could just be an Arora-specific problem, but it could be a more general problem with how certificate-related errors are propagated up through Qt. Anyway, you may like to: - try "apt-get install ca-certificates", restart QtMoko, and see if any of your SMTP cases succeed after that - see if your working v35 rootfs has CA certificates in it (at /etc/ssl/certs). Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QtMoko] Hyperlink viewing and factory reset
Hi there,
Below is a QtMoko patch (for the Arora submodule) for hyperlink viewing
- i.e. so that touching on a hyperlink in, say, an email causes Arora to
pop up and show the corresponding web page.
I imagine a very similar patch could be applied to Yberbrowser, but I
still mostly use Arora, so haven't looked at that in detail. Also I
don't know what happens if there are two installed apps that both
provide the WebAccess service.
Slightly related is this story about tel: URLs in web pages with
telephone "numbers" that are actually dangerous USSD requests, and some
Android phones automatically executing those requests:
http://nakedsecurity.sophos.com/2012/09/26/are-android-phones-facing-a-remote-wipe-hacking-pandemic
On the GTA04, with QtMoko:
- USSD requests in general are implemented; e.g. typing *#06# into the
dialer will cause your IMEI to pop up. This happens immediately after
the second #, without any call button press.
- The Arora browser doesn't seem to understand tel: URLs at all, so the
patch below isn't exposing any new danger (unless/until Arora might be
enhanced to support tel: URLs).
- I don't know if the dialer would execute a USSD request without
confirmation if the request came from another application, instead of
being typed into the dialer.
- I don't know if the GTA04 has any dangerous USSD codes!
Does anyone know about the last two points?
Regards,
Neil
>From a3784d5e4107cbc460139bc3ded8fe0cde76b9ec Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Sun, 16 Sep 2012 23:42:19 +0100
Subject: [PATCH] arora - Provide the Qtopia "WebAccess" service
This makes clicking on links in email work - both when Arora is
already running, and when there isn't already any web browser
running (in which case Arora is started automatically).
---
.gitignore |2 +-
src/browserapplication.cpp | 29 +
src/qbuild.pro |6 ++
src/services/WebAccess/arora |2 ++
src/webservice.h | 37 +
5 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 src/services/WebAccess/arora
create mode 100644 src/webservice.h
diff --git a/.gitignore b/.gitignore
index b101154..a8bea3c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,4 @@
-arora
+/arora
Arora.app
Makefile
.DS_Store
diff --git a/src/browserapplication.cpp b/src/browserapplication.cpp
index cc8bd1f..5585971 100644
--- a/src/browserapplication.cpp
+++ b/src/browserapplication.cpp
@@ -83,9 +83,23 @@
#include
#include
+#include
#include
+#include "webservice.h"
+
+void WebAccessService::openURL(QString url)
+{
+emit openUrl(url);
+}
+
+void WebAccessService::openSecureURL(QString url)
+{
+// XXX make sure this is a secure url
+emit openUrl(url);
+}
+
DownloadManager *BrowserApplication::s_downloadManager = 0;
HistoryManager *BrowserApplication::s_historyManager = 0;
NetworkAccessManager *BrowserApplication::s_networkAccessManager = 0;
@@ -152,6 +166,10 @@ BrowserApplication::BrowserApplication(int &argc, char **argv)
this, SLOT(lastWindowClosed()));
#endif
+QObject *service = new WebAccessService(this);
+connect(service, SIGNAL(openUrl(const QString &)),
+ this, SLOT(messageRecieved(const QString &)));
+
#ifndef AUTOTESTS
QTimer::singleShot(0, this, SLOT(postLaunch()));
#endif
@@ -455,6 +473,17 @@ BrowserMainWindow *BrowserApplication::newMainWindow()
m_mainWindows.prepend(browser);
setMainWidget(browser); //
showMainWidget();
+
+// Calling showMainWidget() a second time is the magic sauce that
+// is needed for Qtopia not to kill Arora after it has processed a
+// request for the WebAccess service. When servicing a
+// QtopiaServiceRequest requires _launching_ a new application -
+// i.e. because a suitable application isn't already running -
+// Qtopia's default behaviour is to close the launched application
+// again as soon as it appears to have processed that request.
+// For a web browser, we clearly don't want that.
+showMainWidget();
+
//browser->show();
return browser;
}
diff --git a/src/qbuild.pro b/src/qbuild.pro
index 4db82b6..7e39289 100644
--- a/src/qbuild.pro
+++ b/src/qbuild.pro
@@ -93,6 +93,7 @@ HEADERS += \
tabwidget.h \
toolbarsearch.h \
webactionmapper.h \
+webservice.h \
webview.h \
webviewsearch.h \
xbel.h
@@ -151,3 +152,8 @@ SOURCES += \
utils/rotate.cpp
#---
+
+# Install service registration
+service.files=services/WebAccess/arora
+service.path=/services/WebAccess
+INSTALLS+=service
diff --git a/src/services/WebAccess/arora b/src/services/WebAccess/arora
new file mode 100644
index 000..f99c0fd
--- /dev/null
+++ b/src/services/WebAccess/arora
@@ -0,0 +1,2 @@
+[
Re: QTMoko website
Neil Jerram writes:
> On Tuesday, October 2, 2012 12:25:31, Radek Polak wrote:
>> Navit currently does not support QtMoko's GPS framework. You will have to
>> edit
>> navit configuration file and give it /dev/ttyO1 as serial NMEA port and you
>> will
>> also need to do "rfkill unblock gps" to power on GPS antenna. Or on
>> Freerunner
>> the port will be something like /dev/ttySAC1.
>>
>> It's one of things i have in plan to add QtMoko's GPS framework support to
>> navit. No idea when i have time to do it, but it's quite big priority for me.
Alternatively, one could install gpsd and gpsd-clients and run Navit
using gpsd (which I think is its default). You'd still have to do the
"rfkill unblock gps" somehow, because the gpsd in Debian Squeeze doesn't
have a hook for doing that. (The gpsd in Wheezy does.)
The only problem then is that QtMoko apps wouldn't be able to access the
GPS at the same time, but for that...
> I'm not sure if it's relevant for Navit but I've integrated gpsd usage
> in QtMoko. I'll write more about that this evening.
Attached is a patch to make QtMoko's GPS framework (Q*Whereabouts) use
gpsd instead of reading directly from /dev/ttyO1. The benefit of that
is that multiple clients, both Qt and non-Qt, can all use GPS at the
same time.
>From edb97c45be3e36b91fbd4bc8836d4cab56046ac3 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Sun, 30 Sep 2012 23:35:15 +0100
Subject: [PATCH] NeoGpsPlugin - use "gpspipe -r" instead of "cat /dev/ttyO1".
This allows us to have multiple GPS clients at the same time.
Specifically, to have NeronGPS running on the GTA04, and also using
gpspipe to export the GPS NMEA stream over Bluetooth.
(An alternative approach is to use QGpsdWhereabouts instead of
NeoGpsPlugin, but this doesn't work because the QGpsdWhereabouts code
assumes the old GPSD protocol which has now been replaced by JSON. To
use QGpsdWhereabouts successfully, that code would need updating for
the new protocol, probably by using libgps.
Using "gpspipe -r" at the bottom of NeoGpsPlugin should be equally
effective, and doesn't require such a complex code change.)
---
.../src/plugins/whereabouts/neo/neogpsplugin.cpp | 21
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp b/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp
index 7737c17..f6e55fc 100644
--- a/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp
+++ b/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp
@@ -31,7 +31,20 @@
#include
/*
- This plugin only works for Goldelico's GTA04
+ This plugin uses "gpspipe -r" to get NMEA sentences out of GPSD,
+ then feeds those to QNmeaWhereabouts. It should work on any
+ distribution where GPSD is running and successfully accessing the
+ GPS device.
+
+ The benefit of using GPSD, instead of reading the GPS device
+ directly, is that multiple clients can access GPS information at the
+ same time. For example, GPS can be simultaneously used by a local
+ application such as NeronGPS, and exported over Bluetooth to another
+ device.
+
+ An alternative GPSD-based solution would be to use QGpsdWhereabouts
+ instead of QNmeaWhereabouts, but that would require updating
+ QGpsdWhereabouts for GPSD's new JSON-based protocol.
*/
NeoGpsPlugin::NeoGpsPlugin(QObject * parent)
: QWhereaboutsPlugin(parent)
@@ -56,12 +69,12 @@ QWhereabouts *NeoGpsPlugin::create(const QString &)
qLog(Hardware) << __PRETTY_FUNCTION__;
reader = new QProcess(this);
-reader->start("cat", QStringList() << "/dev/ttyO1", QIODevice::ReadWrite);
+reader->start("gpspipe", QStringList() << "-r", QIODevice::ReadWrite);
if (!reader->waitForStarted()) {
-qWarning() << "couldnt start cat /dev/ttyO1: " + reader->errorString();
+qWarning() << "Couldn't start gpspipe -r: " + reader->errorString();
QMessageBox::warning(0, tr("GPS"),
- tr("Cannot open GPS device at /dev/ttyO1"),
+ tr("Couldn't start gpspipe -r"),
QMessageBox::Ok, QMessageBox::Ok);
delete reader;
reader = 0;
--
1.7.10.4
I don't think this patch is ready for inclusion yet, because it would be
better if it handled both gpsd usage and direct access gracefully -
i.e. try using gpspipe, and fall back to opening /dev/ttyO1 if that
fails. But it would be interesting to hear if people think this is the
right longterm approach.
Regards,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: QTMoko website
On Tuesday, October 2, 2012 12:25:31, Radek Polak wrote: > On Tuesday, October 02, 2012 10:08:02 AM matthsch...@arcor.de wrote: > > > Hi Radek, > > > > OK, i installed it with apt-get install qtmoko-navit. Now I'm about to > > assign maps, onscreen buttons and so on, I will figure it out. Whta I didd > > not find until now is how navit turns the GPS on. Neither I found how > > Nerongps turns it on - here it works, but I dont know how. > > Navit currently does not support QtMoko's GPS framework. You will have to > edit > navit configuration file and give it /dev/ttyO1 as serial NMEA port and you > will > also need to do "rfkill unblock gps" to power on GPS antenna. Or on > Freerunner > the port will be something like /dev/ttySAC1. > > It's one of things i have in plan to add QtMoko's GPS framework support to > navit. No idea when i have time to do it, but it's quite big priority for me. > > > BTW, > > http://qtmoko.sourceforge.net/apps/qtmoko-qtopiagps.html > > gives an error message about the package not present. > > Yup, the app needs someone to adapt it make it working. > > Regards > > Radek > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > I'm not sure if it's relevant for Navit but I've integrated gpsd usage in QtMoko. I'll write more about that this evening. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Transcoding movies for QMPlayer
Gilles Filippini writes: > Hi, > > Movies transcoded with mencoder often lose A/V sync. For one of my video > files there is a 5 secondes drift after only 1 minute of playing. >From when I used to do that for my Nokia 770, I remember that it used to work better when I told mencoder to create an index. I don't remember exactly but I guess that would have been the -forceidx option. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
