Re: FOSDEM2016
I will be there on Sunday afternoon. Focussed in the SDN/NFV DevRoom, but would love to meet up. Neil Original Message From: Boudewijn Sent: Sunday, 24 January 2016 21:59 To: List for communicating with real GTA04 owners; List for Openmoko community discussion Reply To: List for Openmoko community discussion Subject: FOSDEM2016 Hi lists, Do any of you intend to visit Brussels for FOSDEM, next weekend? I have been terribly inactive, with hardly enough time to lurk the mailinglist, let alone participate in anything. This year I can make it to FOSDEM, it would be nice to meet if there's a chance to. Best regards, Boudewijn ___ 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: Some questions to new SHR images (ubifs, gps)
If you read the SHR wiki page[1] you will find a list of features. The ones with a red background are broken. GPS is broken and links to a ticket on the SHR bug tracker[2]. GPS not working after suspend is a known issue. If you have any insight into the bug (like "it stopped working when I upgraded from the x.y.z kernel to the to the2.6.32 kernel), please post it to that thread. Thanks, Neil Another who has the problem [1]: http://wiki.openmoko.org/wiki/SHR [2]: http://www.shr-project.org/trac/ticket/1085 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: State of FreeCalypso
A non-technical comment that you can take or leave - but it is my genuine response to your writings... I'm impressed by your dedication and detail, and I partly enjoy reading your updates; but I find it hard to forget the unacceptably violent threats that you've made in the past (on this list) towards particular people. I wonder if you might now consider retracting and apologising for those, and undertake not to repeat similar in future? Viva la humanidad! Neil Original Message From: Spacefalcon the Outlaw Sent: Saturday, 18 April 2015 07:29 To: community@lists.openmoko.org Reply To: List for Openmoko community discussion Subject: State of FreeCalypso Hello community, This periodic post is a summary of the goals of the FreeCalypso family of projects and the high-level status toward their achievement. Goals = The overall end goals of the project are, in no particular order: 1. Produce a standalone realization of Openmoko's modem. I have had occasion to work with various GSM modems and phones acting as modems (presenting an AT command interface) since A.D. 2000, and the modem in the Freerunner is by far the nicest I've ever touched. TI's implementation of the GSM specs is the richest in terms of functionality (contrast with the lack of CSD support in most 3G+ USB "stick" modems), and thanks to the Leonardo semi-src find, we now have full visibility into its inner workings. But it's a shame that this awesome GSM+GPRS modem is currently tucked away in the guts of the Freerunner, inaccessible to anyone besides the tiny handful of active FR owners/users - and even when one does have a Freerunner, it is not possible to take the FR's AP subsystem out of the picture and use the modem directly from an external host; one has to go through the AP instead, severely limiting the ability to use this modem outside of the FR. Hence I would like to build a modem just like Om's, but brought out on a board by itself, with external connections for power and the two UARTs. And throw in a quadband RFFE and a higher capacity flash+pSRAM chip while at it. 2. Produce a practically usable phone that runs practically free firmware, i.e., fw whose source every user is empowered to study and improve or otherwise modify. Note the emphasis on practical usability. I hear from FR owners that the practical usability of the FR as a phone is rather poor, and because there is absolutely nothing wrong with the modem (hw or fw), the defects in usability must be the result of some flaw(s) in the AP subsystem - a subsystem which from my PoV is nothing but unwanted complexity. And I would never be able to use my FR as a personal phone because it would require running something like QtMoko, and that stuff is far too complex for my old peasant mind. Free software which is far too complex for me to understand and work with comfortably is little different from proprietary sw from the purely practical standpoint - it's a impenetrable black box in practical terms. Therefore, the only way for me to have a practically usable phone that runs practically free firmware is to produce a non-smart phone, a plain phone with no AP subsystem. The long-term solution is to build my own handset hardware, but in the short term it would be OK to use not-quite-fitting but already existing hardware like Pirelli and Motorola phones. 3. Produce a FreeCalypso modem module that could be used in the place of off-the-shelf proprietary ones by free smartphone projects like Neo900. I would like to buy a couple of Neo900 units for two of my family members, but cannot do so for as long as the product includes a modem module from an immoral vendor who withholds source code and documentation and imposes restricted boot barriers to alternative firmware implementations. To the person who emailed me off-list and asked if I could design my FreeCalypso modem in the form factor matching Gemalto's so it could be a drop-in replacement: yes, I still like that idea very much and would like to do it, but I'm unsure whether I can manage such a task by myself, so we may need to work on it together. I also think that it would be easier if I prove my basic design first on a non-form-factor-constrained board, and then go through the form factor gymnastics as a second step. So the above 3 are the overall goals of the FreeCalypso family of projects. Out of those, goal 2 (practically usable non-smart phone running free fw) has been my main focus because it is the one that would improve my own quality of life: I am sick and tired of dealing with Pirelli's proprietary fw (I use a Pirelli DP-L10 as my personal daily phone, running its original proprietary fw as nothing better exists yet - better as in more free *and* practically usable), and I really, really, really want to replace it with my own free firmware. Firmware subproject === The firmware subproject of FreeCalypso is le
RE: Welcome to the Tinkerphones community
Agreed - I think the new name is exactly right. Neil -Original Message- From: community [mailto:community-boun...@lists.openmoko.org] On Behalf Of joerg Reisenweber Sent: 01 July 2016 08:12 To: community@lists.openmoko.org; OpenPhoenux Community Subject: Re: Welcome to the Tinkerphones community Congrats! This was overdue and the new name is absolutely to the point and has quite some appeal. The definition of what is / is not a tinkerphone is very helpful and should go to the frontpage at http://www.tinkerphones.org I like it very much. What about icons etc, generally the complete "corporate identity"? Has it been discussed what will change (beyond the obviously pending overhaul of http://www.tinkerphones.org artwork/design), and are there already tasks assigned to experts? Maybe even new logos etc established and available? Many thanks, Nikolaus - and whoever else been involved! :-) cheers jOERG On Fri 01 July 2016 08:29:39 H. Nikolaus Schaller wrote: > Hi, > after several years of running the OpenPhoenux community, we thought > that it is time to refresh it a little and replace the awkward name > "OpenPhoenux" (it was always difficult to spell and pronounce) with > something new, self-explaining, that your mom understands. > > "OpenPhoneux" was originally coined in ca. 2009 as the name of an > initiative, when it became clear that the Openmoko company would stop > to develop a successor of the Openmoko Freerunner. It finally brought > the GTA04 device to life. > > Back then, this was a motivating allusion to the situation of building > something new on the remains of Openmoko, but nowadays probably only > some core members of our community are able to understand this > background. > > Therefore we discussed in a small circle what the core of Openmoko and > Openphoenux is. > > It was easy to find what it is not: > * it is not a 100% fair phone (we don't have the resources to track > components - it is enough challenge to have it working and being > produced) > * it is not a 100% open phone (we have not found a feasible solution > for WLAN and GPU) > * it is not a 100% secure phone (we can't do security audits of every > component) > * it is not a cutting edge phone (we do not get the latest and greatest > chips as mainstream manufacturers do) > * it is not a geeks (only) phone (we want everybody to be able to use > it) > > But then we found what the common denominator of all Openmoko > activities was and is: > > It is a device that allows you to tinker with it, i.e. find out how it > works, to replace software and even hardware components for smaller or > bigger improvements and even repairs. It is designed in a way to > enable such changes instead of stopping you (e.g. by protected boot > loaders, undocumented code etc.). > > All this is facilitated by being open (as far as NDAs and other > limitations > allow) and using open source technology (e.g. GNU/Linux, Debian). > > Here is a definition of what "tinkering" is [1]: > > "tinker or tinker around to make small changes to something in order > to improve or repair it" "tinker with: He spends hours tinkering > around with car engines." > > So we are now happy to tell the world that we are members of "the > Tinkerphone community" :) > > There is a new web domain representing this change: > > <http://www.tinkerphones.org> > > I hope you will agree with us and stay here, contribute and share your > ideas and achievements. And invite new tinkerers to participate. > > Happy tinkering, > Nikolaus > > PS: it will need your help to update the documentation pages... > > [1]: <http://www.macmillandictionary.com/dictionary/british/tinker_1> > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- () ascii ribbon campaign /\ against html e-mail - against proprietary attachments http://www.georgedillon.com/web/html_email_is_evil.shtml http://www.nonhtmlmail.org/campaign.html http://www.georgedillon.com/web/html_email_is_evil_still.shtml http://www.gerstbach.at/2004/ascii/ (German) ___ 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: latest Openmoko/GTA04 tinkering: wireless charger
That is awesome! Original Message From: H. Nikolaus Schaller Sent: Saturday, 31 December 2016 16:39 To: Tinkerphones Community Reply To: List for Openmoko community discussion Cc: List for Openmoko community discussion Subject: latest Openmoko/GTA04 tinkering: wireless charger Hi, I spent some time to develop a Qi charger for the GTA01/02/04 devices and here its is: https://www.youtube.com/watch?v=LsSdDYHx7d4 Enjoy and happy new year, Nikolaus ___ 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: [Tinkerphones] Fwd: [Gta04-owner] QtMoko: a dream comes true :)
On 23/02/18 11:58, H. Nikolaus Schaller wrote: Am 23.02.2018 um 12:52 schrieb joerg Reisenweber : On Fri 23 February 2018 12:43:08 H. Nikolaus Schaller wrote: And the page http://git.goldelico.com/?p=gta04-qtmoko.git lists it in the "URL" section as g...@github.com:goldelico/gta04-qtmoko.git which is a verbatim quote and AIUI no correctly formed URL AFAIK git automatically adds a git: prefix if you say git clone g...@github.com:goldelico/gta04-qtmoko.git The git@ URL will only work for people who have write access to that repo. The https:// URL should work for everyone (for reading/cloning). Neil BR, Nikolaus ___ 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: [Debian][HOWTO] using bleeding edge FSO (Cornucopia aka vala rewrite)
On 6 May 2010 21:59, Paul Fertser wrote: > Hi, > > I like using Debian on my FR (in fact it is the only system i use as > my daily phone since i bought it) and i decided i want to start > getting all the great improvements and fixes from git again (as i used > to when framework was pure python). Thanks for writing this Howto. I don't know when I might get round to trying this out, but it's great to know that the guidance is there for when I need it. > I've also written an emacs > interface[1] to FSO (thanks to John Sullivan for inspiration), that's > the only UI i use now (will make an announcement later in another > letter). I'm looking forward to seeing this too! Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MeeGo and oFono
On 10 May 2010 14:23, Chuck Norris wrote: > People, what are you think about MeeGo/oFono on FreeRunner? Maybe > someone compiled it for FreeRunner? Or just is it interesting idea to > have meego/ofono for FR? The Neophysis distribution uses ofono. It has beautiful design, but I don't think it's ready for general use yet. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MeeGo and oFono
On 10 May 2010 14:31, Neil Jerram wrote: > On 10 May 2010 14:23, Chuck Norris wrote: >> People, what are you think about MeeGo/oFono on FreeRunner? Maybe >> someone compiled it for FreeRunner? Or just is it interesting idea to >> have meego/ofono for FR? > > The Neophysis distribution uses ofono. It has beautiful design, but I > don't think it's ready for general use yet. I'm sorry, I realize (on rereading) that this isn't very clear! What I mean is that _Neophysis_ has beautiful _visual_ design. I haven't looked at the code for Neophysis or ofono, so I can't comment on their technical design. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] No AUX button
On 1 May 2010 10:00, Neil Jerram wrote: > On 1 May 2010 00:42, Neil Jerram wrote: >> that the answer is probably: >> >> # buttons >> neo1973kbd >> >> And I guess I probably also want: >> >> # leds >> leds-neo1973-gta02 > > Just to confirm: Yes, those make my AUX button and LEDs work again. But now, after an aptitude upgrade yesterday (or the day before), AUX is not working again. I've checked that the modules noted above are still loaded. Any ideas? I think the upgrade included udev - could that be relevant? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
On Fri, 13 Aug 2010 11:22:02 +0200 "Dr. H. Nikolaus Schaller" wrote: > > Am 12.08.2010 um 14:12 schrieb RANJAN: > > > Hi, > > > > When is the next and more powerful openmoko (capable of seamless 3D video > > and faster processor) is going to be released??? > > Assume, you could get a motherboard upgrade board that fits into the > Freerunner (or Neo1973) case. Based on the TI OMAP3 SoC (OMAP3530 or DM3730) > and UMTS. > > Let me ask two questions to everybody: > * How long could you be willing to wait for it to really become available? > * How much would you think you could afford to pay for such a board? > Is there a serious possibility of this? I'm willing to wait a couple of years at least. And the 500 Euro number that people are throwing around seems OK. Would this be re-using the case, display and touch screen and replacing everything else? NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
On Fri, 13 Aug 2010 19:27:38 +0100 Ben Thompson wrote: > > To finance the next phase, we are thinking about asking for donations or to > > hold an auction for the first 5 or 10 prototype units. What would you think > > of such an approach? > > I'm not keen on either (although would consider a donation). What > about a pre-order? > I'm not keen on an auction as it tends to focus on getting large amounts money from few people - those many who have modest amounts of money get excluded. I'm not very keen of straight donations either as you really need a strong accountability structure before donations are at all safe, and I don't think you want to go that way. I like pre-order, but I wonder about combining them all... Choose a maximum subscription and a minimum price. Invite people to pre-order and pay the minimum price or greater as they choose. Only take orders up to the maximum subscription. As units become available, fill orders in order of the price paid starting with those who paid the most. Publish basic statistics about orders received so far and allow people to know their position. Also allow people to top-up their orders to climb the list. That way people can "donate" and are rewarded by getting a phone sooner - but everyone still gets a phone. The maximum subscription ensures that no-one will continually be over-taken by someone new paying a little bit more. An unfortunate quirk of this method is that those who pay the most - and get the first phone - may end up with a phone that is defective as some bug may not have been found yet. (obviously people pay postage plus minimum price plus extra). Just an thought.. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
On 16 December 2010 06:53, Timo Jyrinki wrote: > 2010/11/14 Timo Jyrinki : >> >> http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34 >> >> New Debian pkg-fso kernel available: > > And another one thanks to having inspirational time yesterday evening. Thanks. I am using this series of kernels, so I appreciate your work on them. > - X.Org eats all the CPU unless you disable AutoAddDevices or remove > extra /dev/input files Even after removing the /dev/input files as you suggested (in /etc/rc.local), my observation is that XOrg still eats all CPU after an initial boot-up, but that if I then do "/etc/init.d/nodm stop" and "/etc/init.d/nodm start", it returns to using a normal (small) amount of CPU. Is that as you would expect? > - Sys paths have changed, so you most probably want to add "om gsm > power 1" to /etc/rc.local (and install newest omhacks from pkg-fso if > you already haven't) I noticed that wifi is powered on after boot-up. Is that expected? Note that I am not currently running frameworkd or other FSO daemons - so perhaps this is normal, and I haven't seen it before because the FSO daemons turn wifi OFF when they start up. (Alternatively, could wicd be powering on the wifi?) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[debian] experimentation with ofono, telepathy-ring and empathy...
I thought this worth mentioning just in case others are doing similar things: I'm experimenting with the stack mentioned in the Subject, on my debian install, to see what kind of UI it gives, and how stable the telephony is. Current status is that - with a patch to enable udev autodetection of the calypso modem [1], ofonod starts up and detects the modem - the empathy UI's debug log (and also the "Previous Conversations" area) shows SMSs being successfully sent and received, but there's no indication of this in the main UI - I tried an incoming call, and again the debug log shows some trace of this, but there was nothing in the UI. [1] http://lists.ofono.org/pipermail/ofono/2010-December/006497.html Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[debian] howto: rebuilding sgt-puzzles for the FR
For people who like Simon Tatham's puzzle collection... On my SHR-T, for a long time I've used Frode Austvik's sgt-puzzles .ipk package. Compared to the standard Debian package, this .ipk for SHR is better because it has a couple of tweaks for "stylus-based" devices like the FR. (Specifically, it adds some extra buttons, and makes clicking somewhere twice, in some puzzles, equivalent to a right-click.) I've wondered about this for a while, and yesterday evening I finally realised that (a) the necessary code, i.e. Frode Austvik's patches, is all already in the Debian source package; and (b) it's quite easy to rebuild the package (on the FR) to enable it: # apt-get build-dep sgt-puzzles # apt-get source sgt-puzzles # cd sgt-puzzles-8853 # vi puzzles.h Comment out the "#ifdef _WIN32_WCE" and "#endif" around a group of defines for "Pocket PC devices", which are equally applicable to the FR. # debian/rules binary # dpkg -i ../sgt-puzzles_8853-3_armel.deb Now I can play Loopy as much in my Debian as in my SHR-T Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] howto: rebuilding sgt-puzzles for the FR
On 20 December 2010 23:25, EdorFaus wrote: > On 12/19/2010 06:29 PM, Timo Juhani Lindfors wrote: >> >> I meant a command line option that a user could pass so that he would >> not need to recompile.. > > Ah. That's... technically possible, I *think*, but would be quite a bit of > work for (IMHO) very little gain, as most people don't need access to both > variants on the same device, and if they do, that can be solved more easily > by having them both installed in seperate locations. I don't quite agree that the gain would be "very little". For me, though, it is not a priority to do this; the solution of rebuilding the package is good enough (especially with the "CFLAGS=... debian/rules binary" invocation) for the bottlenecks in my Debian usage to move elsewhere, and hence I'm now shifting focus to other things. > Really, for the FR (and similar devices), the better solution for what I > guess you're really after (ease of use for non-techies) would be to make > this the default in the binary package, or to provide an alternate binary > package with this configuration. I don't know, but I would guess that there may be armel devices on which the current standard build is just fine. So I'm not sure it would work for armel to imply switching on those #defines. Surely the optimal solution would be runtime auto-detection? Does udev provide sufficient information to infer that there is a touchscreen and no keyboard? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] howto: rebuilding sgt-puzzles for the FR
On 19 December 2010 14:28, EdorFaus wrote: > On 12/17/2010 12:08 AM, Neil Jerram wrote: >> >> For people who like Simon Tatham's puzzle collection... >> >> On my SHR-T, for a long time I've used Frode Austvik's sgt-puzzles > > Thank you! You just made me go back to look at this code again. Thank you for writing those patches! > When I first started doing this package, I fully intended to keep > maintaining it - but then several things conspired against it, which has > caused it to be unmaintained (by me at least) for a year now... That doesn't seem to have harmed anything. The .ipk always installs cleanly for me, and the code is upstream. > Actually, most of them have been included upstream, which is probably where > Debian got them from... Absolutely, yes, that's what I meant. Sorry for not being clear about it. > I've still got a couple left though... and made a new one just now... I > should probably try to push those upstream as well. That's interesting, what do they do? > CFLAGS="-D_WIN32_WCE" debian/rules binary Nice, much better than editing! For the record, have you actually tried this and checked it works, or is it just a suggestion? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] howto: rebuilding sgt-puzzles for the FR
On 21 December 2010 12:33, Timo Juhani Lindfors wrote: > Neil Jerram writes: >> Surely the optimal solution would be runtime auto-detection? Does >> udev provide sufficient information to infer that there is a >> touchscreen and no keyboard? > > udev does not know what X server your sgt-puzzles is connected > to. It's probably better to ask X about the input devices? Ah yes, of course, good point. So assuming the X API is rich enough to provide that information, I'd say that's the ideal solution. Of course it would also be possible to provide a command line option to override the auto-detection. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
On 17 December 2010 10:10, Al Johnson wrote: > On Friday 17 December 2010, Timo Jyrinki wrote: >> >> Anyway, if one can come up with a perfect xorg.conf that disables the >> extra devices there and only configures glamo + touch input + hw >> buttons, that'd be nice. What about the SHR xorg.conf? SHR is also using 2.6.34, so is there any reason why their xorg.conf - or at least the InputDevice and AutoAddDevices parts - would not be correct for Debian with 2.6.34? I've appended it below. Neil Section "Module" Load"glx" Load"dri2" EndSection Section "Monitor" Identifier "LCD Panel" EndSection Section "Device" Identifier "Glamo Graphics Chip" Driver "glamo" EndSection Section "Screen" Identifier "Default Screen" Device "Glamo Graphics Chip" Monitor "LCD Panel" EndSection Section "InputDevice" Identifier "Power Button" Driver "evdev" Option "Device""/dev/input/event0" EndSection Section "InputDevice" Identifier "AUX Button" Driver "evdev" Option "Device""/dev/input/event2" EndSection Section "InputDevice" Identifier "Touchscreen" Driver "tslib" Option "Device""/dev/input/event1" Option "EmulateRightButton""True" EndSection Section "ServerFlags" Option "AutoAddDevices" "False" EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "Power Button" InputDevice "AUX Button" InputDevice "Touchscreen" EndSection ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[UK] Experience with Vectone SIM?
I noticed today - http://www.vectonemobile.co.uk/ - what looks like an excellent PAYG deal for the Freerunner in the UK, because for £5 per month it means you can leave your GPRS on all the time, for random small bits of internet usage. I've sent off for one of their SIMs, but I wonder (1) if anyone else already has experience with them, and (2) if there is any existing support for tracking GPRS usage and alerting or disconnecting when it reaches a configured total. (I have no connection at all with this company, so apologies if this might sound like an advert. Also apologies if there are actually lots of similar offers like this already well known, and I've just failed to notice them before.) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ANN]: GTA04 (Beagleboard inspired Openmoko Upgrade) - Early Adpoter Program
On 21 December 2010 15:33, Dr. H. Nikolaus Schaller wrote: > -- early adopter program -- > > Therefore, we have thought hat we offer an early adoper > program to the benefit of everybody. > > The idea is that you can order a GTA04A3 immediately. [...] Fantastic stuff; I've placed an order. I understand that there are lots of caveats, and to be honest I'm not sure what they add up to, and what my expectations can reasonably be. But I can spare the money, and I think you and your team deserve support. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: faenqo
On 5 February 2011 18:06, Joif wrote: > > Hi cyberesprit! > You came here like the Spring! :D You made a really awesome theme! Now our > Freerunner seems really a brandnew smartphone :D I completely agree. This really is a beautiful look. Although I have nothing but admiration for the way that Radek and his contributors have been shepherding and improving QtMoko, I haven't actually tried it recently because I find the default look too dull. But your theme makes me feel like trying QtMoko again. Thanks! Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS and QtMoko (v32): can't
On 9 February 2011 17:54, Gennady Kupava wrote: > So, now one who want to archive stable GPRS should: > 3. manage rate on interface according to description in that PR. :) Is there a package containing tc for SHR? I don't have tc already installed on my SHR-T, and a few quick google attempts didn't turn up a package name. Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: bug: sd card not unmounting
On 9 March 2011 20:07, dmatthews.org wrote: > I think I should add to my own post to mention that I briefly tried the > January SHR testing a few weeks ago. That had the same problem ie (even) a > clean shutdown -> fsck reporting improper unmounting of the uSD. Interesting. Is there a way to check for the "filesystem was not unmounted cleanly" status without removing the uSD and taking it to another computer? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v33 - More battery info and questions
On 26 March 2011 09:54, Philip Rhoades wrote: > People, > > Using: > > echo bq27000-battery.0 > /sys/bus/platform/drivers/bq27000-battery/unbind > modprobe platform_battery > > allows me to check the value of: > > /sys/class/power_supply/battery/capacity > > and using: > > rmmod platform_battery > echo bq27000-battery.0 > /sys/bus/platform/drivers/bq27000-battery/bind > > restores the "smart" battery function. > > I attach a graph of the resulting discharge rate of the fully charged Nokia > BL-6C battery. > > Questions: > > - Even with the "dumb" battery configuration, the battery charging animated > icon continues after USB (power) disconnection - should that happen? > > - Using the methods above, both "bind" and "unbind" files exist in the > driver directory - shouldn't there be only one at any one time? I would guess not, because the ".0" at the end of bq27000-battery.0 suggests that there might be multiple battery instances, of which, at a given moment, some might be bound and others not. > If not, > don't the files only need to be created once instead of repeatedly each time > the scripts/aliases are run? Are you thinking that those echo commands create the files? I doubt it works like that; files in /sys and /proc are special, and it's more like echoing something into them causes some action to happen, or some config change. Cf. "echo 1 > /proc/sys/net/ipv4/ip_forward" to enable IP forwarding. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ROS on Freerunner
> Am 19.04.2011 um 09:46 schrieb Jan Tuennermann: > Right now I'm trying to get a gpsd_client node to run on the OpenMoko. On a > remote PC a gpsd_viewer node will run, subscribing gpsFix messages which it > will use to display the Moko's location in a map from the OpenStreetMap > project. Regarding the part of this problem that involves getting information out of GPS on the OpenMoko, so that it can be fed across to the viewer: note that this is very similar to using the OpenMoko as a GPS receiver and exporting that information to another device over Bluetooth. That is well understood and tested now, so if hit any difficulties in this area, please don't hesitate to come back to this list and ask. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: ROS on Freerunner
On 20 April 2011 10:12, Jan Tuennermann wrote: > Hi Neil, hi Boudewijn, > > thanks for the suggestions. I understand that there are probably more > usefull ways to get GPS info out of the Moko. Right now I'm trying it in the > context of creating a complete ROS integration, so that all the phone's > sensors will publish their information as ROS messages. Understood. All I meant was that if you have any difficulty getting at the basic GPS info (in order to publish it as ROS), we can help with that. > Did the GPRS connection prove reliable enough for this? In my experience, sadly no. I've regularly seen problems at all levels, including - GPRS connection doesn't come up (especially - but not only - if after terminating a previous connection) - connection comes up but routing table hasn't been updated so as to route over it - connection up and routing correct, but /etc/resolv.conf is wrong so DNS doesn't work - connection, routing and DNS all look good, but for some reason data still doesn't get anywhere (or come back). One known underlying problem here is that the modem crashes if the outgoing data rate is too high. But I imagine that that is relatively rare in practice, so probably there are other underlying problems. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: ROS on Freerunner
On 20 April 2011 10:47, Neil Jerram wrote: > On 20 April 2011 10:12, Jan Tuennermann >> Did the GPRS connection prove reliable enough for this? > > In my experience, sadly no. I've regularly seen problems at all > levels, including [...] I realized that that statement was overly negative. For balance, I should also say that I've sometimes had GPRS up and running successfully for whole days - e.g. for maps on long car trips. In summary, sometimes it works great, but I don't think you can completely rely on it. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] ANN: GTA04A2 engineering sample is now running Linux / will be shown at LinuxTag
On 20 April 2011 22:09, Dr. H. Nikolaus Schaller wrote: > Here is finally a brand new video showing the device in (battery!) operation: > [2] It looks really great, and fast too! Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
On 16 May 2011 17:02, Michael 'Mickey' Lauer wrote:
> NOTE: Cross-posted to three mailing lists, please keep it that way, if
> you want to reply.
If you can persuade them all to accept emails from non-subscribed
email addresses... (For weird historical reasons, I'm subscribed to
different lists with different addresses.)
> In the past, FSO has been too much developed without considering how the
> features will actually be used by the API consumers.
> Apart from the great work our friends from SHR did, there has only been
> a handful of special purpose FSO clients, such as
> the Emacs client, Zhone, and Zhone2. Zhone (and its successor Zhone2) is
> currently an oversimplified approach based on a
> non-maintainable Edje file. We have therefore decided to develop a new
> testing/demonstrator for FSO named Aurora that
> is supposed to be the driving force for further development.
I'm afraid I don't understand. Why not just have SHR as your
reference set of applications? If you don't think they are using the
FSO APIs in the pattern that you would recommend, presumably you could
work with them to correct that? Or, if they are missing applications
or features to showcase some of the latest FSO API features,
presumably you could help them to add those?
> At the top of every application stack is the user. Pleasing him or her
> is the topmost priority.
Speaking as a user, I would be pleased not to see more unnecessary
fragmentation of front-end efforts; also for the FSO2 middleware to be
rock-solid, with things fixed like RequestResource('bluetooth')
starting bluetoothd.
To be fair, it may be that FSO2 already is rock-solid now. I haven't
reviewed the situation recently, but I can't immediately think of any
known and clear issues, about from the bluetoothd one. But in that
case I'd still prefer focus on the SHR front end, over some new UI.
> Some words about the technology choices we have made for Aurora. The UI
> components of Aurora will be based on Qt's QML
> (Qt Markup Language) and will have parts written in C++ and Vala
> (although we're going to use Python for prototyping as well).
> We will support both Qt/X11 and Qt/Embedded, the latter being useful on
If you strongly favour Qt, you could take QtMoko as your reference set
of applications. That would be especially helpful right now, as Radek
is just looking at converting QtMoko to use FSO.
> Speaking about welcoming people, the major aim of this announcement is
> to find people who want to share this vision
> and give us a bit of a hand. We are especially lacking artists and folks
> who can improve our user interaction.
> Apart from the technical reasons, we chose QML to have a very low
> barrier of entry. QML is easy to understand
> and it also comes with a GUI design tool.
>
> If you are interested and share our vision, please feel free to contact
> us. We can then see how you could help us to get to the end goal (see
> roadmap) even faster.
I'm almost lost for words here. Starting from scratch seems so
obviously the wrong thing to do, when there are mature projects that
you could contribute to...
I must be misunderstanding what you mean - please do explain more!
Regards,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
Hi Simon, Many thanks for your explanations of Aurora. I think I understand now, at least as regards what you are trying to do, and why. I have just one further comment below. On 17 May 2011 06:57, Simon Busch wrote: > Aurora is not about fragmentation. Zhone was already there before SHR > and Aurora will continue Zhone. We will take aurora as our new reference > application as it is quite simple and let us integrate new features very > fast. One question, then, is how will Aurora be different from Zhone? Having worked a bit with Zhone myself, I'd say that - on the one hand, its code seems pretty accessible and easy to experiment with - but on the other hand, it feels relatively hard to add completely new features into the UI (possibly because of my own familiarity with the Edje/embryo stuff). Is that roughly your feeling too? If it is, how will you make Aurora better? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtmoko : typing text without stylus
Hi there... On 6 June 2011 17:01, Xavier Cremaschi wrote: > But currently I am still unable to use prediction :/ Just in case it is a cause for confusion - are you aware that the keyboard doesn't actually predict at all? Rather, it performs fuzzy matching of where you pressed against the possible letters around that point. (Whereas "predicting" would be something like offering me "understand" when I had only pressed near the letters "unders".) I wrote about this a while back: http://lists.openmoko.org/pipermail/community/2008-September/030442.html. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] GTA04A3 board boots
On 14 June 2011 21:03, Dr. H. Nikolaus Schaller wrote: > after another illness related delay and a public holiday in Germany, > we finally received the first two GTA04A3 boards populated in > "module configuration". [...] Today, both boards worked almost immediately, > started U-Boot and > the kernel on a RS232 interface (the bare board has no buttons nor > display). As far as we did test today, there are only software bugs (e.g. > preventing that the second 256 MB DRAM bank is enabled; and we still > have a software fix in the u-boot code for a hardware problem of > the A2 version which now is no longer needed). More lovely news - thanks as ever! Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] experimentation with ofono, telepathy-ring and empathy...
Hi Johannes, On 23 June 2011 12:24, Johannes Schauer wrote: > Hi, > > On Thu, Dec 16, 2010 at 01:53:59PM +0000, Neil Jerram wrote: >> I thought this worth mentioning just in case others are doing similar >> things: I'm experimenting with the stack mentioned in the Subject, on >> my debian install, to see what kind of UI it gives, and how stable the >> telephony is. > Can you elaborate on how you approached that issue so that others can > reproduce your findings? Unfortunately I no longer have the details to refer to. But as far as I recall, it was something like... - Install oFono. It was 0.36 at the time, and it looks like that's still the latest in Debian, even though I believe upstream has had several releases since that. - Start ofonod, then play with test scripts like `list-modems' and `enable-modem'. - Discover that nothing happens because calypso hasn't been detected. I wrote a patch to fix that, and sent it to the oFono guys. AFAIK that is in the upstream code now, so a more recent oFono release should detect calypso out of the box. - `list-modems' and `enable-modem' now work. - Install telepathy-ring and empathy, and see what happens - and I wrote about that earlier (but a long time ago) in this same thread. Does that help? Please feel free to ask more detailed questions, and I'll do my best! Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Freerunner and Wayland
Hi there,
Just wondering... is it at all feasible, in the nearish future, for
Wayland to run on the Freerunner? I mean directly on KMS, not as an X
client.
Would there be any advantage to that, compared to the current X usage?
I'm imagining it might perform better, but I don't really know.
Thanks,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner and Wayland
Hi Tom, Thanks for your answer... On 13 July 2011 10:01, Thomas White wrote: > acceleration pathways. A lot of the performance difficulties with the > X pathway (not just on our hardware) seem to be because the server > can't possibly know enough about what the client wants to accelerate it > effectively. Fast and smooth graphics on the Freerunner should be > perfectly possible, but would rely on exactly this kind of > "clairvoyance" from the X server. > > So, getting Wayland to run on its own shouldn't be too difficult > (famous last words..), but writing programs which can actually make use > of it is significantly more difficult. I have read that some toolkits, like Gtk+ and Cairo, have (or are in the process of having) support for Wayland as their backend directly (i.e. not via X). Also that it's possible to write clients using a GL API directly, and that the library providing that API would use Wayland directly. I guessed from that that the toolkit or GL implementation might be in a better position to have exactly that kind of clairvoyance - i.e. to know what kind of acceleration would be useful, and to ask the hardware driver for that. Hence, I thought, there might be some performance benefit in the acceleration-potential being in the toolkit or library, instead of in X; and also perhaps in just cutting out one of the layers. Also, I presume, I could write a new client today using e.g. the Cairo API, and that should Just Work. Is any of that correct? (Having said that, I don't recall reading yet of any Wayland support in the E toolkit, and certainly that would be a specific problem for SHR usage. But maybe Wayland is still worth experimenting with in a non-SHR setup.) Thanks again, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Writing my own Free Plain Phone sw distro for GTA02
On Sat, 17 Sep 2011 22:04:45 GMT, msoko...@ivan.harhan.org wrote:
weeks (intercontinental shipping and all). But the real purpose of
this
introductory post of mine is to announce what I plan to do with it:
my
desire is to write my own from-scratch Free Plain Phone software
distro
for it.
That's an interesting post and new project, and I think I understand
your motivation.
On the GSM front, however, you may want to consider the DeforaOS code
at http://www.defora.org/os/project/browse/3343?file=/src. It was also
written from scratch, in C, and to be minimal (compared to something
like FSO or oFono), and I think it may be small enough for you to feel
happy studying it instead of reimplementing it yourself.
Regards,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Sharing literki work
Hi there. I'm doing some incremental work with literki, and wanted to share that in case it's of interest to more than just me. I've pushed my changes (starting from the current Debian package) to gitorious at https://gitorious.org/stuff-for-openmoko-freerunner/literki-work. I've also uploaded a couple of screenshots at http://www.screenshots.cc/show/50482/akgaz and http://www.screenshots.cc/show/50483/1ecqm. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sharing literki work
On Mon, 17 Oct 2011 10:34:12 +0300, Timo Jyrinki wrote: Yes! I still found literki the most interesting keyboard around, Me too. Its code is nicely organised and easy to read and modify. I like the transparent overlay approach, and its target of being finger-usable, and the hide/show control by swiping. And the touchpad idea... My only reservation is that I've found it not to look very beautiful. Plus I'm interested at the moment in optimising for a landscape UI. Those are the motivations for my current work. which is why I packaged it in Debian (some patches at [1], probably not interesting if not the 03). I have those already, apart from 02, because I started from the Debian package. I've independently implemented something like 02. If only I could find out how to force it to stay on top on my setup so that I wouldn't need to restart it every time I switch a window and want to write something... (I have a button for that in my tihos program). Yes. My idea about that is that I'd like the Input Method (IM) system to tell a small server program (which is pretending to be an IM engine) when keyboard input is needed, and then that program could run literki and make sure that it is on top. Do you think that might work? I believe that ibus is the most modern and actively developed IM system, so I've installed that and am looking at its doc, but haven't got far yet with working out the detail of what would be needed. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sharing literki work
On Mon, 17 Oct 2011 09:55:36 +0200, Davide Scaini wrote:
Interesting!
d
Thanks. I've popped up another screenshot - but only showing a little
more incremental change - at http://www.screenshots.cc/show/50531/frk2a.
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Sharing literki work
On Mon, 17 Oct 2011 17:03:56 +0200, Michał Brzozowski wrote: On Mon, Oct 17, 2011 at 2:46 PM, Neil Jerram wrote: Me too. Its code is nicely organised and easy to read and modify. I like the transparent overlay approach, and its target of being finger-usable, and the hide/show control by swiping. And the touchpad idea... I'm glad to hear it! Hi Michał, thanks for commenting on this thread. What setup do you have? OpenBox at the moment; but I can change if something else is better. I used IceWM, and I remember hacking it to put windows with override_redirect bit on the top. You mean you had to change IceWM's code for this? That wouldn't surprise me, because I think override_redirect just means "don't decorate me and don't mess with my size or position". I don't think it normally implies being "always on top". That gives the user total control over hiding the keyboard. Some WMs seem to respect this bit, and it maybe can be considered a bug if the don't. I doubt it can be considered a bug. It seems to me that a WM needs to take specific action in order to implement "always on top" for a window, and the (normal) overall sense of override_redirect is more "WM, please just leave me alone". Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MCNavi 0.3.1 released
On 17.11.2011 18:56, Boudewijn wrote:
On Thursday 17 November 2011 17:36:14 Mike Crash wrote:
make current release not compatible. I'm working on coastlines
generation
and it seems to be a little complicated.
A bit of an open door, but didn't Mandelbrod find the same some 35
years ago? ;-)
And I was thinking of Slartibartfast
(http://en.wikipedia.org/wiki/Slartibartfast).
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Merry Christmas and a Happy New Year from the GTA04 project
elf Pavlik writes: > Thank You Nikolaus =) > > And big big big appreciation to all GTA04 contributors for the great work you > do!!! > > Happy Hacking... Very much +1 from me too. I know I've gone a bit quiet in the last few weeks, but GTA04 has been a fantastic ride so far, and I personally have lots more work that I'd like to do with and for it. Best wishes, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Community Survey 2011 – Results
Niels Heyvaert writes: > Why is AoF is not even mentioned in the distro list is a mystery to me. > > Believe we should pollute this list more often with pure AoF related topics to > keep reminding people it also exists ;-) Yes, please do! The community is small enough as it is; we don't need every tiny fragment to have a separate discussion forum. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] GTA04: gyroscope and compass drivers added/made working
"Dr. H. Nikolaus Schaller" writes: > Now we have all sensors working: Accelerometer, Barometer, Gyroscope, > Compass, Touch screen. And some of them even have a built-in thermometer. Can I just check: I don't believe my GTA04A3 has any of these sensors, because I didn't explicitly ask or pay for them. Is that right? (I guess it might be possible that some of them were included anyway.) Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New $200 tablet?
"Gay, John (GE Energy Services, Non-GE)" writes: > http://aseigo.blogspot.com/2012/01/reveal.html I hope it will be capable of running mainline kernels and any GNU/Linux ecosystem software, not just KDE. I think Plasma Active looks pretty nice and interesting, and look forward to being able to try it, but all the same I hope this tablet will not be in some way _tied_ to KDE, or to a system image that only the manufacturer can provide. (cf. Maemo.) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM 2012 - Presentation online
Niels Heyvaert writes: > The slides are also available online for download on the AoF project page. > > http://code.google.com/p/android-on-freerunner/ I couldn't straightforwardly find any slides, from that starting point. Could you post the exact URL? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM as car navigation
[For people not also following the GTA04 ML: this followup makes (a little) sense following the case manufacturing discussion at http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001691.html, in particular regarding the large hole underneath "neo".] openm...@pulster.de (Christoph Pulster) writes: > Hi, > > please see Openmoko inside a vehicle as navigation system: > https://despora.de/posts/228392 And there's another unidentified use of the hole there too. I wonder what that string is for? :-) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to bring forward the community?
rhn writes: > Having an easy way to build and share programs (without the need of an > entire distribution checkout like SHR needed if I remember right) > would also help. Native compilation perhaps? FWIW, native compilation has always been possible on the GTA02, at least under Debian. Admittedly it was sometimes painfully slow - depending on what I was compiling - but nevertheless definitely possible. On the GTA04 it is quite straightforward and quick to compile things. I'm doing it all the time. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: what to with 02 when upgrading to 04? was: Re: How to bring forward the community?
msoko...@ivan.harhan.org (Michael Sokolov) writes: > close in terms of hackability. Unfortunately the greedy bastards are > refusing to share, hence extracting the ware from them requires the > use of a soldering iron, inserted rectally. If anyone is willing to I'm sorry, but that is an intolerable thing to write. I hope you will take it back and apologise for it. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Keyboard for GTA04
"Dr. H. Nikolaus Schaller" writes: > Now comes the key idea: having a shapeways printed case makes > it possible to think about a keyboard built into a replacement battery > cover. It makes it a little thicker than normal, but you can detach it > and use it as a keyboard. This sounds interesting. I can imagine that my fingers might even get used to using such a keyboard without detaching it from the back. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Perfect on screen keyboard?
Radek Polak writes: > Any other ideas for nice and usable keyboards? I'm wondering about dasher, controlled by slight tilt movements, which would be detected by the accelerometer and/or gyroscope. Dasher already runs on the GTA04 with finger/stylus control, but there are two problems with that: it needs two hands, and for right handed people the finger/stylus hides a significant section of the letters appearing from the right. With tilt movements input could be done with one hand, and the oncoming letters would not be obscured. It needs prototyping to see if it would be really comfortable, so I may try to work on that. AFAICT from some very quick searching, it's been done on a tablet [1] but not on a smartphone yet. [1] http://www.inference.phy.cam.ac.uk/saw27/dasher/toshtilt/ I think the steps needed for GTA04 are: - finished drivers for the accelerometer and/or gyroscope - a program to take and process driver output and feed inputs into dasher's UDP socket input (like 'ToshTilt' mentioned at [1], but for GTA04) - input method integration so that dasher appears automatically when a text field gets focussed (which can be done by using or modifying the matchbox-keyboard-im code) - dasher UI modifications to hide things that aren't needed (the menu and toolbar) and add finger-friendly controls for what is needed (e.g. completing input and returning to the underlying app) - optionally, UI tweaks to make it fit better in the look of the containing distribution. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Discussion: what are your dreams for the Openmoko Community
"Dr. H. Nikolaus Schaller" writes: > It has become a little quiet here in the last weeks so that I > really fear about the spirit and status of this community. I think your fear is unnecessary. There have also been times with very high activity not so long ago. It's northern hemisphere spring / summer, so people are spending more time outdoors and less with their electronics. Also I guess there will be more activity when the GTA04 group tour devices go out. > So what are your dreams with respect to open mobile handhelds? > What would you like as future hardware? What to see in software > distros? Anything else? What missing piece are you waiting for? I've written this kind of email 2 or 3 times and got relatively little response. My impression is that most people are impressed only by flashy whole systems, or by ideas associated with extreme(-ish) outdoor activities; and not much by - dreams/ideas that haven't been implemented at all yet - incremental developments and experiments in everyday OS or phone usage, outside the "whole system" context. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Discussion: what are your dreams for the Openmoko Community
Timo Juhani Lindfors writes: > "Dr. H. Nikolaus Schaller" writes: >> What would you like as future hardware? What to see in software >> distros? > > I'd like to have an open source calendar application, please :) "dates" ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Delivery of the GTA04
Bob Ham writes: > On Tue, 2012-05-08 at 09:26 +0200, Dr. H. Nikolaus Schaller wrote: >> * I think it will need 1-2 weeks until we finally know and they have >> production ramped up > > Do we know whether the GTA04 group tour units have production ramped up? > We could do with them here in the UK right now.. > > http://www.computerworlduk.com/news/public-sector/3357807/met-police-uses-quick-mobile-data-extraction-system-against-suspects/ > > :-) In the current policing and surveillance climate, it might be in GTA04 owners' interest to develop something that _appears_ to co-operate with that extraction software. Better for an officer on the road to see some quick harmless results, than to be confronted with an unknown and so probably terrorist device that their software can't understand. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ideas for a personal cluster with gta04
joa...@verona.se writes: > In the spirit of the recent ideas threads here, I'd like to share my > ideas that I would like to achieve with the gta04, as part of a larger > system. I wrote it in an article format, and it isn't finished, but > nothing ever is. So here goes. I really like your ideas. I don't have specific comments on them for now, but in general the client-server approach looks very interesting. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Missing libmpfr.so.1 for building qtmoko on Ubuntu Precise Pangolin 12.04 64-bit
Carsten Gerlach writes: > I understand it right, this script creates a *.tar.gz file for > using on the sd-card and has to be used in the build directory? Yes, but that .tar.gz file only contains - and therefore updates - things on the SD card under /opt/qtmoko. > Ok, the generated file is only 23 MB big, but I would expect a file > size of 87 MB, like the file on souceforge.net [1]. So, did I missed > something in the building process or what else is the reason for this > difference? The 87 MB file also includes everything outside /opt/qtmoko, which is a normal Debian rootfs. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko ringtones
robin writes: > that's what I had thought too so the ringtone sides in "sides in" doesn't make sense here. What did you mean? > /home/root/Documents/Music/Ringtones > > for mp3 compatability I installed the codec package. But if I now start to > edit a contact and go for ringtone I get none alarm phonering and others. > if I press on others I only get No Documents found. Do you know the folder > of alarm and phonering. maybe I can place it in there directly or do a > symlink. root@neo:~# find /opt/qtmoko/ -name "*phonering*" /opt/qtmoko/etc/SystemRingTones/phonering.wav Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WLAN connection problems w. static IP
Thomas Pantzer writes: > I can't use DHCP with my home network since my DHCP server > refuses to send IP address to clients that send too short > request. This is another bug in the QtMoko. According to > the RFC a DHCP-request needs to be padded up to 300 chars. If my reading of the QtMoko source is correct, QtMoko simply uses 'udhcpc' to do client-side DHCP. So what you've described may be a known bug with the Debian squeeze version of udhcpc (which is part of busybox). Therefore, you might like to: - see if you can reproduce the same problem with Debian squeeze udhcpc, running independently of QtMoko - investigate if that problem has since been fixed in busybox upstream - build and install a modified busybox package that adds that udhcpc fix. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
Radek Polak writes:
> On Thursday, May 17, 2012 12:55:13 AM Robin Paulson wrote:
>
>> it printed this, i'm not sure what it means:
>> QDBusObjectPath: invalid path ""
>> Method call "/->DefaultAdapter()" failed:
>> QDBusError("org.bluez.Error.NoSuchAdapter", "No such adapter")
>
> It looks like bluetooth adapter and bluez are not working. You can
> try: [...]
I wonder if it would be a generally useful idea to catch and show qpe's
output in cases like this, and then give the user the choice of
restarting or powering off? I think that might be less alarming that
seeing the UI restarting repeatedly. When this restarting last happened
to me, I was worried if it would be safe to force the phone to power off
- so it would be nice to have an explicit option for that.
Alternatively, the top level loop could measure how quickly qpe is
restarting, and power off automatically if it restarts twice in less
than 1 minute. In that case it might also pop up a notice/explanation,
with a reference to where to look (on the SD card) to see qpe's output.
What do you think? Are either of those worthwhile?
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: upgrade my freerunner
Jason Cawood writes: > I heard a rumor that I could buy a faster processor or more memory from the > gta04? 'Tis true. Please take a look at www.gta04.org. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: upgrade my freerunner
Jason Cawood writes: > Is gta04.org working for you guys? When I try to go there I get a 504 > error. Hmm, yes, for me too. Similarly for projects.goldelico.com/p/gta04-main/ and http://www.handheld-linux.com/wiki.php?page=GTA04. Normally those are all fine, so I guess Golden Delicious must be having a spot of technical trouble. Hopefully it won't last long. In the meantime, in answer to your question about upgrading: the deal with GTA04 is that you can get a GTA04 PCB that you swap with the existing (GTA02) PCB in your Freerunner. The main advantages of the new GTA04 PCB are a faster processor and 3G, but there's a lot more detail to it than that, of course. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Good bye qtmoko.org?
Radek Polak writes: > Hi, > it seems that the domain qtmoko.org is no more leading to qtmoko > website. Indeed. That is strange! > I > never owned the domain i though that people who registered it will take care > of it or at least tell me when they don't want to maintain it. > > I have no intention to buy qtmoko.org or put any activity in this direction. > Please correct your bookmark and use: > > http://qtmoko.sourceforge.net/ Will do. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
8939] gadget: high-speed config #1: CDC Ethernet (ECM) [ 84.825927] ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready [ 95.707122] i2c i2c-2: Failed to register i2c client bmp085 at 0x77 (-16) [ 95.812652] usb0: no IPv6 routers present [ 115.061218] i2c i2c-2: Failed to register i2c client bmp085 at 0x77 (-16) [ 134.169494] i2c i2c-2: Failed to register i2c client bmp085 at 0x77 (-16) [ 150.929351] i2c i2c-2: Failed to register i2c client bmp085 at 0x77 (-16) [ 167.122558] i2c i2c-2: Failed to register i2c client bmp085 at 0x77 (-16) [ 186.316558] i2c i2c-2: Failed to register i2c client bmp085 at 0x77 (-16) [ 200.983581] i2c i2c-2: Failed to register i2c client bmp085 at 0x77 (-16) [ 218.814331] i2c i2c-2: Failed to register i2c client bmp085 at 0x77 (-16) ->8-- hciconfig: ->8-- root@neo:~# hciconfig hci0: Type: BR/EDR Bus: UART BD Address: 00:19:88:19:DD:23 ACL MTU: 310:10 SCO MTU: 64:8 DOWN RX bytes:470 acl:0 sco:0 events:16 errors:0 TX bytes:86 acl:0 sco:0 commands:16 errors:0 ->8-- hcitool scan: ->8-- root@neo:~# hcitool scan Device is not available: No such device ->8-- rfkill state: ->8-- root@neo:~# rfkill list 0: GPS: GPS Soft blocked: no Hard blocked: no 1: Bluetooth: Bluetooth Soft blocked: yes Hard blocked: no 2: hso-5: Wireless WAN Soft blocked: no Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no 4: hci0: Bluetooth Soft blocked: yes Hard blocked: no ->8-- I'm a newbie with Bluetooth, so please advise what further tests and information would help to debug this. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
Radek Polak writes: > On Sunday 10 June 2012 14:23:20 Neil Jerram wrote: > >> rfkill state: >> ->8-- >> root@neo:~# rfkill list >> 0: GPS: GPS >> Soft blocked: no >> Hard blocked: no >> 1: Bluetooth: Bluetooth >> Soft blocked: yes > > ^^ this looks like bluetooth if off. Can you try unblock it? IIRC it was: > > rfkill unblock bluetooth Well there is a line "rfkill block bluetooth &" in qpe.sh, so I guess that is what blocked it. Also I'd guess now that this problem - QtMoko restarting because of a bluetooth problem - is a simple race between that background rfkill command and the rest of the qpe.sh script. (It then makes sense that if QtMoko doesn't start quickly enough the first time, because of bluetooth already being off, it will never start on any further iterations.) Here's what I see after commenting out that rfkill line: - QtMoko starts up fine. (This is not yet significant, though, because it often starts up fine anyway.) - Bluetooth symbol is shown in the top line of the UI - Diagnostic output: ->8-- root@neo:/opt/qtmoko# hciconfig hci0: Type: BR/EDR Bus: UART BD Address: 00:19:88:19:DD:23 ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:1564 acl:0 sco:0 events:47 errors:0 TX bytes:510 acl:0 sco:0 commands:47 errors:0 root@neo:/opt/qtmoko# hcitool scan Scanning ... root@neo:/opt/qtmoko# rfkill list 0: GPS: GPS Soft blocked: no Hard blocked: no 1: Bluetooth: Bluetooth Soft blocked: no Hard blocked: no 2: hso-5: Wireless WAN Soft blocked: no Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no 4: hci0: Bluetooth Soft blocked: no Hard blocked: no ->8-- Presumably, then, the right fix for this is either to ensure somehow that the "rfkill block bluetooth" happens after QtMoko startup, or to make QtMoko start up even if bluetooth is off. The latter would be better, because someone might have switched bluetooth off and then choose to "Restart QtMoko". Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] QtMoko v45 : keyboard layout and emails
adrien writes: > Hello! > > I was playing with keyboard layouts and I've made this : I've added an > "ABC" mode (so the "abc" mode, but shifted) and I modified the switch > button to reflect which will be the next layout. That sounds good; I was also missing easy access to the shifted letters. I'll try out your change this evening. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] QtMoko v45 : keyboard layout and emails
Neil Jerram writes: > adrien writes: > >> Hello! >> >> I was playing with keyboard layouts and I've made this : I've added an >> "ABC" mode (so the "abc" mode, but shifted) and I modified the switch >> button to reflect which will be the next layout. > > That sounds good; I was also missing easy access to the shifted letters. > I'll try out your change this evening. It works for me, and I think it's a nice improvement. Also it's really cool that you can do that just by working with svg files. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v45
Marc Langlois writes: > Hi, > > I do not have much knowledge on the environment qtmoko and I have the same > problem as glaszlo cf. Mail Wed Jun 27. > I see that pppd is not included in the image-debian-gta04 qtmoko-v45.tar.gz > while it is in the image qtmoko-debian-GTA02-v45.tar.gz. > Should we not added in the image to pppd gta04? GPRS on the GTA04 doesn't need pppd. The modem and driver already provide something that looks like a Linux Ethernet interface (hso0). That doesn't make it necessarily right that pppd isn't included, because it could be needed for other reasons. But I expect it's a good part of the explanation. > When I add a GPRS configuration, I give information APN, user, password but I > have the message: > I enabled logging and got > / usr / sbin / pppd: the remote system (dialup6542625957) is required to > authenticate soi purpose I could not find any secret password Suitable to use > for it to do so. Is that on GTA02 or GTA04? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v45
Marc Langlois writes: > Neil, > > My phone is GTA04A4. Ah, thanks. Has GPRS actually been integrated yet in QtMoko on the GTA04? I'm not sure that it has. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v45
Neil Jerram writes: > Marc Langlois writes: > >> Neil, >> >> My phone is GTA04A4. > > Ah, thanks. Has GPRS actually been integrated yet in QtMoko on the > GTA04? I'm not sure that it has. For ease of reference, here's Neil Brown's howto for GPRS on the GTA04 (and which it's well worth creating another copy of): > 0/ connect to /dev/ttyHS3 (others might work) > 1/ make sure you are registered with network. > e.g. > AT+CFUN=3D1 > AT+COPS > AT+COPS? > > 2/ establish data connection > AT_OWANCALL=3D1,1,1 > > 3/ collect status > >AT_OWANDATA? > My response was >_OWANDATA: 1, 49.179.102.244, 0.0.0.0, 211.29.132.12, 61.88.88.88, 0.0.0= > .0, 0.0.0.0,144000 > ^IP address ^ ^DNS-1--^ ^DNS-2^ > > 4/ configure network > > ifconfig hso0 49.179.102.244 up > route add default dev hso0 > > echo nameserver 211.29.132.12 > /etc/resolv.conf > echo nameserver 61.88.88.88 >> /etc/resolv.conf > > > > > And you should be set to go. If you want tethering via USB then add: > on GTA04: > echo 1 > /proc/sys/net/ipv4/ip_forward=20 > iptables -t nat -A POSTROUTING -s 192.168.0.200 -j MASQUERADE > >(here 192.168.0.200 is the IP of my notebook on the USB interface.) > > on notebook/desktop/whatever > > route add default gw 192.168.0.202 > echo nameserver 211.29.132.12 > /etc/resolv.conf > echo nameserver 61.88.88.88 >> /etc/resolv.conf > >(192.168.0.202 is IP of GTA04 of USB link). > > To terminate data call > > AT_OWANDATA=3D1,0,1 > > > You don't need pppd at all. But there are no occurrences of "OWAN" in the qtmoko codebase - so I'm pretty sure it hasn't been integrated yet. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Status OpenPhoneux / GTA04
"Dr. H. Nikolaus Schaller" writes: > The good answer is that as soon as we decide to continue, > it takes less than 4 weeks to produce, test and ship all missing > boards. They have planned that it works even if holiday season > is coming. And our shipment plan is by sequence of order. So > if you did order early, it is even a little closer. Just a thought... If there are any Group Tour participants who are planning on developing stuff with/for QtMoko, and are feeling frustrated because of not yet having a physical GTA04 in their hands, then: - I would encourage you to get going anyway with cloning the repository, setting up the tool chain, becoming familiar with the codebase, and trying and building some changes. - I undertake to test any patches that anyone may want to send me and to provide feedback on them. In other words, it's still possible to do development but with a remote GTA04. Then when the Group Tour orders arrive, we'll be that much further forward. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] MokoFaen theme v2
francesco.dev...@mailoo.org writes: > Critics and suggestions are always appreciated. I really like MokoFaen, thanks! But I'm a bit confused by all the similar theme names: faenqo, faenqomod and mokofaen. What's the history there, and is it still useful to have all these variants? It's a bit confusing for anyone who's not deeply into this yet. (For example, if I want to add pressure somewhere, as I have with finxi, do I have to do that with all 3 of the themes above?) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] MokoFaen theme v2
francesco.dev...@mailoo.org writes: >> But I'm a bit confused by all the similar theme names: faenqo, faenqomod >> and mokofaen. What's the history there, and is it still useful to have >> all these variants? > > Faenqo: > is the first theme in chronological sequence, made by cyberesprit. > I don't think it is maintained anymore, but it works and it's cute; > > FaenqoMod: > a mod of faenqo theme, made by me and based on the work of cyberesprit. > It works but I don't think I'll update it anymore; > > MokoFaen: > is a new theme, it's the ideal prosecution of faenqomod. > I'm currently working on it, and for the foreseeable future it's the > theme that I will update. Thanks for explaining that; now I'll go and try them all out a bit more. > To have all of them it's just to give choices to the users, maybe a > more accurate description in the download page could be useful. Yes, I think descriptions like you've given above would be nice. >> For example, if I want to add pressure somewhere, as I have with finxi, >> do I have to do that with all 3 of the themes above? > > Well, yes. But if you have some special request I could manage to add > some features in future releases, or you can simply hack and update > the themes yourself ;) As long as a theme has a continuing owner/designer, I guess it's best to go through him/her, for consistency of the theme design. In Finxi, I added a current pressure display (as e.g. "985mb") to the top left corner of the homescreen. Where do you think that would fit best in MokoFaen? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Simon Busch writes: > I would be really happy to hear what other people are thinking about > the idea behind FSO since it was started back in 2008. What are your > missing features? What do you like and what not? All of the details you've described sound to me like excellent and compelling things to work on. But your wider problem is that you're working in a vacuum, because there's no reasonably widely used phone distribution that uses FSO and that is also regularly and safely updated. That means you have no users for your incremental improvements. Obviously there's SHR, but from what I see on the mailing lists it seems to me that the development edge of SHR is a complete basket case: constantly broken and regressing in very basic functionality. I think you either need to change SHR's approach, or to find/create another compelling distribution (perhaps around Aurora) that uses FSO; otherwise all your planned improvements won't help anyone. I'm sorry to be so negative and unconstructive here, but it seems clear to me that SHR is your "elephant in the room", and I don't think you should ignore that. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Enrico Zini writes: > What I think is needed now are components that give existing > distributions capabilities they didn't have before. Then to see what > people develop on top of them. +1 > But to be appealing to developers who are new to the system (which > basically means, all of them), such componends need to be: few, simple, > reliable, stable, easy to deploy, and if not documented, at least coming > with some working example code. > > Should I mention they should also be compilable with the *stable* > release of the compiler they need? In the past, and for years, I would > even have needed to mention that. I want to believe that at least that > has already changed :) Arguably those two paragraphs are already well satisfied by oFono. oFono probably now has the advantage in terms of maturity and deployment, is compilable by a standard C compiler, and has a recent version packaged in Debian. The following may sound pointlessly controversial, but I don't intend it that way; I think it may help the FSO developers to review and understand more precisely their objectives. Why is FSO still needed at all, given that oFono exists and appears to have the development mindshare and advantages noted above? Would your objectives be achieved more quickly or easily by switching to oFono and contributing any needed additions to that? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
"Dr. Michael Lauer" writes: > Hi, > >> Arguably those two paragraphs are already well satisfied by oFono. >> oFono probably now has the advantage in terms of maturity and >> deployment, is compilable by a standard C compiler, and has a recent >> version packaged in Debian. > > FSO is compilable with a standard C compiler as well. Every tarball release > we did has been shipping C files. Ah sorry, my mistake. (I thought FSO was written in Vala now.) >> The following may sound pointlessly controversial, but I don't intend it >> that way; I think it may help the FSO developers to review and >> understand more precisely their objectives. Why is FSO still needed at >> all, given that oFono exists and appears to have the development >> mindshare and advantages noted above? Would your objectives be achieved >> more quickly or easily by switching to oFono and contributing any needed >> additions to that? > > Oh, FSO is so much more than oFono. If you want to compare, then > compare oFono to fsogsmd alone. I agree that there is a difference in scale, but would draw the opposite conclusion. Probably one of the factors in oFono's success is that it concentrates on doing one thing well. I'm not sure any of the non-GSM FSO components have proved themselves yet. I could be seeing things wrong, but to pull out a couple of examples: - GPS: it seems clear now that it was a mistake to pull that under the FSO umbrella, and that mobile devices should just use standard gpsd instead - the Usage API, which I understand to be motivated mostly by power management, is being rendered unnecessary in many cases by the powering on/off being handled automatically in the kernel. > As for the comparison between those two, well, fsogsmd was first, has (IMO, > of course) > a better architecture, a better API, and supports other modems. And there's no > agenda of a company behind – some people may view that as an advantage, rather > than a disadvantage. > > I don't see why we should invest time in something we consider not being > superior. But might it be less work overall to address those inferiorities in oFono? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Denis 'GNUtoo' Carikli writes: > On Tue, 2012-07-31 at 23:13 +0200, Neil Jerram wrote: >> >> - GPS: it seems clear now that it was a mistake to pull that under >> the >>FSO umbrella, and that mobile devices should just use standard gpsd >>instead > However I was told that adding support for AGPS and GTA02 UBX would not > be straingtforward in gpsd. > > AGPS is very usefull to save/restore the AGPS data offline in order to > speedup the fix. > > All that works on ogps. Hmm. I should probably concede here because I don't know any of the details or history. Technically, however, I'm surprised if there was no feasible way of doing this with gpsd. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] MokoFaen theme, update
francesco.dev...@mailoo.org writes: > Hi list! > > I'm going to work to an update for the MokoFaen theme for QtMoko. I'm > planning a few changes to it but I really would like to have some > feedback from the community. I like MokoFaen a lot. I think it's more beautiful and elegant than Finxi, and has better overall use of the screen space. Nevertheless I still switch back to Finxi quite frequently - simply because that's where Radek adds new things, and sometimes I need to see those. I think the challenge is more or less exactly as you've said below: how can you allow for all those extra little bits of information, while still staying elegant? > Usually I just follow my taste, but I admit that my work sometimes > lacks beauty and functionality. So I'm asking you to give me some > hints, to tell me what you like, what you don't like, what features do > you want. > > For now I found some aspects that I would like to change: > - The theme became heavy, if you use a GTA02 you can notice a less > responsiveness of the system, compared to the default Finxi theme. > I have to lighten the graphical elements; FWIW, on GTA04 I don't notice this. > - The theme became also "heavy" from an aesthetic point of view, maybe > a more minimal style could be pleasant; I don't know, because I only looked at MokoFaen recently. It doesn't seem heavy to me as it is now. > - In the home screen there are a lot of infos displayed, maybe they > can be regrouped in a more efficient way, I'm thinking about > something like conky [1] or conky-colors [2]; Those links look nice to me. I suppose if a bunch of information moved inside conky, and then each theme's homescreen embedded conky, - the advantage would be only having to manage that information in one place - the disadvantage would be that it would become more different to theme those pieces of information in a very fine-grained way. That's quite finely balanced... Perhaps what swings it, in favour of conky, is that when you have a large collection of basically numbers to present, it's good to impose some more structure on that. > I know that theming is not a critical task, for me it's just an > amusement, but your opinions and help could be really useful. It's much appreciated, all the same. Seems to make the phone a bit more human. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] Setting the clock from GPS time
Run NeronGPS, select the menu, select Other, select Clock. Then press the Sync button. Jiří Pinkava writes: > Hi, > > yes, Neron GPS has this ability. > > On 08/27/2012 05:07 PM, Gilles Filippini wrote: > > Hi, > > Is there a way to set the clock from GPS time with qtmoko? > > Thanks in advance, > > _g. > > > > > ___ > 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: [QtMoko] MokoFaen v2.1
francesco.dev...@mailoo.org writes: > Feedbacks always appreciated. Beautiful! Just one nit: what's supposed to appear next to the globe? I'm guessing some kind of location, but I don't know what to do to make anything appear there? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] MokoFaen v2.1
francesco.dev...@mailoo.org writes:
>>Just one nit: what's supposed to appear next to the globe? I'm guessing
>>some kind of location, but I don't know what to do to make anything
>>appear there?
>
> Yes it is the GSM cell location. To activate it go to Appearance, open the
> options menu and select the main window settings, there check the location
> box.
> However, for me this feature doesn't work, nor in mokofaen nor in finxi.
> Could someone check if it works?
If I've understood the code correctly, there appears to be a missing
link between QModemNetworkRegistration, which is the first place that
gets registration and cell location info, and CellModemManager, which is
the class that sets the Telephony/Status/CellLocation value that the UI
expects.
The patch below tries to connect those two up. It builds, but I don't
have time this evening to quickly test it. If anyone else feels
brave...
Neil
>From 828d7c687e2bc90b11d35b42c5a6d9b9785e5f5c Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 29 Aug 2012 22:08:35 +0100
Subject: [PATCH] Connect the jigsaw pieces for displaying cell location
---
.../telephony/callpolicymanager/cell/cellmodemmanager.cpp | 12
.../telephony/callpolicymanager/cell/cellmodemmanager.h|1 +
2 files changed, 13 insertions(+)
diff --git a/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.cpp b/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.cpp
index 6607581..a03b0c9 100644
--- a/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.cpp
+++ b/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.cpp
@@ -205,6 +205,8 @@ CellModemManager::CellModemManager(QObject *parent)
this, SLOT(registrationStateChanged()));
QObject::connect(d->m_netReg, SIGNAL(currentOperatorChanged()),
this, SLOT(currentOperatorChanged()));
+QObject::connect(d->m_netReg, SIGNAL(locationChanged()),
+ this, SLOT(locationChanged()));
// Rename signal for QAbstractCallPolicyManager.
QObject::connect(this, SIGNAL(registrationStateChanged(QTelephony::RegistrationState)),
@@ -340,6 +342,16 @@ void CellModemManager::registrationStateChanged()
doAutoRegister();
}
+void CellModemManager::locationChanged()
+{
+ QString cell_location;
+ QTextStream(&cell_location)
+<< m_netReg.locationAreaCode()
+<< "/"
+<< m_netReg.cellId();
+ setCellLocation(cell_location);
+}
+
void CellModemManager::rfLevelChanged()
{
QPhoneRfFunctionality::Level level = d->m_rfFunc->level();
diff --git a/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.h b/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.h
index 77a6fd0..1d239d1 100644
--- a/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.h
+++ b/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.h
@@ -108,6 +108,7 @@ private slots:
const QPinOptions&);
void currentOperatorChanged();
void registrationStateChanged();
+void locationChanged();
void autoRegisterTimeout();
void planeModeChanged(bool);
void queryCallForwarding();
--
1.7.10.4
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] MokoFaen v2.1
Neil Jerram writes:
> If I've understood the code correctly, there appears to be a missing
> link between QModemNetworkRegistration, which is the first place that
> gets registration and cell location info, and CellModemManager, which is
> the class that sets the Telephony/Status/CellLocation value that the UI
> expects.
>
> The patch below tries to connect those two up. It builds, but I don't
> have time this evening to quickly test it. If anyone else feels
> brave...
Sorry, wrong patch. Here's the right one.
Neil
>From fdb74f5f6c8a69f4f5e0b63ba4d549d1510821ab Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 29 Aug 2012 22:08:35 +0100
Subject: [PATCH] Connect the jigsaw pieces for displaying cell location
---
.../telephony/callpolicymanager/cell/cellmodemmanager.cpp | 12
.../telephony/callpolicymanager/cell/cellmodemmanager.h|1 +
2 files changed, 13 insertions(+)
diff --git a/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.cpp b/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.cpp
index 6607581..4293b66 100644
--- a/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.cpp
+++ b/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.cpp
@@ -205,6 +205,8 @@ CellModemManager::CellModemManager(QObject *parent)
this, SLOT(registrationStateChanged()));
QObject::connect(d->m_netReg, SIGNAL(currentOperatorChanged()),
this, SLOT(currentOperatorChanged()));
+QObject::connect(d->m_netReg, SIGNAL(locationChanged()),
+ this, SLOT(locationChanged()));
// Rename signal for QAbstractCallPolicyManager.
QObject::connect(this, SIGNAL(registrationStateChanged(QTelephony::RegistrationState)),
@@ -340,6 +342,16 @@ void CellModemManager::registrationStateChanged()
doAutoRegister();
}
+void CellModemManager::locationChanged()
+{
+ QString cell_location;
+ QTextStream(&cell_location)
+<< d->m_netReg->locationAreaCode()
+<< "/"
+<< d->m_netReg->cellId();
+ setCellLocation(cell_location);
+}
+
void CellModemManager::rfLevelChanged()
{
QPhoneRfFunctionality::Level level = d->m_rfFunc->level();
diff --git a/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.h b/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.h
index 77a6fd0..1d239d1 100644
--- a/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.h
+++ b/src/server/phone/telephony/callpolicymanager/cell/cellmodemmanager.h
@@ -108,6 +108,7 @@ private slots:
const QPinOptions&);
void currentOperatorChanged();
void registrationStateChanged();
+void locationChanged();
void autoRegisterTimeout();
void planeModeChanged(bool);
void queryCallForwarding();
--
1.7.10.4
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] MokoFaen v2.1
Radek Polak writes: > On Wednesday, August 29, 2012 11:25:01 PM Neil Jerram wrote: > >> Sorry, wrong patch. Here's the right one. > > Tested and applied now in git, thanks! Nice, thanks. > Btw those two numbers are nice, but they dont say much. IIRC symbian must > have > some database which could translate them to town name. Indeed. Maybe in future we might connect those numbers to the CellHunter/Openbmap/OpenCellID databases, and integrate both using and reporting to those databases. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko ringtones follow up
robin writes: > has anyone successfully used a different ringtone than the standard phonering > and alarm? > > I have copied a wav, an ogg and a mp3 version into the ringtones directory > and to /home/root/Documents but when I select the ringtone under contacts > still only alarm and phonering show up... > > lola.die.maus_44kHz.wav lola.die.maus.mp3 lola.die.maus.ogg > root@neo:~# ls /opt/qtmoko/etc/SystemRingTones/ > alarm.wav lola.die.maus_44kHz.wav lola.die.maus.mp3 lola.die.maus.ogg > phonering.wav > root@neo:~# I think you have to do a Document Rescan before trying to select a newly installed ringtone. Click the bottom right icon on the Main Menu page, then select "Rescan System" from the menu. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QtMoko] RFC: UI for adding Search to NeronGPS
I'm interested in adding a Search facility to NeronGPS, using http://nominatim.openstreetmap.org/, but I'm not sure what would be the best UI, so would appreciate ideas or input on this. I think the starting point has to be a dialog with text entry, where the user types in what they want to search for. In future there could also be voice input and voice recognition, but let's assume text entry for now. Given that, http://nominatim.openstreetmap.org/ will return a list of possible places, each with coordinates and a description, so the question is what to do with those. - We could show them all as markers on the map. But that raises the question of what to do if some of them are outside the current map. Any automatic shifting or zooming of the map might cause unwanted new downloading, and/or show areas of black for a while. Options could be: - Not shifting or zooming the map at all. The only markers that will be visible straightaway are those within the current bounds. Other markers would become visible as/when the user shifted/zoomed the map so as to cover them. - Shifting and zooming the map as much as is needed to show all the returned markers, and never mind the implications. - Shifting and zooming up to some configurable limits, so as to show as many markers as those limits allow. - Alternatively, the results could instead be shown in text form in the search dialog, with a "Go to" button for each one. In addition it would be nice to have an integration with the POI (Point of Interest) function. - All search results could automatically become POIs, or alternatively a new temporary kind of POI that only lasts until a different search is done. - If the map is on or close enough to a search result, and the user selects to make a POI, the POI name is automatically initialised from the search result description. Any thoughts? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mokofaen default theme in QtMoko?
Radek Polak writes: > Hi, > anyone has objections? I have been using Mokofaen for some time and for me > this theme wins. I would like to make it default for v48 or v49. I would be happy with that! Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] QX touchscreen input do not work
francesco.dev...@mailoo.org writes:
> Also, in QX the option "rotate screen" does nothing, what should it do?
I have some theoretical patches for that (attached), but I haven't
offered them to Radek because I haven't really got QX working much at
all, and so I couldn't be sure if the QX rotation support was working.
The first attached patch is for the main QtMoko repository; the second
is for the Arora submodule.
Regards,
Neil
>From 2cdb6f0b0e8393379670efe7e4aee6e89056995d Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Tue, 17 Jul 2012 22:55:15 +0200
Subject: [PATCH] Improve accelerometer library, and use it in Arora and QX
for autorotation
---
src/3rdparty/applications/arora|2 +-
src/3rdparty/applications/qx/qbuild.pro|1 +
src/3rdparty/applications/qx/rotate.cpp| 76
src/3rdparty/applications/qx/rotate.h |5 --
src/3rdparty/games/qtmaze/form.cpp |2 +-
src/libraries/accelerometer/accelerometers.cpp | 65
src/libraries/accelerometer/accelerometers.h |6 +-
7 files changed, 72 insertions(+), 85 deletions(-)
diff --git a/src/3rdparty/applications/arora b/src/3rdparty/applications/arora
index 6fe8d25..c4938dc 16
--- a/src/3rdparty/applications/arora
+++ b/src/3rdparty/applications/arora
@@ -1 +1 @@
-Subproject commit 6fe8d25fd36dbc29b5e6c479db1193e6523eeb7b
+Subproject commit c4938dce05b27426334cd32d594084fbd055880d
diff --git a/src/3rdparty/applications/qx/qbuild.pro b/src/3rdparty/applications/qx/qbuild.pro
index a22a561..3fbf3e7 100644
--- a/src/3rdparty/applications/qx/qbuild.pro
+++ b/src/3rdparty/applications/qx/qbuild.pro
@@ -4,6 +4,7 @@ TARGET=qx
CONFIG+=qtopia
LIBS+=-lX11 -lXtst
DEFINES+=QTOPIA
+MODULES*=accelerometer
# I18n info
STRING_LANGUAGE=en_US
diff --git a/src/3rdparty/applications/qx/rotate.cpp b/src/3rdparty/applications/qx/rotate.cpp
index 52302d6..4463698 100644
--- a/src/3rdparty/applications/qx/rotate.cpp
+++ b/src/3rdparty/applications/qx/rotate.cpp
@@ -7,6 +7,8 @@
#include
+#include
+
/**
* The acceleromer algorithms and code taken from omnewrotate-0.5.4
* Copyright © 2008 Rui Miguel Silva Seabra
@@ -55,9 +57,7 @@ RotateHelper::RotateHelper(QObject *parent, int dflg) : QObject(parent)
down = 0;
last_pos= -1;
current_pos = -1;
- event3 = -1;
debug = dflg;
- skip_zero = 1;
initial_rotation= -1;
}
@@ -88,6 +88,9 @@ void RotateHelper::start(int timeinms)
stop();
}
+ // start accelerometer
+ accelerometer_start(timeinms, NULL, NULL);
+
// start up a single shot timer to check accelerometers
// it will be restarted each time
timer = new QTimer(this);
@@ -103,10 +106,8 @@ void RotateHelper::stop()
timer= NULL;
}
- if(event3 != -1){
- close(event3);
- event3= -1;
- }
+ // stop accelerometer
+ accelerometer_stop();
}
void rotate(int degree)
@@ -145,6 +146,10 @@ void RotateHelper::maybe_rotate(int deg)
void RotateHelper::sample()
{
+ x = 1000 * getacx();
+ y = 1000 * getacy();
+ z = 1000 * getacz();
+
if(packet_reader()){
int pos= define_position();
if(pos != last_pos)
@@ -218,66 +223,9 @@ int RotateHelper::define_position(void)
return current_pos;
}
-
-int RotateHelper::read_packet()
-{
- static struct input_event event_x, event_y, event_z, event_syn;
- void *packet_memcpy_result = NULL;
- int packet_size = sizeof(struct input_event);
- int size_of_packet = 4 * packet_size;
- int bytes_read = 0;
- char packet[size_of_packet];
-
- bytes_read = read(event3, packet, size_of_packet);
-
- if (bytes_read < packet_size)
- {
- qWarning("RotateHelper: fread failed");
- stop();
- return -1;
- }
-
- /* obtain the full packet */
- packet_memcpy_result = memcpy(&event_x, packet, packet_size);
- packet_memcpy_result = memcpy(&event_y, packet + packet_size, packet_size);
- packet_memcpy_result = memcpy(&event_z, packet + 2 * packet_size, packet_size);
- packet_memcpy_result = memcpy(&event_syn, packet + 3 * packet_size, packet_size);
-
- if(skip_zero && (event_x.value == 0 || event_y.value == 0 || event_z.value == 0))
- {
- // qDebug("Bad packet!");
- return(0);
- }
-
- if (event_syn.type == EV_SYN)
- {
- x = event_x.value;
- y = event_y.value;
- z = event_z.value;
-
- return (1);
- }
- else
- return (0);
-}
-
bool RotateHelper::packet_reader()
{
- if(event3 == -1){
- event3 = open(EVENT_PATH, O_RDONLY);
-
- if (event3 < 0){
- qWarning("Can't open '%s': %s\n", EVENT_PATH, strerror(errno));
- return false;
- }
- qDebug("Opened: %s", EVENT_PATH);
- }
-
- while(read_packet() == 0);
-
- // qDebug("read packet");
-
- return true;
+ return (x || y || z);
}
#else // QTOPIA
diff --git a/src/3rdparty/applications/qx/rotate.h b/src/3rdparty/applications/qx/rotate.h
index fdce73b..cfcc608 100644
--- a/src/3rdparty/a
Re: [QtMoko] QX touchscreen input do not work
Radek Polak writes: > On Monday, September 10, 2012 08:17:05 PM Neil Jerram wrote: > >> I have some theoretical patches for that (attached), but I haven't >> offered them to Radek because I haven't really got QX working much at >> all, and so I couldn't be sure if the QX rotation support was working. >> >> The first attached patch is for the main QtMoko repository; the second >> is for the Arora submodule. > > Hi Neil, > it's applied now. I tried in arora and it works good, so i expect QX to be > working too - i will try later on Freerunner. Great, thanks! > Btw has anyone figured how to rotate X server on GTA04? No, I don't think so. I tried for a while before moving onto QtMoko, but didn't manage to understand the omapfb X driver. And Neil Brown said recently that it was on his list of things he wanted to do but couldn't yet. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48
Radek Polak writes: > i have reverted commit that made the problem [1]. > [1] > https://github.com/radekp/qtmoko/commit/b98287747b785bb72954edc76105592d6c9404d4 Well, sorry everyone if it was my DTMF-related change that caused this regression. But, Radek, did you notice that there were some other QSerialPort changes that got included somehow in that commit? I'm pretty sure those changes weren't in my patch, and I wonder if they might be related to the SMS issue. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
"dmatthews.org" writes: > I found a single area with (what appears to me to be) regressions - > email I have a copy of a known good qtopiamail.conf which I just put > into place after a slapdash account creation. I can retrieve the > folder list, but the "Fetch all mail" option only sporadically appears > so the imap inbox is not really usable. I never managed to send mail, > getting socket errors everytime. For me, on GTA04, email is working almost perfectly; I'm also using IMAP. For sending, can you ping your SMTP server from the Freerunner? For "Get all mail", note that this is visible only on the Email page, not on the parent page for all messages (including SMS), or on the more specific pages for each email account. When I did a "Get all mail", with several thousand messages to download, it did take around a minute (I think) before the application even started showing a progress bar; and it took a few hours to complete that initial download. On the Freerunner, with 2G instead of 3G, I imagine those operations would probably take even longer. If you're sure you have IP-level connectivity to your IMAP and SMTP servers, and still things aren't working, perhaps you could use tcpdump to capture the IMAP and SMTP exchanges, then look at that on another computer with Wireshark? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
"dmatthews.org" writes: > 2. Socket error on trying to send mail - I was pretty certain this was > failing too quickly to actually be going out and trying to > authenticate. I have generally used the fastmail.fm smtp server on the > phone - not sure why, although possibly because it used to just work > without too much fiddling. > > So I sacrificed the previously known good config in the copied > qtopiamail.conf file that served me through several versions of qtmoko > and entered details of my own mail server. I can then look at it's > logs for information about a failed smtp connection - as I suspected, > there is nothing there. > > In summary I'm pretty sure these are real problems on the neo that did > not exist, in for instance versions 26 and 35. I'd like to do what I can to help debug this, as I've been looking a bit at the qtmail program, and finding it very useful. For the mail sending problem, what exactly are the diagnostics? For example, what is it that makes you write "Socket error" above? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] [QtMoko] QX touchscreen input do not work
NeilBrown writes: > I spent a while looking into this and my conclusion is that while the frame > buffer does support rotation, the Xorg driver for the omap3 framebuffer > doesn't hook into that. Also I couldn't find any evidence of ongoing > development of the omap3 Xorg driver. > So I'm guessing that to make 'xrandr' work on the GTA04 will take some fairly > serious hacking in Xorg driver code. > > I wish I had time to do that ... though to be honest, if I did have the time > I'd probably spend it on something else :-( It seems that xf86-video-omap is going to be the way forward (rather than -omapfb or -omap3) and that xrandr support has just recently gone into it: http://cgit.freedesktop.org/xorg/driver/xf86-video-omap/ http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1026975.html For QX in QtMoko, if I've understood correctly, I think this will be a reason for upgrading to wheezy (when it's released). Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] QX touchscreen input do not work
Radek Polak writes:
> On Monday, September 10, 2012 08:17:05 PM Neil Jerram wrote:
>
>> I have some theoretical patches for that (attached), but I haven't
>> offered them to Radek because I haven't really got QX working much at
>> all, and so I couldn't be sure if the QX rotation support was working.
>>
>> The first attached patch is for the main QtMoko repository; the second
>> is for the Arora submodule.
>
> Hi Neil,
> it's applied now. I tried in arora and it works good, so i expect QX to be
> working too - i will try later on Freerunner.
I have one more accelerometer-patch, below. It changes QtMaze so that
it doesn't run its own fast timer in parallel with the one in the
accelerometer library.
I've had this for a while, so I'm confident it's good for GTA04. It
would be good to hear from GTA01/2 people that all accelerometer
functions are still working correctly there.
Regards,
Neil
>From bc52c9b07bd05dfdad3a4dd2828a788b6f3fc3c9 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Sun, 29 Jul 2012 20:34:43 +0200
Subject: [PATCH 05/14] QtMaze: use accelerometer callback instead of running
own timer
---
src/3rdparty/games/qtmaze/form.cpp | 23 ++-
src/3rdparty/games/qtmaze/form.h |5 +++--
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/src/3rdparty/games/qtmaze/form.cpp b/src/3rdparty/games/qtmaze/form.cpp
index f021414..c02c97a 100644
--- a/src/3rdparty/games/qtmaze/form.cpp
+++ b/src/3rdparty/games/qtmaze/form.cpp
@@ -195,15 +195,10 @@ void Form::apply_temp_phys_res()
post_phys_res(tmp_px,tmp_py, tmp_vx,tmp_vy);
}
-void Form::tout()
+void Form::tout(double ax, double ay)
{
-//printf("[acc] %.4f %.4f %.4f\n", getacx(), getacy(), getacz());
-
new_game_state = GAME_STATE_NORMAL;
-double ax = getacx();
-double ay = getacy();
-
double mid_px=px, mid_py=py;
double mid_vx=vx, mid_vy=vy;
@@ -537,13 +532,13 @@ void Form::MoveBall(double x, double y)
ballshadow_lbl->move(lpx+shadow_shift, lpy+shadow_shift);
}
-void Form::acc_timerAction()
+void Form::acc_timerAction(double acx, double acy)
{
if (!fullscreen) return;
if (game_state == GAME_STATE_NORMAL)
{
-tout();
+tout(acx, acy);
if (game_state != GAME_STATE_NORMAL)
{
int bshift = (qt_game_config.hole_r - qt_game_config.ball_r) / 3;
@@ -854,15 +849,11 @@ Form::Form(QWidget *parent, Qt::WFlags f)
info1_lbl->setText( "Touch the screen to continue" );
InitState();
-accelerometer_start(0, NULL, NULL);
+accelerometer_start(PROC_ACC_DATA_INTERVAL, Form::accel_callback, this);
timer = new QTimer(this);
connect(timer, SIGNAL(timeout()), this, SLOT(timerAction()));
-QTimer *acc_timer = new QTimer(this);
-connect(acc_timer, SIGNAL(timeout()), this, SLOT(acc_timerAction()));
-acc_timer->start(PROC_ACC_DATA_INTERVAL);
-
installEventFilter(this);
this->levelno_lbl->installEventFilter(this);
this->info1_lbl->installEventFilter(this);
@@ -884,3 +875,9 @@ Form::~Form()
{
// no need to delete child widgets, Qt does it all for us
}
+
+void Form::accel_callback(void *closure, double acx, double acy, double acz)
+{
+ Form *form = (Form *)closure;
+ form->acc_timerAction(acx, acy);
+}
diff --git a/src/3rdparty/games/qtmaze/form.h b/src/3rdparty/games/qtmaze/form.h
index 9af8422..68f2e17 100644
--- a/src/3rdparty/games/qtmaze/form.h
+++ b/src/3rdparty/games/qtmaze/form.h
@@ -49,12 +49,14 @@ private:
void ProcessGameState();
int testbump(double x,double y, double mm_vx,double mm_vy);
int edgebump(int tx,int ty, double x,double y, double mm_vx,double mm_vy);
-void tout();
+void tout(double ax, double ay);
void apply_temp_phys_res();
void post_temp_phys_res(double x, double y, double mm_vx, double mm_vy);
void post_phys_res(double x, double y, double mm_vx, double mm_vy);
void BumpVibrate(double speed);
void setButtonsPics();
+void acc_timerAction(double acx, double acy);
+static void accel_callback(void *closure, double acx, double acy, double acz);
public:
Form( QWidget *parent = 0, Qt::WFlags f = 0 );
@@ -62,7 +64,6 @@ public:
private slots:
void timerAction();
-void acc_timerAction();
bool eventFilter(QObject *target, QEvent *event);
void ScreenTouchedPause();
void ScreenTouchedContinue();
--
1.7.10.4
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
"dmatthews.org" writes: > Hi Neil, Radek > > I spent some time on what I believe are the email issues. > > First thing I did to ensure I'm not going mad is the flash back to > v35. As I remembered, I can create an account without bothering with > correct settings, put the qtopiamail.conf in place and everything > works. > > Next I flashed the 2nd v48 image - the situation has improved - the > problem with the "Get all mail" entry disappearing has ... well > disappeared - it does work fine. Despite what you thought - a > difference in v48-1 with the upgraded qtmoko package installed on top > as against the good v48-2? Can't be sure, but at least it's gone away > for me. Well that's good news! > Trying to send mail though, that problem is as I reported already; I'm > using the same qtopiamail.conf I just used in v35 which specifies the > fastmail SMTP server (which I can ping) - sending a test mail to > myself at dmatthews.org gives this rather generic looking error:- > > dmatthews.org -Error sending > Email:Error occurred > [Unknown error] That comes from EmailClient::transferFailure() in src/applications/qtmail/emailclient.cpp. Tracking back from there, I see: - EmailClient::activityChanged(QMailServiceAction::Failed) - QMailTransmitAction::activityChanged(QMailServiceAction::Failed) - QMailServiceActionPrivate::emitChanges() following something that set _activityChanged to TRUE - QMailServiceActionPrivate::setActivity(QMailServiceAction::Failed) (which is the only place that sets _activityChanged to TRUE) - QMailServiceActionPrivate::errorOccurred() or (QMailTransmitActionPrivate::sendCompleted with !_ids.isEmpty()). More likely errorOccurred, I guess. That's as far as I can get for now; the next step seems to involve a QtopiaIpcAdaptor, which I'm not familiar with. However, I think that point is not far above the raw SMTP level, so I wonder if it would help to enable SMTP logging and see what that shows? To do that, go into Home, Settings, Logging; choose YES twice; then choose "Categories..." from the context menu, and check SMTP; then back all the way out. (You don't need to restart QtMoko, despite what it says.) Then repro the sending error. Then go back into Logging and see what it says. With fingers crossed, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko annoyance
On Friday, September 21, 2012 07:59:11, Radek Polak wrote: > On Thursday, September 20, 2012 11:35:27 PM Minus 0 wrote: > > > Hi, > > I wonder if it is at all possible to prevent the screen from unlocking on > > an incoming call? As I happen to keep my phone in my pocket, the automatic > > unlocking leads to the call being answered or rejected before I even have > > a chance to take the phone out of the pocket. Most of the time I use a > > silent profile, and if I walk around, I won't notice the call at all. > > But it will wake the phone up and unlock the screen, so random touches of > > the screen will make it do whatever it likes, like calling someone, e.g. > > an ambulance, delete all my contacts, or break my highscore in snake game, > > and of course drain the battery. > > An incoming message will wake it up, but not unlock the screen, which I > > think is a much more reasonable behaviour. Considering that SHR does it > > right, QtMoko should also be able to, I think. > > Sure. Maybe it would be nice to add slider for answering call on the lock > screen - so that you dont have to unlock & press answer. > > But i cant promise if i'll have time for implementing something like this > soon > :( > > Regards > > Radek > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > But, as a first step, we could implement that the phone is always locked when it resumes? I could take a look at that, if everyone would be happy with it. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 Setting time from phone network using NITZ ?
Adam Ward writes: > I have a GTA02 which I acquired a few years back and until now I have not > really done anything with it. Now I want to use it as my main phone. > > The automatic setting of the date/time from the providors network (in this > case it is Optus) does not work in qtmoko. The provider does support this as > I have a another phone that gets this information. > > I see there is an old bug from the Nokia days: > http://docs.huihoo.com/qt/qtextended/4.4/release-4-4-3.html > BUG 231983 > > According to > http://www.scribd.com/doc/30428306/54/AT-CTZU-Automatic-Time-Zone-Update > I should be able to chat to the modem to get some information. Time and time zone are two different things. In my (patchy and non-scientific) experience, mobile networks often do tell you the time zone, but not the time. Do you know that NeronGPS can sync both time and time zone for you? - obviously, subject to having a GPS fix. > But the following command does not return anything: > root@neo:~# chat -vse '' 'AT+CTZU=?' '' '' > /dev/ttySAC0 < /dev/ttySAC0 > send (AT+CTZU=?^M) > send (^M) > > syslog shows: > Jan 1 08:13:45 neo chat[1109]: send (AT+CTZU=?^M) > Jan 1 08:13:46 neo chat[1109]: send (^M) > > Is there a way to automatically log the AT chat commands ? > Do I have the correct /dev/tty ? > > More generally, is this a problem with the calypso firmware, or qt extended / > qtmoko or something else ? I'm afraid I don't know about those points. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Adam Ward writes: > On Mon, 23 Jul 2012 10:29:38 AM Radek Polak wrote: >> On Sunday, July 22, 2012 02:08:39 PM Simon Busch wrote: >> > As far as I know Qtmoko can use FSO but does not as default. >> >> Yes this is correct. >> >> My plan was to use FSO for GTA04. But when i got my GTA04, there was no work >> for this device done in FSO, so i rather added gta04 modem plugin based on >> qtopiaphonemodem framework and this now default. >> > > New GTA02 user here, I see the code in neocontrol.cpp pulls the library from > http://activationrecord.net/radekp/pub/ > I am guessing that at the time it was current. > The debian package is now current, so I would expect it to be used instead ? I can't tell what you mean here. Which library / package? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Adam Ward writes: > On Sat, 22 Sep 2012 10:01:23 AM Neil Jerram wrote: >> Adam Ward writes: >> > On Mon, 23 Jul 2012 10:29:38 AM Radek Polak wrote: >> >> On Sunday, July 22, 2012 02:08:39 PM Simon Busch wrote: >> >> > As far as I know Qtmoko can use FSO but does not as default. >> >> >> >> Yes this is correct. >> >> >> >> My plan was to use FSO for GTA04. But when i got my GTA04, there was no >> >> work for this device done in FSO, so i rather added gta04 modem plugin >> >> based on qtopiaphonemodem framework and this now default. >> > >> > New GTA02 user here, I see the code in neocontrol.cpp pulls the library >> > from http://activationrecord.net/radekp/pub/ >> > I am guessing that at the time it was current. >> > The debian package is now current, so I would expect it to be used instead >> > ? >> I can't tell what you mean here. Which library / package? >> >> Neil > > I am looking at > http://packages.debian.org/sid/armel/fso-gsmd/filelist > which contains libfsogsm > > Looking again, I see the newer versions are in sid and wheezy which radek > might not be building qtmoko with. Ah, thanks, I understand your question now: what version of fsogsmd does QtMoko build with, and isn't that now rather out of date? But I'm afraid I don't know the answers. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 Setting time from phone network using NITZ ?
Adam Ward writes:
>>
>> Time and time zone are two different things. In my (patchy and
>> non-scientific) experience, mobile networks often do tell you the time
>> zone, but not the time.
>>
>
> I know that Telstra in Australia sends both. My current phone would get the
> correct details after traveling between timezones when I was on that network.
> I will find out in a few weeks if Optus does the same.
FWIW, from a quick look at
devices/neo/src/plugins/phonevendors/neo/vendor_neo.cpp, I see that the
suspend code includes
// Turn off timezone notifications.
chat("AT+CTZR=0");
chat("AT%CTZU=0");
and the resume ("wake") code includes
// Turn on timezone notifications again.
chat( "AT+CTZR=1" );
chat( "AT%CTZU=1" );
and that the code for a CTZU response appears to handle both date/time
and timezone:
void NeoModemService::ctzu( const QString& msg )
{
// Timezone information from the network. Format is
"yy/mm/dd,hh:mm:ss+/-tz".
So maybe I was wrong about time and timezone being separate.
Also note that
(1) there could still be missing bits of support higher up, for actually
doing anything useful with this information
(2) I wonder if it's also necessary to do the "Turn on" actions when the
phone first boots up?
Regards,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v48 neofreerunner
"dmatthews.org" writes: > 3) Finally I attempt unencrypted access to the fastmail server - this is what > definitely works in v35 (I tried it just a few days ago):- > > Sep 23 13:47:09 neo Qtopia: SMTP : newConnection > Sep 23 13:47:09 neo Qtopia: SMTP : Open SMTP connection > Sep 23 13:47:09 neo Qtopia: socketError: 0 : "Connection refused" > Sep 23 13:47:09 neo Qtopia: SMTP : Closed connection Regarding (3), I notice that https://www.fastmail.fm/help/remote_email_access_server_names_and_ports.html says that the right port number is 465, and here's what happens when I try to connect to ports 25 and 465: neil@neil-laptop:~$ telnet mail.messagingengine.com 25 Trying 66.111.4.52... Trying 66.111.4.51... telnet: Unable to connect to remote host: Connection refused neil@neil-laptop:~$ telnet mail.messagingengine.com 465 Trying 66.111.4.51... Connected to mail.messagingengine.com. Escape character is '^]'. ^C^C Connection closed by foreign host. neil@neil-laptop:~$ So perhaps the "Connection refused" you get is caused by QtMoko incorrectly using port 25? Did you set port 465 in the account configuration for sending? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
