Neo1973 video (was Re: What would be a realistic but challenging level for Bryce announced trophy money for video playback on the Neo1973? Re: h.264 format is now open?)
On Fri, Feb 02, 2007 at 11:06:43PM +0200, Siarhei Siamashka wrote: On Friday 02 February 2007 12:31, Robert Michel wrote: Some video information given by Sean in november: http://lists.openmoko.org/pipermail/community/2006-November/000340.html A few technical questions here. Is image data constantly transferred to LCD from system memory (60 times per second)? yes, since the graphics controller is embedded in the S3C2410 SoC. The LCM signal lines are directly attached to the S3C2410. There is no other graphics memory than main memory. If we compare it to Nokia 770, Nokia 770 has a similar design with framebuffer stored in the system memory with data getting transferred to graphics chip using DMA when needed (graphics chip has its own video memory). That's a significantly different design. Also, the 770 has a landscape display. We have a portrait display. The S3C2410 cannot rotate the image, so you would have to rotate every frame in software, too! If video is really heavy on memory bus, is it possible to reduce refresh rate somewhat (to 50Hz for example) to improve performance? There's not too much room since the minimum pixel clock frequency of the LCM is 20MHz. At a typical cycle of 520x648, you get 59Hz minimum refresh rate. You could probably go all the way to extend horzontal /vertical front/back porch, etc. But they can only be increased a tiny bit, the maximum values are determined by the S3C2410 register set. Just for some experiment, I compiled mplayer for arm920t (not using armv5te instructions), and benchmarked it with sdl video output (software YUV-RGB conversion, generic nonoptimized scaling 320x240 = 640x480) and libmad mp3 audio decoder. Please note that the LCM we use in the Neo1973 can do hardware scaling, e.g. theoretically you can software-reconfigure the LCM to behave as QVGA 240x320, and then change the s3c2410_fb kernel driver timings accordingly. This has not been tested or implemented by us, since we're mainly interested in getting a high-res phone UI working right now :) However, if somebody skilled wants to write, integrate and test code for this, I'm happy the help. We cannot disclose the LCM data sheet, but I can add the software sequence for 240x320 / 480x640 switching to the [GPL licensed] kernel LCM driver at least after phase-1 (March 11). The S3C2410 user manual is publicly available from Samsung Semiconductors, so basically it's up to whoever is interested to implement it. One interesting question is how to merge this into X11/Kdrive... As far as I understand, only the very latest big (non-kdrive) X11 has randr capabilities for dynamically adding/removing viewports and changing resolutions. [But did I mention that Keith Packard gets a phase-0 phone? *g*] Cheers, -- - 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 https://lists.openmoko.org/mailman/listinfo/community
Re: AT commands (Re: But wich GSM chip? Re: AT commands document (Was: Fax modem? Fax software? Neo as T.38 gateway?))
On Sat, Feb 03, 2007 at 09:48:08AM +0200, Aloril wrote: Wild guess: some of vendor-specific, proprietary TI AT commands allow user to write/read GSM module flash. I do not think so ;) -- - 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 https://lists.openmoko.org/mailman/listinfo/community
Re: AT commands (Re: But wich GSM chip? Re: AT commands document (Was: Fax modem? Fax software? Neo as T.38 gateway?))
Salve Harald! Harald Welte schrieb am Samstag, den 03. Februar 2007 um 14:49h: I put the list into the wiki - it would be fine to mark out which are not the optional ones and how to use them. So from this list, every contribution, commentation of this commands are welcome. For everything but the few TI-proprietary ones, all this is in the GSM standard. I don't think it's worth replicating that inforation. For the standard we can takeover this informations http://wiki.openezx.org/AT_commands Not now - in some weeks a list and information about the TI-proprietary ones would be fine. If the community learns something about the TI-proprietary commands, that's certainly a different thing. E.g. the network quality - nearly non of us would run around (daily) with mobil/laptop/GPS device to monitor the networkquality, but with the Neo1973 it could be an interesting thing. network quality is sent as event from GSM Modem to our gsmd, from where any process can get it over a unix domain socket. Yes, and the community could collect some first step examples to make starting the first step using the freedom on the Neo more easy :) Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Q: How does USB hubs work? Re: Multiple USB Devices
On Wed, Jan 31, 2007 at 08:20:04AM -0700, Joe Pfeiffer wrote: Robert Michel writes: Brilliant! Thanks for that :-) So now the question, how does an USB hub work? Can we plug in the host on any port? Short form: USB is strictly a hierarchical, tree-structured network. There is one host, which may connect to the upstream port on a hub; you can then plug in more hubs and devices downstream of the hub. They were very careful when writing to the standard to specify cables that can't plug in the wrong way: you can only plug a host into the (single) upstream port on the hub. Long form: http://viper.cs.nmsu.edu:8000/classes/473/notes/usb.php?currentsem=s06 Really long form (this is the USB 2.0 specification) http://www.usb.org/developers/docs/usb_20_05122006.zip The Neo1973 will have mini-USB-B normal hubs powered USB-A for the adapter and one unpowerd USB-B for the host. My understanding is that it will be USB On-The-Go, No. OTG is a complex specification, and it comprises way more than just a AB socket, but also electrical and software components which we cannot provide using the S3C2410. All you need is a special Mini-B to regular-B cable, which you then can plug in the upstream port of any regular self-powered USB hub.You can then use any (low-speed,full-speed) usb device on that hub. But that normal hub will not charge the phone, though. FIC product development is looking in providing something that conveniently solves this problem. I cannot say more than that at this point :) -- - 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 https://lists.openmoko.org/mailman/listinfo/community
Re: data encryption + Biometric security
On Thu, Feb 01, 2007 at 10:11:41AM -0700, Ben Burdette wrote: Here are a couple of items for the phone wish list: data encryption and biometric security. data encryption will not be that much of a problem. There will not [yet] be a easy-to-use user interface, but we will have dm-crypt modules in our kernel, and make sure all user data is stored in one specific location. So once you mount a crypto volume there, you have it basically working. As for 'biometric security': In my 'life before OpenMoko', I've been working as an IT security expert. I've been doing a lot of research on RFID security and biometrics, too. Believe me, there is no single fingerprint scanner that I've ever seen which could not be tricked one way or the other. In most cases, it is _EXTREMELY_ easy (see e.g. http://www.ccc.de/biometrie/fingerabdruck_kopieren) Also, what is the end result, if there is some really important stuff protected by a fingerprint scanner? Malicious people will cut off your finger. Don't laugh, it has happened before. There are proven cases, e.g. where a carjacker cut off the finger of his victim in order to be able to steal the car. Thus, I don't think that fingerprint recognition is by any means a contribution to security. -- - 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 https://lists.openmoko.org/mailman/listinfo/community
Re: Encrypting voice comunications..
On Fri, Feb 02, 2007 at 07:13:12PM +0200, Mikko J Rauhala wrote: On pe, 2007-02-02 at 09:06 -0800, Tim Newsom wrote: If we have access to the mic and speakers while a call is in process, and we have the ability to record conversations etc... Where does the processor sit in that chain? Can we consume the voice, encrypt it and feed an encrypted datastream back out to the gsm module which would transmit it and another neo1973 user could receive the stream, process through decryption and play out? No. The GSM processor does its own audio de- and encoding, and its connection to the audio i/o is analog, as reported by LaF0rge on irc a while back (any misunderstanding is probably mine if present, though). We can get at the audio via the a/d converters, but not do anything really fancy directly. Thus, I refer you to my last mail; make a GSM data call (phone-to-phone if possible, Yes, that's also how commercial products like GSMK's cryptophone work (http://www.cryptophone.com/) -- - 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 https://lists.openmoko.org/mailman/listinfo/community
Re: Posibility to get status informations with the help of a LED
On Thu, Feb 01, 2007 at 11:47:02AM +0100, Robert Michel wrote: Salve denis! denis schrieb am Donnerstag, den 01. Februar 2007 um 11:03h: I searched the different hardware specs and archives of the mailing list but didn't find any information if LEDs will be one part of the hardware. AFAIK the Neo1973 v1 will have no LEDs (beside the screen backlight and inside the touchscreen) This is true, no LED. -- - 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 https://lists.openmoko.org/mailman/listinfo/community
[OT] Re: data encryption + Biometric security
On Thu, Feb 01, 2007 at 01:45:55PM -0500, Heilpern, Mark wrote: Unfortunately I couldn't provide 100% open source on the driver or the application libraries. That's not the point. Just send your device[s] to the Berlin CCC (feel free to route it via me). A proprietary windows app for enrollment+verification is fine. We're more than happy to see how we can do something about it. So far, many capacitive and infrared sensors could be fooled. I don't think the CCC has looked at SAW and related technology. In any case, to get back to the Neo1973, or even future phones: I don't think that there are many sensors that fulfill the following criteria 1) full hardware docs (may be under NDA, but allowing GPL software development) 2) small enough for a mobile device 3) cheap enough 4) not easy to fool You can probably have two or maybe three conditions fulfilled, but not all of them. -- - 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 https://lists.openmoko.org/mailman/listinfo/community
OpenMoko with Apple?
I just wondered if anybody had any reason to think that the phone will not work as well with Macs as it does with PCs. I want one bad, It is February, right??? Thanks, Ryan ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Encrypting voice comunications..
Mikko Rauhala wrote: pe, 2007-02-02 kello 09:54 -0800, Tim Newsom kirjoitti: So, though possibly inefficient, we could not some how take the analog audio stream, do some predictable and reversible encoding/encrypting then convert into sounds again.. Like doing base64 encoding for binary data.. In that way we are still sending audio information and letting it get encoded by the gsm module. Well. Even if the hardware supports feeding the GSM chip with audio from the SoC instead of the mic directly (does it? it would be useful for other stuff too, but I don't really know), it would be a rather nontrivial exercise to make an encryption transform that would properly survive lossy GSM encoding (and two d-a-d-conversions...) and be readable. GSM encoding is not lossy in that way. If you have perfect knowledge of the sample stream that the GSM coder has been passed, then you can accurately predict the output of the GSM coder. And you can then perfectly predict the decoders output stream in that way, and get a clean bitstream out that matches what was put in. In practice, well... If we have no A/D on either end, it might actually work, though there will probably be horrible framing problems. Bit errors are going to be really, really annoying, as the GSM codec has many properties of an encryption algorithm. It is designed on single bit errors to produce something that sounds to the ear - most of the time with reasonable input - similar. This means in practice that you will not get one bit error in the output, but most of them in error. It _is_ possible to correct this - you construct a model of the GSM codec state, and for each packet recieved, you update this model. If an output packet does not checksum cleanly, you try taking the GSM codecs output, back-calculating what the input to it must have been, try flipping bits on that input till you get output that checksums correctly. Unfortunately, this takes a lot of CPU power. I would be surprised if it's possible to correct double bit errors in real time on the latest desktop CPUs. I suspect in practice this scheme may only work for absolutely perfect links, where there is no noise, or where there is little enough noise that you can afford to throw away the affected packets. It would give a drastically better bandwidth, when it works, but you're going to need a fallback option for the other 80% of the time. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
Crane, Matthew wrote: With a point to point link what would be the minimal software stack needed? There's only so much CPU, might it be more appropriate to use a relatively lightweight process to rx/tx+encrypt/decrypt the data? In any case, the idea of an open encryption standard for cell phone communications is pretty appealing. Even a really anemic processor can manage AES or whatever at 8Kbit/sec, in realtime. However, as a near-zero CPU option, you could always use one-time-pads from the SD. Key management is substantially more annoying - you need 3M or so of pad per person per hour, and you can't reuse it. However, as long as nobody copies the pad, or compromises the phone, it's perfectly secure, even from advances in decryption. Overwrite the flash several times as the pad is read, and then take out and crunch the SD between your teeth if you need to destroy it. (Your Dental Bill May Vary) ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Sat, 3 Feb 2007, Ian Stirling wrote: Even a really anemic processor can manage AES or whatever at 8Kbit/sec, in realtime. However, as a near-zero CPU option, you could always use one-time-pads from the SD. Key management is substantially more annoying - you need 3M or so of pad per person per hour, and you can't reuse it. However, as long as nobody copies the pad, or compromises the phone, it's perfectly secure, even from advances in decryption. Overwrite the flash several times as the pad is read, and then take out and crunch the SD between your teeth if you need to destroy it. The pad can be stolen from both ends, and you'd have no perfect forward secrecy. Using a onetime pad directly is inheritantly dangerous. You are better of using the one-time pad to authenticate a diffie-hellman key exchange, and then use session keys which are never stored to flash, written to disk, and can be safely intercepted. And that's all provided your onetime pad is truly random, which it won't be, and that people won't accidentally use the same page twice. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973 video (was Re: What would be a realistic but challenging level for Bryce announced trophy money for video playback on the Neo1973? Re: h.264 format is now open?)
la, 2007-02-03 kello 14:47 +0100, Harald Welte kirjoitti: Also, the 770 has a landscape display. We have a portrait display. The S3C2410 cannot rotate the image, so you would have to rotate every frame in software, too! Modifying a player to render the image to be rotated in the first place shouldn't be hard, though perhaps any straightforward way to do that would degrade cache behaviour? (A wild guess.) Also, as re-encoding files spesifically for the Neo would be quite ok with me, rotating at that point would be quite a workable solution also. (I'll add that I don't necessarily expect the Neo1973 to play back decent video and won't blame FIC if it doesn't, but I'll sure _try_ it ;) Please note that the LCM we use in the Neo1973 can do hardware scaling, e.g. theoretically you can software-reconfigure the LCM to behave as QVGA 240x320, and then change the s3c2410_fb kernel driver timings accordingly. Now this is excellent news. I asked before if the XVideo extension present on the xdpyinfo output implied scaling support; apparently it didn't, but even having full screen QVGA capability should aid significantly. And yeah, do concentrate on the high-res UI for now, but great if you can at some point provide code/info for the QVGA mode. And Keith getting a p0 phone, that's a nice one too ;) -- Mikko Rauhala - [EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Posibility to get status informations with the help of a LED
Harald Welte wrote: I searched the different hardware specs and archives of the mailing list but didn't find any information if LEDs will be one part of the hardware. AFAIK the Neo1973 v1 will have no LEDs (beside the screen backlight and inside the touchscreen) This is true, no LED. Which is utterly sad, given I'm such a big fan of Blinkenlights... Trying to make sure we get a couple of multicolor LEDs in v2 ;) -- - Michael Lauer [EMAIL PROTECTED] http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: music applications: piano, drum, bell...
On Friday 02 February 2007 16:57, kkr scribbled in crayon on the back of a kid's menu: You're right, the first version will not be able of it. But in the V2 (2007-09-11), on the basis of this link (http://cs.nyu.edu/~jhan/ftirtouch/), I think that it will be possible :-) Quotation: Our technique is force-sensitive, and provides unprecedented resolution and scalability... But I don't know if it will use exactly the same technology. Could anybody confirm it? Does anyone know if an FTIR sensor is available in small form factors? What is the the thickness of the stack, and how much perimeter area is required? Heck, are the things even being commercially produced in ANY size yet? ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Posibility to get status informations with the help of a LED
One LED would be enough for me. But it's worth adding it to the hardware. ;) It's right that 1 to 4 hardware buttons would be nice as well. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Joe Pfeiffer Gesendet: Samstag, 3. Februar 2007 18:50 An: Michael 'Mickey' Lauer Cc: community@lists.openmoko.org Betreff: Re: Posibility to get status informations with the help of a LED Michael 'Mickey' Lauer writes: Harald Welte wrote: I searched the different hardware specs and archives of the mailing list but didn't find any information if LEDs will be one part of the hardware. AFAIK the Neo1973 v1 will have no LEDs (beside the screen backlight and inside the touchscreen) This is true, no LED. Which is utterly sad, given I'm such a big fan of Blinkenlights... Trying to make sure we get a couple of multicolor LEDs in v2 ;) Much as I love flashing lights (there's just something *wrong* when my ethernet hub looks more like a computer than my computers do!), I'd much rather get more hardware buttons. Wiring application launching to the buttons on my Palm is really, really nice. ___ 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
Re: [OT] Re: data encryption + Biometric security
Harald Welte wrote: On Thu, Feb 01, 2007 at 01:45:55PM -0500, Heilpern, Mark wrote: In any case, to get back to the Neo1973, or even future phones: I don't think that there are many sensors that fulfill the following criteria 1) full hardware docs (may be under NDA, but allowing GPL software development) 2) small enough for a mobile device 3) cheap enough 4) not easy to fool You can probably have two or maybe three conditions fulfilled, but not all of them. There are not-bad options - with something like a 4*256 pixel imager. Cheap, pretty small, docs - as it's just a camera, easy to fool... Well, it's a fingerprint sensor. There are interesting possibilities to add security to fingerprint sensors. For example, which finger? If three fingers of one hand have to be scanned in a particular order, or it requires a password afterwards. Or use it as a little optical mouse backwards, and have a 'signature'. It can even be used as a substitute for a thumbstick in the normal UI. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko with Apple?
On Sat, 2007-02-03 at 09:09 -0600, Ryan Kline wrote: I just wondered if anybody had any reason to think that the phone will not work as well with Macs as it does with PCs. I want one bad, It is February, right??? Thanks, Ryan Well, if we stick to our dominant open standards, then I see no reason that it shouldn't work worse on an apple (that is unless apple strays from the open standards again)...it would even be good to develop guides for interoperability on the official wiki. That has always bothered me how phones really only target PCs...we can do much better! Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
IRC logs, anyone?
On 02-02-07 18:13, Mikko J Rauhala wrote, in passing: as reported by LaF0rge on irc a while back I'm not an IRC guy, usually, but I like to browse IRC logs every once in a while. Are there IRC logs of #openmoko available anywhere? If not, is someone in a position to set this up? Thanks! Groetjes, Marnix ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko with Apple?
our phone talks syncML... iSync talks syncML... there is no problem On 2/3/07, Jon Phillips [EMAIL PROTECTED] wrote: On Sat, 2007-02-03 at 09:09 -0600, Ryan Kline wrote: I just wondered if anybody had any reason to think that the phone will not work as well with Macs as it does with PCs. I want one bad, It is February, right??? Thanks, Ryan Well, if we stick to our dominant open standards, then I see no reason that it shouldn't work worse on an apple (that is unless apple strays from the open standards again)...it would even be good to develop guides for interoperability on the official wiki. That has always bothered me how phones really only target PCs...we can do much better! Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: IRC logs, anyone?
On 2/3/07, Marnix Klooster [EMAIL PROTECTED] wrote: On 02-02-07 18:13, Mikko J Rauhala wrote, in passing: as reported by LaF0rge on irc a while back I'm not an IRC guy, usually, but I like to browse IRC logs every once in a while. Are there IRC logs of #openmoko available anywhere? If not, is someone in a position to set this up? http://apt.rikers.org/%23openmoko/ cheers Philipp ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: IRC logs, anyone?
Marnix Klooster wrote: I'm not an IRC guy, usually, but I like to browse IRC logs every once in a while. Are there IRC logs of #openmoko available anywhere? The NSLU2-Linux project (which I lead) is happy to provide both live and archived logs of #openmoko (and any other future OpenMoko related channels on Freenode) to the OpenMoko community. http://logs.nslu2-linux.org/livelogs/openmoko/ are the archives (we have been logging the channel since 29 Nov 1996). http://logs.nslu2-linux.org/livelogs/openmoko.txt is the current live log (it rolls over once per day). http://logs.nslu2-linux.org/livelogs/openmoko-prev.txt is for the previous day (this is the same as the most recent file in the archive). Note that #oe (for OpenEmbedded), #nslu2-linux (for NSLU2-Linux) and some other related channels are also logged in the same area with obvious pathnames. We have been logging #nslu2-linux since Feb 2005 and #oe since May 2005, and expect to continue support of these resources indefinitely (donations to the project easily cover all our expenses each year, and the server hosting and connectivity is graciously provided by OSUOSL). The box which serves this site is in the same rack as kernel.org and debian.org (see http://osuosl.org/hosting/clients#nslu2 for details). -- Rod ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Handy application ideas
2007/2/2, kkr [EMAIL PROTECTED]: ...Because, I presume that the thief will do very quickly a hard reset. There is no such thing like restore to factory default in Neo1973. What you load to flash memory, will remain there. And I bet the silent alarm application will be very popular among OpenMoko power users (ones able to configure application which doesn't show up in visual application manager, otherwise it doesn't make sense). -- Tomek Z. [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Posibility to get status informations with the help of a LED
On Sat, 3 Feb 2007, Michael 'Mickey' Lauer wrote: Harald Welte wrote: I searched the different hardware specs and archives of the mailing list but didn't find any information if LEDs will be one part of the hardware. AFAIK the Neo1973 v1 will have no LEDs (beside the screen backlight and inside the touchscreen) This is true, no LED. Which is utterly sad, given I'm such a big fan of Blinkenlights... You want a phone that looks like the front panel of an Imsai 8080, right? :-) ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
OpenMoko at Oreilly Emerging Telephony Conference
Heya, is anyone attending the Oreilly Emerging Telephony Conference in San Francisco? And, if so, is it worthwhile? I guess if enough people are going, good to have an OpenMoko BOF. Some of us will have phones by then so could have mini-hack-fest... http://wiki.oreillynet.com/etel2006/index.cgi?BOFs Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko at Oreilly Emerging Telephony Conference
GREAT idea. Whether or not we are attending the conference, enough of us live in the area that we should get together, if not at the conference then in a suitably friendly bar or restaurant. Perhaps we should find out when Sean is available, and see if we can work around that? Michael On Sat, 3 Feb 2007, Jon Phillips wrote: Heya, is anyone attending the Oreilly Emerging Telephony Conference in San Francisco? And, if so, is it worthwhile? I guess if enough people are going, good to have an OpenMoko BOF. Some of us will have phones by then so could have mini-hack-fest... http://wiki.oreillynet.com/etel2006/index.cgi?BOFs ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
RE: OpenMoko at Oreilly Emerging Telephony Conference
I will be. (You're pointing to the ETEL 2006 pages. The 2007 npages start at http://wiki.oreillynet.com/etel2007/ and the Who's Attending page is at http://wiki.oreillynet.com/etel2007/index.cgi?PlanningtoAttend ) -Original Message- From: [EMAIL PROTECTED] on behalf of Jon Phillips Sent: Sat 2/3/2007 3:54 PM To: community@lists.openmoko.org Subject: OpenMoko at Oreilly Emerging Telephony Conference Heya, is anyone attending the Oreilly Emerging Telephony Conference in San Francisco? And, if so, is it worthwhile? I guess if enough people are going, good to have an OpenMoko BOF. Some of us will have phones by then so could have mini-hack-fest... http://wiki.oreillynet.com/etel2006/index.cgi?BOFs Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ 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
Re: OpenMoko at Oreilly Emerging Telephony Conference
On Sat, 2007-02-03 at 16:27 -0800, [EMAIL PROTECTED] wrote: GREAT idea. Whether or not we are attending the conference, enough of us live in the area that we should get together, if not at the conference then in a suitably friendly bar or restaurant. Perhaps we should find out when Sean is available, and see if we can work around that? Michael Yah, that sounds goodSean, what do you think? Jon On Sat, 3 Feb 2007, Jon Phillips wrote: Heya, is anyone attending the Oreilly Emerging Telephony Conference in San Francisco? And, if so, is it worthwhile? I guess if enough people are going, good to have an OpenMoko BOF. Some of us will have phones by then so could have mini-hack-fest... http://wiki.oreillynet.com/etel2006/index.cgi?BOFs ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
RE: OpenMoko at Oreilly Emerging Telephony Conference
Same here. -Original Message- From: [EMAIL PROTECTED] on behalf of Sean Moss-Pultz Sent: Sat 2/3/2007 9:53 PM To: Jon Phillips Cc: community@lists.openmoko.org; [EMAIL PROTECTED] Subject: Re: OpenMoko at Oreilly Emerging Telephony Conference On Sat, 2007-02-03 at 16:45 -0800, Jon Phillips wrote: GREAT idea. Whether or not we are attending the conference, enough of us live in the area that we should get together, if not at the conference then in a suitably friendly bar or restaurant. Perhaps we should find out when Sean is available, and see if we can work around that? Michael Yah, that sounds goodSean, what do you think? Sounds like a great idea. Can you organize something? I seem to be free just about any night now. -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
