Re: [debian/fso] fsoraw no effect?
Am Mittwoch, den 25.11.2009, 22:44 +0100 schrieb A.A.:
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage
org.freesmartphone.Usage.SetResourcePolicy Display enabled
ERROR:dbus.connection:Unable to set arguments ('Display',) according
to signature u'ss': type 'exceptions.TypeError': More items found in
D-Bus signature than in Python arguments
How can I solve?
Can you grab the latest mdbus from python-helpers in
git.freesmartphone.org and try with that? I recall a patch being applied
that fixed that.
--
:M:
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM 2010: Devroom for openmoko declined
http://fosdem.org/2010/list-devrooms-their-call-talks Looking at this list, I really wonder about the criteria these folks use... *shakes head* :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Experiment: better sound on remote end
Am Donnerstag, den 03.12.2009, 17:25 +0100 schrieb Matthias Felsche: Besides: I've implemented Dictator 0.3 as Dbus-Service and -Client. Will be released soon. Don't know lot about fso-progress of the last months. Do you already have something for recording sound I should rather use than to have another dbus-service next to fso? Would it be worth to integrate it into fso? Absolutely. There's no code that yet, but I think simple recording at least should eventually be provided by FSO as well. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] BT Keyboard
Am Montag, den 07.12.2009, 19:04 + schrieb Al Johnson: On Sunday 06 December 2009, Christ van Willegen wrote: Hi everyone, I'm using a BT keyboard (right now! Yeah!). During this e-mail, the SHR today screen keeps popping up. Also, the Illume keyboard keeps popping up (I thought Raster fixed this...). Is there something I missed? FSO's idle detection isn't aware of the keyboard input. Is this with fsodeviced? fsodeviced should recognize new input nodes on demand. Can I see a log? -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus deb with increased timeout
Am Samstag, den 12.12.2009, 20:04 +0100 schrieb arne anka: hi, after hours of struggling with debian's djungle of ways to build a package i finally succeeded to cross compile dbus with an increased timeout. reason: for months now i was fighting with zhone taking several attempts (4 to 5 ususally, often at least one restart of frameworkd and sometimes even reboots) to pop up the pin dialog. after installing the newly built packages, the dialog popped up at the first try. i restarted to be sure and again it was there the first attempt. for those struggling with the same problem in debian, here's the debs: http://www.ginguppin.de/node/29 Awesome, thanks for the update. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR-U Accelerometer data
Am Donnerstag, den 17.12.2009, 11:59 -0500 schrieb Iain B. Findleton: Many tests appear to indicate that a complete report set read from /dev/input/event2 or event3 is a relative rarity. Looking at the code from the lis302dl driver in git.openmoko.org it appears to me that this should not be true, and if I recall correctly, proper output was couming out under OM2009.x at one point. Let me remind you that the driver has changed wrt. RELATIVE and ABSOLUTE. These days, upon opening the device, only the first report is a full report. Subsequent reports only contain changed axes. Anybody with any thoughts on this issue? According to what I read, /dev/input/eventx interface should reliably handle every event and make it available. The other issue is that the first report from the driver following an open on the device should be complete and contain the axis calibration values. This appears to be not true in that the first report I get is often incomplete in that not all axes are supplied. I can't confirm that. I'm running andy-tracking and when I call hexdump inputnode the first three entries are always axes 0, 1, 2. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: UBI success story
Thanks for sharing. How's speed and reliability for ubifs? I wonder whether it's worth the hassle to switch, given that SD access should be even faster and much more convenient. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR unresponsiveness
What is [h]top telling? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] Activate GPRS more than once?
Am Montag, den 28.12.2009, 12:38 + schrieb Tom Yates: On Mon, 28 Dec 2009, Neil Jerram wrote: Can anyone with an FSO-based system activate GPRS more than once? i.e. ActivateContext, DeactivateContext, ActivateContext again. For me - on Debian, and using openmoko-panel-plugin to do the activation and deactivation - the first ActivateContext and DeactivateContext are fine, but the second ActivateContext call fails. The openmoko-panel-plugin logs say that there was no reply to the ActivateContext call. The frameworkd logs have no trace at all of the second ActivateContext call, even with logging level set to DEBUG. I'm wondering if this is just me, or just Debian, or affecting everyone? All thoughts appreciated. i'm running SHR-U, and i'd noticed someting similar, and done a little digging, and it seems to be FSO-related. i summarised my problem and the digging i'd done on the FSO list last month, see http://lists.linuxtogo.org/pipermail/smartphones-userland/2009-November/002201.html , but i got no replies. i'm not sure what to do about it. possibly having more people log their experiences in the FSO tracker at http://trac.freesmartphone.org/ticket/474 would help. once i get home after Christmas, and can bring up GPRS without paying humungous US roaming charges, i'll try to do that. it's not fatal, but it's the last big thing in between me and a fully-functional 'moko. it'd be nice to get it resolved. I'm afraid this is a strange combination of a problem in Python, the Python glib bindings, and/or glib itself. When the ppp process gets closed, the supervising process (frameworkd in that case) hangs forever. I have not yet found a way to fix this, and these days I rather put all my energy into finishing fsogsmd. Patches appreciated, of course. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] Activate GPRS more than once?
Am Donnerstag, den 31.12.2009, 23:33 + schrieb Neil Jerram: 2009/12/28 Michael 'Mickey' Lauer mic...@vanille-media.de: I'm afraid this is a strange combination of a problem in Python, the Python glib bindings, and/or glib itself. When the ppp process gets closed, the supervising process (frameworkd in that case) hangs forever. I have not yet found a way to fix this, and these days I rather put all my energy into finishing fsogsmd. Patches appreciated, of course. When fsogsmd is finished, will it be responsible for the ppp supervision instead of frameworkd? If so, I presume that will fix this problem, because of fsogsmd not using Python and the bindings mentioned above. Is that correct? Yes. In that case, putting energy into fsogsmd sounds good to me; thanks! :) Happy new year! :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Happy New Year from FSO
In the name of the FSO team, I wish all of you a Happy New Year! 2009 was a turbulent year for us, the year where Openmoko stopped supporting us and we had to show our belief in the project by just continuing with as much effort as possible. Thanks to all contributors and users of our APIs. 2010 will be a very critical year for FSO, perhaps the most critical ever -- since it's going to show whether we dive into oblivion being overrun by the big guys, or whether we can establish and strengthen our niche. Middleware always has this problem of invisibility -- what people recognize are applications, not so much the driving software layers below. In order to be a bit more visible, I'd like all of you who are using FSO to join Ohloh[1] and state that you are either a contributor and/or using FSO. If all goes well, 2010 will be the year where we finally migrate all remaining FSO services to C (or Vala, to be exact), hence delivering a significant speedup for your FreeRunner (or whatever device you run FSO on). Let me also remind you that we have a PayPal account for donations, and are also available for contract work. Thanks for your support! (1) http://www.ohloh.net/p/fso -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Happy New Year from FSO
Am Sonntag, den 03.01.2010, 13:35 +0100 schrieb Laszlo KREKACS: On Sat, Jan 2, 2010 at 2:31 PM, Michael 'Mickey' Lauer mic...@vanille-media.de wrote: (or whatever device you run FSO on). Btw how are going the Palm Pre reverse engineering effort? Somewhat disappointing. Although some progress is being made (and we're still working on it), the modem communication proved to be a complete show stopper. Apparantly Palm is using one of Qualcomm's binary protocols, which is very complex to reverse engineer :/ -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Happy New Year from FSO
Am Sonntag, den 03.01.2010, 15:18 +0100 schrieb Laszlo KREKACS: On Sun, Jan 3, 2010 at 2:45 PM, Michael 'Mickey' Lauer mic...@vanille-media.de wrote: (or whatever device you run FSO on). Btw how are going the Palm Pre reverse engineering effort? Somewhat disappointing. Although some progress is being made (and we're still working on it), the modem communication proved to be a complete show stopper. Apparantly Palm is using one of Qualcomm's binary protocols, which is very complex to reverse engineer :/ I had asked, because Im waiting to a device to replace my freerunner. My only requirement is nice audio quality (any mobile phone out there is ok), I want to run fso on it, and 3G. I hoped such device surfaces within a year (ie. until 2011) or even Palm Pre could be this device ... There is still hope. I like the form factor of the Palm Pre very much. If we get access to the modem, the rest should be relatively simple. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Happy New Year from FSO
Am Sonntag, den 03.01.2010, 15:42 +0100 schrieb Marcel: What about the Nokia N900? I don't know about the GSM modem, but at least its got a quite open Linux userspace... AFAIK we can't even charge the battery N900 with FOSS, so I'd say there's a whole set of different showstoppers lurking when attempting to bring a free OS to the N900. The modem itself is using a binary protocol as well, as opposed to the Palm Pre though it seems to be somewhat documented. Unfortunately this time I didn't seem to be eligible for a Nokia developer discount, that's pretty much the reason why I don't have a N900. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM Network Time
Am Montag, den 04.01.2010, 18:25 +0100 schrieb Esben Stien: Any way to extract the time from the GSM network and have the time set based on this? FSO contains support for that but so far I have not managed to receive a single NITZ report anywhere in the world. Might be a Calypso problem, then again only very few providers support NITZ reports in the first place. Timezone support is rare, but actual time support is extremely rare. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Alternatives to FR
Am Montag, den 04.01.2010, 20:08 +0200 schrieb Margo: The Officer S101 seems interesting: http://www.road.de/en/handypcs/officer.html http://blog.hackable1.org/2009/08/running-hackable1-on-the-road-officer-s101.html Unfortunately it has been just around the corner and almost out for about 5 years now and the scheduled price tag when it actually comes out (of which I'm not convinced) will be way more than a N900 -- I doubt that it will spread wide that way :/ :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Alternatives to FR
Am Mittwoch, den 06.01.2010, 17:28 +0100 schrieb Laszlo KREKACS: What do you think which mobile phone has the most likeliness to RE or somehow put fso on it? - Google Nexus http://www.google.com/phone/ Unlikely. Same as all other Android phones. Nightmare to get root and after that, you have quite some work to remove the Androidisms. Or teach FSO to use them as well. Modem-interface unclear. - Motorola MILESTONE (US version: Droid) http://www.motorola.com/Consumers/XW-EN/Consumer-Products-and-Services/Mobile-Phones/Motorola-MILESTONE-XW-EN See Nexus. Already rooted the US version (Droid): http://alldroid.org/viewtopic.php?f=236t=567 See Nexus, minus rooting. - Nokia N900 http://maemo.nokia.com/n900/ Likely. It uses basic GNU/Linux, and the modem interface is at least somewhat known. Advanced drivers (Wifi, BT, PowerManagement, Camera) unknown though. - Palm Pre http://www.palm.com/us/products/phones/pre/ Very likely, if it wasn't for the completely obfuscated modem interface which we're still working on. - Apple iphone http://www.apple.com/iphone/ Unrealistic. There won't be a Linux-port soon. Is there some site, who tracks the process of RE of each individual devices? Not really, FSO has a page on the wiki, but since we're not in the kernel business, but rather working on middleware, we rely on the various reverse-engineering communities to do the grunt work. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Alternatives to FR
Am Donnerstag, den 07.01.2010, 18:55 +0100 schrieb Petr Vanek: It may be nice to organize a donation to provide such device to FSO/OE/SHR staff. Excellent idea. +1 Wonderful. How do we get this going? Seems like 600€ in Germany, dunno if with contract or what... what service could we use? Mickey, would this be an option for you? If we get enough people... Absolutely. I think I could get it here even for around 500. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] the Display resource
Am Donnerstag, den 07.01.2010, 21:57 +0100 schrieb Michal Brzozowski: Sorry this has been documented somewhere. I'm playing with the 'Display' resource, and I'm totally confused. I can understand that. The semantics of the Display (and CPU) resource is somewhat different from the semantics of the other peripherals. The display resource is _not_ controlling the display. What it does instead is modifying the way the Idle Notifier works. When you claim the display resource, then the Idle Notifier IDLE_DIM (and subsequent states, such as LOCK and SUSPEND) will no longer be sent, hence the display will stay on and the device will not go into suspend. If I put this into /etc/freesmartphone/oevents/rules.yaml: while: PowerStatus() filters: Not(HasAttr(status, discharging)) actions: -OccupyResource(Display) -OccupyResource(CPU) Does it mean that if the phone is plugged in the display will be always on, and the phone will not suspend ? Yes, that's the idea. What's the right way to tell frameworkd that I've modified rules.yaml? pkill -HUP frameworkd or /etc/init.d/frameworkd restart? I'm afraid the current frameworkd needs a restart after modifying the rules. I promise to fix this in the FSO2. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Happy New Year from FSO
Am Donnerstag, den 14.01.2010, 17:05 +0100 schrieb Patryk Benderz: [cut] Let me also remind you that we have a PayPal account for donations, and HI Mickey, I was looking at (1) http://www.ohloh.net/p/fso but wasn't able to find PayPal account for FSO. Our paypal address is coret...@freesmartphone.org -- this goes to the whole FSO core team. BTW, are you really only one person developing/rewriting FSO to Vala? Unfortunately yes, after Openmoko stopped funding us, my colleagues started diving into their studies to finish those (which is a good thing) -- so for the 6 months, I have been Mr. Lone Rider ... and due to Vala's immaturity it has been a wild ride :) In the last 6 months, I worked roughly 60 hours per week on FSO2. Thanks to my wife having a full-time-job, I could do this without causing any financial trouble. I really believe in the APIs and the architecture we have with FSO1, so I just had to work so much to get the critical mass done, in order to get more people on board then. This year will be different, as I have some other contracts to work on non-FOSS. We're still trying to gather any FSO-based jobs, but with us lacking a showcase on (non-Openmoko) hardware, it's very tough. Don't get me wrong, I love the FreeRunner as it got the whole movement going, but if FSO wants to have a chance to survive, it's vital to finding newer platforms. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Happy New Year from FSO
Am Donnerstag, den 14.01.2010, 22:52 +0530 schrieb rakshat hooja: Not really new hardware but have you seen Rafeal's attempt to get FSO working on the hardware that compulab exeda is based on. He should still have the compulab developer kit we gave him around. He is planning to shift to Brazil so in case you want the kit I will check with him if he can ship it to you Sure, if he no longer is using it, I'd like to have a look at it. Regards, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] illume/e17: relict after killing X/illume
Am Samstag, den 16.01.2010, 16:19 +0100 schrieb arne anka: every time after switching to a runlevel w/o X there's still one process left: /usr/lib/enlightenment/modules/battery/linux-gnueabi-arm-ver-svn-05/batget 64 and it's not even reused when restarting X, but a new one will be created. i am pretty sure, even that process has to be killed when shutting down e17/illume (or whatever starts it). I'd wish someone could write an e17 plugin to get the battery information from FSO. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: debian/fso on freerunner
Am Mittwoch, den 20.01.2010, 11:45 + schrieb Neil Jerram: IMO Debian will eventually assimilate everything, including SHR. (Unless there is some major advantage of the OE build and packaging system that I haven't understood yet...) It's the best combination of free software focussed build, tracking and package management that there is, and I really don't understand why anyone persists with other systems... Well, I've been hearing that for almost a decade now, but still systems like buildroot, OpenEmbedded, OpenWRT, t2-project, etc. are being preferred on lots of embedded systems. Why do you think is that? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Which FSO interface is best to get battery state
Hi Christian, I'm afraid I didn't update the docs after changing the semantics slightly for FSO2. These days, for most applications, I advise to use the aggregated power supply instance, which will provide what you need. The individual supply objects are merely there for monitoring applications. Also, is it certain Freerunner battery is always supply nr. 3? The order of individual power supplies is not guaranteed to be fixed. So which way is best to check my battery is discharging and below requested level? Do I have to always also ask for GetPowerStatus and make sure it is not charging? Or shall I use aggregate one? Yes. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Which FSO interface is best to get battery state
Am Sonntag, den 24.01.2010, 23:29 +0100 schrieb Christian Rüb: So I need to use both - Get Capacity and GetPowerStatus - to make sure I do not release a resource just because capacity is low as the device might be charging? Exactly. In your case, GetCapacity should only be evaluated, if PowerStatus is discharging. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] minor enhancements
Am Donnerstag, den 28.01.2010, 08:24 +0200 schrieb Timo Jyrinki: (forgot to answer to this) 2010/1/12 Neil Jerram neiljer...@googlemail.com: - In zhone, keep current SMS selected when returning from the SMS display screen. You could try to submit that to upstream [1] as well. I regard all of my patches as submitted upstream, by virtue of having been announced here. Is there a specific further step that I should take to offer and flag them to git.freesmartphone.org ? Well, I think you could discuss with FSO team if you could commit rights to the zhone repository there. It's the most obvious/known place anyway, and I'd think it'd bring more visibility to the patches in your tree if they would be there. Absolutely. If you want to get commit access to zhone, drop me your ssh key. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ar6000 (FR's wifi) bugs, workarounds and CLI usage tips, read this for stable wifi
Am Sonntag, den 21.02.2010, 17:14 +0100 schrieb arne anka: please, explain power cycling. rebooting ar6000 (one of Freerunner's computers). that i did understand -- the question is, how to do that. On FSO via releasing/requesting the WiFi resource. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] phonfsod/phoneuid: fso-deviced killed when calling
fsodeviced provides different plugins for audio routing. You want the alsa one for the FreeRunner. You're running debian, right? Do they ship the new alsa data files for fsodeviced? Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mic volume extremely soft after buzz fix with SHR unstable
btw: What is the difference between /etc/freesmartphone/alsa/default/gsmhandset This one is used by fsodeviced, i.e. the new stuff that's being used on SHR. and /usr/share/shr/scenarii/gsmhandset.state ? That's from the old days where we used to call alsactl to do the work. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] phonfsod/phoneuid: fso-deviced killed when calling
Am Sonntag, den 21.02.2010, 21:45 +0100 schrieb arne anka: fsodeviced provides different plugins for audio routing. You want the alsa one for the FreeRunner. well, as written, alsa kills fsodeviced. Probably because of the missing alsa data files (see below). what kind of audio routing? call seems to work even with none (at least i hear something when i call my box). audio routing is necessary i.e. to switch between ring tone and in-call audio. You might hear the ring tone, if that's the default routing, but you will not have in-call audio without routing. You're running debian, right? Do they ship the new alsa data files for fsodeviced? what alsa data files? http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/freesmartphone/fso-alsa-data/om-gta02 Those have to be copied to /etc/freesmartphone/alsa/. Next week, I'll make fso ship them instead of putting them into OE. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] phonfsod/phoneuid: fso-deviced killed when calling
Am Sonntag, den 21.02.2010, 19:21 +0100 schrieb arne anka: investigating my core issue of the fr not suspending anymore after a call, i see now that fsodeviced dies the moment i hit either call (outgoing) or accept (incoming). since fso-deviced is dead, nothing, in terms of idle notification at least, happens anymore. A backtrace would be splendid. Could you install -dbg packages as well as gdb, change params to have apps emit a coredump and then get us a backtrace? Or just run fsodeviced directly under gdb and once it dies get us a backtrace. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SHR Stable Party
Awesome plan, Rakshat, thanks for your work! We're probably not doing enough PR in general -- next week I'll work on giving the FSO website a new couple of entry pages that document what we're after and why we're better than the competition ;) Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
Am Samstag, den 27.02.2010, 10:46 +0100 schrieb ri...@happyleptic.org: You can't just separate software from hardware. The fact is you can't have open software without hardware specs, so open soft and open hard comes close together. Go try to rebuild a kernel on a nokia open phone for instance, and see what part of the phone hardware still works. So what should we do ? a) crack open closed phones by reverse engeneering ? b) wait for a manufacturer to compromise its pot of gold by producing an open phone ? c) put our head in a bag and pretend an iphone or an android is open enough ? d) aim at building one collectively despite all the unbelievers trying to discourage the effort ? a), b) and d) can be parallized; it's different tasks anyways. FSO will be ready for any whatever comes out of a), b), and d) :) Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [PATCH] frameworkd battery status reporting
Hi Neil, can you point me to an example why this patch is necessary? On a related note, I think this code path is not in use since we moved to fsodeviced. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Thone 0.5
Amazing stuff, congrats! -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA02] disable resume on headphone jack removal?
Am Samstag, den 03.04.2010, 13:21 +0300 schrieb Timo Juhani Lindfors: Paul Wise pa...@bonedaddy.net writes: My FreeRunner resumes from suspend-to-memory if I remove the headphones from the headphone socket. Does anyone know if that is configurable or if the hardware just doesn't allow it to be changed? Just check the resume reason and put the phone back to suspend if the reason is headphone. Having the phone unsuspend for 1 second can't be that bad for energy consumption. While that is true, in my opinion the proper way to do it is to expose the wakeup reasons we're interested in to userland. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: RFC: FSOSHRCON 2010 kickoff
I'm afraid not much has been done. I for one certainly do not have the time to take the wheel in organizing it. I'd love to see it happening and I will take part in helping to run it, but someone else needs to take the wheel. Serdar, Frederik? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: false stamentent on http://www.enlightenment.org ?
Am Mittwoch, den 14.04.2010, 15:55 +0200 schrieb mobi phil: On the page: http://www.enlightenment.org/p.php?p=aboutl=en The Openmoko Freerunner sold thousands of devices with EFL on them. Maybe I am wrong, but the default software was never with EFL, or? It was. The 2008 software release was a hybrid composed out of Qtopia/X and EFL. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [E-devel] Fwd: Glamo secrets, acceleration, X11, directfb, was: X11 dependencies hardcoded in ecore_evas
Am Sonntag, den 18.04.2010, 13:38 +0200 schrieb mobi phil: dfb isnt common to fb and x11 - it is an enitre display system of its own. there is a specific xdirectfb server on top of dfb. but it is not a common component. i think you misunderstand directfb... :) \ No!!! I do not misunderstand... Yourself you said the same... Indeed there is a simple xdirectfb on top of dfb. So If everybody, Qt based apps (QtMoko) and X would talk to directfb, then directfb would be an almost perfect lowest common denominator. The lowest common denominator is already present, it's the dumb (but almost always present) framebuffer. I'd appreciate a library that implements an OSD in EFL. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: git.openmoko.org / GTA02 kernel sources?
Am Montag, den 26.04.2010, 18:09 +0200 schrieb Joachim Steiger: the repo got quite big so we hit memory as well as diskspace quotas at the same time ;) i just cloned the kernel repo and it went through fine at 800kbyte/sec kind regards Thanks for continuously providing infrastructure support to us although your contract has ended long ago! Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Congrats! Will I get a fully assembled one for free if I promise to implement FSO DBus APIs? :) Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Am Sonntag, den 02.05.2010, 13:54 +0200 schrieb Michele Brocco: On 5/2/10, Michael 'Mickey' Lauer mic...@vanille-media.de wrote: Congrats! Will I get a fully assembled one for free if I promise to implement FSO DBus APIs? :) Hey Mickey! In fact we planned to ship you one :) So the next one we will produce is yours. We should keep in touch regarding shipping information and later the API. Cheers Michele Splendid! Thanks :) Cheers, Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Status of GSM base station positioning services clients
Yeah, unfortunately we didn't hear much of any of these projects. With the progress in FSO2, I definitely want native support for at least one of these, i.e. both for uploading newly found cells and also as 1st or 2nd level geolocation provider. Onen, what's new? :) -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mdbus2 to check GSM firmware version in latest SHR-u
Am Sonntag, den 09.05.2010, 19:46 +0200 schrieb Jan Girlich:
Hi,
in preparation for checking out android I wanted to see what my GSM
firmware version is as described on this page:
http://wiki.openmoko.org/wiki/GSM/Flashing
Unfortunately I'm not familiar with mdbus2 and FSO and don't know what
to do about this:
r...@om-gta02 ~ # mdbus2 -s
org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device
org.freesmartphone.GSM.Device.GetInfo
[ERR]: No method org.freesmartphone.GSM.Device.GetInfo found
at /org/freesmartphone/GSM/Device for org.freesmartphone.ogsmd
I guess it got restructured. But how do I find the new GetInfo
equivalent?
mic...@saphir:~$ mdbus2 -s
org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device
org.freesmartphone.Info.GetInfo
( { revision: GSM:
gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko11, imei:
354651011601806, model: Neo1973 GTA01/GTA02 Embedded GSM Modem,
manufacturer: FIC/OpenMoko } )
Hint: mdbus2 -s org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device
would have told you ;)
--
:M:
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [pkg-fso-maint] [debian] recent navit packages?
Am Montag, den 10.05.2010, 02:26 +0300 schrieb Timo Juhani Lindfors: Gilles Filippini p...@debian.org writes: I hope to upload one in a few days. But I'm currently busy making ogpsd a gpsd client. It takes me quite some time, /me being a python noobs :D I've something functional since today. Time to refactor / polish... Hmm, isn't upstream rewriting ogpsd in vala? Yes, eventually FSO 2.0 will all be in Vala - C. As a matter of fact, fsotdld (Time, Date, Location Daemon) is already working, but has little support for GPS. After the drama with gpsd and gypsy, I did not decide yet how to move on with GPS, either roll an own -- this time a something that really feels like D-Bus -- API or integrate one of the existing solutions. Time will tell. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ANN][SHR][Debian] New Emacs interface for FSO
Paul, that's purely amazing. iPhoners and Androids, do that! :D Could you provide some screenshots? I'd love to add this to the forthcoming section of 'Show Cases' on the new FSO website. Great work! -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on LinuxTag, Berlin
Christoph, will you be there in person? Would love to say hi. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: libmokoui2
Am Mittwoch, den 16.06.2010, 23:56 +0700 schrieb Chuck Norris: Hi, all! I'm writing transparent fullscreen keyboard in gtk. So I need finger scroll control for some windows. I googled moko-finger-scroll widget but I cannot find something like official site of libmokoui2... Maybe anybody here know where I can get last sources of libmokoui2? http://svn.openmoko.org/trunk/src/target/OM-2007.2/libraries/libmokoui2/ Is kinetic scrolling _still_ missing in Gtk+? -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FoxtrotGPS 0.99.4 available (also: looking forward...)
Congrats! -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
I don't know if my mail client uses these paramters - but it does not have an option to do line wrapping when sending. Indeed. That's the one thing I really hate when using Mail.app. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yocto for Openmoko?
Am Samstag, den 30.10.2010, 13:15 +0400 schrieb Nikita V. Youshchenko: Just saw the announcement on lwn.net for the Yocto Project. This aims to create a standard build system for embedded systems. Sounds like it might be an interesting way to build for the FreeRunner. Of course it also sound like 'yet-another-build-system' tool. Just wanted to high-lite this to the various people building various distros and hear their feedback on what this might, or might not offer for simplifying builds for the FreeRunner. Cheers, and let the flames ignite (-= Isn't that Yocto based on the same OpenEmbedded as current build system for several distros is? Yes, it is. Although it might contain some higher-level shells that could simplify dealing with the actual build process. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [gta04-devel] Fwd: FOSDEM 2011 Devroom on SHR/FSO declined
Am Sonntag, den 31.10.2010, 10:48 +0100 schrieb David Lanzendörfer: Seems as we lost our devroom after all. Not surprising. That we got it last year was an exception thanks to Xorg not being able to fill in their slot. Unfortunately FOSDEM organizers fail to realize the importance of mobile technologies, hence desktop stuff is still set and obviously if you had a room for 'n' years, you will have it every year. *sigh* Sadly our project is still to small to get a room or so. Dunno. Mickey? Nikolaus? Do you wanna hold your presentation after all? Not me. A lightning talk about the state of FSO on foreign hardware makes no sense to me and the program of the embedded room seems to be fixed to buildsystems, C libraries, and kernel tweakings for years now. :M: ___ 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
FWIW, let me state that I fully support this project and will do my share to add FSO support once the necessary dependencies (hardware verification, kernel drivers) have been solved. This project is keeping the OM-spirit alive! Best regards, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About QtMoko future
Am Mittwoch, den 11.05.2011, 21:06 +0300 schrieb Timo Jyrinki: 2011/5/9 Radek Polak pson...@seznam.cz: qtopia = qt extended = qt extended improved = QtMoko ... From technical point of view QtMoko is using regular Qt as framework for GUI, networking and other nice features that Qt supports. Qt is just compiled with custom configure switches. We can upgrade Qt from upstream and receive new Qt features quite easily. Great to hear that! I obviously thought Qt Exte... QtMoko is more stuck in the Qt 4.4 time than it it is in reality. Sounds pretty great, maybe actually at some point QtMoko or some part of it could be pushed back to upstream as part of the ongoing improvements in the Open Governance model :) Especially if there is something that would help maintaining QtMoko in the longer term. For what it's worth... a bunch of folks and me have just started working on a new featurephone-client (expect a formal announcement later this week) which is going to use QML, so we can perhaps share some Qt code. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Aurora
NOTE: Cross-posted to three mailing lists, please keep it that way, if you want to reply. Dear FOSS-Telephony lovers, today we want to announce something that has been brewing in our minds for quite a while and will change the way we develop the freesmartphone.org middleware. 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. AURORA The aim of Aurora is to replace zhone and zhone2 as development UIs for FSO. From the viewpoint of a middleware architect, it's essential to have clients available that use the various features of the FSO services. On the other hand though, this time we want to create something that is also suitable for day to day use. Aurora is supposed to be something we call a featurephone client – featurephones being those things we used for telephony before smartphones were invented. Aurora being a featurephone client does not necessarily mean it will never get the smartphone features Android or iOS are popular for, it rather describes our approach as being as-simple-as-possible. So for now you will not be able to install additional apps or features. Everything (you need) is part of the Aurora client. DEVELOPMENT PROCESS At the top of every application stack is the user. Pleasing him or her is the topmost priority. Technology should not stand in the way, but rather support the user. Hence, Aurora releases will be done as user milestones. For every user milestone, we will pick a number of user stories to be implemented. We will then split a user story into tasks and distribute among the contributors. SUPPORTED DEVICES We decided to only support the Palm Pre devices (Pre/Pre Plus/Pre 2) for the first to-be-released version of Aurora. More supported devices will join after the 0.1 release. This decision has been forced by the fact that we are only very few people working both on FSO and Aurora (and also on OpenEmbedded). Later on, we expect to see the OpenEZX family of devices, the Openmoko devices, the Nokia N900, and possibly also a bunch of HTC smartphones supported. TECHNOLOGY 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 smaller systems, such as the OpenEZX family of devices (48MB RAM, no GFX acceleration, etc.) For the first release we will only provide Qt/Embedded based images for the Palm Pre devices; those flashable images will be based on OpenEmbedded, however we'd welcome people taking care of creating releases based on Debian, Gentoo, etc. THE CODE At the moment, there is not much to look at, but feel free to download the current status via git.freesmartphone.org - aurora. HOW TO HELP 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. There are two possibilities to make us aware of you: - IRC: irc.freenode.net; channel: #openmoko-cdevel - Mail: smartphones-userl...@linuxtogo.org Thanks for your attention, Mickey Morphis. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
Am Freitag, den 20.05.2011, 19:57 +0200 schrieb Enrico Zini: On Mon, May 16, 2011 at 06:02:58PM +0200, Michael 'Mickey' Lauer wrote: SUPPORTED DEVICES We decided to only support the Palm Pre devices (Pre/Pre Plus/Pre 2) for the first to-be-released version of Aurora. More supported devices will join after the 0.1 release. This decision has been forced by the fact that we are only very few people working both on FSO and Aurora (and also on OpenEmbedded). Later on, we expect to see the OpenEZX family of devices, the Openmoko devices, the Nokia N900, and possibly also a bunch of HTC smartphones supported. Thank you for the announcement, it sounds nice. This bit made me wonder, though: why must each different platform require a separate effort? Is there something in FSO which works differently on different kinds of phones? Yes, unfortunately... but that's due to the nature of being a middleware. Middleware is an abstraction layer on top of the hardware which shields the applications from the underlying differences. That means while FSO provides always the same interface to the applications, the hard and daunting task is to cope with the device specifics and make them disappear. FSO has to deal with varying kernel-level interfaces, such as to audio routing, GSM modem, accelerometers, LEDs, buttons, peripheral control... to name just a few. Although we have seen a welcome level of standardization via kernel class devices in the past years, there are still too many home-grown vendor solutions and interfaces developed out of the kernel tree. All those we (FSO) have to adapt to provide a unified experience to the application level. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
Although we have seen a welcome level of standardization via kernel class devices in the past years, there are still too many home-grown vendor solutions and interfaces developed out of the kernel tree. All those we (FSO) have to adapt to provide a unified experience to the application level. And to expand on that... some of those device specifics have to be reverse engineered. As a scaring prime example: In September 2009, we launched the 'FSO on Palm Pre' challenge, trying to get a GSM voice call running within one month. Boy, how did we fail :) It took us (or rather 'Morphis, our hero') the better part of 12 months to get a proof of concept done. Even today, almost 20 months after we started working on the Pre, we don't have full coverage, e.g. we just started to work on SMS, and GPS is also still lacking. Our friends over @ HTC-Linux can sing many songs on that as well. And our friends from OpenEZX can tell a story as well... it has been 6 years now since the A780 has been introduced with Linux 2.4. Guess what, it's still not fully supported in kernel 2.6, i.e. no ALSA, no GPRS, no GPS. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko and FSO
Excellent progress, Radek. Thanks, Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
