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
h...@computer.org 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 spielr...@web.de 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 n...@ossau.homelinux.net
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 n...@ossau.homelinux.net
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 @@
 		layout rect=0,0,106x400 orientation=vertical align=vcenter
 			image name=dialer rect=0,0,96x96 src=phone.png scale=yes interactive=yes/
 			image name=mainmenu rect=0,0,96x96 src=go-home.png scale=yes interactive=yes/
-			image name=favorites rect=0,0,96x96 src=application-default-icon.png scale=yes interactive=yes/
+			image name=taskmanager rect=0,0,96x96 src=application-default-icon.png scale=yes interactive=yes/
 			image name=lock rect=0,0,96x96 src=system-lock-screen.png scale=yes interactive=yes/
 		/layout
 	/group
-- 
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 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: 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: GTA02 Screen broken..

[Neil Jerram]

Πρεκατές Αλέξανδρος apreka...@gmail.com 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 pson...@seznam.cz 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 pson...@seznam.cz 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 ra...@g-pb.de 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 n...@ossau.homelinux.net
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 quakem...@gmx.net 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] 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 n...@ossau.homelinux.net
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 trarg, 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 @@
 		/layout
 		rect rect=0,25pt,0x18pt
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages == 1
-trtrtext1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
+trtrtext1 new/trtext/tr
 			/text
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages  1
 trtrtext%1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
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 @@
 		/layout
 		rect rect=0,25pt,0x18pt
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages == 1
-trtrtext1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
+trtrtext1 new/trtext/tr
 			/text
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages  1
 trtrtext%1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
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 @@
 		/layout
 		rect rect=0,25pt,0x18pt
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages == 1
-trtrtext1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
+trtrtext1 new/trtext/tr
 			/text
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages  1
 trtrtext%1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
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 @@
 		/layout
 		rect rect=0,25pt,0x18pt
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages == 1
-trtrtext1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
+trtrtext1 new/trtext/tr
 			/text
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages  1
 trtrtext%1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
-- 
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

Re: QtMoko audio state work

[Neil Jerram]

Neil Jerram n...@ossau.homelinux.net 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 occured: Broken pipe
0 frames available

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 pson...@seznam.cz 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: [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 + Neil Jerram n...@ossau.homelinux.net
 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]

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

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

[Neil Jerram]

Dmitry Shalnoff shaln...@gmail.com 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 pson...@seznam.cz writes:

 On Thursday, December 06, 2012 08:25:36 PM Neil Jerram wrote:

 Neil Jerram n...@ossau.homelinux.net writes:
  Radek Polak pson...@seznam.cz 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]

Radek Polak pson...@seznam.cz 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]

Neil Jerram n...@ossau.homelinux.net writes:

 Radek Polak pson...@seznam.cz 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]

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: QtMoko: how is long Power key press (= shutdown/restart menu) handled?

[Neil Jerram]

Radek Polak pson...@seznam.cz 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: How to access the modem in QtMoko

[Neil Jerram]

robin spielr...@web.de 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: how is long Power key press (= shutdown/restart menu) handled?

[Neil Jerram]

robin spielr...@web.de 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]

Neil Jerram n...@ossau.homelinux.net writes:

 robin spielr...@web.de 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: How to access the modem in QtMoko

[Neil Jerram]

robin spielr...@web.de 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 whatever' 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

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: QtMoko: how is long Power key press (= shutdown/restart menu) handled?

[Neil Jerram]

Radek Polak pson...@seznam.cz 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

Re: QtMoko: how is long Power key press (= shutdown/restart menu) handled?

[Neil Jerram]

robin spielr...@web.de 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: How to access the modem in QtMoko

[Neil Jerram]

robin spielr...@web.de 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 audio state work

[Neil Jerram]

Radek Polak pson...@seznam.cz 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 

Qt 4.8 Draft Message problem

[Neil Jerram]

Radek Polak pson...@seznam.cz 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 pson...@seznam.cz 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 n...@ossau.homelinux.net writes:

 Radek Polak pson...@seznam.cz 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 n...@ossau.homelinux.net
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

Re: QtMoko media playback progress?

[Neil Jerram]

Radek Polak pson...@seznam.cz 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 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 n...@ossau.homelinux.net
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 pson...@seznam.cz
-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 n...@ossau.homelinux.net
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()
 {
 rm -f /tmp/restart-qtopia

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 n...@ossau.homelinux.net
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 trarg, 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 @@
 			/rect
 		/layout
 		text name=calls size=6 rect=0,25pt,0x9pt align=hcenter bold=yes color=#ff outline=#00 
-			trtrtext1 missed/trtexttrarg@/Communications/Calls/MissedCalls/trarg/tr
+			trtrtext1 missed/trtext/tr
 		/text
 	/rect
 	rect name=calls rect=0,28pt,0x0 transient=yes active=expr:@/Communications/Calls/MissedCalls  1 interactive=yes
@@ -60,7 +60,7 @@
 		/layout
 		rect rect=0,25pt,0x18pt
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages == 1
-trtrtext1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
+trtrtext1 new/trtext/tr
 			/text
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages  1
 trtrtext%1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
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 @@
 			/rect
 		/layout
 		text name=calls size=6 rect=0,25pt,0x9pt align=hcenter bold=yes color=#ff outline=#00 
-			trtrtext1 missed/trtexttrarg@/Communications/Calls/MissedCalls/trarg/tr
+			trtrtext1 missed/trtext/tr
 		/text
 	/rect
 	rect name=calls rect=0,28pt,0x0 transient=yes active=expr:@/Communications/Calls/MissedCalls  1 interactive=yes
@@ -95,7 +95,7 @@
 		/layout
 		rect rect=0,25pt,0x18pt
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages == 1
-trtrtext1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
+trtrtext1 new/trtext/tr
 			/text
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages  1
 trtrtext%1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
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 @@
 			/rect
 		/layout
 		text name=calls size=6 rect=0,25pt,0x9pt align=hcenter bold=yes color=#ff outline=#00 
-			trtrtext1 missed/trtexttrarg@/Communications/Calls/MissedCalls/trarg/tr
+			trtrtext1 missed/trtext/tr
 		/text
 	/rect
 	rect name=calls rect=0,28pt,0x0 transient=yes active=expr:@/Communications/Calls/MissedCalls  1 interactive=yes
@@ -85,7 +85,7 @@
 		/layout
 		rect rect=0,25pt,0x18pt
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages == 1
-trtrtext1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
+trtrtext1 new/trtext/tr
 			/text
 			text rect=0,0,0x9pt align=hcenter bold=yes color=#ff outline=#00 transient=yes active=expr:@/Communications/Messages/NewMessages  1
 trtrtext%1 new/trtexttrarg@/Communications/Messages/NewMessages/trarg/tr
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 @@
 			/rect
 		/layout
 		text name=calls size=6 rect=0,25pt,0x9pt align=hcenter bold=yes color=#ff outline=#00 
-			trtrtext1 missed/trtexttrarg

Re: QtMoko backup/restore

[Neil Jerram]

dmatthews.org m...@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 n...@ossau.homelinux.net
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 @@
+?xml version=1.0 encoding=iso-8859-1?
+!-- Generator: Adobe Illustrator 12.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 51448)  --
+!DOCTYPE svg PUBLIC -//W3C//DTD SVG 1.1//EN http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd; [
+	!ENTITY ns_svg http://www.w3.org/2000/svg;
+	!ENTITY ns_xlink http://www.w3.org/1999/xlink;
+]
+svg  version=1.1 id=#x56FE;#x5C42;_1 xmlns=ns_svg; xmlns:xlink=ns_xlink; width=33.738 height=33.912
+	 viewBox=0 0 33.738 33.912 style=overflow:visible;enable-background:new 0 0 33.738 33.912; xml:space=preserve
+g
+	
+		linearGradient id=XMLID_11_ gradientUnits=userSpaceOnUse x1=26.4502 y1=21.7085 x2=26.4502 y2=9.3337 gradientTransform=matrix(0.927 0.375 -0.375 0.9271 6.0237 -9.6258)
+		stop  offset=0 style=stop-color:#FF/
+		stop  offset=0.0173 style=stop-color:#FBFBFB/
+		stop  offset=0.2212 style=stop-color:#D5D5D5/
+		stop  offset=0.423 style=stop-color:#B6B6B6/
+		stop  offset=0.6197 style=stop-color:#A0A0A0/
+		stop  offset=0.8092 style=stop-color:#939393/
+		stop  offset=0.9831 style=stop-color:#8F8F8F/
+	/linearGradient
+	path style=fill:url(#XMLID_11_);stroke:#221815;stroke-width:0.25; d=M33.23,7.067c0.646-1.596,0.444-3.31-0.375-4.651
+		l-1.557,3.848c-0.214,0.529-0.745,0.82-1.178,0.645l-3.792-1.533c-0.434-0.176-0.613-0.755-0.399-1.283l1.583-3.914
+		c-1.566,0.369-2.948,1.484-3.609,3.116c-0.662,1.638-0.441,3.403,0.435,4.761l-6.117,15.121l5.301,2.146l6.127-15.147

Re: QtMoko pulseaudio patches

[Neil Jerram]

Gilles Filippini p...@debian.org 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 pson...@seznam.cz
 -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 n...@ossau.homelinux.net
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

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 n...@ossau.homelinux.net
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

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: QtMoko backup/restore

[Neil Jerram]

Neil Jerram n...@ossau.homelinux.net 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: [Gta04-owner] QtMoko v49

[Neil Jerram]

Radek Polak pson...@seznam.cz 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: [Community] [Gta04-owner] QtMoko v49

[Neil Jerram]

Radek Polak pson...@seznam.cz 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

___
Openmoko 

Re: QWSLock errors

[Neil Jerram]

Radek Polak pson...@seznam.cz 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 n...@ossau.homelinux.net
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 == -1) {
@@ -195,6 +203,7 @@ bool QWSLock::down(unsigned short semNum, int)
 if (semNum == BackingStore)
 sops.sem_flg |= SEM_UNDO;
 
+//qDebug(QWSLock::down(): %p, semop(%d, %d

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: QtMoko backup/restore

[Neil Jerram]

dmatthews.org m...@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

Re: Kernel panic on Freerunner QtMoko boot

[Neil Jerram]

I'm afraid I can't help much, but...

Harry Prevor habsti...@gmail.com 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

[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: Where is the design and electric scheme of gta04?

[Neil Jerram]

Nadav Vinik nadav...@gmail.com 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

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]

Radek Polak pson...@seznam.cz 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 n...@ossau.homelinux.net
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 qwebsettings.h
 
 #include QtopiaApplication
+#include QtopiaAbstractService
 
 #include qdebug.h
 
+#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

Re: Missing icons in current QtMoko git build

[Neil Jerram]

Neil Jerram n...@ossau.homelinux.net 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 n...@ossau.homelinux.net
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 qwebsettings.h
 
 #include QtopiaApplication
+#include QtopiaAbstractService
 
 #include qdebug.h
 
+#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.
+**
+/
+
+#ifndef

Re: Missing icons in current QtMoko git build

[Neil Jerram]

EdorFaus edorf...@xepher.net writes:

 On 11/07/2012 11:01 PM, Neil Jerram wrote:
 Neil Jerram n...@ossau.homelinux.net 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 n...@ossau.homelinux.net writes:

 Radek Polak pson...@seznam.cz 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: Help needed with GSM Geolocation without GPS

[Neil Jerram]

robin spielr...@web.de 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

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 spielr...@web.de 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 LAC/CELLID 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()  LAC/CELLID is   lac_cell_id-value().toString();

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 spielr...@web.de 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 pson...@seznam.cz 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 n...@ossau.homelinux.net
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 m...@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: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf

[Neil Jerram]

Gilles Filippini gilles.filipp...@free.fr writes:

From what I understand, the emdebian repository had its toolchains
 upgraded on the 23/10/2012 [1]. It may be broken at the moment: it's now
 impossible to create a pdebuild chroot with my scripts :(

 [1] http://emdebian.org/debian/pool/main/g/

 I'll have a deeper look this evening.

 Thanks,

Thanks; I'm happy to have discovered a real problem and not just PEBKAC.
:-)

Neil

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

Re: QtMoko v48 neofreerunner

[Neil Jerram]

David Matthews m...@dmatthews.org 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: QtMoko v48 neofreerunner

[Neil Jerram]

David Matthews m...@dmatthews.org 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]

Boudewijn wankelwan...@yahoo.com 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: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf

[Neil Jerram]

Neil Jerram n...@ossau.homelinux.net writes:

 Gilles Filippini gilles.filipp...@free.fr 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 pson...@seznam.cz
  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: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf

[Neil Jerram]

Gilles Filippini gilles.filipp...@free.fr 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 n...@ossau.homelinux.net writes:

 Gilles Filippini gilles.filipp...@free.fr 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: 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/something.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 m...@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 

Re: QtMoko v48 neofreerunner

[Neil Jerram]

 dmatthews.org m...@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]

dmatthews.org m...@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: [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: [Gta04-owner] Experimental QtMoko/GTA04 build for armhf

[Neil Jerram]

Radek Polak pson...@seznam.cz 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]

Gilles Filippini gilles.filipp...@free.fr 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]

Neil Jerram n...@ossau.homelinux.net writes:

 Radek Polak pson...@seznam.cz 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: QTMoko website

[Neil Jerram]

Radek Polak pson...@seznam.cz 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 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: QTMoko website

[Neil Jerram]

Neil Jerram n...@ossau.homelinux.net 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 n...@ossau.homelinux.net
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 qtopialog.h
 
 /*
- 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

[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 n...@ossau.homelinux.net
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 qwebsettings.h
 
 #include QtopiaApplication
+#include QtopiaAbstractService
 
 #include qdebug.h
 
+#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

Re: QtMoko v48 neofreerunner

[Neil Jerram]

dmatthews.org m...@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

Re: Transcoding movies for QMPlayer

[Neil Jerram]

Gilles Filippini p...@debian.org 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 m...@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 cay...@internode.on.net writes:

 I have a GTA02 which I acquired a few years back and until now I have not 
 really done anything with it.  Now I want to use it as my main phone.

 The automatic setting of the date/time from the providors network (in this 
 case it is Optus) does not work in qtmoko.  The provider does support this as 
 I have a another phone that gets this information.

 I see there is an old bug from the Nokia days:
 http://docs.huihoo.com/qt/qtextended/4.4/release-4-4-3.html 
 BUG 231983

 According to 
 http://www.scribd.com/doc/30428306/54/AT-CTZU-Automatic-Time-Zone-Update 
 I should be able to chat to the modem to get some information.

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.

Do you know that NeronGPS can sync both time and time zone for you? -
obviously, subject to having a GPS fix.

 But the following command does not return anything:
 root@neo:~# chat -vse '' 'AT+CTZU=?' '' ''  /dev/ttySAC0  /dev/ttySAC0
 send (AT+CTZU=?^M)
 send (^M)

 syslog shows:
 Jan  1 08:13:45 neo chat[1109]: send (AT+CTZU=?^M)
 Jan  1 08:13:46 neo chat[1109]: send (^M)

 Is there a way to automatically log the AT chat commands ?
 Do I have the correct /dev/tty ?

 More generally, is this a problem with the calypso firmware, or qt extended / 
 qtmoko or something else ?

I'm afraid I don't know about those points.

   Neil

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

Re: [Shr-Devel] About the future of the freesmartphone.org middleware

[Neil Jerram]

Adam Ward cay...@internode.on.net writes:

 On Mon, 23 Jul 2012 10:29:38 AM Radek Polak wrote:
 On Sunday, July 22, 2012 02:08:39 PM Simon Busch wrote:
  As far as I know Qtmoko can use FSO but does not as default.
 
 Yes this is correct.
 
 My plan was to use FSO for GTA04. But when i got my GTA04, there was no work
 for this device done in FSO, so i rather added gta04 modem plugin based on
 qtopiaphonemodem framework and this now default.
 

 New GTA02 user here, I see the code in neocontrol.cpp pulls the library from 
 http://activationrecord.net/radekp/pub/ 
 I am guessing that at the time it was current.
 The debian package is now current, so I would expect it to be used instead ?

I can't tell what you mean here.  Which library / package?

 Neil

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

Re: [Shr-Devel] About the future of the freesmartphone.org middleware

[Neil Jerram]

Adam Ward cay...@internode.on.net writes:

 On Sat, 22 Sep 2012 10:01:23 AM Neil Jerram wrote:
 Adam Ward cay...@internode.on.net writes:
  On Mon, 23 Jul 2012 10:29:38 AM Radek Polak wrote:
  On Sunday, July 22, 2012 02:08:39 PM Simon Busch wrote:
   As far as I know Qtmoko can use FSO but does not as default.
  
  Yes this is correct.
  
  My plan was to use FSO for GTA04. But when i got my GTA04, there was no
  work for this device done in FSO, so i rather added gta04 modem plugin
  based on qtopiaphonemodem framework and this now default.
  
  New GTA02 user here, I see the code in neocontrol.cpp pulls the library
  from http://activationrecord.net/radekp/pub/
  I am guessing that at the time it was current.
  The debian package is now current, so I would expect it to be used instead
  ?
 I can't tell what you mean here.  Which library / package?
 
  Neil

 I am looking at 
 http://packages.debian.org/sid/armel/fso-gsmd/filelist 
 which contains libfsogsm

 Looking again, I see the newer versions are in sid and wheezy which radek 
 might not be building qtmoko with.

Ah, thanks, I understand your question now: what version of fsogsmd does
QtMoko build with, and isn't that now rather out of date?  But I'm
afraid I don't know the answers.

  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 cay...@internode.on.net 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

Re: QtMoko annoyance

[Neil Jerram]

On Friday, September 21, 2012 07:59:11, Radek Polak wrote:
 On Thursday, September 20, 2012 11:35:27 PM Minus 0 wrote:
 
  Hi,
  I wonder if it is at all possible to prevent the screen from unlocking on
  an incoming call? As I happen to keep my phone in my pocket, the automatic
  unlocking leads to the call being answered or rejected before I even have
  a chance to take the phone out of the pocket. Most of the time I use a
  silent profile, and if I walk around, I won't notice the call at all.
  But it will wake the phone up and unlock the screen, so random touches of
  the screen will make it do whatever it likes, like calling someone, e.g.
  an ambulance, delete all my contacts, or break my highscore in snake game,
  and of course drain the battery.
  An incoming message will wake it up, but not unlock the screen, which I
  think is a much more reasonable behaviour. Considering that SHR does it
  right, QtMoko should also be able to, I think.
 
 Sure. Maybe it would be nice to add slider for answering call on the lock 
 screen - so that you dont have to unlock  press answer.
 
 But i cant promise if i'll have time for implementing something like this 
 soon 
 :(
 
 Regards
 
 Radek
 
 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community
 

But, as a first step, we could implement that the phone is always locked when 
it resumes?  I could take a look at that, if everyone would be happy with it.

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

Re: QtMoko v48 neofreerunner

[Neil Jerram]

dmatthews.org m...@dmatthews.org writes:

 Hi Neil, Radek

 I spent some time on what I believe are the email issues.

 First thing I did to ensure I'm not going mad is the flash back to
 v35. As I remembered, I can create an account without bothering with
 correct settings, put the qtopiamail.conf in place and everything
 works.

 Next I flashed the 2nd v48 image - the situation has improved - the
 problem with the Get all mail entry disappearing has ... well
 disappeared - it does work fine. Despite what you thought - a
 difference in v48-1 with the upgraded qtmoko package installed on top
 as against the good v48-2? Can't be sure, but at least it's gone away
 for me.

Well that's good news!

 Trying to send mail though, that problem is as I reported already; I'm
 using the same qtopiamail.conf I just used in v35 which specifies the
 fastmail SMTP server (which I can ping) - sending a test mail to
 myself at dmatthews.org gives this rather generic looking error:-

 dmatthews.org -Error sending
 Email:Error occurred
 [Unknown error]

That comes from EmailClient::transferFailure() in
src/applications/qtmail/emailclient.cpp.  Tracking back from there, I
see:

- EmailClient::activityChanged(QMailServiceAction::Failed)

- QMailTransmitAction::activityChanged(QMailServiceAction::Failed)

- QMailServiceActionPrivate::emitChanges() following something that set
  _activityChanged to TRUE

- QMailServiceActionPrivate::setActivity(QMailServiceAction::Failed)
  (which is the only place that sets _activityChanged to TRUE)

- QMailServiceActionPrivate::errorOccurred() or
  (QMailTransmitActionPrivate::sendCompleted with !_ids.isEmpty()).

More likely errorOccurred, I guess.  That's as far as I can get for now;
the next step seems to involve a QtopiaIpcAdaptor, which I'm not
familiar with.

However, I think that point is not far above the raw SMTP level, so I
wonder if it would help to enable SMTP logging and see what that shows?
To do that, go into Home, Settings, Logging; choose YES twice; then
choose Categories... from the context menu, and check SMTP; then back
all the way out.  (You don't need to restart QtMoko, despite what it
says.)

Then repro the sending error.  Then go back into Logging and see what it
says.

With fingers crossed,

  Neil

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

Re: QtMoko v48 neofreerunner

[Neil Jerram]

dmatthews.org m...@dmatthews.org writes:

 2. Socket error on trying to send mail - I was pretty certain this was
 failing too quickly to actually be going out and trying to
 authenticate. I have generally used the fastmail.fm smtp server on the
 phone - not sure why, although possibly because it used to just work
 without too much fiddling.

 So I sacrificed the previously known good config in the copied
 qtopiamail.conf file that served me through several versions of qtmoko
 and entered details of my own mail server. I can then look at it's
 logs for information about a failed smtp connection - as I suspected,
 there is nothing there.

 In summary I'm pretty sure these are real problems on the neo that did
 not exist, in for instance versions 26 and 35.

I'd like to do what I can to help debug this, as I've been looking a bit
at the qtmail program, and finding it very useful.

For the mail sending problem, what exactly are the diagnostics?
For example, what is it that makes you write Socket error above?

Regards,
Neil

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

Re: [Gta04-owner] [QtMoko] QX touchscreen input do not work

[Neil Jerram]

NeilBrown ne...@suse.de writes:

 I spent a while looking into this and my conclusion is that while the frame
 buffer does support rotation, the Xorg driver for the omap3 framebuffer
 doesn't hook into that.  Also I couldn't find any evidence of ongoing
 development of the omap3 Xorg driver.
 So I'm guessing that to make 'xrandr' work on the GTA04 will take some fairly
 serious hacking in Xorg driver code.

 I wish I had time to do that ... though to be honest, if I did have the time
 I'd probably spend it on something else :-(

It seems that xf86-video-omap is going to be the way forward (rather
than -omapfb or -omap3) and that xrandr support has just recently gone
into it:

http://cgit.freedesktop.org/xorg/driver/xf86-video-omap/
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1026975.html

For QX in QtMoko, if I've understood correctly, I think this will be a
reason for upgrading to wheezy (when it's released).

  Neil

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