Re: [QtExtended] Latest and greatest, progress mail 12

[Lorn Potter]

Goffi wrote:
> Thank you for all the great work ! I compile your git branch regularly and it 
> works very well, it's my main distro for daily telephony (I keep an eye on 
> OM2009 too ;) ).
> 
> I have some questions/remarks:
> 
> - I didn't found any option for sms delivery receipt, will QTEi have this 
> option in the future ? It would be really handy :)
> 
> - There is a french dictionary in the sources, but not activable during the 
> configure (only en_US is available). I cheat by copying french dict on en_US 
> files, but an option for other languages would be greatly appreciated (phone 
> key are IMHO unusable with a foreigner dictionary).

This would require someone to translate the ~3000 strings in Qtopia, and 
then configure it with that language enabled and then install that language.

> It would be very perfect to have the choice of the dict language when we use 
> phone keys.

Currently there is no way to do this, other than installing a new 
language and using it.
> 
> - I my knowledge, it is not possible to change the volume during a call, it 
> would be nice to add a slider.

There is, but it is rather difficult. (during a call) Settings->Call 
Options->Call Volume. But it doesn't currently remember this setting.

> I found the sound a little weak in the speaker, it's difficult to hear 
> somebody 
> in a noisy environment, is it possible to do a software boost ? I have 
> already 
> put 127 in control 4 of  /usr/share/openmoko/scenarios/gsmhandset.state, but 
> it's not enough.
> 
> - The alarm don't seem to awake the phone in deep sleep (need some tests: I 
> will try again and fill a bug report)
> 

known bug. patches welcome. :)

> - sometime when I look into my sim's contacts, there is nothing (but 
> everything is ok most of time)
> 
> - I have followed manually the instructions of the script when I have 
> installed my own compiled QTEi version, but for the bluetooth everything is 
> commented, and I can't install anything related to bluetooth with opkg ("opkg 
> search bluetooth" give nothing, "opkg install bluez-audio" says there is not 
> package of this name), so my BT is not working :( .
> It's not a big deal since I have usb cable, but I'd like to save my contacts, 
> and sending vcards via BT is a solution.
> 
> Anyway everything is very usable, again thanks to you and the other devs for 
> all the work.
> I have no time for the moment, but I'd like to install a dev environment to 
> give some help in the future :).
> 
> Cheers,
> Goffi
> 
> On lundi 1 juin 2009 21:02:29 Franky Van Liedekerke wrote:
>> (install instructions and script updated on 2090601: see below)
>>
>> It's been a while, but we haven't been sleeping :-)
>>
>> New website:
>> 
>> We have a new website now, thanks to Fale: http://www.qtmoko.org
>> There you can find all the latest changes, report bugs, etc ...
>>
>> IRC channel:
>> 
>> For those wanting to talk: on irc.freenode.net, channel #qtopia is open
>> for business.
>>
>> Things solved/added/changed:
>> 
>> See http://www.qtmoko.org/wiki/Change_log
>> See http://github.com/liedekef/qtmoko/commits/master for the changelog
>> in detail
>>
>> Problems found (more like small nuisances now):
>> ===
>> See http://www.qtmoko.org
>> - if you set the time back to something in the past, the clock service
>>   crashes and you need to restart qtextended if you want to use the
>>   clock again
>> - bluetooth is not working totally ok, only after initial boot it
>>   works, not after suspend/resume. Seems to be kernel/bluez3 version
>>   combo issue ... After suspend/resume bluetooth seems to work, but
>>   receiving files for sure doesn't.
>> - if you try to delete the "Wireless Lan", the system crashes ... cool
>>   huh, a crashed phone? So for now: don't do it :-)
>> - slow building up of the Contacts, because of all the sql queries for
>>   a*, b*, c*, ...
>>
>> Install instructions:
>> =
>> download the script
>> http://www.e-dynamics.be/openmoko/qtmoko_install.sh , read the
>> comments at the top and then execute the script on your openmoko (after
>> having flashed the device and made sure internet works).
>> The script has 2 options: "install" or "update". An update will just
>> download the tgz file and replace your current qtmoko with it.
>>
>> For those who just want to replace their existing qtmoko manually,
>> here's the link: http://www.e-dynamics.be/openmoko/qte_20090601.tgz .
>>
>> Enjoy!
>>
>> Franky
>>
>> ___
>> 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
> 


-- 
Lorn Potter, Software Engineer, Qt Software R & D, Nokia

Re: Fundamental Qi question

[roguemoko]

On 1/06/2009 9:14 PM, arne anka wrote:
>> No, Qi doesn't support jffs2.
>
> bummer.
> how's that -- it makes qi unusable for everybody using the internal flash
> as "primary device" and forces to boot from sd card.
> not sensible imo.

I booted from flash and SD card for quite some time. Your information is 
wrong and does not contribute to this thread in any way. Unless you have 
tested this, you are just spreading FUD and creating unnecessary email 
congestion ;)

Sarton

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

Re: [QtExtended] Latest and greatest, progress mail 12

[Jim Morris]

Franky Van Liedekerke wrote:
> (install instructions and script updated on 2090601: see below)
> 
> It's been a while, but we haven't been sleeping :-)

FYI...

I followed the instructions, and ran the script from ssh using the install 
option and it runs out of 
memory...

lib/fonts/dejavu_sans_condensed_36_75.qpf2
lib/fonts/dejavu_sans_condensed_10_50.qpf2
lib/fonts/dejavu_sans_condensed_21_75.qpf2
tar: write error: No space left on device

I'll do the install manually for now.

Thanks for your work on this.


-- 
Jim Morris, http://blog.wolfman.com

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

Re: [QtExtended] Latest and greatest, progress mail 12

[Franky Van Liedekerke]

Hi Goffi,

On Mon, 1 Jun 2009 23:22:40 +0200
Goffi  wrote:

> - I my knowledge, it is not possible to change the volume during a
> call, it would be nice to add a slider.
> I found the sound a little weak in the speaker, it's difficult to
> hear somebody in a noisy environment, is it possible to do a software
> boost ? I have already put 127 in control 4
> of  /usr/share/openmoko/scenarios/gsmhandset.state, but it's not
> enough.

well, there exists a patch for this, I need to take a look at it ...
for now, just boost the volume in the settings

> - The alarm don't seem to awake the phone in deep sleep (need some
> tests: I will try again and fill a bug report)

since you do this manually: you need to install the atd package, that's
responsible for waking up the phone ... see the install script for this.
O btw: I again disabled deep sleep, it is now again normal "sleep" :-)

Franky

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

Re: [QtExtended] Latest and greatest, progress mail 12

[Fabio Locati]

Thank you Goffi :)
About the BT: is all commented because qtmoko does not support bluez4
;). We are going to work on it ;).

On Mon, Jun 1, 2009 at 11:22 PM, Goffi  wrote:
> Thank you for all the great work ! I compile your git branch regularly and it
> works very well, it's my main distro for daily telephony (I keep an eye on
> OM2009 too ;) ).
>
> I have some questions/remarks:
>
> - I didn't found any option for sms delivery receipt, will QTEi have this
> option in the future ? It would be really handy :)
>
> - There is a french dictionary in the sources, but not activable during the
> configure (only en_US is available). I cheat by copying french dict on en_US
> files, but an option for other languages would be greatly appreciated (phone
> key are IMHO unusable with a foreigner dictionary).
> It would be very perfect to have the choice of the dict language when we use
> phone keys.
>
> - I my knowledge, it is not possible to change the volume during a call, it
> would be nice to add a slider.
> I found the sound a little weak in the speaker, it's difficult to hear 
> somebody
> in a noisy environment, is it possible to do a software boost ? I have already
> put 127 in control 4 of  /usr/share/openmoko/scenarios/gsmhandset.state, but
> it's not enough.
>
> - The alarm don't seem to awake the phone in deep sleep (need some tests: I
> will try again and fill a bug report)
>
> - sometime when I look into my sim's contacts, there is nothing (but
> everything is ok most of time)
>
> - I have followed manually the instructions of the script when I have
> installed my own compiled QTEi version, but for the bluetooth everything is
> commented, and I can't install anything related to bluetooth with opkg ("opkg
> search bluetooth" give nothing, "opkg install bluez-audio" says there is not
> package of this name), so my BT is not working :( .
> It's not a big deal since I have usb cable, but I'd like to save my contacts,
> and sending vcards via BT is a solution.
>
> Anyway everything is very usable, again thanks to you and the other devs for
> all the work.
> I have no time for the moment, but I'd like to install a dev environment to
> give some help in the future :).
>
> Cheers,
> Goffi
>
> On lundi 1 juin 2009 21:02:29 Franky Van Liedekerke wrote:
>> (install instructions and script updated on 2090601: see below)
>>
>> It's been a while, but we haven't been sleeping :-)
>>
>> New website:
>> 
>> We have a new website now, thanks to Fale: http://www.qtmoko.org
>> There you can find all the latest changes, report bugs, etc ...
>>
>> IRC channel:
>> 
>> For those wanting to talk: on irc.freenode.net, channel #qtopia is open
>> for business.
>>
>> Things solved/added/changed:
>> 
>> See http://www.qtmoko.org/wiki/Change_log
>> See http://github.com/liedekef/qtmoko/commits/master for the changelog
>> in detail
>>
>> Problems found (more like small nuisances now):
>> ===
>> See http://www.qtmoko.org
>> - if you set the time back to something in the past, the clock service
>>   crashes and you need to restart qtextended if you want to use the
>>   clock again
>> - bluetooth is not working totally ok, only after initial boot it
>>   works, not after suspend/resume. Seems to be kernel/bluez3 version
>>   combo issue ... After suspend/resume bluetooth seems to work, but
>>   receiving files for sure doesn't.
>> - if you try to delete the "Wireless Lan", the system crashes ... cool
>>   huh, a crashed phone? So for now: don't do it :-)
>> - slow building up of the Contacts, because of all the sql queries for
>>   a*, b*, c*, ...
>>
>> Install instructions:
>> =
>> download the script
>> http://www.e-dynamics.be/openmoko/qtmoko_install.sh , read the
>> comments at the top and then execute the script on your openmoko (after
>> having flashed the device and made sure internet works).
>> The script has 2 options: "install" or "update". An update will just
>> download the tgz file and replace your current qtmoko with it.
>>
>> For those who just want to replace their existing qtmoko manually,
>> here's the link: http://www.e-dynamics.be/openmoko/qte_20090601.tgz .
>>
>> Enjoy!
>>
>> Franky
>>
>> ___
>> 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
>



-- 
Fabio A Locati

Home: Segrate, Milan, Italy (GMT +1)
Phone: +39-328-3799681
MSN/Jabber/E-Mail: fabioloc...@gmail.com

PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334

Envolved in: KDE, OpenStreetMap, Ubuntu, Wikimedia
Sent from Milano, Lombardia, Italia

___
Openmoko community mailing list
community@lists.openmoko.org
ht

Re: [QtExtended] Latest and greatest, progress mail 12

[Goffi]

Thank you for all the great work ! I compile your git branch regularly and it 
works very well, it's my main distro for daily telephony (I keep an eye on 
OM2009 too ;) ).

I have some questions/remarks:

- I didn't found any option for sms delivery receipt, will QTEi have this 
option in the future ? It would be really handy :)

- There is a french dictionary in the sources, but not activable during the 
configure (only en_US is available). I cheat by copying french dict on en_US 
files, but an option for other languages would be greatly appreciated (phone 
key are IMHO unusable with a foreigner dictionary).
It would be very perfect to have the choice of the dict language when we use 
phone keys.

- I my knowledge, it is not possible to change the volume during a call, it 
would be nice to add a slider.
I found the sound a little weak in the speaker, it's difficult to hear somebody 
in a noisy environment, is it possible to do a software boost ? I have already 
put 127 in control 4 of  /usr/share/openmoko/scenarios/gsmhandset.state, but 
it's not enough.

- The alarm don't seem to awake the phone in deep sleep (need some tests: I 
will try again and fill a bug report)

- sometime when I look into my sim's contacts, there is nothing (but 
everything is ok most of time)

- I have followed manually the instructions of the script when I have 
installed my own compiled QTEi version, but for the bluetooth everything is 
commented, and I can't install anything related to bluetooth with opkg ("opkg 
search bluetooth" give nothing, "opkg install bluez-audio" says there is not 
package of this name), so my BT is not working :( .
It's not a big deal since I have usb cable, but I'd like to save my contacts, 
and sending vcards via BT is a solution.

Anyway everything is very usable, again thanks to you and the other devs for 
all the work.
I have no time for the moment, but I'd like to install a dev environment to 
give some help in the future :).

Cheers,
Goffi

On lundi 1 juin 2009 21:02:29 Franky Van Liedekerke wrote:
> (install instructions and script updated on 2090601: see below)
>
> It's been a while, but we haven't been sleeping :-)
>
> New website:
> 
> We have a new website now, thanks to Fale: http://www.qtmoko.org
> There you can find all the latest changes, report bugs, etc ...
>
> IRC channel:
> 
> For those wanting to talk: on irc.freenode.net, channel #qtopia is open
> for business.
>
> Things solved/added/changed:
> 
> See http://www.qtmoko.org/wiki/Change_log
> See http://github.com/liedekef/qtmoko/commits/master for the changelog
> in detail
>
> Problems found (more like small nuisances now):
> ===
> See http://www.qtmoko.org
> - if you set the time back to something in the past, the clock service
>   crashes and you need to restart qtextended if you want to use the
>   clock again
> - bluetooth is not working totally ok, only after initial boot it
>   works, not after suspend/resume. Seems to be kernel/bluez3 version
>   combo issue ... After suspend/resume bluetooth seems to work, but
>   receiving files for sure doesn't.
> - if you try to delete the "Wireless Lan", the system crashes ... cool
>   huh, a crashed phone? So for now: don't do it :-)
> - slow building up of the Contacts, because of all the sql queries for
>   a*, b*, c*, ...
>
> Install instructions:
> =
> download the script
> http://www.e-dynamics.be/openmoko/qtmoko_install.sh , read the
> comments at the top and then execute the script on your openmoko (after
> having flashed the device and made sure internet works).
> The script has 2 options: "install" or "update". An update will just
> download the tgz file and replace your current qtmoko with it.
>
> For those who just want to replace their existing qtmoko manually,
> here's the link: http://www.e-dynamics.be/openmoko/qte_20090601.tgz .
>
> Enjoy!
>
> Franky
>
> ___
> 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

[debian] navit_0.1.0+svn-2301_armel.deb

[arne anka]

new navit up at
> http://www.ginguppin.de/node/26

i tweaked the config opts further, adding to the default opts of   
debain/rules

CCFLAGS="-march=armv4t -mtune=arm920t" --enable-avoid-float  
--disable-garmin --disable-samplemap --disable-postgresql  
--disable-graphics-opengl --disable-graphics-win32 --disable-gui-win32  
--disable-vehicle-demo --disable-vehicle-wince  
--disable-graphics-qt-qpainter --enable-graphics-gtk-drawing-area  
--disable-hildon --disable-speech-cmdline  
--disable-speech-speech-dispatcher --disable-vehicle-demo  
--disable-vehicle-wince --disable-vehicle-gypsy --enable-graphics-gd  
--disable-threads

although i am not sure, if everyone ist necessary, at least i got the  
impression that it is far more responsive now (compared to 2279 which  
yesterday virtually froze, eating 100% cpu and excuting random actions,  
slightly related to my tapping on the screen -- leaving on my own with a  
bike in a foreign forrest ...)

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

Re: How to fix a broken AUX button ?

[Rafael Campos]

On Tue, May 26, 2009 at 1:55 PM, Joerg Reisenweber  wrote:
> Am Mo  25. Mai 2009 schrieb Philippe Lhardy:
>> Hi,
>>
>> I am looking for a way to fix my Neo FreeRunner that felt badly on the
> floor.
>> AUX button was not soldered anymore and i definitely broke the button
>> by trying to glue it.
>
> FWIW:
> SW1501,SW1701.
> SWITCH 4.7*3.5*1.6 SIDE PUSH SMT TYPE 4 PIN EVQPUD02K
> PANASONIC FOE GSM LR
>
>
> cheers
> jOERG
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>

I fixed  one without problems. But i was lucky to don't need to bought one.

I get the reference, in case it would be necessary ;)

I like to have some references like this for possible repair components.
Do you have a BOM in some place jOERG?

cheers

-- 
___
Rafael Campos
o0 Methril 0o
http://openblog.methril.net/

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

[navit] Crash with sdl + internal gui

[Marcel]

Hello,

I'm trying to use navit with sdl driver and the internal gui (something 
told me thats faster, don't know where I got that from). gtk_drawing_area 
works fine, so in principle everything's fine. Once I change the driver to 
"sdl", navit crashes like this: http://pastebin.ca/1443950
Do I need some additional library? The backtrace isn't too helpful for me.
sdl-image is installed...

--
Marcel

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

Re: boxar : New Audio Application (download or watch video)

[Yorick Moko]

nice
maybe you could also add it on opkg.org, so it can reach more people?

y

On Mon, Jun 1, 2009 at 9:06 PM, RzR www.rzr.online.fr
 wrote:
> Dear openmoko users
>
> Here is an other Audio Application for Openmoko platform :
>
> Boxar is a kind of piano using the full surface of the touch screen to
> display scales
>
> It was created by Sampath Jagananthan on the Nokia n8x0
> but I built it for the openmoko (GTA02 Running SHR) as well.
>
> Head to this page for download it or watch video demo :
>
> URL: http://rzr.online.fr/q/esd
>
> I'll make an other release if it can be supported on other OM distributions 
> ...
>
> Find me online or contact: http://rzr.online.fr/contact.htm
>
>
> --
> Related Obsession : http://rzr.online.fr/q/openmoko
>
> ___
> 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

boxar : New Audio Application (download or watch video)

[RzR www.rzr.online.fr]

Dear openmoko users

Here is an other Audio Application for Openmoko platform :

Boxar is a kind of piano using the full surface of the touch screen to
display scales

It was created by Sampath Jagananthan on the Nokia n8x0
but I built it for the openmoko (GTA02 Running SHR) as well.

Head to this page for download it or watch video demo :

URL: http://rzr.online.fr/q/esd

I'll make an other release if it can be supported on other OM distributions ...

Find me online or contact: http://rzr.online.fr/contact.htm


-- 
Related Obsession : http://rzr.online.fr/q/openmoko

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

[QtExtended] Latest and greatest, progress mail 12

[Franky Van Liedekerke]

(install instructions and script updated on 2090601: see below)

It's been a while, but we haven't been sleeping :-)

New website:

We have a new website now, thanks to Fale: http://www.qtmoko.org
There you can find all the latest changes, report bugs, etc ...

IRC channel:

For those wanting to talk: on irc.freenode.net, channel #qtopia is open
for business.

Things solved/added/changed:

See http://www.qtmoko.org/wiki/Change_log
See http://github.com/liedekef/qtmoko/commits/master for the changelog
in detail

Problems found (more like small nuisances now):
===
See http://www.qtmoko.org
- if you set the time back to something in the past, the clock service
  crashes and you need to restart qtextended if you want to use the
  clock again
- bluetooth is not working totally ok, only after initial boot it
  works, not after suspend/resume. Seems to be kernel/bluez3 version
  combo issue ... After suspend/resume bluetooth seems to work, but
  receiving files for sure doesn't.
- if you try to delete the "Wireless Lan", the system crashes ... cool
  huh, a crashed phone? So for now: don't do it :-)
- slow building up of the Contacts, because of all the sql queries for
  a*, b*, c*, ...

Install instructions:
=
download the script
http://www.e-dynamics.be/openmoko/qtmoko_install.sh , read the
comments at the top and then execute the script on your openmoko (after
having flashed the device and made sure internet works).
The script has 2 options: "install" or "update". An update will just
download the tgz file and replace your current qtmoko with it.

For those who just want to replace their existing qtmoko manually,
here's the link: http://www.e-dynamics.be/openmoko/qte_20090601.tgz .

Enjoy!

Franky

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

Re: Debuzzing

[Steve Mosher]

   Yes. Since I'm marketing I'll give the only description I can which 
is considerably dumbed down.

RF ( from GSM) gets coupled onto the lines leading INTO the audio mixer.
the mixer cannot filter this signal. The RF remains on the line coming 
out of the mixer. The only way to remove it before it gets on the 
microphone is to apply a filter: the CAP in the buzz fix.

It's unclear whether this buzz can be removed by processing done
by carriers or receiving handsets once the infected signal leaves the 
FR. Clearly in some cases it is not removed. Since the buzz signal is 
obviously in the hearable range I would imagine that any post processing
would be a hit on S/N or audio quality.

[To remove the ROOT cause ( RF from GSM getting on the lines) you apply
ferrite beads ( or other EE contraptions that I won't pretend to 
comprehend) on the input side of the Mixer. ]

Now, to the question of how the RF gets on the lines going into the 
mixer. I believe there is a frequency dependency. That is, some 
frequencies ( say 900 for example) will couple more readily than others
( say 1900) and obviously harmonics of 900 might couple more readily as 
well. EMI is black magic as far as I'm concerned so I'll shut up and not
beclown myself any further.

arne anka wrote:
>>> Aother note to all who read this: the Buzz rework is only required if
>>> you have the Buzz problem.
>> Hmm, wasn't there an environmental component as well, i.e., band and
>> signal strength ? So changes in the network, e.g., traveling, moving,
>> or the provider messing with things, might bring buzz to phones that
>> still lacked that experience.
> 
> 
> as far as i understood the issue, the buzz is there by design and not to  
> be solved by tewaking a state file.
> thus, while actually experiencing that buzz is subject to several factors,  
> otoh nobody can be said to be sure not to be bitten by it.
> conclusion: everyone having access to the buzz fix should take hold of it.
> 
> ___
> 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: Debuzzing

[Steve Mosher]

YA,
  When I first started putting the program together I asked Tony Tu to 
get me a test protocal for incoming. Engineering ( and others) then 
pointed out that the Buzz problem was conditioned by enviromental 
factors that we CND ( could not duplicate) such that a phone with Buzz
in the feild may not exhibit it at the test site ( For example, I never
had phones buzz for me, even when sean flew out with a phone to show
me the buzz) And a phone without buzz in the field may exhibit it at the 
test site. So, I dropped the requirement for an incoming test protocal.
My logic was this. The circuit was known to manifest the problem under
certain circumstances. Its clear that RF gets on the line and clear also 
that the CAP fix, if properly applied, reduces the symptoms, both in 
theory and in practice. So, if we offer the buzz fix to all, some small
fraction of people who do not have the problem will still want the fix.
If they are willing to part with their phone for a week or so to get a 
fix they dont need, then go ahead and fix it.

Werner Almesberger wrote:
> Dr. H. Nikolaus Schaller wrote:
>> Aother note to all who read this: the Buzz rework is only required if  
>> you have the Buzz problem.
> 
> Hmm, wasn't there an environmental component as well, i.e., band and
> signal strength ? So changes in the network, e.g., traveling, moving,
> or the provider messing with things, might bring buzz to phones that
> still lacked that experience.
> 
> - Werner
> 
> ___
> 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: Debuzzing

[Steve Mosher]

See inline below

Ori Pessach wrote:
> On Mon, Jun 1, 2009 at 10:05 AM, Steve Mosher  wrote:
> 
>>  Getting a focused effort in the US has been problematic. The reason is
>> simple. The vast majority of sales in the US have been through the OM
>> store. The disty, therefore, don't have the same motivation that say
>> Dr. N has. neither do they have the resources required. The best thing,
>> the most logical thing would be for OM in the US to set up a program
>> just like Dr. N did.
>>
>> The problem? OM usa is me. Part of the reason the deal worked with Dr. N
>> is that he was able to do all the detailed ground work required to get
>> this done. I would have to execute the fix by myself. That's no simple
>> feat, but now that Dr. N has shown the way, I can look into copying his
>> effort. basically I'm a marketing guy, but if need be I'll be the
>> customer support, feild rework, logistics guy.
>>
>> In the US it might require a different approach, but I can start to look
>> into it.
>>
> 
> Steve, I do realize that coordinating this is a challenge, but in this case
> it seems like the vendor I bought my phone from is trying to work with
> Openmoko, and isn't getting a satisfactory response, or any response at all
> if I take their version of the story to be true - which I have no reason not
> to.
   Well, I put together a rework plan for all the distributors. It was a 
program to rework existing stock. That was phase 1. That program was 
supposed to be administered by 1 employee at OM. I'll have to check
and see if that task was completed. PHASE TWO of the program was to 
figure out a way to rework devices already in the hands of end users.
Dr. N and I have been discussing an approach for a while. And he has
just proved that it can work. Understand, Dr. N set up his whole 
program: he found the technician. he got a quote. he prepare his website
to take orders for the program. When he had that all set up he came to
me and said: here is my proposal: the customer does this, GDC does that,
and OM compensates me in this fashion. So, Sean and I said yes to the
deal. That's basically what it would take. You can just have the vendor
write me directly with their proposal. If they pattern their proposal
after Dr. Ns proposal then I have a good basis to make my case. But you
have to understand the issue of scale here. Dr. N offers the service a 
larger pool of customers. So his technician, of course, can offer a 
better price. There is a learning curve in doing this fix. If your
vendor sold 100 phones, he can expect to get 5 people to mail in phones
for a buzz fix. To service these 5 people he has to do a bunch of work.
he would be better off just shipping you a A7 for free. But if he
openly offered exchanges, then people without the buzz problem could 
just take advantage of the situation.
> 
> Since I've been waiting for a fix for nearly 10 months, I feel I've been
> extremely patient. But even my patience (which is otherwise legendary, I can
> assure you) runs out.
> 
> What would you suggest that I do at this point?

  Have your vendor write me directly. I can see what can be done. They 
would have to, at minimum, pattern their proposal after Dr. Ns proposal.
Find a technician to do the rework. get a quote from him. Establish a
way for US owners to ship their product in. Arrange for the rework
and adminster it. negotiate a reimbursement package from OM. etc.

other ideas?
> 
> --Ori Pessach
> 

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

Re: Debuzzing

[arne anka]

>> Aother note to all who read this: the Buzz rework is only required if
>> you have the Buzz problem.
>
> Hmm, wasn't there an environmental component as well, i.e., band and
> signal strength ? So changes in the network, e.g., traveling, moving,
> or the provider messing with things, might bring buzz to phones that
> still lacked that experience.


as far as i understood the issue, the buzz is there by design and not to  
be solved by tewaking a state file.
thus, while actually experiencing that buzz is subject to several factors,  
otoh nobody can be said to be sure not to be bitten by it.
conclusion: everyone having access to the buzz fix should take hold of it.

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

Re: Debuzzing

[Paul Fertser]

Werner Almesberger  writes:
> Dr. H. Nikolaus Schaller wrote:
>> Aother note to all who read this: the Buzz rework is only required if  
>> you have the Buzz problem.
>
> Hmm, wasn't there an environmental component as well, i.e., band and
> signal strength ? So changes in the network, e.g., traveling, moving,
> or the provider messing with things, might bring buzz to phones that
> still lacked that experience.

AFAICT, you're completely right. I can't fully understand why
Dr. H. Nikolaus Schaller thinks that the buzz rework is not always
required (probably some people never travel/move and use the same band
and network without provider doing anything). OTOH if a person uses FR
as a phone for a year and doesn't experience the buzz problem and he
is not going to change network or places where he uses his phone,
probably chances he'll get problems with buzz are low.

I'd say that's something that every person should decide for himself,
the only thing that needs stressing is "there's no buzz-free devices
(unless it's A7 or a reworked one), there're some good external
conditions which might or might not eventually change". Probably Joerg
will want to comment more.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Debuzzing

[Werner Almesberger]

Dr. H. Nikolaus Schaller wrote:
> Aother note to all who read this: the Buzz rework is only required if  
> you have the Buzz problem.

Hmm, wasn't there an environmental component as well, i.e., band and
signal strength ? So changes in the network, e.g., traveling, moving,
or the provider messing with things, might bring buzz to phones that
still lacked that experience.

- Werner

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

Re: Debuzzing

[Ori Pessach]

On Mon, Jun 1, 2009 at 10:05 AM, Steve Mosher  wrote:

>  Getting a focused effort in the US has been problematic. The reason is
> simple. The vast majority of sales in the US have been through the OM
> store. The disty, therefore, don't have the same motivation that say
> Dr. N has. neither do they have the resources required. The best thing,
> the most logical thing would be for OM in the US to set up a program
> just like Dr. N did.
>
> The problem? OM usa is me. Part of the reason the deal worked with Dr. N
> is that he was able to do all the detailed ground work required to get
> this done. I would have to execute the fix by myself. That's no simple
> feat, but now that Dr. N has shown the way, I can look into copying his
> effort. basically I'm a marketing guy, but if need be I'll be the
> customer support, feild rework, logistics guy.
>
> In the US it might require a different approach, but I can start to look
> into it.
>

Steve, I do realize that coordinating this is a challenge, but in this case
it seems like the vendor I bought my phone from is trying to work with
Openmoko, and isn't getting a satisfactory response, or any response at all
if I take their version of the story to be true - which I have no reason not
to.

Since I've been waiting for a fix for nearly 10 months, I feel I've been
extremely patient. But even my patience (which is otherwise legendary, I can
assure you) runs out.

What would you suggest that I do at this point?

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

Re: Fundamental Qi question

[Paul Fertser]

Rask Ingemann Lambertsen  writes:
> On Mon, Jun 01, 2009 at 04:07:10PM +0400, Paul Fertser wrote:
>> My MUA is flexible enough to strip _forged_ Reply-To header that this
>> list errorneously adds to every mail. So i'm perfectly aware how this
>> fucking mailing list works and i had to explicitly workaround this
>> stupidity.
>
>There's a header field for this purpose. Use it:
>
> List-Post: 
>
>In mutt, I just hit 'L' - list reply - and it figures it out. Of course,
> if you send a copy to someone directly, that header field is missing and the
> list server doesn't send a duplicate to the directly addressed recipient,
> who then has to manually edit the addresses when replying. So please don't
> put both the list and a person on the list in the To/Cc fields.

Now imagine i see a message from some person, with some ML (i'm
subscribed to Cc'd). Also there's like 5 persons in Cc list, that are
addressed explicitly because they have something to do with the topic
(like they're subsystem maintainers, original authors or something
like that). If i press "g" in mutt my To: header will be set to what
was in Reply-To: (if the sender for some reason decided to set it for
whatever reason) or to the From:. My Cc will be identical to those of
original message. Everybody relevant to the topic will receive the
message and in case some persons from that list were subscribed, they
won't receive it twice because ML software will see them already in To
or Cc and so will avoid sending a dup. But if i press "L" and some of
the Cc'd persons are not subscribed to the list (which is a very
common situation for things involving different areas of interest,
e.g. both alsa and arm) they will not receive my reply which is not
what is intended.

So, basic rules are: 1. lists don't send duplicate mails to those
already present in To or Cc. 2. not every person participating in
conversation is subscribed and it's perfectly legal to post to most
MLs without being subscribed (with proper spam protection in place
(i'd require SPF PASS) it works without much troubles).

My conclusion is: group reply aka reply-all is the right thing to do,
other methods (Reply-To forgery or "list reply") are wrong.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Om2009 testing release 4

[The Rasterman]

On Mon, 1 Jun 2009 11:12:41 +0100 Rui Miguel Silva Seabra  said:

> > My experience is that most applications become almost unusable because
> > things are simply compressed beyond what is usable, so they need to do
> > something themselves.
> > 
> > Merely having the interface scaled down doesn't seem to work well enough
> > (to me).
> 
> Example:
> 
> http://files.1407.org/2009/06/01/paroli_is_borked_on_landscape.jpg

actually - that's more because paroly was designed for 480x640 only and has no
concept of adjusting to another size that is not that :) ask mirko.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Avoid duplicates on ML (was: Re: Fundamental Qi question)

[Paul Fertser]

Marcel  writes:

> Am Montag, 1. Juni 2009 14:32:26 schrieb Paul Fertser:
>> "Maksim 'max_posedon' Melnikau"  writes:
>> >> My MUA is flexible enough to strip _forged_ Reply-To header that
>> >> this list errorneously adds to every mail. So i'm perfectly aware
>> >> how this fucking mailing list works and i had to explicitly
>> >> workaround this stupidity.
>> >
>> > You still putting arne anka, in TO: and list in CC:,
>> >
>> > I agree with arne anka, that you should send mails(and reply-s) only
>> > TO: list.
>>
>> I said i did the wrong thing only once as a courtesy to arne. I won't
>> do it again because it's plain wrong. If you don't want to find the
>> proof yourself i will do that for you later. But i think you know me
>> enough to understand that if i do it that way i have a good enough
>> reason to do so. And if you look at any other sane ML out there (LAKML
>> e.g.) you'll see everybody doing the same.
>
> I have often enough seen people on debian-user-german that actually 
> *don't* want to be CCed because they read the list and therefore don't 
> need a dedicated reply.

To avoid getting duplicates (when a person sends a mail To or Cc you
and the list at the same time) one just needs to set his personal
preferences (and for most ML it's default to avoid duplicates), for
mailman it's described in [1].

[1] http://www.gnu.org/software/mailman/mailman-member/node21.html

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Fundamental Qi question

[Rask Ingemann Lambertsen]

On Mon, Jun 01, 2009 at 04:07:10PM +0400, Paul Fertser wrote:

> My MUA is flexible enough to strip _forged_ Reply-To header that this
> list errorneously adds to every mail. So i'm perfectly aware how this
> fucking mailing list works and i had to explicitly workaround this
> stupidity.

   There's a header field for this purpose. Use it:

List-Post: 

   In mutt, I just hit 'L' - list reply - and it figures it out. Of course,
if you send a copy to someone directly, that header field is missing and the
list server doesn't send a duplicate to the directly addressed recipient,
who then has to manually edit the addresses when replying. So please don't
put both the list and a person on the list in the To/Cc fields.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

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

Re: usb0 vs eth0

[David Ford]

The udev operation is simple.  The net interface naming is normally 
based on the MAC address and is stored in /etc/udev/rules.d/{something} 
like 70-persistent-net.rules IF your distribution runs the persistence 
script.  Otherwise device naming is based on the order in which devices 
are found by the kernel.  If you load modules by hand, and you alternate 
which you load first, then you would see the associated order change.

Mind you, if everything is done automatically by the kernel, the device 
order can change if the kernel's sequence of loading drivers changes.  
Every once in a great while that happens.

Here's my server's persistent net file:

Colt ~ # cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib64/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:1e:c9:2a:1c:64", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth0"

# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:1e:c9:2a:1c:65", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth1"


These are rules and they can be changed.  If you want the 1c:64 device 
to be named "funkadiddle" instead of "eth0", you'd simply edit the file 
and make the change of NAME="funkadiddle"

If you alter the MAC address of your device, either by hand or on boot 
such as in Qi etc, then it won't match if you have a rule set for the 
old MAC address and it'll get the next available interface name.

So, simply set up your persistent-net rules file like you want and be 
happy.  Name your interfaces "usbcable" and "wifi" and set your 
/etc/network/interfaces file to match if it pleases you so.


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

Re: Debuzzing

[Steve Mosher]

  Getting a focused effort in the US has been problematic. The reason is
simple. The vast majority of sales in the US have been through the OM 
store. The disty, therefore, don't have the same motivation that say
Dr. N has. neither do they have the resources required. The best thing,
the most logical thing would be for OM in the US to set up a program
just like Dr. N did.

The problem? OM usa is me. Part of the reason the deal worked with Dr. N
is that he was able to do all the detailed ground work required to get 
this done. I would have to execute the fix by myself. That's no simple
feat, but now that Dr. N has shown the way, I can look into copying his
effort. basically I'm a marketing guy, but if need be I'll be the 
customer support, feild rework, logistics guy.

In the US it might require a different approach, but I can start to look 
into it.


Ori Pessach wrote:
> On Mon, Jun 1, 2009 at 12:33 AM, Steve Mosher  wrote:
> 
>> Joerg, Dr. N and I have been discussing this. There is no need for the
>> HWD fix of 1024 as there is a software fix.
>> The hwdware fix of 1024  would require much more work than the
>> debuzzing. Joerg recommends against it.
>> I would agree.  I can have him come on here and explain. Even if the fix
>> were required we would still have
>> to do a lot of work before it could be fielded. So, dont wait. get your
>> phone buzz fixed
> 
> 
> Steve,
> 
> I would love to, but how? I live in the US, the vendor I bought my phone
> from has been apparently ignoring my emails about this and when I called
> them to ask they told me that they're not getting answers from Openmoko.
> It's been over 9 months since I first contacted them about the buzz.
> 
> --Ori Pessach
> 
> 
> 
> 
> 
> ___
> 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: Fundamental Qi question

[Marcel]

Am Montag, 1. Juni 2009 14:32:26 schrieb Paul Fertser:
> "Maksim 'max_posedon' Melnikau"  writes:
> >> My MUA is flexible enough to strip _forged_ Reply-To header that
> >> this list errorneously adds to every mail. So i'm perfectly aware
> >> how this fucking mailing list works and i had to explicitly
> >> workaround this stupidity.
> >
> > You still putting arne anka, in TO: and list in CC:,
> >
> > I agree with arne anka, that you should send mails(and reply-s) only
> > TO: list.
>
> I said i did the wrong thing only once as a courtesy to arne. I won't
> do it again because it's plain wrong. If you don't want to find the
> proof yourself i will do that for you later. But i think you know me
> enough to understand that if i do it that way i have a good enough
> reason to do so. And if you look at any other sane ML out there (LAKML
> e.g.) you'll see everybody doing the same.

I have often enough seen people on debian-user-german that actually 
*don't* want to be CCed because they read the list and therefore don't 
need a dedicated reply.

--
Marcel

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

Re: Debuzzing

[Warren Baird]

Hmm..   You say that the buzz rework is only required by people who have the
buzz problem.How do we tell the difference between the buzz problem and
a badly tuned gsmhandset.state?

My situation is that when I talk to people on the FR I generally hear them
very clearly, but they get a lot of static on their side - is that the buzz
problem?  Or is that something I can fix by tweaking the gsmhandset.state
file?

I'm using OM2009 TR4 btw - switching from the default alsa state file to
http://www.kurppa.fi/freerunner/config_files/gsmhandset.state seemed to help
the static, but it's still pretty bad...

Warren


On Mon, Jun 1, 2009 at 8:03 AM, Dr. H. Nikolaus Schaller
wrote:

>
> Am 01.06.2009 um 13:16 schrieb Paul Fertser:
>
> > "Dr. H. Nikolaus Schaller"  writes:
> >>> and standby time jumping up 25% looks a lot to me.
> >>
> >> If you find a way to DIY to gain these 25%, please share with us.
> >
> > In fact overall time required for hand rework is roughly equal for
> > both buzz and #1024 fixes. If one has already dismounted the can
>
> The key difference is the word "if already dismounted the can".
>
> >
> > (quite easy if one is careful) then changing that particular capacitor
> > is not a problem at all for a skilled person, it's SMT0805 size, big
> > enough comparing to 0402 R and it's very conveniently located.
> >
> > This is for purely informational purposes for DIY-ers, i'm not
> > recommending any distributors to offer this rework, quite the
> > opposite.
>
> Thanks for this description which will help DIY-ers!
>
> Our reworker just opens the two torx screws, unclips the front cover
> and then does the Buzz-Rework under a microscope. Then, the front
> cover is clipped back and torx screws are replaced. This keeps rework
> cost low even in a high-wage country like Germany (which is still more
> than the 3 EUR we formally charge - Openmoko is sponsoring the rework).
>
> For opening the GSM shield you have to dismantle the whole PCB from
> the Freerunner plastics and then open the can. Doing the reverse
> direction means to put the power and aux buttons in place, make sure
> that the vibramotor and speaker give contact etc.  and everything
> snaps back. This all sums to approx. 4 times as many minutes. That is
> the time that adds up in our calculation. So if we find a way to apply
> it without opening the can and dismantling the PCB, it will be the
> same speed.
>
> So it is the simplicity of the buzz-rework that made us start this
> adventure but more complex reworks are beyond our limits...
>
>
> Aother note to all who read this: the Buzz rework is only required if
> you have the Buzz problem. If your device does not, there is no need
> to rework. My personal estimate is that <5% of users have experienced
> it.
>
> And if you don't own a Freerunner yet, you don't necessarily have to
> wait for A7 devices. So purchasing an A6 is still a good bet.
>
> Nikolaus
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>



-- 
Warren Baird - Photographer and Digital Artist
http://www.synergisticimages.ca
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: usb0 vs eth0

[Angus Ainslie]

On June 1, 2009 08:54:51 am ivvmm wrote:
>
> Read the section for Slackware on that wiki page. This way that will do
> the right routing whatever the interface is called so you will not have
> to think how is it named at this time.
>
> As for me, I experience another problem: cannot connect to the
> freerunner twice, only once until device is rebooted. How this can be
> solvfed?

On the host side  

ifdown ethx; ifup ethx

Angus

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

Re: Debuzzing

[Steve Mosher]

Agreed. I've not heard about the jump in standby time, but joerg 
mentioned something about that ( as i recall).
arne anka wrote:
>> as there is a software fix.
> 
> imo it is still a workaround, not a fix.
> and standby time jumping up 25% looks a lot to me.
> 
> ___
> 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: usb0 vs eth0

[ivvmm]

roby wrote:
> On Mon, Jun 1, 2009 at 8:29 AM, Paul Fertser  > wrote:
> 
> Max mailto:m...@darim.com>> writes:
> > When I plug FR it appears as eth0 instead of usb0.
> It's on purpose and it's damn right. Search the archives. If you want
> some kind of interface renaming for whatever reason, write an
> appropriate udev rule.
> 
> 
> Everybody saying that it's right, but nobody explaining how to use it..
> the problem is that it's not so simple to write an udev interface
> renaming rule because i don't know which interface udev will assign to
> the neo.. for example when i connect it i get eth1, suddenly renamed to
> eth7 by udev, but am i sure it will always get eth7?
> The page http://wiki.openmoko.org/wiki/USB_Networking explain how to
> setup nat and routing, but all the examples use usb0. The problem is
> that each different udev installation will assign a possibly different
> interface name to the neo, so what should one do? setup nat and routing
> for all the interfaces being attached? seems strange.. I just would like
> to see an example, because it's not clear to me, and i think for many
> like me..
> 
> -- 
> roby
> 
> 

Read the section for Slackware on that wiki page. This way that will do
the right routing whatever the interface is called so you will not have
to think how is it named at this time.

As for me, I experience another problem: cannot connect to the
freerunner twice, only once until device is rebooted. How this can be
solvfed?



signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: usb0 vs eth0

[Ben Wong]

> i don't know which interface udev will assign to the neo.. for
> example when i connect it i get eth1, suddenly renamed to eth7 by udev, but
> am i sure it will always get eth7?

I believe it depends on which distribution you run.  Some
distributions, like Debian, use a persistent-net-generator script
which will always give a particular ethernet device a consistent name
in /dev whenever it is plugged in.  Personally, that drives me batty;
I'm a tidy person and I don't like seeing my first ethernet card be
named eth7 simply because I used several other cards in the distant
past.  But it's good for you in this case, your Freerunner should
always have the same device name.


> The page http://wiki.openmoko.org/wiki/USB_Networking explain how to setup
> nat and routing, but all the examples use usb0. The problem is that each
> different udev installation will assign a possibly different interface name
> to the neo, so what should one do? setup nat and routing for all the
> interfaces being attached? seems strange.. I just would like to see an
> example, because it's not clear to me, and i think for many like me..

Yes, the usb0/eth1/eth7 problem is very annoying from a documentation
point of view.  It would be nice to have a single example on the wiki
which people can use without editing.  I don't have the answer to that
one, but I'd love to see it if someone else does.

--Ben

P.S. If you're using Debian, you can check the file
/etc/udev/rules.d/70-persistent-net.rules to see the mappings between
the MAC address and device name.  I believe OpenMoko devices always
have a MAC address that starts with 00:1F:11

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

Re: Om2009 testing release 4

[Warren Baird]

Hi Rask,

I'm afraid I have no idea which X server and touch screen driver were in
use.   I was using OM2009 TR3 and hadn't modified the X server at all, if
that helps.   The behaviour was that sometime when I rotated the device with
omrotatenew the touch pad response would be about 1.5cm to the left of where
I pressed.  Usually when that happened I could just rotate it to another
position and back again, and it was usually fine.

Warren


On Sun, May 31, 2009 at 12:46 PM, Rask Ingemann Lambertsen
wrote:

> On Mon, May 25, 2009 at 05:20:08PM +0100, Rui Miguel Silva Seabra wrote:
> > On Mon, May 25, 2009 at 12:08:33PM -0400, Warren Baird wrote:
> > > I had another
> > > experience with epdfview where when I held the FR horizontally I had to
> > > click about 1.5 cm to the right of the 'next page' button to get it to
> > > actually go to the next page.  After holding it vertically and then
> > > horizontally again, it was fine.
>
> > As for your problem with landscape vs portrait positions and GUIs...
> well, that's
> > a problem that's not easy to solve unless all applications pay attention
> to
> > a specific dbus signal which omnewrotate will send in the future.
>
>No problem as long as the X server and touch screen driver is working.
> Which X server did it happen with (kdriver Xglamo, Xorg fbdev or Xorg
> glamo)?
>
> --
> Rask Ingemann Lambertsen
> Danish law requires addresses in e-mail to be logged and stored for a year
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>



-- 
Warren Baird - Photographer and Digital Artist
http://www.synergisticimages.ca
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Debuzzing

[Ori Pessach]

On Mon, Jun 1, 2009 at 12:33 AM, Steve Mosher  wrote:

> Joerg, Dr. N and I have been discussing this. There is no need for the
> HWD fix of 1024 as there is a software fix.
> The hwdware fix of 1024  would require much more work than the
> debuzzing. Joerg recommends against it.
> I would agree.  I can have him come on here and explain. Even if the fix
> were required we would still have
> to do a lot of work before it could be fielded. So, dont wait. get your
> phone buzz fixed


Steve,

I would love to, but how? I live in the US, the vendor I bought my phone
from has been apparently ignoring my emails about this and when I called
them to ask they told me that they're not getting answers from Openmoko.
It's been over 9 months since I first contacted them about the buzz.

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

Re: Fundamental Qi question

[Paul Fertser]

"Maksim 'max_posedon' Melnikau"  writes:
>> My MUA is flexible enough to strip _forged_ Reply-To header that this
>> list errorneously adds to every mail. So i'm perfectly aware how this
>> fucking mailing list works and i had to explicitly workaround this
>> stupidity.
> You still putting arne anka, in TO: and list in CC:,
>
> I agree with arne anka, that you should send mails(and reply-s) only
> TO: list.

I said i did the wrong thing only once as a courtesy to arne. I won't
do it again because it's plain wrong. If you don't want to find the
proof yourself i will do that for you later. But i think you know me
enough to understand that if i do it that way i have a good enough
reason to do so. And if you look at any other sane ML out there (LAKML
e.g.) you'll see everybody doing the same.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Fundamental Qi question

[Maksim 'max_posedon' Melnikau]

> My MUA is flexible enough to strip _forged_ Reply-To header that this
> list errorneously adds to every mail. So i'm perfectly aware how this
> fucking mailing list works and i had to explicitly workaround this
> stupidity.
You still putting arne anka, in TO: and list in CC:,

I agree with arne anka, that you should send mails(and reply-s) only TO: list.


signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Debuzzing

[Paul Fertser]

"Dr. H. Nikolaus Schaller"  writes:
>> In fact overall time required for hand rework is roughly equal for
>> both buzz and #1024 fixes. If one has already dismounted the can
>
> The key difference is the word "if already dismounted the can".

I would require those who wants that #1024 rework to be performed to
just send a bare board with can dismounted. Probably i'm dead wrong,
but i disassembled and assembled my FR many times and i dismounted the
GSM can without problems.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Fundamental Qi question

[Paul Fertser]

"arne anka"  writes:
>> Source code is what actually compiles to binary that then runs on
>> device. So it's the ultimate source of information about what and how
>> it is supposed to work. Any discussions on ML especially those filled
>> with inaccurate conclusions drawn from nowhere can't get you any clear
>> understanding of what the code actually does.
>
> in other words you aree saying "i don't like writing documentations. and  
> if you don't think that's the right attitusde, you are stuoid."

I don't like writing documentation, that's true. And i'm not obliged
to do that. Nevertheless i did improved Qi wiki page a lot (read the
history if you want); later improvements came directly from Andy.

>>> would you please stop, to cc me always and instead reply to the list as
>>> everybody else does?
>>
>> I didn't CC you, i just directed my letters to you because i was
>> answering to you and i kept ML CC'd for others to read. That's how MLs
>> work. If you don't like it, don't use mailing lists. This time i
>> altered headers just to show that i'm polite enough.
>
> apparently you never realized how _this_ mailinglist works!
> it has a default reply-to which is the list -- if you or your mail client  
> are unable to cope with something more different than "single click, no  
> thinking required", you should probaly not use mailinglists at all.

My MUA is flexible enough to strip _forged_ Reply-To header that this
list errorneously adds to every mail. So i'm perfectly aware how this
fucking mailing list works and i had to explicitly workaround this
stupidity.

> i certainly hope, your bad day is over soon and you are able to  
> communicate like an intelligent being again.

I certainly hope that you will start understand what i'm saying.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Debuzzing

[Dr. H. Nikolaus Schaller]

Am 01.06.2009 um 13:16 schrieb Paul Fertser:

> "Dr. H. Nikolaus Schaller"  writes:
>>> and standby time jumping up 25% looks a lot to me.
>>
>> If you find a way to DIY to gain these 25%, please share with us.
>
> In fact overall time required for hand rework is roughly equal for
> both buzz and #1024 fixes. If one has already dismounted the can

The key difference is the word "if already dismounted the can".

>
> (quite easy if one is careful) then changing that particular capacitor
> is not a problem at all for a skilled person, it's SMT0805 size, big
> enough comparing to 0402 R and it's very conveniently located.
>
> This is for purely informational purposes for DIY-ers, i'm not
> recommending any distributors to offer this rework, quite the
> opposite.

Thanks for this description which will help DIY-ers!

Our reworker just opens the two torx screws, unclips the front cover  
and then does the Buzz-Rework under a microscope. Then, the front  
cover is clipped back and torx screws are replaced. This keeps rework  
cost low even in a high-wage country like Germany (which is still more  
than the 3 EUR we formally charge - Openmoko is sponsoring the rework).

For opening the GSM shield you have to dismantle the whole PCB from  
the Freerunner plastics and then open the can. Doing the reverse  
direction means to put the power and aux buttons in place, make sure  
that the vibramotor and speaker give contact etc.  and everything  
snaps back. This all sums to approx. 4 times as many minutes. That is  
the time that adds up in our calculation. So if we find a way to apply  
it without opening the can and dismantling the PCB, it will be the  
same speed.

So it is the simplicity of the buzz-rework that made us start this  
adventure but more complex reworks are beyond our limits...


Aother note to all who read this: the Buzz rework is only required if  
you have the Buzz problem. If your device does not, there is no need  
to rework. My personal estimate is that <5% of users have experienced  
it.

And if you don't own a Freerunner yet, you don't necessarily have to  
wait for A7 devices. So purchasing an A6 is still a good bet.

Nikolaus

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

Re: Fundamental Qi question

[Chris Samuel]

On Mon, 1 Jun 2009 09:49:11 pm Paul Fertser wrote:

> File name is wrong, the kernel is 2.6.29 actually. Look at the git
> hash.

Ahh, good call, eventually traced it to this to confirm that..

http://git.openmoko.org/?p=kernel.git;a=blob_plain;f=Makefile;hb=f19f259d3c1afde8eae53983fd19f61831927413

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 29
EXTRAVERSION += -rc2
NAME = Erotic Pickled Herring

Phew, so I'm not going mad!

Thanks Paul.

-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP



signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Fundamental Qi question

[arne anka]

> Source code is what actually compiles to binary that then runs on
> device. So it's the ultimate source of information about what and how
> it is supposed to work. Any discussions on ML especially those filled
> with inaccurate conclusions drawn from nowhere can't get you any clear
> understanding of what the code actually does.

in other words you aree saying "i don't like writing documentations. and  
if you don't think that's the right attitusde, you are stuoid."


>> would you please stop, to cc me always and instead reply to the list as
>> everybody else does?
>
> I didn't CC you, i just directed my letters to you because i was
> answering to you and i kept ML CC'd for others to read. That's how MLs
> work. If you don't like it, don't use mailing lists. This time i
> altered headers just to show that i'm polite enough.


apparently you never realized how _this_ mailinglist works!
it has a default reply-to which is the list -- if you or your mail client  
are unable to cope with something more different than "single click, no  
thinking required", you should probaly not use mailinglists at all.

i certainly hope, your bad day is over soon and you are able to  
communicate like an intelligent being again.



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

Re: Fundamental Qi question

[Paul Fertser]

Chris Samuel  writes:
> On Mon, 1 Jun 2009 09:09:02 pm Paul Fertser wrote:
>
>> No, Qi doesn't support jffs2.
>
> That's what I thought.
>
> But, in that case, how come my Om2009 phone boots into 2.6.29-rc2 (which is
> in /boot in the JFFS2 image) and not to the 2.6.28 image I've
> flashed to it ?

File name is wrong, the kernel is 2.6.29 actually. Look at the git
hash.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Fundamental Qi question

[Paul Fertser]

"arne anka"  writes:
>> You should have read Qi wiki page or Qi source code instead.
>
> well, i follow the discussion on the lists a long time.
> if that kind of information is not worth to be mentioned, i certainly do  
> not expect it to be mentioned in either wiki or code.

Source code is what actually compiles to binary that then runs on
device. So it's the ultimate source of information about what and how
it is supposed to work. Any discussions on ML especially those filled
with inaccurate conclusions drawn from nowhere can't get you any clear
understanding of what the code actually does.

> would you please stop, to cc me always and instead reply to the list as  
> everybody else does?

I didn't CC you, i just directed my letters to you because i was
answering to you and i kept ML CC'd for others to read. That's how MLs
work. If you don't like it, don't use mailing lists. This time i
altered headers just to show that i'm polite enough.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Fundamental Qi question

[Chris Samuel]

On Mon, 1 Jun 2009 09:09:02 pm Paul Fertser wrote:

> No, Qi doesn't support jffs2.

That's what I thought.

But, in that case, how come my Om2009 phone boots into 2.6.29-rc2 (which is
in /boot in the JFFS2 image) and not to the 2.6.28 image I've flashed to it ?

Flashed with:

dfu-util -d 0x1d50:0x5119 -a kernel -R -D 
uImage-2.6.28-stable+gitr0+f19f259d3c1afde8eae53983fd19f61831927413-
r2-om-gta02.bin

But boots into:

Linux om-gta02 2.6.29-rc2 #1 PREEMPT Thu May 21 17:06:24 CEST 2009 armv4tl 
unknown

Both are listed in okpg!

r...@om-gta02:~# opkg list_installed | fgrep kernel | head
kernel - 2.6.28-stable+gitr0+f19f259d3c1afde8eae53983fd19f61831927413-r2 -
kernel-2.6.29-rc2 - 
2.6.28-stable+gitr0+f19f259d3c1afde8eae53983fd19f61831927413-r2 -

It's not coming off the SD card as that's a single partition with
just the OSM tiles for TangoGPS on it.

r...@om-gta02:~# ls /media/card/
lost+found  Maps


cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP



signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: usb0 vs eth0

[Paul Fertser]

roby  writes:
> On Mon, Jun 1, 2009 at 8:29 AM, Paul Fertser  wrote:
> Max  writes:
> > When I plug FR it appears as eth0 instead of usb0.
> It's on purpose and it's damn right. Search the archives. If you want
> some kind of interface renaming for whatever reason, write an
> appropriate udev rule.
>
> Everybody saying that it's right, but nobody explaining how to use
> it..  the problem is that it's not so simple to write an udev
> interface renaming rule because i don't know which interface udev
> will assign to the neo.. for example when i connect it i get eth1,
> suddenly renamed to eth7 by udev, but am i sure it will always get
> eth7?

Yes, you're sure. As long as you don't touch udev. It's the same as
with pci ethernet boards. Once you plugged it in, you'll have a
persintent name for it no matter what unless you erase/alter your udev
configuration.

> The page http://wiki.openmoko.org/wiki/USB_Networking explain how to
> setup nat and routing, but all the examples use usb0. The problem is
> that each different udev installation will assign a possibly
> different interface name to the neo, so what should one do?

So what? You just substitute the interface assigned to freerunner
instead of usb0 in all the examples, i can't see a problem.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Fundamental Qi question

[arne anka]

> You should have read Qi wiki page or Qi source code instead.

well, i follow the discussion on the lists a long time.
if that kind of information is not worth to be mentioned, i certainly do  
not expect it to be mentioned in either wiki or code.

would you please stop, to cc me always and instead reply to the list as  
everybody else does?



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

Re: usb0 vs eth0

[roby]

On Mon, Jun 1, 2009 at 8:29 AM, Paul Fertser  wrote:

> Max  writes:
> > When I plug FR it appears as eth0 instead of usb0.
> It's on purpose and it's damn right. Search the archives. If you want
> some kind of interface renaming for whatever reason, write an
> appropriate udev rule.
>

Everybody saying that it's right, but nobody explaining how to use it..
the problem is that it's not so simple to write an udev interface renaming
rule because i don't know which interface udev will assign to the neo.. for
example when i connect it i get eth1, suddenly renamed to eth7 by udev, but
am i sure it will always get eth7?
The page http://wiki.openmoko.org/wiki/USB_Networking explain how to setup
nat and routing, but all the examples use usb0. The problem is that each
different udev installation will assign a possibly different interface name
to the neo, so what should one do? setup nat and routing for all the
interfaces being attached? seems strange.. I just would like to see an
example, because it's not clear to me, and i think for many like me..

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

Re: Fundamental Qi question

[Paul Fertser]

"arne anka"  writes:
> as far as i understood from the qi discussions, qi does not use that  
> partition but looks for a specific file in a specific location, make the  
> kernel nand partition unnecessary.
> so, if it can't read jffs2, one cannot boot from flash.

You should have read Qi wiki page or Qi source code instead.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Fundamental Qi question

[arne anka]

>>> No, Qi doesn't support jffs2.
>>
>> bummer.
>> how's that -- it makes qi unusable for everybody using the internal  
>> flash
>> as "primary device" and forces to boot from sd card.
>> not sensible imo.
>
> How's that? Why don't you want to use the kernel flashed to dedicated
> nand partition?


as far as i understood from the qi discussions, qi does not use that  
partition but looks for a specific file in a specific location, make the  
kernel nand partition unnecessary.
so, if it can't read jffs2, one cannot boot from flash.



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

Re: Fundamental Qi question

[Paul Fertser]

"arne anka"  writes:
>> No, Qi doesn't support jffs2.
>
> bummer.
> how's that -- it makes qi unusable for everybody using the internal flash  
> as "primary device" and forces to boot from sd card.
> not sensible imo.

How's that? Why don't you want to use the kernel flashed to dedicated
nand partition?

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Debuzzing

[Paul Fertser]

"Dr. H. Nikolaus Schaller"  writes:
>> and standby time jumping up 25% looks a lot to me.
>
> If you find a way to DIY to gain these 25%, please share with us.

In fact overall time required for hand rework is roughly equal for
both buzz and #1024 fixes. If one has already dismounted the can
(quite easy if one is careful) then changing that particular capacitor
is not a problem at all for a skilled person, it's SMT0805 size, big
enough comparing to 0402 R and it's very conveniently located.

This is for purely informational purposes for DIY-ers, i'm not
recommending any distributors to offer this rework, quite the
opposite.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Fundamental Qi question

[arne anka]

> No, Qi doesn't support jffs2.

bummer.
how's that -- it makes qi unusable for everybody using the internal flash  
as "primary device" and forces to boot from sd card.
not sensible imo.



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

Re: Fundamental Qi question

[Paul Fertser]

Chris Samuel  writes:
> Am I right in thinking that if you are using Qi and have flashed a JFFS2 
> image 
> to your NAND which has a /boot with a kernel in it then it will boot that 
> kernel in preference to the one that you have flashed directly with
> dfu-util ?

No, Qi doesn't support jffs2.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Debuzzing

[Dr. H. Nikolaus Schaller]

Am 01.06.2009 um 10:46 schrieb arne anka:

>> as there is a software fix.
>
> imo it is still a workaround, not a fix.

For the GSM-Buzz there was not even a SW workaround for those who have  
been affected. So it had to be fixed.

We have estimated that reworking the #1024 is at least 4 times as  
expensive (because it is done manually and needs much more time to  
open the GSM shield; how testing could work is also unclear).
Therefore, we decided not to offer it as a rework service (since there  
*is* a solution available).

> and standby time jumping up 25% looks a lot to me.


If you find a way to DIY to gain these 25%, please share with us.

Nikolaus

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

Re: PISI 0.2 released

[Michael Pilgermann]

Richy,

I assembled a new package for vobject (as well for gdata and dateutil)
and uploaded them to opkg.
Besides the Python 2.5 parts they also include the Python 2.6 packages now.

If you update, please let me know, whether this working for you ...
greetings
Mike

Richy wrote:
> I tried this on shr-testing but I get:
> 
> r...@om-gta02 ~/.pisi $ pisigui
> Traceback (most recent call last):
>   File "/bin/pisigui", line 31, in 
> import pisi
>   File "/opt/pisi/pisi.py", line 31, in 
> from events import events,  eventsSync
>   File "/opt/pisi/events/events.py", line 22, in 
> import vobject
> ImportError: No module named vobject
> 
> 
>  Maybe this is python-2.6 related?
> 
> 
> 
> 
> ___
> 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: Launcher/Home Page (alpha) Release 0.18

[c_c]

Hi,

jeremy jozwik wrote:
> 
> c_c, if you get no reply from him let me know. making pritty things is
> about
> all i can do for the openmoko community at the moment.
> but youll have to wait a bit as im on vacation 180* around the globe from
> my
> home. but id be very interested in making some things for this and intone
> 
 Sure. I'd be happy to receive help for the artwork. Things I can think of
Immediately are :-
 
  * wallpapers for launcher
  * icons for launcher (basically for the categories in the toolbar)
  * button symbols for intone and e-tasks
 
  Whatever you can think of is welcome.
 
  I've been travelling myself and will be back probably by the 4th. And I've
managed to leave my freerunners usb cable back home. Hence no updates (till
I buy another one).

  I have got the toolbar working at the bottom of the screen - and the icons
are now icons - so they should be transparent too.

  Will be releasing soon.
-- 
View this message in context: 
http://n2.nabble.com/Launcher-Home-Page-%28alpha%29-Release-0.18-tp2969146p3005537.html
Sent from the Openmoko Community mailing list archive at Nabble.com.


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

Fundamental Qi question

[Chris Samuel]

Hi folks,

Am I right in thinking that if you are using Qi and have flashed a JFFS2 image 
to your NAND which has a /boot with a kernel in it then it will boot that 
kernel in preference to the one that you have flashed directly with dfu-util ?

cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP



signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Om2009 testing release 4

[Rui Miguel Silva Seabra]

On Mon, Jun 01, 2009 at 10:59:00AM +0100, Rui Miguel Silva Seabra wrote:
> On Mon, Jun 01, 2009 at 07:24:22PM +1000, Carsten Haitzler wrote:
> > On Mon, 1 Jun 2009 09:10:41 +0100 Rui Miguel Silva Seabra  
> > said:
> > > On Mon, Jun 01, 2009 at 05:21:15PM +1000, Carsten Haitzler wrote:
> > > > On Mon, 25 May 2009 17:20:08 +0100 Rui Miguel Silva Seabra 
> > > > 
> > > > said:
> > > > 
> > > > > I'm sure it's not, AFAICT (since I don't know Parloi's internals) it
> > > > > doesn't touch anything Paroli or anything related to calls.
> > > > > 
> > > > > As for your problem with landscape vs portrait positions and GUIs... 
> > > > > well,
> > > > > that's a problem that's not easy to solve unless all applications pay
> > > > > attention to a specific dbus signal which omnewrotate will send in the
> > > > > future.
> > > > > 
> > > > > This signal can be used by apps so they adjust their UI according to 
> > > > > the
> > > > > display mode, but other than that, they all think they're in the same
> > > > > position.
> > > > 
> > > > no dbus signals needed. when x rotates,you'll get a configurenotify on 
> > > > root
> > > > AND an XRRScreenChangeNotifyEvent event (on root). These will also tell 
> > > > you
> > > > your orientation and new size. The WM, if smart, will resize your app
> > > > window anyway, so all you really need to do is, on resize, query x for 
> > > > the
> > > > orientation, if orientation matters. if it doesn't just adjusting to the
> > > > new size is what you should be doing anyway.
> > > 
> > > Ah... so applicaitons like, say, paroli, mokomaze, etc... need to pay
> > > attention to XRRScreenChangeNotifyEvent ?
> > 
> > well they dont HAVE to - they simply should adjust to a new size (640x480 as
> > opposed to 480x640). that is already done for them (if under a window 
> > manager
> > that is sensible). they will get resized.
> 
> My experience is that most applications become almost unusable because things 
> are
> simply compressed beyond what is usable, so they need to do something 
> themselves.
> 
> Merely having the interface scaled down doesn't seem to work well enough (to 
> me).

Example:

http://files.1407.org/2009/06/01/paroli_is_borked_on_landscape.jpg

Rui

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

Re: Om2009 testing release 4

[Rui Miguel Silva Seabra]

On Mon, Jun 01, 2009 at 07:24:22PM +1000, Carsten Haitzler wrote:
> On Mon, 1 Jun 2009 09:10:41 +0100 Rui Miguel Silva Seabra  
> said:
> > On Mon, Jun 01, 2009 at 05:21:15PM +1000, Carsten Haitzler wrote:
> > > On Mon, 25 May 2009 17:20:08 +0100 Rui Miguel Silva Seabra 
> > > said:
> > > 
> > > > I'm sure it's not, AFAICT (since I don't know Parloi's internals) it
> > > > doesn't touch anything Paroli or anything related to calls.
> > > > 
> > > > As for your problem with landscape vs portrait positions and GUIs... 
> > > > well,
> > > > that's a problem that's not easy to solve unless all applications pay
> > > > attention to a specific dbus signal which omnewrotate will send in the
> > > > future.
> > > > 
> > > > This signal can be used by apps so they adjust their UI according to the
> > > > display mode, but other than that, they all think they're in the same
> > > > position.
> > > 
> > > no dbus signals needed. when x rotates,you'll get a configurenotify on 
> > > root
> > > AND an XRRScreenChangeNotifyEvent event (on root). These will also tell 
> > > you
> > > your orientation and new size. The WM, if smart, will resize your app
> > > window anyway, so all you really need to do is, on resize, query x for the
> > > orientation, if orientation matters. if it doesn't just adjusting to the
> > > new size is what you should be doing anyway.
> > 
> > Ah... so applicaitons like, say, paroli, mokomaze, etc... need to pay
> > attention to XRRScreenChangeNotifyEvent ?
> 
> well they dont HAVE to - they simply should adjust to a new size (640x480 as
> opposed to 480x640). that is already done for them (if under a window manager
> that is sensible). they will get resized.

My experience is that most applications become almost unusable because things 
are
simply compressed beyond what is usable, so they need to do something 
themselves.

Merely having the interface scaled down doesn't seem to work well enough (to 
me).

Rui

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

Re: [Om2009] a community effort

[Paul Fertser]

Chris Samuel  writes:
> On Sun, 31 May 2009 09:17:30 pm Rui Miguel Silva Seabra wrote:
>> Also: suspend is working much more reliably ever since the upgrade to Qi,
>> so far I've only had to reboot because of that damn bug where suspend stops
>> and no calls are doable (in and out).
>
> Yeah, for me that happens whenever I get an incoming call (answered or 
> missed). :-(

As a temporary workaround (on Debian) i use this:

pkill zhone
/etc/init.d/fso-frameworkd stop
pkill -f frameworkd
pkill -f gsm0710
sleep 7
/etc/init.d/fso-frameworkd start
zhone &

Not sure if all the delays and actions are needed, it's anyway much
faster than rebooting.

HTH
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: [Om2009] a community effort

[Chris Samuel]

On Sun, 31 May 2009 09:17:30 pm Rui Miguel Silva Seabra wrote:

> Also: suspend is working much more reliably ever since the upgrade to Qi,
> so far I've only had to reboot because of that damn bug where suspend stops
> and no calls are doable (in and out).

Yeah, for me that happens whenever I get an incoming call (answered or 
missed). :-(

-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP



signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Om2009 testing release 4

[The Rasterman]

On Mon, 1 Jun 2009 09:10:41 +0100 Rui Miguel Silva Seabra  said:

> On Mon, Jun 01, 2009 at 05:21:15PM +1000, Carsten Haitzler wrote:
> > On Mon, 25 May 2009 17:20:08 +0100 Rui Miguel Silva Seabra 
> > said:
> > 
> > > I'm sure it's not, AFAICT (since I don't know Parloi's internals) it
> > > doesn't touch anything Paroli or anything related to calls.
> > > 
> > > As for your problem with landscape vs portrait positions and GUIs... well,
> > > that's a problem that's not easy to solve unless all applications pay
> > > attention to a specific dbus signal which omnewrotate will send in the
> > > future.
> > > 
> > > This signal can be used by apps so they adjust their UI according to the
> > > display mode, but other than that, they all think they're in the same
> > > position.
> > 
> > no dbus signals needed. when x rotates,you'll get a configurenotify on root
> > AND an XRRScreenChangeNotifyEvent event (on root). These will also tell you
> > your orientation and new size. The WM, if smart, will resize your app
> > window anyway, so all you really need to do is, on resize, query x for the
> > orientation, if orientation matters. if it doesn't just adjusting to the
> > new size is what you should be doing anyway.
> 
> Ah... so applicaitons like, say, paroli, mokomaze, etc... need to pay
> attention to XRRScreenChangeNotifyEvent ?

well they dont HAVE to - they simply should adjust to a new size (640x480 as
opposed to 480x640). that is already done for them (if under a window manager
that is sensible). they will get resized. if you want to do something SPECIAL
when in a particular rotation other than just adjust to the new size (i
generally would advise this as a bad idea - in he case of the freerunner, i see
no good reason to do anything special as there are no particular
markings/buttons around the screen you may want to specially have your ui
adjust to their new location relative to the pixels on the screen).

as paroli is in python - there isn't much it can do. the python bindings, as
best i know, don't export the Ecore_X_Event_Screen_Change,
Ecore_X_Event_Randr_Crtc_Change, Ecore_X_Event_Randr_Output_Change and
Ecore_X_Event_Randr_Output_Property_Notify events (these are more than you need
though - you only need the first, the other 3 are for xrandr1.3+ where you can
get events based on new outputs being added/removed (eg plug in an external
monitor to a laptop). also other function calls to query:
ecore_x_randr_screen_rotations_get(), ecore_x_randr_screen_rotation_get() etc.
etc.

so again - the only reasons i could think of for ACTUALLY wanting to know
rotation (other than adjust to screen size change) are:

1. external input like camera image needs rotating (as the camera just rotated
and the screen pixels did so you need to rotate the camera image back, but no
camera on freerunner)
2. you have some special markers/buttons around the screen that you have
buttons/indicators referring to these. (not on freerunner)

other than that window resize events are all you need (and if you need a new
custom layout - then choose it based on window size, not on rotation, as now
you also work in devices with landscape displays - eg n800).


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

GTA01 SHR Image, anyone have a good one?

[Ben Wilson]

Hi

I've been using SHR on my gta01 for a while as my everyday phone.
Recently I decided to try the latest testing/unstable images and ran 
into problems.

I'd like to move back to an earlier version so I can keep using my phone 
but unfortunately I deleted the old
image that I was using.

So does anyone out there with a GTA01 have a good SHR image I could grab?
Or maybe there's an archive of old images that I'm unaware of?

Thanks,

Ben.



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

Re: Debuzzing

[arne anka]

> as there is a software fix.

imo it is still a workaround, not a fix.
and standby time jumping up 25% looks a lot to me.

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

Re: SHR testing won't boot - jffs2 error ?

[Chris Samuel]

On Mon, 1 Jun 2009 10:43:17 am Rask Ingemann Lambertsen wrote:

> You need to upgrade the kernel then.

Is this one not the right one ?

http://build.shr-project.org/shr-testing/images/om-gta02/uImage-om-gta02-
latest.bin

> I see you mention 2.6.28 in another message.

That was about Om2009..

cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP



signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Om2009 testing release 4

[Rui Miguel Silva Seabra]

On Mon, Jun 01, 2009 at 05:21:15PM +1000, Carsten Haitzler wrote:
> On Mon, 25 May 2009 17:20:08 +0100 Rui Miguel Silva Seabra  
> said:
> 
> > I'm sure it's not, AFAICT (since I don't know Parloi's internals) it doesn't
> > touch anything Paroli or anything related to calls.
> > 
> > As for your problem with landscape vs portrait positions and GUIs... well,
> > that's a problem that's not easy to solve unless all applications pay
> > attention to a specific dbus signal which omnewrotate will send in the 
> > future.
> > 
> > This signal can be used by apps so they adjust their UI according to the
> > display mode, but other than that, they all think they're in the same
> > position.
> 
> no dbus signals needed. when x rotates,you'll get a configurenotify on root 
> AND
> an XRRScreenChangeNotifyEvent event (on root). These will also tell you your
> orientation and new size. The WM, if smart, will resize your app window 
> anyway,
> so all you really need to do is, on resize, query x for the orientation, if
> orientation matters. if it doesn't just adjusting to the new size is what you
> should be doing anyway.

Ah... so applicaitons like, say, paroli, mokomaze, etc... need to pay attention
to XRRScreenChangeNotifyEvent ?

Rui

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

Re: Debuzzing

[Lech Karol Pawłaszek]

Steve Mosher wrote:
> Joerg, Dr. N and I have been discussing this. There is no need for the 
> HWD fix of 1024 as there is a software fix.
> The hwdware fix of 1024  would require much more work than the 
> debuzzing. Joerg recommends against it.
> I would agree.  I can have him come on here and explain. Even if the fix 
> were required we would still have
> to do a lot of work before it could be fielded. So, dont wait. get your 
> phone buzz fixed and use the software fix
> for 1024. A hardware fix is not likely.

Oh. You probably mean this:

http://lists.openmoko.org/pipermail/hardware/2009-May/001208.html

;-) I don't know how I've missed that mail. So no need to make Joerg
come here. Thanks.

I'll send my FR for debuzzing.

Kind regards,

-- 
Lech Karol Pawłaszek 
"You will never see me fall from grace" [KoRn]

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

Qi UI (was: Re: [Om2009] a community effort)

[Paul Fertser]

William Kenworthy  writes:
> On Sun, 2009-05-31 at 18:15 +0400, Paul Fertser wrote:
>> On Sun, May 31, 2009 at 03:47:04PM +0800, William Kenworthy wrote:
> ...
>> 
>> Look at AUX led. Enable whichever loglevel for kernel you like. Boot a
>> minimal kernel that will boot really fast.
>> 
>> Not a bootloader problem.
>> 
>
> I probably have not been clear enough - if the bootloader exits (as it
> was doing to me silently), you can go along blithely thinking that the
> phone was booted and working but it wasn't so I missed an important
> call.

No. Qi never (except when the battery is deeply discharged or on gta01
that lacks leds and vibrator) silently exits.

> The problem is that Qi doesnt give ANY feedback to a user, its always a
> worry - is it or isnt it booting? 

That's obviously not true. Read again about AUX led and vibrator
feedback.

> Granted that you can overide to force feedback

No, the feedback provided by Qi is always present and always identical
(unless you have a very discharged battery, in this case feedback is
disabled).

> but then why not use uboot which has proven reliable AND tells the
> user that something is happening faster than Qi will boot when in
> debug mode (so I presume from my memories of trying to test/time
> this).  I am not talking about kernel boot messages, but "something"
> every 10-15 seconds to reassure the user.

Qi takes about 2 seconds to boot the kernel. After that it can do
_nothing_ "to reassure the user" because the control is transfered to
the kernel. The same with u-boot.

> I have used a number of cheap mobiles, a treo650.  Thfamily have a range
> of mobiles up to an N95.  I have used quite a number of linux versions
> over the years - none, absolutely none including windows tells the user
> nothing like Qi does.  That if nothing else should tell how wrong Qi's
> operation is.

You use Qi only for 2-3 seconds on boot. And it provides feedback
during that time. Period.

> syndrome.  Again, I can only remember Andy saying he didnt like uboot,
> hence Qi, and Qi was going to be so much faster ...

If you like u-boot, go ahead, hack on u-boot. But don't think that
someone else must do that for you.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

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

Re: Om2009 testing release 4

[The Rasterman]

On Mon, 25 May 2009 17:20:08 +0100 Rui Miguel Silva Seabra  said:

> I'm sure it's not, AFAICT (since I don't know Parloi's internals) it doesn't
> touch anything Paroli or anything related to calls.
> 
> As for your problem with landscape vs portrait positions and GUIs... well,
> that's a problem that's not easy to solve unless all applications pay
> attention to a specific dbus signal which omnewrotate will send in the future.
> 
> This signal can be used by apps so they adjust their UI according to the
> display mode, but other than that, they all think they're in the same
> position.

no dbus signals needed. when x rotates,you'll get a configurenotify on root AND
an XRRScreenChangeNotifyEvent event (on root). These will also tell you your
orientation and new size. The WM, if smart, will resize your app window anyway,
so all you really need to do is, on resize, query x for the orientation, if
orientation matters. if it doesn't just adjusting to the new size is what you
should be doing anyway.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: Launcher/Home Page (alpha) Release 0.18

[jeremy jozwik]

c_c, if you get no reply from him let me know. making pritty things is about
all i can do for the openmoko community at the moment.

but youll have to wait a bit as im on vacation 180* around the globe from my
home. but id be very interested in making some things for this and intone

On Thu, May 28, 2009 at 1:19 PM, c_c  wrote:

>
> Hi,
> @ Warren Baird - Hey I saw that you're a digital artist. Can you contribute
> some wallpapers? :-) Just a thought.
>
>
>
> --
> View this message in context:
> http://n2.nabble.com/Launcher-Home-Page-%28alpha%29-Release-0.18-tp2969146p2985771.html
> Sent from the Openmoko Community mailing list archive at Nabble.com.
>
>
> ___
> 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: [Om2009] a community effort

[Rui Miguel Silva Seabra]

On Mon, Jun 01, 2009 at 02:46:19PM +0800, William Kenworthy wrote:
> and the clincher for me was that the gain using Qi (faster booting)
> didnt seem very much ... so why use it all?

There's also a much faster recover from suspend.

Rui

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