Re: [android] Answer calll problems
Christophe Badoit wrote: > Denis Galvão a écrit : > >> Talked to hackbod on the #android freenode room. >> >> Im not sure if it is official, but this is what he told me yesterday. >> > > > Thank you for the source. > > This is indeed bad news if all android apps have to be patched to be > usable on the FR :-( > > > They don't; there's got to be several ways around this, from USB or BT keyboards to softkeys that run at a layer android doesn't know about to faking multiple buttons from the two available ones based on chording and press duration. --pj ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Nishit Dave wrote: > On Wed, Oct 22, 2008 at 8:31 PM, Kishore <[EMAIL PROTECTED]>wrote: > > >> Since i got my neo rather recently, i have only tried 4.4.1. Is 4.3 still >> the >> better choice? A couple of days ago i lost my daily use phone (motoming >> A1200) >> and so i now need to use the FR as my daily phone. >> >> > > Join the club. > FWIW, I've been running 4.3 as my only cellphone for several weeks now. I've got the bug #1024 re-registration problem, which is annoying, but I can still make and receive calls. I've only gotten into a really funky state once or twice - due, I think, to switching between booting 4.3 and other distros (FSO). It's been pretty stable since I ran out of time to mess with it :) --pj ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: VARTA Digital USB Charger
Looks similar to the DIYer "mintyboost' project: http://www.ladyada.net/make/mintyboost/ Radek Bartoň wrote: > Hello list. > > I've just read an article about new VARTA Digital USB Charger > http://www.en.varta-consumer.com/content.php?path=/1204126618.html&&domain=www.en.varta-consumer.com > > so I'm sharing it with you. > > For our purposes it's really great that it can charge our precious Neo from > inserted AA or AAA accumulators, power point or car socket :-). > > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: RFC: delete page USB
Don't delete it; someone will recreate it. Make it a redirect to the Category:USB page. Fredrik Wendt wrote: > lör 2008-08-30 klockan 00:29 -0700 skrev Michael Shiloh: > >> http://wiki.openmoko.org/wiki/USB >> > > My comment: Just go ahead! :) > > / Fredrik > > > > ___ > 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: MokSec - The Security Framework
Alex Oberhauser wrote: > Bumbl wrote: > >> It would be more important to not run everything as root I think >> > > This will be also a main focus. When we receive the Freerunners, we will see > how fast we can change this bad state. > > Personally, I'd be more interested in an encrypted filesystem so that I can worry less about snoopy people getting access to my personal data if I lose my phone or it's stolen. How many 'main focuses' are you allowed ? :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: questions for steve regarding group purchases
steve wrote: Mass Pro is slated to start between may9 and may 16. Steve's rule say add a week. Then you got test, then you shipping. On Monday ( or maybe Sunday night for my EU friends ) I will do an update. Could you also include status of debug boards? Will they go on sale at the same time as the phones? Will there be debug-board 10-packs? (I don't expect so, but it's possible!) If I'm getting a phone via a group order, is there any advantage to getting a debug board via the same order, or should I just order it on my own? Answers can wait until your update, bu I wanted to get the questions out there. Thanks again for keeping us so well informed! --pj ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stylus Recommendation
Ponoko has acrylic in 1/8" and some 1/4" thicknesses that you can get laser-cut for fairly reasonable prices - IIRC, they just opened a bay-area cut/ship center to reduce shipping in the US (they're originally from New Zealand!). Looks like a typical project from 7"x7"x1/8" acrylic is around $10-$20. That's potentially several "stylus-racks". --pj On Monday, May 5, 2008, "steve" writes: >I looked at emachines a few years back for doing some custom car parts. The >CAD tool was a bit funky. The price was not hobby friendly as you note. >My friend owned a machine shop so he just CNCed the thing since he wanted it >too. I never tried a plastic part with emachine, but its all about the set >up cost and the tool you use. material is immaterial ( or should be) > >You've seen the fishing rod holders. small rubber part u-shaped things. pry >it open >slip the rod in... I'm thinking down those lines, just for me, not a company >endorsed thing. Just messing around. > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Steven ** >Sent: Monday, May 05, 2008 2:30 PM >To: List for Openmoko community discussion >Subject: Re: Stylus Recommendation > >I just drew up my first part. The price quote was $1600! :-( (In >all fairness, it's a much larger piece than what you're talking and in >aluminum.) > >Are their prices workable for smaller plastic designs? > >-Steven > >On Mon, May 5, 2008 at 3:53 PM, steve <[EMAIL PROTECTED]> wrote: >> Have you used emachine shop? > >___ >Openmoko community mailing list >community@lists.openmoko.org >http://lists.openmoko.org/mailman/listinfo/community > > >___ >Openmoko community mailing list >community@lists.openmoko.org >http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Steve on V5 versus v6
Related to making openmoko gear - is there vector art of the logo somewhere? I checked the wiki and couldn't find a reference, and checked downloads.openmoko.com and again came up empty. Inquiring minds want to know! Also, if it is published, we'd probably want some kind of license to use it that we could show to the printer/manufacturer we wanted to use... My personal idea was to talk to the guys at skoobadesign(.com) and see what kind of surchage there'd be to get a moko-branded small RAPS to use as a pouch since the moko's not going to ship with one. What's Openmoko's stance on the community using thier logo, maybe even creating "Openmoko branded" items? --pj On Monday, Apr 21, 2008, Michael Shiloh writes: > > >Daniel Barkalow wrote: >> On Sun, 20 Apr 2008, steve wrote: >> >>> The pouch, alas, did not fit into the box. When Michael gets his photos >>> done, or my spawn get their video done, then you will see that we have >>> greatly reduced the size of the box. Partly for aesthetics, and partly to >>> create a product where I could pack 10 phones boxes in a bigger box, and >>> then ship that bigger box efficiently. So, I had to optimize some things. >>> >>> Now, I realize that people want accessories. So As this launch gets going >>> I'll put together some ideas, for accessory packs >>> >>> Fundamentally, I would rather that some community member build a business >>> around this. Our marketing materials are open source. So, you can build >>> your own pouches, use our brand, and make a business from accessories. >> >> No, no, you should include a sewing pattern for the official pouch in the >> box. It would be neat to have an official Openmoko pouch for your phone, >> but it would be even better if that pouch was handmade by each owner for >> their own phone. Especially if the instructions have configuration >> options. > > >It's all open, dude. I invite any of you to create a sewing pattern for >an Openmoko pouch. > >Michael > >___ >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: Charging Neo Freerunner via USB port
Hi Michael, This is a good start, very informative. Some good additions, I think, would be: * Why does computer/usb charging max out at 500mA? is that a limitation of the USB spec? * you mention 'other manufacturers' that 'identify their own chargers' with various resistors... if I have one of those chargers, is there a way to get the phone to ID it? * for hacking purposes it would be good to document what other mfrs chargers use and how easy they are to hack into moko fastchargers. This should be a wiki page and community driven, of course, but you could get it jump-started with whatever info you have on this issue. I, for one, have a small pile of motorola chargers with mini USB on them that I'm more than willing to hack into moko fastchargers given some basic instructions. * you/we should make the charging status *VERY APPARENT*. People are going to be unhappy if they plug it in and it doesn't charge when they think it will (consider the case of a cheapo usb hub that won't supply the power), but this can be avoided if the phone makes it obvious when it is or isn't charging. Just my pair of pennies, --pj On Friday, Apr 18, 2008, Michael Shiloh writes: >Hi everyone, > >With input from the experts who designed the system, I've tried to >document precisely how charging works on the Neo Freerunner. > >I welcome your feedback: > > > >The Neo Freerunner charges the battery when 5VDC is provided at the USB >port, whether from a computer USB port or from a dedicated USB charger. > >The Neo Freerunner can charge most rapidly when it can pull 1 Amp from >the power supply connected to the USB socket. However, not all chargers >or computers can provide this much current. > >When the Neo Freerunner detects that power has been provided at the USB >port, it will attempt to draw only 100mA. This minimum is mandated by >the USB standard. This amount of current is insufficient to both power >the Neo Freerunner (or even just its backlight) and to charge the >battery, and therefore the battery will not be charged. (The battery >discharge rate, however, will be slightly lower, as the supplied 100mA >will be used to augment the battery.) > >(When a charger is connected to the USB port, the Neo Freerunner >automatically powers up. Thus, if charging at 100mA is desired, the Neo >Freerunner must be shut down after the startup process has completed.) > >After detecting USB power, The Neo Freerunner will attempt to negotiate, >via the USB protocol, a higher charge rate of 500mA. If the device >powering the Neo is capable of doing so, the Neo Freerunner will charge >at 500mA. > >USB chargers do not implement the USB protocol, and thus can not respond >to requests for higher charge rates. Some manufacturers have worked >around this issue by installing resistors of different values between >different pairs of pins in in order to "identify" their own chargers of >known capacity. This is not part of the USB standard and is completely >up to each manufacturer. > >The USB charger provided with the Neo Freerunner can source up to 1A. In >order to identify this special charger, there is a 47K ohm resistor >between the ID pin and ground. If the Neo Freerunner detects this >resistor, then the Neo Freerunner will charge at 1A. > >In summary, the Neo can charge at 3 different rates: 100mA, 500mA, and 1A. > >Notes: > >1. USB negotiation and resistor detection is performed in software, and >is thus under developer control. A developer might write an application >to indicate that 500mA or 1 Amp are available, bypassing the USB >negotiation and the 47K ohm resistor detection. > >There is nothing preventing the software from charging at a higher rate >than then power provider can supply, although there is danger in doing so. > >The danger in drawing more current than a charger or computer USB port >can provide is that components overheat and may become permanently >damaged, or even catch fire, although most USB host devices implement >current limits that will depower the port on overcurrent. > >2. The Neo Freerunner charger is a single assembly which includes >the USB cable. The cable is NOT a separate item and can not be removed >from the charger (without cutting). > >3. Any third-party charger that does not contain the 47K resistor will >cause the software to assume it can draw only 100mA, regardless of how >much current the charger really can source. > >4. In its hard-coded configuration, the PMU doesn't charge the battery >at all. The hard-coded configuration is used when power is applied to >the PMU after a period of complete absence of power, including the >backup battery. > >When the system comes up, it reconfigures the PMU to enable charging. >Most of the configurable items are also preserved by the PMU if it >powers the system down, but the PMU itself still has power - either from >USB, main battery, or the backup battery. (This is the PMU's STANDBY mode.) > >
Re: FreeRunner Pricing and PVT update
On Monday, Apr 14, 2008, "steve" writes: >Ok thanks dirk. > >Frankly, some people thought the pouch sucked. > >If I ship a pouch, you have no choice. you get my pouch. > >My opinion: it's a phone sock. > >Ideally I would love to have the community >develop this accessory if they want it. Anyone have thoughts on the RAPS stuff at skoobadesign.com ? (http://www.skoobadesign.com/product/advanced-protection-system-wrap-small-22/) Maybe you could talk to them about getting an openmoko-branded version? --pj ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
PDA Case that fits the Neo?
Has anyone tried putting their Neo into a PDA case? The Case Logic PLT-2 looks like it might fit the Neo and doulbe as a wallet at the same time :) I'm also considering the 12" skooba R.A.P.S. thing as a 'case' for my future Freerunner... Are there other suggestions? I think the Neo shipped with a bag, but has anyone tried anything else? --pj ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Metal case [was: Application idea: Bicycle computer]
How about a case that's part metal and part plastic? Make it plastic just around the antennas (which, IIRC are at the 'ends' of the phone) and metal everywhere else? Heck, it could end up having a *good* effect by being extra shielding between the antennas and the (noisy) electronics of the phone itself. --pj On Tuesday, Mar 18, 2008, "Flemming Richter Mikkelsen" writes: >On 3/7/08, Erland Lewin <[EMAIL PROTECTED]> wrote: >> 2008/3/6, JW <[EMAIL PROTECTED]>: >> > Why do people want metal cases so much...???Features in wiki >> > hardware wishlist too. >> >> > My thought is aluminium = metal = faraday cage = stops gps, gsm, wifi, >> > bt signals = BAD idea >> >> The back of the iPhone is mainly metal isn't it? Many attractive cell phones >> today have at least parts of their cases made of metal. >> >> Also, I read about someone (forgot where) trying to make a Faraday cage, but >> apparently it is quite difficult in practice. For an efficient cage you >> apparently need many meshes with holes in different sizes for different >> frequencies if I recall correctly. I guess this could be easily tested by >> putting a cell phone in a tin can and trying to call it... > >I don't think it is as easy as you think. Please correct me if I am wrong. >For low frequencies the cage will have little effect, but for the wifi >it is not easy to predict. It gets complicated with high freqs. And if >it seems to work nicely when you test it without touching the phone, >maybe it don't work so nice when you do??? I am no expert... just my >thoughts > > >-- >Please don't send me Word or PowerPoint attachments. See >http://www.gnu.org/philosophy/no-word-attachments.html > >Join the FSF as an Associate Member at: >http://www.fsf.org/register_form?referrer=5774> > >___ >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: GTA02 Battery Capacity (Was: Re: More about the GTA02)
On Thursday, Feb 14, 2008, "Kyle Bassett" writes: >There is talk about pushing startup power control of the internal devices >(wifi, bt, gps, mmc, etc.) to user level, as every user may or may not want >certain devices available at bootup/all the time (availability vs. >duration). Indeed, this along with good realtime stats on power usage and current battery level would let people have reasonably accurate predictions of their battery life. It'd be interesting (to me at least) to turn on and off the various peripherals and watch my projected battery life go up and down accordingly. --pj ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: proprietary firmware
+1 Software by its nature is easier to fix than hardware or even firmware; this approach does the Right Thing: vendors win because the firmware layer just got a whole lot easier to write and the rest of the world wins because we get as much control as legally permissible of our hardware. On Friday, Feb 8, 2008, Wolfgang Spraul writes: >Dear Community, > >Some of our chips or chipsets contain proprietary firmware in flash >memory. For example, in GTA02 these include the Wi-Fi, GPS, and GSM >chipsets. >Ideally, we would have liked to use chipsets for which even the >firmware code would be free, but they don't exist right now. >So we accepted proprietary firmware, as long as it was in flash or ROM. > >Then we ran into problems when bugs were found in the firmware, and we >wanted to update handsets out in the field. >The vendors would give us firmware updates and reflashing tools, but >they wouldn't let us redistribute those tools to our users. We asked >for special licenses to allow us to distribute those flashing tools to >our users, and got them in some cases, after months of licensing >negotiations. >Next we discovered that those reflashing tools had further issues: for >example, they would only allow loading cryptographically signed >firmware into the chipset flash memory. The tools do this because >vendors are worried that people would disassemble, patch, and >reassemble the firmware, triggering regulatory reclassification of >their chipsets (software controlled radio). >Furthermore, we see that for upcoming chipsets, vendors are switching >from storing the firmware in flash memory to loading the firmware into >RAM at run time. One reason for this is that RAM needs less power and >is cheaper. In this case the firmware, whether original or updated, >has to be loaded each time the device boots, requiring that the binary- >only, restrictively licensed firmware updater be included in the >OpenMoko distribution. > >This got quite frustrating, until we met Richard Stallman last >weekend. And he cleared it up for us rather quickly :-) > >He suggested we treat any chipset with proprietary firmware as a black- >box, a circuit. He suggested we ignore the firmware inside. If the >firmware is buggy and the vendor needs the ability to update the >firmware, we instead ask the vendor to reduce the firmware to the bare >minimum, so that it can be very simple and bug free, and move the rest >of the logic into the GPL'ed driver running on the main CPU. This way >we completely avoid the issue of distributing proprietary firmware >updates and binary firmware updaters with restrictive licensing that >load only cryptographically signed firmware. > >We liked his advice. It speeds up our decision making and allows us to >focus on what we do best: Developing Free Software that is available >in full source code, running on the main CPU, that we and anyone else >can modify and optimize. There are downsides: We will no longer offer >reflashing tools to update proprietary firmware, under any license. >For critical firmware bugs, we will accept returns, or in some cases >fix the bug in-house. >We will push vendors to simplify the functionality of their >proprietary firmware, so we can implement more of this on the main CPU >as Free Software. Maybe some vendors will even open up firmware for >Free Software development, that would be the ideal outcome we are >working towards. > >We hope this helps clarify OpenMoko's current position on proprietary >firmware: Ignore them while they stay inside of a chip or chipset, and >refuse to touch them. Focus on what Free Software can do. >Feedback and comments are always very welcome. >Best Regards, >Wolfgang > >___ >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: Debug board
On Saturday, Sep 15, 2007, Michael 'Mickey' Lauer writes: >[EMAIL PROTECTED] wrote: >> does anyone happen to know if the debug board of the "advanced" Neo >> kit will be compatible with future versions of the Neo (or other FIC OpenMok >o phones, at that)? > >It will definitely be compatible w/ GTA02. As for the successor >models, we can't make a definitive answer yet (there is not even >schematics nor silicon for those anyways ;), but of course we'll >try to make it compatible... Does this means there're no plans on the drawing board for GTA03? Even if it's just an incremental improvement on GTA02, I'd expect there to be *some* plans - the wiki is surely full of suggestions :) --pj ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: information efficient text enty using dasher
On Tuesday, May 29, 2007, Peter Hoffmann writes: >Hi > >i just stumbled over a video at the google talks series[0] about >information-efficient text entry using dasher[1]. > >I think this is quite an interesting input method for mobile devices >with touch screens or motion sensors. And it is open source and its user >interface is based on gtk. > >An other great point is that it is not only limited to english text, but >you an use any input language/alphabet you want. > > >I'm looking forward to test it on a neo. What do you think? > > >Regards Peter > >[0] http://video.google.com/videoplay?docid=5078334075080674416 >[1] http://www.inference.phy.cam.ac.uk/dasher/ I think you should've searched the wiki :) http://wiki.openmoko.org/wiki/Wishlist:Text_Input lists Dasher as only one of over a dozen different wishlisted input methods. --pj ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
I can think of worse things than having multiple possible distros competing to be the software on my phone :) --pj On Tuesday, May 8, 2007, Vincent writes: >On 08/05/07, Marco Miani <[EMAIL PROTECTED]> wrote: >> >> Hi >> >> I've just read this >> http://www.sfgate.com/cgi-bin/blogs/sfgate/detail?blogid=19&entry_id=16310 >> >> about sun JavaFx and a mockup of a phone that will be presented soon >> WTF it's a Neo > > >Now that's funny... But as the text says: > >"even as he released a photo of a mockup (left)" > >And: > >"We're not introducing a phone. We're introducing software to make this >possible." > >So I suppose they just made a screenshot of the software and pasted it onto >a picture of the Neo1973... > > >> >> bye >> >> Marco >> >> ___ >> OpenMoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > > >-- >Vincent > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Neo-use idea
If someone wants to repurpose the neo hardware, check out what the guys at http://www.environmental-studies.de/products/pet-tracking/pet-tracking.h tml are doing. They're sold out for now, but they might be worth talking to to see if they want to try and start from a base Neo and just add some custom software to. Random idea as I was browsing the web. --pj ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Please no crossposting! Re: Information regarding theMessaging Support in OpenMoko
I think a good Jabber client could totally supplant MMS - it support file transfers, which is all MMS really does (I think), as well as things MMS never dreamed of like encryption and presence and etc. Putting a good mobile-UI on, say, Psi or one of the other open source Jabber clients shouldn't be too difficult. Unless there's already one that I don't know about? Another feature could actually be an SMS-to-Jabber gateway that runs on your phone, so as long as your phone has power (and permission to get on the net, etc) your SMSs will get gatewayed to Jabber so you don't miss them if you happen to leave your phone at home. --pj On Thursday, Feb 1, 2007, Sean Moss-Pultz writes: >On 2/1/07 4:30 AM, "David Schlesinger" <[EMAIL PROTECTED]> >wrote: > >>> Also, who uses MMS? >> >> Only pretty much the majority of actual cellphone users in Europe, based on >> the market research and carrier requirements I've read... > >IMHO, only because nobody has given us anything better. We're trying to do >that. So I asked the guys to ignore MMS for the now. If this is an issue >I'll put resources on this in the future. Right now, I'd much prefer to see >solutions that use GPRS such an IM / Email / ... > >>> Seems like the typical user would just email >>> and attach media and/or just s/ftp >> >> Typical _Linux_ user, maybe. This is the sort of thing which (in my view) >> represents something of a disconnect between the goals of "having as open a >> phone as possible" and "selling a lot of phones"... > >You might be right. But I personally feel that MMS is fundamentally flawed. >Costs aside, it's just not the way I think media should be transferred. The >benefits are just too low for the end user. We're trying to fix this. > >Really guys, we're trying to rethink lots of things with OpenMoko. I don't >want to do the same things just running under FOSS. We'd be missing out on a >huge invitation to innovate both as a company and a community. Why not use >the flexibility and rethink how we want these devices to work -- as end >users -- not just for geeks but for everyone? I'm not saying we'll get >things right the first time. Just that we're going to try our best ;-) > >_This_ opportunity is what makes me excited about OpenMoko. Not (simply) the >fact that it's FOSS based. > >-Sean > > > ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Developers phone also fit for early adopters?
Sean please just ignore idiots like this. The rest of us know you're doing the best job you can and want to see the phone out ASAP just as much as we do. In summary: ignore the trolls and keep doing what you're doing. --pj On Saturday, Jan 27, 2007, Sean Moss-Pultz writes: >On 1/26/07 9:40 AM, "Marcus Bauer" <[EMAIL PROTECTED]> wrote: > >> The fact that I didn't answer to that mail doesn't mean I didn't read >> it. Should I now say you obviously didn't follow your own annoucements >> and didn't read the topic you set on IRC because you said the phone >> would come out in January? > >Listen, there's nobody on this list that wishes we'd had this phone out in >January more than I. But delays happen. You can't seriously be calling us >liars now are you? > >-Sean > > >___ >OpenMoko community mailing list >community@lists.openmoko.org >https://lists.openmoko.org/mailman/listinfo/community > ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Idea for OpenMoko: Kid Mode
How about a locked-down 'kid version' of the UI with touchable pictures for 'mommy', 'daddy', etc ? Maybe not even labelled, but just the pictures? --pj ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Real Neo1973 photo?
On Thursday, Jan 11, 2007, Sean Moss-Pultz writes: >On 1/10/07 8:53 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> >wrote: > >Yes. > >So even though Apple's phone might be very elegant phone, its going to be >more of the same stuff that (IMHO) has held the mobile industry back -- >namely the lack of an open ecosystem for developers. Yes, their innovations are mostly UI things - which we can pick and choose among, to some extent =) For instance, I fully expect the next OpenMoko to have some kind of accelerometer or orientation sensor. The idea of a 'nearness sensor' that detects when you have the phone to your ear is also a good one - if it's at your ear you're not looking at it, so save some battery by shutting down the screen. Gestural screen unlock is another feature we'll probably want. A multitouch screen too, if we don't already have one. >What really excites me now is how we can work together to make OpenMoko even >more innovative. We'll be four months into collaborative development before >the public even gets an iPhone. And judging from the ideas / comments that >have been flying around this list for the past few months, I don't see any >reason why, together, we can come up with some applications that allow >people to use phones in entirely new ways. How about jumpstarting this with an SDK? Ideally an emulator and a one-button-build, but we'll settle for just the code =) >Once we have phones shipping, I would love to start a conversation with all >of you about how to organize and support this effort. I promise to put >resources where my mouth is ;-) Offhand, any idea what the size of the first production run will be like? I'm really looking forward to the phone and want to make sure I can get one :) --pj ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
still on track for Mid January release?
Sean, are you guys still on track for a mid-January release of rev 1 of the phone? It seems a bit late for you to both be able to make that deadline and not know exactly what hardware is going into the phone. --pj ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: audio link Re: Peer Discovery
Reminds me of the watch that has a small camera in it and uses your computer monitor as its 'uplink'... you tell it to download data and then point the watch at the screen and it 'reads' the patterns that the PC displays for it. If the phones had cameras they'd be able to do the same... and even 'send' to each other using their own displays. On Monday, Dec 11, 2006, "Richard Franks" writes: >On 12/11/06, Robert Michel <[EMAIL PROTECTED]> wrote: >> > > 10 bonus points if it sounds like R2D2. >> efficient data transmission via audio mustn't sound well >> for the user - DTMF for transmitting your phonenumber >> would be acceptable, but the other modulations? > >Heh! That idea was intended just for handshaking/swapping business >cards - very small amounts of data. Hands up who wouldn't sacrifice a >little speed, for a phone that shared business cards with a fellow >Neo1973 with cute 'threeps' and 'twerps'? > > >> To beem your virtual business card via audio it would be >> nice when the data transmission would be encoded into >> a non uggly modification of a voice output: >> "I'm beaming you now my virtual buseness card - complete" > >Or multiplexing a higher frequency data signal, if the hardware supports it? > > >> Such a solution could be also run on other smartphones with >> java - send and receive business cards and more without >> Bluetooth or IRDA nor cable nor online connections. > >I wonder if it's possible to support the basic modem signalling >protocol in software? I haven't touched anything like that, but if for >the price of a local phonecall and an old PCI modem, I could call a PC >and encrypt whatever I liked through that connection.. it could end up >being a cheaper, secure, alternative than GPRS? > >Richard > >___ >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
Sensors
I read the thread about a light sensor and think it's really a good idea for several reasons, not the least of which are that photodiodes are both simple to interface to and cheap, so the price/performance tradeoff here if even one or two reallly good applications for it are found (and several ideas have been presented) is really good. Thinking about other similar inputs that might also be good, I came up with: * Temperature sensor - It might be able to figure out if it was in your pocket vs. in your hand vs. sitting on the desk. Again though, this is such a simple and cheap thing to add that it could, I think, be included just on the off chance someone will come up with a great use for it. * Motion sensor - lots of potential uses: shake your phone to rapidly to get to the main menu. Tilt scrolling, and application switching by tapping the sides of the phone (ala the 'Smackbook Pro' hack at http://blog.medallia.com/2006/05/smacbook_pro.html). Or maybe it should scream when you drop it to make sure you know you've dropped it so you don't leave it behind. * Consumer-level IR - too late for v1 probably, but maybe v2 ? - useful not only for docking/interfacing with printers, etc, but also for turning your phone into the ultimate TV remote :) The Agenda handheld had this feature and I've heard of people who are using the little thing for nothing *but* this - they've replaced their pile of remotes with a (now fairly dated) ~$100 linux palmtop that never loses its IR settings. * some number of plain old LEDs - useful for message-waiting indicators (for voicemail, SMS, email, and IM) for example, without having to power up the display. Bonus points for multi-color LEDs. Oh, and I was glad to hear there will be vibrate-mode hardware, but what about speakerphone? And is the touch-screen a multitouch type? or single? I've gotten quite used to the 'point with one finger, scroll with two' features on my Macbook Pro. PS: Add my vote for bluetooth. --pj ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
