Re: video/graphics on GTA02
I had those questions too, I think that when 3D specs of the Glamo chip will be available, it will be possible to make some 3D-accelerated tasks, but I've no idea about the performances of this chip. Anyway I don't think it's so great... Right, but because it is local to the glamo where the memory is, it is possible it can surprise us a bit. Currently the Glamo data is under NDA, if anyone with experience on this end is interested to write the driver support they should definitely let us know. I've been toying with the idea of doing some 3D driver work on the Glamo in my spare time for a few months. I'm currently working on OpenGL ES support in Qt/Embedded (formally Qtopia Core). As part of this work, I'm trying to get to grips with the DRM and am starting work on a Qt/E screen driver which uses the DRM modesetting branch. I don't have any experience in writing 3D drivers, but I've poked around the DRM sources and have a fair idea of how it all hangs together. I've also had a brief look around the Xglamo sources. This would be a personal project, in my own time, completely unrelated to Trolltech. What would be involved in getting the docs for the Glamo? I.e. is it possible for an individual to sign the NDA and if so, what would the NDA contain. E-mail me off-list if you believe that would be more appropriate. Cheers, Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: video/graphics on GTA02
Tom Cooksey wrote: I had those questions too, I think that when 3D specs of the Glamo chip will be available, it will be possible to make some 3D-accelerated tasks, but I've no idea about the performances of this chip. Anyway I don't think it's so great... Right, but because it is local to the glamo where the memory is, it is possible it can surprise us a bit. Currently the Glamo data is under NDA, if anyone with experience on this end is interested to write the driver support they should definitely let us know. I've been toying with the idea of doing some 3D driver work on the Glamo in my spare time for a few months. I'm currently working on OpenGL ES support in Qt/Embedded (formally Qtopia Core). As part of this work, I'm trying to get to grips with the DRM and am starting work on a Qt/E screen driver which uses the DRM modesetting branch. I don't have any experience in writing 3D drivers, but I've poked around the DRM sources and have a fair idea of how it all hangs together. I've also had a brief look around the Xglamo sources. This would be a personal project, in my own time, completely unrelated to Trolltech. What would be involved in getting the docs for the Glamo? I.e. is it possible for an individual to sign the NDA and if so, what would the NDA contain. E-mail me off-list if you believe that would be more appropriate. Hi Tom, smedia wanted $15,000 for the spec docs for their chip. -- Lorn 'ljp' Potter Software Engineer, Systems Group, MES, Trolltech ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Price of the Freerunner spare parts
Le lundi 24 mars 2008 à 16:00 -0700, steve a écrit : I thought about spare parts a while back. The Issue is this. 1. WHAT do I stock ( which parts) 2. How Many do I stock? 3. How do I sell them to you? 4. What will it cost? 5. how do you get them? I suppose I could Offer component kits for sale. That would be the quickest thing for me to do. Sell the whole bag of parts; fix it your self. or build a business around this service. Hi Steve, As resellers of few products, we always share this information between resellers and the global manufacturer. This kind of risk should be shared between Openmoko and resellers, and they need a good communication to share statistics about returns and defect parts. Now, about shipping, spare parts ordering and cost, you probably need to setup a kind of extranet where the resellers will find the special price, customer's price, qty and where to get them (from a local hub). Best regards -- Alexandre ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Drawing icons...
Gianluca wrote: Hello, I am sorry to write directly to you, but in this moment I dunno who is the guy involved in drawing themes and icons in OM project. I am trying to create a new set of icons and themes and publish them when they will be ready, but I would to know how to proceed further. Usually I'm used to use Fireworks, PhotoShop and GIMP when create icons and themes, but for this project I need scalable vector graphic images. The only icons and themes I can see on this OpenMoko project are *already* built (various size) but unusable to change them to my needs. Where I can find them in a scalable, vector graphic way? Or, even better, who is the guy involved for this issue, so I can ask it to him directly? Best regards, Dear Gianluca Our icon designer just dropped off a CD this morning. I've posted all her files here: http://downloads.openmoko.org/ui_icons/moko_2007_2_icons.zip under a Creative Commons Attribution-ShareAlike 3.0 License. Enjoy. Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Drawing icons...
perfect, thank you! are there any special needs (no gradients, no blue, whatever)? On Wed, Mar 26, 2008 at 11:12 AM, Sean Moss-Pultz [EMAIL PROTECTED] wrote: Gianluca wrote: Hello, I am sorry to write directly to you, but in this moment I dunno who is the guy involved in drawing themes and icons in OM project. I am trying to create a new set of icons and themes and publish them when they will be ready, but I would to know how to proceed further. Usually I'm used to use Fireworks, PhotoShop and GIMP when create icons and themes, but for this project I need scalable vector graphic images. The only icons and themes I can see on this OpenMoko project are *already* built (various size) but unusable to change them to my needs. Where I can find them in a scalable, vector graphic way? Or, even better, who is the guy involved for this issue, so I can ask it to him directly? Best regards, Dear Gianluca Our icon designer just dropped off a CD this morning. I've posted all her files here: http://downloads.openmoko.org/ui_icons/moko_2007_2_icons.zip under a Creative Commons Attribution-ShareAlike 3.0 License. Enjoy. Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- My corner of the web: http://blog.ramsesoriginal.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
headphone (was: RE: Price of the Freerunner spare parts)
On Tue, 2008-03-25 at 18:58 -0700, steve wrote: But onto your specifics: 4. Headsets. It’s a standard part. Hi Steve, I looked on the wiki pages but can't find the specs. As nokia headsets with a 2.5mm plug don't work (different wiring and impedance) there are apparently several standards for headsets. Can you tell us which wiring the jack uses and what impedance the earplugs have? thanks marcus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: headphone (was: RE: Price of the Freerunner spare parts)
Am Mi 26. März 2008 schrieb Marcus Bauer: On Tue, 2008-03-25 at 18:58 -0700, steve wrote: But onto your specifics: 4. Headsets. It’s a standard part. Hi Steve, I looked on the wiki pages but can't find the specs. As nokia headsets with a 2.5mm plug don't work (different wiring and impedance) there are apparently several standards for headsets. Can you tell us which wiring the jack uses and what impedance the earplugs have? I already did this somewhere in wiki, IIRC. Wait a moment, I'll have a look where to find it. jOERG ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: headphone (was: RE: Price of the Freerunner spare parts)
Am Mi 26. März 2008 schrieb Marcus Bauer: On Tue, 2008-03-25 at 18:58 -0700, steve wrote: But onto your specifics: 4. Headsets. It’s a standard part. Hi Steve, I looked on the wiki pages but can't find the specs. As nokia headsets with a 2.5mm plug don't work (different wiring and impedance) there are apparently several standards for headsets. Can you tell us which wiring the jack uses and what impedance the earplugs have? [from a previous msg in this list] Am Di 4. März 2008 schrieb Gilles Casse: Hi all, I am a little bit embarrassed: my audio headset is lost, another one bought recently is not compatible (a 4 ring model for a Nokia, the [...] base = ground speaker left (internal impedance 33R) to ground. (+jackinsert detection) speaker right (internal impedance 33R) to ground. tip = mic electret condenser type, to ground. bias (power for mic) 2K2 from +3.3v(wolfson codec) (+HoldButton shortcircuit to ground) Due to the internal 33R resistors, any low impedance headset will not work (or only low sound). I guess 40R should be minimum impedance for the speakers. cheers jOERG ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC volunteer (as student)
Hello. On Mon, 2008-03-24 at 17:40, Patryk Szymczak wrote: I am also asking if someone is interested in mentoring me? It's likely that we coordinate the mentoring while we are doing the rankings. I have 1 year left to Master of Science degree. I also have half-time job in programming GSM terminals, GSM modules (Telit [1], Wavecom [2]), telemetry devices, mobile devices. At job, my responsibility covers everything, starting with contacts with client, lots of research, planning steps, implementing, testing, documentation maintaining and client training (I am planning to give it up for a summer because of GSoC) . I am also experienced in working in multinational team (especially with Germans) and love programming Python! Sounds impressive. If I had to choose something from the Ideas list [3] that would be (in decreasing order): * Support/documentation/tutorials/examples for building Applications in Python (so we could build apps as easily as on Symbian Python) Honestly I think with your skills, something else would be more suited. :) * Ambient Noise Detection I really like to see getting this done. Some nice demo app on top o it showing us what we can do with such things in the future. * Framework for Accelerometer Gestures (not a kernel driver) A lot people like to do this it seems. Still it is only one task atm, so we would need to make a choice. Better be prepared for other tasks and send applications, too. With your experience in GSM you perhaps also have nice ideas what we can do with this feature. :) Don't hesitate to offer different applications then the one you can find in the wiki. We are open for ideas here. regards Stefan Schmidt signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC 2008
Hello. On Mon, 2008-03-24 at 19:02, Niluge KiWi wrote: I'm interested in the accelerometers features [1]: Recognising gestures is a really important part of the interface between the user and the phone. Seems this ideas gets the interest of a lot people. Nice. :) But as we only can choice one of them for this application, you should be prepared for other applications, too. With the two accelerometers in the FreeRunner, I think we can recognise lots of gestures, not only simple ones like a click (which is already recognised by the accelerometers used in the FreeRunner). The main difficulty is probably to extract the useful data from the gestures noise : calibration may take time. The goal is to have an almost pre-calibrated library (an idea from the wish-list in the Wiki is to allow the user to record its own gestures, but I think it's not easy to do it simple for the end-user). Letting the user add new gestures is a key feature IMHO. Also letting them combine different gestures to new ones. We should make it easy for people beaing creative with this. That's where innovation can start. :) If we can have a preset of already known gestures shipped with the device, great. I'm also interested in working in the ambient noise detection in second choice. Also interesting. What I never understand completely is what kind of cool stuff we can do with this. I mean detecting the ambient volume level and adjust the ringing, etc is nice, but can we do more with it? Fancy things like detect if we are in a car or plane and react accordingly? regards Stefan Schmidt signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Price of the Freerunner spare parts
joerg wrote: AFAIK, the BL-?C will fit and power the device, but like bat for GTA01 they have no telemetry (smart bat). So you won't get a bat-fuel-indicator with nokia bat. Charging isn't quite tested i think. That's an important thing imho...! Then I've read a thread on the kernel list some time ago and the lasting time of the non-FIC batteries was quite lower! -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC 2008
On Tue, Mar 25, 2008 at 4:36 PM, Stefan Schmidt [EMAIL PROTECTED] wrote: Hello. On Mon, 2008-03-24 at 19:02, Niluge KiWi wrote: I'm interested in the accelerometers features [1]: Recognising gestures is a really important part of the interface between the user and the phone. Seems this ideas gets the interest of a lot people. Nice. :) But as we only can choice one of them for this application, you should be prepared for other applications, too. With the two accelerometers in the FreeRunner, I think we can recognise lots of gestures, not only simple ones like a click (which is already recognised by the accelerometers used in the FreeRunner). The main difficulty is probably to extract the useful data from the gestures noise : calibration may take time. The goal is to have an almost pre-calibrated library (an idea from the wish-list in the Wiki is to allow the user to record its own gestures, but I think it's not easy to do it simple for the end-user). Letting the user add new gestures is a key feature IMHO. Also letting them combine different gestures to new ones. We should make it easy for people beaing creative with this. That's where innovation can start. :) If we can have a preset of already known gestures shipped with the device, great. I'm also interested in working in the ambient noise detection in second choice. Also interesting. What I never understand completely is what kind of cool stuff we can do with this. I mean detecting the ambient volume level and adjust the ringing, etc is nice, but can we do more with it? Fancy things like detect if we are in a car or plane and react accordingly? Maybe the GPS would be better suited to that... Speed below 30km/h = walking / running Speed above 40km/h and below 240km/h = driving Speed above 600km/h = plane. Naturally however there should be an option to override this :) Cheers, Federico ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: GSoC 2008
But as we only can choice one of them for this application, you should be prepared for other applications, too. Yea, whatever API into the accelerometer is made should return some form of condensed data but not necessarily be tied to the idea of gestures. Different applications may want the data at the same time. E.g. background car crash detector (that dials out and knows when it's on the road) working concurrently with gestures for answering phone etc. Maybe the sort of thing where an api would allow an app to register a set of gesture, defined mathematically, and only one system process polls for matching events. Doesn't sound like multiple processes polling the data, or even processing the gestures, would work as nicely. Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Schmidt Sent: Tuesday, March 25, 2008 10:36 AM To: community@lists.openmoko.org Subject: Re: GSoC 2008 Hello. On Mon, 2008-03-24 at 19:02, Niluge KiWi wrote: I'm interested in the accelerometers features [1]: Recognising gestures is a really important part of the interface between the user and the phone. Seems this ideas gets the interest of a lot people. Nice. :) With the two accelerometers in the FreeRunner, I think we can recognise lots of gestures, not only simple ones like a click (which is already recognised by the accelerometers used in the FreeRunner). The main difficulty is probably to extract the useful data from the gestures noise : calibration may take time. The goal is to have an almost pre-calibrated library (an idea from the wish-list in the Wiki is to allow the user to record its own gestures, but I think it's not easy to do it simple for the end-user). Letting the user add new gestures is a key feature IMHO. Also letting them combine different gestures to new ones. We should make it easy for people beaing creative with this. That's where innovation can start. :) If we can have a preset of already known gestures shipped with the device, great. I'm also interested in working in the ambient noise detection in second choice. Also interesting. What I never understand completely is what kind of cool stuff we can do with this. I mean detecting the ambient volume level and adjust the ringing, etc is nice, but can we do more with it? Fancy things like detect if we are in a car or plane and react accordingly? regards Stefan Schmidt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC volunteer (as student)
It's likely that we coordinate the mentoring while we are doing the rankings. Good to know, so there is no place for private discussion with potential mentor about how such project could be done? Sounds impressive. It is very nice to hear it :) * Ambient Noise Detection I really like to see getting this done. Some nice demo app on top o it showing us what we can do with such things in the future. Actually I think that there are 2 solutions for ambient noise detection: 1) We will need knowledge from 2 disciplines: signal processing and acoustics. Solution 1a) consists of: * once per fixed time interval audio path is activated * we take a short sound sample (~500ms) * it is time to put in under processing: a) filter for detecting and removing cracks - e.x. if you have phone in your trouser's pocket, then there would be lots of such cracks. b) simple general noise recognition algorithm Solution 1b) consists of: * once per fixed time interval audio path is activated. I assume that whole audio path is activated (both mic and speaker) * we begin gathering sound sample from microphone * we generate a fixed sound 'beep' using speaker for ~300ms (a special preprepared sound sample - a model) * we stop gathering sound * it is time to put in under processing: a) filter for detecting and removing cracks - e.x. if you have phone in your trouser's pocket, then there would be lots of such cracks. b) sound goes by PCB much faster than through the air so we need to remove this mess from recorded data c) simple general noise recognition algorithm based on comparing to model sound. Unfortunately, that solution needs lots of data processing. I can not estimate it right now, but it might be too heavy. There is another idea (2): We need to build some generic algorithm and write learning software. A special genetic filter will be automatically created after testing in as many different conditions as possible. That would be learn cases for genetic algorithm. It will be now easy to use it for sound samples in typical use. Again: does anyone have sufficient knowledge and is interesting in mentoring me? With your experience in GSM you perhaps also have nice ideas what we can do with this feature. :) Don't hesitate to offer different applications then the one you can find in the wiki. We are open for ideas here. Unfortunately, I don't have OpenMoko phone and I am not familiar with its GSM features so it is hard for me to find something that OpenMoko lacks of. I have a little idea for something that probably is not useful for anything than experiments :) I am talking about GSM (BSS) positioning. Imagine that OpenMoko GSM engine performs extended network survey in fixed interval time (something like AT#CSURVEXT). It looks for base station identification codes and receiption levels (in dBm) around phone. Now it is time to put some algorithm (easy one) and we can estimate direction of movement with accuracy even less that 7 meters :) Now imagine that before processing, OpenMoko can check for precise GPS position and after lots of samples taken, we could have some adaptive algorithm for tuning coefficients in positioning algorithm based on BSSes. After some time, we ?could? (maybe) have good enough BSS (GSM) positioning without GPS! -- -- Patryk Szymczak ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Dash Express Software on the freerunnner?
I was wondering if any portion of the Dash Express software might be made available for the openmoko freerunner, it seems like a great way to enhance both offerings (More capable phone, better traffic data). -Will ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSoC Interest
On Tue, Mar 18, 2008 at 12:44 PM, Mark Schneider [EMAIL PROTECTED] wrote: Dear Openmoko Community, snip Since most of my experience is in hardware and low level software (device drivers and kernel hacking), I think my skills would be best used there, however, I would not be apposed to working in higher level middleware. Initially, I had wanted to write an open source device driver for the GPS device in the Neo1973 that would provide a standard NMEA output which gpsd could interpret. However, I see that the Freerunner will be getting a new GPS device, so this may no longer be necessary. Other ideas that I saw on the GSoC wiki page that I thought might be of interest: Ad hoc communication via Bluetooth/WLAN Cooperative Differential GPS Accelerometer Gestures My willingness to work on the project is not conditional on whether my application gets accepted. I would like to work regardless of Google supporting me. If there are any other projects that you think would be good, please let me know. I would like to discuss this more before I submit my application. Email works well, or you can occasionally find me on #openmoko under the handle 'queueRAM'. Regards, Mark Schneider Dear Openmoko Community, Thank you to those who have responded to my questions. After some more thought, I would like to propose another idea for a project. I have seen that the Neo1973 takes a while to boot (~1.5-2 minutes). I would like to see if there are opportunities to speed up the boot process. I have noticed that there has been some previous work done by Alessandro to profiling the boot process with bootcharts [1]. My idea is to start with the kernel, to see where in the kernel there might be room for improvement and then continue into the boot process by using Alessandro's bootcharts work as a reference and coming up with other ways to measure the processes that consume the most time and try to work with them to improve their speed. Before submitting this in a GSoC application, i wanted to throw this idea out there in case anyone had any thoughts on the matter and to make sure this work hadn't already been done. Thanks, Mark [1] http://wiki.openmoko.org/wiki/Bootcharts ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA01 Machine Config Renamed
The machine config file for gta01 and gta02 machines has been renamed to om-gta01 and om-gta02 to reflect better the manufacturer of the phones is actually Openmoko. The will mean people probably need to clean tmp/ Graeme ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
