Re: [Tinkerphones] Fwd: [Gta04-owner] QtMoko: a dream comes true :)

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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:
> 
>   
> 
> 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]: 
> 
> 
> ___
> 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: Qx and QtMoko v58 in GTA04

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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..

[Neil Jerram]

Πρεκατές Αλέξανδρος  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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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?

[Neil Jerram]

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

[Neil Jerram]

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]

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

[Neil Jerram]

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]

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]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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, but I know from previous
experience that it sometimes fails completely.  alsaloop in comparison
has a drastically different and more complex

Re: looking for used (or broken) GTA02 (whole or PCB) to purchase

[Neil Jerram]

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?

[Neil Jerram]

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]

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?

[Neil Jerram]

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?

[Neil Jerram]

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?

[Neil Jerram]

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]

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?

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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 all of the above works, we can look at whether it all
_still_ works with the squeeze version of pulseaudio.

Hopefully eventually the software audio routing can be go

Re: How to access the modem in QtMoko

[Neil Jerram]

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?

[Neil Jerram]

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?

[Neil Jerram]

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?

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

"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

[Neil Jerram]

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

[Neil Jerram]

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?

[Neil Jerram]

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?

[Neil Jerram]

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

[Neil Jerram]

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: X11 initialization 
failed.
W: ratelimit.c: 15 events suppressed

OK, this is looking better now.  After a reboot, responsiveness is back
to normal and I can play media.

Thanks,
Neil

_

Re: [Gta04-owner] QtMoko v49

[Neil Jerram]

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

[Neil Jerram]

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]

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

[Neil Jerram]

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

[Neil Jerram]

"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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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?

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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]

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

[Neil Jerram]

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]

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]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

"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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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] 
>
> 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]

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

[Neil Jerram]

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]

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

[Neil Jerram]

"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

[Neil Jerram]

> "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

[Neil Jerram]

Prompted by David Matthews' reports, I've improved my understanding of
SMTP authentication mechanisms.  Little of this is specific to QtMoko or
even smartphones, but I think it's worth covering anyway in the context
of this thread.

When you want to send email via an SMTP server that isn't in your own
immediate network, the client needs to authenticate itself to the
server.  Otherwise that server would be an "open relay", which is a big
no-no.  So the client (e.g. on your GTA0x) has to send something
involving your ID and password to the server - and obviously that raises
the questions of (1) whether the server is really the right server, and
(2) whether something else can sniff the communication and work out your
ID and password.

The available SMTP auth mechanisms in QtMoko are "LOGIN" and "PLAIN",
and both of those are basically plaintext - i.e. anyone sniffing the
communication can see your ID and password.  Therefore you really need
to be using encryption - either SSL or TLS - as well, for sending email
from a QtMoko phone.  (There is a non-plaintext SMTP auth mechanism,
"CRAM-MD5", but it appears that QtMoko does't support that.)

TLS and SSL are largely the same.  In this context (SMTP), the
difference is that SSL encrypts the TCP connection before _any_ SMTP
protocol is exchanged (and requires a distinct port number from
unencrypted SMTP), whereas a "TLS" connection starts off unencrypted and
becomes encrypted once both the client and the server have agreed that
(and so can operate within the normal SMTP port 25).  Crucially, in the
TLS case, both the client and the server can ensure that they don't
exchange any authentication information until the connection has become
encrypted.

There's still question (1), whether the server you're connecting to is
really the server that you trust to know your ID/password and to see
your outgoing email.  SSL and TLS both address this by the server having
a certificate that uniquely identifies itself.  That certificate is
passed to the client, as part of the process of the connection becoming
encrypted, and the client must decide if it trusts that certificate.

In QtMoko (and I think in general) this is done by the client having a
pre-installed set of certificates that it trusts.  Then, when the client
sees the SMTP server's certificate, it must either exactly match one of
the pre-installed ones, or have been signed by one of the pre-installed
ones.  Some certificate-handling applications, like Firefox, also allow
the user to inspect an untrusted certificate and make it trusted, but
QtMoko doesn't do that.

Therefore...

- If you're using a public SMTP server, that server's certificate should
  be signed by a recognised "certificate authority" (CA), and that CA's
  certificate should be pre-installed in your QtMoko.  "apt-get install
  ca-certificates" does this.

- If you're using your own SMTP server, you can:

  (a) create your own self-signed CA certificate

  (b) create a certificate for your SMTP server, signed by your CA
  certificate

  (c) configure your SMTP server to support TLS, using the newly created
  certificate

  (d) install your own CA certificate in QtMoko by copying it to
  /usr/local/share/ca-certificates/.crt, running
  update-ca-certificates, and restarting QtMoko.

  In other words, you're telling your QtMoko to trust your own CA.
  There are good instructions for (a), (b) and (c) at
  http://www.postfix.org/TLS_README.html.

There are probably other variants on the "own SMTP server" procedure
described here, but this is what I've just successfully tested for my
own SMTP setup.

Now, with all that as background...

"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" 

I think this means that the mail.inbox.lv server provided a self-signed
certificate (or a chain of certificates rooted in a self-signed
certificate), and that QtMoko doesn't have that certificate installed.

If I run "swaks -s mail.inbox.lv -t nos...@gmail.com -tls -a LOGIN"
from a laptop, with Wireshark running at the same time, I see that
mail.inbox.lv provides a chain of 3 certificates, of which the root
certificate looks similar to /etc/ssl/certs/Ad

Re: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

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

[Neil Jerram]

"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

[Neil Jerram]

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]

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

[Neil Jerram]

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

[Neil Jerram]

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

Re: QtMoko v48 neofreerunner

[Neil Jerram]

"dmatthews.org"  writes:

> 3) Finally I attempt unencrypted access to the fastmail server - this is what 
> definitely works in v35 (I tried it just a few days ago):-
>
> Sep 23 13:47:09 neo Qtopia: SMTP :  newConnection 
> Sep 23 13:47:09 neo Qtopia: SMTP :  Open SMTP connection 
> Sep 23 13:47:09 neo Qtopia: socketError: 0 : "Connection refused" 
> Sep 23 13:47:09 neo Qtopia: SMTP :  Closed connection 

Regarding (3), I notice that
https://www.fastmail.fm/help/remote_email_access_server_names_and_ports.html
says that the right port number is 465, and here's what happens when I try
to connect to ports 25 and 465:

  neil@neil-laptop:~$ telnet mail.messagingengine.com 25
  Trying 66.111.4.52...
  Trying 66.111.4.51...
  telnet: Unable to connect to remote host: Connection refused
  neil@neil-laptop:~$ telnet mail.messagingengine.com 465
  Trying 66.111.4.51...
  Connected to mail.messagingengine.com.
  Escape character is '^]'.
  ^C^C
  Connection closed by foreign host.
  neil@neil-laptop:~$ 

So perhaps the "Connection refused" you get is caused by QtMoko
incorrectly using port 25?  Did you set port 465 in the account
configuration for sending?

Regards,
Neil

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: GTA02 Setting time from phone network using NITZ ?

[Neil Jerram]

Adam Ward  writes:

>> 
>> Time and time zone are two different things.  In my (patchy and
>> non-scientific) experience, mobile networks often do tell you the time
>> zone, but not the time.
>> 
>
> I know that Telstra in Australia sends both.  My current phone would get the 
> correct details after traveling between timezones when I was on that network.
> I will find out in a few weeks if Optus does the same.

FWIW, from a quick look at
devices/neo/src/plugins/phonevendors/neo/vendor_neo.cpp, I see that the
suspend code includes

// Turn off timezone notifications.
chat("AT+CTZR=0");
chat("AT%CTZU=0");

and the resume ("wake") code includes

 // Turn on timezone notifications again.
chat( "AT+CTZR=1" );
chat( "AT%CTZU=1" );

and that the code for a CTZU response appears to handle both date/time
and timezone:

void NeoModemService::ctzu( const QString& msg )
{
// Timezone information from the network.  Format is 
"yy/mm/dd,hh:mm:ss+/-tz".

So maybe I was wrong about time and timezone being separate.

Also note that

(1) there could still be missing bits of support higher up, for actually
doing anything useful with this information

(2) I wonder if it's also necessary to do the "Turn on" actions when the
phone first boots up?

Regards,
Neil

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community