Re: Two finger input methods (PyGTK demos)
On 9/3/07, Henryk Plötz [EMAIL PROTECTED] wrote: Moin, Am Thu, 30 Aug 2007 20:12:00 +0200 schrieb Lars Hallberg: Both demos can easily be adjusted between 3x4 to 3x6 keys to test the feel. I don't know hove easy it is to get a PyGTK demo running on the phone... and they probably perform horribly. But I would be grateful for any report on hove easy the keys and strokes are to hit. Hmm, I just ran it on a Neo and seems to work okay. The biggest problem is that switching to the second set of displayed keys is awfully slow. Apart from that it's only missing some optimizations of the layout. (For example: Backspace absolutely needs to be a main key. Nobody needs ^ as a main key.) In order to run it on a Neo you need to install python-pygtk, python-pygobject (might need ipkg install -force-overwrite since it pulls in libc6-dev, but that's another story) and python-pycairo. The python-pygtk package should now depend on -pygobject and -pycairo and I moved the .pc file out of python-pygobject, so it shouldn't depend on libglib-2.0-dev anymore. Could you rebuild and test those three packages, please? cheers Philipp ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two finger input methods (PyGTK demos)
Henryk Plötz skrev: Moin, Hmm, I just ran it on a Neo and seems to work okay. The biggest problem is that switching to the second set of displayed keys is awfully slow. Yes... I believe it's the text rendering. dreamingWish gtk.Label had a flag 'cash_rendering' and maybe a method 'pre_render' taking a win as argument so it usable even if the label is not attached to a top level window yet/dreaming Been looking at doing it myself. But I'm a bit of a newbie on the hole thing (gtk, pango, gdk). Have not really figured out how to render according to the gtk style at use. And I'm not sure have important speed is for a demo. Apart from that it's only missing some optimizations of the layout. (For example: Backspace absolutely needs to be a main key. Backspace is important... but a main key when it is only 12 main keys? Figured space and drag back was intuitive. Nobody needs ^ as a main key.) That key, and its 'page' is meant to be user definable, and possibly app dependent... so ju can put backspace there :-) Thanks /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Ubuntu embedded/mobile
Hi, Not sure if this has been posted before, but will it be possible in the future to support the Ubuntu embedded stack on the neo? I see on the Ubuntu wiki they support the Intel's MID (Mobile Internet Device) platform - so it will need some porting. https://wiki.ubuntu.com/MobileAndEmbedded Hans E-Mail disclaimer: http://www.sunspace.co.za/emaildisclaimer.htm ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
gpsd and AGPS
Hi all, I am trying to understand how AGPS can work with gpsd daemon. In my undestanding, when I have an UMTS/GSM module and a GPS module supporting AGPS, I can retrieve Assistance Data for AGPS from UMTS/GSM. I believe this can be done through an AGPS control software running on a host processor. All this collected Data should be passed to GPS module through gpsd, I believe. At this point I'd like to understand, if it is really possible to do it through gpsd and in which way this can be done. Someone please help me to understand the way in which AGPS actually works. Thanks in advance, Luca Cabriolu ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Luca Cabriolu wrote: Hi all, I am trying to understand how AGPS can work with gpsd daemon. In my undestanding, when I have an UMTS/GSM module and a GPS module supporting AGPS, I can retrieve Assistance Data for AGPS from UMTS/GSM. I believe this can be done through an AGPS control software running on a host processor. All this collected Data should be passed to GPS module through gpsd, I believe. At this point I'd like to understand, if it is really possible to do it through gpsd and in which way this can be done. Someone please help me to understand the way in which AGPS actually works. http://en.wikipedia.org/wiki/A-GPS http://wiki.openmoko.org/wiki/Server:A-GPS AGPS is solely a marketing term. It covers several different techniques. Whatever the case - the current binary GPS solution does not support this sort of AGPS - at least according to its help info. So, you need to find out how your phone provider broadcasts the assistance data, or how it accepts information from the phone to postprocess into a position, and then find out if the TI chipset in the phone is able to download/upload this data. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
problem with vanilla-kernel-patchset
Hi all, I have some problems pushing all patches onto the vanilla Kernel (2.6.21.1). After using quilt push -a not all patches were applied. quilt produces this output: -- ... Applying patch patches/s3c_mci.patch patching file include/asm-arm/arch-s3c2410/regs-sdi.h patching file drivers/mmc/host/mmc_debug.c patching file drivers/mmc/host/mmc_debug.h patching file drivers/mmc/host/s3cmci.c patching file drivers/mmc/host/s3cmci.h can't find file to patch at input line 1578 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |Index: linux-2.6.22.1/drivers/mmc/host/Kconfig |=== |--- linux-2.6.22.1.orig/drivers/mmc/host/Kconfig 2007-07-19 01:10:43.497907574 +0200 |+++ linux-2.6.22.1/drivers/mmc/host/Kconfig2007-07-19 01:11:57.214108422 +0200 -- No file to patch. Skipping patch. 1 out of 1 hunk ignored can't find file to patch at input line 1597 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |Index: linux-2.6.22.1/drivers/mmc/host/Makefile |=== |--- linux-2.6.22.1.orig/drivers/mmc/host/Makefile 2007-07-19 01:10:43.517908714 +0200 |+++ linux-2.6.22.1/drivers/mmc/host/Makefile 2007-07-19 01:11:07.043249347 +0200 -- No file to patch. Skipping patch. 1 out of 1 hunk ignored Patch patches/s3c_mci.patch does not apply (enforce with -f) -- All patches before s3c_mci.patch seemed to work correctly. Is there anything I do wrong? The revision of the patch-series is 2898. I also tried the kernel-Version 2.6.22.3 and .5 with the same result. For me as non-experienced kernel-developer, it looks like there is a missing file... Thanks for help, Dennis ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How snappy can the Openmoko GUI get using GTK?
denis wrote: Watching a lot of videos about Openmoko and the GUI I saw that it is very slow and yards away from being snappy. (regarding the application startup and the acting inside an application) I know that speed is not the priority thing in developement at the moment but how fast and snappy can the Openmoko GUI using GTK get? I think this will improve with the new faster CPU. Seeing the difference between the Nokia 770 and the Nokia 800 (faster CPU), this will make a great difference. Especially considerung that OpenMoKo and Maemo use very much the same technology. But you are right at some point. Having a true multitasking os with memory management and the like and a display abstraction layer like X servers is completely different from dump devices like (old) palm with neither of them. *g* And as you said. The sofware is not optimised yet. I would say the device has enough horse power and most important enough RAM to run smoothly eventually. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mount the phone filesystem over USB?
On 9/3/07, Shawn Rutledge [EMAIL PROTECTED] wrote: Is anybody having success with nfs or sshfs or some other method? I installed openssh to give it a try, which seems to be installed correctly but when I try to mount it: [proton][08:30:43 PM] sshfs moko:/ /mnt/moko remote host has disconnected For this to work I think you need the openssh packages on the Neo instead of the default ssh package. For detailed instructions see http://www.rwhitby.net/blog/nslu2-linux/replacing-dropbear-with-openssh.html Hope this helps, Alessandro ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AW: omit qemu from OE build?
on gentoo try: # emerge -av 'sys-deve/gcc-4.0' # gcc-config -l [1] x86_64-pc-linux-gnu-3.4.6 [...] [6] x86_64-pc-linux-gnu-4.1.2 [7] x86_64-pc-linux-gnu-4.2.0 * # gcc-config 1 # source /etc/profile # gcc-config 7 # make build-qemu || stuff you need to compile with gcc 3.4 # source /etc/profile I do prefer to reset the right compiler right after the profile sourcing to avoid forget it after, the setting needed to compile stuff with gcc 4.0 are kept untill the shell is closed ore profile is sourced again. [EMAIL PROTECTED] ha scritto: hi shawn, qemu NEED gcc 3.x. chees CY Ursprüngliche Nachricht Von: [EMAIL PROTECTED] Datum: 02.09.2007 02:44 An: List for OpenMoko community discussion[EMAIL PROTECTED] openmoko.org Betreff: omit qemu from OE build? After the compiler badness on my one gentoo system (which I have no idea how to resolve) I decided to try on another machine which happens to be 64-bit and with gcc 4.1, so there isn't much hope of getting qemu to run. But openmoko-devel-image or openmoko-image depend on it. Is there a way to remove this dependency so I can just build images for the phone? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Hi Ian, thanks for your answer. I'd like to know how AGPS is currently supported on the NEO 1973. Can you help me to understand how it works from a software and a hardware point of view? Thanks. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ubuntu embedded/mobile
The Ubuntu stack is not necessarily designed for phones - it is targeted first at ultramobile PCs and tablet PCs. However, many of the programs that Ubuntu has started should be of benefit to the OpenMoko project. On 9/3/07, Hans van der Merwe [EMAIL PROTECTED] wrote: Hi, Not sure if this has been posted before, but will it be possible in the future to support the Ubuntu embedded stack on the neo? I see on the Ubuntu wiki they support the Intel's MID (Mobile Internet Device) platform - so it will need some porting. https://wiki.ubuntu.com/MobileAndEmbedded Hans E-Mail disclaimer: http://www.sunspace.co.za/emaildisclaimer.htm ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AW: omit qemu from OE build?
Dnia poniedziałek, 3 września 2007, Francesco Riosa napisał: on gentoo try: Also try to remove not needed content from mail. Would be good to try to answer under post not on top of it. # gcc-config 1 # source /etc/profile # gcc-config 7 # make build-qemu || stuff you need to compile with gcc 3.4 # source /etc/profile You can have gcc 3.4.x in PATH as gcc-3.4 and OpenEmbedded will automatically choose it to build QEmu. No need to change default compiler. -- JID: hrw-jabber.org OpenEmbedded developer/consultant Perl - The only language that looks the same before and after RSA encryption. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Luca Cabriolu wrote: Hi Ian, thanks for your answer. I'd like to know how AGPS is currently supported on the NEO 1973. Can you help me to understand how it works from a software and a hardware point of view? Fortunately, the answer is very simple. Unfortunately, that answer is It's not. The binary GPS program seems to have the ability to communicate with AGPS servers run by Global Locate - however, these require a subscription by some third party willing to buy service. I don't know the prices. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How snappy can the Openmoko GUI get using GTK?
On 2 Sep 2007, at 14:57, denis wrote: Watching a lot of videos about Openmoko and the GUI I saw that it is very slow and yards away from being snappy. (regarding the application startup and the acting inside an application) I know that speed is not the priority thing in developement at the moment but how fast and snappy can the Openmoko GUI using GTK get? I'm looking at this from the user point of view, I'm not a developer so it would be very interesting to me what can be expected in the future. What are you're expectations? Will it get as snappy as the old PALM Pdas had been? I haven't seen anyone else mention the obvious: some of the device drivers and alot of the code have debugging output enabled. Start the X server manually, and watch the debugging info spew forth, and you'll get an idea where a bunch of CPU cycles are going. As an example, every stylus press results in at least 4 debugging msgs printed, something happening in a place I would consider latency-sensitive. In addition various things complain constantly of missing icon image files, etc... things that would surely be cached if they were present, and those complaints take cycles. It's all appropriate in a development environment - we just have to factor that in when considering the responsiveness of the device. IMO it's appropriate for the primary focus to be functionality and the secondary focus to be user interaction effectiveness at this point. -Andy ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How snappy can the Openmoko GUI get using GTK?
On 3 Sep 2007, at 18:32, Andy Poling wrote: I haven't seen anyone else mention the obvious: some of the device drivers and alot of the code have debugging output enabled. Start the X server manually, and watch the debugging info spew forth, and you'll get an idea where a bunch of CPU cycles are going. As an example, every stylus press results in at least 4 debugging msgs printed, something happening in a place I would consider latency-sensitive. In addition various things complain constantly of missing icon image files, etc... things that would surely be cached if they were present, and those complaints take cycles. It's all appropriate in a development environment - we just have to factor that in when considering the responsiveness of the device. IMO it's appropriate for the primary focus to be functionality and the secondary focus to be user interaction effectiveness at this point. I've found that using a stylus seems to help it recognise touches, maybe someone has tweaked something so finger presses don't register as easily? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How snappy can the Openmoko GUI get using GTK?
On Mon, 3 Sep 2007, I wrote: It's all appropriate in a development environment - we just have to factor that in when considering the responsiveness of the device. IMO it's appropriate for the primary focus to be functionality and the secondary focus to be user interaction effectiveness at this point. Just to be clear, by user interaction effectiveness I meant the interaction paradigms used and the use case solutions. Not response time... -Andy ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: gpsd and AGPS
Hello, The AGPS functionality is split into these components: 1) Hammerhead GPS silicon - performs GPS measurements under control of (2). 2) Computation library - converts the GPS measurements into positions. The library is embedded into the GLLIN control program. NMEA output is via named pipe /tmp/nmeaNP. 3) OMGUI - user interface to test the GLLIN: stop/start, show signal strength, etc. 4) liblto - library to examine LTO expiration date 5) GPSD - standard GPSD with extensions to control host-based GLLIN. Here's the status of each: 1) Hammerhead is proven to work very well on GTA01 - I have measured down to -160 dBm sensitivity. The GTA01 antenna is VERY good, and the FIC designers did a great job keeping GPS RFI out of the antenna. 2) GLLIN is complete and tested for LTO AGPS. More on this below. The EULA/SLA for GLLIN is currently bouncing back forth between FIC and Broadcom. 3) OMGUI is done, but I'm sure a GTK+ hacker will find lots of cool ways to zoom it up, add maps, etc. 4) liblto is also done. 5) GPSD is started. OMGUI/src/gllin.cpp can be used to finish it to start/stop GLLIN. I hear the FIC team has the IPC mechanism running on it. (I forget the IPC name: DB, ADB, DBM??) AGPS Status: There are many levels to AGPS. Even a standard autonomous GPS receiver has a simple form of AGPS by virtue of caching recent information: position, time, ephemeris, clock frequency, etc. The GLLIN has this level of AGPS, embodied in two NVRAM.dat files kept in gpsd directory. (You can test factory cold start of GPS by removing these files). Beyond that, the only AGPS capability in the GTA01 is LTO. This is long-term orbit data files downloaded from the network. The delivery of the files can be done via wget or the lto_get facility included with OMGUI. FIC has purchased LTO delivery for the GTA01 for the lifetime of the product with the price of the Hammerhead chip. LTO is there now and it is free for FIC customers. Normally, ephemeris satellite data is downloaded at 50 bps from the satellites, but only when the signal strength is above about -142 dBm. Live ephemeris data is good for about 2 hours. With a data connection (I use a USB TCP/IP bridge to a PC, and then to the network), we can download 7 days of ephemeris in 3 or 4 seconds, independent of GPS signal conditions. When the GTA01 can make a data call, SUPL will be tested on the GLLIN. The choice of which SUPL server to connect to will be a command-line option to the GLLIN. The SUPL protocol is an OMA standard, so there will be competition in this arena. Broadcom sells a SUPL server, and we'll use it to test the GTA01 when this is possible, but there will not be any automatic lock-in to a specific server. When GTA01 is productized and customized by large integrators, there may be such lock-ins performed by the integrators that is not under control of FIC or Broadcom. Such a lock-in will be to meet the needs of the integrators' customer base, and would not affect the developer community. Behind the SUPL server are a bunch of other complicated servers and services that most network operators are getting into place. Here's some of the things a SUPL server needs to play well with: - access to the GPS ephemeris. There is yet another standard for this data pipe, and competition in this area. Of course Broadcom has a product for delivery of the ephemeris, as to others. - database of cellID -- initial position look up. I understand network operators cherish and protect this database. - interface to E911. This seems reasonable, but I don't know for sure about it. With C-Plane AGPS, E911 is definitiely there. GLLIN should be capable of supporting MS-BASED and MS-ASSISTED SUPL requests. Typically, SUPL-NI (Network Initiated) requests are signalled via a SUPL-NI data packet sent via SMS. I doubt this is available on the TI Calypso. Unfortunately, the TI Calypso GSM chipset does not provide control-plane access, so RRC and RRLP assistance is not available. So you can see that direct access to LTO via TCP/IP bypasses lots of complicated infrastructure, and can be accelerated to suit your style of use of the GTA01. On WindowsCE devices, the LTO mechanism is enhanced by these features, all of which can be added to GTA01 by the OpenMoko community: - cache LTO on a PC. Upon PC==GTA01 sync; squirt the LTO to the GTA01 - on GTA01: detect data connection creation and retrieve LTO if needed - on GTA01: add a cron job. - for specialized GTA01 environments: store forward the LTO file as needed. I hope this helps, Ken Yale -Original Message- From: Ian Stirling [mailto:[EMAIL PROTECTED] Sent: Mon 9/3/2007 9:38 AM To: List for OpenMoko community discussion Subject: Re: gpsd and AGPS Luca Cabriolu wrote: Hi Ian, thanks for your answer. I'd like to know how AGPS is currently supported on the NEO 1973. Can you help me to understand how it works from a software
Re: gpsd and AGPS
Ken Yale wrote: Hello, snip my largely incorrect comments thanks for the response! AGPS Status: snip Beyond that, the only AGPS capability in the GTA01 is LTO. This is long-term orbit data files downloaded from the network. The delivery of the files can be done via wget or the lto_get facility included with OMGUI. FIC has purchased LTO delivery for the GTA01 for the lifetime of the product with the price of the Hammerhead chip. LTO is there now and it is free for FIC customers. Great! Is there a url for wget, or is it more complex than this? Normally, ephemeris satellite data is downloaded at 50 bps from the satellites, but only when the signal strength is above about -142 dBm. Live ephemeris data is good for about 2 hours. With a data connection (I use a USB TCP/IP bridge to a PC, and then to the network), we can download 7 days of ephemeris in 3 or 4 seconds, independent of GPS signal conditions. Ephemeris data is broadcast for 12 of every 30s, by each satellite about its own orbit. So, you can get a good position if you've had 30s clear view of the sky within the last two hours, in order to download those 500 or so bits per satellite. Or alternatively, at some time in the past weeks, 12.5 minutes of signal to download the almanac (12 - which is good for a fair while. (some 3K of data) http://www.colorado.edu/geography/gcraft/notes/gps/gif/databits.gif I assume you mean LTO in the above. Are there any nice graphs (or even NMEA logs) of comparisons between positions of the LTO files, and downloaded? (or see the above URL/wget question) I'm assuming that LTO files are not simply copies of the almanac - but more precise orbital data - the almanac has data errors of 1m. snip So you can see that direct access to LTO via TCP/IP bypasses lots of complicated infrastructure, and can be accelerated to suit your style of use of the GTA01. On WindowsCE devices, the LTO mechanism is enhanced by these features, all of which can be added to GTA01 by the OpenMoko community: - cache LTO on a PC. Upon PC==GTA01 sync; squirt the LTO to the GTA01 - on GTA01: detect data connection creation and retrieve LTO if needed - on GTA01: add a cron job. - for specialized GTA01 environments: store forward the LTO file as needed. The hardware supports in principle more than this - http://wiki.openmoko.org/wiki/Server:A-GPS details some possibilities. But broadly, any assistance model is possible - SMOP -, from downloading long-term-orbit files, (who knows, GL may go down under lawsuits, and the servers fall over, be eaten by giant mice, ...) to providing only a snapshot of the partial data obtained during a short fix, and asking the server to provide a position. I hope this helps, Ken Yale I notice you mention GTA01 only - is there any significance in this? Thanks for the info! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AW: omit qemu from OE build?
Marcin Juszkiewicz ha scritto: Dnia poniedziałek, 3 września 2007, Francesco Riosa napisał: on gentoo try: Also try to remove not needed content from mail. Would be good to try to answer under post not on top of it. Sorry I think that's not the case , the configure file has this search list: gcc3_list=gcc-3.4 gcc34 gcc-3.3.6 gcc-3.3 gcc33 gcc-3.2 gcc32 gcc on gentoo is /usr/bin/gcc-3.4.6 so configure does not found it ... or I'm missing some piece regards ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AW: omit qemu from OE build?
On 9/3/07, Francesco Riosa [EMAIL PROTECTED] wrote: Marcin Juszkiewicz ha scritto: Dnia poniedziałek, 3 września 2007, Francesco Riosa napisał: on gentoo try: Also try to remove not needed content from mail. Would be good to try to answer under post not on top of it. Sorry I think that's not the case , the configure file has this search list: gcc3_list=gcc-3.4 gcc34 gcc-3.3.6 gcc-3.3 gcc33 gcc-3.2 gcc32 gcc on gentoo is /usr/bin/gcc-3.4.6 so configure does not found it ... or I'm missing some piece I fixed it by creating gcc32 as a script in /usr/bin, like this: #!/bin/sh gcc -m32 $@ (thanks Steve for the suggestion) Oh, I just realized it means a version number, not that it's a 32-bit gcc... Well I guess somebody should add to gcc3_list in the recipe and then we won't have this problem anymore on gentoo, eh? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: omit qemu from OE build?
Shawn Rutledge wrote: I got past qemu now and it's getting stuck on qtopia. (Again, why do I need that for openmoko?) qtopia or qmake? Qmake is needed to build webkit which is used by openmoko-feedreader. uicmoc4-native_4.3.1 To workaround the problem you had with gentoo and uicmocv4-native_4.3.1 please see bug 747 http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=747 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
