from:"Dave"

Rui Miguel Silva Seabra wrote:
 On Tue, Nov 10, 2009 at 12:00:31AM +, Dave Ball wrote:
 option1: New atoms in the _NET_WM_STATE property.
 - _NET_WM_STATE_LANDSCAPE
 - _NET_WM_STATE_PORTRAIT

 If neither is present for a given window, WM can choose (based on
 the accelerometers). Both present is an error - or could be defined
 as leave the window in it's current orientation.

 option2: New property.

 _NET_WM_ORIENTATION
 0 = Either / WM decides
 1 = Landscape
 2 = Portrait

 There are two landscape positions and 2 portrait positions :)
Doh - of course!  Which would lead to:

_NET_WM_STATE_ORIENTATION_LANDSCAPE
_NET_WM_STATE_ORIENTATION_PORTRAIT
_NET_WM_STATE_ORIENTATION_INVERTED

or

_NET_WM_ORIENTATION
0 = Either / WM decides
1 = Landscape
2 = Portrait
3 = Landscape inverted
4 = Portrait inverted

However, what's the use-case for an application requesting either of the 
inverted states?  I can't see when those would be useful - in terms of 
hints the app would supply.

Obviously, if the WM was deciding orientation based on the device 
position, you would correctly rotate to the inverted states, but if an 
application is built for portrait or landscape is there any reason a 
developer would not want the normal portrait/landscape orientation for 
the device?


Dave


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

Re: Ideal screen rotation

Warren Baird wrote:
 perhaps the landscape / portrait flag should just contrain the 
 rotation?   So if you flip the phone 180 degrees, you get the 
 'expected' behaviour, but if you just flip it 90 degrees nothing changes?

Given that these properties are for the orientation an application 
requests (to the WM) should ideally be used, I'm not sure how the actual 
rotation would help?  Working from rotation would also complicate the 
behaviour on devices that are normally landscape - such as the Nokia N900. 

What I'm suggesting is that the application just says landscape or 
portrait, and then the WM would decide the most appropriate way to 
orient the screen for that device.

If an application doesn't request either landscape or portrait, then the 
WM would rotate the screen according to the device orientation, through 
each of the positions the device could be held (including inverted).  So 
the WM definitely needs to know the actual orientation of the device 
(such as from the FSO api), but I think the application itself only 
needs to request Landscape, Portrait or neither.


Dave

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

Re: Ideal screen rotation

Rui Miguel Silva Seabra wrote:
 On Tue, Nov 10, 2009 at 12:08:06PM +, Dave Ball wrote:
 However, what's the use-case for an application requesting either of the 
 inverted states?  I can't see when those would be useful - in terms of 
 hints the app would supply.

 Obviously, if the WM was deciding orientation based on the device 
 position, you would correctly rotate to the inverted states, but if an 
 application is built for portrait or landscape is there any reason a 
 developer would not want the normal portrait/landscape orientation for 
 the device?
 

 Yes, certain devices may be better prepared (in terms of connectivity for
 power, usb, etc...) for one kind of landscape rather than the other.
   

Yup - although that would be at the device level rather than the 
application level.  If the WM knows what the device's policy is, I can't 
see a situation where one app wants to be in landscape, and a 
different app wants to be in landscape inverted on the same device?

Dave

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

Re: Ideal screen rotation

Warren Baird wrote:
 I meant that it should *constrain* the behaviour of rotation - more or 
 less like omnewrotate behaves now, but skipping over the two 
 'incorrect' orientations. 

 so if the app says 'landscape', it's still flip between xrandr -o 1 
 and xrandr -o 3 as you rotate the phone, but won't flip to xrandr -o 0 
 or xrandr -o 2.

 I don't think it will normally makes sense for an application to 
 specficially request 'xrandr -o 3' - they will usually just want to be 
 sure that they are displayed in portrait or landscape mode.
ok, we can make that a policy decision in the WM, but the app only needs 
to specify portrait or landscape.


Dave


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

Re: Ideal screen rotation

2009-11-09 Thread Dave Ball


Carsten Haitzler (The Rasterman) wrote:
wm needs to track both and determine which one takes precedence based 
on policy and th en implement that rotation, if needed. policy is what 
a wm implements - that's the nature of the beast. that policy may be 
hard-coded in the wm or configuration for it.


I've been looking at existing window properties [1] to try and 
understand the best way to do this.



option1: New atoms in the _NET_WM_STATE property.
 - _NET_WM_STATE_LANDSCAPE
 - _NET_WM_STATE_PORTRAIT

If neither is present for a given window, WM can choose (based on the 
accelerometers). Both present is an error - or could be defined as leave 
the window in it's current orientation.



option2: New property.

_NET_WM_ORIENTATION
 0 = Either / WM decides
 1 = Landscape
 2 = Portrait


Thoughts?



http://www.youtube.com/watch?v=abNsVyYTSkU
  

OT - but I'm struggling with e's xnest.sh script:
   xhost +
   su newuser
   Xnest -ac :1 
   env DISPLAY=:1 enlightenment_start 

works, but:

   xhost +
   su newuser
   /data/programming/e17/e17_src/e/xnest.sh

doesn't.  Initially it ran through e's firstrun wizard in an xnest, then 
crashed - now it dies on start.  I've attached the xnest.sh output - any 
ideas?



Dave

[1] http://standards.freedesktop.org/wm-spec/1.4/ar01s05.html

newu...@dougal:/data/programming/e17/logo-0.0.1$ 
/data/programming/e17/e17_src/e/xnest.sh
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing 
from list!
(EE) config/hal: NewInputDeviceRequest failed (2)
(EE) config/hal: NewInputDeviceRequest failed (2)
(EE) config/hal: NewInputDeviceRequest failed (2)
(EE) config/hal: NewInputDeviceRequest failed (2)
(EE) config/hal: NewInputDeviceRequest failed (2)
(EE) config/hal: NewInputDeviceRequest failed (2)
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu...
[Thread debugging using libthread_db enabled]
ESTART: 0.0 [0.0] - begin
ESTART: 0.00010 [0.00010] - signals done
ESTART: 0.00014 [0.4] - determine prefix
DYNAMIC DETERMINED PREFIX: /opt/e17
ESTART: 0.00034 [0.00020] - prefix done
ESTART: 0.00037 [0.3] - eina init
[New Thread 0x7f440ce2c710 (LWP 25665)]
ESTART: 0.01835 [0.01798] - intl init
ESTART: 0.01840 [0.5] - parse args
ESTART: 0.01841 [0.1] - arg parse done
ESTART: 0.01845 [0.3] - ecore init
ESTART: 0.02113 [0.00268] - ecore_file init
ESTART: 0.02128 [0.00015] - more ecore
ESTART: 0.02129 [0.1] - x connect
Xlib:  extension DPMS missing on display :1.0.
Xlib:  extension RANDR missing on display :1.0.
ESTART: 0.02402 [0.00273] - ecore_con
ESTART: 0.02432 [0.00030] - xinerama
E17 INIT: XINERAMA CHOSEN: [0], 1080x675+0+0
ESTART: 0.02665 [0.00233] - x hints
ESTART: 0.02702 [0.00037] - x hints done
ESTART: 0.02703 [0.1] - ecore_evas init
ESTART: 0.02715 [0.00012] - test done
ESTART: 0.02716 [0.1] - efreet
ESTART: 0.02731 [0.00015] - efreet done
ESTART: 0.02732 [0.1] - configure
ESTART: 0.02738 [0.6] - dirs
ESTART: 0.02746 [0.8] - filereg
ESTART: 0.02747 [0.1] - config
ESTART: 0.02906 [0.00159] - scale
ESTART: 0.02915 [0.8] - pointer
ESTART: 0.02916 [0.2] - path
ESTART: 0.02922 [0.6] - ipc
INFO: E_IPC_SOCKET=/tmp/enlightenment-system/disp-:1.0-25665
ESTART: 0.02954 [0.00031] - font
ESTART: 0.02957 [0.4] - theme
ESTART: 0.03629 [0.00672] - intl post
ESTART: 0.04364 [0.00735] - move/resize info
ESTART: 0.04374 [0.9] - splash
RUN INIT: /opt/e17/lib/enlightenment/utils/enlightenment_init 
'/opt/e17/share/enlightenment/data/themes/default.edj' '1' '0' 'Enlightenment' 
'0.16.999.062'
Xlib:  extension DPMS missing on display :1.0.
Xlib:  extension RANDR missing on display :1.0.
E17 INIT: XINERAMA CHOSEN: [0], 1080x675+0+0

Program received signal SIGUSR2, User defined signal 2.
[Switching to Thread 0x7f440ce2c710 (LWP 25665)]
0x7f4407b0e8b0 in __pause_nocancel () from /lib/libpthread.so.0
#0  0x7f4407b0e8b0 in __pause_nocancel () from /lib/libpthread.so.0
#1  0x0042e626 in main ()
The program is running.  Exit anyway? (y or n) [answered Y; input not from 
terminal]
newu...@dougal:/data/programming/e17/logo-0.0.1$ [dix] Could not init font path 
element /usr/share/fonts/X11/cyrillic, removing from list!
(EE) XKB: No components provided for device Virtual core keyboard

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

Re: Ideal screen rotation

2009-11-08 Thread Dave Ball

Carsten Haitzler (The Rasterman) wrote:
 On Sun, 08 Nov 2009 04:37:07 + Dave Ball openm...@underhand.org said:
   
 Is there a quick-start guide for writing an e module, maybe some simple 
 code / example?
 

 http://www.rasterman.com/files/logo-0.0.1.tar.gz
 http://www.youtube.com/watch?v=abNsVyYTSkU
   

Heh - Thanks!  That's pretty comprehensive and cool - now if only 
youtube would let me step frame-by-frame!  :-)

Dave

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

Re: Ideal screen rotation

2009-11-07 Thread Dave Ball

Carsten Haitzler (The Rasterman) wrote:
 On Sat, 7 Nov 2009 19:46:28 + Rui Miguel Silva Seabra r...@1407.org 
 said:
   
 Being X properties or DBUS, it's the same for me. DBUS seems more natural as
 there's probably less pooling, but then I know only a bit more of DBUS than
 of X11 (which AFAIR was a bunch of huge books) :)
 

 no. dbus is far from natural or correct. that's what i keep saying. this is 
 not
 something for dbus. it's something for properties on a window.
   

Sounds like we should be using window properties for passing hints to 
the WM, and dbus for getting orientation information from the 
accelerometers.

Maybe it's time for omnewrotate to retire, with the WM talking to FSO's 
orientation API [1] directly?

app - window properties - wm - dbus - fso

WM making the decision on what direction to orient the display, based on 
window properties and device actual orientation etc.


Dave

[1] 
http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Orientation.html;hb=HEAD


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

Re: Ideal screen rotation

2009-11-07 Thread Dave Ball

Carsten Haitzler (The Rasterman) wrote:
 On Sun, 08 Nov 2009 02:03:47 + Dave Ball openm...@underhand.org said:

   
 Sounds like we should be using window properties for passing hints to 
 the WM, and dbus for getting orientation information from the 
 accelerometers.
 

 that is sane. :)

   
 Maybe it's time for omnewrotate to retire, with the WM talking to FSO's 
 orientation API [1] directly?
 

 perhaps. whatever the mechanism

 1. the wm is the right place to make the decision.
 2. the wm is in the best position to easily gather information about an
 application's window and know what window is active
 3. the wm is already talking to the xserver as part of its job - and it's
 always hanging around
 4. all the wm needs to know is some external input has decded that the screne
 should be rotated. 

I think what you meant here is the WM decides whether the screen should 
be rotated or not - all the 'external input' provides to the WM is some 
hint that e.g. the _device_ has been rotated?  WM could decide to NOT 
rotate the screen, if the current app only works in one orientation.

 be this an accelerometer, or like the g1, opening up the
 screen, so be it. as long as
 4.1 the current status of this rotation state can be queried at any time (you
 can ask what position the device is in or the screen is opened up or not etc.
 etc.)
 4.2 you can get an event when this state changes really quickly (not have to
 wait a while).
   

Indeed.  I've not played with the fso orientation API, but it looks like 
that is exactly what it's designed to provide.  It seems sensible for 
this to be over dbus - given that it's an abstraction of hardware.

 if it were me... i'd even have the current desired rotation state be a 
 property
 on the root window too... but at this point its moot - dbus or property. 

If the root window will only work in one orientation, specifying that 
orientation through a window property would be consistent - but ideally 
wouldn't we want the root window to be able to cope with being rotated 
to work in either orientation?  Or have i missed something special about 
the root window?


Dave


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

Re: Ideal screen rotation

2009-11-07 Thread Dave Ball

Carsten Haitzler (The Rasterman) wrote:
 wm needs to track both and determine which one takes precedence based 
 on policy and th en implement that rotation, if needed. policy is what 
 a wm implements - that's the nature of the beast. that policy may be 
 hard-coded in the wm or configuration for it.

Is there a quick-start guide for writing an e module, maybe some simple 
code / example?

Dave

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

Re: zzz Freerunner headphones and screen protector - free to a good home!

2009-11-02 Thread Dave

Hi Chris,

Thank you for your generous offer - I have sent you an email with my
details.

On Tue, Nov 3, 2009 at 2:07 AM, Chris Hogan hodgin...@gmail.com wrote:

 Hi all,

 As the subject says: I have a set of Freerunner headphones and an
 Invisible Shield screen protector (screen only) available to anyone
 who wants them. I don't have a use for either - they've been
 cluttering up my bookshelf for over a year now - so I've decided to
 pass them on to someone who might use them. If you want either or both
 of these items then send me an email with your address and I'll send
 them out.

 Australians will get preference, to keep down postage costs, but the
 offer is open worldwide (If the recipient wants to cover the cost of
 postage I'd appreciate it, but it's up to them).

 The screen protector is still in the box unused. The headphones I
 think I used once, to see if they worked. I'll try them again before I
 send them off, to make sure they still work.

 Thank you!

 Chris.

 ___
 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: [QtMoko] minor questions

2009-10-23 Thread Dave TV

Hi,
Remove from favorites is right click while in
SettingsTaskmanagerFavorites, not from the favorites screen

Dave

On Sat, Oct 24, 2009 at 4:08 AM, foringer forin...@gmail.com wrote:

 Hello!

 В Птн, 23/10/2009 в 10:24 +0200, Vincent Meurisse пишет:
   First is - how can I remove application from Favorites tab? I did not
   find any possibility to do this for now.
  If you do a right click (click on an element and stay a few seconds) on
 the
  element you want to remove, you will see a menu where you can remove it.
 Thanks, but where is that magic remove button? Under Application menu
 - I can get right click, but there only add to Favorites sub menu.
 When I tried to get right click under Favorites tag - I had nothing,
 it does not work there...

 
   Third is - what is the location of my contacts database on the FR?
  /home/root/Applications/Qtopia/qtopia_db.sqlite
 
   Fifth is - I did apt-get update and had about 14 not upgraded packages.
   Is it safe for now to do and upgrade for the system software from lenny
   repository?
  If you read this : http://bugs.qtmoko.org/view.php?id=58
  
   Six is - as I understood, all personal information is located under
   Documents directory of the user. Can I move this directory to the SD
   card and make simlink to the home location?
  Make a symlink for all the /home/root/ directory
 
   PS. I found some minor bug: the home directory of the root user in the
   qtopia environment is /home/root, but in debian - it is /root. Updating
   the HOMEPATH in the /etc/passwd fix this issue.
  
  The best would be to move QtMoko home to /root to keep the installation
 close
  to standard debian. Unfortunately Qtopia don't like to have the home
 directory
  not in /home/root.


 ___
 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: Qi - why only 3 partitions on SD card?

2009-09-26 Thread Dave Ball

Dr. H. Nikolaus Schaller wrote:
 What I wonder is why nobody did fix u-boot if it had problems with  
 bigger kernels.
   
I'm just a bystander here, but from what I understood this wasn't the 
reason Qi was started.

u-boot is an entire environment that needs drivers for a lot of the 
hardware (usb, graphics, pmu, etc.) all of which end up duplicated in 
the Linux kernel.  The u-boot philosophy (of an entire environment 
supporting DFU and a boot menu) implies that those drivers have to be 
maintained in two places (u-boot and kernel) which cases pain, and 
inevitably results in u-boot being slower to boot.

Qi starts with a completely different philosophy - that the bootlooder 
should do as little as possible, and that it should need to know as 
little as possible about the hardware.  In terms of intent, it's closer 
to the coreboot project than it is to u-boot.  You really couldn't 
achieve this [separation of bootloader  device drivers] with u-boot, 
which is why the separate Qi project was formed instead of continuing to 
evolve u-boot.

So what you _can't_ do inside Qi is have a graphical boot menu, or 
support dfu - because Qi doesn't know how to talk to the hardware.  What 
you _can_ do is construct a mini Linux environment that provides a boot 
menu / usb-dfu, and is booted by Qi in the normal way.  This would place 
those tools in regular Linux userspace, i.e. much more accessible to 
regular non kernel / bootloader hackers.  This could be the default or 
secondary boot option - provide a boot menu and then chainload the 
desired final Linux environment.

There's a philosophical difference between the two projects, and I think 
Qi's approach is much better suited to this kind of hardware, than 
u-boot could ever be (with trunk, or with the existing gripes resolved). 

 But you can only influence the future but never change the history...
   

Wise words! :-)  Imho our time would be better spent building this 
mini-environment (which would probably be best constructed in initrd as 
Paul mentioned) than returning to u-boot.

Any takers?


Dave



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

Re: [CU] voting required

2009-07-29 Thread Dave Ball

Andrew Stephen wrote:
 2009/7/28 Warren Baird wjba...@alumni.uwaterloo.ca:
   
 looks great - I took the liberty of adding the version #'s into the output
 created by the template, so you can see the version #'s on the draft
 community page.

 My preference is '8a'
 

 I vote for 8a also.

   
8a was the one I liked.

Dave

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

Re: [CU] voting required

2009-07-27 Thread Dave Ball

Jon 'maddog' Hall wrote:
 I assume you would like to modify V1, but could you explain how more 
 precisely?
 I like the over-all look of V1, but I also like the working hardware
 box.  By putting the working hardware box in a column by itself,
 making a three-column layout, you reduce the amount of space for column
 two, which makes the page longer showing the same amount of information.
 I suggest that the working hardware box of V3 be moved to the first
 column under the left-hand picture of the application/distribution. Then
 the home page, Image, Tested on Hardware, etc. which is now at the
 bottom of the page could also be listed in the left hand column beneath
 the working hardware box.  This would allow the right hand column (of
 what is now a two-column page) to be just text on a white background.
   

I was just trying to describe exactly the same thing.  I like this 
approach, based on the clean V1, and think that it will be clear enough 
where one section stops and the other starts by the picture/title 
associated with each table.  If that doesn't work, in my mind a simple 
1px gray light border would work better than the block colours, which 
can be a little over-powering.


Dave

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

Re: [CU] voting required

2009-07-27 Thread Dave Ball

Patryk Benderz wrote:
 [cut]
   
 associated with each table.  If that doesn't work, in my mind a simple 
 1px gray light border would work better than the block colours, which 
 can be a little over-powering.
 
 1 px added for you where relevant. Tell me how do you like it now.
   

I Like it - particularly the one with two columns (not three) and the 
1px orange border.


Dave

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

Re: The University of São Paulo's intent to join Openmoko development

2009-07-17 Thread Dave Ball

Hi Maddog,

 it certainly sounds like an amazing opportunity, almost too good to be true 
 - what's the catch!  :-)
 
 I hope that you will find there is no catch.  If you do think there is
 a catch, please tell me.
   

Thanks again for bringing this to us, and the detailed responses.  I 
think this is a very positive opportunity, and I hope we are on track to 
the university being in a position to help out with our little projects.

I think Werner is trying to catch up with Dr Zuffo - which in my mind 
would be a very good thing to happen as Werner is definitely the point 
man for the gta02-core effort.

 I certainly see the university as sponsors of the project, in the fact
 that it does cost money to run such an SMT line, to do some of the legal
 work, etc.  I would like to find a way to help compensate them for this
 work, to make the project truly self-sustaining.  Dr. Zuffo and I have
 discussed government grants and other funding ideas.  Please see below.
   

snip

 In order to fund the Openmoko project, I would like to suggest that
 *all* the things that Openmoko made open *up to this time*:

 o circuit design
 o case design
 o circuit board layout
 o testing issues.
 o plans for future, etc.

 be completely open and published as before.

 But (for example) the gerbers be licensed with a small royalty (1-2
 dollars per phone, with a cap of 500,000 to 1,000,000 USD) only if the
 party will make *over* 5,000-10,000 phones

There are obviously some significant costs associated with developing 
hardware that while HW development took place inside openmoko, were met 
by Sean etal.  You rightly point out that if we're to be successful 
we'll need to find ways to meet those costs.

I'd very much like to hear others thoughts on the matter, but from my 
point of view (and this may be wishful thinking), if there are 
opportunities to fund this work through grants or corporate donations, I 
think this would be preferable to licensing the end results (i.e. the 
gerbers) for production.

In my mind, licensing the gerbers for production introduces restrictions 
on the uses that a recipient may put those designs too - including their 
ability to modify  redistribute those files.  My preference would be to 
encourage that redistribution, through Share-Alike / GPL style licensing 
of all assets.  If a manufacturer wants to adopt the design to a new 
case, add extra buttons, changes components or invests additional 
resources in increasing production yields, the rational for sharing that 
investment with other licenses is less concrete.

Some potential sources for funding might be:
 - phone fabs that would otherwise need to spend significantly more 
money either developing their own designs or buying someone else's design
 - government grants to seed phone production industries, or promote 
telephony freedom
 - universities or other research organisations that can use our devices 
as a platform for learning or their own development.

If gerber licensing is believed to be the only realistic way to generate 
the investment needed for prototype runs etc., I think there would be 
benefit in any such ownership and licensing being conducted through a 
legal vehicle independent of any one individual or organisation (I don't 
know if LSITEC fits this description or not).  Doing so would encourage 
the involvement of multiple organisations, universities or individuals, 
and would allow the team to select the most economic or timely method 
for purchasing or prototype production - through one of our partners or 
external commercial parties if they're able to deliver more effectively.


I don't want my comments to be taken negatively, I think LSI-USP has 
fantastic potential for helping these projects, ensuring the longterm 
viability of our dream and filling in some of the gaps that are apparent 
in our efforts to-date.  I think you're spot on that universities could 
be excellent partners with many shared objectives in what we're trying 
to achieve.

Can we do this without resorting to paid licensing of any of our assets?

I see a scenario where we, with USP, are in a position to generate 
designs that they could take into small scale production (similar to 
OM), selling those handsets to the community at small scale profits, 
using the process for the benefit of their students and generating a 
platform for them to grow in the future - while maintaining the SA style 
licensing.  If it's achievable, this seems the ideal outcome to me.

/$0.02

All the best,
Dave


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

Re: Freerunner Chat Application: Suggestions wanted!

2009-07-16 Thread Dave Ball

Rui Miguel Silva Seabra wrote:
 On Thu, Jul 16, 2009 at 01:16:09PM +0100, Michael Sheldon wrote:
   
 Alex Teiche wrote:
 
 Hello everyone,

 I recently recieved my A6 FreeRunner, and have been looking for some coding
 to do:)  I plan on writing a chat application(similar to Pidgin) optomized
 for the small screen.  I was wondering what suggestions the community had
 before I get too far into it.
   
 Hi Alex,

  I'm actually currently working on a project similar to this using
 elementary and telepathy; I haven't made it particularly public yet as
 it's only in a very roughly usable state and I think I still need to
 spend some time updating some of the telepathy packages in OE before
 it's easy to install directly on the device (there are easy to install
 debian/ubuntu packages though).
 

 Release early, release often, have a public repository for sources, issues,
 etc... works best even if your first releases only have basic functionality.

 Go, go, go, go! Mike :)
   
+lots

I love the concept here - bringing together a contact and all your 
contact with them (through whatever medium), and using the best method 
for reaching them.  What's the odds of integrating this with google 
voice or similar roaming-number service?

I don't know where FSO is at with a comprehensive contacts database 
(i.e. beyond sim stored data), but it might be worth talking to them 
about integrating your contacts store needs as an FSO api?


Cheers,
Dave

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

Re: The University of São Paulo's intent to join Openmoko development

2009-07-16 Thread Dave Ball

Jon 'maddog' Hall wrote:
 So organize your needs.  Reach out to your own universities and software
 usability development groups.  Get them to join the project.

 Don't give up.  If you look closely, you can see the light at the end of
 the tunnel.  It may be faint, but I have seen similar tunnels before,
 and I can see the light now.
   

This (and the aim of something better) is all the encouragement we 
should need.  This is up to us, and we need to work together - each 
finding the area we can contribute - to first make the current projects 
successful, then expand, and later change the way people look at their 
phones (in the same way that Linux has changed data centres and startups).

Dave

ps - illume and SHR rocks my FR

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

Re: The University of São Paulo's intent to j oin Openmoko development

2009-07-13 Thread Dave Ball

Hi Maddog,

[added cc to gta02-core list]

Thanks for looking into this - it certainly sounds like an amazing 
opportunity, almost too good to be true - what's the catch!  :-)

Do you know how Dr Zuffo sees the universities involvement with, and 
relationship to the rest of the community - i.e. do they seem themselves 
driving the projects, becoming 'sponsors', or as contributing members of 
the wider community?

 From my point of view, it sounds like they've got a lot to offer the 
projects (both in expertise and facilities), and I think our community 
would be stronger with them as members.  I'm assuming from your messages 
below that (initially at least) they are happy participating in the 
kicad / CC-SA licensed community process gta02-core has adopted so far?

While we're a long way away from producing quantities of 10,000 devices, 
in the coming weeks and months the gta02-core project is hoping to be in 
position to produce a handful of prototypes.  It sounds like LSI-USP 
might be able to help us with this current design process, and 
production of the prototypes?  This could be a sensible starting point 
for Dr Zuffo and LSI-USP to get involved with the community, building a 
relationship that can grow as we get to know them, and they get to know 
us! 


All the best,

Dave


Jon 'maddog' Hall wrote:
 Dear Openmoko Community,

 In light of the refocusing of Sean's company on consumer items, there
 has been a perceived vacuum created in the Openmoko community's efforts
 to create next-generation open cellular smart phones.

 I happened to be working with Dr. Marcelo Zuffo, a full professor and
 the head of the Laboratory for Integrated Systems at the University of
 São Paulo, Brazil, on an unrelated project.  I asked Dr. Zuffo if the
 university would be willing to join the Openmoko community and to
 provide critical resources to the task at hand.

 I subsequently have met with Dr. Zuffo several times on this matter,
 have seen his facilities (which include a very modern and
 state-of-the-art SMT line) and have discussed the goals of the community
 to design and prototype a completely open design for a cellular phone.
 Dr. Zuffo and the university understand your issues, understand free and
 open source software and hardware and are willing to assist the
 community with this project.

 I might add that the university can bring several new capabilities to
 the community:

 First of all, Dr. Zuffo has discussed the Openmoko project with the
 Minister of Telecommunications of Brazil, and the Minister is very
 enthusiastic about the concept.  Having the support of the government of
 the twelfth largest economy behind the project might really help us with
 various negotiations with vendors.

 Secondly the University has been working on several aspects of
 telecommunications for a long time, and therefore has expertise in
 telephonic security and codecs (among other things) that could be of use
 to the Openmoko community.

 Third, the university has the ability and expertise to design new
 integrated circuits.  Recently they designed a a range of analog-digital
 chips.  Therefore the possibility of developing, manufacturing and
 freely licensing new chips to help reduce the cost of the phone is
 possible.

 Forth, while the facilities I mentioned are capable of producing up to
 10,000 units at the rate of one circuit board every 30 seconds,  the 
 purpose of the facilities is research, developing and support projects
 that can lead innovation, the lab's charter does not allow them to
 manufacture more units then the 10,000 because that would be commercial
 production.  Therefore the university has a goal of freely licensing
 the design to companies for manufacture.

 Fifth, the university would be happy to host the mailing lists and
 forums of the Openmoko project.  If some of the software projects need
 hosting and can not find hosting services other places, the university
 will consider acting as a primary hosting facility for these projects.

 Sixth, personally I would like to see this concept extended, of inviting
 more universities and their facilities to help with this project
 world-wide.  I hope that the leadership of the University of Sao Paulo
 will help create the structure and inspiration for this to happen.

 Finally, the university has a non-profit legal entity, LSITEC, which can
 easily do the type of paperwork that Sean's company did (NDAs,
 certification) so the community can leverage off that.

 I know that there will be a lot of questions and considerations to take
 before the community is comfortable with this relationship.  Dr. Zuffo
 has asked that I help coordinate the joining together of the university
 with the community, and in the interest of seeing Openmoko continue to
 do the fine work started by Sean and all of you, I will be glad to help
 in this capacity.  I am monitoring the community mailing list, and
 people are also welcome to email me directly (mad...@li.org

Debuzzing in the UK?

2009-06-10 Thread Dave Smith

Hi all,

It's been a while since I looked at getting the buzz on my FreeRunner 
fixed up, after having no luck finding anyone with the right equipment 
to be able to perform it amongst local friends and contacts, so I 
figured I'd throw a message out on here to see if anyone can point me in 
the direction of anyone in the United Kingdom who has the tools, time, 
and inclination to perform the fix for me. :)

Has anyone any experience with getting someone in this area performing 
the fix?

Thanks in advance,

Dave

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

Re: Debuzzing in the UK?

2009-06-10 Thread Dave Smith

Many thanks.

Dr. H. Nikolaus Schaller wrote:
 http://www.handheld-linux.com/wiki.php?page=Buzz-Rework
 
 Just as far as your nearest Royal Mail...
 
 BR, Nikolaus
 
 Am 10.06.2009 um 09:08 schrieb Dave Smith:
 
 Hi all,

 It's been a while since I looked at getting the buzz on my FreeRunner
 fixed up, after having no luck finding anyone with the right equipment
 to be able to perform it amongst local friends and contacts, so I
 figured I'd throw a message out on here to see if anyone can point  
 me in
 the direction of anyone in the United Kingdom who has the tools, time,
 and inclination to perform the fix for me. :)

 Has anyone any experience with getting someone in this area performing
 the fix?

 Thanks in advance,

 Dave

 ___
 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


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

Re: Freerunner's Future

2009-06-02 Thread Dave Ball

Rui Miguel Silva Seabra wrote:
 On Wed, Jun 03, 2009 at 12:30:21AM +0400, Alexander Chemeris wrote:
   
 On Tue, Jun 2, 2009 at 8:44 PM, Rui Miguel Silva Seabra r...@1407.org 
 wrote:
 
 For now, I'm hoping my Freerunner improves enough to last long, as I don't
 expect another Free Software phone to come up anytime soon.
   
 Don't forget about GizmoForYou project with its Flow, as just an example:
 http://www.gizmoforyou.com/comment.php?comment.news.41
 
 Flow looks sleek, but what about it's commitment to Free Software? I really
 don't know, can you help me know more?
   

The flow project itself seems pretty open, but it depends on gumsticks, 
which have closed hardware but seem to be widely supported by open 
software  corresponding communities.

It sounds an interesting project, and will be available much sooner than 
the gta02-core or 'future' work which we have started, although these OM 
/ gta derivatives might have more potential in the longer term.

I echo everyone elses thanks to Sean and the rest of the team that have 
had involvement with OM - you guys both achieved a lot, and did so 
openly in a way that gives us a platform to build from.  Through the 
last couple of years and now, thanks for communicating as openly as you 
have.

It's down to us now, and I look forward to both contributing myself, and 
benefiting from the contributions from the whole community.


Dave


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

Re: Freerunner's Future

2009-06-02 Thread Dave Ball

Risto H. Kurppa wrote:
 Thanks Sean for this announcement!

 It's appreciated to get a status update from OM of things we've heard
 rumors of. I'm very happy that OM got this far with the phones: we
 have some tens of thousands (better guess anyone?) of Linux phones
 around the world, various open/free distros to run on the HW and means
 to communicate to make it better. I think OM was decent on the
 hardware side, it's a great achievement to have manufactured a
 open/free Linux-phone. Thank you for that, thank you everyone who
 worked on OM for this!
   

ditto!  :-)  And also thanks for the commitments to opening up further 
details, designs and marks in support of the community, and providing 
the om.org infrastructure we're using.

 Now as the community will go 'wild', I'd now, more than ever, like to
 see good leadership practices to organize and guide the community. If
 you ask me where OM failed, it's this: managing and leading the
 community. So I think we'd need some direction where to make people
 go, who don't know where to go. We have around 20 distros and phone
 apps - I wouldn't like to see this all break in small sub-projects
 that all do the same work and don't communicate, but one single big
 project that'd actually take us somewhere.

Diversity has it's advantage, though focus on a smaller number of 
projects has it's own benefits too.  I think it's great that FSO has 
resulted in a stable platform that most of the current distros rely on 
and benefit from.

While there remains interest in the current (or future) distros, my 
personal feeling is that we shouldn't try to kill one, in favour of 
another.  They currently all have strengths and weaknesses, and the 
community as a whole gets strength from their diversity.  We should 
collaborate on any common ground (kernel, fso?, illume?), and allow 
distributions to differentiate where they see appropriate.

I think you are spot on though that we need to be better organised, and 
as individuals, communities and 'leaders' (if that's appropriate) have 
clear asperations and achievable objectives.

Overall, I think clarity and sensible organisation will allow the 
community(ies) to flourish, while supporting as much diversity as the 
different sectors of our community want.


Dave

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

Re: New Life in Openmoko Phones

2009-05-20 Thread Dave Ball

Max wrote:
 Are there plans to change uSD placeholder?

No - changing uSD holder isn't part of the GTA02-core plans. 

In GTA02-core the intention is that the uSD card contains the full OS 
image including kernel.  The NAND will only contain QI, and the 
expectation is that QI won't need to be re-flashed regularly.  
GTA02-core can't start if the card is missing, and there's no 
possibility of swapping out the card while the phone is switched on.

Thus the uSD is rather like a standard PC's OS hard drive, and rather 
unlike 'removable' media types.

This is how some folk are using the uSD at the moment, with one or 
multiple distro images on an uSD card.  Upgrading a distribution, or 
fixing a broken install is then possible by removing the uSD and 
mounting it in a regular PC, without necessarily re-flashing through 
dfu.  With GTA02-core, each distro can have a kernel ( modules etc) 
it's matched to, because the kernel is part of the distro's filesystem 
image.  This also means that our internal storage is upgradable, as 
new uSD devices become economical etc.

One thought is that future phones should include two uSD cards - one 
'internal' for OS/kernel etc. and one that is 'removable' for data 
storage/exchange - although this is out of scope for GTA02-core.



All the best,

Dave

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

Re: New Life in Openmoko Phones

2009-05-20 Thread Dave Ball

Martin Bernreuther wrote:
 One thought is that future phones should include two uSD cards - one 
 'internal' for OS/kernel etc. and one that is 'removable' for data 
 storage/exchange - although this is out of scope for GTA02-core.
s/should/could.

Obviously there isn't any commitment to future phones at the moment, so 
while I may think two uSD cards is a swell idea, it may or may not happen.

Dave

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

Re: New Life in Openmoko Phones

2009-05-19 Thread Dave Ball

GNUtoo wrote:
 *will the sound quality be ok(is there a plan to correct the problematic
 capacitor that is between the sound card and the audio connector)? and
 will it fit into the same case than the GTA02...because if I understood
 well the sound problem can't or is too difficult to fix well(otherwise
 it's dangerous...) on the GTA02
   

We expect to be able to get the 100uF capacitors in the space we gain 
from removing the audio amp and the u4401 (gsm upload) circuitry.  
Retro-fitting to gta02 boards is more complex, as there is neither board 
space or vertical height above existing components and below the can.

 *Does everything fit into the buses(GPIO,SPI etc...) because the
 removing the glamo removes some GPIO if I remember well
   

Removing Glamo loses the SDIO interface currently used for the SD card.  
So we will be moving the WLAN to SPI, and the SD card to the SDIO 
interface on the SoC freed up by the WLAN  It all fits so far.

 *I bet I will need to buy the debug board if I buy such phone...because
 I'm afraid of bricking it(no NOR means only one bootloader...and I could
 have rendered mine unbootable if the nor was not present: I typed bad
 uboot command and that prevented the nand uboot from beeing used(no more
 usb-serial access and no more booting))
   

The expectation is that QI and any build data will be written to NAND 
once, and then not over-written.  QI's simplicity means that once it's 
working for the new board, it shouldn't need upgrading later.  Combined 
with the kernel and OS images on the SD card, this should eliminate (or 
at least vastly reduce) any writing to NAND.  This puts the gta02-core 
bootloader in a similar situation to the current GSM firmware, and many 
PC BIOSes - not normally field serviced, but can be if needed.

Debug boards or other JTAG equipment will be needed for anyone hacking 
on the initial boot/bringup, which probably covers all of the handful of 
prototype boards we're currently expecting to produce...


Dave

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

Re: New Life in Openmoko Phones

2009-05-18 Thread Dave Ball

Werner Almesberger wrote:
 Wolfgang Spraul wrote:
   
 Today Openmoko released additional pieces of documentation about 
 Freerunner hardware: board outline, footprints and netlist.
 

 This is great. Thanks a lot to you and everyone in Openmoko who has
 helped to make this happen !

Ack - Thanks all!

Dave

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

Re: New Life in Openmoko Phones

2009-05-18 Thread Dave Ball

David Reyes Samblas Martinez wrote:
 2009/5/18 Rui Miguel Silva Seabra r...@1407.org:
   
 On Mon, May 18, 2009 at 07:20:13PM +0200, arne anka wrote:
 
 http://wiki.openmoko.org/wiki/Gta02-core
 
 sounds interesting.
 could someone add background information why parts change?
 removing the glamo seems pretty plausible, but why removing one of the
 accelerometers? audio amp? nor? ...
   
 I don't see why to remove one of the accelerometers and have added so to
 the Discussion tab.
 
 For this you have the actual GTA02,
 I'm not an expert at all, but keep things simply is always a good Idea
 , and as they sayd is not pretended to have a production ready phone,
 but all the learning done in the way of do this simply phone can
 help to start a more complicated design, even with gyroscopes,
 compass, a full kitchen and swimming pool if it fit the case, but now
 I agree in do this a simple but powerful as they can,  and even if
 they finish with something looks like this[1]   but with functional
 GPS/WIFI/BT/GPRS/CIR/SIR/USB will worth the effort
   
For me, I think you've hit the nail on the head.  We're trying something 
new with gta02-core, and by working on the small changes we've proposed 
we can focus on the tools that we use, the organisation of individual 
contributors and the stages we need to go through to get functional 
hardware.  Doing gta02-core means that we should be able to move forward 
fairly rapidly and shake out any problems as we go.  For that aim, the 
specific changes we make are almost arbitrary - and as stated on the 
wiki we don't expect this to turn into production hardware.

My hope is certainly that we'll be in a position to design a more 
interesting device once we've finished with gta02-core, having 
established a hardware community and process for making those design 
decisions.  We'll also be in a better position to discuss part 
availability with suppliers (or project sponsors), if we've demonstrated 
our ability to 'create' as a community.

There's definitely plenty to do, so it would be great to see anyone 
interested in helping with hardware construction or review on the gta03 
list.


Dave

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

Re: New Life in Openmoko Phones

2009-05-18 Thread Dave Ball

Toni Mueller wrote:
 They chose a 100% GPL layout tool, KiCAD 
 (http://en.wikipedia.org/wiki/Kicad), which uses only text-based 
 files 

 This sounds good, but you seem to require a certain minimum version of
 Kicad, right? Checking out from OM and running Lenny's Kicad produced
 less-than-satisfactory results... Either the repo is broken, or the
 software is. Some clarification would be nice to have!
   

I'm currently using 20080825 (latest ubuntu package), and Werner is on 
the svn bleeding edge - both seem to work with the current repo.  It's 
early days, and we are still experimenting with KiCad to work out how 
best to use it collaboratively - so there may be things we need to change.

Come over to the gta03 mailing list and we'll try to help with the 
specific problems you're having.



Dave


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

Crackly Calls and Battery Tips!

2008-12-07 Thread Dave Smith

Hello folks,

Just a few questions really to kick start me being on this list. :-)

I received my FreeRunner about a week or so ago and have just about got 
around to playing with it a bit more and actually using it. It's running 
FDOM based on recommendations, and picked up my Orange SIM and contacts 
without difficulty.

A few issues I have had though:

1) Recipients of phone calls consistently seem to report a buzz / 
crackling during calls made from the FreeRunner. Apparently the buzz is 
particularly prevelant when I stop speaking, whilst I'm speaking the 
line seems to be clear enough - anyone suffered a similar issue and know 
/ suspect it's cause?

2) Battery Life. I was warned by people before getting the phone that 
battery life wasn't great as of yet, and as I understand from what I 
have it is a fairly high priority. However, what do you folks do to 
maximise life out of your battery?
The reason I ask is that with everything (bar GSM) turned off, and the 
phone mostly locked / on standby (30 second timeout for standby and 
blank screen are set up at the moment) I am struggling to get even 12 
hours life out of it.
To give an example from today, where I didn't get chance to glance at 
the phone whilst at work, it went from being fully charged at 08:00 (I 
took it off charge from the Desktop at that point) to being powered down 
and without the juice to startup at 16:30.
So, what do you all do to get the most out of it, and what sort of life 
do you get?

Whilst I can live with the battery as a work in progress, the 
crackliness would be interesting to find out if it's just my unit 
suffering, as it does make using it as my primary phone a little difficult!

Thanks in advance,

Dave

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

Re: The forbidden topic: Glamo OpenGL

2008-11-14 Thread Nishit Dave



 I might have to skip GTA03 since I have just spent a huge 300 Euros for
 a GTA02 :)

 I hope the software stack becomes less of a joke in time for GTA03 or it'll
 be hard to get much new customers...

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

Re: The forbidden topic: Glamo OpenGL

2008-11-14 Thread Nishit Dave

On Fri, Nov 14, 2008 at 7:06 PM, Minh Ha Duong [EMAIL PROTECTED]wrote:

   I hope the software stack becomes less of a joke in time for GTA03
   or it'll be hard to get much new customers...

 Actually I have never read any jokes about the software stack. But it is a
 sign of good mental health when a community is able to make fun of itself.
 Besides, where else would one share jokes about Openmoko ? Open fire !

 Here is a old one: With milestone IV, openmoko-fso-console-image , FSO is
 getting really close to a workable GNUPhone as described at:

 http://notnews.today.com/2008/09/22/free-software-foundation-announces-gnuphone/

 Minh, Wolfgang,

Please don't misunderstand those of us who seem to have nothing but negative
opinions.  We bought the phone because we loved the open source ideal.
However, having committed good money and not having the ability to make
infinite copies of it, those of us who bought it for pure philosophical and
utilitarian purposes, rather than academic or career-oriented ones, have
been definitely disappointed at the never-ending list of problems.

I'd rather not enumerate them.

I believe Rui is very correct in his comment on the commercial aspect of
this effort and the results it has yielded so far.  Here is a great idea
with tremendous potential if you set the right goals and direct your
energies to achieve them.  The open source philosophy has a distinct
disadvantage of people developing just for the joy of it without considering
the harsh realities of economics and consumerism.

You are competing against real products that, if you disregard the
deliberate crippling and proprietary technologies, 'Work'.  A commodity
device should perform its basic functions faultlessly 'Out Of The Box'.  I
hate these cliches as much as you do, but they fit their purpose perfectly.

I am, as other users must probably be, thankful to your team and the
community for the effort you have put in, and the support and spirit you
have shown.  I am glad that the Freerunner is no vapourware.  I am glad the
Back To Basics program was conceived and started.  However, I believe that
the GTA02 is your only chance to make the GTA03 and future versions a
resounding success.

Please concentrate your efforts in curing its shortcomings.  Make it
reliable and usable at least for us semi-geeks.  The path you have followed
allows the boys to use it as their toy, but if that remains its only
purpose, there will be definitely lesser repeat customers for the GTA03,
whenever it comes out, and whatever it turns out to be.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Qtextended] Bluetooth headset

2008-11-10 Thread Nishit Dave

On Wed, Oct 22, 2008 at 2:11 AM, Angus Ainslie [EMAIL PROTECTED]wrote:

 On Tue, Oct 21, 2008 at 11:21 AM, Nishit Dave [EMAIL PROTECTED]wrote:

 Thanks, I was testing the bluetooth connection today and realised that
 once you use the installed script to switch bluetooth off, there is no
 (known or easy) way to restart it except by rebooting the phone.  Any
 feedback on how it behaves with suspend/resume?


 You can restart it. It just doesn't look like its restarted. IIRC the power
 indicator in /sys/bus/platform/devices/neo1973-pm-bt.0/power_on gets
 inverted after a suspend resume cycle.

 If lsusb shows the bluetooth device is there then it's powered on, the sys
 method isn't reliable.

 Hi,

Being tired of switching between the handset, speaker and headset states to
get rid of the echo, buzz and low volume problems, I finally bought a simple
Nokia BH 101 bluetooth headset.

I have been able to pair it with the FR, and can accept and disconnect calls
with its button.  There however was no audio, and on reading the log (and
checking /usr/share/openmoko/scenarios) I found that there was no
gsmbluetooth.state file installed.

I have copied a couple of files linked to on the wiki, but the audio refuses
to work.  Moreover, once the bluetooth headset is connected, I can't get
audio using any other state, and have resorted to rebooting the FR.

Any clue to what might be going wrong, and how to correct it? I use
Qtextended 4.4.2 (binary upgrade) with mwester's 3rd October kernel.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

[Qtextended] Access to Feeds forbidden?

2008-11-07 Thread Nishit Dave

I don't know why, but I suddenly found today that access to
http://qtextended.org/packages/feed/ was forbidden.  Aren't we supposed to
go and see what packages become available?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: QtExtended 4.4.2 : GPRS

On Tue, Nov 4, 2008 at 4:06 AM, Roland Kossel [EMAIL PROTECTED]wrote:

 Hello,

 in which script did you change the dialup number? I have to change the one
 for my provider too but don 't want to use the console to create the
 connection.

 Thanks,
 Roland

 --
 From: [EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED] On Behalf Of Nishit Dave
 Sent: Monday, November 03, 2008 8:15 PM
 To: List for Openmoko community discussion
 Subject: Re: QtExtended 4.4.2 : GPRS

 […]

 I have figured out where the chat script and settings rest, edited the
 script to reflect the correct dialup number *99# for Vodafone Mumbai (not
 the default *99#) and after Bart's advise, have been successfully able
 to *establish* a connection.

 […]

 Look under /home/root/Applications/Network/chat/

There will be a connect-dialupxx (where x's are some numbers) script,
containing the parameters you have entered in the fields you in the gprs
gui.  The last line has the dialup number.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

[Qtextended] Feeds up for 4.4 and 4.4.2

They're up on http://qtextended.org/packages/feed/

But don't rush there just yet, there's nothing in them so far.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Android open sourced

On Tue, Nov 4, 2008 at 6:03 PM, Cédric Berger [EMAIL PROTECTED]wrote:

 On Sun, Nov 2, 2008 at 16:58, Martin Vyšný [EMAIL PROTECTED] wrote:
 
  Port done. Somebody build the images! :-)
 
 http://groups.google.com/group/android-porting/browse_thread/thread/7be8ec2e4dae9fd6#
 
  http://benno.id.au/images/android_on_neo1973.jpg
 
  http://wiki.openmoko.org/wiki/User:Seanmcneil3
 


 Ok, thanks to Sean first image is online !
 http://wiki.openmoko.org/wiki/User:Seanmcneil3

 Seeing as the rootfs image is only 32 MB, what are its current features?
What works and has been tested?  Some screenshots would be nice.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: QtExtended 4.4.2 : GPRS

On Tue, Nov 4, 2008 at 12:32 AM, rakshat hooja [EMAIL PROTECTED] wrote:

 Have you seen this blog for connecting to gprs on qtopia.

 http://johnsu01.livejournal.com/tag/openmoko


I have tried everything I know (which is limited, by the way).  Using
opendns, not using opendns, linking /etc/resolv.conf correctly, using and
not using the official proxy etc.  The best results I got were on pinging,
resolving the ip address of the target but no successful pings.  Traceroute
stops after a couple of hops within my subnet.  Now, GPRS used to work
properly with my old phone, and with OM2008.8 (Services GUI), so I can't
figure out what is wrong now.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: QtExtended 4.4.2 Changes?

On Mon, Nov 3, 2008 at 1:50 PM, Cédric Berger [EMAIL PROTECTED]wrote:

 On Fri, Oct 31, 2008 at 20:30, Lorn Potter [EMAIL PROTECTED] wrote:
 properly or the same problems?
 
  I forgot to add mwesters file system changes to this image.

 Hi,
 Is this image now based on 2008.8 (base testing) ?
 I can see that opkg config files now target 2008.x testing repository.
 Should it be safe to opkg upgrade ?

 And could we know what modifications were made (or not) to standard
 OM rootfs ?

 The opkg files have always targeted OM repositories.  IMHO it would be very
dangerous to try anything from there, because of X.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: QtExtended 4.4.2 Changes?

On Mon, Nov 3, 2008 at 2:14 PM, Cédric Berger [EMAIL PROTECTED]wrote:

 On Mon, Nov 3, 2008 at 09:26, Nishit Dave [EMAIL PROTECTED]
 wrote:
  On Mon, Nov 3, 2008 at 1:50 PM, Cédric Berger [EMAIL PROTECTED]
 
  wrote:
  Is this image now based on 2008.8 (base testing) ?
  I can see that opkg config files now target 2008.x testing repository.
  Should it be safe to opkg upgrade ?
 
  And could we know what modifications were made (or not) to standard
  OM rootfs ?
 
  The opkg files have always targeted OM repositories.  IMHO it would be
 very
  dangerous to try anything from there, because of X.
 

 Well previous qtopia images targeted OM repos, but buildhost ones
 (2007.2). (it was indicated somewhere that first rootfs were made
 starting from a FSO one).
 Since opkg config has been modified to target
 download.openmoko.org/repository/testing/ , I thought that might
 indicate rootfs was at least aligned with OM one...


So far they have been saying it is based on the FSO stack...



 Anyway, it would be good to know what rootfs is really made of.
 And we should be able to install qtextended on a OM rootfs (in fact I
 did on one partition of my phone).


If you are really interested, they have also released the source package and
toolchain.


 X should not interfere here, at least as far as OM qtopia X packages
 are not installed. And I think they are not in OM base testing image,
 and of course neither in Trolltech's image. So opkg upgrade should not
 be dangerous.
 On my partition were I started from a 2008.8 base testing image +
 qtextended (and, before, qtopia 4.3.2), I kept doing opkg
 update/upgrade with not much trouble.

 Did you install anything from there? How effective was upgrade? I did try
checking if opkg update worked, but as the internet connection was faulty at
that time, I couldn't get any results.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: QtExtended 4.4.2 : GPRS

On Mon, Nov 3, 2008 at 5:56 PM, [EMAIL PROTECTED] wrote:

 hi,

 oh...that wasn't my idea...I've tried several howtos for the OM distro
 (none works, perhaps because I don't want to disable my PIN for security
 reasons...) and in one of them (on freeyourphone.de - german community)
 there was that hint, that you've to enter something into that, even if your
 provider doesn't need it ;)

 I needed a proxy to make it work and (in my case) proxy, DNS and Gateway
 are all the same...write an email to your provider to get these
 informations...

 Happy browsing ;)


Oh, I know the details, but thanks anyway.  I have been trying to figure out
if the reason for my inability to get data in or out through gprs relates to
a dns problem (I use opendns) or a routing issue, or something entirely
else.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community Updates/November 2nd, 2008

On Mon, Nov 3, 2008 at 5:56 PM, arne anka [EMAIL PROTECTED] wrote:

  [edit] System-level improvements

 what about the buzzing issue?
 last thing was in august that buzzing could be literally cut off by
 clipping a pin of the headset connector -- or by placing a ferrite pearl
 somewhere.


It is extremely necessary to be solved, imho.  The headset finally works as
it should with qtextended 4.4.2 but it seems to have a terrible buzzing as
reported by the persons I call.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: QtExtended 4.4.2 : GPRS

On Tue, Nov 4, 2008 at 12:32 AM, rakshat hooja [EMAIL PROTECTED] wrote:

 Have you seen this blog for connecting to gprs on qtopia.

 http://johnsu01.livejournal.com/tag/openmoko




 Oh, I know the details, but thanks anyway.  I have been trying to figure
 out if the reason for my inability to get data in or out through gprs
 relates to a dns problem (I use opendns) or a routing issue, or something
 entirely else.

 ___


I have figured out where the chat script and settings rest, edited the
script to reflect the correct dialup number *99# for Vodafone Mumbai (not
the default *99#) and after Bart's advise, have been successfully able
to *establish* a connection.

However, what I am trying to work out is why the browser or anything else
can't connect to the internet.  I tried your advise to use the server
assigned dns, but it is not working.  I'll try and see if it fetches pages
through ip addresses - have been plagued by this in linux.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

[Qtextended] [X-post] The ugly part

2008-11-01 Thread Nishit Dave

Well, I spoke too soon.  There was some gsm buzzing even I could hear on a
call, so I switched on the speaker.  Result: LOUD feedback.  So I inserted
the headphones while the call was on (after apologizing to the other party).
Result: LOUD feedback from the earphones.

I removed the earphones, reverted to the handset, but the other party was
not at all audible.  So I disconnected, and dialed again, only to realize
after some attempts that gsm had stopped working.  The only workable remedy
was to reboot the phone.

I repeat that I have used the binary update for 4.4.2, which means my
original .state files (as fiddled with countless times) must be intact, and
the 'official' .state files may have a better overall results.  However, I
also noticed something else: when I pick up an incoming call on the handset,
first there is an audible squeak like feedback for half a second.

I really wonder what is happening here.  I might have to unwillingly
downgrade the FR with Qtextended from 'almost a daily phone' to 'not at all
a daily phone' if this persists.

Oh, by the way, my interest is in seeing that the FR becomes a daily phone
for *everyone*, except for those who stubbornly refuse to admit it was ever
meant to be one.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Android open sourced

2008-10-28 Thread Nishit Dave

On Tue, Oct 28, 2008 at 12:53 PM, KaZeR [EMAIL PROTECTED] wrote:

  Joerg Lippmann a écrit :

 Am Mittwoch 22 Oktober 2008 schrieb Lorn Potter:


  Jim Morris wrote:


  Lorn Potter wrote:


  Jim Morris wrote:


  Cédric Berger wrote:


  Just because 4.4.1 might be unstable doesn't mean qt extended will
 always be that way. It just means that 4.4.1 was buggier than expected.


  Oh I know it will get better, I was just disappointed it was less stable
 than the previous version.


  We all were. The truth is, 4.4.1 was pushed out before it was ready. But it
 couldn't be helped.


  Wouldn't it be great to release an intermediate version soon, in which the
 most severe UI-bugs are fixed (like the finger-scrolling/selection-Bug or the
 way-to-sensitive-keyboard where it's almost impossible to
 switch to special characters)? I'm quite sure it's just a matter of settings
 as it worked in the former version.


  or the bouncing calypso and the echo fix.. It would be really nice.

  See Lorn J.Potter's mail in support.  Qtextended 4.4.2 may be out
tomorrow and he will try to release Neo images along with it.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Qtextended]Mapping demo maps

On Mon, Oct 27, 2008 at 6:05 PM, kimaidou [EMAIL PROTECTED] wrote:



 Nishit Dave wrote:
 
  It being just a demo, it gives you your co-ordinates, direction and
 speed,
  and of course, an API to develop against.  You can wait for OpenCityMap
 to
  be ported to Qtextended, and use it the same way as you did tangogps.
 

 Hi Dave,
 Do you have some more information on OpenCityMap ? Is there any other
 application working on qtextended (pyroute, navit, etc. )?


In fact, as I learnt later, MappingDemo works fine with google maps by
default, if you have a working gprs (not tested) or wifi (tested)
connection.  Getting gprs to work is however a challenge for me.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: GPS sensitivity

On Mon, Oct 27, 2008 at 9:18 PM, Alastair Johnson [EMAIL PROTECTED]wrote:

 Stefan Monnier wrote:
  The FR is the first device I use with a GPS, so I don't know what's
  considered as normal w.r.t GPS function.  I find that my FR's GPS
  never works inside a building (e.g. at home), and even outside in the
  streets of Montreal, it seems to only be able to get a first fix if I'm
  in a somewhat open area (i.e. not in a street but on a place, in
  a park), and also it seems to rarely if ever be able to get a first fix
  when it's in my pocket.
 
  Is that normal?  My FR does have the capacitor in the µSD slot and it
  has a fairly recent kernel (don't know if that means it has the software
  fix that stops the µSD clock when possible, does it?)

 It's a little tricky to describe 'normal' since the movement of the sats
 gives some inherent variability. Getting the first fix also requires
 significantly more signal than maintaining a fix once acquired, and it
 seems to help being stationary when doing it. I don't know how limited
 the view of the sky is in Montreal, but 'urban canyon' effects have long
 been a problem for GPS systems due to limited view of the sky (can't see
 enough sats) and multiple reflected signals. That said, since the SD
 clocking fixes were added to the kernel I find the Freerunner usually at
 worst as quick as my Garmin Gecko at getting a fix, and substantially
 better at keeping it. The Freerunner will often keep a fix indoors when
 the Gecko hasn't a hope. OTOH the Gecko is hardly state of the art now,
 so expectations may be different.


I recently tested the performance of a Nokia E71 with the FR, while standing
2 feet from a window inside my office building.  Most of the view (line of
sight) was obstructed by another large building 200 ft away, although the
sky over it can be viewed from the said window.

The Nokia got a fix and started to download maps with google maps in 15
seconds.  I was unsuccessful in getting the FR to register a fix at the same
position for greater than 15 minutes, after which the experiment was
stopped. Qtextended 4.4.1, MappingDemo used.  The FR version I use is from
the time when the software fix to the hardware problem was about to be
released.  The FR still takes some minutes to get a fix when in a moving
vehicle, and anywhere inside a building, it is as if it never worked.

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

Re: [Qtextended]Mapping demo maps

On Mon, Oct 27, 2008 at 9:02 PM, Mik Doud [EMAIL PROTECTED] wrote:

 Ah ah, that is great news. One more questions : does it have store the
 tiles in a cache, as Tangogps . When I go hicking, I have no wifi
 connection, and my phone netword provider won't give me free data transfer
 by gprs :D

 The name suggests it is a demo, and like everybody else, they seem to want
you to roll your own fix.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Splash screen during boot

On Tue, Oct 28, 2008 at 2:51 AM, Robin Paulson [EMAIL PROTECTED]wrote:

 2008/10/28 Daniel Benoy [EMAIL PROTECTED]:
  Also, can anyone point me toward any documentation on how to edit the
 splash partition?  I'm thinking perhaps of making a 'If found, please return
 to this guy' type message with gimp.

 download this file:
 http://downloads.openmoko.org/releases/Om2008.9/Om2008.9.splash.gz

 and uncompress it.

 i would imagine (on windows at the moment, can't open gz files),
 there's an image inside it


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

Re: GPS sensitivity

On Mon, Oct 27, 2008 at 10:00 PM, Gora Mohanty [EMAIL PROTECTED] wrote:

 On Mon, 27 Oct 2008 21:30:22 +0530
 Nishit Dave [EMAIL PROTECTED] wrote:
 [...]
  I recently tested the performance of a Nokia E71 with the FR, while
 standing
  2 feet from a window inside my office building.
 [...]

 Um, does the Nokia E71 have assisted GPS (AGPS), as I
 rather suspect it does? If so, you are comparing apples
 and oranges.

 Regards,


Yes, it does, but do you think AGPS reliably works in India?  Google
Mylocation service has a radius of 5km here.  The E71 had pinpointed our
position very accurately, and I doubt if AGPS would have that level of
triangulation accuracy.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Android open sourced

2008-10-23 Thread Nishit Dave

On Wed, Oct 22, 2008 at 8:31 PM, Kishore [EMAIL PROTECTED]wrote:

 On Wednesday 22 Oct 2008 4:38:31 am Lorn Potter wrote:
  Jim Morris wrote:
   Lorn Potter wrote:
   Jim Morris wrote:
   Cédric Berger wrote:
  
   Just because 4.4.1 might be unstable doesn't mean qt extended will
   always be that way. It just means that 4.4.1 was buggier than
 expected.
  
   Oh I know it will get better, I was just disappointed it was less
 stable
   than the previous version.
 
  We all were. The truth is, 4.4.1 was pushed out before it was ready. But
 it
  couldn't be helped.

 Since i got my neo rather recently, i have only tried 4.4.1. Is 4.3 still
 the
 better choice? A couple of days ago i lost my daily use phone (motoming
 A1200)
 and so i now need to use the FR as my daily phone.


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

[Qtextended] Bluetooth headset

2008-10-21 Thread Nishit Dave

Hi List,

Can someone say which bluetooth headset has been found to work the best with
FR?  Any experience in using it with Qtextended, such as how easy it is to
connect, how is the battery drain-out situation, whether it solves the noise
and echo problems etc.?

If your collective wisdom can provide a good pointer, I can go buy one and
start using the FR peacefully.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Qtextended] Bluetooth headset

2008-10-21 Thread Nishit Dave

On Tue, Oct 21, 2008 at 8:58 PM, Paul [EMAIL PROTECTED] wrote:


  Can someone say which bluetooth headset has been found to work the
  best with FR?  Any experience in using it with Qtextended, such as how
  easy it is to connect, how is the battery drain-out situation, whether
  it solves the noise and echo problems etc.?
 
  If your collective wisdom can provide a good pointer, I can go buy one
  and start using the FR peacefully.

 I own a Parrot Minikit, which is recognised by the FR in QTE4.4.1. Note:
 recognised. I can pair it and that's it. When I switch it on later,
 things die and in the log (logread) I see they die because of a kernel
 bug...

 Thanks, I was testing the bluetooth connection today and realised that once
you use the installed script to switch bluetooth off, there is no (known or
easy) way to restart it except by rebooting the phone.  Any feedback on how
it behaves with suspend/resume?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

[Qtextended] Clue, just a clue about everlasting sleep problem

2008-10-21 Thread Nishit Dave

The clock turned from 11:59pm to 0:00 hours of 22 October, and my FR woke up
automatically from suspend.  Is this, and other tricks it may be trying when
humans are asleep, the reason for its battery mysteriously going dead
overnight?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: one day usage of qtextended

2008-10-20 Thread Nishit Dave

On Mon, Oct 20, 2008 at 7:26 PM, Marx [EMAIL PROTECTED] wrote:


 Hi
 I tried qtextended and I really like it. I even got WIFI working using only
 the GUI . And I have no problems with sound during calls.


Good. I do have the old problems - echo and buzzing.  There is no way to
optimize the levels.  The echo removal or suppression (?) patch recently
posted may or may not apply to qtextended, but it did certainly create new
problems for me, so I removed it.


 But there are also some problems. Mostly the same as Franky described.

 That is with using suspend? I charged the phone fully and turned the
 suspend
 off. After about 8 or 9 hours (I didn't do anything with the phone during
 that time, except one wake-up alarm) it said that the battery is extremely
 low.


The battery lasts *half of the time* overnight if you turn the alarm off
completely.  It is useless as it is now anyway.  However, at least once in
every three nights, the battery will mysteriously drain itself.





 Franky Van Liedekerke wrote:
 
  - echo issue: with my alsa state file, no issue anymore
 
 No problems, even without updating the alsa state file.


 You must be really lucky

My phone didn't wake up from suspend when a call came in. So I can't use the
 suspend. Is there any fix or workaround for this?


Mine does, so there could be differences in each user's experience.  I hope
you are using the latest version of 4.4.1 (2008/10/3 aka 2008/10/6).  I
think the un-updated version had solved the echo problem but the resume
problem persisted, and it got reversed with the update.



 And some more problems and questions:
 - If suspended, the wake-up alarm goes off too late (It seems the alarm
 starts as many minutes too late how many minutes before the expected alarm
 time I set it. So if i set the alarm at 12:00 to start at 12:05 then it
 actually starts 12:10 and if I set it at 12:00 to start at 12:30 then it
 starts 13:00 etc). If not suspended, it goes off at the right time.


Every time the phone's battery is drained, the clock resets itself to what
is probably GMT, but the timezone is static!  DO NOT rely on the
Freerunner's (QTX) alarm to work for anything that is important.  It only
rang once for me, and that too after nearly 12 hours, after a reboot.


 - The arrow keys on the on-screen keyboard don't work when using the
 Terminal application. So I can't go up in the bash history.
 - If a call arrives and I select Send busy tone it registers two missed
 calls.


Actually, about half of all calls received are registered twice.  New
messages result into multiplication of messages already received.



 - First it didn't show any of my SIM contacts. They appeared after I
 selected some other configuration from Server Widgets. And now they are
 still here, even after I switched back to Default QT Extended.


I can't see some of the new contacts I imported.  They had not been imported
the first time, but the latest import seemed to work till the phone got
switched off overnight.



 - As Franky said, after every call it plays a weird and loud sound. It's
 really annoying. What is it? And why? Can I disable it?


It is random.  On some days, it rings.  It doesn't on some days.  Pick your
choice.


 - Same problems with mp3 playback as Franky described.
 - So it's impossible to install any extra software? The default feed url
 (http://qtextended.org/packages/feed/4.4.1/neo) shows 404 and


It is not there yet.  Lorn has said it would be available soon, and I am
dying to see if it fixes the sound problem and offers some usable packages.


 http://qtextended.org/packages/feed/4.3.2/neo just doesn't show any
 packages
 in the package manager, although it shows them when viewing this url in a
 web browser.


Don't try those packages!


 - Can I manually add something in the Applications menu? For example a
 short
 cut to a bash script.
 - What video formats can the Media Player play? I tried ogg, xvid and 3gp -
 didn't play them.


None, as of now, I think.


 - It's impossible to delete a file using a GUI?


You need a file manager.  The only one available is in source code, and I
don't know if it compiles for Qtextended.


 - When editing notes using the Notes application it most times doesn't save
 the changes when clicking Back. But few times it did. I don't know what I
 did differently these times.


cf. comment about contacts.



 But otherwise it's quite good and I can (almost) use my Freerunner as an
 everyday phone.


My thoughts too! I am using it as an everyday phone in any case.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Back to the basics: improving user experience


 Prioritized:
 1 - Solve the call quality problems (echo, buzzing, volume) for 99% of
 the users.
 2 - Solve the illume resume problems. They have been talked about over
 and over, but unfortunately the information is scattered and
 imprecise. the tickets themselves have misleading info (I should know,
 I helped confuse you...), so maybe this deserves a new single ticket,
 where everyone contributes with more exact information;
 3 - Get the wifi driver corrected, so that it does not create link
 association and stability and problems;
 4 - Finish/validate implementation of the networking stack (all the
 way up to resolv.conf and friends);
 5 - Merge the GPRS muxer into the stable distro, so that it works out
 of the box;
 6 - Integrate the main applications with the power management: if QPE
 wants to index the whole friggin' filesystem right after boot, then
 give it time to do so before going into suspend; if you don't, it just
 bogs down the CPU for many suspend/resume cycles, creating all sorts
 of problems, and we don't know what is going on...
 7 - Accelerate Qt applications - they respond so slowly that a normal
 user will shoot itself in the foot everyday (i.e. pushing the Answer
 button twice because it didn't appear to respond, effectively killing
 the call; or taking the phone to the ear after pushing Answer and
 having it rind loudly one last time in the ear);
 8 - Work with the people of FDOM to integrate the best workarounds and
 hacks - they did the work already, just use it.
 9 - Get all the bluetooth support organized out-of-the-box. I haven't
 played with it in a long time, but it looked like black voodoo to get
 a simple pairing and OBEX exchange going... forget about PAN!...
 10 - Put a speaker button on the dialer app. This is my only GUI
 desire for now...

 +5, Insightful

Meaning, I second, third and fourth the recommendation.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [qtextended] new release 4.4.3

On Thu, Oct 16, 2008 at 1:40 PM, Cédric Berger [EMAIL PROTECTED]wrote:

 oups, sorry it is 4.3.3 ! :-p I'll check it closer before I update the
 correct partition on my phone...

 :(

For a moment, my hopes had gone soaring up, like the stock markets of yore.
Now they are down to a better correlation with the trend.

Still waiting for Lorn to share some good news.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMooCow 0.1

On Thu, Oct 16, 2008 at 12:37 PM, David Samblas 
[EMAIL PROTECTED] wrote:

 a better demostation of the toy :)
 LOL
 http://es.youtube.com/watch?v=CHw9EOVwKnk

 El mié, 15-10-2008 a las 17:38 +0200, Xavier Bestel escribió:
  As far as I understand, it should mimick that toy:
  http://www.youtube.com/watch?v=2GQ126DUsyQNR=1
 
Xav
 
  On Wed, 2008-10-15 at 17:19 +0200, Thomas Bertani wrote:
   sorry I can't understand what this software is. is there a video or
   image aviable?
  
   2008/10/15 Joseph Reeves [EMAIL PROTECTED]:
I just loaded this onto a colleagues phone - he said he wanted a cat
and suggested the name OpenMeowKo
   
:)
   
   
   
2008/10/14 Thomas White [EMAIL PROTECTED]:
I'm pleased to be able to announce version 0.1 of my advanced
accelerometer and audio framework testing system, OpenMooCow.
Available from 
http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/http://www.srcf.ucam.org/%7Etaw27/openmoko/openmoocow/
   
When installed and run, OpenMooCow displays an artistic rendition of
a fine specimen of Friesian dairy cattle.  Invert the device and
 return
it to an upright orientation to experience the pinnacle of audio
rendering kwality.
   
The sound effect can be altered by putting a suitable WAV file
in /usr/share/openmoocow/moo.wav.  A credit is due to Chris
 Hendricks
who is the author of the original sound file (obtained from
www.flashkit.com).
   
Comments/abuse to this address.
   
Tom


We want Teh Lightsaberz!!
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Echo issue on OM2008.08 solved

On Wed, Oct 15, 2008 at 11:45 PM, Marco Trevisan (Treviño) [EMAIL PROTECTED]
 wrote:

 Matthias Apitz wrote:
  El día Wednesday, October 15, 2008 a las 08:18:40AM +0200, Marco
 Trevisan (Treviño) escribió:
 
  Here you are [1]. It includes also the mwester fix for re-registering
  network and my workaround for GSM firmware crash. I hope it won't have
  any incompatibility with your installed Qtopia...
 
  [1]
 
 http://downloads.tuxfamily.org/3v1deb/openmoko/libficgta01vendor-echo-cancellation.so.tar.gz
 
  Thanks for this.
  the outgoing RING tone nearly killed my ear; with 111 for value.[01] it
 is
  fine, but with the above described noise; what is your gsmhandset.state
 file for
  this? thx again

 I'm pratically using the standard gsmhandset.state... I've to say that
 in my experience in noisy places the main speaker volume (for ringing)
 isn't so loud...


I inserted the file in /usr/Trolltech/Qtopia/plugins/phonevendors/ on
qtextended.  No change in the echo / buzzing problem for me, but then I
started to have problems with the phone going on unrecoverable standby, and
loss of audio (speaker, mic and ringtone, all together) when it could be
woken up.

I have removed the file again, because I don't know if it was meant for
qtextended in the first place.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Echo issue on OM2008.08 solved

2008-10-15 Thread Nishit Dave

On Wed, Oct 15, 2008 at 11:48 AM, Marco Trevisan (Treviño) [EMAIL PROTECTED]
wrote:

Matthias Apitz ha scritto:
El día Wednesday, October 15, 2008 a las 02:25:04AM +0200, Marco
Trevisan (Treviño) escribió:

Marco Trevisan (Treviño) wrote:
Lorn Potter wrote:
Hello,

I finally found a place in the qtopia sources where I could put code
for
activating the
echo suppression for every incoming/outgoing call.
I'm quite sure that experienced qtopia programmers would find a
better
place for it.
A better place for stuff needed for a particular modem, would be in
the
phone vendor plugin. That's what its there for. Not to defray this
patch, but this is very calypso specific, and not part of the GSM
spec.
(although any other modem would most likely just spit out an error)
I agree... That's why some weeks ago I started something like that but
I've not pushed out the code yet... I'll attach as soon as I can.
Ok, a first implementation is now at ticket #1267

May I ask you kindly for a binary (shared lib) for those of us who at
the moment don't compile from SVN; thanks in advance;

matthias

Here you are [1]. It includes also the mwester fix for re-registering
network and my workaround for GSM firmware crash. I hope it won't have
any incompatibility with your installed Qtopia...

[1]

http://downloads.tuxfamily.org/3v1deb/openmoko/libficgta01vendor-echo-cancellation.so.tar.gz

Can I try it with qtextended? Instructions for installation?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Qt-Extended] Messenger bugs?

2008-10-15 Thread Nishit Dave

On Wed, Oct 15, 2008 at 10:47 AM, Matthew Lane [EMAIL PROTECTED] wrote:

 Hey,

 I'm using the new qt-extended (4.4 I think).  I'm getting strange
 problems, especially with the messenger.  It always says my SMS is full,
 and when receiving a new text it displays it between 5-15ish times.
 Also, scrolling doesn't stop at the top of units, it continues into
 blank area, and then when I let my finger up, it jumps to the top-most
 unit (if I scrolled too far).  Is anyone else receiving these errors?


Common problem, oft reported.  There are no updates yet, so we will have to
see if its solved when they are released.


 Also, I can't seem to get a WEP access point on WIFI.


More information needed about nature of problem and circumstances.  I can
connect to my WPA network easily.  You can try putting ethernet offline when
you attempt the wifi connection and see.  It resolves some default route
issues that might otherwise crop up.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Introducing http://www.opkg.org

2008-10-14 Thread Nishit Dave

On Mon, Oct 13, 2008 at 11:48 PM, Tobias Kündig [EMAIL PROTECTED]wrote:

 Thank you for reporting this bug.
 It has been fixed.

 Dear Tobias,

Regardless of many contrarian and critical opinions posted here, I think you
have done a great job in creating the site and giving people a quick way to
look up available applications.  You own the opkg.com domain, and if someone
has a problem with it, they should have thought of buying it up first.  I am
sure of your intentions, and I know they are good.

If people bother you too much about fragmenting and possible malware and
such, you can just provide two links to each software: one to the package on
your site, and one to the 'official' repository.  You can also put in a
disclaimer, and tell the paranoid to use the official package.

Do not be discouraged by negative opinions.  The most marginal are usually
the most strident.  And for sake of ease, please put the category list on
top.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Echo issue on OM2008.08 solved

2008-10-14 Thread Nishit Dave

On Tue, Oct 14, 2008 at 2:02 AM, Daniel Nöthen [EMAIL PROTECTED] wrote:

 Lorn Potter wrote:
  A better place for stuff needed for a particular modem, would be in the
  phone vendor plugin. That's what its there for. Not to defray this
  patch, but this is very calypso specific, and not part of the GSM spec.
  (although any other modem would most likely just spit out an error)
 
 
 
 Yes, I assumed something like that.
 I've looked at the ficgta01 phonevendor sources but didn't find
 a method that is called on every initiated call where I could
 put those two lines.
 This patch is only meant as a temporary bugfix until some more
 experienced qtopia programmer (maybe you? ;)) finds a better
 place for the echo suppression lines.


Whatever you and Lorn decide to do, when can we clueless users expect to
find it in updates for qtextended?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Echo issue on OM2008.08 solved

2008-10-14 Thread Nishit Dave

On Tue, Oct 14, 2008 at 12:58 PM, Cédric Berger
[EMAIL PROTECTED]wrote:

 On Tue, Oct 14, 2008 at 09:07, Nishit Dave
  Whatever you and Lorn decide to do, when can we clueless users expect to
  find it in updates for qtextended?
 

 Is it not already in ? Looking at qtextended logs, to track my roaming
 problem, I could see the AT%N0187 command passed to the modem.



 Also I experience almost no buzz sound since using qtextended (with
 mwester kernel). But I do not know if it is due to sound levels being
 different, or other settings...

 Well in fact I can't test anymore just now because my qtextended do
 not start anymore... stuck on PIN screen (even if PIN code not
 activated...). And I have the same problem on 2 separate partitions !
 (second is with 2008.8 base rootfs + qtextended)

 I use the 2008/10/03 update, which has reintroduced the echo problem as I
believe, but only Lorn can confirm that.  I get a severe echoing / buzzing
problem as soon as I raise the speaker / mono speaker / mic2 volumes in my
gsmhandset.state file (which I am about to re-edit right now).
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Editing text files

On Mon, Oct 13, 2008 at 10:18 AM, Joel Newkirk [EMAIL PROTECTED]wrote:

 On Sun, 12 Oct 2008 22:21:06 -0400, Stefan Monnier
 [EMAIL PROTECTED] wrote:
  I use Raster's Illume keyboard, and select the Terminal layout, and most
  of
 
  I guess it's the part that I don't get.  What means Raster's Illume
  keyboard and how do I select another keyboard?
  I've read the Wiki about it, but I must be too dense to understand it;
  it always seems to refer to a system that looks different from mine.
  I have installed 2008.9 with few changes as of now.
  I guess I'll try again,
 
 
  Stefan

 try:
 opkg install illume-config illume-config-illume

 Should net you the 'qwerty' icon on the left in the Top Shelf.  When
 selected it will open Raster's Illume keyboard. (which should be the
 default keyboard at this point, though you may need to restart - at least
 xserver-nodm - and it WILL occasionally revert to the Qtopia keyboard,
 particularly when changes or updates to something Qtopia are made.  if it
 shows the predictive keyboard (Raster's version) then tab the icon at the
 top-right of the keyboard and select 'Terminal' from the list.

 Back up the 89qtopia before updating wholesale, and replace it when the
keyboards fail.  Less pain, more gain.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Qtextended] Kernel modules from mwester

On Thu, Oct 9, 2008 at 5:04 PM, Andy Green [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Nishit Dave wrote:
  Hi,
 
  I am using the current kernel for qtexended on FR available from
  mwester.  I also downloaded the minimal kernel module set from
  http://moko.mwester.net/dl.html#kernels.
 
  The version of the module set and the kernel seems to be matching, but
  after extracting the modules on my system, I now have two directories
  under /lib/modules (as I had expected): 2.6.24 (the original kernel) and
  2.6.24mw-g291a9d50 (the minimal module set).

 A given kernel is going to look for its modules down only one path.  We
 have been using these build-specific paths in the git build system for
 some time, they eliminate the problem that incorrect modules get loaded
 into kernel space when you change the main kernel binary.  I dunno what
 our packaging side is doing about modules because it's not discussed
 anywhere that I read.

 Anyway it's good news mwester is using the same system, it just means
 that you only actually need the dir that matches the build stamp of the
 monolithic kernel you are using; any other dirs left lying around don't
 make any trouble except waste space if you will never revert to the
 kernel that matches them.

 Update:

After deleting the 2.6.24mw-g291a9d50 branch from under /lib/modules and
rebooting, I found that the original kernel looks for modules under it (the
deleted branch).  So it is useful, after all.

I don't know what additional utility it provides, though.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Editing text files

On Mon, Oct 13, 2008 at 6:15 PM, Stefan Monnier [EMAIL PROTECTED]wrote:

  Nishit == Nishit Dave
 [EMAIL PROTECTED] Back up the 89qtopia
 before updating wholesale, and replace it when the
  keyboards fail.  Less pain, more gain.

 I have no idea what you're talking about.  What wholesale update are
 you referring to?  What failure of keyboards?  What do you gain?
 Could you expand a little for me poor novice here?


 What I meant was that after you install illume-config-illume and set up the
new keyboards [1], you should back up your 89qtopia file from
/etc/X11/Xsession.d/

When you go for opkg update  upgrade, and if that upgrades illume for you,
it could result into your new keyboards disappearing.

Doing things mentioned here [2] to install a good utility for gprs etc. and
then updating the system may also undo some modifications, so backing up
89qtopia after [2] is a good idea.  You can have the qpe process disappear,
and the dialers, messaging etc. fail after updates.

It will help you rescue the setup when you restore it.  You will gain more
insights with actual experience.

[1] http://wiki.openmoko.org/wiki/Keyboard_Debate
[2]
http://wiki.openmoko.org/wiki/Manually_using_GPRS#Option_1:_With_GSM_multiplexing_and_with_a_GUI
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [QtExtended] Snapshots? Yes, please!

On Mon, Oct 13, 2008 at 2:54 PM, MartinG [EMAIL PROTECTED] wrote:

 On Thu, Oct 9, 2008 at 1:12 PM, Nishit Dave [EMAIL PROTECTED]
 wrote:
  On Thu, Oct 9, 2008 at 3:57 PM, MartinG [EMAIL PROTECTED] wrote:
  Yes: Setup, Internet, Options, New, GPRS, Account name, APN.
  I need to investigate more myself.
 
  I rather meant asking how you managed to enter the APN, because on my
 phone,
  that option is unclickable / disabled and does not respond to the stylus.
  I
  can't even Tab to it with the keyboard, as the keyboard forcibly
 disappears
  when you tab across from account name to connection type.
 
  Do you specify it in any of the configuration files in /etc/ppp or
  etc/ppp/peers?

 I haven't touched any files in /etc/ at all -- for me the APN input
 field was just working. But I haven't managed to get online yet, as
 it seems the pppd stuff isn't fully configured.

 I'll let you know if I make any progress.

 -MartinG

 PS. What I said in an earlier post about the web browser not having a
 Go button was just wrong - indeed it has got one. Sorry about that!

 I finally was able to enter the APN. Hadn't chanced on the 'magic' tap
location earlier.  However, still no cigar. I don't know if the phone can
connect in the first place.

I also want to know which number is being dialed, but there seems to be no
clue
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: QtExtended call forwarding