Re: qtmoko and FSO
Excellent progress, Radek. Thanks, Mickey. ___ 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
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: 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
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: [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: 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: 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: 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: 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: 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: [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: [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: 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: 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: 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: 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: 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: [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: 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: 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: [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: Thone 0.5
Amazing stuff, congrats! -- :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: 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: 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: [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: 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/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: [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: 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: [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: 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: 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
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: [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
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: SHR unresponsiveness
What is [h]top telling? :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-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: 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] 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: 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: 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: [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: org.freesmartphone.Device.Orientation
Am Donnerstag, den 12.11.2009, 08:48 +0100 schrieb Patryk Benderz: Dnia 2009-09-10, czw o godzinie 00:10 +0200, Michael 'Mickey' Lauer pisze: is now working in the first version. Here's an example output of mdbus -s -l where I have (orientation status in brackets): [cut] Great job Mickey, but what about integer orientation codes which were discussed previously? These are much easier to use, easier to compare integer than some long string. Please take a look other dbus APIs. The general consensus these days is that enums are pretty much frowned upon, since a) dbus marshalling is adding overhead anyways, and b) string constants are way better to debug and use from command line interfaces. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: org.freesmartphone.Device.Orientation
Am Mittwoch, den 11.11.2009, 09:54 +0100 schrieb Petr Vanek: On Thu, 10 Sep 2009 00:10:54 +0200 Michael 'Mickey' Lauer mic...@vanille-media.de (M'L) wrote: is now working in the first version. Here's an example output of mdbus hi, any plans to have fso based accelerator threshold settings for waking up from suspend? Yes, definitely. Please open a bug to remind me of it :) :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: org.freesmartphone.Device.Orientation
Michael 'Mickey' Lauer mic...@vanille-media.de (M'L) wrote: is now working in the first version. Here's an example output of mdbus hi, any plans to have fso based accelerator threshold settings for waking up from suspend? Yes, definitely. Please open a bug to remind me of it :) Heya, this is great. will do. Has anyone tried it? The maximum 8g might be still a bit too sensitive while normal bumping occures, but perhaps it is OK? Well, 4G already is quite a whack, 8G should really be ok :) :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Am Sonntag, den 08.11.2009, 14:39 +1100 schrieb Carsten Haitzler: so to me - it makes perfect sense for such a desired state to be put into the x domain entirely as the property is related directly to the display/screen. gsm makes no sense being properties/events of x11. neither does wifi, or bt but brightness of screen, current abient lighting sensor data, etc. makes sense. as such x also covers input devices (kbd, mouse), thus anything you can deem to be an input device (touchscreen, buttons on the device, accelerometrs etc.) makes sense to put via x11, not dbus. its within the logical domain for its functionality. In the light of more versatile use I prefer this to be via dbus, but I'd absolutely welcome an fsodeviced plugin that sets an atom on the root window. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Am Mittwoch, den 28.10.2009, 09:36 -0400 schrieb Ken Young: Personally, I wish OM had stayed with the UI they had in 2007.1. That's right, 2007.1 - the first version, which had no kinetic scrolling. There was never any chance that OM would produce a phone with graphics as smooth and fancy as what a high-volume smart phone has. You have a very valid points here. We certainly did some strategic mistakes here -- me included, since I did not realize the awesomeness and importance of dbus early enough... it's not too late though for us (as in the community) to fix this. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Am Freitag, den 30.10.2009, 16:36 +0100 schrieb ri...@happyleptic.org: You have a very valid points here. We certainly did some strategic mistakes here -- me included, since I did not realize the awesomeness and importance of dbus early enough... How lucky you are ! I still wonder why dbus was invented in the first place :-) Hehe, coming from a strong background in CORBA on one hand, but pure bare-metal unix domain socket IPC on the other hand, I have to admit that while dbus lacks a lot, it * (pretty much) ends the horror of proprietary IPC protocols, thus * enabling interconnecting components, hence * bringing interoperability. * It also comes with an interactive scripting console (read: Python). And that's what I'm all glad for. But now we went really off topic considering the original thread :) :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
Am Mittwoch, den 28.10.2009, 12:58 +0100 schrieb Julien Cassignol: Hey there, Bearstech (through me and others) would like to be there to talk about hackable:1 and our forthcoming initiative about open hardware. Excellent. Plus, I'd also like to be there to talk a bit about SHR/FSO, as well as drink some beers (Mickey, you owe me one!) :-) For sure! :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
Great idea, an Openmoko community-managed table or devroom would be a strong reason for me to come this year, so +1 from my side! If it's going to be a devroom, I would offer a presentation on FSO: Origins, Status, and Future. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openBmap-locator (was Re: Ericsson releases free cell-id lookup API)
Is there already a way to trick ogpsd into using the openbmap-locator dbus interface? or is that still future research/improvement? Not that I know of. I managed to use a configuration for fso-gpsd to use openbmap-locator but there is nothing that can merge the two signals and use the better one that is available. I think it's time to either start using geoclue or add a location API in FSO that takes different location providers into account. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] DBus services and methods doc
Am Freitag, den 23.10.2009, 10:25 +0200 schrieb Mickael Labrousse: But for example I don't have any org.freesmartphone.Device when I check with mdbus but I have org.freesmartphone.odeviced... org.freesmartphone.Device is an interface, while org.freesmartphone.odeviced is a bus name (service provider). What is documented in docs.freesmartphone.org are the interfaces, since it is application dependent which service provider creates which objects at which path offering the (documented) interfaces. You can use introspection (e.g. via mdbus) to find out where these objects live. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-rework service available
Am Freitag, den 23.10.2009, 12:39 +0200 schrieb Yorick Moko: thanks for offering this service! (although too bad I already sent my device once to Germany) can you give us an indication on how much this would improve batterylife? I'm assuming it only extends standby-time. I once saw a graph that indicated that it was a huge boost, but can't find it anymore In optimal conditions, it's going to double your standby time from ~70h to ~140h. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
Framework not being able to open a new channel means fso-abyss is not able to register a channel with the multiplexer. That it only works 4 out of 5 times sounds like a race condition. Do you have anything else installed that could compete with fso-abyss over the GSM resource? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
Am Montag, den 19.10.2009, 12:46 +0200 schrieb Petr Vanek: On Mon, 19 Oct 2009 01:50:51 -0400 David Ford da...@blue-labs.org (DF) wrote: actually i was vague/misleading in what i wrote. what i would like to see is for the end user to be notified in a friendly fashion. like injecting a service message into opimd/sms buffer sounds like a good communication method for the future :), if the devs like it :)) I'm open for it. I find sending a dbus signal somewhat less intrusive though... :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian/fso] zhone+fso-abyss: some log snippets
Am Montag, den 19.10.2009, 16:13 +0200 schrieb arne anka: but apparently the gsm resource is not resumed accordingly when resuming the fr: [...] who is responsible for resuming the resources? fsousaged. Apparantly something gets wrong along the code path. Please give me a link to the very image you have been testing this with, so I can try to reproduce this problem. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
Hi, I get messages like [2009-10-18 07:51:27.107655] Signal : cid=4E91, lac=006A [2009-10-18 07:52:45.145288] Signal : cid=4E7B, lac=006A [2009-10-18 07:53:18.218122] Signal : cid=4E91, lac=006A ... So I guess my #1024 is not fixed :-( The three lines you quoted are not showing #1024. Again, frequent cell _handovers_ are perfectly normal. #1024 is about dropping out of a cell, then recamping into it, e.g. it looks like that: [2009-10-18 07:51:27.107655] Signal : cid=4E91, lac=006A [2009-10-18 07:52:45.145288] Signal : cid=4E91, lac=006A [2009-10-18 07:53:18.218122] Signal : cid=4E91, lac=006A (NB: This compact debug output form is not optimal for recognizing #1024 anyways, you should rather watch for CSQ and CREG messages. If CSQ suddenly drops to 99 and you get thrown out of the cell, then it's 100% clear you have #1024). :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
How about this output: [2009-10-18 13:37:02.701925] Signal : cid=9E4A, lac=17A2 [2009-10-18 13:37:26.813505] Signal : cid=7149, lac=17A2 [2009-10-18 13:41:22.576405] Signal : cid=9E4A, lac=17A2 [2009-10-18 13:45:48.512750] Signal : cid=7149, lac=17A2 [2009-10-18 13:49:10.453532] Signal : cid=9E4A, lac=17A2 No recamping either, just handovers. If there is a better way - script of determining whether the 1024 has been dealt with correctly, it would be helpful... Yes, just use frameworkd with ti_calypso_sleep_mode = 'adaptive' and inspect the logs. Frameworkd will tell you, when a real recamping exists. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso-abyss docs anywhere? (Was: GSM errors after 1024 fix)
http://www.freesmartphone.org/index.php/Implementations/fso-abyss. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: voice calls with 3G USB dongle
Am Mittwoch, den 14.10.2009, 18:55 -0500 schrieb Eric Olson: I was wondering about those details too. If it works, perhaps FSO could consider adding support for the huawei E169 or similar 3G modems :D Absolutely, in fact, chances are it'll already work with the singleline abstraction. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM errors after 1024 fix
Am Donnerstag, den 15.10.2009, 12:48 +0200 schrieb arne anka: try the other muxer, gsmwhatsitsname, instead. to me it seems, fso-abyss has detoriated into almost unusability over the last months. Wow, that'd be quite an achiement considering that I didn't do any development on it. Note that it still works flawlessly here. Perhaps software these days starts to rot, just as organic material ;) :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Off Topic (was: Re: WikiReader)
Am Donnerstag, den 15.10.2009, 16:01 +0300 schrieb Risto H. Kurppa: On Thu, Oct 15, 2009 at 2:35 PM, Niels Heyvaert nielsheyva...@hotmail.com wrote: Yes it's a openmoko community list so both products can be discussed. Stric= tly speaking you're 100% correct. However=2C it would make a lot more sense= to have separate lists for the FR and the WikiReader. =20 - Not everybody interested in the FR is also interested in the Wikireader a= nd vice versa. - Given the traffic we already have on the list=2C adding another topic cou= ld render the list useless. I do agree that not everyone are interested in both products, but given the traffic we have, now that om2009 is not existing discussed, SHR is discussed on other mailing lists so it's mostly qt/QT/Qt/similar discussion, I think there's still room for wikireader threads here :) (to me it looks like that the # of mails on -community list has went down a lot). But however, it's Openmoko Inc who makes the decisions. I disagree, it's our choice. These days this mailing list is now bein operated by the community for the community. We chose what is on topic and what not. As for the case of the wikireader, why not make a poll and let all decide whether it's welcome to discuss here or not? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Off Topic (was: Re: WikiReader)
Sure, no point in rushing things. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Xfbdev+ALSA - which phone?
Right now, the Palm Pre seems to come closest to the FreeRunner wrt. openness (albeit still miles away, of course). It has just been released in europe and work has started to port an own userland based on FSO to it. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rod Whitby (MokoMakefile author) moves on to start WebOS Internals
Hi Alan, On a related point freesmartphone.org seems to be using the old hackish 3gpp ts07.10 user space code. Correct, for systems which don't use premultiplexed drivers, we're resorting to a userland muxer (not the gsm0710muxd though, but rather a clean implementation based on other code). I'd love to see a kernel muxer, really. While I don't think it makes a difference on GPRS, it might improve system performance on EDGE or UMTS a lot. I've got almost all of a kernel driver only my AT+CMUX capable device has expired. Dunno if anyone is interested in finishing the job (its basically written but not at all debugged and I know the tx queueing needs work either to make it do all the priorities right or just forget the the whole priority nightmare) I think it'd be great if you could upload your code somewhere. Alternatively does anyone know what cheaper EU devices support AT+CMUX, it seems quite rare this side of the pond Do you no longer have an Openmoko device? If not, I could arrange to ship you one -- it may have problems, but at least the GSM would work. Best regards, Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WikiReader
Sean, let me be the first one to congratulate you. I think I know what an undertaking this project has been for you, so I'm very glad you made it. I wish you great success with this product! All the best, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: HOWTO: Sharing SHR-U GPRS to *buntu laptop
Alternatively, use org.freesmartphone.Network.StartConnectionSharingWithInterface usb0 and find a dhcp server running on the FR with everything else preconfigured. I'm having a couple of problems with this: $ mdbus -s org.freesmartphone.Network.StartConnectionSharingWithInterface usb0 Service name not found As per mdbus --help, you need a busname and an objectname before the method -- you can gather these by recursively calling mdbus -s ... and how would you turn it off again? This is not implemented yet :) Add me a ticket and I'll do it. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rod Whitby (MokoMakefile author) moves on to start WebOS Internals
Rod, thanks for all the work you did to bring Openmoko forward! Even though it took all so long due to all our detours, I'm quite satisfied with what the Openmoko community has created throughout the years, especially since Openmoko Inc. stopped guiding the project. A hardware family often is the initial trigger to establish a community, however it's important to embrace and extend, especially when the days of the hardware family are counted. As other solution come around, it gets important for the Openmoko community to widen the focus and grow into something larger. I created the freesmartphone.org project to cover a much wider scope than Openmoko -- as such, we are looking forward to continue our work on FSO covering both anti-vendor-ports and forthcoming semiopen devices such as the Palm Pre and the Nokia N900. So... good bye and hello again! See you soon, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all/fso?] external battery just mobile gum pro woes
Am Dienstag, den 22.09.2009, 15:05 +0200 schrieb Sebastian Krzyszkowiak: Charging from only 100mA explains oscillating. Check if sysfs paths in opp are up to date with your kernel. Unfortunatelly there is no dbus call in FSO for that yet. Add me a ticket and I'll do it when I'm back from holidays. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to Make Data Call in Openmoko?
Am Freitag, den 18.09.2009, 10:39 +0500 schrieb Muhammad Asif: I want to establish data call (aka CSD) between two Openmoko phones. Can anybody guide me to a starting point? Is there any Telephony API exists for Openmoko (as there is telephony library named Microsoft TAPI for Windows OS)? Hi Muhammad, the Openmoko TAPI is part of the FSO dbus middleware. Please see http://docs.freesmartphone.org and http://www.freesmartphone.org CSD handling as been implemented some months ago. If you have problems using it, ping me here, and I'll come up with an example. Good speed! Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debian first experience made a bit easier...
On Monday 14 September 2009 04:07:43 Carsten Haitzler wrote: On Sun, 13 Sep 2009 21:42:49 -0400 Stefan Monnier monn...@iro.umontreal.ca said: Or more precisely, for $DISPLAY on fso-controlled device at runtime, not installation time. I think that mess will be larger than that of having two icons, menu items or whatever the launcher makes of it, for the user to choose between. The solution is to use a scheme where the blanking code and the application use a standard protocol to sync-up. AFAIK, there is such a protocol already (which is hopefully used by all tools like VLC, Xine, mplayer, totem, at least when in fullscreen mode). So mokomaze should use it. And the FSO side should also support it. x screensaver extension. you can request x to suspend blanking until u un-suspend it (or your x connection closes - eg u exit or crash). FSO tho wants to re-invent this wheel. Bzzt. Wrong. IdleNotifier is optional as are the rules in oeventsd. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: org.freesmartphone.Device.Orientation
On Sunday 13 September 2009 16:42:14 Rui Miguel Silva Seabra wrote: Just to add that if this simple orientation is achieved, then rotation should probably be handled from FSO, from now on, instead of a separate program (like omnewrotate). Yes, that'd be good. Note though that this feature is a plugin of fsodeviced (successor to odeviced) which does not ship in any FSO-based distribution yet. I hope said distros switch to it soon, though. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dbus api for gta2 accelerometers
On Saturday 12 September 2009 09:56:08 Ivo van den Maagdenberg wrote: Anyone able to show how to read out the accelerometers through d-bus? I tried looking it up on http://wiki.openmoko.org/wiki/Dbus_device_API but did not find references to the accelerometers. What's your usecase? Since very recently, we provide http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Orientation.html;hb=HEAD Perhaps this is enough for your usecase. It's not giving you the exact data though, since this -- as Frederik also mention -- would not give any benefit over the direct reading from the input event nodes, but also come with the rather severe disadvantage of additional CPU impact. Btw., thanks for pointing at http://wiki.openmoko.org/wiki/Dbus_device_API, I have completely removed this page and what links to it. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dbus api for gta2 accelerometers
On Saturday 12 September 2009 19:50:26 Ivo van den Maagdenberg wrote: 2009/9/12 Michael 'Mickey' Lauer mic...@vanille-media.de On Saturday 12 September 2009 09:56:08 Ivo van den Maagdenberg wrote: Anyone able to show how to read out the accelerometers through d-bus? I tried looking it up on http://wiki.openmoko.org/wiki/Dbus_device_API but did not find references to the accelerometers. What's your usecase? Since very recently, we provide http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesm artphone.Device.Orientation.html;hb=HEAD The use case is as follows: take the openmoko and make it a cycleway shock measuring platform, utilizing the accelerometers. So, direct reads from the are going to be needed. Excellent, very valid usecase, but not for org.freesmartphone.Device.Orientation. As I've said multiple times, for real- time data, you better read the accelerometers by directly querying the input event nodes. I am not yet up to speed with the fso stack. Is it possible to explain why the fso direction to read out data from the accelerometers was abandoned? It was not abandoned, it has never been provided. (Ok, that's not 100% true. In fact, we had an experimental plugin for that but that consumed so much CPU time that it made the whole system crawl and was never used). :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: org.freesmartphone.Device.Orientation
On Friday 11 September 2009 11:38:58 Rui Miguel Silva Seabra wrote: On Thu, Sep 10, 2009 at 11:47:52PM +0200, Michael 'Mickey' Lauer wrote: On Thursday 10 September 2009 23:23:46 Michael 'Mickey' Lauer wrote: On Thursday 10 September 2009 20:05:44 Rui Miguel Silva Seabra wrote: What is 'held'? slightly not straight-vertical? Held is the opposite of flat, i.e. everything that deviates from holding it +-5 degrees (or so). Err, that was written in a suboptimal way. Next try: Held is the opposite of flat, i.e. everything that deviates from laying flat on the table with a tilt of +-5 degrees (or so). Is the freerunner held or flat in the following situation, then? ++ / \ | | | (freerunner, standing on side) \ / ++ - (table from side) That would be 'held'. Nice ASCII art. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: org.freesmartphone.Device.Orientation
On Thursday 10 September 2009 13:00:31 Frederik Sdun wrote: This API is only for the Orientation of the phone. Not really fot that kind of usage. Correct. It's definitely not meant for real-time-handling, e.g. right now there's a delay of 1 second between the end of the movement and before the actual orientation gets sent. This is done on purpose to keep CPU consumption under control. What we could experiment with (in addition to the delayed orientation signal) is detecting whacks, since these are characterized by a high force applied to one or two axes. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: org.freesmartphone.Device.Orientation
On Thursday 10 September 2009 20:05:44 Rui Miguel Silva Seabra wrote: What is 'held'? slightly not straight-vertical? Held is the opposite of flat, i.e. everything that deviates from holding it +-5 degrees (or so). :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: org.freesmartphone.Device.Orientation
On Thursday 10 September 2009 23:23:46 Michael 'Mickey' Lauer wrote: On Thursday 10 September 2009 20:05:44 Rui Miguel Silva Seabra wrote: What is 'held'? slightly not straight-vertical? Held is the opposite of flat, i.e. everything that deviates from holding it +-5 degrees (or so). Err, that was written in a suboptimal way. Next try: Held is the opposite of flat, i.e. everything that deviates from laying flat on the table with a tilt of +-5 degrees (or so). :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Device Orientation API
On Wednesday 09 September 2009 13:23:55 Nils Faerber wrote: Michael 'Mickey' Lauer schrieb: Hi folks, I'm sketching a simple device orientation API for FSO. The purpose is to be informed about changes in the physical device orientation. My first take is at http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesm artphone.Device.Orientation.html;hb=HEAD Basically, it's sending you a string whenever the orientation changes. Valid substrings contain portrait, landscape, faceup, facedown. Comments? Sind it will for sure be supposed to become an general interface I would suggest not to use names which can be confusing (if landscape is the native orientation it becomes messy) but rather use degrees, i.e. 45, 90, 180, 270 Which represent the number of degrees turned from native device orientation. Hmm, good point. Let me think about this. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko - screen undims every minute or so?
On Wednesday 09 September 2009 20:41:06 Torfinn Ingolfsen wrote: On Tue, Sep 8, 2009 at 11:33 PM, Radek Polak pson...@seznam.cz wrote: Torfinn Ingolfsen wrote: Hi, When my FreeRunner is connected via usb to my laptop, the screen un-dims ever minute or so. Screen dim is set to default (20 seconds?), ut every minute the screen goes back to un-dimmed again, without me doing any activity on the FreeRunner. Why does it do that? This is due to odeviced's idlenotifier not being aware of devices that are plugged in after its start. This issue is already fixed in fsodeviced which will substitute odeviced soon. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
org.freesmartphone.Device.Orientation
is now working in the first version. Here's an example output of mdbus -s -l
where I have (orientation status in brackets):
* put the Neo on to the table (flat faceup),
* took it and put it up-side-down back on the table (flat facedown),
* took it and operated it for a bit (held faceup portrait normal),
* rotated it to read some text (held faceup landscape normal),
* and put it back on the table with the display visible (flat faceup).
See also
http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Orientation.html;hb=HEAD
r...@om-gta02:/etc/opkg# mdbus -s -l
listening for signals on SystemBus from service 'all', object 'all'...
[SIGNAL]org.freesmartphone.Device.Orientation.OrientationChangedfrom
:1.47 /org/freesmartphone/Device/Orientation
('flat faceup ',)
[SIGNAL]org.freesmartphone.Device.Orientation.OrientationChangedfrom
:1.47 /org/freesmartphone/Device/Orientation
('facedown ',)
[SIGNAL]org.freesmartphone.Device.Orientation.OrientationChangedfrom
:1.47 /org/freesmartphone/Device/Orientation
('held faceup portrait normal ',)
[SIGNAL]org.freesmartphone.Device.Orientation.OrientationChangedfrom
:1.47 /org/freesmartphone/Device/Orientation
('landscape ',)
[SIGNAL]org.freesmartphone.Device.Orientation.OrientationChangedfrom
:1.47 /org/freesmartphone/Device/Orientation
('flat ',)
To play with that, you need to download install a fsodeviced from HEAD (and
all its dependencies) and activate the accelerometer plugin in
/etc/frameworkd.conf:
[fsodeviced]
log_level = DEBUG
log_to = stderr
[fsodevice]
[fsodevice.accelerometer]
device_type = lis302
movement_idle_threshold = 15
movement_busy_threshold = 100
[fsodevice.accelerometer_lis302]
inputnode = /input/event2
Note that you have to stop frameworkd for this experiments as fsodeviced is
using the same busname as odeviced (of course... it's supposed to be a drop-in
replacement soon).
I hope we'll see some cool things with that now. I for one am planning to
connect 'flat facedown' to suspend via oeventsd :)
Cheers,
:M:
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] Bluetooth (was mplayer with glamo and audio working?)
On Monday 07 September 2009 16:38:24 c_c wrote: Yup. Though I'm planning on automating it in launcher. Any idea how launcher can know if the phone has resumed from suspend? http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Usage.html;hb=HEAD#SystemAction :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Device Orientation API
Hi folks, I'm sketching a simple device orientation API for FSO. The purpose is to be informed about changes in the physical device orientation. My first take is at http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Orientation.html;hb=HEAD Basically, it's sending you a string whenever the orientation changes. Valid substrings contain portrait, landscape, faceup, facedown. Comments? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
