Re: tangoGPS 0.99.3 is out
great! looking forward to trying this out y On Sun, Feb 14, 2010 at 4:53 PM, Marcus Bauer marcus.ba...@gmail.comwrote: Hi, tangoGPS is out with lots of speed improvements and a lot less of CPU usage. Moreover the speed display is now set in pixels and no longer in points - especially on SHR that should result in lot smaller digits. (not configurable yet). Enjoy, Marcus ___ 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: OpenMoko Developer required
David Morris da...@david-morris.co.uk writes: I've recently discovered OpenMoko and Freerunner and am looking for freelance developers to customise the OS for specific requirements. If you Which the OS are you talking about? Primarily I want to have the handset able to retrieve SIM details over TCP/IP from a SIM bank rather than from a local SIM to the handset and for the handset to act as a remote slave for a WAN. This would mean having to somehow intercept and replace the SIM details that the GSM chip reads from the internal SIM storage area and instead pull this over the wireless connection or USB network connection instead. My guess is that this is not possible. We do not have source code to the part that talks to the SIM card. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko Developer required
Hello Timo, Timo Juhani Lindfors wrote: My guess is that this is not possible. We do not have source code to the part that talks to the SIM card. Those who are/were under NDA with Openmoko have access to the GSM firmware source code (at least the small part which was delivered by TI). Intercepting and simulation SIM access is possible, however the biggest problem is that you usually don't know the A3/A8 algorithm and the Ki inside the SIM. Those are needed whenever the phone has to authenticate to the GSM network. You can't extract them from current SIM cards so you are not able to authenticate to the GSM network without having access to the real SIM. Best regards, Dieter ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHRu] Stuck @ language screen aka Contest of the day.
Hi mokists, here's a challenge of the day contest : I just reflashed SHRu (feb 15). And I was surprised to see a touch-calibration utility at really startup ! Nice idea. But only problem : I touch my screen anywhere by mistake My calibration was validated ! now, I can't click on the Egnlish language button... And by SSH, as I didn't set my password, I cannot reset anything. I know I can reflash, but I don't want to. (I don't like easy things). If someone knows how to connect SSH or relauch the calibration utility I will send an openmoko-fr sticker. -- AstHrO - openmoko-fr.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHRu] Stuck @ language screen aka Contest of the day.
Thomas HOCEDEZ wrote: Hi mokists, here's a challenge of the day contest : I just reflashed SHRu (feb 15). And I was surprised to see a touch-calibration utility at really startup ! Nice idea. But only problem : I touch my screen anywhere by mistake My calibration was validated ! now, I can't click on the Egnlish language button... And by SSH, as I didn't set my password, I cannot reset anything. I know I can reflash, but I don't want to. (I don't like easy things). If someone knows how to connect SSH or relauch the calibration utility I will send an openmoko-fr sticker. DISPLAY=:0.0 xinput_calibrator -- Valéry ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHRu] Stuck @ language screen aka Contest of the day.
If someone knows how to connect SSH or relauch the calibration utility I will send an openmoko-fr sticker. Can you try to run DISPLAY=:0 /usr/bin/xinput_calibrator from your ssh shell? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHRu] Stuck @ language screen aka Contest of the day.
Valery Febvre wrote: Thomas HOCEDEZ wrote: Hi mokists, here's a challenge of the day contest : I just reflashed SHRu (feb 15). And I was surprised to see a touch-calibration utility at really startup ! Nice idea. But only problem : I touch my screen anywhere by mistake My calibration was validated ! now, I can't click on the Egnlish language button... And by SSH, as I didn't set my password, I cannot reset anything. I know I can reflash, but I don't want to. (I don't like easy things). If someone knows how to connect SSH or relauch the calibration utility I will send an openmoko-fr sticker. DISPLAY=:0.0 xinput_calibrator After, it may be necessary to: $ /etc/init.d/xserver-nodm stop $ /etc/init.d/xserver-nodm start -- Valéry ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: [SHRu] Stuck @ language screen aka Contest of the day.
If someone knows how to connect SSH or relauch the calibration utility I will send an openmoko-fr sticker. Can you try to run DISPLAY=:0 /usr/bin/xinput_calibrator from your ssh shell? you can also remove /etc/pointercal.xinput and reboot. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHRu] Stuck @ language screen aka Contest of the day.
On Tue, Feb 16, 2010 at 02:01:53PM +0100, Thomas HOCEDEZ wrote: Hi mokists, here's a challenge of the day contest : I just reflashed SHRu (feb 15). And I was surprised to see a touch-calibration utility at really startup ! Nice idea. But only problem : I touch my screen anywhere by mistake My calibration was validated ! now, I can't click on the Egnlish language button... And by SSH, as I didn't set my password, I cannot reset anything. I know I can reflash, but I don't want to. (I don't like easy things). If someone knows how to connect SSH or relauch the calibration utility I will send an openmoko-fr sticker. -- AstHrO - openmoko-fr.org I've already asked author of xinput-calibratior utility for confirmation dialog after calibration.. he said that he will check that soon. Sorry for a bit difficult sollution, see my e-mail here: http://www.mail-archive.com/shr-de...@lists.shr-project.org/msg01868.html If you cannot SSH (empty password should be allowed again in new images - partially because of this issue), then you can remove that file from 2nd distribution on uSD or on your PC if you have problem with image installed on uSD. Regards, -- uin:136542059jid:martin.ja...@gmail.com Jansa Martin sip:jama...@voip.wengo.fr JaMa ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHRu] Stuck @ language screen aka Contest of the day.
On Tue, Feb 16, 2010 at 02:13:33PM +0100, Valery Febvre wrote: Valery Febvre wrote: Thomas HOCEDEZ wrote: Hi mokists, here's a challenge of the day contest : I just reflashed SHRu (feb 15). And I was surprised to see a touch-calibration utility at really startup ! Nice idea. But only problem : I touch my screen anywhere by mistake My calibration was validated ! now, I can't click on the Egnlish language button... And by SSH, as I didn't set my password, I cannot reset anything. I know I can reflash, but I don't want to. (I don't like easy things). If someone knows how to connect SSH or relauch the calibration utility I will send an openmoko-fr sticker. DISPLAY=:0.0 xinput_calibrator After, it may be necessary to: $ /etc/init.d/xserver-nodm stop $ /etc/init.d/xserver-nodm start No this is not enough.. with /etc/pointercal.xinput file it will always use the wrong values stored there. You have to remove /etc/pointercal.xinput first and then restart xserver-nodm. Regards, -- uin:136542059jid:martin.ja...@gmail.com Jansa Martin sip:jama...@voip.wengo.fr JaMa ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v19
* Radek Polak wrote, Il 15/02/2010 14:57: I can try to play a bit more with the config. Maybe we can find something with same speed and less buggy. I was hoping to have 2.6.32 kernel, which is fast and stable. But currently for me does not wake from suspend on incoming call and getting somehow trashed touchscreen input in X (both xglamo and Xorg with tslib input). I didnt have much time to explore it yet. No problem Radek, and thanks anyway for your super effort :-) I'm not a programmer so i cannot resolve my self these kinds of problem. But i hope someone will do ;-) I can help as beta-tester, or helping on documentation, not more. I think that the community behind QtMoko now it's not so tiny, but we need a method to concentrate better our efforts. IE: on the site it must be some places to easily report bugs, problems or feedback by users, to help testing (and betatesting) fo this (great) distribution. Something like a bug tracker, answer for users, and so on, more over wiki. Maybe we can open it on launchpad ? It's there a stable main developer group behind QtMoko or is only a onemanwork? -- Andrea ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
tangogps google satellite url
Hi all, I'm a happy tangogps user, but it seems like google changed their satellite url once again. for google maps I use http://mt0.google.com/vt/v=w2.97hl=nlx=%dy=%dz=%ds=G and this one still works could someone be so kind to give me the correct url for the satellite images? (for testing purposes only of course) Kind regards, y ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangoGPS 0.99.3 is out
Marcus Bauer wrote: Hi, tangoGPS is out with lots of speed improvements and a lot less of CPU usage. Moreover the speed display is now set in pixels and no longer in points - especially on SHR that should result in lot smaller digits. (not configurable yet). Enjoy, Marcus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community awesome work! can you supply also the pkg for hackable:1 please. It was quite hard to install it with GUI ,actually only adding th the sources and apt-get update could be used to install it... Can you also supply a clear all msg button? Juergen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: [SHRu] Stuck @ language screen aka Contest of the day.
Last brick to find : how to SSH my FR ! Probably the only way not to install shr again, would be to boot from sd card and remove the file /etc/pointercal.xinput in the flash partition from that system. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v19
[cut] But i hope someone will do ;-) I can help as beta-tester, or helping on documentation, not more. Lets strike while the iron is hot! QtMoko's wiki [1] probably needs attention, also there is not a single mention about this distro in Distributions page [2]! If you really want to help you can start here. [1] http://wiki.openmoko.org/wiki/QtMoko [2] http://wiki.openmoko.org/wiki/Distributions -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Monday 15 February 2010 19:33:56 Rui Miguel Silva Seabra wrote: A framebuffer device is usually slower than a native driver under X. My Freerunner's UI performance definitely felt a bit faster after moving to the native driver. My point is that X server probably kills the performance here. You can try compile Qtopia on top of X and you will see the difference. The slowness of the graphics is better explained by the brain deadness of the hardware. I think that this is very unfortunate explanation. To me it looks like somebody said that freerunner's graphics sucks and there is no way it will ever be faster and it was taken as a fact. Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. Sorry, i dont like to hear that it sucks. It could be probably good enough as any other phone. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps google satellite url
On Tue, 16 Feb 2010 15:42:13 +0100 Yorick Moko yorickm...@gmail.com wrote: Hi all, I'm a happy tangogps user, but it seems like google changed their satellite url once again. for google maps I use http://mt0.google.com/vt/v=w2.97hl=nlx=%dy=%dz=%ds=G and this one still works could someone be so kind to give me the correct url for the satellite images? (for testing purposes only of course) you can use firebug to easily figure out the url of an image. usually only the version number changes. a quick check reveals that it is now at v=55. if you keep older version numbers, the servers will refuse the request. marcus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
2010/2/16 Radek Polak pson...@seznam.cz: I think that this is very unfortunate explanation. To me it looks like somebody said that freerunner's graphics sucks and there is no way it will ever be faster and it was taken as a fact. I'm no hardware guru, but if i remember it correctly, it was the fact, that the processor and the graphics chip can't access the RAM at the same time. Both of them lock the channel to the RAM, so they block each other. To make things worse, the uSD card is connected with the same channel. Please correct me, if i'm wrong. Cheers, Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
* Radek Polak wrote, Il 16/02/2010 15:48: Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. I totally agree Radek's words, and in my experience the GUI in QtMoko 19 with the new kernel, it's fast like any other smartphone. _Really_ _fast_, now. So the myth of slowness of the FR, it's now a legend, because QtMoko now has a GUI with a speed absolutely comparable with any other commercial phone. These are facts. -- Andrea ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tuesday 16 February 2010 15:48:49 Radek Polak wrote: On Monday 15 February 2010 19:33:56 Rui Miguel Silva Seabra wrote: I think that this is very unfortunate explanation. To me it looks like somebody said that freerunner's graphics sucks and there is no way it will ever be faster and it was taken as a fact. Graphics performance is better of what it seemed could be archieved at the beggining, but Glamo's bus slowness is not something someone said, it's a fact. Also, qtopia (qtextended, qtmoko) do a lot less effects on graphics than enlightment, that's why it's faster. If you turn off shadows, transparency, etc, you can get shr graphics as fast as qtopia. If you don't believe me, you can try SHR's Neo Theme. You will see it's not X, but eyecandy what makes SHR slower than qtopia. You can search lists archives for several threads about this matter, it was spoken to death. Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. No, it can't, at least until we have an OpenGL driver. But it's true that using VGA resolution is a handicap for such a slow graphics chip, and it would be better QVGA for this hardware. Fact is that glamo is a graphics decelerator. It's known that Neo1973 was faster than FreeRunner on graphics (even on VGA), despite of slower processor. signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangoGPS 0.99.3 is out
On Tue, 16 Feb 2010 14:44:00 + Juergen Schinker ba1...@homie.homelinux.net wrote: awesome work! can you supply also the pkg for hackable:1 please. Afaik David 'Deubeuliou' is already working on it and it should be apt-get installable in the next two or three days. Can you also supply a clear all msg button? Yes, there is definitely a need for a solution for this... Marcus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[GTA02] VGA-QVGA switching - #2263 revisited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm trying to get VGA-QVGA switching/rotation to work - with mixed results.. Distro: recent SHR-t (using Xorg), xglamo-hack disabled during startup Commands I intend to use (ie, VGA portrait and QVGA landscape): xrandr -s 240x320 -o 3 xrandr -o 0 -s 480x640 I don't really care about specific kernel version - I just want it to run 'well' with SHR-t (this mode switching, suspend, maybe wifi; if I need to hack some changed sysfs paths that's OK) The best I can get is with default SHR-t kernel (which is andy-tracking); however, in this case bug #2263 is present (after res. change the image is shifted randomly on the screen, http://docs.openmoko.org/trac/ticket/2263) I've tried a few more kernels: 2.6.31-no-drm: simple rotation corrupts the display or WSOD 2.6.32-no-drm: rotation in VGA works QVGA is mostly white #2263 is not present 2.6.3x-drm: QVGA/rotation not available (not via xrandr at least) latest 'experimental' kernel from http://downloads.openmoko.org/distro/experimental (as mentioned in #2263): DRM - no QVGA Thus, I'd like to ask if anyone know: - a solution that works? - a git revision which is supposed to fix #2263? - some background on #2263 so I can try to fix it in SHR kernel? I'm also fine with DRM kerels if they can somehow switch the modes/orientations; I didn't find a word how that should work, though. Thanks regards, Vlado -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iJwEAQECAAYFAkt6vYAACgkQutgEj9ZLuzRCqwP/T13D/p1iwQB8TPtnODCmqTSb 1oqi7HdWDDy+4IFcq6Ucs6hJRcAzObWKByZTiolgh6HZNGUic3NvejIGMaFv6pTG Ltzdu+vUtFzVF1AZ81AMWU34GJDL/+yctbf+aZQYPkHuGwivJGCPT+megte9hRRW O1NoidWO0o5iMcfzZcc= =66hC -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tue, 16 Feb 2010 16:19:08 +0100 David Garabana Barro da...@garabana.com wrote: Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. No, it can't, at least until we have an OpenGL driver. But it's true that using VGA resolution is a handicap for such a slow graphics chip, and it would be better QVGA for this hardware. A small point, but there are things we can do along the way to a full GL driver which speed things up, and I don't think we've found them all just yet. For instance, adding proper fencing in the DRM driver unclogs things by a fairly noticable amount: fullscreen (VGA) blits at 100fps with 0% CPU usage, anyone? Fact is that glamo is a graphics decelerator. It's known that Neo1973 was faster than FreeRunner on graphics (even on VGA), despite of slower processor. Yes, the bus speed is a fundamental limitation, and it does suck. But there are other reasons (see below) why the current driver and rendering model is a bad match for the hardware. In fact, it's a bad match for almost all hardware, it's just that normally the overall speed is high enough to get away with it. We haven't yet allowed ourselves to make meaningful use of the acceleration features, and I'm absolutely convinced that if we did so then the GTA02's UI could fly along. It's a fact that to get to this state we're going to have to write a lot of hardware-specific code, and each developer who would potentially work on this stuff has to make their own decision about whether they want to do that for a GPU which won't be found elsewhere. Extract from http://lists.shr-project.org/pipermail/shr-devel/2009-December/001702.html - see the thread for context. --- If you're only talking about the X protocol overhead, then that's true - although I haven't yet seen any numbers... However, it's not the driver's fault. By the time (say) GTK's rendering instructions get to our driver (i.e. xf86-video-glamo), they've been turned into a series of tiny rectangle operations which are almost impossible to accelerate in any useful way. In this sense, the way X requires programs to send their rendering commands, and the way GTK/Cairo sends its commands, and the way the X server core communicates with the driver, are hurting us. Essentially, that's why E is so much faster: it prepares larger chunks of data at a higher level where acceleration can be much more meaningful, then sends them to the server in one big block. The price of this is that the acceleration done by the driver is hardly used in most cases, so we still don't get the best out of our hardware. A more fundamental redesign could potentially allow such pitfalls to be side-stepped, but this also comes at a price: Hardware-dependent code would end up existing at a higher level in the software [1], reducing the reusability of code. [1] In the extreme case, hardware-dependent code can be moved all the way up the the individual client program, abstracted by a library. This is what DRI does, in which case that abstraction library is usually Mesa, providing an OpenGL API. --- My decision about this was simple: Since I enjoy the development work, it doesn't make any difference to me that the hardware will go away in time. Nothing is forever, and this is a perfect opportunity to learn about driver development on a relatively tame piece of hardware. I don't have any immediate plans for world domination [2].. Tom [2] ... or is that just what I want you to believe? Mwahahahaha... -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA02] VGA-QVGA switching - #2263 revisited
On Tue, 16 Feb 2010 16:45:04 +0100 Vladimir Koutny vl...@moko.ksp.sk wrote: Thus, I'd like to ask if anyone know: - a solution that works? - a git revision which is supposed to fix #2263? - some background on #2263 so I can try to fix it in SHR kernel? I'm also fine with DRM kerels if they can somehow switch the modes/orientations; I didn't find a word how that should work, though. XRandR hasn't really been worked on yet for the DRM/KMS stack, so if it works then it's more luck than judgement. I'm working on stabilising this kind of thing in the 2.6.32+DRM kernel right now. Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: TangoGPS font size for speed indicator
On 6 January 2010 11:11, Neil Jerram neiljer...@googlemail.com wrote: line. (I plan to make a donation shortly.) Finally getting around to this - but I don't see a Donate button anywhere on the tangogps website. Is there a donation mechanism? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
It's a fact that to get to this state we're going to have to write a lot of hardware-specific code, and each developer who would potentially work on this stuff has to make their own decision about whether they want to do that for a GPU which won't be found elsewhere. There is another, much more concrete obstacle across this path : AFAIK there are no public release of glamo's datasheet. While I find it conceivable to dedicate some time and effort to code some low level code for a never to be seen again video chip, then to code some apps using this code, I can't stand to have to guess how the chip works. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tuesday 16 February 2010 17:04:28 ri...@happyleptic.org wrote: It's a fact that to get to this state we're going to have to write a lot of hardware-specific code, and each developer who would potentially work on this stuff has to make their own decision about whether they want to do that for a GPU which won't be found elsewhere. There is another, much more concrete obstacle across this path : AFAIK there are no public release of glamo's datasheet. AFAIK, Thomas has access to Glamo's doc under NDA Isn't it, Thomas? signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tue, 16 Feb 2010 16:49:30 +0100 Thomas White t...@bitwiz.org.uk said: On Tue, 16 Feb 2010 16:19:08 +0100 David Garabana Barro da...@garabana.com wrote: Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. No, it can't, at least until we have an OpenGL driver. But it's true that using VGA resolution is a handicap for such a slow graphics chip, and it would be better QVGA for this hardware. A small point, but there are things we can do along the way to a full GL driver which speed things up, and I don't think we've found them all just yet. For instance, adding proper fencing in the DRM driver unclogs things by a fairly noticable amount: fullscreen (VGA) blits at 100fps with 0% CPU usage, anyone? indeed nice.. if there is 100fps of data to blit TO the screen usefully. something has to generate that data... :) technically if you tyried to implement full xrender accel - evas could be partly accelerated by the 2d hw - but.. it's my guess (and still is - but if you ever get that far - prove me wrong :)) that for every win u get from using the 2d hw accel, you will post a loss by falling back to software ops going across the bus from cpu - glamo as the 2d is only partly able to implement xrender and the kind of ops you need. of course.. i'm open to be proven wrong, but.. it's my guess that after all the work and effort, you'll have spent that effort standing still (i.e. gaining on one hand, losing on the other). as for GL.. there is gl-es1.1 - but only minimally useful. can't do vga rendering - so u need to drop to qvga anyway. max texture size of 256x256? not useful for 2d anymore. evas has a full opengl-es2.0 engine - but 2.0 and 1.x in gl-es are completely incompatible api's so you choose one or the other to work on - i chose 2.0 as it's friendly to 2d much more than 1.1. given just the 2 limits above i suspect it will be marginally useful at best. also note - i've working on soc's with full gl-es2.0 gpu's and fast shared buses where cpu and gpu are living in the same memory and there is no system - video ram bottleneck... and software can equal or beat hw gl in a lot of cases. in others gl can beat software - but it's not immensely common. i've pushed things to minimise gl state transitions a lot - minimise re-binds, use texture atlases - and i've pushed shaders to take a lot of the weight of things like enabling and dsabling blending and more. of course u'd need 2.0 to have shaders... but in general gl-es is really good at 3d. ie rotations and perspective transforms. for simpler things like plain alpha blending, blits, fills etc. software can equal or beat even the best gpu's (i'm talking s3c6410, omap3 - sgx 530 and even an sxg540 clocking in at 200mhz and 4 cores). example: http://www.rasterman.com/files/other-vs-gl.html notice gl really works well on the 3d stuff (rotations/perspective), but can lose badly on many other paths. and thats one of the top-of-the-line gpu's in embedded. and for s3c6410 (this is what was once considered for gta03/04 long ago, and by now this SoC is considered old/legacy): http://www.rasterman.com/files/s3c-gl-vs-soft.html the amount of work needed to get it up to snuff was non-trivial with full docs and sample driver code and a few people working on it full time for many months from both ends (kernel driver, xserver, userspace libgl and application sides). you just need to know that - you may get it to work in the end. sure. that may happen. but... your results may be sorely disappointing :( just beware. Fact is that glamo is a graphics decelerator. It's known that Neo1973 was faster than FreeRunner on graphics (even on VGA), despite of slower processor. Yes, the bus speed is a fundamental limitation, and it does suck. But there are other reasons (see below) why the current driver and rendering model is a bad match for the hardware. In fact, it's a bad match for almost all hardware, it's just that normally the overall speed is high enough to get away with it. We haven't yet allowed ourselves to make meaningful use of the acceleration features, and I'm absolutely convinced that if we did so then the GTA02's UI could fly along. It's a fact that to get to this state we're going to have to write a lot of hardware-specific code, and each developer who would potentially work on this stuff has to make their own decision about whether they want to do that for a GPU which won't be found elsewhere. thats one of the saddest things. if glamo had a future.. a glamo2,3,4 that would be found.. it'd be worth effort - but all of this will be for a 1-off gpu that is for a dead platform (freerunner is no longer produced and there is no successor coming that has the glamo or successors as part of it). how much effort do you put into something like that? me - i am a pragmatist here - i'd put as
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tuesday 16 February 2010 17:18:27 Carsten Haitzler wrote: as for GL.. there is gl-es1.1 - but only minimally useful. can't do vga rendering - so u need to drop to qvga anyway. max texture size of 256x256? Wasn't max texture size 512x512? signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tue, 16 Feb 2010 17:33:32 +0100 David Garabana Barro da...@garabana.com said: On Tuesday 16 February 2010 17:18:27 Carsten Haitzler wrote: as for GL.. there is gl-es1.1 - but only minimally useful. can't do vga rendering - so u need to drop to qvga anyway. max texture size of 256x256? Wasn't max texture size 512x512? that was max rendering viewport (max gl buffer). this can't do vga (as vga is 640x... 640 512). maybe u can start rendering by rendering 2 buffers then combining them in 2 output blits. it's not going to be pretty for performance... or for the driver internals. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps google satellite url
thanks a lot Marcus On Tue, Feb 16, 2010 at 4:11 PM, Marcus Bauer marcus.ba...@gmail.comwrote: On Tue, 16 Feb 2010 15:42:13 +0100 Yorick Moko yorickm...@gmail.com wrote: Hi all, I'm a happy tangogps user, but it seems like google changed their satellite url once again. for google maps I use http://mt0.google.com/vt/v=w2.97hl=nlx=%dy=%dz=%ds=G and this one still works could someone be so kind to give me the correct url for the satellite images? (for testing purposes only of course) you can use firebug to easily figure out the url of an image. usually only the version number changes. a quick check reveals that it is now at v=55. if you keep older version numbers, the servers will refuse the request. marcus ___ 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: TangoGPS font size for speed indicator
On Tue, 16 Feb 2010 16:00:20 + Neil Jerram neiljer...@googlemail.com wrote: On 6 January 2010 11:11, Neil Jerram neiljer...@googlemail.com wrote: line. (I plan to make a donation shortly.) Finally getting around to this - but I don't see a Donate button anywhere on the tangogps website. Is there a donation mechanism? Thanks, Neil Hello Neil, So far I have added the donation button occasionally under the release notes but now I have added one to the left sidebar. Best regards, Marcus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v19
-= Apertum =- wrote: No problem Radek, and thanks anyway for your super effort :-) I am glad to hear it, thanks too. I think that the community behind QtMoko now it's not so tiny, but we need a method to concentrate better our efforts. IE: on the site it must be some places to easily report bugs, problems or feedback by users, to help testing (and betatesting) fo this (great) distribution. Something like a bug tracker, answer for users, and so on, more over wiki. Maybe we can open it on launchpad ? I have already project on sourceforge. Although i have nothing against launchpad, i'd like to use the existing infrastructure. Maybe we can talk about it in #qtmoko irc. It's there a stable main developer group behind QtMoko or is only a onemanwork? There is probably no stable contributor now, but the occasional contributors are great. I just felt like wow and couldnt believe when i saw Arora or NeronGPS. Or the bugs in latest release fixed by Jeroen. It's perfect work and many thanks for it. Btw i have very little time lately (family, money work and trying to do some sports). Please dont expect too much from me :-) Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tracking power leackage in my freerunner
-[ Mon, Feb 15, 2010 at 09:55:35PM +0200, Timo Juhani Lindfors ] ri...@happyleptic.org writes: Do you think usb could be the source of power consumption (nothing is plugged in of course) ? Or maybe SD card reader ? Remove SD card and SIM card and see? Got 18.5mA. I also did this using qtmoko (setting deep sleep mode in /opt/qtmoko/etc/default/Trolltech/Modem.conf), just to be sure. Also, I upgraded to latest gsm chipset firmware. Should I conclude to a hardware bug ? Any idea where/how I should look for ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tracking power leackage in my freerunner
ri...@happyleptic.org writes: I also did this using qtmoko (setting deep sleep mode in /opt/qtmoko/etc/default/Trolltech/Modem.conf), just to be sure. Deep sleep only matters if the GSM chip is on. Should I conclude to a hardware bug ? Any idea where/how I should look for ? My expertise pretty much ends here :-) However, it might help if you power down all extra hardware (bt, gsm, gps, wifi) and then run gpio from http://svn.openmoko.org/trunk/src/target/gpio/ and post the results. Here's what I get in this state: li...@ginger:~$ om power bt power 0 gsm power 0 gps power 0 gps keep-on-in-suspend 1 wifi power 0 li...@ginger:~$ sudo bin/gpio A 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 0 F0 0 0 F0 F0 F0 F0 F0 F0 B 0 1 2 3 4 5 6 7 8 9 10 0 0 0 0 0 0 0 0 0 1 0 C 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 0 0 0 0 0R0 0 0 0 0 0 0 1 0 1 D 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1 0 0 1 1 0 0 0 0 0 0 0 1 1 1 0 E 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 F1 F1 F0 F1 F1 0 F1 F1 F1 F1 F1 F1RF1 F1 F1 F1 F 0 1 2 3 4 5 6 7 F1 F0 F1 F0RF0 F1 F0 F0 G 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 F1 X1 0 F1 1R0 1 F1 F1 F1 F0 0 1 1 0 H 0 1 2 3 4 5 6 7 8 9 10 F0 0R 0 F0R0 F1 F1 F1 F0RF1 0 J 0 1 2 3 4 5 6 7 8 9 10 11 12 0R1 0 0 1 1 1 0R1 0 0 0 0 By looking at https://svn.openmoko.org/trunk/doc/hardware/GTA02v4/gpio.txt you can see where each GPIO pin is connected to in the schematics http://people.gta01.hmw-consulting.de/people/joerg/schematics/GTA02/Schematics_Freerunner-GTA02_A5-A7cumulative_public_RC0.pdf Does your GPIO output differ from mine? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
