Re: Terminal for ASU
On Wednesday 23 July 2008 05:56:41 Jacob Peterson wrote: > Ken, I too feel your pain. I had just stated to get things setup, then I > decided to update and to my surprise, all applications requiring a keyboard > are now useless. I ended up reverting back to the July 21st snapshot for > now, but I will try editing the illume theme and rebuilding once I can > locate the required tools to edit the themes. The theme files are "edje" files. There is edje_cc to compile them from edc files and there is edje_decc to decompile them (can be compiled with edje_cc again). So get a illume.edj where raster forgot to remove the "QWERTY" button, get the next rev (fixing up that "oversight"), decompile both edj files, see the difference, patch in the keyboard button. Ask someone in the community to provide illume-theme packages which are up-to-date but have the qwertz button present? I hope this hint helps z. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Terminal for ASU
On Wednesday 23 July 2008 05:32:34 Stroller wrote: > After all the efforts that Openmoko have made over being open, I am > just amazed that design decisions that affect everyone are being made > in secret. Check the openmoko-devel/disto-devel archives from back then. Sure the decision was made "in private" as someone walked into raster's office and discussed this in person. The mailing list thread on the issue and the request for me to change Qtopia to send the matchbox hints were done in public. I know that not everyone wants to read the development mailinglists and that it is quite hard to keep track with every OM mailinglist (I don't) but on the other hand just because I'm unaware of certain threads doesn't make things "private". regards z. PS: If you can't find the discussion from back then I can give you a hand to search the archives. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Terminal for ASU
On Wednesday 23 July 2008 03:39:54 Ken Restivo wrote: > Can someone document what hacks are available to bring the Illume keyboard > back, and to manually trigger it with that little "qwerty" button that used > to be there, in case the designers decide they don't want users to be able > to type things in anymore? Asking for "hacks" is almost certainly the wrong thing to do. So keyboard stopped working in your org.openmoko.asu.stable build? Well, then let us track down the regressions in e and illume. no hacks needed. z. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OSCON get together
On Sun, 13 Jul 2008, Sameer Verma wrote: > I will be there as well. Great - email me off-list and let's chat about setting up a BOF or something. (-: -- Asheesh. -- You are dishonest, but never to the point of hurting a friend. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Terminal for ASU
Ken, I too feel your pain. I had just stated to get things setup, then I decided to update and to my surprise, all applications requiring a keyboard are now useless. I ended up reverting back to the July 21st snapshot for now, but I will try editing the illume theme and rebuilding once I can locate the required tools to edit the themes. Having a manual keyboard button is an important feature. The automatic keyboard is not going to read my mind and know if I want it visible or not. There may be times that I want the extra screen space to look at something without half the screen taken up as the automatic keyboard suggests or maybe the automatic keyboard isn't 100% bug free with 100% of applications properly implementing support for it. In a perfect world, a system without a manual button might be feasible. However this is far from a perfect world and with an open system like this it is unrealistic to expect 100% of all applications that can/will be used, to work perfectly with the automatic keyboard. Hopefully the order to remove the button will be reversed, as it is sorely missed. -Jacob On Tue, Jul 22, 2008 at 8:39 PM, Ken Restivo <[EMAIL PROTECTED]> wrote: > On Tue, Jul 22, 2008 at 09:01:24AM +0200, =?ISO-8859-1?Q?C=E9dric_Berger_ > wrote: > > Indeed I fail to see the advantage of having no manual triggering of > keyboard. > > On my desktop PC, I have never dreamt of my keyboard popping out of a > > drawer when it thinks I should need it... > > > > And this morning, after my daily opkg upgrade... I rebooted ASU and I > > am stuck, not even able to enter my SIM PIN !! > > Because... there was no keyboard on the screen ! > > > > > > I experienced this today too. It rendered my FR useless. Everything I'd > finally gotten working yesterday (VTE, Minimo, tasks app) stopped working > today, and I'm stuck with, essentially, a brick. > > The keyboard doesn't even pop up automatically anymore, and there's no way > to add it. > > Can someone document what hacks are available to bring the Illume keyboard > back, and to manually trigger it with that little "qwerty" button that used > to be there, in case the designers decide they don't want users to be able > to type things in anymore? > > Thanks. > > -ken > > ___ > 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: Terminal for ASU
On 22 Jul 2008, at 14:36, Carsten Haitzler (The Rasterman) wrote: >> ... >> Sorry to trouble you, but who are these designers, please? > > i'll let them speak up if they wish to be part of a debate on this. > it's up to > them. I'd be grateful if someone @openmoko could be a bit transparent about this. > ... i have technical reasons why i think the > move to remove any such manual control is a bad thing and have made > them clear > often enough. This is why openness would be beneficial to the community. After all the efforts that Openmoko have made over being open, I am just amazed that design decisions that affect everyone are being made in secret. >> I think many of us would like to contribute to the ASU, seeing as >> how it's the future of Openmoko, so this would appear to be a >> limitation upon community contributions. > > as such we are paid by openmoko to do what we are told to do by > the design > department and that is what we then do. you in the community can go > and do your > own themes and patches and packages and do what u want. Openmoko promotes itself as an "open" company soliciting contributions from community developers. That's great! But if that means I can only develop apps that run ON the phone - or if I want to code for core apps then I need to fork - it would be great if they could say so. Sorry to use the alarmist word "fork" here, I don't mean it that way. But right now it appears difficult to contribute changes to the ASU window manager (if I'm understanding correctly that that is the component which is missing a manual keyboard toggle button). It is pointless me doing so if I have to maintain this patch all on my own and no-one else is going to benefit. If I want to add a manual keyboard toggle button then that's exactly the scenario - if other people want to use it I effectively have to "fork" the code, maintaining a whole package or firmware image, simply so people can download it from my website. >> Where are the design documents which say "no keyboard toggle button >> should be included", please? If one wishes to contribute code or >> patches to ASU then I guess it's necessary to know this, or one will >> find patches rejected because they don't meet this design >> specification? > > well design documents are pretty thin on the ground. i was told so in > email/irc directly to do this. i had a manual button there > originally and was > explicitly told to remove it. Right. So right now there's no point in members of the community trying to contribute patches to core features or functionality, lest these patches get declined because the designers don't happen to like them. Even worse is the prospect of you saying "great! this is really useful, I'll add it to git" and then the community member feeling disappointed (pissed off) later when you're told to remove it. IMO it's crazy for you (the senior developer to ASU? you're surely the most active?) to have his hands tied by these shadowy "designers" who can interfere apparently on a whim. Especially when they're coming up with crazy decisions that are technically poor!! On 21 Jul 2008, at 19:47, Carsten Haitzler (The Rasterman) wrote: >>> ... >>> the problem is the designers decided that ASU is not to have any >>> manual keyboard toggle button because it will disturb the design >>> and/or confuse users, so all apps and toolkits need modification >>> to talk a "protocol" to bring up the keyboard on demand (no >>> manual controls). that is why you need to do this. They asked you to take out a simple button, in favour of a whole protocol, when no protocol currently exists? Aside from the points you make about porting existing (Gnome, KDE, whatever) applications to ASU, what's the hard in keeping the button until this protocol is later developed? Please would the "designers" speak up so we can flame them directly. Presently I think you're misnaming these individuals (this individual?). A design document is required for a design, so that everyone can see the rationale for decisions. Everything that's implemented should have a reason (stated in the design document), and that a button might "disturb the design and/or confuse users" is not a rational reason for having broken apps which can't use a bloomin' keyboard. Making ad-hoc demands for change after the fact is not "designing" it is *meddling*. Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: the answering machine
On 20 Jul 2008, at 05:13, Frederik Sdun wrote: > ... > I'm one of the GSoC students and work on the answering machine. ... Hi there, Is there any page on the Wiki about your work? I'm posting a fair bit to the documentation mailing list at present and today discovered this page: http://wiki.openmoko.org/wiki/Voice_Mailbox It looks like the current Voice_Mailbox wiki page is simply a wishlist and unless anyone is implementing its specifics then that page is pretty much useless. It would be nice if you could take a look at that page & see if there's any ideas there that would be valuable to your implementation. Unless anyone is currently working on the Voice_Mailbox _as described_ on that page ISTM to be a candidate for deletion or archival. It would be nice, in that case, to link it to your implementation, seeing as that's sure to appear in official images & repositories. I am posting this to the documentation mailing list - I have cc'd - community seeing as I'm replying to your message there, but please make any further responses regarding wiki pages to documentation, please. Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
On Wed, Jul 23, 2008 at 6:41 AM, Frederik Sdun <[EMAIL PROTECTED]> wrote: > Hi, > > I'm one of the GSoC students and work on the answering machine. I > already use this concept in my project and it uses modules so it might > be possible to extend it to fit your needs. It's implemented in vala so > you can use all GLib functionality and more. As far as you can create > vala bindings for it or you can use C and GObject. > > I just implemented 2 types of connecting rules yet: all of them or one > of them. Also a complex type might be possible. > > my current rules are: > -time ( depending on day of week and current time) > -calendar ( depending on your entries in you calendar ) > -GPS ( depending on a GPS position and a radius around this ) > my current actions are: > - run a custom command on startup and at the end > - answer call: yes it is an answering machine > - answer asterisk call: this should also be answered > - send sms: send a user defined message to a caller > > Here you can find the class diagram [1]. it will be updated soon. > > Regards, > Frederik > > [1]: http://v1187.ncsrv.de/classes.jpeg > Frederik, Can you explain how/where you define the rules? Also, how are you gathering event information? Thanks Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
fledgling open source web tablet project.... similar to moko business model
http://www.techcrunch.com/2008/07/21/we-want-a-dead-simple-web-tablet-help-us-build-it/ so steve, which other products are YOU going to bring us (joke, i know you have hands somewhat full at the moment ) jw ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Terminal for ASU
On Tue, Jul 22, 2008 at 11:36:27PM +1000, Carsten Haitzler wrote: > On Tue, 22 Jul 2008 02:05:48 +0100 Stroller <[EMAIL PROTECTED]> > babbled: > > > > > On 21 Jul 2008, at 19:47, Carsten Haitzler (The Rasterman) wrote: > > > ... > > > the problem is the designers decided that ASU is not to have any > > > manual > > > keyboard toggle button because it will disturb the design and/or > > > confuse users, > > > so all apps and toolkits need modification to talk a "protocol" to > > > bring up the > > > keyboard on demand (no manual controls). that is why you need to do > > > this. > > > personally i think you need a manual control because, as such, many > > > apps and > > > toolkits will not be changed, or they will get it wrong and give > > > you a keyboard > > > when you don't want one, or decide not to give you one when you > > > do... but > > > that's not my call. > > > > Hi Carsten, > > > > Sorry to trouble you, but who are these designers, please? > > i'll let them speak up if they wish to be part of a debate on this. it's up to > them. i am not one way or another here. not going to defend or dob-in. i have > no vested interests one way or another. i have technical reasons why i think > the > move to remove any such manual control is a bad thing and have made them clear > often enough. i am not going to get into it again. i am staying neutral - i > have my professional opinions and personal ones, but my job is to implement > what is designed by others to the best of my ability - if something is > technically not possible or utterly infeasible - i can't do it, but removing a > manual keyboard button is perfectly easy to do, and so it gets done. > > if i hadn't made it clear.. i am being neutral on this - i am simply stating > the facts as they are. i am not wanting to beat anyone one over this. i am > just stating facts. emotions and opinions thereafter are entirely those of > people as they wish to express them - they were not intended or written here. > just sticking to facts. > > > I think many of us would like to contribute to the ASU, seeing as > > how it's the future of Openmoko, so this would appear to be a > > limitation upon community contributions. > > as such we are paid by openmoko to do what we are told to do by the design > department and that is what we then do. you in the community can go and do > your > own themes and patches and packages and do what u want. > > > Where are the design documents which say "no keyboard toggle button > > should be included", please? If one wishes to contribute code or > > patches to ASU then I guess it's necessary to know this, or one will > > find patches rejected because they don't meet this design specification? > > well design documents are pretty thin on the ground. i was told so in > email/irc directly to do this. i had a manual button there originally and was > explicitly told to remove it. i argued that this was a bad move for many Please tell me who told you to do this so I can flame him :-) He ruined my whole afternoon. > technical reasons (porting of apps such as SDL games that don't use gtk or qt > that now all need modifications, i listed the apps it will break, the > reasoning > of not always wanting a virtual keyboard (ie an entry box may be focused, but > you just want to READ the content, not edit) etc. etc.) but it was made > entirely clear that the button had to go - arguments or not. as i remember the > reasons being that "it cluttered the interface", was "confusing", > "unnecessary" > and that "all applications can be modified to talk the protocol anyway". or > something to that effect. this was a while ago so i'm a little hazy on the > reasons - but it was something like that. > > again - i'm neutral. i'm just a programmer. i just implement code. > Smart move. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Terminal for ASU
On Tue, Jul 22, 2008 at 09:01:24AM +0200, =?ISO-8859-1?Q?C=E9dric_Berger_ wrote: > Indeed I fail to see the advantage of having no manual triggering of keyboard. > On my desktop PC, I have never dreamt of my keyboard popping out of a > drawer when it thinks I should need it... > > And this morning, after my daily opkg upgrade... I rebooted ASU and I > am stuck, not even able to enter my SIM PIN !! > Because... there was no keyboard on the screen ! > > I experienced this today too. It rendered my FR useless. Everything I'd finally gotten working yesterday (VTE, Minimo, tasks app) stopped working today, and I'm stuck with, essentially, a brick. The keyboard doesn't even pop up automatically anymore, and there's no way to add it. Can someone document what hacks are available to bring the Illume keyboard back, and to manually trigger it with that little "qwerty" button that used to be there, in case the designers decide they don't want users to be able to type things in anymore? Thanks. -ken ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New Freerunner User - Stick with GTK & Any voicemail apps or monitors?
I'm not going to have much time for playing with the toolchain for a while, so for now I'm trying to use my freerunner as a replacement for my existing GSM phone. (A Motorola v551 that's getting long in the tooth) So far, given that this thing is effectively an open beta, I'm very impressed (and it certainly pays off in geek chiq at the office). I've had no problems sending and receiving calls and SMS using my old SIM and I've been able to update everything over the USB/Ethernet from a machine running Vista of all things! No love from the GPS of course, we'll see how that goes over time. Two questions: A) If part of my goal is to be a beta tester should I stick with the default software stack or switch to one of the other options? B) Are there any applications out there for managing or monitoring a voicemail account? regards, -- Alex Fitzpatrick ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is Qtopia much faster?
On Mon, Jul 21, 2008 at 4:38 PM, Tilman Baumann <[EMAIL PROTECTED]> wrote: > I might do qtopia more wrong than is fair. But they modelling just a > regular smart phone like you can get from most vendors. > With a very closed (but opensource) framework wich you can develop for. > > You can not port your garden variety x11 app to qtopia. Which you can > (almost) do with the other frameworks. This bias makes no sense. QT is a toolkit. So is GTK. It's OK if you prefer the APIs of one to the other, or prefer plain old C to C++. But what does "closed" mean? It's been getting more and more open for years now. Finally even QTopia is GPL... I think that's the last piece isn't it? Is it because it already emerged fully-formed, and was not depending on community help for its very existence, that you think it's more closed? What does "garden variety" mean? I don't think there's any such thing as a "garden variety X11 app" unless you are using xlib itself, which very few people bother with. Or maybe you are thinking about older toolkits like Motif and Athena Widgets? With QT, apps tend to be smaller because the toolkit is so complete, that you have less code to write. You pay a cost in having a larger library to load, but then all the apps benefit from it. So having a simpler, more spartan toolkit can cut both ways. But whatever, it's just Gnome/KDE all over again, I shouldn't expect a logical argument I guess. > And of course the fact that it does not use x11, i expected you to > know that. ;-) But the plan is that it will, right? And then we will see, which is really faster. It would be an option in either case to do some optimization: kdrive could accelerate some graphics operations, and QTopia-on-framebuffer could do the same. All else being equal, the one with fewer layers ought to be faster. But kdrive is likely to get more community attention, so maybe we will realistically see some hardware acceleration eventually. > It really depends, many people like the simple qtopia stack. But i did > not buy my Neo to have a phone that does essentially what any better > Motorola or Nokia could do too. Anyone can write new QT apps. It's even fun, and fairly rapid development compared to typical C/C++. The Motorola phones unfortunately made it difficult to install them though, used a very old version of QT, and customized it too, so "garden-variety" QT apps aren't too well integrated even if you can get them to run. I think Nokia smartphones were mostly running Symbian until recently; I don't have experience with their QT models (if they have some already). > It would look great on a motorla razr (or however these things are > called today) > But i did not find it to fit very well on the extremely large screen > resolution and touchpad only input. The RAZR used a completely proprietary OS and toolkit. The high-end touchscreen phones are exactly the ones that are mostly running QT or Symbian, in the commercial world. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Anyone using FR as a phone?
Is bluetooth working to the degree where a bluetooth headset can be used instead? While it isn't perfect, I have an Aliph JawBone headset and it works reasonably well when there's no wind around. Also have a Sony Ericsson HBH 300 but people always say I sound too quiet - maybe I could amplify the volume on the FreeRunner in ways I can't on regular phones? On Tue, Jul 22, 2008 at 6:33 PM, Al Johnson <[EMAIL PROTECTED]> wrote: > On Tuesday 22 July 2008, Scott Derrick wrote: >> Come on! Blame the telcos for the Neo echo!! Thats stretching it. > > Take a breath. Reread what I said. I'm not blaming them, but they may be a > factor in why people report widely differing levels of echo. > > > > ___ > 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: Why is Qtopia much faster?
On Wed, 23 Jul 2008 09:38:35 +1000 Lorn Potter <[EMAIL PROTECTED]> babbled: > > and so from that point of view - qtopia would be a loser as it has many > > fewer apps written for it than general X11. :) > > No, because it is easy to make a Qt app into a Qtopia app. > two or three line change in the best case (QApplication -> QtopiaApplication > and for the menu) still limits it to qt apps only. gtk, xul, fltk, efl, raw xlib... need major work. an x11 environment can ALSO run the qt apps... so it's a superset. > >>> 1. do a whole port of the app to qt/qtopia (work work work!) > >>> (not to mention now that this basically means you pay nokia a license > >>> fee, or your app must be GPL, can't be mit-x11, bsd, APL, MPL etc.). > >> You want to charge people money for your commercial app? so why is it bad > >> for Trolltech ^H^H^H^H^H^H^H^H^H Nokia to do the same? > >> GPL ensures that the code and software remains free. Besides, the Neo is > >> touted as a "Free your phone" phone. Why would you want to install non free > >> apps on it? I could just as easily use any Nokia phone in existence. > > > > i never mentioned commercial apps nor money. > > Yes you did. "pay for a license' implies both money and you needing a > commercial license, which implies you intend on producing closed source > applications. no - i meant either i accept GPL, OR i pay for a license TO nokia to AVOID the GPL infecting my software. me paying for a license to not mean i thus obviously am going to make my library app closed and force people to pay for it, but the reality that i have to fork out money to ship something licensed as NOT being GPL, invariably will lead to having to charge for it. > > your idea of open is not mine - or > > the next person along's. i prefer the open of mit-x11/bsd, not GPL. all are > > free, open and cost $0, but GPL places more restrictions. > > > >> Actually you are free to license the code you write in any way you want. It > >> just has to be compatible with the license you link it to. No one is > >> stopping you from writing your code in multiple licenses anyway. > > > > if i want to write a library and license it with a less restrictive, yet > > still open license, it BECOMES GPL - for all purposes GPL will virally > > impose itself. this is not the case if i use gtk, sdl, efl etc., but is the > > case with qt. it then would be my choice, as a developer of open, and free > > software, to choose a toolkit that doesn't limit my own freedom to license > > as i please. remember i never talked about charging for software or it > > being closed. :) > > So, instead you choose to limit the freedom of your users, which include > other developers. how does this limit them? they have access t more apps, more toolkits and more software and have the CHOICE to choose their applications, be they open, or closed, GPL, LGPL, MIT-X11, BSD etc. etc. etc. how does this seem like less freedom to you? > btw, kde libs are licensed LGPL. i know. but as they invariably use QT, GPL superceeds LGPL in terms of being more restrictive. -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
VTE font size
How can I adjust the font size in the VTE terminal? I'm using it with the ASU. Is it the same xrdb/.Xresources style way that is used on, say, xterm or rxvt? There doesn't appear to be any options menu or other settings available for VTE. The default font is too big though, there's not even enough room to even fit the path, let alone any commands or output. And xrdb doesn't seem to be installed on the phone either. Thanks. -ken ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is Qtopia much faster?
Carsten Haitzler (The Rasterman) wrote: > On Wed, 23 Jul 2008 07:36:06 +1000 Lorn Potter <[EMAIL PROTECTED]> babbled: > >>> i guess i just don't lik the idea of a thin vertical stack where at each >>> layer 1 choice has been made for me and i'm stuck with it, like it or not, >>> or i move to a whole different stack. eg - must use qt, or must use gtk, or >>> must use efl. allow the choice to be made at the latest stage - not the >>> earliest. i prefer the idea of an ecosystem where all these toolkits and >>> mechanisms get along and co-habitate. jungle vs ivory tower guess... i'm a >>> jungle kinda guy! :) anyone want a banana? :) >> I guess you have to define your target audience. The small niche linux hacker >> group or the larger general phone community that requires a consistent look >> and feel. Perhaps a good read of the Human Interface Design Principles at >> apple might do some good. > > in that case, maybe we should all have given up - trolltech included, and > simply have used windows and visual studio - so we have a consistent os, > programming environment, ui toolkit etc. why should there be any variety or > choice - i mean... qt is a waste of time competing because it's different to > everything else. > > variety is a fact of life. UNLIKE other platforms we get the chance to support > all of the variety - at once easily. other platforms force you into their idea > of toolkit, like it or no. at least i dont have to reboot just to run another > app using another toolkit... > >>> sure, but any non-qt app.. will be a behemoth to port. you either: >> just as any non- >> Like porting a qtopia app to gpe. or a windows app to linux. are you going to >> include win32 or S60 port because they have _way_ more applications written >> for them. > > and so from that point of view - qtopia would be a loser as it has many fewer > apps written for it than general X11. :) No, because it is easy to make a Qt app into a Qtopia app. two or three line change in the best case (QApplication -> QtopiaApplication and for the menu) > >>> 1. do a whole port of the app to qt/qtopia (work work work!) >>> (not to mention now that this basically means you pay nokia a license fee, >>> or your app must be GPL, can't be mit-x11, bsd, APL, MPL etc.). >> You want to charge people money for your commercial app? so why is it bad for >> Trolltech ^H^H^H^H^H^H^H^H^H Nokia to do the same? >> GPL ensures that the code and software remains free. Besides, the Neo is >> touted as a "Free your phone" phone. Why would you want to install non free >> apps on it? I could just as easily use any Nokia phone in existence. > > i never mentioned commercial apps nor money. Yes you did. "pay for a license' implies both money and you needing a commercial license, which implies you intend on producing closed source applications. > your idea of open is not mine - or > the next person along's. i prefer the open of mit-x11/bsd, not GPL. all are > free, open and cost $0, but GPL places more restrictions. > >> Actually you are free to license the code you write in any way you want. It >> just has to be compatible with the license you link it to. No one is stopping >> you from writing your code in multiple licenses anyway. > > if i want to write a library and license it with a less restrictive, yet still > open license, it BECOMES GPL - for all purposes GPL will virally impose > itself. > this is not the case if i use gtk, sdl, efl etc., but is the case with qt. it > then would be my choice, as a developer of open, and free software, to choose > a > toolkit that doesn't limit my own freedom to license as i please. remember i > never talked about charging for software or it being closed. :) So, instead you choose to limit the freedom of your users, which include other developers. btw, kde libs are licensed LGPL. -- Lorn 'ljp' Potter Software Engineer, Systems Group, Trolltech, a Nokia company ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS software fix, just CRUFT?
Scott Derrick wrote: > With the GPS hardware fix done(10pf cap installed) are the software > changes to the kernel/modules just added cruft? IE. do they add > anything useful? They save people from destroying their Freerunners trying to do some amateur-level soldering or ordering incorrect capacitors. ;o) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is Qtopia much faster?
On Wed, 23 Jul 2008 07:36:06 +1000 Lorn Potter <[EMAIL PROTECTED]> babbled: > > i guess i just don't lik the idea of a thin vertical stack where at each > > layer 1 choice has been made for me and i'm stuck with it, like it or not, > > or i move to a whole different stack. eg - must use qt, or must use gtk, or > > must use efl. allow the choice to be made at the latest stage - not the > > earliest. i prefer the idea of an ecosystem where all these toolkits and > > mechanisms get along and co-habitate. jungle vs ivory tower guess... i'm a > > jungle kinda guy! :) anyone want a banana? :) > > I guess you have to define your target audience. The small niche linux hacker > group or the larger general phone community that requires a consistent look > and feel. Perhaps a good read of the Human Interface Design Principles at > apple might do some good. in that case, maybe we should all have given up - trolltech included, and simply have used windows and visual studio - so we have a consistent os, programming environment, ui toolkit etc. why should there be any variety or choice - i mean... qt is a waste of time competing because it's different to everything else. variety is a fact of life. UNLIKE other platforms we get the chance to support all of the variety - at once easily. other platforms force you into their idea of toolkit, like it or no. at least i dont have to reboot just to run another app using another toolkit... > > sure, but any non-qt app.. will be a behemoth to port. you either: > > just as any non- > Like porting a qtopia app to gpe. or a windows app to linux. are you going to > include win32 or S60 port because they have _way_ more applications written > for them. and so from that point of view - qtopia would be a loser as it has many fewer apps written for it than general X11. :) > > 1. do a whole port of the app to qt/qtopia (work work work!) > > (not to mention now that this basically means you pay nokia a license fee, > > or your app must be GPL, can't be mit-x11, bsd, APL, MPL etc.). > > You want to charge people money for your commercial app? so why is it bad for > Trolltech ^H^H^H^H^H^H^H^H^H Nokia to do the same? > GPL ensures that the code and software remains free. Besides, the Neo is > touted as a "Free your phone" phone. Why would you want to install non free > apps on it? I could just as easily use any Nokia phone in existence. i never mentioned commercial apps nor money. your idea of open is not mine - or the next person along's. i prefer the open of mit-x11/bsd, not GPL. all are free, open and cost $0, but GPL places more restrictions. > Actually you are free to license the code you write in any way you want. It > just has to be compatible with the license you link it to. No one is stopping > you from writing your code in multiple licenses anyway. if i want to write a library and license it with a less restrictive, yet still open license, it BECOMES GPL - for all purposes GPL will virally impose itself. this is not the case if i use gtk, sdl, efl etc., but is the case with qt. it then would be my choice, as a developer of open, and free software, to choose a toolkit that doesn't limit my own freedom to license as i please. remember i never talked about charging for software or it being closed. :) -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
I have not had time to test any. But I could. M steve wrote: > Michael do you have any phones that fail GPS test? > > -Original Message- > From: Michael Shiloh [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2008 10:10 PM > To: steve > Cc: 'Joerg Reisenweber'; community@lists.openmoko.org; 'C R McClenaghan'; > [EMAIL PROTECTED]; Andy Green > Subject: Re: GTA02 GPS rework for SD card interference issue > > ave ceasar! > > steve wrote: >> Then I am Rome. >> >> The SOP needs to be reviewed. Basically, I will need to hear from >> jOERG, Werner, >> Micheal, Andy. >> >> I would like to have micheal test the SOP. >> >> Then I can figure out how to offer the repair. >> >> >> 1. Give people a free repair kit? >> 2. work with distributors to do repair. >> 3. Host repair PARTIES! Woo hoo. Bring your own soldering iron. >> BYOSI >> >> >> >> -Original Message- >> From: Michael Shiloh [mailto:[EMAIL PROTECTED] >> Sent: Monday, July 21, 2008 11:18 AM >> To: Joerg Reisenweber >> Cc: community@lists.openmoko.org; steve; C R McClenaghan; >> [EMAIL PROTECTED] >> Subject: Re: GTA02 GPS rework for SD card interference issue >> >> ...and Michael goes to Steve, so all roads lead to Steve. >> >> Expect a reply from Steve very shortly (if he hasn't already done so). >> >> Michael >> >> Joerg Reisenweber wrote: >>> This should go to Steve and Michael, I guess >>> >>> >>> Am Fr 18. Juli 2008 schrieb C R McClenaghan: Tony, Will OpenMoko offer this repair to Freerunner owners? How and under what terms? Chris On Jul 18, 2008, at 2:28 AM, Neng-Yu Tu (Tony Tu) wrote: > Dear Community: > > For GTA02 SD card interference GPS issue, our hardware team provide > a hardware fix/workaround for this coexistence bug. Sorry post it > late, because we have to make sure this fix works and don't have > side effects. > > Here is the fix: > > http://www.openmoko.org/wiki/Image:Gta02_gps_10pf_rework_sop.pdf > > This fix could give almost same performance with SD card out of case. > > But this work still not suggest do by yourself, also, this fix need > proper size capacitor (10 pf with 0402 package), and some solder > technique. > > We saw people ask about service issues of Openmoko devices, and we > are working on it. Our sales discussing with our distributor about > proper services model, but do not have consensus yet, I will keep > update >> it. > Thanks, > > Tony Tu > > Openmoko, Inc. > > Support > > ___ > 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: GTA02 GPS rework for SD card interference issue
Michael do you have any phones that fail GPS test? -Original Message- From: Michael Shiloh [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2008 10:10 PM To: steve Cc: 'Joerg Reisenweber'; community@lists.openmoko.org; 'C R McClenaghan'; [EMAIL PROTECTED]; Andy Green Subject: Re: GTA02 GPS rework for SD card interference issue ave ceasar! steve wrote: > Then I am Rome. > > The SOP needs to be reviewed. Basically, I will need to hear from > jOERG, Werner, > Micheal, Andy. > > I would like to have micheal test the SOP. > > Then I can figure out how to offer the repair. > > > 1. Give people a free repair kit? > 2. work with distributors to do repair. > 3. Host repair PARTIES! Woo hoo. Bring your own soldering iron. > BYOSI > > > > -Original Message- > From: Michael Shiloh [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2008 11:18 AM > To: Joerg Reisenweber > Cc: community@lists.openmoko.org; steve; C R McClenaghan; > [EMAIL PROTECTED] > Subject: Re: GTA02 GPS rework for SD card interference issue > > ...and Michael goes to Steve, so all roads lead to Steve. > > Expect a reply from Steve very shortly (if he hasn't already done so). > > Michael > > Joerg Reisenweber wrote: >> This should go to Steve and Michael, I guess >> >> >> Am Fr 18. Juli 2008 schrieb C R McClenaghan: >>> Tony, >>> >>> Will OpenMoko offer this repair to Freerunner owners? How and under >>> what terms? >>> >>> Chris >>> >>> On Jul 18, 2008, at 2:28 AM, Neng-Yu Tu (Tony Tu) wrote: >>> Dear Community: For GTA02 SD card interference GPS issue, our hardware team provide a hardware fix/workaround for this coexistence bug. Sorry post it late, because we have to make sure this fix works and don't have side effects. Here is the fix: http://www.openmoko.org/wiki/Image:Gta02_gps_10pf_rework_sop.pdf This fix could give almost same performance with SD card out of case. But this work still not suggest do by yourself, also, this fix need proper size capacitor (10 pf with 0402 package), and some solder technique. We saw people ask about service issues of Openmoko devices, and we are working on it. Our sales discussing with our distributor about proper services model, but do not have consensus yet, I will keep update > it. Thanks, Tony Tu Openmoko, Inc. Support ___ 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: Operation without battery (GTA02)
Andy Green wrote: > Jeffrey, if you are interested about what the battery experiences, there > are a bunch of goodies from the Coulomb Counter in the battery > accessible down /sys/class/power_supply/bat, just cat them. These tell > you the battery's view of what is going on directly. > > # cat /sys/class/power_supply/bat/current_now > > is particularly interesting, this is the flow of current out of (+ve) or > into (-ve) the battery in uA. These values come fresh from the Coulomb > Counter each time, but that device itself updates its registers only > every few seconds. Is there a Wiki page or docs that explain what each register is and the units it refers to? especially in the .../power_supply/bat/... area which seems to have very pertinent information. Do the values appearing in the /sys/classes/... files differ anyway from what the hardware provides or is it tweaked by the kernel? Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeBSD / dfu-util
> Which FreeBSD version and arch (i386? amd64?) 6.3-STABLE for i386 - I've tried on two machines. My home machine is 7.0 -- I'll have to try it when I'm home. > Did you just follow the OS X procedure, or something else? Actually I followed the Linux instructions and then noticed I got the same errors as OS/X so used that little patch. If anyone's curious, yes I'm running as rood, and yes usbdevs shows the device, and...yes it works with USB networking. I'll let you know how 7.0 goes, thanks Torfinn. Best Regards, Ben Cadieux ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeBSD / dfu-util
Hello, On Tue, Jul 22, 2008 at 7:37 PM, Ben Cadieux <[EMAIL PROTECTED]> wrote: > Hi Everyone, > > I got dfu-util to compile using the OSX patch for endian.h & byteswap.h. Which FreeBSD version and arch (i386? amd64?) Did you just follow the OS X procedure, or something else? > developers of something unrelated to be ported to FBSD...is there > anyone that would like to take a crack at this? Well I could help out with testing and bug-finding at least. i have both amd64 and i386 FreeBSD machines. They normally run FreeBSD 7.0-stable, but can also run FreeBSD 6.3-stable if needed. Ideally, I would like to be able to run both dfu-util and the Openmoko development environment under FreeBSD. Just because it sjuold be possible. :-) HTH -- Regards, Torfinn Ingolfsen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is Qtopia much faster?
Carsten Haitzler (The Rasterman) wrote: > On Tue, 22 Jul 2008 10:38:35 +1000 Lorn Potter <[EMAIL PROTECTED]> babbled: > >>> Well, a almost desktop compliant x11 system with a wide variety of >>> frameworks, libs and programming languages. >> It will be hard to achieve a consistent look and feel across all these >> toolkits. Not to mention inter process communication. > > dbus. common look and feel - as long as there is choice and variety, this > won't > happen. wouldn't we love it if everyone drove a blue ford falcon.it's be so > uniform. parts would be easy to find ad everyone drove the same car. spray > painters would have such an easy time - they only need to stock blue paint! :) > > in the end - we are humans. variety *IS* part of life. without it our lives > would be dull and boring. different toolkits, different looks, different > feels, > different applications, languages, hell... different devices... are here to > stay :) > > i guess i just don't lik the idea of a thin vertical stack where at each layer > 1 choice has been made for me and i'm stuck with it, like it or not, or i move > to a whole different stack. eg - must use qt, or must use gtk, or must use > efl. > allow the choice to be made at the latest stage - not the earliest. i prefer > the idea of an ecosystem where all these toolkits and mechanisms get along and > co-habitate. jungle vs ivory tower guess... i'm a jungle kinda guy! :) anyone > want a banana? :) I guess you have to define your target audience. The small niche linux hacker group or the larger general phone community that requires a consistent look and feel. Perhaps a good read of the Human Interface Design Principles at apple might do some good. > >>> You can not port your garden variety x11 app to qtopia. Which you can >>> (almost) do with the other frameworks. >> Any Qt app can be 'ported' easily. Just as with gtk, or efl, or >> pick-your-toolkit for any library that is on the device. >> So yes, you _can_ port your garden variety app to Qtopia. It just needs to be >> written with one common toolkit - Qt. > > sure, but any non-qt app.. will be a behemoth to port. you either: just as any non- Like porting a qtopia app to gpe. or a windows app to linux. are you going to include win32 or S60 port because they have _way_ more applications written for them. > > 1. do a whole port of the app to qt/qtopia (work work work!) > (not to mention now that this basically means you pay nokia a license fee, > or your app must be GPL, can't be mit-x11, bsd, APL, MPL etc.). You want to charge people money for your commercial app? so why is it bad for Trolltech ^H^H^H^H^H^H^H^H^H Nokia to do the same? GPL ensures that the code and software remains free. Besides, the Neo is touted as a "Free your phone" phone. Why would you want to install non free apps on it? I could just as easily use any Nokia phone in existence. Actually you are free to license the code you write in any way you want. It just has to be compatible with the license you link it to. No one is stopping you from writing your code in multiple licenses anyway. > 2. you port the toolkit (port gtk, efl, etc. etc.) to qtopia (and this also > then follows the above license issue), which when done once at least covers > all > users of that toolkit, but which is no small feat > 3. you write an xserver for qtopia/qws! (the server itself will be GPL or you > have to pay nokia), but you avoid license issues... and now anything that uses > x11 should work... > > but the above all require work... a signficant amount of it. > -- Lorn 'ljp' Potter Software Engineer, Systems Group, Trolltech, a Nokia company ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Qtopia] roaming - manual selection not working
not so easy to try since at home I do not have access to roaming network...
but when I try to select manual search mode (while yet connected) from
the Network selection menu, which fails, log shows :
AT+COPS=1,2,0
+CME ERROR: 3
so it looks like the AT+COPS=1,2,0 is wrong : last number should have
been provider number (20810)
I was able from console to do a successful AT+COPS=1,1,"SFR" (and I
think also AT+COPS=1,2,"20810")
(when connected to roaming network,I thought I had seen failed log of
AT+COPS=1,2,20810 but I will have try again tomorrow)
On Tue, Jul 15, 2008 at 09:09, Cédric Berger <[EMAIL PROTECTED]> wrote:
> Hi,
>
> My freerunner connects to my operator with no problems (SFR, france),
> and when I am in switzerland (geneva) and loose the signal, it
> automatically switches to another (swisscom... roaming costs so much
> more expensive for me...). That's fine with automatic mode.
>
> But I cannot force it into manual mode (once it has switched, even
> though the SFR signal is back -and even if it is stronger than
> swisscom's-, it won't try to go back to SFR).
> Even rebooting, it stays on the same network.
>
> When I try in the settings-Call Networks to "Select operator", it
> fails ("Failed to register to the selected network operator").
> Same error when I just try to switch mode from Automatic to Manual, on
> either of these 2 networks.
>
> Any idea ? Does this work for some people ?
>
> I guess I should try in console with AT commands...
>
> (I could only force switch back by putting my SIM in my old phone,
> switching network, and SIM back into freerunner ! )
>
>
>
> Oh I can see there is a new qtopia version today (I have the one
> published just before). I do not know if I had this "startup crash"...
> But twice, when I had qtopia blocked, it happened that I could not
> boot again (kernel booted, but then boot stopped and waited). I boot
> from microSD.
> First time I reflashed a new version.
> Second time I was able to unlock... not really sure how, but may be
> that was because I could boot on the original OS and ran a e2fsk on
> the microSD partition with the rootfs of qtopia (formatted in ext3).
> filesystem maybe was corrupted...
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
On Wed, July 23, 2008 1:42 am, Alexey Feldgendler wrote: > On Tue, 22 Jul 2008 17:34:58 +0200, Andy Green <[EMAIL PROTECTED]> wrote: > >> I guess you're not a kernel coder... not only is the segment for these >> definitively zero at start of kernel, but it is an offence against >> ./scripts/checkpatch.pl to explicitly zero these things. > > It's strange to have a script that enforces a worse practice, even when > you really can assume that the segment is zeroed. > "worse" is subjective. int foo = 0; will put foo in the "initialised data" section with a value of 0. int foo; will put foo in the "uninitialised data" section which is guaranteed to be initialised to zero when the kernel is loaded. The former adds 4 bytes to the size of vmlinux. 4 bytes isn't much, but if there are hundreds of these, it is just a waste of space. If it really offends you, use int foo /* = 0 */; but that isn't really necessary. It wont take long before you start reading int foo; in global context as "foo is initialised to 0". NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is Qtopia much faster?
I just played with Qt Jambi the Trolltech Java UI SDK for Java. It looks good, but will it work under Qtopia? Or only under Qt/X11? I have Jalimo loaded on the FR and of course non of the graphics libs they provide work because they are GTK/X11, so what does it take to use Java to write an app under Qtopia. (For me if I can't do that it is a show stopper for me using Qtopia) I either need Java or Ruby to write to the screen. I presume some people will want python too. There are Qt bindings for Ruby but I think they are Qt/X11 not Qtopia. Any suggestions? Thanks Jim Lorn Potter wrote: > Tilman Baumann wrote: >> And not using x11 is probably a very sane step, if you can live >> without the portability factor. (That's porting other apps) > > There is no portability factor. Only which toolkit is available. > > As one of our engineers here said on our internal discussion (and goes > back to rasters comment): > > "One of the neat advantages of Qtopia on Qt for Embedded Linux is that > there is little penalty in converting back and forth between a QImage > and QPixmap so we have used this extensively which makes quite a few > things much easier and more possible than if things are based on X11 > where these conversions are expensive and you then need to put a bit > more thought in to it. " > > > -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Hi, I'm one of the GSoC students and work on the answering machine. I already use this concept in my project and it uses modules so it might be possible to extend it to fit your needs. It's implemented in vala so you can use all GLib functionality and more. As far as you can create vala bindings for it or you can use C and GObject. I just implemented 2 types of connecting rules yet: all of them or one of them. Also a complex type might be possible. my current rules are: -time ( depending on day of week and current time) -calendar ( depending on your entries in you calendar ) -GPS ( depending on a GPS position and a radius around this ) my current actions are: - run a custom command on startup and at the end - answer call: yes it is an answering machine - answer asterisk call: this should also be answered - send sms: send a user defined message to a caller Here you can find the class diagram [1]. it will be updated soon. Regards, Frederik [1]: http://v1187.ncsrv.de/classes.jpeg ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: debugging pppd
OK, found it myself. A different syslog.conf helps. Michael Michael Kluge schrieb: > Hi, > > has anyone experience debugging pppd profiles? I have a profile > (attached) for the German provider "simyo" (eplus reseller). The chat > script "/etc/ppp/simyo-connect-chat" suceeds and I get the message > "Serial connection established". pppd itself is started with 'debug' and > 'nodetach'. After the "Serial connection ..." message the script gets > stuck without any error message :( If I stop it with Ctrl-C the pppd > process is somehow still present in the backgound. No clue why, it > should stay attached, right? > > Any hints how to debug this stuff is highly appreciated :) > > > > Michael > > > /etc/ppp/peers/simyo > --8<---8<-- > > /dev/ttySAC0 > 115200 > connect /etc/ppp/simyo-connect-chat > crtscts > lock > hide-password > defaultroute > usepeerdns > disconnect /etc/ppp/simyo-disconnect-chat > holdoff 3 > ipcp-accept-local > ipcp-accept-remote > noauth > nomagic > noipdefault > novj > novjccomp > replacedefaultroute > lcp-echo-interval 3 > lcp-echo-failure 12 > user "eplus" > > ___ > 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: Clock Configuration Question
That would be a feature of the openmoko-clock package. As far as I know, there are no configuration options for that app. -Steven On Tue, Jul 22, 2008 at 11:31 AM, reaper527 <[EMAIL PROTECTED]> wrote: > > I have my clock configured to the proper date/time, however I was hoping to > set it up as a 12 hour (am/pm) clock instead of the 24 hour (military time) > clock it uses by default. > > Does anyone know how to set this up? I did a google search on the date > command, but it didn't seem to take pm in the time parameter like the search > suggested. > -- > View this message in context: > http://n2.nabble.com/Clock-Configuration-Question-tp576928p576928.html > Sent from the Openmoko Community mailing list archive at Nabble.com. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problems with building openmoko-sample with toolchain
Thanks, I'm going to try this. But I just don't understand, I'd think having a working toolchain would be a high priority. -Stephen On Tue, Jul 22, 2008 at 4:06 AM, Andreas Dalsgaard < [EMAIL PROTECTED]> wrote: > 2008/7/22 Dylan Reilly <[EMAIL PROTECTED]>: > >> Haven't been able to get the patch to work, I had to modify it to use > the > >> right paths, but then all hunks fail still. > > > >> Why isn't the toolchain in a working state? How is anyone doing > development? > >> I've been playing around with it but I still can't get the sample > project to > >> compile. > > > > I am also having difficulties. I made a valiant effort to replace all > > the erroneous > > references in all the .la files in > > /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/lib > > but that sort of thing rarely goes well when one is not familiar with > > the system. > > > > Are there any tool chains available with correct references, a fixed > patch for > > the current one, or etc.? I have some ideas I really want to start > hacking out. > > > > I have been working on an Ubuntu package of the toolchain. I'm > currently testing it but if anyone want to help out take a look at: > > http://andreasdalsgaard.blogspot.com/2008/07/openmoko-development-in-5-minutes.html > > At the moment the package fixes the .la problem with an "evil hack" > that make the compilation process use an alternative libtool script. > Actually I would like to have ./configure pick up the LIBTOOL > enviroment variable instead but I have not figured that part out yet, > however I believe this might require another autoconf package. > > > -- > > Dylan Maxwell Reilly > > > > ___ > > 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
syslog.conf
Hi, could someone please give me a pointer to the structure of the /etc/syslog.conf? It looks neither like a normal syslog.conf (http://linux.about.com/od/commands/l/blcmdl5_syslogc.htm) nor like the syslog-ng I am used to. Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
debugging pppd
Hi, has anyone experience debugging pppd profiles? I have a profile (attached) for the German provider "simyo" (eplus reseller). The chat script "/etc/ppp/simyo-connect-chat" suceeds and I get the message "Serial connection established". pppd itself is started with 'debug' and 'nodetach'. After the "Serial connection ..." message the script gets stuck without any error message :( If I stop it with Ctrl-C the pppd process is somehow still present in the backgound. No clue why, it should stay attached, right? Any hints how to debug this stuff is highly appreciated :) Michael /etc/ppp/peers/simyo --8<---8<-- /dev/ttySAC0 115200 connect /etc/ppp/simyo-connect-chat crtscts lock hide-password defaultroute usepeerdns disconnect /etc/ppp/simyo-disconnect-chat holdoff 3 ipcp-accept-local ipcp-accept-remote noauth nomagic noipdefault novj novjccomp replacedefaultroute lcp-echo-interval 3 lcp-echo-failure 12 user "eplus" ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeBSD / dfu-util
> it might be a stupid comment, but have you booted the freerunner in NOR? > Yes, I held AUX while turning on, got the boot menu with [NOR] next to it and booted up. I assume everything went okay. I wasn't expecting to be back in the GUI and using the phone as usual, but that's how it is. Best Regards, Ben Cadieux ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
> I'm really quite surprised it managed to ship in this condition, when > the fix is fundamentally a hardware one. yikes. i think your record is broken ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
On Wed, Jul 16, 2008 at 9:01 AM, Edward A. Falk <[EMAIL PROTECTED]> wrote: > You do NOT get tech support like this anywhere else. Those of you > pounding your virtual fists on the table and demanding a fix *right now* > are out of line. The OpenMoko team is obviously working on it; give > them a little time. Nevertheless the fact that this problem existed, was identified months ago by early testers, and it took this long to find the root cause. I'm really quite surprised it managed to ship in this condition, when the fix is fundamentally a hardware one. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Import contacts qtopia
Holger Freyther wrote: > On Monday 21 July 2008 22:07:30 Kalle Happonen wrote: > > >> Hmm I didn't get this to work. I didn't have a terminal on the phone, so >> I ran it with X forwarding, i.e. the windows opened on my laptop. I >> think I would have gotten them imported (vCard version 2.1, not 3 for >> some reason), but I found no way of confirmin the "Would you like to >> import" dialog. I didn't find a way to tell addressbook to autoimport, >> the documentation is a bit skimpy.. >> > > well, Qtopia has this concept of a soft menu... So far only the software on > the neo knows how to treat the properties set on the Qtopia windows to show > the buttons. > So set DISPLAY=:0, show the addressbook on the screen of the neo, get a > softmenu and click the buttons there.. > > z. > Ah thanks, I feel like an idiot, I could have come up with the DISPLAY idea myself. Well luckily there seems to be sharper brains out here. :) Kalle ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How can I solve the TS Calibration in Landscape mode?
Hi Alexander, This issue is in the bug tracker: http://docs.openmoko.org/trac/ticket/1244 Though, I'm not sure if there has been any progress towards a fix yet. Looks like Tony Tu is possibly working on it? (it is assigned to him) -Hans On Tue, Jul 22, 2008 at 12:46 PM, Alexander Syring <[EMAIL PROTECTED]> wrote: > Hi > How can I solve the TS Calibration in Landscape mode? > > I've tested ts_calibrate in landscape mode but the screen goes to portrait > mode to calibrate. > > regards > Alex > > ___ > 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: Reason for GPS problems found!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | This is now starting to look great! I seem to be unable to get the Wah it's good to hear! | It would be nice to know whether the S/N ratio is about as good with | the software fix as it's without SD card - it might not be, it might | be. If I get into situation that I can't get signal or it takes very | long to get a fix, it's easy to wonder whether the situation could be | even better... Halting SD_CLK is the best behaviour for this of all, at that time the cap doesn't bring anything aditionally measurable to the party. That'll be the case when you're not actively doing something with SD Card now. When you are spamming SD Card tomorrow's kernel changes the default drive power for those lines to the lowest. Energy then at 1.5GHz from that is 6dBm more than background level under those conditions, I guess the cap will reduce it 1 or 2 dBm extra but it's already under the level it seems to make any difference to GPS. Combined with the fact we stop the clock altogether normally I don't think the cap rework is needed... if these positive reports keep coming anyway. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiGIfsACgkQOjLpvpq7dMqwhQCgknGK/8KK6Hz69zuRpP8uu6LA BAMAniHqEaH/wqGHkiLJk29/nwErKrfP =0BAb -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeBSD / dfu-util
I've tracked down a little more. In main.c, in the function list_dfu_interfaces(void) around line ~310...The USB tree is being walked, and 4 devices are detected (root hubs?). However, the for(dev = usb_bus->devices;.) loop never executes. dev = usb_bus -> devices doesn't seem to return anything ever. I've been poking around usbdevs.c, a FreeBSD command that returns USB hubs and their devices, to see what's being done differently, but haven't gotten anywhere so far. Best Regards, Ben Cadieux ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeBSD / dfu-util
it might be a stupid comment, but have you booted the freerunner in NOR? On Tue, Jul 22, 2008 at 7:45 PM, Ben Cadieux <[EMAIL PROTECTED]> wrote: > I notice some comments in there with regards to FBSD, so maybe it does > work and I'm screwing something up :) > > > > On Tue, Jul 22, 2008 at 10:37 AM, Ben Cadieux <[EMAIL PROTECTED]> wrote: >> Hi Everyone, >> >> I got dfu-util to compile using the OSX patch for endian.h & byteswap.h. >> >> Unfortunately, -l lists no USB devices. I've tried using the --device >> parameter, but that doesn't seem to help --- dfu-util sticks to its >> guns that there are no DFU compatible devices. >> >> I'm going to be setting up a FBSD box at some point to give some >> developers of something unrelated to be ported to FBSD...is there >> anyone that would like to take a crack at this? >> >> Best Regards, >> Ben Cadieux >> > > ___ > 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: Reason for GPS problems found!
2008/7/20 Andy Green <[EMAIL PROTECTED]>: > Thanks for this report, I went and looked and found I didn't take care > of the case where last packet transferred was not a bulk read packet: > that what happens on resume. I added a patch to stable branch that > should be out tomorrow hopefully and give the same SD_CLK performance > with or without resumes. This is now starting to look great! I seem to be unable to get the device into mode where it wouldn't be getting any fixes - suspend, idle, power off, agps ui, switching GPS on and off, after everything it's still ready for GPS action. So, huge thanks for finding the glitch so that the GPS is now finally really usable even without hardware fix! It would be nice to know whether the S/N ratio is about as good with the software fix as it's without SD card - it might not be, it might be. If I get into situation that I can't get signal or it takes very long to get a fix, it's easy to wonder whether the situation could be even better... Anyway, next step for me personally would be more to find out what's wrong with GPRS functionality via which I could get the agps data to speed up GPS even more. -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Import contacts qtopia
On Monday 21 July 2008 22:07:30 Kalle Happonen wrote: > Hmm I didn't get this to work. I didn't have a terminal on the phone, so > I ran it with X forwarding, i.e. the windows opened on my laptop. I > think I would have gotten them imported (vCard version 2.1, not 3 for > some reason), but I found no way of confirmin the "Would you like to > import" dialog. I didn't find a way to tell addressbook to autoimport, > the documentation is a bit skimpy.. well, Qtopia has this concept of a soft menu... So far only the software on the neo knows how to treat the properties set on the Qtopia windows to show the buttons. So set DISPLAY=:0, show the addressbook on the screen of the neo, get a softmenu and click the buttons there.. z. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
How can I solve the TS Calibration in Landscape mode?
Hi How can I solve the TS Calibration in Landscape mode? I've tested ts_calibrate in landscape mode but the screen goes to portrait mode to calibrate. regards Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeBSD / dfu-util
I notice some comments in there with regards to FBSD, so maybe it does work and I'm screwing something up :) On Tue, Jul 22, 2008 at 10:37 AM, Ben Cadieux <[EMAIL PROTECTED]> wrote: > Hi Everyone, > > I got dfu-util to compile using the OSX patch for endian.h & byteswap.h. > > Unfortunately, -l lists no USB devices. I've tried using the --device > parameter, but that doesn't seem to help --- dfu-util sticks to its > guns that there are no DFU compatible devices. > > I'm going to be setting up a FBSD box at some point to give some > developers of something unrelated to be ported to FBSD...is there > anyone that would like to take a crack at this? > > Best Regards, > Ben Cadieux > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
FreeBSD / dfu-util
Hi Everyone, I got dfu-util to compile using the OSX patch for endian.h & byteswap.h. Unfortunately, -l lists no USB devices. I've tried using the --device parameter, but that doesn't seem to help --- dfu-util sticks to its guns that there are no DFU compatible devices. I'm going to be setting up a FBSD box at some point to give some developers of something unrelated to be ported to FBSD...is there anyone that would like to take a crack at this? Best Regards, Ben Cadieux ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Clock Configuration Question
I have my clock configured to the proper date/time, however I was hoping to set it up as a 12 hour (am/pm) clock instead of the 24 hour (military time) clock it uses by default. Does anyone know how to set this up? I did a google search on the date command, but it didn't seem to take pm in the time parameter like the search suggested. -- View this message in context: http://n2.nabble.com/Clock-Configuration-Question-tp576928p576928.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: have anyone changed his ringtone ?
> pulseaudiot nice freudian slip ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: have anyone changed his ringtone ?
for sure... I didn't experiment with sizes much but my attempt of 3M in size led pulse to explicitely state that it is too big: just run that pulse from cmdline, without -D and log-level=2 should be sufficient. You would need to restart X so dialer reconnects to pulseaudio also there seems to be a flaw in the logic (or communication with pulseaudiot) of the dialer, so if you place lengthy ringtone, you will get multiple copies of it playing with a delay from each other ;-) On Tue, 22 Jul 2008, Zitune wrote: >in fact it's a size problem ... -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dfu-util: line 1: syntax error: "(" unexpected
Ooops! I thought it was used on the FR! Thanks.
Best Regards,
Ben Cadieux
On Tue, Jul 22, 2008 at 7:53 AM, xiangfu <[EMAIL PROTECTED]> wrote:
> Ben Cadieux wrote:
>> Hi Everyone,
>>
>> Got my FR yesterday. Neat device so far :)
>>
>> I followed the instructions for reflashing, dfu-util gives this when I
>> execute it:
>> dfu-util: line 1: syntax error: "(" unexpected
>>
>> I'm having trouble updating it though. I've wget'ted it more than
>> once and checked the md5;
>>
>> [EMAIL PROTECTED]:~# md5sum /usr/bin/dfu-util
>> 84f0bd60bef2450e57bda627254faf3a /usr/bin/dfu-util
>>
> i thank you use dfu-util at FreeRunner, don't do that.
> the dfu-util is use at HOST, not at FreeRunner
>> I'm not sure if that's right or not. I searched the lists but I seem
>> to be the only one with this issue, if not I'm sorry for not being
>> able to locate other e-mails.
>>
>> Best Regards,
>> Ben Cadieux
>>
>> ___
>> 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: Reason for GPS problems found! / more patches
On Tue, 22 Jul 2008 17:34:58 +0200, Andy Green <[EMAIL PROTECTED]> wrote: > I guess you're not a kernel coder... not only is the segment for these > definitively zero at start of kernel, but it is an offence against > ./scripts/checkpatch.pl to explicitly zero these things. It's strange to have a script that enforces a worse practice, even when you really can assume that the segment is zeroed. -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
ti, 2008-07-22 kello 17:01 +0200, Alexey Feldgendler kirjoitti: > On Tue, 22 Jul 2008 16:25:45 +0200, Andy Green <[EMAIL PROTECTED]> wrote: > > static int sd_drive; > > This doesn't seem like zero initialization to me. Static is initialized to zero. But indeed, I too noticed this from the patch, and would make it explicit to be more clear. (Shan't bother to check if the C standard actually allows it to be merely zeroed bits but nonzero when interpreted as an int...) -- Mikko Rauhala - [EMAIL PROTECTED] - http://www.iki.fi/mjr/> Transhumanist - WTA member - http://www.transhumanism.org/> Singularitarian - SIAI supporter - http://www.singinst.org/> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | On Tue, 22 Jul 2008 16:25:45 +0200, Andy Green <[EMAIL PROTECTED]> wrote: | |> http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=66a83c97c4545ce4f07e0d90998f906fae49caf2 | |> static int sd_drive; | | This doesn't seem like zero initialization to me. I guess you're not a kernel coder... not only is the segment for these definitively zero at start of kernel, but it is an offence against ./scripts/checkpatch.pl to explicitly zero these things. I often forget that and zero them anyway because I like to see it, but most times I remember to run checkpatch and have to go back and "fix" myself... - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiF/iIACgkQOjLpvpq7dMq6ZACgjRipRwzoKXDeLsP1mrBYQP1F sOsAn2dTjbwPDVwcx5LopCGwHp4oRVT0 =WiHe -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SD Card
>> afair the latest uboots allow ext3, too, of what use a journal ever >> might >> be with an sd card. > > No fsck. An 8G SD with lots of little files would take a while to fsck > after a crash. sounds sensible, indeed. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS software fix, just CRUFT?
Scott Derrick schrieb: > IE. do they add anything useful? > > Scott > i think turning off an clock that isn't needed, is always a good thing. power saving rules. ... greenpeace-energy rules (just in germany as far as i know)... :) ... o yeah and OM rules ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SD Card
On Tue, Jul 22, 2008 at 7:36 AM, arne anka <[EMAIL PROTECTED]> wrote: >> on a related note, what is the best way to format an sd card for use in >> the freerunner? > > fat, ext2. > afair the latest uboots allow ext3, too, of what use a journal ever might > be with an sd card. No fsck. An 8G SD with lots of little files would take a while to fsck after a crash. It would be interesting to get a number though, maybe it's not as bad as I imagine. I'll add it to my upcoming SD tests. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS software fix, just CRUFT?
Scott Derrick wrote: > With the GPS hardware fix done(10pf cap installed) are the software > changes to the kernel/modules just added cruft? IE. do they add > anything useful? I believe you'll get less power consumption from the SD controller due to it idling properly now. Mike. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GPS software fix, just CRUFT?
With the GPS hardware fix done(10pf cap installed) are the software changes to the kernel/modules just added cruft? IE. do they add anything useful? Scott ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
On Tue, 22 Jul 2008 16:25:45 +0200, Andy Green <[EMAIL PROTECTED]> wrote: > http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=66a83c97c4545ce4f07e0d90998f906fae49caf2 > static int sd_drive; This doesn't seem like zero initialization to me. -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
Use an ESD safe soldering iron also. Preferably one you can set tip temperature, though with a quick hand thats not necessary. Scott Yaroslav Halchenko wrote: > doh me -- I meant to ask about soldering iron primarily. So which gun > would you recommend (so it feels comfortable in hand, is not too long, > doesn't heat the handle more than the tip ;-) etc) > > On Tue, 22 Jul 2008, Sander van Grieken wrote: > >>> could anyone recommend a nice solder for such kind of work? (haven't >>> bothered to buy one in the states... in ukraine at the university was >>> using whatever was given ;-)) > >> You will need 'flux core solder' (normal 'resin' electronics solder), with a >> low wattage >> soldering iron, like 15W. It also helps to apply the solder to all contacts >> first, >> before putting the capacitor in place. > >> Sander > > > > > >> ___ >> 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: dfu-util: line 1: syntax error: "(" unexpected
Ben Cadieux wrote:
> Hi Everyone,
>
> Got my FR yesterday. Neat device so far :)
>
> I followed the instructions for reflashing, dfu-util gives this when I
> execute it:
> dfu-util: line 1: syntax error: "(" unexpected
>
> I'm having trouble updating it though. I've wget'ted it more than
> once and checked the md5;
>
> [EMAIL PROTECTED]:~# md5sum /usr/bin/dfu-util
> 84f0bd60bef2450e57bda627254faf3a /usr/bin/dfu-util
>
i thank you use dfu-util at FreeRunner, don't do that.
the dfu-util is use at HOST, not at FreeRunner
> I'm not sure if that's right or not. I searched the lists but I seem
> to be the only one with this issue, if not I'm sorry for not being
> able to locate other e-mails.
>
> Best Regards,
> Ben Cadieux
>
> ___
> 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: SD Card
Peter Abplanalp wrote: > hi, > > i am seeing a lot of things on the list about sd cards and that they > interfere with the gps and that call clarity is worse when using an sd > card. i know that the gps issue has been addressed with a patch. will this > patch also address the call clarity issue? also, do i get the patch if i > install a daily build or do i need to build it all myself via the moko > makfile? > > on a related note, what is the best way to format an sd card for use in the > freerunner? > > format in freerunner :-) --umount /dev/mmcblk0p1 --mkfs.ext3 /dev/mmcblk0p1 --mount /dev/mmcblk0p1 > thanks, > > > > > ___ > 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 GPS rework for SD card interference issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | doh me -- I meant to ask about soldering iron primarily. So which gun | would you recommend (so it feels comfortable in hand, is not too long, | doesn't heat the handle more than the tip ;-) etc) Dunno about the soldering iron, but if you never soldered 0402 before you will certainly need to invest in some solder braid so you can recover easily from any errors. And don't breathe heavily on it :-) I would definitely put this off until I tried tomorrow's kernel, it may well remove the need for it. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiF8voACgkQOjLpvpq7dMp6zACfV8nq+GG769N6EUD9p1cy0bVb AFQAn3gMBBmDF4ff4n7W11FrBJPyYE/t =6gG6 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
doh me -- I meant to ask about soldering iron primarily. So which gun would you recommend (so it feels comfortable in hand, is not too long, doesn't heat the handle more than the tip ;-) etc) On Tue, 22 Jul 2008, Sander van Grieken wrote: > > could anyone recommend a nice solder for such kind of work? (haven't > > bothered to buy one in the states... in ukraine at the university was > > using whatever was given ;-)) > You will need 'flux core solder' (normal 'resin' electronics solder), with a > low wattage > soldering iron, like 15W. It also helps to apply the solder to all contacts > first, > before putting the capacitor in place. > Sander > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dfu-util: line 1: syntax error: "(" unexpected
> [EMAIL PROTECTED]:~# md5sum /usr/bin/dfu-util > 84f0bd60bef2450e57bda627254faf3a /usr/bin/dfu-util where did you get it from and on what platform are you using it? i got mine from the debian repositories and it works well -- so, other linux distributions might have it, too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SD Card
> patch also address the call clarity issue? also, do i get the patch if i as far as i remember there were one or to post which _thought_ it possible that the sd card _might_ influence call clarity. but there was and is no evidence for that idea. > install a daily build or do i need to build it all myself via the moko > makfile? nope. the patches are in the kernels upgradable by opkg. only if you can't wait or parch your own kernel you need to build. > on a related note, what is the best way to format an sd card for use in > the > freerunner? fat, ext2. afair the latest uboots allow ext3, too, of what use a journal ever might be with an sd card. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Hi Andy, | Can you do your voodoo so that this will install from opkg upgrade? That's someone else's voodoo, but it is the intention that it'll just turn up in packages after 24hrs or less. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiF7msACgkQOjLpvpq7dMruqACglQXUFWZibexvsQoMeapvFWkB rKwAni8O+4Rhu1g76FLCCjaj5LAOcqXj =+IOf -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
dfu-util: line 1: syntax error: "(" unexpected
Hi Everyone,
Got my FR yesterday. Neat device so far :)
I followed the instructions for reflashing, dfu-util gives this when I
execute it:
dfu-util: line 1: syntax error: "(" unexpected
I'm having trouble updating it though. I've wget'ted it more than
once and checked the md5;
[EMAIL PROTECTED]:~# md5sum /usr/bin/dfu-util
84f0bd60bef2450e57bda627254faf3a /usr/bin/dfu-util
I'm not sure if that's right or not. I searched the lists but I seem
to be the only one with this issue, if not I'm sorry for not being
able to locate other e-mails.
Best Regards,
Ben Cadieux
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | So you mean the patch allowing to change the drive strength for SD, | not the latest patch you committed about 2 hours ago which set default | strength to 0 ? Yes, the now older patch introduced the /sys things. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiF7jAACgkQOjLpvpq7dMow0QCfeykm0Z81BdgVY5zOfIachLs6 vhAAoIKFrtLbtUA8s2XQsiaCxsn/X0j5 =2ifJ -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | I know it is difficult to quantify this but it would be nice to know | that say the clock current drive decrease by itself improved the SN | ratio by say 6dB, the capacitor mod by itself improved the SN by say | 3dB, and combined the change was 6dB. If this was the case just the | software mod would be necessary. If on the other hand the combined | change was 9dB then both would be worthwhile. There are some numbers here: http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=66a83c97c4545ce4f07e0d90998f906fae49caf2 - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiF7ekACgkQOjLpvpq7dMrO1QCffFC9Yi13p++StrjrrfhYLcZd 3c8AoJIXpKWvb/qsxTCQOpi3mg+blXcG =ccYU -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
Hi Andy, Can you do your voodoo so that this will install from opkg upgrade? Thanks, Vinc Duran user On Tue, Jul 22, 2008 at 6:01 AM, Andy Green <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Somebody in the thread at some point said: > |> So the fact you were OK at drive level 0 should mean are able to use > |> SD > |> card how you like without problems from SD_CLK to GPS any more. > | > | > | If at all possible, can someone who understands this explain it so we > | developers can add the hack/patch to our running Freerunners and > | continue development unimpeded by this issue any longer? Or do we > | just have to wait until the next image update or something? > > I will change the default drive strength to 0 today, tomorrow's kernel > should "just work". The SD Card we ship anyway seems to work fine like > that. > > - -Andy > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkiFy/0ACgkQOjLpvpq7dMrCLQCfU0laYPbSmWELTc0JDkuekmNj > T6wAoIBoNn+lpWWYD16KMYC9f3YevB/U > =llOW > -END PGP SIGNATURE- > > ___ > 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
SD Card
hi, i am seeing a lot of things on the list about sd cards and that they interfere with the gps and that call clarity is worse when using an sd card. i know that the gps issue has been addressed with a patch. will this patch also address the call clarity issue? also, do i get the patch if i install a daily build or do i need to build it all myself via the moko makfile? on a related note, what is the best way to format an sd card for use in the freerunner? thanks, -- Peter Abplanalp ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launching apps in ASU
On Tue, 22 Jul 2008 12:56:52 +0200 Sven Klomp <[EMAIL PROTECTED]> babbled: > On Tuesday 22 July 2008 11:46:40 Marcel wrote: > > Am Dienstag 22 Juli 2008 08:39:20 schrieb Kalle Happonen: > > > Hello, > > > I just flashed to ASU (again, it's fun to play around :) ). I installed > > > the vte terminal with opkg, and it installed nicely. Now I wonder how I > > > can add it to the launcher, or how I can launch it at all? I can > > > ofcourse do it with X forwarding over ssh, but that kind of misses the > > > whole point :). If I'm not completely mistaken, the settings are in a > > > sqlite database, and even if I do like fiddling, I wondered if there > > > would be an easier way than playing with sqlite. > > > > Simply add a new .desktop file for it to /usr/share/applications. :) > > But you have to select the right Category (e.g. Games) since Illume shows > only a few categories in the launcher. I don't know what categories that are. actually not illume's code - its /etc/xdg/meuns/applications.menu that defines what to show. standard XDG menu stuff. same as your desktop linux distro. -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Terminal for ASU
Carsten Haitzler (The Rasterman) wrote: > On Tue, 22 Jul 2008 02:39:01 +0100 JW <[EMAIL PROTECTED]> babbled: > > >>> Where are the design documents which say "no keyboard toggle button >>> should be included", please? If one wishes to contribute code or >>> patches to ASU then I guess it's necessary to know this, or one will >>> find patches rejected because they don't meet this design specification? >>> >>> >> surely this is a prime candidate for a motion detection / gesture detection >> to bring up the keyboard >> >> easy - no extra button needed >> >> geeks who enable their gesture of choice get the keyboard when they want it >> >> carsten can you build in the sleeping gesture as you go? >> > > what gesture, where? how? how ill this be able to not conflict with operation > of other apps? i am not so hot on gestures - especially ones that use up the > "whole screen" or parts o the screen where apps run - as now gestures fight > for > usability with apps themselves. there is no coordination. example: > > if the gesture was "slide up the screen from bottom to top" - how is this > gesture different from me dragging my finger to scroll a list in the > application > on my screen? how do i make sure only ONE of these happens (the keyboard pops > up > OR the scroll happens) and not both? > I'm not sure, but I think he meant gesture as in accelerometer. Double tap the phone for instance, or tap it on the bottom and it slides up, and tap it on the top and it slides down... or... Kalle ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is Qtopia much faster?
On Tue, 22 Jul 2008 10:38:35 +1000 Lorn Potter <[EMAIL PROTECTED]> babbled: > > Well, a almost desktop compliant x11 system with a wide variety of > > frameworks, libs and programming languages. > > It will be hard to achieve a consistent look and feel across all these > toolkits. Not to mention inter process communication. dbus. common look and feel - as long as there is choice and variety, this won't happen. wouldn't we love it if everyone drove a blue ford falcon.it's be so uniform. parts would be easy to find ad everyone drove the same car. spray painters would have such an easy time - they only need to stock blue paint! :) in the end - we are humans. variety *IS* part of life. without it our lives would be dull and boring. different toolkits, different looks, different feels, different applications, languages, hell... different devices... are here to stay :) i guess i just don't lik the idea of a thin vertical stack where at each layer 1 choice has been made for me and i'm stuck with it, like it or not, or i move to a whole different stack. eg - must use qt, or must use gtk, or must use efl. allow the choice to be made at the latest stage - not the earliest. i prefer the idea of an ecosystem where all these toolkits and mechanisms get along and co-habitate. jungle vs ivory tower guess... i'm a jungle kinda guy! :) anyone want a banana? :) > > You can not port your garden variety x11 app to qtopia. Which you can > > (almost) do with the other frameworks. > > Any Qt app can be 'ported' easily. Just as with gtk, or efl, or > pick-your-toolkit for any library that is on the device. > So yes, you _can_ port your garden variety app to Qtopia. It just needs to be > written with one common toolkit - Qt. sure, but any non-qt app.. will be a behemoth to port. you either: 1. do a whole port of the app to qt/qtopia (work work work!) (not to mention now that this basically means you pay nokia a license fee, or your app must be GPL, can't be mit-x11, bsd, APL, MPL etc.). 2. you port the toolkit (port gtk, efl, etc. etc.) to qtopia (and this also then follows the above license issue), which when done once at least covers all users of that toolkit, but which is no small feat 3. you write an xserver for qtopia/qws! (the server itself will be GPL or you have to pay nokia), but you avoid license issues... and now anything that uses x11 should work... but the above all require work... a signficant amount of it. -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why is Qtopia much faster?
On Tue, 22 Jul 2008 19:10:27 +1000 Lorn Potter <[EMAIL PROTECTED]> babbled: > Tilman Baumann wrote: > > And not using x11 is probably a very sane step, if you can live > > without the portability factor. (That's porting other apps) > > There is no portability factor. Only which toolkit is available. > > As one of our engineers here said on our internal discussion (and goes > back to rasters comment): > > "One of the neat advantages of Qtopia on Qt for Embedded Linux is that > there is little penalty in converting back and forth between a QImage > and QPixmap so we have used this extensively which makes quite a few > things much easier and more possible than if things are based on X11 > where these conversions are expensive and you then need to put a bit > more thought in to it. " yup. for qws your conversions are cheap/almost free, but in x11 - not so. it probably is a matter of working with the x11 port of qtopia or changing the assumption that such conversions are cheap/free (eg never even using pixmaps - do everything software-rendered in client-space virtual framebuffers, as this is exactly what happens with qtopia on qws with a dumb fb anyway). this will never allow seamless acceleration and gfx-chip side functions doing as much work as they can, but will probably function about as well as qtopia with qws natively on a freerunner. so indeed - you are right. you made an ASSUMPTION of qws and these things being cheap conversions - though that may not be the case for some accelerated back ends for qws... but anyway - it can be improved.many options as to how to do it. x11 itself is not really a performance bottlneck - it is just the way you use it that makes the difference between it being "a blocker for performance" and a "it doesnt matter". :) -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Terminal for ASU
On Tue, 22 Jul 2008 02:05:48 +0100 Stroller <[EMAIL PROTECTED]> babbled: > > On 21 Jul 2008, at 19:47, Carsten Haitzler (The Rasterman) wrote: > > ... > > the problem is the designers decided that ASU is not to have any > > manual > > keyboard toggle button because it will disturb the design and/or > > confuse users, > > so all apps and toolkits need modification to talk a "protocol" to > > bring up the > > keyboard on demand (no manual controls). that is why you need to do > > this. > > personally i think you need a manual control because, as such, many > > apps and > > toolkits will not be changed, or they will get it wrong and give > > you a keyboard > > when you don't want one, or decide not to give you one when you > > do... but > > that's not my call. > > Hi Carsten, > > Sorry to trouble you, but who are these designers, please? i'll let them speak up if they wish to be part of a debate on this. it's up to them. i am not one way or another here. not going to defend or dob-in. i have no vested interests one way or another. i have technical reasons why i think the move to remove any such manual control is a bad thing and have made them clear often enough. i am not going to get into it again. i am staying neutral - i have my professional opinions and personal ones, but my job is to implement what is designed by others to the best of my ability - if something is technically not possible or utterly infeasible - i can't do it, but removing a manual keyboard button is perfectly easy to do, and so it gets done. if i hadn't made it clear.. i am being neutral on this - i am simply stating the facts as they are. i am not wanting to beat anyone one over this. i am just stating facts. emotions and opinions thereafter are entirely those of people as they wish to express them - they were not intended or written here. just sticking to facts. > I think many of us would like to contribute to the ASU, seeing as > how it's the future of Openmoko, so this would appear to be a > limitation upon community contributions. as such we are paid by openmoko to do what we are told to do by the design department and that is what we then do. you in the community can go and do your own themes and patches and packages and do what u want. > Where are the design documents which say "no keyboard toggle button > should be included", please? If one wishes to contribute code or > patches to ASU then I guess it's necessary to know this, or one will > find patches rejected because they don't meet this design specification? well design documents are pretty thin on the ground. i was told so in email/irc directly to do this. i had a manual button there originally and was explicitly told to remove it. i argued that this was a bad move for many technical reasons (porting of apps such as SDL games that don't use gtk or qt that now all need modifications, i listed the apps it will break, the reasoning of not always wanting a virtual keyboard (ie an entry box may be focused, but you just want to READ the content, not edit) etc. etc.) but it was made entirely clear that the button had to go - arguments or not. as i remember the reasons being that "it cluttered the interface", was "confusing", "unnecessary" and that "all applications can be modified to talk the protocol anyway". or something to that effect. this was a while ago so i'm a little hazy on the reasons - but it was something like that. again - i'm neutral. i'm just a programmer. i just implement code. -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
Hi, So you mean the patch allowing to change the drive strength for SD, not the latest patch you committed about 2 hours ago which set default strength to 0 ? On Tue, Jul 22, 2008 at 14:41, Andy Green <[EMAIL PROTECTED]> wrote: > Somebody in the thread at some point said: > |> According to the filename, this uImage.bin has the patch in > |> > |> > http://buildhost.openmoko.org/daily/freerunner/200807/20080722/uImage-2.6.24+git23+1d04b142ffeaa15129f046751f1366b0f0614f47-r0-om-gta02.bin > | ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
I use "electronic silver solder", 62/36/2 62% tin, 36% lead, 2% silver 44 flux, dia 0.5mm made by Kester with all that lead maybe its not available in the EU? Kester makes a lead free equivalent. here's a lead free equivalent in a small package. http://www.shopatron.com/product/part_number=5831/135.0 Scott Yaroslav Halchenko wrote: > could anyone recommend a nice solder for such kind of work? (haven't > bothered to buy one in the states... in ukraine at the university was > using whatever was given ;-)) > > On Tue, 22 Jul 2008, Tim Schmidt wrote: > >> On Mon, Jul 21, 2008 at 8:35 PM, steve <[EMAIL PROTECTED]> wrote: >>> 1. Give people a free repair kit? >>> 2. work with distributors to do repair. >>> 3. Host repair PARTIES! Woo hoo. Bring your own soldering iron. BYOSI > >> Personally, a kit would work for me. I have fine pitch solder and a >> nice iron, but not enough SMT parts to have that cap on hand (or >> easily aquired). I suspect others might not be so lucky though. > >> --tim > >> ___ >> 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: Terminal for ASU
On Tue, 22 Jul 2008 02:39:01 +0100 JW <[EMAIL PROTECTED]> babbled: > > > > > > Where are the design documents which say "no keyboard toggle button > > should be included", please? If one wishes to contribute code or > > patches to ASU then I guess it's necessary to know this, or one will > > find patches rejected because they don't meet this design specification? > > > > surely this is a prime candidate for a motion detection / gesture detection > to bring up the keyboard > > easy - no extra button needed > > geeks who enable their gesture of choice get the keyboard when they want it > > carsten can you build in the sleeping gesture as you go? what gesture, where? how? how ill this be able to not conflict with operation of other apps? i am not so hot on gestures - especially ones that use up the "whole screen" or parts o the screen where apps run - as now gestures fight for usability with apps themselves. there is no coordination. example: if the gesture was "slide up the screen from bottom to top" - how is this gesture different from me dragging my finger to scroll a list in the application on my screen? how do i make sure only ONE of these happens (the keyboard pops up OR the scroll happens) and not both? IMHO - gestures are black magic box filled with cans of worms. i'd rather avoid them unless you can guarantee the flow of the user action and where it will go. it's not so simple. either way - there WAS a button.. it was in the top-left corner of the screen that was blank and unused anyway. it used up no extra screen space and was obvious to hit. it was by far the best option available so far. if you hack the illum theme (edje_decc illme.edj to decompile - edit the .edc and run build.sh to rebuild... copy it back in place). you can add the button back - if you can find it. -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Terminal for ASU
On Mon, 21 Jul 2008 23:21:22 +0100 Al Johnson <[EMAIL PROTECTED]> babbled: > On Monday 21 July 2008, Carsten Haitzler wrote: > > On Mon, 21 Jul 2008 22:32:47 +0100 Al Johnson > > <[EMAIL PROTECTED]> > > > > babbled: > > > On Monday 21 July 2008, Carsten Haitzler wrote: > > > > the problem is the designers decided that ASU is not to have any manual > > > > keyboard toggle button because it will disturb the design and/or > > > > confuse users, so all apps and toolkits need modification to talk a > > > > "protocol" to bring up the keyboard on demand (no manual controls). > > > > that is why you need to do this. personally i think you need a manual > > > > control because, as such, many apps and toolkits will not be changed, > > > > or they will get it wrong and give you a keyboard when you don't want > > > > one, or decide not to give you one when you do... but that's not my > > > > call. > > > > > > The designers' idea is great, but in practise I suspect you're right. > > > Please can we at least have a manual override as a configure option, even > > > if it's not on by default? > > > > sorry. "not in the design". it's not specified as a config option. i'm only > > doing what's in the spec as there is much unhappiness if i do otherwise. if > > you REALLY want the button you will have to hack the theme to put it back > > in (as its just a theme element that emits a signal when pressed). > > GRR...defective by design. You've made a fair summary of my feelings on > automated keyboards too. So what does the spec say about when there's another > input device like a bluetooth or USB keyboard? it says nothing... not specified as a design parameter. :) (another good reason for a manual overried until auto-detection of a bt/usb keyboard is flawless. even with a bt keyboard - it may be on, in your pocket or bag, but you may not want to use it.. thus want a manual "give me a virtual keyboard anyway - bt keyboard there or not". :) i'm with you on this and i understand why an automatic keyboard is goo d(no need to always manually bring it up when you'd want it anyway), but manual control is going to be needed for a long time to come as it may never always automatically do it right for you... :) > > yes automatic keyboard popup is good, but we don't live in a world where we > > can guarantee and force every app to behave perfectly. lots of things are > > "ported" (recompiled) and forcing them to add patches to bring up keyboards > > is just yet another barrier to porting and leaves us with less software :( > > > > even though automatic cars are ... automatic - they STILL have manual gears > > you can use - auto doesn't always get it right! :) 100% auto should only be > > considered once there is nothing left alive that ever could need a manual > > override. we are very far from that reality :( > > > > (as such the protocol used by matchbox keyboard/multi-tap is very error > > prone as anyone can send a message and the keyboard can be left in all > > sorts of erroneous states. the property-based one i implemented is reliable > > as the keyboard state desire is a property of the windows - thus the > > focused window's keyboard property determines if keyboard should be there > > or not, but this so far is a private protocol implemented by e. it is not > > documented, nor has it been standardised. all of this should go to > > freedesktop.org and be proposed as wm-spec extensions for "mobile devices" > > and then adopted, specified, and implemented everywhere, tested well, > > then.. when all this is done.. the manual button may have a chance of being > > removed...) > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
> > Surely the hardware and software 'fixes' can only be seen as a total fix > > if they make the SN (signal to noise ratio) of the GPS the same as if > > the SD card is not present. > > FWIW and IMAO, this definition of a "total fix" is impractical almost to > the point of uselessness. There will always be some noise in a tightly > packed product incorporating many high frequency sources. The question > is if the noise is significant (as it seems to have originally been). Sorry i don't think i have made myself clear. What i meant is that each of the modifications has been claimed to be a fix, when i would think they are only an improvement. What i am trying to get at is to find which of the modifications gives the best improvement. I know it is difficult to quantify this but it would be nice to know that say the clock current drive decrease by itself improved the SN ratio by say 6dB, the capacitor mod by itself improved the SN by say 3dB, and combined the change was 6dB. If this was the case just the software mod would be necessary. If on the other hand the combined change was 9dB then both would be worthwhile. > > Again, kudos to the team for a job well done on all fronts, sw and hw, > with regard to this issue. > I agree with this. I find it very impressive that they can get three radio transmitters, four radio receivers, high speed electronics and audio working in such a small package without more problems, and probably done on a shoestring budget as well. Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ruleby was: Rules based policy engine
Tilman Baumann wrote: > Scott wrote: > >> I just found this inference engine. >> >> http://ruleby.org/wiki/Ruleby >> >> I working on a Rails project think Ruby is a great language to work >> with. And Ruby is pretty small.. >> > > A bit too many layers there for my taste. :) > A domain specific rules language implemented in ruby embedded in c? > The ruby layer does not seem to be thin enough to justify that. > (ok, writing rules in ruby is kind cool. As would any other real > language be. Like lightweights like lua or certain lisp-ish languages. > Even javascript would not be bad.) > > Btw. I like the idea of a rules language. But why not something simple > and stupid like for example SIEVE filters in cyrus imap. > That's a hand full of yacc and lex magic and some stupid engine code. > I mean, what we can match is pretty much defined by the fact that we > match numbers and SMS. > A hand full of logic expressions on pre defined attributes should be enough. > My email filter is not smarter too, but email a lot more complicated. > And it works well. > > If someone puts the effort in to something like Prolog or Ruleby i will > not argue. But it seems a bit overkill to me. > > I agree with Rusty's idea (somewhere in this thread), if it's built as modules, the rules processing could be done by various efforts. Python, Ruby, Sieve, Prolog, Datalog, C; how fantastic that we have the chance (and choice) of any (all), including those we haven't thought of yet. Fertile times indeed! For some (me) the FR is a toy of sorts, something to explore. For others it's a tool, something to solve a problem with. I suspect it's partly an act of rebellion too. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
> could anyone recommend a nice solder for such kind of work? (haven't > bothered to buy one in the states... in ukraine at the university was > using whatever was given ;-)) You will need 'flux core solder' (normal 'resin' electronics solder), with a low wattage soldering iron, like 15W. It also helps to apply the solder to all contacts first, before putting the capacitor in place. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: order from Pulster
> The stock situation is getting much better now, we have a new > delivery on 15.08. and everybody who ordered a Freerunner will get > one. Thanks Chris! I got my order confirmation yesterday, with payment information and the 15.8 as delivery date, for the old price. Took some time but i'm happy now and looking forward to my freerunner :) daniel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
could anyone recommend a nice solder for such kind of work? (haven't bothered to buy one in the states... in ukraine at the university was using whatever was given ;-)) On Tue, 22 Jul 2008, Tim Schmidt wrote: > On Mon, Jul 21, 2008 at 8:35 PM, steve <[EMAIL PROTECTED]> wrote: > > 1. Give people a free repair kit? > > 2. work with distributors to do repair. > > 3. Host repair PARTIES! Woo hoo. Bring your own soldering iron. BYOSI > Personally, a kit would work for me. I have fine pitch solder and a > nice iron, but not enough SMT parts to have that cap on hand (or > easily aquired). I suspect others might not be so lucky though. > --tim > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: replaced ringtone but it plays it really funny way
nah... that is though the first thing I thought -- pulse is there to do resampling if needed. I think that my suspicion (said in my prev email to the thread) is the root -- dialer's logic is a big weaked and it doesn't really get idea either the sound has finished playing within its timeout of 500ms (or 1500ms), thus it manages to start 3 requests to play the same sound On Tue, 22 Jul 2008, Jay Vaughan wrote: > > after reboot it plays but incorrectly, it stutter, and even sounds > > like > > multiple instances playing simultaneously. So, I wonder what is the > > reason -- is that a feature or a bug > > RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo > > 44100 Hz > ^^^ sample rate is wrong. Pulseaudio is set up for 48khz. > ; -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
Hi On Tue, Jul 22, 2008 at 2:52 PM, arne anka <[EMAIL PROTECTED]> wrote: >>> btw: why can't these packages not simply have a date in the name, maybe >>> with a time, too? >>> >> >> These signify which git tree/revision is built. >> >> The date is in the folder names containing it. > > doesn't help with opkg -- from looking at the package's name you cannot > tell if your kernel is from today or two weeks old. [EMAIL PROTECTED]:~# cat /proc/version Tells you the build date, but in this case not the git revision > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Nick Loeve ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ruleby was: Rules based policy engine
Scott wrote: > I just found this inference engine. > > http://ruleby.org/wiki/Ruleby > > I working on a Rails project think Ruby is a great language to work > with. And Ruby is pretty small.. A bit too many layers there for my taste. :) A domain specific rules language implemented in ruby embedded in c? The ruby layer does not seem to be thin enough to justify that. (ok, writing rules in ruby is kind cool. As would any other real language be. Like lightweights like lua or certain lisp-ish languages. Even javascript would not be bad.) Btw. I like the idea of a rules language. But why not something simple and stupid like for example SIEVE filters in cyrus imap. That's a hand full of yacc and lex magic and some stupid engine code. I mean, what we can match is pretty much defined by the fact that we match numbers and SMS. A hand full of logic expressions on pre defined attributes should be enough. My email filter is not smarter too, but email a lot more complicated. And it works well. If someone puts the effort in to something like Prolog or Ruleby i will not argue. But it seems a bit overkill to me. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Ruleby was: Rules based policy engine
I just found this inference engine. http://ruleby.org/wiki/Ruleby I working on a Rails project think Ruby is a great language to work with. And Ruby is pretty small.. Scott signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: open phone dictionary
On Tuesday 22 July 2008, Robin Paulson wrote: > does anyone know of any sources of open phone dictionaries? http://www.dict.org could be of some help, or the openoffice dictionaries at http://wiki.services.openoffice.org/wiki/Dictionaries Cheers, Florian -- DI Florian Hackenberger [EMAIL PROTECTED] www.hackenberger.at ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
>> btw: why can't these packages not simply have a date in the name, maybe >> with a time, too? >> > > These signify which git tree/revision is built. > > The date is in the folder names containing it. doesn't help with opkg -- from looking at the package's name you cannot tell if your kernel is from today or two weeks old. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: wifi
On Sunday 20 July 2008, Charles Hill wrote:
> After two days of fighting with WPA2-PSK and getting nowhere, I figured
> something out.
>
> My WAP doesn't broadcast the SSID. Normally, this isn't a problem as I
> specify the SSID in the wpa_supplicant.conf file. But when I turned ON
> broadcast of SSID, I connected immediately and it even properly updated my
> resolv.conf file.
>
I used the following wpa_supplicant.conf and had no problems to connect
to a hidden SSID:
[EMAIL PROTECTED]:~# cat /etc/wpa_supplicant/wpa_supplicant.conf
# WPA-PSK/TKIP
ctrl_interface=/var/run/wpa_supplicant
ap_scan=2
network={
ssid="HIDDEN"
scan_ssid=0
proto=WPA
key_mgmt=WPA-PSK
pairwise=TKIP
group=TKIP
psk="what ever"
}
[EMAIL PROTECTED]:~#
wpa_supplicant -ieth0 -c/etc/wpa_supplicant/wpa_supplicant.conf -B ; ifup
eth0
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[SIOCSIWENCODEEXT]: Operation not supported
udhcpc (v1.11.1) started
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
Sending discover...
Sending discover...
Sending select for 192.168.1.9...
Lease of 192.168.1.9 obtained, lease time 268435455
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
adding dns 192.168.1.21
Dietmar Friede
PS.: The FR is really great. Good work!!!
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Caps for GTA02 GPS rework
I just bought ten, 10pf 0402 package ceramic caps from digikey. Part number 399-1011-1-ND. http://www.digikey.com They are 2.5 cents apiece, min order 10. With shipping they will probably be 50 cents apiece. Once I get them, For a buck I will send one to anybody where a 42 cent US stamp will reach. I only need two, so will have 8 extra. I should have them in hand in a few days, and will post again when they are here and I verify the 0402 package is the right one. Scott JW wrote: well from what Andy says they have found a software fix which - keeps good SD card perf (for cards tested so far) - doesn't degrade gps signal the software fix will be in the new kernel very soon and - switches off SD clock when not needed - reduces the drive strength of the SD signal when on so looks to me that the hardware kids can go ahead if they want to but not proved necessary right now... jw ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
Hi On Tue, Jul 22, 2008 at 2:29 PM, arne anka <[EMAIL PROTECTED]> wrote: >> According to the filename, this uImage.bin has the patch in >> >> http://buildhost.openmoko.org/daily/freerunner/200807/20080722/uImage-2.6.24+git23+1d04b142ffeaa15129f046751f1366b0f0614f47-r0-om-gta02.bin > > > how did you tell? by looking at the md5sum? Thats a SHA hash, which is what git uses as a 'revision' id > btw: why can't these packages not simply have a date in the name, maybe > with a time, too? > These signify which git tree/revision is built. The date is in the folder names containing it. > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > Cheers -- Nick Loeve ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: |> According to the filename, this uImage.bin has the patch in |> |> http://buildhost.openmoko.org/daily/freerunner/200807/20080722/uImage-2.6.24+git23+1d04b142ffeaa15129f046751f1366b0f0614f47-r0-om-gta02.bin | | | how did you tell? by looking at the md5sum? | btw: why can't these packages not simply have a date in the name, maybe | with a time, too? I think it's a SHA1-sum, but yes, this is the hash of the patch that was the HEAD of stable git when this was pulled from there and built. That hash is the hash of the patch that adds these /sys files. You can search for the commit hash here or just hover cursor and read URL: http://git.openmoko.org/?p=kernel.git;a=shortlog;h=stable - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiF1XsACgkQOjLpvpq7dMo1IACeNfXbGZPWBIMoP195I3M4gzfq SJUAniuOfD/6gYVUB26WDzvxzVT547pI =2ZGS -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
> According to the filename, this uImage.bin has the patch in > > http://buildhost.openmoko.org/daily/freerunner/200807/20080722/uImage-2.6.24+git23+1d04b142ffeaa15129f046751f1366b0f0614f47-r0-om-gta02.bin how did you tell? by looking at the md5sum? btw: why can't these packages not simply have a date in the name, maybe with a time, too? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Hey Andy, | will the patch be spread by opkg too? | I did some updates, but the sd_card file still does not appear. | | Anything I missed? According to the filename, this uImage.bin has the patch in http://buildhost.openmoko.org/daily/freerunner/200807/20080722/uImage-2.6.24+git23+1d04b142ffeaa15129f046751f1366b0f0614f47-r0-om-gta02.bin Likewise, this package http://buildhost.openmoko.org/daily-feed/om-gta02/kernel-image-2.6.24_2.6.24+git23+1d04b142ffeaa15129f046751f1366b0f0614f47-r0_om-gta02.ipk has the right hash in for having the patch too. If they still don't have the /sys thing, something 'orrible has happened somewhere. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiF0cEACgkQOjLpvpq7dMolXgCdEmeIz0qxkeZEZvAatsyCYAo7 tLUAoJB27QpRa3lMFo54Q/5lM8YAFFUc =3nXL -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS rework for SD card interference issue
well from what Andy says they have found a software fix which - keeps good SD card perf (for cards tested so far) - doesn't degrade gps signal the software fix will be in the new kernel very soon and - switches off SD clock when not needed - reduces the drive strength of the SD signal when on so looks to me that the hardware kids can go ahead if they want to but not proved necessary right now... jw ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
