Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
2008/11/21 Lally Singh [EMAIL PROTECTED]: As Raster's already pushed hard on Glamo acceleration, and I know he's quite capable (I was an old enlightenment WM user back in the day), I consider the glamo issue closed. We're stuck with what we have, and simply have to find ways to be efficient with what what's already there. Yes, efficiency, but let's remember the stable-tracking kernel has Glamo core clock boosted from 50MHz to 80MHz with some wait states disabled - it also does bring additional performance to play with / optimize for. And I don't know what where the exact details for some big (?) wait state somewhere in the driver that was earlier hoped to be gotten ridden of, but which turned out not to be easy? Something, somehow, is anyway hopefully fixable in addition to boosting the clock speeds, since the CPU usage of using Glamo seems quite ridiculous at times. I'm taking a protective role for the community in all this. IMHO the community's what makes the OM phone interesting. I'd rather not see well-intentioned hackers spend long months on a venture with little likely return. This is something that depends on what the mentioned hackers want to do. It's not anyone else's job to tell others how to spend their free time. And also little return is quite relative. As for QVGA Glamo 3D support, I think it would be really worthwhile not only to have it, but to have the possibility to try out eg. Clutter-based applications during GTA02 lifeframe. It would benefit a lot also the future generations of Openmoko hardware. By the time the GTA03's entering its lifetime, hopefully there should be some good options available. I like the idea of one or more vector units.. I'm hoping that with the openness on the desktop side - AMD, Intel, Via and XGI, it cannot be indefinitely until there is also mobile graphics chipsets available with open documentation. It's not that much more special and on the desktop side you have already basically everybody but one vendor (nvidia). -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Fri, Nov 21, 2008 at 3:09 AM, Timo Jyrinki [EMAIL PROTECTED] wrote: 2008/11/21 Lally Singh [EMAIL PROTECTED]: snip I'm taking a protective role for the community in all this. IMHO the community's what makes the OM phone interesting. I'd rather not see well-intentioned hackers spend long months on a venture with little likely return. This is something that depends on what the mentioned hackers want to do. It's not anyone else's job to tell others how to spend their free time. And also little return is quite relative. As for QVGA Glamo 3D support, I think it would be really worthwhile not only to have it, but to have the possibility to try out eg. Clutter-based applications during GTA02 lifeframe. It would benefit a lot also the future generations of Openmoko hardware. I'm not stopping anyone, just making sure they know what they're getting into. By the time the GTA03's entering its lifetime, hopefully there should be some good options available. I like the idea of one or more vector units.. I'm hoping that with the openness on the desktop side - AMD, Intel, Via and XGI, it cannot be indefinitely until there is also mobile graphics chipsets available with open documentation. It's not that much more special and on the desktop side you have already basically everybody but one vendor (nvidia). -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
2008/11/20 The Rasterman Carsten Haitzler [EMAIL PROTECTED]
it's accelerated - but likely polling the command queue status as you have
no
interrupts thanks to the linux kernel's policy of not exporting interrupts
to
userspace, so you're stuck with a poll loop. i can't remember if glamo had
a
i'm done interrupt for the command queue or operations - i know it had
several interrupts it can generate (but as the kernel wouldnt allow
userspace
to make use of them i pretty much ignored them).
I'm not sure I understand completely, may you elaborate this?
Profiling my loop:
{
switch foreground paint color
draw a vertical line from 0,0 to 0,639
XCopyArea to scroll the screen 1 pixel right
XFlush
usleep(4) to have aproximately 25 fps
}
I got that:XCopyArea + XFlush are about 100 microseconds long, usleep is
about 44000, and as the last is not cpu intensive this should results in a
near 0% cpu busy. But as top reports 70% of cpu wasted by glamo (vmstat
reports 25% user time and about 50% system time), I added after XFlush a
call to XSync, and this reported another 4 microseconds wasted while
waiting for X server to complete the request. As top reports again 70% of
busy cpu I suppose that during the XSync the main CPU is working and suppose
this is not only due to protocol latency and other overhead, but the glamo
driver is doing some other things while the gpu is blitting.
Is this the interrupt problem you are referring to?
And if this is true would be possible to write a workaround?
You are right, 2d is accelerated but this is unuseful if the cpu has to be
busy while the gpu is working!
Regards
Nicola
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | so right now other than bugs and trying to minimise cpu overhead on handling | the commandqueue 2d is done - it's not getting faster. only thing left is 3d. | and that comes with a long list of gotchas. this is the bit where someone needs | to make a call on what is the effort needed, and the result. this is up to | openmoko to decide what to do as the docs are in their hands. 2d is pretty much | done. :) Having heard the down side :-) whatever else one can say about it compared to other hardware, Glamo 3D unit is interesting for two reasons: first the render work happens on the other side of the bus, past the bottleneck. A large part of the 8MB on-chip memory is available to hold assets that can be prepped beforehand, these can be operated on by the 3D unit with no real CPU bus load. Even allowing for the constraints we can expect smooth 3D capability on the LCM from this far beyond what software render could manage, and with the CPU able to work in parallel. The second reason is that if we leverage pure xorg - Mesa - OpenGL ES basis for this implementation, the architecture of autonomous rendering is very compatible with future products which will also feed themselves from (shared) memory without heavy CPU involvement. So we bring GTA02 up into being able to use OpenGL ES-based apps, games and UI we can expect in future with minimal or no special-casing. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkmjhsACgkQOjLpvpq7dMq30QCfVq1lx6s8nVxPGk1PEpotUz8/ 1OQAn3eIm3LFHkAb0TsCDUeOsvhJbSRC =ciVI -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Fri, 21 Nov 2008 12:19:59 +0100 Nicola Mfb [EMAIL PROTECTED] babbled:
2008/11/20 The Rasterman Carsten Haitzler [EMAIL PROTECTED]
it's accelerated - but likely polling the command queue status as you have
no
interrupts thanks to the linux kernel's policy of not exporting interrupts
to
userspace, so you're stuck with a poll loop. i can't remember if glamo had
a
i'm done interrupt for the command queue or operations - i know it had
several interrupts it can generate (but as the kernel wouldnt allow
userspace
to make use of them i pretty much ignored them).
I'm not sure I understand completely, may you elaborate this?
Profiling my loop:
{
switch foreground paint color
draw a vertical line from 0,0 to 0,639
XCopyArea to scroll the screen 1 pixel right
XFlush
usleep(4) to have aproximately 25 fps
}
I got that:XCopyArea + XFlush are about 100 microseconds long, usleep is
about 44000, and as the last is not cpu intensive this should results in a
near 0% cpu busy. But as top reports 70% of cpu wasted by glamo (vmstat
reports 25% user time and about 50% system time), I added after XFlush a
call to XSync, and this reported another 4 microseconds wasted while
waiting for X server to complete the request. As top reports again 70% of
busy cpu I suppose that during the XSync the main CPU is working and suppose
this is not only due to protocol latency and other overhead, but the glamo
driver is doing some other things while the gpu is blitting.
Is this the interrupt problem you are referring to?
And if this is true would be possible to write a workaround?
You are right, 2d is accelerated but this is unuseful if the cpu has to be
busy while the gpu is working!
XSync sends a request to x and waits for a reply - so your client app will stop
and wait until x replies. x will reply once it has completed all existing
requests - that means the XCopeArea. while your app is waiting xglamo is
waiting for the gfx chip to do the work - and likely its sitting in a loop
polling checking when the command is done.
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Hi, all this talking without outcome is very boring to read. :| I cannot help with the development of a free 3D-capable driver for the Glamo directly instead I offer money! As soon as cofundos.org is working again (I hope they haven't shut it down) I will create a project and offer 50€ to the people who develop that driver. Of course, to make the money offer attractive some more people need to join. That will be up to the community. Spread the word! Regards Robert signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
2008/11/21 The Rasterman Carsten Haitzler [EMAIL PROTECTED] XSync sends a request to x and waits for a reply - so your client app will stop and wait until x replies. x will reply once it has completed all existing requests - that means the XCopeArea. while your app is waiting xglamo is waiting for the gfx chip to do the work - and likely its sitting in a loop polling checking when the command is done. Thanks Raster, now things are becoming clear :) The glamo chip should raise an interrupt when the command is done, a specialized kernel module should export this interrupt to the userspace so Xglamo may suspend waiting for this interrupt without wasting cpu cycles! I suppose that this should be quite easy and cheap for Openmoko developers, may it be considered? This will really improve the device performance! Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
harald welte did good for via: http://www.via.com.tw/en/resources/pressroom/pressrelease.jsp?press_release_no=2887 let's ship him to smedia :) On Fri, Nov 21, 2008 at 2:02 PM, Nicola Mfb [EMAIL PROTECTED] wrote: 2008/11/21 The Rasterman Carsten Haitzler [EMAIL PROTECTED] XSync sends a request to x and waits for a reply - so your client app will stop and wait until x replies. x will reply once it has completed all existing requests - that means the XCopeArea. while your app is waiting xglamo is waiting for the gfx chip to do the work - and likely its sitting in a loop polling checking when the command is done. Thanks Raster, now things are becoming clear :) The glamo chip should raise an interrupt when the command is done, a specialized kernel module should export this interrupt to the userspace so Xglamo may suspend waiting for this interrupt without wasting cpu cycles! I suppose that this should be quite easy and cheap for Openmoko developers, may it be considered? This will really improve the device performance! Regards Nicola ___ 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: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | 2008/11/21 The Rasterman Carsten Haitzler [EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] | | | XSync sends a request to x and waits for a reply - so your client | app will stop | and wait until x replies. x will reply once it has completed all | existing | requests - that means the XCopeArea. while your app is waiting xglamo is | waiting for the gfx chip to do the work - and likely its sitting in | a loop | polling checking when the command is done. | | | Thanks Raster, now things are becoming clear :) | The glamo chip should raise an interrupt when the command is done, a | specialized kernel module should export this interrupt to the userspace | so Xglamo may suspend waiting for this interrupt without wasting cpu cycles! | I suppose that this should be quite easy and cheap for Openmoko | developers, may it be considered? | This will really improve the device performance! Graeme seems to be planning to do his xorg version of Xglamo partially in kernelspace to unify the locking, that would be when to do this too. The Glamo's interrupt itself is supported and working, it's the basis for the same waiting strategy (yielding until completion interrupt) in the Glamo MMC stuff. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkmvsIACgkQOjLpvpq7dMqv2ACeOBYzeq9vyfgisJSznt+Fr3HL YCMAn1yqajW9/lTDFcnjcJVIhPJlkgnN =oTbc -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
2008/11/21 Andy Green [EMAIL PROTECTED] Graeme seems to be planning to do his xorg version of Xglamo partially in kernelspace to unify the locking, that would be when to do this too. The Glamo's interrupt itself is supported and working, it's the basis for the same waiting strategy (yielding until completion interrupt) in the Glamo MMC stuff. - -Andy This is great! Thanks! Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
2008/11/18 The Rasterman Carsten Haitzler [EMAIL PROTECTED] [...] evas supports opengl too. no it doesn't have an advantage, as glamo won't be doing opengl at VGA (the resolution of the device) so you won't be doing it for normal 2D UI's (thus my comments of it being of limited use for some fullscreen games for example where you drop to QVGA for the game). also the 256x256 max texture size leads to problems even if it could do VGA output. Oh this is a definitive limit, I would appreciate 3d acceleration to speedup everyday apps, and not some small 3d games, this is secondary for the freerunner actually. *) when necessary you can use directly Xlib because X is 2d accelerated ? you ALWAYS use xlib* - if you want to interact with x in any way. I mean, if my preferred toolkit does not advantages of hardware acceleration, I may use Xlib and call for example XCopyArea to do fast blits in video memory? I wrote a small code snippet to test XCopyArea performance, and it seems to do about 25fps smoothscrolling but at the cost of XGlamo using 70/80% of CPU. This seems very strange, it maybe my code is wrong (I repeat I'm not an expert :) ), or XCopyArea is not full accelerated, or Xglamo has to be optimized, or that the Glamo GPU is simply slow :) Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Thu, 20 Nov 2008 19:00:02 +0100 Nicola Mfb [EMAIL PROTECTED] babbled: 2008/11/18 The Rasterman Carsten Haitzler [EMAIL PROTECTED] [...] evas supports opengl too. no it doesn't have an advantage, as glamo won't be doing opengl at VGA (the resolution of the device) so you won't be doing it for normal 2D UI's (thus my comments of it being of limited use for some fullscreen games for example where you drop to QVGA for the game). also the 256x256 max texture size leads to problems even if it could do VGA output. Oh this is a definitive limit, I would appreciate 3d acceleration to speedup everyday apps, and not some small 3d games, this is secondary for the freerunner actually. *) when necessary you can use directly Xlib because X is 2d accelerated ? you ALWAYS use xlib* - if you want to interact with x in any way. I mean, if my preferred toolkit does not advantages of hardware acceleration, I may use Xlib and call for example XCopyArea to do fast blits in video memory? you can. I wrote a small code snippet to test XCopyArea performance, and it seems to do about 25fps smoothscrolling but at the cost of XGlamo using 70/80% of CPU. This seems very strange, it maybe my code is wrong (I repeat I'm not an expert :) ), or XCopyArea is not full accelerated, or Xglamo has to be optimized, or that the Glamo GPU is simply slow :) it's accelerated - but likely polling the command queue status as you have no interrupts thanks to the linux kernel's policy of not exporting interrupts to userspace, so you're stuck with a poll loop. i can't remember if glamo had a i'm done interrupt for the command queue or operations - i know it had several interrupts it can generate (but as the kernel wouldnt allow userspace to make use of them i pretty much ignored them). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Hi, On Fri, Nov 21, 2008 at 09:16:15AM +1100, Carsten Haitzler wrote: On Thu, 20 Nov 2008 19:00:02 +0100 Nicola Mfb [EMAIL PROTECTED] babbled: I wrote a small code snippet to test XCopyArea performance, and it seems to do about 25fps smoothscrolling but at the cost of XGlamo using 70/80% of CPU. This seems very strange, it maybe my code is wrong (I repeat I'm not an expert :) ), or XCopyArea is not full accelerated, or Xglamo has to be optimized, or that the Glamo GPU is simply slow :) it's accelerated - but likely polling the command queue status as you have no interrupts thanks to the linux kernel's policy of not exporting interrupts to userspace, so you're stuck with a poll loop. i can't remember if glamo had a i'm done interrupt for the command queue or operations - i know it had several interrupts it can generate (but as the kernel wouldnt allow userspace to make use of them i pretty much ignored them). ??? What's wrong with: interrupt handler - wait queue - file operations read/poll? Greetings, Sascha ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Fri, 21 Nov 2008 02:18:25 +0100 Sascha Wessel [EMAIL PROTECTED] babbled: Hi, On Fri, Nov 21, 2008 at 09:16:15AM +1100, Carsten Haitzler wrote: On Thu, 20 Nov 2008 19:00:02 +0100 Nicola Mfb [EMAIL PROTECTED] babbled: I wrote a small code snippet to test XCopyArea performance, and it seems to do about 25fps smoothscrolling but at the cost of XGlamo using 70/80% of CPU. This seems very strange, it maybe my code is wrong (I repeat I'm not an expert :) ), or XCopyArea is not full accelerated, or Xglamo has to be optimized, or that the Glamo GPU is simply slow :) it's accelerated - but likely polling the command queue status as you have no interrupts thanks to the linux kernel's policy of not exporting interrupts to userspace, so you're stuck with a poll loop. i can't remember if glamo had a i'm done interrupt for the command queue or operations - i know it had several interrupts it can generate (but as the kernel wouldnt allow userspace to make use of them i pretty much ignored them). ??? What's wrong with: interrupt handler - wait queue - file operations read/poll? the policy of the kernel developers is not to export interrupts to usersapce in a generic way - or it hasn't been in the past. this may have changed recently. so u can patch and create a specific driver just for glamo just to export an interrupt - and it'll never go upstream most likely, and the kernel supports no generic hook to an interrupt from userspace. one way or another something will block your path (be it getting patches upstream back to mainline kernel or just living without interrupts etc.). this is last i checked. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Hi, On Fri, Nov 21, 2008 at 12:28:44PM +1100, Carsten Haitzler wrote: the policy of the kernel developers is not to export interrupts to usersapce in a generic way - or it hasn't been in the past. this may have changed recently. so u can patch and create a specific driver just for glamo just to export an interrupt - and it'll never go upstream most likely, and the kernel supports no generic hook to an interrupt from userspace. one way or another something will block your path (be it getting patches upstream back to mainline kernel or just living without interrupts etc.). this is last i checked. I have never tried it but userspace i/o [1] is a more or less generic way to export interrupts to userspace (in the kernel since ~2.6.23). Greetings, Sascha [1] http://www.kernel.org/doc/htmldocs/uio-howto/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Fri, 21 Nov 2008 04:11:58 +0100 Sascha Wessel [EMAIL PROTECTED] babbled: Hi, On Fri, Nov 21, 2008 at 12:28:44PM +1100, Carsten Haitzler wrote: the policy of the kernel developers is not to export interrupts to usersapce in a generic way - or it hasn't been in the past. this may have changed recently. so u can patch and create a specific driver just for glamo just to export an interrupt - and it'll never go upstream most likely, and the kernel supports no generic hook to an interrupt from userspace. one way or another something will block your path (be it getting patches upstream back to mainline kernel or just living without interrupts etc.). this is last i checked. I have never tried it but userspace i/o [1] is a more or less generic way to export interrupts to userspace (in the kernel since ~2.6.23). this is relatively new. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Lally, how long is OM going to be using the Glamo? The glamo will be kept for the lifetime of gta02, i.e. every gta02 will have the glamo chip. For gta03, release date unknown, the decision is to not have a glamo, we use the acceleration of the SoC. The GTA02's been on the brink of obsolescence since the day it was introduced. Don't agree with you. In the long run everything is obsolete. GTA02 is a real pioneering device for Linux in mobile phones, and is still advancing the state of Free Software in mobile phones in many areas. We owe the community better hardware, and have made decisions internally to only focus on hardware and lower-level software. But that will not remove the pioneering status of GTA02, not even when GTA03 ships, again release date unknown at this point. It can't even take most modern (3G) SIMs. Thanks to great work from Dieter, Joerg and Werner, this bug (trac #666) seems to be fixed now, GSM reflash utility and instructions are available, etc. Next they target trac #1024 (network re-registration). If the Glamo (or something compatible) is going to be around for a while, either in a long production life of the GTA02, or in newer phones, Long production life of GTA02. Hence, my earlier suggestion on just using the acceleration for some Gtk operations. Small, effective changes. Get that done to make the device feel responsive. If someone wants to do the big OpenGL implementation later, fine, use this Gtk work as a sandbox for getting a feel for the device. Very good idea. I always prefer breaking a large idea into smaller pieces. $400 for a phone is a reasonable investment. But months of work in one's spare time is much bigger. Before anyone commits to a large-scale project, I think it's fair to ask OM what their plans are with this chip. Absolutely. I have already answered many aspects in other mails, but let me summarize again: 1. We currently are disappointed about s-media. To be fair to them I do not want to quote from contracts we have with them, but let me tell you at the bottom line we feel there have been some broken promises with regards to opening documentation. 2. Because of this situation, we decided to not use s-media chips in future Openmoko products. 3. At the same time, we decided to not come out with GTA02 versions that had the glamo removed, because that would have been hard to do technically, and it would have created too much technical fragmentation. 4. Even with raster's bashing, the glamo chip is a really nice mobile graphics chip. I say this also considering when it was released. Openmoko's speed of progress still does not match industry speed. While the other (closed) chip vendors are already 2 generations ahead, we (Openmoko and the Free Software community) are still writing drivers for older chips. But we shouldn't let others distract us. Our software is 100% Free Software. We want to be able to install mainline kernel.org kernels one day. We want to be able to run many Linux distributions on the phone one day. We are coming from behind, but I'm sure with the help of the community we can even drag something like the glamo out into the open. 5. We will have the same problem with open 2D/3D acceleration again in the future, so breaking the glamo free could be considered a good 'exercise'. No matter whether you look at future Samsung, TI, Marvell chips. The 3D acceleration part is always closed. In other words needs to be opened by us. We might as well start with the glamo now, better than waiting for the 'perfect moment' which will never come... Best Regards, Wolfgang On Nov 17, 2008, at 3:40 PM, Lally Singh wrote: Well then, Therein lies the question, how long is OM going to be using the Glamo? There's apparently some real potential in the device, but that's really measured as much by the chip's relevance as its functionality. The GTA02's been on the brink of obsolescence since the day it was introduced. It can't even take most modern (3G) SIMs. If the Glamo (or something compatible) is going to be around for a while, either in a long production life of the GTA02, or in newer phones, then all this makes sound engineering sense to work on. Otherwise, I have real doubts about the longevity of a software project aggressive enough to attempt major work (e.g. accellerated OpenGL) on this chip. Lots of open source projects start off with a bang of enthusiasm, and die with a whimper. If the chip's gone in a few months, I don't think we'll see the project survive. Hence, my earlier suggestion on just using the acceleration for some Gtk operations. Small, effective changes. Get that done to make the device feel responsive. If someone wants to do the big OpenGL implementation later, fine, use this Gtk work as a sandbox for getting a feel for the device. $400 for a phone is a reasonable investment. But months of work in one's spare
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Fri, 21 Nov 2008 11:59:42 +0800 Wolfgang Spraul [EMAIL PROTECTED] babbled: Lally, how long is OM going to be using the Glamo? The glamo will be kept for the lifetime of gta02, i.e. every gta02 will have the glamo chip. For gta03, release date unknown, the decision is to not have a glamo, we use the acceleration of the SoC. The GTA02's been on the brink of obsolescence since the day it was introduced. Don't agree with you. In the long run everything is obsolete. i think he is referring to using an old soc, old gfx chip etc. something that has been out for many years - where the competition (not in open phones, but in phones in general) is busy building new devices on chips not yet in mass production as they follow the curve and by the time it is in production - their device is ready. it's perfectly understandable why openmoko is building on an old platform - but it still makes the hardware very much behind the curve :) GTA02 is a real pioneering device for Linux in mobile phones, and is still advancing the state of Free Software in mobile phones in many areas. We owe the community better hardware, and have made decisions internally to only focus on hardware and lower-level software. But that will not remove the pioneering status of GTA02, not even when GTA03 ships, again release date unknown at this point. It can't even take most modern (3G) SIMs. Thanks to great work from Dieter, Joerg and Werner, this bug (trac #666) seems to be fixed now, GSM reflash utility and instructions are available, etc. Next they target trac #1024 (network re-registration). If the Glamo (or something compatible) is going to be around for a while, either in a long production life of the GTA02, or in newer phones, Long production life of GTA02. Hence, my earlier suggestion on just using the acceleration for some Gtk operations. Small, effective changes. Get that done to make the device feel responsive. If someone wants to do the big OpenGL implementation later, fine, use this Gtk work as a sandbox for getting a feel for the device. Very good idea. I always prefer breaking a large idea into smaller pieces. one thing everyone seems to think that is wrong. this gtk acceleration is already done. blits, fills. xvideo too. :) aa text isn't possible as the glamo doesn't meet xrender specs for doing aa text, so it's software or bust (unless you upload ARGB glyphs and pre-colour them. the end result will be slower rendering that current software - that's my bet). so you are about as good as it gets - acceleration-wise for gtk (2d). only thing that could be done is some basic xrender accel (composite ARGB32 src to rgb565 dest if src and dest 640x640). and that also involves having to have uploaded the ARGB32 pixel source first - which is double the bandwidth needs of 16bit... across the bus to the glamo (thus why i originally was so focused on trying to squeeze more out of that bus - that is a real killer). so right now other than bugs and trying to minimise cpu overhead on handling the commandqueue 2d is done - it's not getting faster. only thing left is 3d. and that comes with a long list of gotchas. this is the bit where someone needs to make a call on what is the effort needed, and the result. this is up to openmoko to decide what to do as the docs are in their hands. 2d is pretty much done. :) $400 for a phone is a reasonable investment. But months of work in one's spare time is much bigger. Before anyone commits to a large-scale project, I think it's fair to ask OM what their plans are with this chip. Absolutely. I have already answered many aspects in other mails, but let me summarize again: 1. We currently are disappointed about s-media. To be fair to them I do not want to quote from contracts we have with them, but let me tell you at the bottom line we feel there have been some broken promises with regards to opening documentation. 2. Because of this situation, we decided to not use s-media chips in future Openmoko products. 3. At the same time, we decided to not come out with GTA02 versions that had the glamo removed, because that would have been hard to do technically, and it would have created too much technical fragmentation. 4. Even with raster's bashing, the glamo chip is a really nice mobile it's a professional opinion based on what i have seen in my years of doing graphics. i think it's a very very weak graphics chip with lots of missing holes in its featureset - given the kind of screen attached to it and the OS and windowing system as well as the goals and desires of users. if you take the OS and windowing system and goals as a given, the weak point is the glamo. a spade is a spade. :) you can cover it with topping all you like. :) graphics chip. I say this also considering when it was released. indeed. when it was released it was good. but that was long ago. i agree here. in the
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Wolfgang, Raster: On Thu, Nov 20, 2008 at 11:28 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: The GTA02's been on the brink of obsolescence since the day it was introduced. Don't agree with you. In the long run everything is obsolete. i think he is referring to using an old soc, old gfx chip etc. something that has been out for many years - where the competition (not in open phones, but in phones in general) is busy building new devices on chips not yet in mass production as they follow the curve and by the time it is in production - their device is ready. it's perfectly understandable why openmoko is building on an old platform - but it still makes the hardware very much behind the curve :) I suspect the Glamo was designed for a much less sophisticated setup, with a lower-res screen and probably a slower CPU. Hence the texture sizes and I/O speed limitations -- choices made for cost power. snip If the Glamo (or something compatible) is going to be around for a while, either in a long production life of the GTA02, or in newer phones, Long production life of GTA02. I'm all for longer production lives. But, IMHO in the next incarnation, some more thought to a longer useful life should be given. Specifically, a few more ports on the device are necessary to keep its useful life long. LInuxer's will add drivers for new devices as they come, extending the life of the device, but we need I/O. Additionally, the components chosen shouldn't be as overtaxed from the beginning as the glamo. Only after the driving software has been written does a team find out the real limitations of the device. Started from a burdened position usually only leads downward after trying to get aggressive on the software side. IMHO 3D was/is a great idea, so I can't blame OM for trying with the glamo. But there are alwasy some lessons to come out any development effort. Finally, the next device should have stable support for basic phone operation when it's released: suspend, resume, calling, and answer-while-suspended. Without that, it's hard to get the imagination going for what else to do with the phone. The GTA02's release should have been in two phases for hackers and users. The former as it was, the latter after those functions were stable. If that's not possible for the GTA03, then a two-phase release is appropriate for it, too. The nice consequence of it is that it brings in larger community participation of the device's commercial lifecycle, which will lead to a better feeling of community ownership over it. I admit I was quite embarrassed to show the device off upon reception, considering how really raw it was. I'm happy with the results of the optimization team, and it looks like OM's going the right way now. But it was quite painful for too long, and shouldn't be repeated. Hence, my earlier suggestion on just using the acceleration for some Gtk operations. Small, effective changes. Get that done to make the device feel responsive. If someone wants to do the big OpenGL implementation later, fine, use this Gtk work as a sandbox for getting a feel for the device. Very good idea. I always prefer breaking a large idea into smaller pieces. one thing everyone seems to think that is wrong. this gtk acceleration is already done. blits, fills. xvideo too. :) snip so right now other than bugs and trying to minimise cpu overhead on handling the commandqueue 2d is done - it's not getting faster. only thing left is 3d. and that comes with a long list of gotchas. this is the bit where someone needs to make a call on what is the effort needed, and the result. this is up to openmoko to decide what to do as the docs are in their hands. 2d is pretty much done. :) As Raster's already pushed hard on Glamo acceleration, and I know he's quite capable (I was an old enlightenment WM user back in the day), I consider the glamo issue closed. We're stuck with what we have, and simply have to find ways to be efficient with what what's already there. 1. We currently are disappointed about s-media. To be fair to them I do not want to quote from contracts we have with them, but let me tell you at the bottom line we feel there have been some broken promises with regards to opening documentation. 2. Because of this situation, we decided to not use s-media chips in future Openmoko products. 3. At the same time, we decided to not come out with GTA02 versions that had the glamo removed, because that would have been hard to do technically, and it would have created too much technical fragmentation. 4. Even with raster's bashing, the glamo chip is a really nice mobile That isn't stuff you could've known before committing this far. I'm sorry it happened to a platform I like so much. I support your decision of keeping it in, otherwise you'd lose a lot of your community. Nobody likes buying an iPod the day before the new ones come out. 3D was the right way
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
For those of you who are interested in the fltkwish package for the FR,
I have added a couple of ipk packages to the SF repository. The fb2image
package is a small screen shot utility that is capable of generating
either png or jpg images from a sub-window of the FR screen. The
fltkwishlibs package contains the pre-built Tcl 8.4, Mesa 7.03 (OpenGL,
GLU) and TIFF 3.0 libs. All of this is installed under the /usr/local
path, which I have on my SD card to save space on the FR itself.
The sources for these libs are widely available on the net, and the
binaries are just builds of the unmodified sources using the ARM tool chain.
Have fun. Send complaints to my regular e-mail.
Iain F.
Iain B. Findleton wrote:
Okay, for those of you who would like to test out this thing on your FR,
you can get an ipk from the fltkwish project on sourceforge.net. Once
you have Tcl on your phone (opkg install tcl), and the required
graphics libraries, you can do a quick test with the following script:
#!/bin/sh
# \
exec fltkwish $0 ${1+$@}
#
# Create an Image widget and load up a file
#
Image t.t -f myfile.jpg -w 460 -h 570 -autoscale false -center false;
Show t
You can now drag the image about with your finger, or pen. On my machine
the dragging is nice and smooth. You should have an image that is bigger
than the display screen to fully appreciate the results.
If you have troubles, and if you have read the documentation and still
have troubles, feel free to contact me.
Iain F.
Petr Vanek wrote:
On Tue, 18 Nov 2008 10:58:41 -0500
Iain B. Findleton
[EMAIL PROTECTED] (IBF) wrote:
No problem, although my setup is not opkg ready yet. As my stuff uses
Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you
are a Linux handyman type, it can be done. Otherwise, it will have to
wait until I get around to package it all up...
Yes please, do share anyways,
thank you
Petr
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
--
Iain B. Findleton
Tel: 514-457-0744
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
2008/11/17 The Rasterman Carsten Haitzler [EMAIL PROTECTED] [...] no - it's not possible to do a scroll (via blit) as you have alpha channels, layered objects etc. etc. - just trust me in that the cost of trying to figure out a blit - if it is possible is probably much higher than the cost of just doing a redraw in almost all cases - the upload speed of the glamo is so low though that it may just be worth it... I understand and trust your huge experience :), so correct me where wrong, I'm not expert but I'd like to have an high level view on this: *) standard toolkit do complex operation so it's simple/better recompute and upload the view, this means that porting existing software based on them may result in slow performance. *) toolkits that advantages of OpenGL to accelerate its widgets (for example Qt let you choose an opengl viewport for their canvas implementation) does not advantage as Glamo has only 2d acceleration. *) when necessary you can use directly Xlib because X is 2d accelerated ? *) when necessary you may use lowlevel library/toolkit to bypass X overhead and use accelerated 2d graphics (sdl?) ? *) about video streams, bandwidth is not an issue if decoding mpeg4 in glamo, but is a issue if you decode the stream with the main CPU and upload the frames to the glamo? *) glamo will be abandoned, the cost to develop a 3d driver is very high, what's about completing 2d acceleration and mpeg4 hardware decoding? *) the community may produce now or at later time the wanted 3d driver, but this is hard as openmoko has to extend the nda in some legal way Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
2008/11/17 Iain B. Findleton [EMAIL PROTECTED] I have implemented an image display script on the FR that demonstrates smooth scroll in the form of dragging the image about the screen. Works for fairly large images (colour weather maps of North America). The application uses the FLTK tool kit with double buffering through X. May you share it? Thanks Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
No problem, although my setup is not opkg ready yet. As my stuff uses Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you are a Linux handyman type, it can be done. Otherwise, it will have to wait until I get around to package it all up... Nicola Mfb wrote: 2008/11/17 Iain B. Findleton [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] I have implemented an image display script on the FR that demonstrates smooth scroll in the form of dragging the image about the screen. Works for fairly large images (colour weather maps of North America). The application uses the FLTK tool kit with double buffering through X. May you share it? Thanks Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Tue, 18 Nov 2008 10:58:41 -0500 Iain B. Findleton [EMAIL PROTECTED] (IBF) wrote: No problem, although my setup is not opkg ready yet. As my stuff uses Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you are a Linux handyman type, it can be done. Otherwise, it will have to wait until I get around to package it all up... Yes please, do share anyways, thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Okay, for those of you who would like to test out this thing on your FR,
you can get an ipk from the fltkwish project on sourceforge.net. Once
you have Tcl on your phone (opkg install tcl), and the required
graphics libraries, you can do a quick test with the following script:
#!/bin/sh
# \
exec fltkwish $0 ${1+$@}
#
# Create an Image widget and load up a file
#
Image t.t -f myfile.jpg -w 460 -h 570 -autoscale false -center false;
Show t
You can now drag the image about with your finger, or pen. On my machine
the dragging is nice and smooth. You should have an image that is bigger
than the display screen to fully appreciate the results.
If you have troubles, and if you have read the documentation and still
have troubles, feel free to contact me.
Iain F.
Petr Vanek wrote:
On Tue, 18 Nov 2008 10:58:41 -0500
Iain B. Findleton
[EMAIL PROTECTED] (IBF) wrote:
No problem, although my setup is not opkg ready yet. As my stuff uses
Tcl, libjpeg,libpng,libtiff, the setup is not pretty yet, but if you
are a Linux handyman type, it can be done. Otherwise, it will have to
wait until I get around to package it all up...
Yes please, do share anyways,
thank you
Petr
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
--
Iain B. Findleton
Tel: 514-457-0744
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Tue, 18 Nov 2008 15:01:51 +0100 Nicola Mfb [EMAIL PROTECTED] babbled: 2008/11/17 The Rasterman Carsten Haitzler [EMAIL PROTECTED] [...] no - it's not possible to do a scroll (via blit) as you have alpha channels, layered objects etc. etc. - just trust me in that the cost of trying to figure out a blit - if it is possible is probably much higher than the cost of just doing a redraw in almost all cases - the upload speed of the glamo is so low though that it may just be worth it... I understand and trust your huge experience :), so correct me where wrong, I'm not expert but I'd like to have an high level view on this: *) standard toolkit do complex operation so it's simple/better recompute and upload the view, this means that porting existing software based on them may result in slow performance. it depends. its a tradeoff of flexibility and power to change the look and feel of things vs cost. *) toolkits that advantages of OpenGL to accelerate its widgets (for example Qt let you choose an opengl viewport for their canvas implementation) does not advantage as Glamo has only 2d acceleration. evas supports opengl too. no it doesn't have an advantage, as glamo won't be doing opengl at VGA (the resolution of the device) so you won't be doing it for normal 2D UI's (thus my comments of it being of limited use for some fullscreen games for example where you drop to QVGA for the game). also the 256x256 max texture size leads to problems even if it could do VGA output. you'd need to now do texture meshes - and these are nasty if you want scaling to work right (with interpolation and/or mipmaps, anisotropic filtering etc. etc. - in the more general case). *) when necessary you can use directly Xlib because X is 2d accelerated ? you ALWAYS use xlib* - if you want to interact with x in any way. (* or xcb... or write your own x protocol but same - both are x protocol wrapper libraries.) *) when necessary you may use lowlevel library/toolkit to bypass X overhead and use accelerated 2d graphics (sdl?) ? sdl offers screen setup - not acceleration (really - ok for some specific things it wraps that too - but not in general). sdl USES x. same as anyone else (i am ignoring using sdl on the framebuffer - that's no different to using the fb directly). *) about video streams, bandwidth is not an issue if decoding mpeg4 in glamo, but is a issue if you decode the stream with the main CPU and upload the frames to the glamo? yes. it's an issue in this case. decoding mpeg4 on glamo is problematic due to audio not being decoded on the glamo and having to synchronise. all uploads to video block the cpu so you have no cycles to decode the next frame while uploading the current one (slowly). same with ANY pixel uploads. *) glamo will be abandoned, the cost to develop a 3d driver is very high, what's about completing 2d acceleration and mpeg4 hardware decoding? imho it'd dubiously useful - sure. it works. the audio issues, synchronisation, there being no standard x extension/mechanism to upload codec data (having to invent one - this is though a very worthy idea) etc. *) the community may produce now or at later time the wanted 3d driver, but this is hard as openmoko has to extend the nda in some legal way om can't. unless you work for om. smedia control the nda - not om. Regards Nicola -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Mon, 17 Nov 2008 02:40:19 -0500 Lally Singh [EMAIL PROTECTED] babbled: Well then, Therein lies the question, how long is OM going to be using the Glamo? There's apparently some real potential in the device, but that's really measured as much by the chip's relevance as its functionality. this is the problem. glamo is not used anywhere else on any linux/x running devices. it's a one-shot wonder so far in the gta02. as best i know there are no plans to use it again. it's an end-of-life chip anyway - it's old and has been out for a long time so even if you wanted to - it may not be available anymore in the near future (unknown - but likely scenario). in the end - you need to weigh up effort vs. return on effort. the glamo itself actually is quite limited. trust me. when i first just read the bullet point featurelist i too was excited... then i actually read all the nitty details and the gotchas, the only in this situation, only with these inputs or outputs or only within these parameters and my excitements dwindled very quickly. you'll have to jump through some nasty hoops just to get a bit more accel - and as i made a bet long ago, and i still stand by it. you'll spend a lot of code doing a lot of acceleration and you will actually... not be faster. for most things. the only thing that has anything of vague interest is opengl-es - and even then here are some bullet points for limitations: 1. 256x256 max texture size (for vga and 2d this is just appaling in this day and age) 2. max output buffer 511x511 (that means... qvga boys. and right now.. qvga doesn't even work as the pixel timings aren't right). 3. no render-to-texture 4. texture uploads are slow (7m/sec) combined with only 8m video ram 5. if you saw the 3d docs... they are scant at best (register names pretty much) and not much else. now add to this having to merge it with 2d (texture allocation shared with pixmap), the only thing i see gl being useful for is some limited 3d games that are fullscreen (drop to qvga). qvga on the lcd actually looks rather awful (very blocky) as well... i'm not saying don't do it. i'm saying you need to look at what you have, the effort needed, the return on effort, the results, and the future. The GTA02's been on the brink of obsolescence since the day it was introduced. It can't even take most modern (3G) SIMs. If the Glamo (or something compatible) is going to be around for a while, either in a long production life of the GTA02, or in newer phones, then all this makes sound engineering sense to work on. Otherwise, I have real doubts about the longevity of a software project aggressive enough to attempt major work (e.g. accellerated OpenGL) on this chip. Lots of open source projects start off with a bang of enthusiasm, and die with a whimper. If the chip's gone in a few months, I don't think we'll see the project survive. Hence, my earlier suggestion on just using the acceleration for some Gtk operations. Small, effective changes. Get that done to make the device feel responsive. If someone wants to do the big OpenGL implementation later, fine, use this Gtk work as a sandbox for getting a feel for the device. this is the thing.. the drvier is ALREADY doing this. i repeat this ad-nauseum. the acceleration is the same u get in the nv driver or you saw a few years back in the i8xx drivers etc. you get blit and fill accelerated (the most common x ops). xvideo is accelerated. the only thing not is anti-aliases font drawing and as such the glamo doesnt support this fully - u need to do some hacks to pretend it will (like expand fonts to ARGB32 in software) and from the look of it the expansion and then upload of pixels will likely net you zero speedup as this extra cost will negate the speedups you get. imho glamo is right now about as fast as u'll ever likely see it (imho). you can go sink a mountain of work and as per the example above.. see no return. the ONLY thing that i can see it might be worth it is opengl - and even then its a very weak opengl accelerator with lots of gotchas. all of the above of course is in my opinion. it's based from years of doing graphics - software and hardware and with x, and having read all of the glamo docs. the original hope was to do the most urgent acceleration that can be done cleanly and get 90% done (which is where it is at), and then open the docs so people can tweak - thats the point of an open device. openmoko can't go supporting some ancient device forever and ever - in 3 years will people still be demanding updates and support? thats the point of it being open - you can support yourselves via community. the problem is the fact that the docs are not open to allow this to happen so there is a problem here. i know so many of you are all excited over Accelerating glamo - it's already done (for 2d) as much as is probably practical for x11 that will get you speedups. 3d is possible but with a hefty list of limitations and a lot of
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
2008/11/17 Lally Singh [EMAIL PROTECTED]: $400 for a phone is a reasonable investment. But months of work in one's spare time is much bigger. Before anyone commits to a large-scale project, I think it's fair to ask OM what their plans are with this chip. Hey people, please don't underestimate the general willingness to hack stuff :) Most of us don't think about value-for-money, sensibility or other minor aspects. Coding is fun! That's why we have accelerometer-controlled Doom working fluently before phone calls, and I think it's great ;) So I don't think there's any value discussing how sensible / meaningful / valuable doing OpenGL support would be. If there are people interested, that's great and it's not cutting anything away from somewhere else. Volunteer people need to do what they like to do, not what's the most sensible product-wise. And we already have eg. partial MPEG4 hw decoding using Glamo, imagine if the developer of that would have been told don't waste your time on something like that. -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Mon, Nov 17, 2008 at 5:52 AM, Timo Jyrinki [EMAIL PROTECTED]wrote: Coding is fun! That's why we have accelerometer-controlled Doom working fluently before phone calls, and I think it's great ;) I'm just starting my day here on the East coast of the U.S.. I'm confident what you just wrote will be the funniest thing I encounter all day. -Charles Pax ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | On Sun, Nov 16, 2008 at 4:34 PM, Andy Green [EMAIL PROTECTED] wrote: | FWIW I talked this over with an experienced 3D guy recently about | something related and he was all in favour of discarding the kdrive | implementation and making a pure xorg one as a way forward: he told that | kdrive itself was long dead. I also know that XGlamo is not that great | Just fair warning here. As I don't think OM will use the Glamo in | future devices, doing the right thing isn't as critical as normal | software projects. Spend the energy making the best performing, most | functional implementation possible. If that goal's met, *then* go | back and shove it into Xorg. We don't plan to use Glamo at the moment, but we do seem to be planning and are working twoards using xorg everywhere. It makes sense to have a consistent strategy for it across all the devices using the best solution. More developers are likely to want to expend effort to get experience with xorg / GLX type solution than known-deprecated kdrive / lashup implementation. If you look at GTA01 experience, that is still a living device running current rootfs, we can expect GTA02 to have similar long life, we should also make architectural decisions with that in mind I think. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkhT3MACgkQOjLpvpq7dMp8BACffuMTO4LWmoPpsIkqKoI4cCIO 35gAoICe9V8TsLesAtddradgxsOsrdsY =H9Ot -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
2008/11/17 The Rasterman Carsten Haitzler [EMAIL PROTECTED] [...] this is the thing.. the drvier is ALREADY doing this. i repeat this ad-nauseum. the acceleration is the same u get in the nv driver or you saw a few years back in the i8xx drivers etc. you get blit and fill accelerated (the most common x ops). xvideo is accelerated. the only thing not is anti-aliases font drawing and as such the glamo doesnt support this fully - u need to do some hacks to pretend it will (like expand fonts to ARGB32 in software) and from the look of it the expansion and then upload of pixels will likely net you zero speedup as this extra cost will negate the speedups you get. imho glamo is right now about as fast as u'll ever likely see it (imho). you can go sink a mountain of work and as per the example above.. see no return. the ONLY thing that i can see it might be worth it is opengl - and even then its a very weak opengl accelerator with lots of gotchas. all of the above of course is in my opinion. it's based from years of doing graphics - software and hardware and with x, and having read all of the glamo docs. Hi Raster! before reading this post I supposed that 2d acceleration was very partially implemented. This cames out for example because I never see a smooth scroll on the device. So what is the reason for this? glamo? 2d acceleration driver? poor graphics toolkit? Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Mon, 17 Nov 2008 14:30:31 +0100 Nicola Mfb [EMAIL PROTECTED] babbled: Hi Raster! before reading this post I supposed that 2d acceleration was very partially implemented. This cames out for example because I never see a smooth scroll on the device. So what is the reason for this? glamo? 2d acceleration driver? poor graphics toolkit? depends on the toolkit and how ti does it. efl doesn't use any blitting at all for scrolling. it's a redraw - thus a re-compute of pixels and write to screen. i won't go into the details why - but they are complex. glamo can't do enough to cover the accelerated paths (xrender for example) so you get s a software re-compute. no - it's not possible to do a scroll (via blit) as you have alpha channels, layered objects etc. etc. - just trust me in that the cost of trying to figure out a blit - if it is possible is probably much higher than the cost of just doing a redraw in almost all cases - the upload speed of the glamo is so low though that it may just be worth it... but i don't intend to bother as the glamo on the freerunner is a complete anomaly in terms of performance and i have other much better and more important platforms to support as well :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
I have implemented an image display script on the FR that demonstrates smooth scroll in the form of dragging the image about the screen. Works for fairly large images (colour weather maps of North America). The application uses the FLTK tool kit with double buffering through X. Nicola Mfb wrote: 2008/11/17 The Rasterman Carsten Haitzler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [...] this is the thing.. the drvier is ALREADY doing this. i repeat this ad-nauseum. the acceleration is the same u get in the nv driver or you saw a few years back in the i8xx drivers etc. you get blit and fill accelerated (the most common x ops). xvideo is accelerated. the only thing not is anti-aliases font drawing and as such the glamo doesnt support this fully - u need to do some hacks to pretend it will (like expand fonts to ARGB32 in software) and from the look of it the expansion and then upload of pixels will likely net you zero speedup as this extra cost will negate the speedups you get. imho glamo is right now about as fast as u'll ever likely see it (imho). you can go sink a mountain of work and as per the example above.. see no return. the ONLY thing that i can see it might be worth it is opengl - and even then its a very weak opengl accelerator with lots of gotchas. all of the above of course is in my opinion. it's based from years of doing graphics - software and hardware and with x, and having read all of the glamo docs. Hi Raster! before reading this post I supposed that 2d acceleration was very partially implemented. This cames out for example because I never see a smooth scroll on the device. So what is the reason for this? glamo? 2d acceleration driver? poor graphics toolkit? Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
If we work on having x.org server working on the FR, wouldn't that help for whatever comes next?. At least we would have some working knowledge on how to develop drivers for X, and a team of programmers with ample knowledge on all things regarding the x.org Server. I mean, the thing is modularized. Is it not simpler to just replace the glamo driver with the [whatever\] driver? On Mon, Nov 17, 2008 at 11:48 AM, Iain B. Findleton [EMAIL PROTECTED] wrote: I have implemented an image display script on the FR that demonstrates smooth scroll in the form of dragging the image about the screen. Works for fairly large images (colour weather maps of North America). The application uses the FLTK tool kit with double buffering through X. Nicola Mfb wrote: 2008/11/17 The Rasterman Carsten Haitzler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [...] this is the thing.. the drvier is ALREADY doing this. i repeat this ad-nauseum. the acceleration is the same u get in the nv driver or you saw a few years back in the i8xx drivers etc. you get blit and fill accelerated (the most common x ops). xvideo is accelerated. the only thing not is anti-aliases font drawing and as such the glamo doesnt support this fully - u need to do some hacks to pretend it will (like expand fonts to ARGB32 in software) and from the look of it the expansion and then upload of pixels will likely net you zero speedup as this extra cost will negate the speedups you get. imho glamo is right now about as fast as u'll ever likely see it (imho). you can go sink a mountain of work and as per the example above.. see no return. the ONLY thing that i can see it might be worth it is opengl - and even then its a very weak opengl accelerator with lots of gotchas. all of the above of course is in my opinion. it's based from years of doing graphics - software and hardware and with x, and having read all of the glamo docs. Hi Raster! before reading this post I supposed that 2d acceleration was very partially implemented. This cames out for example because I never see a smooth scroll on the device. So what is the reason for this? glamo? 2d acceleration driver? poor graphics toolkit? Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ 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: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Mon, 2008-11-17 at 11:58 -0500, Aliner wrote: If we work on having x.org server working on the FR, wouldn't that help for whatever comes next?. At least we would have some working knowledge on how to develop drivers for X, and a team of programmers with ample knowledge on all things regarding the x.org Server. I mean, the thing is modularized. Is it not simpler to just replace the glamo driver with the [whatever\] driver? Basically yes, the advantages of Xorg are active development and familiarity with developers as comapred to kdrive based stuff. At the moment Xorg with tslib/fbdev drivers works well on GTA02 my task now is to make a glamo driver for Xorg based on the Xglamo code. Graeme ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Mon, Nov 17, 2008 at 12:06 PM, Graeme Gregory [EMAIL PROTECTED]wrote: On Mon, 2008-11-17 at 11:58 -0500, Aliner wrote: If we work on having x.org server working on the FR, wouldn't that help for whatever comes next?. At least we would have some working knowledge on how to develop drivers for X, and a team of programmers with ample knowledge on all things regarding the x.org Server. I mean, the thing is modularized. Is it not simpler to just replace the glamo driver with the [whatever\] driver? Basically yes, the advantages of Xorg are active development and familiarity with developers as comapred to kdrive based stuff. At the moment Xorg with tslib/fbdev drivers works well on GTA02 my task now is to make a glamo driver for Xorg based on the Xglamo code. Do you have the instructions to build Xorg with the toolchain? Graeme ___ 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: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Mon, 2008-11-17 at 12:12 -0500, Aliner wrote: On Mon, Nov 17, 2008 at 12:06 PM, Graeme Gregory [EMAIL PROTECTED] wrote: On Mon, 2008-11-17 at 11:58 -0500, Aliner wrote: If we work on having x.org server working on the FR, wouldn't that help for whatever comes next?. At least we would have some working knowledge on how to develop drivers for X, and a team of programmers with ample knowledge on all things regarding the x.org Server. I mean, the thing is modularized. Is it not simpler to just replace the glamo driver with the [whatever\] driver? Basically yes, the advantages of Xorg are active development and familiarity with developers as comapred to kdrive based stuff. At the moment Xorg with tslib/fbdev drivers works well on GTA02 my task now is to make a glamo driver for Xorg based on the Xglamo code. Do you have the instructions to build Xorg with the toolchain? No, Im an OE guy so I use OE as my toolchain. Graeme ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Mon, Nov 17, 2008 at 6:12 PM, Aliner [EMAIL PROTECTED] wrote: On Mon, Nov 17, 2008 at 12:06 PM, Graeme Gregory [EMAIL PROTECTED]wrote: On Mon, 2008-11-17 at 11:58 -0500, Aliner wrote: If we work on having x.org server working on the FR, wouldn't that help for whatever comes next?. At least we would have some working knowledge on how to develop drivers for X, and a team of programmers with ample knowledge on all things regarding the x.org Server. I mean, the thing is modularized. Is it not simpler to just replace the glamo driver with the [whatever\] driver? Basically yes, the advantages of Xorg are active development and familiarity with developers as comapred to kdrive based stuff. At the moment Xorg with tslib/fbdev drivers works well on GTA02 my task now is to make a glamo driver for Xorg based on the Xglamo code. Do you have the instructions to build Xorg with the toolchain? Graeme ___ 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 I thought Debian on the FR started with X by default? Testing that would give you a quick comparison if you didn't feel like building X. Also, kdrive is part of Xorg now, so you just simply pass it the --enable-kdrive flag at compile time according to information at freedesktop.org [1]. -Jacob [1] http://www.freedesktop.org/wiki/Software/Xserver ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Jacob Peterson wrote: There has been some discussion on the recently about the Glamo and OpenGL where Wolfgang called for serious developers to get in touch with him and he would see what could be done about getting access to the NDA'ed Glamo documents [1]. A couple of developers responded saying they were interested. I would like to see how many people are interested and willing to commit to working on and OpenGL driver in this thread. If there is enough interest I will start a project one projects.openmoko.org http://projects.openmoko.org and then we can work with Openmoko on the legal aspects of the NDA. So please, if you are interested and motivated lets discuss it here, then we can work on getting the rest in motion. What about cross-posting this also to mesa-devel and dri-devel? -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
You can count me in. I have experience doing kernel development. Since the documentation is not available, I saw a couple of pointers on how to start on the nouveau project. They have an excellent section on tools and documentation. http://nouveau.freedesktoplorg/wiki. I have some questions, the glamo chip contains 3d support, what version of OpenGL (or OpenGL ES) is implemented? Are we still going to keep Xglamo (kdrive) or are we goint to use X.org server? (this question arised after Rastermans e-mail) Are we going to support full OpenGL or OpenGL ES on the implementation? Or is it going to be a OpenGL driver and a OpenGL ES driver? Thank you On Sun, Nov 16, 2008 at 2:11 PM, Marco Trevisan (Treviño) [EMAIL PROTECTED]wrote: Jacob Peterson wrote: There has been some discussion on the recently about the Glamo and OpenGL where Wolfgang called for serious developers to get in touch with him and he would see what could be done about getting access to the NDA'ed Glamo documents [1]. A couple of developers responded saying they were interested. I would like to see how many people are interested and willing to commit to working on and OpenGL driver in this thread. If there is enough interest I will start a project one projects.openmoko.org http://projects.openmoko.org and then we can work with Openmoko on the legal aspects of the NDA. So please, if you are interested and motivated lets discuss it here, then we can work on getting the rest in motion. What about cross-posting this also to mesa-devel and dri-devel? -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ 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: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Sun, Nov 16, 2008 at 8:49 PM, Aliner [EMAIL PROTECTED] wrote: You can count me in. I have experience doing kernel development. Since the documentation is not available, I saw a couple of pointers on how to start on the nouveau project. They have an excellent section on tools and documentation. http://nouveau.freedesktoplorg/wiki. I have some questions, the glamo chip contains 3d support, what version of OpenGL (or OpenGL ES) is implemented? Are we still going to keep Xglamo (kdrive) or are we goint to use X.org server? (this question arised after Rastermans e-mail) Are we going to support full OpenGL or OpenGL ES on the implementation? Or is it going to be a OpenGL driver and a OpenGL ES driver? Thank you Those are some good questions. From what I understand the Glamo is fixed-function and supports OpenGL ES 1.1. As far as changing Xglamo to be based on X over kdrive, I think to start, it would be best to leave Xglamo the way it is and just add-in OpenGL ES support, but if there were people dedicated to getting X support I would vote for it. -Jacob ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
What about using a software opengl es implementation ? I used to play on this on wince targets (using vincent) Anyway that's a job I'd like to be involved in , if I had time to -- Related Obsession : http://rzr.online.fr/q/OpenGlEs ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | I have some questions, the glamo chip contains 3d support, what | version of OpenGL (or OpenGL ES) is implemented? | Are we still going to keep Xglamo (kdrive) or are we goint to use | X.org server? (this question arised after Rastermans e-mail) | Those are some good questions. From what I understand the Glamo is | fixed-function and supports OpenGL ES 1.1. As far as changing Xglamo to | be based on X over kdrive, I think to start, it would be best to leave | Xglamo the way it is and just add-in OpenGL ES support, but if there | were people dedicated to getting X support I would vote for it. FWIW I talked this over with an experienced 3D guy recently about something related and he was all in favour of discarding the kdrive implementation and making a pure xorg one as a way forward: he told that kdrive itself was long dead. I also know that XGlamo is not that great a solution since it is largely the Linux framebuffer driver basically cut and pasted into userspace with the locking not being shared between kernel and userland. Whatever it's replaced with ought to be glued into kernel Glamo framebuffer driver I think at the very least for any critical shared parts like locking and this modal commandqueue stuff. He also said the same that Glamo was ES, I think 1.1. Since Graeme is going ahead with xorg generally it sounds like this is the recommended path to follow if at all possible. Lastly he mentioned 2442 has no float unit so this impacts the implementation, but apparently it's not a killer to used fixed in ES. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkgkdUACgkQOjLpvpq7dMr+kgCfcJFz7F2qCJWXtB+63c0scJ5x Yq0An1dfewn2MdpYXxPwl1T73kgegoTd =0qfk -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Sun, Nov 16, 2008 at 4:34 PM, Andy Green [EMAIL PROTECTED] wrote: FWIW I talked this over with an experienced 3D guy recently about something related and he was all in favour of discarding the kdrive implementation and making a pure xorg one as a way forward: he told that kdrive itself was long dead. I also know that XGlamo is not that great a solution since it is largely the Linux framebuffer driver basically cut and pasted into userspace with the locking not being shared between kernel and userland. Whatever it's replaced with ought to be glued into kernel Glamo framebuffer driver I think at the very least for any critical shared parts like locking and this modal commandqueue stuff. He also said the same that Glamo was ES, I think 1.1. Since Graeme is going ahead with xorg generally it sounds like this is the recommended path to follow if at all possible. Lastly he mentioned 2442 has no float unit so this impacts the implementation, but apparently it's not a killer to used fixed in ES. Just fair warning here. As I don't think OM will use the Glamo in future devices, doing the right thing isn't as critical as normal software projects. Spend the energy making the best performing, most functional implementation possible. If that goal's met, *then* go back and shove it into Xorg. -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Lally Singh wrote: Just fair warning here. As I don't think OM will use the Glamo in future devices, doing the right thing isn't as critical as normal software projects... -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech Doing the right this IS critical to support the freerunner, going forward. I, personally, get rather worried by all this talk of supporting future revisions and not putting in too much freerunner-specific energy because it won't be loing until GTA03 is here If OM drop efforts to make 02 better, then they'll probably have a lot of folks that just won't buy the 03 because they're angry. -- View this message in context: http://n2.nabble.com/Calling-interested-Glamo-OpenGL-developers-%28was%3A-The-forbidden-topic%3A-Glamo-OpenGL%29-tp1505667p1507674.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
On Sun, Nov 16, 2008 at 7:42 PM, Gothnet [EMAIL PROTECTED] wrote: Lally Singh wrote: Just fair warning here. As I don't think OM will use the Glamo in future devices, doing the right thing isn't as critical as normal software projects... Doing the right this IS critical to support the freerunner, going forward. I, personally, get rather worried by all this talk of supporting future revisions and not putting in too much freerunner-specific energy because it won't be loing until GTA03 is here If OM drop efforts to make 02 better, then they'll probably have a lot of folks that just won't buy the 03 because they're angry. I think the FR needs an accelerator going forward, but I doubt it's the Glamo. More importantly, I think there's a lot of potential fun to be had with this: http://www.clutter-project.org/ -ls -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
2008/11/17 Gothnet [EMAIL PROTECTED] If OM drop efforts to make 02 better, then they'll probably have a lot of folks that just won't buy the 03 because they're angry. About freerunner in general if Openmoko will drop effort on it they'll have to ship a gta03 without issues otherwise peoples will not trust them anymore :). About the glamo, did someone evaulate how much it will cost to produce the wanted 3d driver, and how much *customers* will be happy of this? Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Those are some good questions. From what I understand the Glamo is fixed-function and supports OpenGL ES 1.1. As far as changing Xglamo to be based on X over kdrive, I think to start, it would be best to leave Xglamo the way it is and just add-in OpenGL ES support, but if there were people dedicated to getting X support I would vote for it. Glamo3363 support: * OpenGL ES 1.0 * OpenGL ES 1.1 * Mobile D3D 3D pipe line: * transform * cull * lighting * clipping * setup * rasterizer The glamo datasheet is full of register settings, as wolfgang said, we hope could resolve this NDA issue in someway that could help people develop 3D development on FR. - -- Neng-Yu Tu (Tony Tu) Openmoko, Inc. Support. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkg9oEACgkQmV6sZhhBn2+FKQCgq+A2HsKkNTlKHvZgi/zjlale qXsAn2gi5L3cc0/SKjYF54ve6KtzIABW =fJkN -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
