Re: Some feedback from using the neo as a phone for a day
I noticed that too. Maybe the panel applets process needs to run under a supervisor that will restart it? Nah, they (or one of them, since I think it's one application) should simply not crash. Supervisors add complexity that I do not desire. I beg to disagree. It's impossible to be absolutely sure it won't crash, since we're open to users installing random stuff there. And I think the complexity of a supervisor is at least trivial. Making sure the phone never becomes partially unusable is much more important to me than the tiny difference in complexity a supervisor would add. ironyThat must be why we have supervisors for complex beasts such as the kernel and a shell./irony Looking at it another way, the matchbox thing that crashes *is* the supervisor. The current crashes should be solved. They should not be hidden. Future crashes should not be hidden, either. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some ideas for the accelerometer
But not while walking... Differentiating between motions and situations will be a big challenge. Once my Neo knows how I walk, it can detect that I am walking and subtract the walking pattern from the accelero data. Remaining data contains noise from walking (hopefully noisy enough to go undetected) and other signals (including signals with lower amplitude than the walking pattern). Should be workable, though there may be funny effects when I start or stop walking :) Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some feedback from using the neo as a phone for a day
- The dialer application has the hangup button on the top right of the screen when in a call. When you actually talk on the phone it's _really_ easy to touch that part of the screen with your face, which results in 3-4 accidental hangups per call. Oops. :-) - The status icons on the top tend to disappear once in a while. Sometimes a reboot gets them back. Sometimes it doesn't. But usually two or three reboots get them back. Very perplexing. :) I noticed that too. Maybe the panel applets process needs to run under a supervisor that will restart it? Nah, they (or one of them, since I think it's one application) should simply not crash. Supervisors add complexity that I do not desire. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dev mess
Is dropbear broken for other people updating their OM dev env? There are thousands of recipes in OE and occasionally a change does break things. However, I rebuild my environment most days and haven't had the problems you describe. Thanks. I've to install the dev env on a second laptop anyhow, so I'll just move it higher on my prio list. Done. Has dropbear symlinks. ttf-fonts/ttf-liberation had very funky problems, though. It tried to download some fonts from https://www.angstrom-distribution.org/unstable/sources/liberation-fonts-ttf-3.tar.gz but it says in the bitbake file (SRC_URI): https://www.redhat.com/f/fonts/liberation-fonts-ttf-3.tar.gz yet if I replace that by http://www.redhat.com/f/fonts/liberation-fonts-ttf-3.tar.gz (without S, thanks ScaredyCat) it successfully downloads http://downloads.openmoko.org/sources/liberation-fonts-ttf-3.tar.gz Needless to say, I'm baffled. When I had problems with gsmd it would lock the entire phone but it wouldn't print anything out as far as I know. The following bug report might be of some help: http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=788 You bet! Some of these things sound familiar. Good enough to try to fix my problems. Taking the console=ttySAC0 out of the bootargs allows me to restart gsmd. Especially the symptom of halting after a few seconds was recognizable. The real solution seems close, too, from what I read in the follow-up on bug 788 from yesterday :) Also, for the first time the openmoko image asked me about my PIN. (either doesn't restart gsmd a handful of times on boot, or can do so safely now) So now I can start complaining about small problems, like: - gsmd does not hang up when I tell the Dialer to (at least when the other side hasn't picked up, yet) this can easily be seen with libgsmd-tool - when there's no SIM, gsm applet keeps telling me that the phone is connected to the network. Every ten seconds or so. - when there is a SIM, no applets whatsoever. Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dev mess
Thanks for you answers, they're helpful. Is dropbear broken for other people updating their OM dev env? There are thousands of recipes in OE and occasionally a change does break things. However, I rebuild my environment most days and haven't had the problems you describe. Thanks. I've to install the dev env on a second laptop anyhow, so I'll just move it higher on my prio list. Could you describe the problems with libgsmd and gsmd in a bit more detail? If you find the Neo1973 is completely locking up, then it is likely your Neo1973 is set up to multiplex the gsm and serial port. This can be disabled by editing a parameter in u-boot. After using libgsmd on gsmd for a bit, something starts spitting out lots of P[ or something like it. Fills the console of the Neo easily. Then it stops spitting. Neo locks up, reboot necessary. Spitting of stuff happens, without me using libgsmd or gsmd, even with symlinks in /etc/rc*.d removed. Succeful booting becomes impossible, I do not get an ssh connection going anymore. Neo might be locked at that point, but I can not verify that. Reinstall needed. A reinstall shouldn't be needed after a software error, unless you were upgrading. If you have an old version of u-boot it may be worth checking that you ran 'nand erase rootfs' before flashing the rootfs. Yes, I ran `nand erase rootfs` every time :) When I had problems with gsmd it would lock the entire phone but it wouldn't print anything out as far as I know. The following bug report might be of some help: http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=788 You bet! Some of these things sound familiar. Good enough to try to fix my problems. Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
dev mess
Hi. Updated OE/OM with MokoMakefile a few times. - dropbear has no /etc/rc*.d/ links anymore There is a postinst script, tho - matchbox-window-manager does not get linked w/ update-alternatives - libmatchbox is gone So I have no X. Together, I had an image in qemu that showed me a progressbar that stopped and I had no way of accessing the image. So I had to remove psplash. When I removed psplash from various RDEPENDS, the Makefile happily kept rebuilding and including it. Until I removed task-openmoko a bit too rough after which it complained it could not find task-openmoko-* (which is correct since the ipkgs were gone; why not try to recreate those ipkgs and (thus) give me a nice warning about what I should do?) Are there some timestamps in use when building things, instead of looking at the things? Which things are replaced by timestamps? Where are the docs or testing scripts for this? Finally, I created an image again, which I can look into. That's when I could see the errors at the start of my post. The big Q for me is, Did I Bork my DevEnv thoroughly enough, such that I must reinstall? Or should I keep trying `bitbake -c rebuild *` until things work again? like for webkit, which I never even touched myself :( [No, it's working fine] That's not my definition of fine. Where should I send the series of bugreports on dropbear and matchbox, then? [Yes, you borked it] How the *** do I prevent that next time?!? Finally, `make flash-qemu-local` fails about 90% of the time on timeouts. If I do not kill the qemu by hand, I can keep trying indefinitely. I handcrafted a few build/qemu/openmoko/flash-*sh files with parts of flash.sh to be faster. That's not how a dev env is supposed to work. The most_recent script using python is ab-so-lutely wrong. It has no clue what most recent constitutes. Is it the -ipkg- insertion? The Sep/Oct ordering? Why doesn't it look at the 2007mmdd part? or the mtime of the rootfs? I can't read the python, it's too perlish. Am I the only one using `make flash-qemu-local` this month? Bye, Kero. PS: I'm getting tired of this. libgsmd/tool destroys my August image after a bit of messing. I can not use the current state of libgsmd since there's no dbus inside it. I can not run fresh images since the dev env isn't quite what I want it to be (tho I suppose I can work on some low-level things without X. Working without dropbear/ssh is virtually impossible, especially when there's no X(term) to start it from. You got the ruby packages and gtk2+glade2 bindings from me, but they're not in bitbake format; do you expect me to be able to wrap things in bitbake if my dev env runs the risk of getting borked any minute? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dev mess
First off, perhaps you can explain a bit more about what you are trying to achieve with your set up. There are pre-built images available from buildhost.openmoko.org. As a developer, I want to be able to extend and add software to OpenMoko. Afaik this can be done wih separate ipkgs, as well as building your own image. For reasons of accepting my additions and changes, I think I'll need the second, eventually. Creating ipkgs is smoother when using bitbake in the local part of the OE tree, too. All the rest is a consequence of that desire. Things just break. They shouldn't, imho, but they do. So, on a reasonably fresh update (today, as well as last Thu evening) both dropbear and the graphical environment are broken. Let's start with dropbear. It's simpler. Is dropbear broken for other people updating their OM dev env? Could you describe the problems with libgsmd and gsmd in a bit more detail? If you find the Neo1973 is completely locking up, then it is likely your Neo1973 is set up to multiplex the gsm and serial port. This can be disabled by editing a parameter in u-boot. After using libgsmd on gsmd for a bit, something starts spitting out lots of P[ or something like it. Fills the console of the Neo easily. Then it stops spitting. Neo locks up, reboot necessary. Spitting of stuff happens, without me using libgsmd or gsmd, even with symlinks in /etc/rc*.d removed. Succeful booting becomes impossible, I do not get an ssh connection going anymore. Neo might be locked at that point, but I can not verify that. Reinstall needed. So far, I have absolutely not been able to figure anything out. Is it the kernel? likely. Which part causes it? communication by gsmd, I'd guess. Specific communication? I need CPIN and I haven't seen a GUI app that requests a PIN code. So I guess there's only a handful of people using PIN codes. But that's going on a limb. What gets broken? Your guess is as good as mine. One last thing I might try is `ipkg upgrade` on the snapshot of OM2007.2 I do not have a debug board. Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Ruby/gtk2/glade2 bindings available for OpenMoko
Hi! On a separate feed, point your webbrowser to http://chmeee.dyndns.org/om/ruby/feed for information and instructions. I adapted my old scripts for iPAQ/familiar to create this. All those scripts you can find via the above link. At some point I (or you? :) will have to translate this into bitbake files and hook it into OE or OM. In the meantime, put the feed in your ipkg config, run `ipkg install ...` And have fun! Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Plea to developers: Make data for all applications available to scripting languages
What I would like to see is ALL programs having a way of getting at their data from a scripting language. I don't know if it makes sense to have some guidelines for developers to make it easier for this information to be got at. This would be for someone more competent than me to suggest. Quite simply, if long term storage utilises and embedded database then so long as the scripting language can access it then it will be fine. Only if the database supports concurrent access by multiple processes, which most don't. You'd be better off supporting a single standard API to obtain the obvious data such as contacts/calendar/todos (EDS being the one that I believe that the developers have settled on). Which leads to a question: is there some way to extend the information held for each EDS entity so that calendar entries contacts and the like can have additional (arbitrary) fields? Underneath eds, there's VCARD, rfc 2426, http://www.ietf.org/rfc/rfc2426.txt It's an ancient-looking format that everybody is using. As messy as it it, I have little doubt that OpenMoko will keep using it. In various places, the TYPE can handle only a few values. So for instance, a person can have a Delivery Address for home, work, but none other. a non-delivery address does not exist, as far as I can see (so I bet ADR, the delivery address, gets abused a lot). A limit of two addresses for a contacts is... so low, I have a feeling I must be missing something. Evolution has an 'other' address, for instance, but I can not find that in the RFC. You can specify X-OPENMOKO-SOMETHING lines, which I guess would work, i.e. we can have our local openmoko app show the values, but will be ignored by Evolution (i.e. not shown, yet retained) if you transfer your data. I am tempted to dump my own data in lines like that, until I find a better solution. There's a whole series of X-EVOLUTION-* lines in vcards exported by evolution, too. The related calender format is iCal, rfc 2445. Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ruby for OpenMoko - got it small
So what do you think guys? Shall I keep going and trying to get it smaller and faster or shall I abandon this and spend my time on something more useful. I for one am very much interested and grateful for your efforts. Having used Ruby as my main programming language for all development work (thus, not only for scripting) for more than two years now, I consider the existence of a carefully optimized ruby engine for openmoko as a very important piece of the puzzle. If, thanks to your work, the ruby interpreter were to find a little corner in the default OM distribution, that would be a key selling point for me. I dug up some of my iPAQ-time scripts and cross compiled ruby 1.8.6 I must say, OE does provide a lot of .h and .so files in only a few places, which makes this an easy-enough task. I measure footprint on the jffs2 image. My ipkgs together are less than 2 MB. Uncompressed, I do not so much care. For your convenience: http://chmeee.dyndns.org/om/ruby/feed/ keep in mind some of those won't work. Openssl bindings are empty, for instance, which I will not change since dropbear is installed by default. Tk is not even provided. Installing readline does not work, same reason. Forcing an install of irb, will make irb work. Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: External Handler Proof of Concept
I'll think about the extension concept a bit more. The fact that you chose
a scenario to modify a phone number is interesting. How about calling a
person from a Contact? and then choosing VoIP or GSM by those extensions?
(specifically, I do not think gsmd is the place where the call should
originate, in the image you have on the Wiki).
[snip reason]
That said, I agree that you would probably want to put another (similar)
extension method in to the dialer. If you had such a method in the dialer
then it could tell the dialer to initiate VoIP rather than GSM, in which
case the GSM extension method would never be called as you wouldn't go down
that codepath. The more extension calls we have the more flexibility we
have, although there is a balance between having them everywhere with
no-one knowing to which one they should attach their extension and having
them in very few places thus limiting the ability to extend the base
product.
Indeed, we'll need more than one place to hook in, but not too many places.
Something I thought of, the application (or whatever) that might want to
register an extension need not be started yet. After all, DBus is capable
of starting applications (and I'm sure Contacts, Agenda and a few more
will be in the nearby future).
So at least for choosing VoIP or GSM, the system-dbus must tell what's
available and Contacts must tell how we can reach the person at all.
I think *calling* Contacts is more suitable than letting it register an
extension, for this case.
What do you think?
In terms of bindings, what I really need to do is put together the D-Bus
methods to register/unregister an extension and for the extension handler
to call the extensions dynamically. At that stage you'll be able to
integrate your Ruby code very easily. I'll give it a crack over the next
couple of days and see what I can put together. Watch this space, as they
say...
Same here, polished my code, you can now use it like in the two little
attachments. It's not as clean as Ruby can be, yet, but it's rather close
now. I'm also happy to have freedesktop.* in a separate file, now.
I bet I can
ext_handler = DBus.proxy.new(org.openmoko.ef.eh.Gsmd,
/org/openmoko/ef/eh/Gsmd/, org.openmoko.ef.eh.Gsmd)
ext_handler.call(method, sig, arg0, arg1, ...)
already :)
update on http://chmeee.dyndns.org/git/?p=dbus/.git;a=summary
Bye,
Kero.
require 'dbus/connection'
# become GSMD
DBus.freedesktop.demand_name(org.openmoko.GSMD)
# We'll be wanting to look in the Contacts, make a proxy (dbus terminology)
contacts = DBus::Proxy.new(DBus.session, org.openmoko.Contacts,
/org/openmoko/Contacts, org.openmoko.Contacts)
counter = 0
loop {
counter += 1
phone_number = (1024_000+counter).to_s
# pretend there is an incoming call
DBus.session.emit(org.openmoko.Call, Incoming, s, phone_number)
# Look up the caller ID in the Contacts
p contacts.call(WhoIs, s, phone_number)
sleep 1
}
require 'dbus/match_rules'
DBus.freedesktop.demand_name(org.openmoko.Contacts)
DBus.session.listen_for(DBus::Interface=org.openmoko.Call,
DBus::Member=Incoming) {|msg|
puts Incoming call from #{msg.body} !
}
DBus.session.publish_method(org.openmoko.Contacts, WhoIs) {|msg|
DBus.session.reply_to(msg, s, John)
}
sleep 1234567890
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: External Handler Proof of Concept
I was playing around with the extensions framework (http://wiki.openmoko.org/wiki/Wishlist:Extension_Framework) over the weekend and have put together a proof of concept for the idea. The packages are not currently designed to run on the openmoko or integrate with the build process but on a standard linux distribution (until I get a 'phone, anyway). The distribution consists of three separate packages: * openmoko-extensionhandler - receives extension requests and passes them through the chain of extensions registered for that request * openmoko-extension-sample - sample extension that changes the parameters of an outgoing call * fakegsmd - simple client that generates an extension request for an outgoing call (as would be expected to be generated by gsmd) [snip] Anyway, if people would like to take a look at this it is available at http://www.devzero.net/openmoko/dist/omext.tar.gz - please give it a go and let me know what you think. Compiles, works. Probably a nice idea to see if I can get my Ruby code to talk to yours :) Ah, ListNames spots [org.freedesktop.DBus, org.openmoko.ef.eh.Gsmd, :1.17, :1.18] so I guess that should be easy enough :) And I'm trying to do the equivalent of this in Ruby, but failing: /* Start repeat for each handler */ obj = g_object_new (EXTENSIONHANDLERGSMD_TYPE, NULL); dbus_g_connection_register_g_object (connection, EXTENSIONHANDLERGSMD_PATH, obj); (NB: there's nothing repeating there. adapt comment, pls) I'll use dbus-monitor on your code and learn :) I'll think about the extension concept a bit more. The fact that you chose a scenario to modify a phone number is interesting. How about calling a person from a Contact? and then choosing VoIP or GSM by those extensions? (specifically, I do not think gsmd is the place where the call should originate, in the image you have on the Wiki). That is it for now, Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 36, Issue 45
Is that searchable? Is it threaded? Will there be someone on 24/7 that is knowledgable and helpful? I understand that some people love IRC and mailing lists. But users expect to search and ask questions in a forum, not on a mailing list and IRC. I think it's about time for some forums. Funny, I expect to ask questions at IRC and search archives. and I expect messages to be archived indefinitely, as a mailing list does (I've seen many forums that don't, unless you mark sticky...) Besides, the usabilty of those forums is very clunky compared to a decent email client. And if you want a webpage for these things? Use gmail. Now, if you like the subforums feature of forums, perhaps the conclusion would be that we need more mailing lists. Atm, I doubt that. What would be bad is to start a forum with the same scope next to an existing mailing list, so we would have two places to search for the same thing. Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
1) How would you put that in an engine? Where does all the relevant info come from? 2) Then build aan interface to allow an end-user to create such rules. 3) And finally do something trivial with dbus, commandline (or even XML...) to play the appropriate ringtone. and show an Pickup/Cancel pair of buttons. there was some talk about this back in january or so... it got even more involved than that: if the addressbook says I'm supposed to be sleeping, but the lights are on (maybe later we'll have an ambient light sensor) there's lots of noise, the GPS shows I'm at a club, and the accelerometers detect movement (those are going to be so cool) I'm probably not sleeping, go ahead and ring (is it too tacky to list attendees for sleeping maybe you don't want it to ring, but anyways) Fun, I'll dig in the archives :) the talk kind of centered around a nodeset somewhere in the filesystem, but from what I've seen on dbus that might be a better solution. basically, you create a group of modules, each of which is queried for a result... then each contact is matched against a set of rules based on the set of results. A module / rule hierarchy. Would that fit the exception-on-exception kind of rules we've been mentioning? I guess it could/ on call importance, you can also list call frequency for the contact (I.E. if john calls me 3 times in 5 minutes, it's probably something important... ring on the third attempt) oh, greylisting :) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
If the monolithic approach is out then some sort of modular approach is required. The most obvious example out there today is Firefox, which comes in a relatively simple base configuration but provides any number of hooks to allow people to write their own extensions on top of the base code and as such to alter the functionality of the product very extensively. If we want this openmoko to be as free as possible then it also needs to be as easy as possible for people to extend, and this is the most likely way of doing it. I know that there are a lot of potential problems that need to be addressed when building this out but if there is a vision from the start as to how this would work then it would go a long way to making the final product the 'phone that we are all dreaming of, regardless of the fact that those dreams are often divergent from others if not totally exclusive. So my questions are there plans to include these hooks, and if not can it be considered? Or is there another way to do this other than hooks? You have to modularise and split the applications into interface and the engine code as much as possible. If clever enough you could even define the interface layout using definition files in XML or some other trendy file format :) There's definitely two interfaces here. One that sets up the rules/filters to let certain things happen (John gets this ringtone, Basil shall be ignored) and one that lets those things actually happen. The last interface is dead simple compared to the first. The engine consists of the rules. That engine is terribly complex. I need my agenda, to see I have a meeting, so my phone will not accept calls. However, it needs my phonebook, to see whether one of my colleagues calls me, who *should* be in the meeting, I better take that call after all. agenda and addressbook are available via dbus already. No point in implementing another interface there. Now, depending on circumstances, your Social Other, a parent or child who needs to see a doctor, your bank/mortgage or person that arranges something big for you may need to drag you out of your meeting. Some or most meetings. Probably not all (discussing a raise with your boss, perhaps?) 1) How would you put that in an engine? Where does all the relevant info come from? 2) Then build aan interface to allow an end-user to create such rules. 3) And finally do something trivial with dbus, commandline (or even XML...) to play the appropriate ringtone. and show an Pickup/Cancel pair of buttons. I know that the Home page on Windows Mobile Smartphone edition is just an XML file which can contain links to plugins. That's the easy part, really... Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: A little bad press? OpenMoko already facing difficulties?
I agree no one should panic. But the guys at openmoko should take their blogs more seriously and stop putting frustrations. remember alot of eyes are upon them these days. they should put their best foot up front. (i think thats how it goes ;)) and look more professional to be taken seriously. Open is just that, open. Be open about your human side, too. If journalists and corporate drones refuse to accept emotions in a team like for OpenMoko/Neo1973, which for many practical purposes is like a very stressfull start-up, well. Ignore the journalists and corporate drones. After all, Linus stopped working on kernel, too: http://www.thejemreport.com/mambo/content/view/320 Moral of the story: do not adapt your best practices because someone might misinterpret them. A blog entry is not a press release. Kind regards, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
