Re: OpenMoko Phase 0 has started

[Joe Pfeiffer]

Igor Foox writes:
>Just wanted to send a big Congratulations to the core OpenMoko team
>for this first shipment of phones. You guys are doing a great job and  
>even
>with the delays the community is (or at least I am) 100% behind you!

Absolutely!

And I think I'm speaking for far too many people when I ask:  what's
happening to the last 14 phones? :)

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

Re: OpenMoko Phase 0 has started

[mathew davis]

Congrats!  I am jealous that I don't have one yet.  Good job every one on
the dev teams.  I can't image it was easy.
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: OpenMoko Phase 0 has started

[Igor Foox]

Just wanted to send a big Congratulations to the core OpenMoko team
for this first shipment of phones. You guys are doing a great job and  
even

with the delays the community is (or at least I am) 100% behind you!

Happy hacking to all those who will receive the phone, and I hope  
that this

will help the FIC folks get a lot more testing of hardware issues!

Igor
(who can't wait to get his hands on a phase 1 phone :-P)

On 5-Mar-07, at 8:32 PM, Harald Welte wrote:


Hi!

The rumours have already spread, as several bloggers have already
reported: Yesterday [subject to time zone], Monday the 5th of March
2007, OpenMoko was finally able to start the Phase 0 of the OpenMoko
Neo1973 developer programme:

The Neo1973 Phase 0 phones have been shipped!

This means that by the end of this week, there will be 36 Free  
Software

developers around the world with a Neo1973 in their hands :)
(Why not 50? Go on reading)

After having releaed the current source code, and development  
resources

such as wiki, bugzilla and mailinglists almost four weeks ago, this
Phase 0 shipment now marks the next logical step: Hardware  
availability.


Unfortunately the current hardware revision GTA01Bv3 still has some
issues that are fixable in post-production rework, most notably too  
high

standby power consumption.  Due to those issues, the remaining 14
developers have chosen to rather wait until the next hardware  
revision.


The brave first 36 will obviously get a free fully working Neo1973 as
soon as they become available - which brings us to the second news  
item:


We have finalized the next revision called GTA01Bv4, which we  
expect to

be available in sample quantities roughly at the end of the month.
Let's hope this time we got everything right and can immediately  
proceed

to producing larger quantities.

In order to enable the Phase 0 developers to even literally "Open  
their

phone" (before freeing it by free software),  we actually packaged all
the tools required for opening and disassembling it:  Torx screwdriver
and guitar plectrum :)

The OpenMoko core team is sending a warm welcome to this first  
group of

36 developers.   We're looking forward to your feedback and help!

Once again our sincere apologies for delays and further delays.  We
werer striving to be above industry average - but have you ever seen
any reasonably complex hard/software project finish on time?  Murphys
law applies to all of us...

Happy hacking,

Harald (for the OpenMoko Core Team)
--
- Harald Welte <[EMAIL PROTECTED]>  	http:// 
openmoko.org/
== 
==

Software for the world's first truly open Free Software mobile phone

___
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

Idea: Location based reminders

[Igor Foox]

Hi,

I just added this to the wiki:
http://wiki.openmoko.org/wiki/Wishlist:Location_based_reminders

It's a bit related to context based todo list (http:// 
wiki.openmoko.org/wiki/Wishlist:context_based_to-do_list) but a  
different type of event.
I came up with the idea today when I was working on my laptop on a  
bus ride and missed my bus stop.

Any further ideas or clarifications on the idea are most welcome!

Igor

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

Re: coverage at linuxdevices.com

[wim delvaux]

On Tuesday 06 March 2007 03:02:38 Andreas Kostyrka wrote:
> * Marcin Juszkiewicz <[EMAIL PROTECTED]> [070305 07:35]:
> > Dnia niedziela, 4 marca 2007, Joe Pfeiffer napisał:
> > > Andreas Kostyrka writes:
> > > >Just wondering, but did I get that right, the Hackers version that
> > > >will be available this month will only be a developers board, without
> > > >a phone casing => unuseable as a mobile phone in day-to-day
> > > >operations, right?
> > >
> > > My understanding is that the $350 "standard kit" will be a real live
> > > phone, though a bit rough around the edges.  You seem to be describing
> > > the $250 "hacker's lunchbox".
> >
> > Hacker's lunchbox is EXTRA equipment (costs 200 USD) to normal package of
> > Neo1973 (costs 350 USD).
> >
> > So Hacker's lunchbox version is 550 USD in total. Thats how I understand
> > it and I think that this is how it looks.
>
> Well, that doesn't seem to be the answer in this case, because the
> $350 package won't be available before Summer, right?

No, AFAIK it will available but in a 0-version.  the summer we will see 
an 'update'/'upgrade'.  the lunchbox version (name will be changed I think), 
will be only for those ppl. that need to mess with hardware 

>
> Andreas
>
> ___
> 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: coverage at linuxdevices.com

[Andreas Kostyrka]

* Marcin Juszkiewicz <[EMAIL PROTECTED]> [070305 07:35]:
> Dnia niedziela, 4 marca 2007, Joe Pfeiffer napisał:
> > Andreas Kostyrka writes:
> 
> > >Just wondering, but did I get that right, the Hackers version that
> > >will be available this month will only be a developers board, without
> > >a phone casing => unuseable as a mobile phone in day-to-day
> > >operations, right?
> 
> > My understanding is that the $350 "standard kit" will be a real live
> > phone, though a bit rough around the edges.  You seem to be describing
> > the $250 "hacker's lunchbox".
> 
> Hacker's lunchbox is EXTRA equipment (costs 200 USD) to normal package of 
> Neo1973 (costs 350 USD). 
> 
> So Hacker's lunchbox version is 550 USD in total. Thats how I understand 
> it and I think that this is how it looks.

Well, that doesn't seem to be the answer in this case, because the
$350 package won't be available before Summer, right?

Andreas

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

Re: GPS for 911 calls

[Martin Lefkowitz]

Yes, but for VoIP I believe it is still in flux.  There is an especially 
nasty issue with encryption and 802.11 with the way the standard is 
described because it assumes you are already on the network.  However 
with 802.1x based systems you need to be authenticated.  As far as I 
know this has not completely been worked out. 

It would be great to take advantage of GPS to do this from the 
Application layer without having to modify the 802.11 driver and to send 
802.11 MAC frames.  You also need to make sure you do not send GPS 
coordinates unencrypted because that can be a life and death issue (for 
example a bad guy trying to figure out exactly where the victim is, by 
sniffing the air).  In fact OpenMoko may enable the described scenario 
to happen. 



I can't remember how emergency calls work in regards to TMSI in GSM.

Marty

Date: Mon, 05 Mar 2007 18:56:08 -0500 From: "Perry E. Metzger" 
<[EMAIL PROTECTED]> Ian Stirling <[EMAIL PROTECTED]> writes:

> Michael Welter wrote:


>> What is the protocol for sending the GPS coordinates to the 911 dispatcher?
  

>
> I don't think there is one protocol.
> Unfortunately, I suspect a 'say GPS coordinates' button on the 911
> screen may be the most compatible way.



Wireless Enhanced 911 for mobiles, including GPS or other
radiolocation data, is a US standard. I don't know how the signaling
works, but if you are selling a new phone in the US, it is mandatory
that you comply.

Perry




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

OpenMoko Phase 0 has started

[Harald Welte]

Hi!

The rumours have already spread, as several bloggers have already
reported: Yesterday [subject to time zone], Monday the 5th of March
2007, OpenMoko was finally able to start the Phase 0 of the OpenMoko
Neo1973 developer programme:

The Neo1973 Phase 0 phones have been shipped!

This means that by the end of this week, there will be 36 Free Software
developers around the world with a Neo1973 in their hands :)
(Why not 50? Go on reading)

After having releaed the current source code, and development resources
such as wiki, bugzilla and mailinglists almost four weeks ago, this
Phase 0 shipment now marks the next logical step: Hardware availability.

Unfortunately the current hardware revision GTA01Bv3 still has some
issues that are fixable in post-production rework, most notably too high
standby power consumption.  Due to those issues, the remaining 14
developers have chosen to rather wait until the next hardware revision.

The brave first 36 will obviously get a free fully working Neo1973 as
soon as they become available - which brings us to the second news item:

We have finalized the next revision called GTA01Bv4, which we expect to
be available in sample quantities roughly at the end of the month.
Let's hope this time we got everything right and can immediately proceed
to producing larger quantities.

In order to enable the Phase 0 developers to even literally "Open their
phone" (before freeing it by free software),  we actually packaged all
the tools required for opening and disassembling it:  Torx screwdriver
and guitar plectrum :)

The OpenMoko core team is sending a warm welcome to this first group of
36 developers.   We're looking forward to your feedback and help!

Once again our sincere apologies for delays and further delays.  We
werer striving to be above industry average - but have you ever seen
any reasonably complex hard/software project finish on time?  Murphys
law applies to all of us...

Happy hacking,

Harald (for the OpenMoko Core Team)
-- 
- Harald Welte <[EMAIL PROTECTED]>  http://openmoko.org/

Software for the world's first truly open Free Software mobile phone

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

Re: Itch3: Anti-lost/theft protection

[t3st3r]

Marcel de Jong wrote:

On 3/4/07, t3st3r <[EMAIL PROTECTED]> wrote:


FYI: just to let you know, an anti-thief\anti-lost system for phones
already exists.Here is the story.Maybe someone already heard that
proprietary Siemens mobile phones (x55 series based on 80C166 CPU and
x65 and x75 series based on ARM9) were reverse-engineered deeply and
people has bypassed boot loader protection (preventing user's code from
being uploaded) so everyone can run it's own code on phone's CPU.Also I
heard some other vendors were hacked successfully as well.Some
SonyEricsson for example.

One of the first firmware patches has been the anti-thief subsystem.How
does it works?It does detects SIM card change (by IMSI checking IIRC)
and then SMSes to predefined number(s) (should be someone of your family
or friends of course).This reveals new phone number (allowing to take a
legal actions) and can allow owner to regain remote control, get
coordinates (actually, on Siemens phones you can get Cell ID at very
most, funny enough anyway).



But how does this affect resale of the device? Because then the new
owner inserts a new SIMcard, and then this mechanism would go active,
wouldn't it?
This subsystem was invented by geeks and intended for smart users only - 
you have to apply binary patch to firmware to use this. Of course you 
have to shut this subsystem down before selling phone. Or tell new owner 
how to deal with it if he\she is smart enough.But actually I have to 
admit that before selling phone it is a good idea to

1) revert all patches, if any (upload factory firmware)
2) reset all phone settings to factory defaults (and address 
books\SMSes as well)

3) revert filesystem to factory state.
At this point at least you're free from being bothered by new owner with 
any sort of firmware\settings problems and do not leak your private 
data.Ideal solution is to make FULL firmware backup of new phone (whole 
flash IC dumped) and when you're about to sell phone, just upload this 
backup before you're selling it (therefore returning device to backed up 
state, completely trashing private data and all things you messed 
up).Unfortunately, at home this is possible for some phones only (yep, 
Siemens phones for example) and this may require unreasonable efforts 
for some others.

I'm just curious, it sounds like an interesting idea.
Btw there is some problem.If this solution is default and popular, 
thieves and "lucky people" may become aware of it and may do something 
against this.So in general this will work only while solution is not 
very popular\custom\invisible.






---
Marcel de Jong

___
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: GPS for 911 calls

[Perry E. Metzger]

Ian Stirling <[EMAIL PROTECTED]> writes:
> Michael Welter wrote:
>> What is the protocol for sending the GPS coordinates to the 911 dispatcher?
>
> I don't think there is one protocol.
> Unfortunately, I suspect a 'say GPS coordinates' button on the 911
> screen may be the most compatible way.

Wireless Enhanced 911 for mobiles, including GPS or other
radiolocation data, is a US standard. I don't know how the signaling
works, but if you are selling a new phone in the US, it is mandatory
that you comply.

Perry

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

Re: Yet another finger keybord (gui mock-up).

[Paul M]

On Mon, 2007-03-05 at 13:50 +0100, Gabriel Ambuehl wrote:
> On Monday 05 March 2007 11:34:47 Lars Hallberg wrote:
> > Should be as clear as on the pictures... But You might need to look
> > close... But the neo case have a hole for the nose for that special
> 
> Clear yes, but also about 3 times smaller than on your desktop screen...
> 
> > purpose :-) Hopefully, You soon learn where the keys are.
> 
> Which gives rise to the question of how to best arrange them...
> 

I have been thinking along very similar lines to this idea, except that
I have been envisioning this as a stylus application. However I think it
makes a lot of sense to have as an input method for both finger and
stylus. From a stylus point of view it makes sense to treat the centre
as a neutral or home position with letters being determined
 by the subsequent movements you make* (as drag vectors). This way you
would not need to lift the stylus off the screen** -- movement would be
relative to the position of the stylus at the end of the last letter.  I
think you could write very fast like this.

*a hexagon arrangement would give you all the alphabet + common
punctuation in unique combinations of two strokes. (Modifier keys/areas
could be added for more). This would be very quick and easy to learn.

** Unless you were getting close to the edge -- but since movement would
be relative you could just pick it up and re-center it.

> 
> If you use drag vectors instead of actual taps on the buttons, you might get 
> away with very short drags, really.
> 

Agreed treating it as vectors rather than as an absolute position makes
it much more flexible.

Paul M
-- 
  "There are no innocent bystanders,
what were they doing there in the first place?"
 William S. Burroughs


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

Re: Near field communication NFC

[Bruce Deschamps]

Hello,

Great to hear that NFC technology is also a growing trend amoung the open
source world!!!

I am studying until the end of  october at the university of Nice Sophia
Antipolis in Southern East of France (diploma called "Master MBDS").  A
master's degree in computer sciences specialized in "communicating objects,
databases and web technologies". We are working on many different projects
related to RFID. (NFC payment, healthcare, business,etc...)

Do not hesitate to contact me if you need more information.

Bruce
+33 6 61 68 72 17


2007/3/5, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:





High Bruce



This is preciely what we have had in mind to do, Both for RFID and the
barcodes with a little help from our friend in EPR forum and OASIS

Please do stay in touch and I wil come back to you in th enear future at
what university are you ?


Sincerely PA Fronth Nyhus

EPRForum
+47 9268 9268



On Monday, March 05, 2007, at 10:55AM, "Bruce Deschamps" <
[EMAIL PROTECTED]> wrote:
>Hi all,
>
>My name is Bruce, I recently subscribe to the community list and I have
been
>reading a few of the very interesting threads you've been talking about.
I
>was wondering if  any of you had thought about near field communication
>capabilities like using RFID reader and chips to deal with payment,
>ticketing, infotainment, or entreprise solutions like tracking by using
the
>neo1973 and openMoko Framework?
>
>I have been starting working on this kind of project this year at
university
>but til now we've only had  proprietary solutions from NXP , Nokia and so
>on. I was wondering if there was any possibility to integrate this
>functionnality into our upcoming Neo and openMoko?
>
>I would be glad to hear about it if anyone has some info...
>
>Cheers
>Bruce
>
>--
>http://bruce.deschamps.free.fr/
>[EMAIL PROTECTED]
>





--
Bruce Deschamps
1380, route d'Antibes
Hameau des Oliviers
06560 Valbonne
Mobile: 06 61 68 72 17
Dom.:04 92 98 18 64
[EMAIL PROTECTED]
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Yet another finger keybord (gui mock-up).

[Joe Pfeiffer]

adrian cockcroft writes:
>This technology is eventually going to be available on Linux according
>to the author, there was a demo at ETel.
>
>http://www.almaden.ibm.com/u/zhai/shapewriter.htm

Very interesting -- I've been looking forward to quikwriting;

http://mrl.nyu.edu/projects/quikwriting/

I find myself wondering if shapewriter will work just as well, since
they'll both end up using our shape memory...



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

Re: Neologics

[Stefan Schmidt]

Hello.

On Mon, 2007-03-05 at 10:47, Pranav Desai wrote:
> On 3/4/07, Stefan Schmidt <[EMAIL PROTECTED]> wrote:
> >
> >No, it is only needed if you break your bootloader. Everything besides
> >this is recoverable with the installed bootloader.
> 
> Will it be possible to add a wiki page specifying how not to break the
> bootloader and other things first time developers shouldn't do to make
> the hardware unusable ?

Everything should be designed to not break the bootloader during
normal development and even software upgrades. In the end it's a
device for enduser, which means it have to be enduser compatible. :)

regards
Stefan Schmidt


signature.asc
Description: Digital signature
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Neologics

[Pranav Desai]

On 3/4/07, Stefan Schmidt <[EMAIL PROTECTED]> wrote:

Hello.

On Sat, 2007-03-03 at 19:18, Pranav Desai wrote:
> On 3/1/07, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote:
>
> In the presentation its mentioned that the debug board will cost an
> additional $200. How important is the debug board for phase 1 phones ?
> Can we update the firmware drivers and put software, kernel, etc. on
> it without the board?

No, it is only needed if you break your bootloader. Everything besides
this is recoverable with the installed bootloader.



Thanks Stefan.

Will it be possible to add a wiki page specifying how not to break the
bootloader and other things first time developers shouldn't do to make
the hardware unusable ?

-- Pranav


Sometimes it can make life easier as you can do step debugging with
the JTAG, but for normal development, even kernel, it is not needed.

regards
Stefan Schmidt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://www.datenfreihafen.org/contact.html

iD8DBQFF6rDXbNSsvd31FmURAmuQAKCM59iT/YJe3YdLCyHFHuenVj8IXQCgrgQC
botGrI6368G6BXEsrW/He9Q=
=g9zb
-END PGP SIGNATURE-

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





--

--
http://pd.dnsalias.org

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

Near field communication

[Bruce Deschamps]

Hi all,

My name is Bruce, I recently subscribe to the community list and I have been
reading a few of the very interesting threads you've been talking about. I
was wondering if  any of you had thought about near field communication
capabilities like using RFID reader and chips to deal with payment,
ticketing, infotainment, or entreprise solutions like tracking by using the
neo1973 and openMoko Framework?

I have been starting working on this kind of project this year at university
but til now we've only had  proprietary solutions from NXP , Nokia and so
on. I was wondering if there was any possibility to integrate this
functionnality into our upcoming Neo and openMoko?

I would be glad to hear about it if anyone has some info...

Cheers
Bruce

--
http://bruce.deschamps.free.fr/
[EMAIL PROTECTED]
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Yet another finger keybord (gui mock-up).

[adrian cockcroft]

This technology is eventually going to be available on Linux according
to the author, there was a demo at ETel.

http://www.almaden.ibm.com/u/zhai/shapewriter.htm

Adrian

On 3/5/07, Joe Pfeiffer <[EMAIL PROTECTED]> wrote:

[EMAIL PROTECTED] writes:
>
>How about making use of AI techniques and having the layout self-adjust to
>generate a layout that pushes frequently used letters to the right places, and
>then arranges the surrounding letters to reduce typos? If this consumes too
>much processing power for normal use, there could be a separate "learning"
>mode during which you would tolerate the slowness, and later switch to fixed
>mode. Or it could be like SpamAssassin - keystrokes (both correct and
>incorrect) are logged in some efficient way, and later you can "train" the
>layout "engine" when the device is not in use, perhaps even pushing the
>processing to a different computer.

That would not be a good idea:  there is no key layout so bad that's
it's worse than one that changes out from under the user.

___
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: Yet another finger keybord (gui mock-up).

[Joe Pfeiffer]

[EMAIL PROTECTED] writes:
>
>How about making use of AI techniques and having the layout self-adjust to
>generate a layout that pushes frequently used letters to the right places, and
>then arranges the surrounding letters to reduce typos? If this consumes too
>much processing power for normal use, there could be a separate "learning"
>mode during which you would tolerate the slowness, and later switch to fixed
>mode. Or it could be like SpamAssassin - keystrokes (both correct and
>incorrect) are logged in some efficient way, and later you can "train" the
>layout "engine" when the device is not in use, perhaps even pushing the
>processing to a different computer.

That would not be a good idea:  there is no key layout so bad that's
it's worse than one that changes out from under the user.

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

Re: GPS for 911 calls

[Martin Lefkowitz]

There is an IETF group (BOF?) looking into this.  802.11k and v are also 
trying to provide some solutions, but they are uncoordinated as far as I 
know.  IMHO it needs to be an IETF solution because of the converged 
devices that are cropping up.  I'm not sure anyone has lifted their 
heads out of -- the sand -- yet on this though.


Marty

Date: Mon, 05 Mar 2007 15:17:03 + From: Ian Stirling 
<[EMAIL PROTECTED]> Subject: To: Michael Welter 
<[EMAIL PROTECTED]> Cc: community@lists.openmoko.org Message-ID: 
<[EMAIL PROTECTED]> Content-Type: text/plain; 
charset=ISO-8859-1; format=flowed Michael Welter wrote:

> What is the protocol for sending the GPS coordinates to the 911 dispatcher?
> 



I don't think there is one protocol.
Unfortunately, I suspect a 'say GPS coordinates' button on the 911 
screen may be the most compatible way.




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

Re: Yet another finger keybord (gui mock-up).

[michael]

On Mon, 5 Mar 2007, Ian Stirling wrote:


Gabriel Ambuehl wrote:

 On Monday 05 March 2007 11:34:47 Lars Hallberg wrote:
>  Should be as clear as on the pictures... But You might need to look
>  close... But the neo case have a hole for the nose for that special

 Clear yes, but also about 3 times smaller than on your desktop screen...

>  purpose :-) Hopefully, You soon learn where the keys are.

 Which gives rise to the question of how to best arrange them...



Ideally - if designing it from a completely clean sheet, you want it so that 
'typos' result in very different letters.


 a
e 0 i
  o

would be a spectacularly bad pick, for example, whereas

 a
d 0 q
  f

might be good.

This is so autocorrection software can function well.



How about making use of AI techniques and having the layout self-adjust to
generate a layout that pushes frequently used letters to the right places, and
then arranges the surrounding letters to reduce typos? If this consumes too
much processing power for normal use, there could be a separate "learning"
mode during which you would tolerate the slowness, and later switch to fixed
mode. Or it could be like SpamAssassin - keystrokes (both correct and
incorrect) are logged in some efficient way, and later you can "train" the
layout "engine" when the device is not in use, perhaps even pushing the
processing to a different computer.

Additionally, one might even have different layouts for different activities -
emailing friends might have a different vocabulary, and hence suggest a
different layout, than C programming. Although I recognize that at some point
the inefficiency of remembering the layout in different modes offsets any
advantage of the layout efficiency. But, having the choice might be
interesting. At the very least I may want to experiment with a new layout but
retain the ability to switch back to a previous layout.

I know, somewhat extreme, but at this early brainstorming stage I like
thinking extreme.

Michael

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

Re: Yet another finger keybord (gui mock-up).

[Lars Hallberg]

Gabriel Ambuehl skrev:

On Monday 05 March 2007 11:34:47 Lars Hallberg wrote:

Should be as clear as on the pictures... But You might need to look
close... But the neo case have a hole for the nose for that special


Clear yes, but also about 3 times smaller than on your desktop screen...


You can always take a closer look by pressing a button, and drag out of 
the 'splash' if it's wrong.



Which gives rise to the question of how to best arrange them...


Yes.. I'm most unhappy about esc and del, and I want to get PG Up and Pg 
Dn in there to.


The numbers are OK, The letters reuse knowledges that T9 users have. The 
 3 buttons at the right feels OK, as do the cursorcontrolls.


Add another button that allows to tap shortcuts (for example like it is done 
in some of the vnc clients). In general, I find I'm using LESS keys for 
terminal work than for text entry. YMMV.


Is not this more the apps responsibility The messenger app know who 
I'm typing to, and can analyse what I usably type to that person.


I meant for the second level, where they are essentially already in a 
hexagonal shape...


Yes, hexagons is better then yes.. just harder to mock up ;-)


I think the size is close to optimal with 6 buttons wide (but it must be
tested on a neo to be sure). The total area is not to big and high, and
the 'drags' is not so long. 


If you use drag vectors instead of actual taps on the buttons, you might get 
away with very short drags, really.


To short drag might make it hard to just tap the 'central' button. But 
the splash should come up centered round the actual press point, not the 
pressed buttons center. That way ju can just strike your key... a 
reasonable right strike starting in the reasonable right spot will work.



One question is if the scroll wheel is needed simultaneous with the
keyboard. That would else leave room for 4 buttons (24 keys) more. But
in that case maybe 5*3 with 'space' on the sides so all buttons can have
all 7 combinations would be better... 5*3*7 - 105 keys.


Do you really need all those keys?


XHTML with embedded both javascript and embedded PHP with embedded 
SQL... Lots of strange chars... Then there's the editors. A lot of stuff 
use emacs key binding. Other 'windows' style (like press shift and move 
the cursor to mark)...


~90 should work. A lot of char may be changed when shift is pressed. And 
removing the 3 boxes frees 3 keys... but as the strokes still is slower 
than typing on a real keyboard, keeping the number of needed strokes 
down is good. so many keys is good.


/LaH


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

Fw: Re: Possible security hole for Dialers/troyan horses

[Tim Newsom]

Sorry, got caught in the reply to issue.

-Original Message-
From: Tim Newsom <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Possible security hole for Dialers/troyan horses
Date: Mon, 5 Mar 2007 7:02:58 -0800


On Mon, 5 Mar 2007 0:05, Evgeny wrote:

On Fri, 2007-03-02 at 07:35 -0800, Tim Newsom wrote:

 On Fri, 2 Mar 2007 6:09, Evgeny wrote:
 >
 > It still Linux based phone — there is absolutely no real-life 
viruses

 > for Linux at this time, trojans are possible treat, but user have to
 > install them by himself.

 That's a pretty strong statement.. Are you absolutely sure there are 
no

 viruses for linux in the wild?

Nope.
If you find one, let me know I'll get, compile $ run "the beast" a
little (In virtual machine of course).
Well if & then you speak about trojans, the cure is "DO NOT INSTALL
THEM". Security holes may exist, but patching them is simple then you
know about them, and in OpenMoko it will be automated by "ipkg".
Read trough  http://tldp.org/HOWTO/Security-HOWTO/ it contains some
basics of security in Linux.
When we will speak  the same language.
There is no Norton Internet security, that can protect you from unknown
treats. When you know about trojan or something, you simple don't use
(it if you don't wont to).
--
Sincerely Evgeny


I realize nothing can protect you from every possible manner of attack, 
but I do know there are vulnerabilities that exist in linux.  If not, 
SELinux would not have been necessary.  If you say there are no viruses, 
I would say that's either because no one has written them or they are 
just not popular right now because windows is a much easier target to 
hit.  My statement was that something like Norton Internet Security 
combined with the ability to run programs in isolated memory should 
provide a lot of protection.  The isolated memory would prevent the 
infected programs from accessing the memory of other running programs 
(something that's possible on windows for sure) and the anti-malware 
program could do like someone previously suggested and check a hash of 
the program to see if it is a known and accepted version with allowed 
rights, etc.  Maybe check the hash and a signature so show 
authenticity?


While you can't detect unknown threats automatically (though I thought 
an anti-virus company said they could do that recently) you can block 
the unexpected behaviors automatically and recommed to the user certain 
actions.


Remember, there are rootkits out there too. Maybe it would be nice to 
have a startup mode where the system goes into rootkit detection mode 
and scans the physical memory of the device and filesystem or 
something.


Regardless, I think its better to have a pound of caution when a half 
pound would do...

--Tim
--Tim
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Yet another finger keybord (gui mock-up).

[Gabriel Ambuehl]

On Monday 05 March 2007 16:43:38 Florent THIERY wrote:
> For instance, type on a text input area; background (app) stays the
> same, the keyboard shows up, 80% transparent, but using optimized
> coloring (for instance, taking the exact negative of the background on
> every point), so that it's still readable.

I don't think the first Neo based upon s3c2410 is powerful enough for 
transparency like that (yes that means the mockups on the wiki won't be real 
for a while). However, the summer refresh supposedly should be.


pgpJxTyBPOntb.pgp
Description: PGP signature
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: GPS for 911 calls

[Attila Csipa]

On Monday 05 March 2007 16:17, Ian Stirling wrote:
> Unfortunately, I suspect a 'say GPS coordinates' button on the 911
> screen may be the most compatible way.

Not sure if coordinates are going to help you much, a 'closest' real-life 
address might be more helpful, but it's a question just how close is there 
something you can reference to electronically. Also, not sure about the per 
country implementation, f.e. our 911 here does not really like automated 
calls (automated alerts & silent alarms go to a different number and are 
generally not available through mobile phones).

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

Re: Yet another finger keybord (gui mock-up).

[Florent THIERY]

About the graphics part, there's something i always found frustrating
with existing virtual keyboards (say, the motorola EZX one): they
remain hidden most of the time, but when you start typing in a text
area, the keyboard appears, taking 70% of the screen.

What could be done here (but it depends on the graphics capabilities
of openmoko), is a fully transparent keyboard, letting you see what's
under, so that text input is optimized for unobtrusivity.

For instance, type on a text input area; background (app) stays the
same, the keyboard shows up, 80% transparent, but using optimized
coloring (for instance, taking the exact negative of the background on
every point), so that it's still readable.

About autocompletion/T9: are there plans for or already existing T9
implementations ?

Florent

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

Re: GPS for 911 calls

[Ian Stirling]

Michael Welter wrote:

What is the protocol for sending the GPS coordinates to the 911 dispatcher?



I don't think there is one protocol.
Unfortunately, I suspect a 'say GPS coordinates' button on the 911 
screen may be the most compatible way.


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

GPS for 911 calls

[Michael Welter]

What is the protocol for sending the GPS coordinates to the 911 dispatcher?

--
Michael Welter
Telecom Matters Corp.
Denver, Colorado US
+1.303.414.4980
[EMAIL PROTECTED]
www.TelecomMatters.net

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

Re: Idea: Mass Text Messaging

[Cathal O'Brien]

I can send a single text message to a group of people by just selecting the
people in my phone book when i go to send a text. I know my old phone wasn;t
able to do this but my new Motorola phone can, so I expect any recent
motorola phone can do this already.


--
Cathal O'Brien
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Yet another finger keybord (gui mock-up).

[Jonathon Suggs]

Ian Stirling wrote:
Ideally - if designing it from a completely clean sheet, you want it 
so that 'typos' result in very different letters.


  a
e 0 i
  o

would be a spectacularly bad pick, for example, whereas

  a
d 0 q
  f

might be good.

This is so autocorrection software can function well.

Then there is the fun question of how many 'initial' points, and how 
many vectors per point.
10 numbers, with 8 drags from each number gives you alphanumeric, and 
easily 30 common phrases, or word components.

'I'll be ' 'home ' 'at ' '6' 'P' 'M' ' ' 'Love you!'
In 8 strokes.

If you go slightly further, and each stroke can either terminate 
normally, go longer, go clockwise, go anticlockwise, or return, that 
takes you up to 5 per stroke, or 400 'keys'.


It would be lovely if this was incrementally learnable.

First level - press 0, hold, get
  d
a 0 q
  f
splashing out.

Once you're comfortable, you get
D d Q
a 0 q
A f F

Drag and hold to F, and you get

Finish First


Found F


Find Friday

( down-right stroke from 0 = F, turning clockwise is Find )

And the words for 'f' might be 'food, friend, ...'

Being silly, you can then hold on food, and go out to 'pizza, chips, 
kebab, lunch'


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
One thing to do is look at existing designs for reference/inspiration.  
I mentioned the fitaly layout in a different post, but here is a link to 
help with the visualization.

http://www.fitaly.com/wince/pocketpcfitaly.htm

Auto-correction software is great when it works, but annoying when it 
doesn't.  So it should be configurable and not mandatory.  You had some 
good ideas in there.  The food => 'pizza, chips, kebab, lunch' is 
stretching it a little bit, but still not a bad idea.


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

Re: Yet another finger keybord (gui mock-up).

[Jonathon Suggs]

Gabriel Ambuehl wrote:

Clear yes, but also about 3 times smaller than on your desktop screen...
  
First, I really like this idea for input and think it has potential to 
being very intuitive while allowing a decent input rate.


That said, the screen size (and corresponding button size) is an issue 
to be conscious of.  You want to find the happy medium where you make 
the most efficient use of as little space as possible.  As you make the 
button input area larger, you are taking up more of the application 
area.  But without seeing how this would look on the actual device, it 
at least looks like a good ratio.


Which gives rise to the question of how to best arrange them...
  
That is a question that people will probably have different opinions 
on.  How much effort would it be to have several different layouts.  
Some with more characters, some with less.  Some more similar to qwerty 
other more sequential (abc...) and possibly others mimicking fitaly.  
You could define your default layout as a preference.  And you could 
switch between layouts at any time (possibly via the scroll-wheel or 
other method).
Add another button that allows to tap shortcuts (for example like it is done 
in some of the vnc clients). In general, I find I'm using LESS keys for 
terminal work than for text entry. YMMV.
  
See everybody has their own unique usage requirements.  So lets keep it 
flexible to accommodate the most amount of people possible.

I think the size is close to optimal with 6 buttons wide (but it must be
tested on a neo to be sure). The total area is not to big and high, and
the 'drags' is not so long. 



If you use drag vectors instead of actual taps on the buttons, you might get 
away with very short drags, really.
  
Exactly.  I don't think it would be that hard.  You've got 60deg of area 
for an accurate hit.  Also, having the background of the keys change as 
you are on the key gives great visual feedback.
Do you really need all those keys? I generally don't. Then again, I don't plan 
on doing non emergency work in terminals either... And on a notebook you 
usually don't have all of them for direct access, either.
  
Again, just showing that different people have different opinions.  Lets 
try to make it useful for everyone.  I would prefer less keys, but that 
is just me.


Heres another thought.  Don't know how it would work/feel, but it might 
give good tactile feedback to give a quick vibration pulse after every 
key press (on the release).  It might help to minimize the disjoint that 
can sometime happen with you are just touching a flat surface.  One step 
further, it might also help if it gave a quick vibration when you 
dragged into different areas.  That way you could tell via touch when 
you were in the different sectors.


Keep the ideas going.  This is one of the best to come out in a while!

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

Re: Idea: Mass Text Messaging

[Steven **]

My crappy Verizon locked-down phone already allows multiple to
addresses.  It also allows assigning contacts to pre-assigned groups.
Sounds like you'd like the address book to allow arbitrary grouping
and the ability to address a message to a group.  Seems pretty simple.
I'd suspect it could be integrated into the existing contacts/SMS
application pretty easily.

-Steven

On 3/4/07, Ryan Kline <[EMAIL PROTECTED]> wrote:

I repeatedly find myself in situations similar to this:
I am at the mall with my parents and want to know if any of my
friends are at the mall. I text individual friends (awkwardly) to ask
if they are at the mall.
Most of the time (99.99%) they are not, but still

Anyway, my idea is a mass text feature that allows you to text a
group of people all at the same time (with some kind of hint that the
text has been sent to others)

Can anyone make this happen?

-ryan

___
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: Yet another finger keybord (gui mock-up).

[Ian Stirling]

Gabriel Ambuehl wrote:

On Monday 05 March 2007 11:34:47 Lars Hallberg wrote:

Should be as clear as on the pictures... But You might need to look
close... But the neo case have a hole for the nose for that special


Clear yes, but also about 3 times smaller than on your desktop screen...


purpose :-) Hopefully, You soon learn where the keys are.


Which gives rise to the question of how to best arrange them...



Ideally - if designing it from a completely clean sheet, you want it so
that 'typos' result in very different letters.

  a
e 0 i
  o

would be a spectacularly bad pick, for example, whereas

  a
d 0 q
  f

might be good.

This is so autocorrection software can function well.

Then there is the fun question of how many 'initial' points, and how
many vectors per point.
10 numbers, with 8 drags from each number gives you alphanumeric, and
easily 30 common phrases, or word components.
'I'll be ' 'home ' 'at ' '6' 'P' 'M' ' ' 'Love you!'
In 8 strokes.

If you go slightly further, and each stroke can either terminate
normally, go longer, go clockwise, go anticlockwise, or return, that
takes you up to 5 per stroke, or 400 'keys'.

It would be lovely if this was incrementally learnable.

First level - press 0, hold, get
  d
a 0 q
  f
splashing out.

Once you're comfortable, you get
D d Q
a 0 q
A f F

Drag and hold to F, and you get

Finish First


Found F


Find Friday

( down-right stroke from 0 = F, turning clockwise is Find )

And the words for 'f' might be 'food, friend, ...'

Being silly, you can then hold on food, and go out to 'pizza, chips,
kebab, lunch'


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

Re: Yet another finger keybord (gui mock-up).

[Ian Stirling]

Gabriel Ambuehl wrote:

On Monday 05 March 2007 11:34:47 Lars Hallberg wrote:

Should be as clear as on the pictures... But You might need to look
close... But the neo case have a hole for the nose for that special


Clear yes, but also about 3 times smaller than on your desktop screen...


purpose :-) Hopefully, You soon learn where the keys are.


Which gives rise to the question of how to best arrange them...



Ideally - if designing it from a completely clean sheet, you want it so 
that 'typos' result in very different letters.


  a
e 0 i
  o

would be a spectacularly bad pick, for example, whereas

  a
d 0 q
  f

might be good.

This is so autocorrection software can function well.

Then there is the fun question of how many 'initial' points, and how 
many vectors per point.
10 numbers, with 8 drags from each number gives you alphanumeric, and 
easily 30 common phrases, or word components.

'I'll be ' 'home ' 'at ' '6' 'P' 'M' ' ' 'Love you!'
In 8 strokes.

If you go slightly further, and each stroke can either terminate 
normally, go longer, go clockwise, go anticlockwise, or return, that 
takes you up to 5 per stroke, or 400 'keys'.


It would be lovely if this was incrementally learnable.

First level - press 0, hold, get
  d
a 0 q
  f
splashing out.

Once you're comfortable, you get
D d Q
a 0 q
A f F

Drag and hold to F, and you get

Finish First


Found F


Find Friday

( down-right stroke from 0 = F, turning clockwise is Find )

And the words for 'f' might be 'food, friend, ...'

Being silly, you can then hold on food, and go out to 'pizza, chips, 
kebab, lunch'


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

Re: Yet another finger keybord (gui mock-up).

[Gabriel Ambuehl]

On Monday 05 March 2007 11:34:47 Lars Hallberg wrote:
> Should be as clear as on the pictures... But You might need to look
> close... But the neo case have a hole for the nose for that special

Clear yes, but also about 3 times smaller than on your desktop screen...

> purpose :-) Hopefully, You soon learn where the keys are.

Which gives rise to the question of how to best arrange them...

> Yes, it's that 'spalash' effect of adjacent keys that's the main
> concept,  not the exact layout. However.. 36 keys may be good for
> entering contacts data... but I *want* a full-blown keyboard level of
> functionality. For me, a common use case is remote admin of servers with
> ssh... and any legacy terminal app may be used (completely unaware of
> 'mobile envirionment').

Add another button that allows to tap shortcuts (for example like it is done 
in some of the vnc clients). In general, I find I'm using LESS keys for 
terminal work than for text entry. YMMV.

> > [1] which brings me to the point that maybe round buttons aren't the most
> > efficient way of doing it?
> Round match hexagons well. Putting them in a square layout is
> suboptimal, 
 
I meant for the second level, where they are essentially already in a 
hexagonal shape...

> I think the size is close to optimal with 6 buttons wide (but it must be
> tested on a neo to be sure). The total area is not to big and high, and
> the 'drags' is not so long. 

If you use drag vectors instead of actual taps on the buttons, you might get 
away with very short drags, really.

> One question is if the scroll wheel is needed simultaneous with the
> keyboard. That would else leave room for 4 buttons (24 keys) more. But
> in that case maybe 5*3 with 'space' on the sides so all buttons can have
> all 7 combinations would be better... 5*3*7 - 105 keys.

Do you really need all those keys? I generally don't. Then again, I don't plan 
on doing non emergency work in terminals either... And on a notebook you 
usually don't have all of them for direct access, either.


pgpczEfdZkzC6.pgp
Description: PGP signature
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Yet another finger keybord (gui mock-up).

[Krzysztof Kajkowski]

I find this idea interesting but I thought of some modification - what
about using there full QWERTY keyboard?

There could be something like miniature keyboard displayed at the
buttom but in QWERTY layout. You could use thumbs to press keys (more
accuartely: areas where keys are - your thumb would press more than
one key at a time). On each key press, the part of keyboard that you
pressed could be zoomed and you would be able to choose the key you
wanted to enter (keys would be bigger now because they lay in zoomed
aread).

That could be pretty fast way of inserting data, using your thumbs, on
small screen keyboard.

cayco

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

Sorry if this arrives

[Miquel Herrera]

It was just a test because my emails were not reaching the list
Miquel

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

Re: Idea: Mass Text Messaging

[Jan Van Vlaenderen]

One nice to have feature would be, if we could tell the phone to send an sms
on a specied date/time.

Jan

On 3/5/07, Ryan Kline <[EMAIL PROTECTED]> wrote:


>> >>Could anyone write this as an extension to the openmoko software?
I meant, would anyone write this as an extension to the openmoko
software?
On Mar 4, 2007, at 6:32 PM, Rod Whitby wrote:

> Ryan Kline wrote:
>> Could anyone write this as an extension to the openmoko software?
>
> Yes, anyone could.  That's the beauty of open source :-)
>
> -- Rod


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





--
If you don't like something, change it. If you can't change it, change your
attitude. Don't complain.
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Yet another finger keybord (gui mock-up).

[Lars Hallberg]

Gabriel Ambuehl skrev:

On Monday 05 March 2007 03:21:15 Florent THIERY wrote:
Yeah, it looks neat. I think I'd downscale the number of special chars though. 
I very much doubt you could actually read the characters on the Neo screen 
right now.


Should be as clear as on the pictures... But You might need to look 
close... But the neo case have a hole for the nose for that special 
purpose :-) Hopefully, You soon learn where the keys are.


And allot can be done to improve the graphics :-)


But there's a problem i didn't find an answear to:
- the neo will have a "monopoint" touchscreen (at least at first)
- a finger is way bigger than a detectable area




-> What point will exactly be detected while pressing somewhere with a
finger?


I don't think those an issue here: you tap on the key (might want to scale it 
down to 6 keys, that still gives you  36 characters which is enough for just 
about any character based language I can think of), hold your finger, then 
move it towards the character you actually want. The phone doesn't actually 
need you to tap the character exactly, the direction of the vector of your 
fingers movement should be enough (with 6 adjacent characters, i.e. honeycomb 
[1] like layout, you still have a 60° field to hit)?


Yes, it's that 'spalash' effect of adjacent keys that's the main 
concept,  not the exact layout. However.. 36 keys may be good for 
entering contacts data... but I *want* a full-blown keyboard level of 
functionality. For me, a common use case is remote admin of servers with 
ssh... and any legacy terminal app may be used (completely unaware of 
'mobile envirionment').


[1] which brings me to the point that maybe round buttons aren't the most 
efficient way of doing it?


Round match hexagons well. Putting them in a square layout is 
suboptimal, but the screen is square anyway and i like the common 
looking keypad, with the 0 in unusual but still logical place. It's 
familiar in more ways... T9 users should fast pick up where the letters are.


I think the size is close to optimal with 6 buttons wide (but it must be 
tested on a neo to be sure). The total area is not to big and high, and 
the 'drags' is not so long. Should make it usable in 'tumb' mode with 
one hand. The press areas should be smaller then the buttons anyway... 
It's not really that hard hitting a small target, what's hard in finger 
operation is avoiding adjacent targets. At least from my experiences 
with a Qteck (os name unrevealed to not hurt anyone innocent).


One question is if the scroll wheel is needed simultaneous with the 
keyboard. That would else leave room for 4 buttons (24 keys) more. But 
in that case maybe 5*3 with 'space' on the sides so all buttons can have 
all 7 combinations would be better... 5*3*7 - 105 keys.


And I'm unsure about the 3 boxes on top... maybe completion should go in 
the app area with 'normal' keyboard interface (enter, tab).


reminder on link: http://www.micropp.se/openmoko/

/LaH


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

Re: Bluetooth Headset - Voice Commands

[Nils Faerber]

Sorry for beeing late here ;)

Mike Hodson schrieb:
> On 2/28/07, Jonathon Suggs <[EMAIL PROTECTED]> wrote:
[...]
> By being connected to the USB bus, this works exactly like every
> current Linux computer with bluetooth: as of now, the BlueZ stack can
> do SCO / headset, and they are working daily on properly working A2DP
> (advanced audio) stereo codec support both as alsa modules.  It would
> then be my guess, that all the OpenMoko software would have to do, is
> change the alsa input/output by responding handsfree button or avrcp
> commands (for stereo headsets).

SCO uses another transfer interface than A2DP - A2DP runs through the
normal data channel und SCO audio is routed through a synchronous
channel though also ending up somewhere else, namely the PCM interface
of the BT chipset.
The PCM interface can be routed either to HCI (the host controller
interface) or a dedicated PCM output of the chipset. This can be used on
dedicated hardware to channel the PCM data directly to some audio codec
and amplifier not wasting HCI bandwidth and making building headsets
easier ;)
Some chipsets can have this routing hardwired to PCM so that you will
never be able to get the SCO audio data into your software.

So buttomline here is that it largely depends on the BT chipset and its
firmware if or if not the SCO data can be routed to HCI.

Since AFAIK the NEO will use a CSR chipset the probability is high that
it can be rerouted if HCI is not yet default.

For A2DP the whole thing is easier since A2DP is always a normal data
connection sending out audio data packets through userspace.

> Furthermore, it is definitely plausible that the bluetooth controller
> in your pocketpc is somehow intertwined with the GSM chipset.  If this
> chip has no provision of routing audio into the software, and only
> considers bluetooth a voice service, then it would talk directly to
> the wireless interface and its GSM chip. The windows mobile/ppc
> software can't grab it.

In theory this could be possible, if the GSM chipset has a matching PCM
input.

[...]

> Mike
Cheers
  nils faerber

-- 
kernel concepts GbRTel: +49-271-771091-12
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen Mob: +49-176-21024535
--

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

Re: OpenMoko featured in Mac|Life

[Marcel de Jong]

Ryan Kline <[EMAIL PROTECTED]> writes:

> 
> Hey Everyone--
> 
> OpenMoko's Neo1973 was featured in Mac | Life's March Issue in an  
> article titled "A Tale of Three Smartphones"
> 
> "...we temporarily forgot that two other touchscreen smartphones had  
> previously been announced: LG's Prada phone and the Neo1973  
> smartphone, manufactured by Taiwan-based FIC and developed by  
> OpenMoko, an open-source mobile "movement."...while the OpenMoko  
> device is a linux geek's you-know-what-dream..."
> 
> It also has a nice chart comparing iPhone, Neo1973, and PRADA.
> 
> There is also an online editorial:
http://www.maclife.com/article/is_three_a_crowd_in_the_touch_screen_phone_arena

That article seems a bit scoffing towards the Neo1973, and has some mistakes in
its information on which I've commented on the site. 
(I've added this article to the Wiki Press Coverage page (under February))

---
Marcel de Jong


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

Re: Possible security hole for Dialers/troyan horses

[Bartłomiej Zdanowski DRP AC2]

Tim Newsom napisał(a):


On Fri, 2 Mar 2007 6:09, Evgeny wrote:


It still Linux based phone — there is absolutely no real-life viruses
for Linux at this time, trojans are possible treat, but user have to
install them by himself.


That's a pretty strong statement.. Are you absolutely sure there are 
no viruses for linux in the wild?
There are but not many. But remember that virus must be compiled to 
binaries for OpenMoko. You OpenMoko phone would not catch virus from 
other linux distro.


Regards.
--
*Bartłomiej Zdanowski*
Programista
Dział Rozwoju Produktów
AutoGuard & Insurance Sp. z o.o.

Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy Krajowego 
Rejestru Sądowego

KRS: 029534
NIP PL1132219747
ul. Omulewska 27
04-128 Warszawa
tel. +48 22 611 69 23
www.autoguard.pl 
begin:vcard
fn;quoted-printable:Bart=C5=82omiej Zdanowski
n;quoted-printable:Zdanowski;Bart=C5=82omiej
org;quoted-printable:AutoGuard & Insurance Sp. z o.o.;Dzia=C5=82 Rozwoju Produkt=C3=B3w
adr:;;ul. Omulewska 27;Warszawa;;04-128;Polska
email;internet:[EMAIL PROTECTED]
title:Programista AC2
tel;work:022 611 69 23
tel;cell:603 525 105
x-mozilla-html:TRUE
url:http://www.autoguard.pl
version:2.1
end:vcard

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

Re: Yet another finger keybord (gui mock-up).

[Gabriel Ambuehl]

On Monday 05 March 2007 03:21:15 Florent THIERY wrote:
> Hey, great idea ! I'd be happy to use such a system.

Yeah, it looks neat. I think I'd downscale the number of special chars though. 
I very much doubt you could actually read the characters on the Neo screen 
right now.

> But there's a problem i didn't find an answear to:
> - the neo will have a "monopoint" touchscreen (at least at first)
> - a finger is way bigger than a detectable area


> -> What point will exactly be detected while pressing somewhere with a
> finger?

I don't think those an issue here: you tap on the key (might want to scale it 
down to 6 keys, that still gives you  36 characters which is enough for just 
about any character based language I can think of), hold your finger, then 
move it towards the character you actually want. The phone doesn't actually 
need you to tap the character exactly, the direction of the vector of your 
fingers movement should be enough (with 6 adjacent characters, i.e. honeycomb 
[1] like layout, you still have a 60° field to hit)?


[1] which brings me to the point that maybe round buttons aren't the most 
efficient way of doing it?





pgpryc3sWXecp.pgp
Description: PGP signature
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: 'My Account' - a way to store information about the phones owner, so they can be reunited if it's lost.

[Bartłomiej Zdanowski DRP AC2]

Ian Stirling napisał(a):

Paul Wouters wrote:

On Thu, 1 Mar 2007, Ian Stirling wrote:

Reflashing never gets you back a different account number, it keys 
off the
IMEI, which is not flashable. (well, perhaps it is, but it's not 
flashable

from the linux side, and AIUI, nobody else knows how at the moment.)


I really hope the IMEI number is not available to every application 
or even


The IMEI is readable out of the modem with standard AT commands.
There is even a standard across all GSM phones to get it to display it.
Guys, guys... IMEI is written on phone's specific component. In older 
phones there was just eeprom which could be desoldered changed and 
soldered back. That was the way to disable SIM-Lock too.

I used to do it.
IMEI is like MAC address. It can be changed. It is granted from special 
pool to every GSM module manufacturer (just like MAC is).
The phone manages IMEI distribution and displaying. If you can program 
your phone, you can disable IMEI showing to user.


It was the primary task after phone theft to change IMEI so GSM network 
cannot recognize it as stolen. Really, consider it as MAC address. Phone 
operators actually keep only black list to block stolen phone and not 
every GSM operator does it. Also if the number is out of the official 
manufacturer pool (illegal) network won't give access.


Ian Stirling says: "a standard across all GSM phones to get it to 
display it". Yes, it is *#06# combination from keypad (try it) and AT 
commands. But it is the standard, like Ctrl+alt+delete for rebooting 
(both Linux and MS Products). Showing it to user or applications CAN be 
disabled.
Other thing is GSM network request. GSM network requires the phone to 
tell it's IMEI otherwise it won't give the phone access to network.  
This cannot be disabled.


Summing:
As *we* program Neo 1973 we are managing the use of IMEI number. We can 
hide it from user. We cannot hide it from GSM network.


--
*Bartłomiej Zdanowski*
Programista
Dział Rozwoju Produktów
AutoGuard & Insurance Sp. z o.o.

Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy Krajowego 
Rejestru Sądowego

KRS: 029534
NIP PL1132219747
ul. Omulewska 27
04-128 Warszawa
tel. +48 22 611 69 23
www.autoguard.pl 
begin:vcard
fn;quoted-printable:Bart=C5=82omiej Zdanowski
n;quoted-printable:Zdanowski;Bart=C5=82omiej
org;quoted-printable:AutoGuard & Insurance Sp. z o.o.;Dzia=C5=82 Rozwoju Produkt=C3=B3w
adr:;;ul. Omulewska 27;Warszawa;;04-128;Polska
email;internet:[EMAIL PROTECTED]
title:Programista AC2
tel;work:022 611 69 23
tel;cell:603 525 105
x-mozilla-html:TRUE
url:http://www.autoguard.pl
version:2.1
end:vcard

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