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: The forbidden topic: Glamo OpenGL
hehehe, it's good to see OM people having a sense of humour as well! :) Steve Mosher wrote: they don't already? please issue a ticket. we'll fix the bug. George Brooke wrote: On Wed, 19 Nov 2008 00:01:47 +1100 Dale Maggee [EMAIL PROTECTED] wrote: Tig wrote: Ok I will bite :) Q: Why did OM cross the road? A: To get to another toolkit :) Q: How many OM devs does it take to change a lightbulb? A: Well first we need to abandon the old lightbulb holder because at a later date we may not be able to plug a floodlight in, bring in a new lightbulb holder and adapt it to multiple floodlights, meanwhile the engineering team has realized that this will only run green floodlights and has started rewiring the whole house.. :) The burnt out lightbulb is due to be fixed at a later date :) Please not this is not a cue for a thread on lightbulb analogies :) Q: What is the difference between a professional photographer and OM user? A: The OM user has to flash more often :) Q: Why did the OM newbie log onto #openmoko? A: Because they had not read: a) the wiki and b) the topic As then they would know you slide your finder up on the keyboard to get the numbers to enter your sim pin. I will be here all week, try the salad :) Regards (apologies for posting via gmane moving e-mail around) Hehe, love the lightbulb one! Q: What's the difference between an iphone and a freerunner? A: One works but takes away your freedom, the other is free but needs your work Knock, Knock Who's There? A Neo User A Neo User Q: What did the Neo say to the insomniac? A: At least when you go to sleep you know you'll wake up! Ancient chinese proverb: Neo owner is man carrying wall charger And I've saved my favorite for last: Q: What's the difference between a brick and a freerunner? A: A brick isn't designed to make phone calls. ;) -Dale (All in good fun) Maybe these should appear on the splash screen of the Neos solar.george ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Warren Baird wrote: OM2008.9 and FSO walk into a bar. How are you? How are you? asks FSO. Buzzz says OM2008.9 LOL! (for once, usage of that horrible acronym is actually appropriate - I really did laugh out loud!) this is my new splash screen... :D moko_bar.gz Description: GNU Zip compressed data ___ 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: Buzzing (was :The forbidden topic: Glamo OpenGL)
Timo, You will find echo fixed in Openmoko's 2008.11 release, if you keep using the Openmoko distro, and responsiveness and touch screen usability will also improve with 2008.11 release. End call / accept You are right that people are working on these things and fixes appear. However, please don't expect a real Om 2008.11 'release' before the end of the month. There is simply too much progress in all areas right now, we need a bit more time for everything to settle before calling something another 'release'. Maybe a few months. Maybe we come out with snaphost in between, similar to FSO's milestone builds. If someone proves me wrong then great, I am just telling you please keep your Om 2008.11 release expectations low. Wolfgang On Nov 17, 2008, at 6:35 PM, Timo Jyrinki wrote: 2008/11/14 Gothnet [EMAIL PROTECTED]: It really needs work on the basics. I mean, responsiveness is not there, interface is dodgy (the end call button being in the same spot as the accept call button, and being unresponsive, made me hang up s many calls). Echo on calls, battery life... These are all small issues as such, as they are all on the software side and many have been either fixed or are different on different distributions (you don't need to use Openmoko's distribution - you can use Debian, Qt Extended, SHR, ...). You will find echo fixed in Openmoko's 2008.11 release, if you keep using the Openmoko distro, and responsiveness and touch screen usability will also improve with 2008.11 release. End call / accept call stuff are just UI things, easy to fix, but maybe you should file a bug report about it since otherwise no-one might notice. The buzzing issue is the only real, serious issue. Also, I know everyone loves X, but is it really the best choice for a low powered device that needs a responsive UI? Yes :) Any unresponsiveness in the UI is not because of the X. I think maybe I had the wrong impression about the state of the software when I bought it. Probably. It's not a phone product yet, it's a phone in development. From your point of view I can understand the frustration with the other issues, but for me they are just a few things to work on / test fixes. The buzzing / hw issue is really the only thing I'm worried about, since it needs to be fixed and there is no known software fix for it yet. -Timo ___ 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)
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: The forbidden topic: Glamo OpenGL
Maybe these should appear on the splash screen of the Neos solar.george Brilliant! 1. Save either attachment somewhere 2. Use NeoTool or 'dfu-util -a splash -R -D filename' to flash the new splash to your neo 3. power down then turn on your neo 4. Laugh. :D -Dale moko_brick.gz Description: GNU Zip compressed data knock_knock.gz Description: GNU Zip compressed data ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
On 18 Nov 2008, at 13:22, Nicola Mfb wrote: ... Yes! When someone asks me if it's a good idea to give a try to gentoo (my preferred distro) I point them to: http://uncyclopedia.wikia.com/wiki/Gentoo :) From TFA: Old-school Linux users were desperate to find a new way to feel superior. Some migrated to versions of BSD, ... I recently considered Solaris, but only briefly. Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
On 18 Nov 2008, at 13:01, Dale Maggee wrote: ... Q: What's the difference between an iphone and a freerunner? A: One works but takes away your freedom, the other is free but needs your work 3 3 3 Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
On 19 Nov 2008, at 08:46, Dale Maggee wrote: Q: What's the difference between a brick and a freerunner? A: A brick isn't designed to make phone calls. Maybe these should appear on the splash screen of the Neos Brilliant! 1. Save either attachment somewhere 2. Use NeoTool or 'dfu-util -a splash -R -D filename' to flash the new splash to your neo 3. power down then turn on your neo 4. Laugh. :D -Dale moko_brick.gz I find the idea of flashing an attachment called moko_brick somewhat ominous. Stroller. ___ 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)
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: The forbidden topic: Glamo OpenGL
they don't already? please issue a ticket. we'll fix the bug. George Brooke wrote: On Wed, 19 Nov 2008 00:01:47 +1100 Dale Maggee [EMAIL PROTECTED] wrote: Tig wrote: Ok I will bite :) Q: Why did OM cross the road? A: To get to another toolkit :) Q: How many OM devs does it take to change a lightbulb? A: Well first we need to abandon the old lightbulb holder because at a later date we may not be able to plug a floodlight in, bring in a new lightbulb holder and adapt it to multiple floodlights, meanwhile the engineering team has realized that this will only run green floodlights and has started rewiring the whole house.. :) The burnt out lightbulb is due to be fixed at a later date :) Please not this is not a cue for a thread on lightbulb analogies :) Q: What is the difference between a professional photographer and OM user? A: The OM user has to flash more often :) Q: Why did the OM newbie log onto #openmoko? A: Because they had not read: a) the wiki and b) the topic As then they would know you slide your finder up on the keyboard to get the numbers to enter your sim pin. I will be here all week, try the salad :) Regards (apologies for posting via gmane moving e-mail around) Hehe, love the lightbulb one! Q: What's the difference between an iphone and a freerunner? A: One works but takes away your freedom, the other is free but needs your work Knock, Knock Who's There? A Neo User A Neo User Q: What did the Neo say to the insomniac? A: At least when you go to sleep you know you'll wake up! Ancient chinese proverb: Neo owner is man carrying wall charger And I've saved my favorite for last: Q: What's the difference between a brick and a freerunner? A: A brick isn't designed to make phone calls. ;) -Dale (All in good fun) Maybe these should appear on the splash screen of the Neos solar.george ___ 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: The forbidden topic: Glamo OpenGL
OM2008.9 and FSO walk into a bar. How are you? How are you? asks FSO. Buzzz says OM2008.9 On Tue, Nov 18, 2008 at 8:01 AM, Dale Maggee [EMAIL PROTECTED]wrote: Tig wrote: Ok I will bite :) Q: Why did OM cross the road? A: To get to another toolkit :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Tig wrote: Ok I will bite :) Q: Why did OM cross the road? A: To get to another toolkit :) Q: How many OM devs does it take to change a lightbulb? A: Well first we need to abandon the old lightbulb holder because at a later date we may not be able to plug a floodlight in, bring in a new lightbulb holder and adapt it to multiple floodlights, meanwhile the engineering team has realized that this will only run green floodlights and has started rewiring the whole house.. :) The burnt out lightbulb is due to be fixed at a later date :) Please not this is not a cue for a thread on lightbulb analogies :) Q: What is the difference between a professional photographer and OM user? A: The OM user has to flash more often :) Q: Why did the OM newbie log onto #openmoko? A: Because they had not read: a) the wiki and b) the topic As then they would know you slide your finder up on the keyboard to get the numbers to enter your sim pin. I will be here all week, try the salad :) Regards (apologies for posting via gmane moving e-mail around) Hehe, love the lightbulb one! Q: What's the difference between an iphone and a freerunner? A: One works but takes away your freedom, the other is free but needs your work Knock, Knock Who's There? A Neo User A Neo User Q: What did the Neo say to the insomniac? A: At least when you go to sleep you know you'll wake up! Ancient chinese proverb: Neo owner is man carrying wall charger And I've saved my favorite for last: Q: What's the difference between a brick and a freerunner? A: A brick isn't designed to make phone calls. ;) -Dale (All in good fun) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
2008/11/14 Minh Ha Duong [EMAIL PROTECTED] I hope the software stack becomes less of a joke in time for GTA03 or it'll be hard to get much new customers... Actually I have never read any jokes about the software stack. But it is a sign of good mental health when a community is able to make fun of itself. Besides, where else would one share jokes about Openmoko ? Open fire ! Yes! When someone asks me if it's a good idea to give a try to gentoo (my preferred distro) I point them to: http://uncyclopedia.wikia.com/wiki/Gentoo :) May we start an openmoko page there :) 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 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: The forbidden topic: Glamo OpenGL
On Wed, 19 Nov 2008 00:01:47 +1100 Dale Maggee [EMAIL PROTECTED] wrote: Tig wrote: Ok I will bite :) Q: Why did OM cross the road? A: To get to another toolkit :) Q: How many OM devs does it take to change a lightbulb? A: Well first we need to abandon the old lightbulb holder because at a later date we may not be able to plug a floodlight in, bring in a new lightbulb holder and adapt it to multiple floodlights, meanwhile the engineering team has realized that this will only run green floodlights and has started rewiring the whole house.. :) The burnt out lightbulb is due to be fixed at a later date :) Please not this is not a cue for a thread on lightbulb analogies :) Q: What is the difference between a professional photographer and OM user? A: The OM user has to flash more often :) Q: Why did the OM newbie log onto #openmoko? A: Because they had not read: a) the wiki and b) the topic As then they would know you slide your finder up on the keyboard to get the numbers to enter your sim pin. I will be here all week, try the salad :) Regards (apologies for posting via gmane moving e-mail around) Hehe, love the lightbulb one! Q: What's the difference between an iphone and a freerunner? A: One works but takes away your freedom, the other is free but needs your work Knock, Knock Who's There? A Neo User A Neo User Q: What did the Neo say to the insomniac? A: At least when you go to sleep you know you'll wake up! Ancient chinese proverb: Neo owner is man carrying wall charger And I've saved my favorite for last: Q: What's the difference between a brick and a freerunner? A: A brick isn't designed to make phone calls. ;) -Dale (All in good fun) Maybe these should appear on the splash screen of the Neos solar.george signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
On Mon, 17 Nov 2008 13:54:55 +0800 John Lee [EMAIL PROTECTED] babbled: On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote: x's internals are definitely up for improvement - callium3d is there to try and fix this by providing a better more organised and better accelerated driver layer - but again - they aren't going to replace x... just clean up internals. what it means is - the rest of us can continue happily writing x apps and just wait for an improvement to pop out the pipeline. indeed x's internal acceleration layer could be improved. it has in the past (especially with xaa) proved an impediment if you have to code AT the driver layer. as such - x was originally designs (as a system - not specifically the xorg tree etc.) to allow full freedom to implement the internals of x any way you like - so as such if you wanted to spend the effort x could accelerate just about everything as long as hardware can do it, somehow - but the points at which that acceleration knowledge need to go into might be much higher up than xaa/exa. you'd have to write a forked x with all sorts of hooks higher up. - but it's possible... and then x client work as they always did - and get more use of the hardware :) MicroXwin ? http://www.microxwin.com/ MicroXwin is binary compatible to the Xlib API. However it is niether client server nor network oriented. Graphics operations are implemented in the linux kernel via a kernel module. An open source Xlib library sends graphics commands to the kernel. There is no network overhead and no context switch from X client to X server. This makes our solution smaller and faster than traditional X Windows. as such - context switching doesn't happen as often as people think.. if you write good x code - its' buffered. but as such this is an interesting solution - that is linux specific. not sure if it handles everything (window management, and not to mention enough of the modern extensions), but for gta03 (as this is framebuffer based) this could be a definite option. i'd say it'd be worth exploring. keeps compatibility AND should give you some speedup. not sure just how much day to day though. but the license seems... opaque - no idea what it is but it looks closed. but as such this would be another valid way of doing things with x. as such x apps just should avoid round-trip calls to x, so while they run they can do all their gfx ops WITHOUT a single round trip (thus no cache flush) and they only flush on final draw of everything - so just once per frame really (for the app). -- - 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: Buzzing (was :The forbidden topic: Glamo OpenGL)
2008/11/14 Gothnet [EMAIL PROTECTED]: It really needs work on the basics. I mean, responsiveness is not there, interface is dodgy (the end call button being in the same spot as the accept call button, and being unresponsive, made me hang up s many calls). Echo on calls, battery life... These are all small issues as such, as they are all on the software side and many have been either fixed or are different on different distributions (you don't need to use Openmoko's distribution - you can use Debian, Qt Extended, SHR, ...). You will find echo fixed in Openmoko's 2008.11 release, if you keep using the Openmoko distro, and responsiveness and touch screen usability will also improve with 2008.11 release. End call / accept call stuff are just UI things, easy to fix, but maybe you should file a bug report about it since otherwise no-one might notice. The buzzing issue is the only real, serious issue. Also, I know everyone loves X, but is it really the best choice for a low powered device that needs a responsive UI? Yes :) Any unresponsiveness in the UI is not because of the X. I think maybe I had the wrong impression about the state of the software when I bought it. Probably. It's not a phone product yet, it's a phone in development. From your point of view I can understand the frustration with the other issues, but for me they are just a few things to work on / test fixes. The buzzing / hw issue is really the only thing I'm worried about, since it needs to be fixed and there is no known software fix for it yet. -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)
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: Buzzing (was :The forbidden topic: Glamo OpenGL)
About the buzzin issue, I would like to be sure : is it or is it not hardware related ? I heard about a soldering fix of one electronic component which could get rid of the interferences... Has anyone more information ? Kimaidou 2008/11/17 Timo Jyrinki [EMAIL PROTECTED] 2008/11/14 Gothnet [EMAIL PROTECTED]: It really needs work on the basics. I mean, responsiveness is not there, interface is dodgy (the end call button being in the same spot as the accept call button, and being unresponsive, made me hang up s many calls). Echo on calls, battery life... These are all small issues as such, as they are all on the software side and many have been either fixed or are different on different distributions (you don't need to use Openmoko's distribution - you can use Debian, Qt Extended, SHR, ...). You will find echo fixed in Openmoko's 2008.11 release, if you keep using the Openmoko distro, and responsiveness and touch screen usability will also improve with 2008.11 release. End call / accept call stuff are just UI things, easy to fix, but maybe you should file a bug report about it since otherwise no-one might notice. The buzzing issue is the only real, serious issue. Also, I know everyone loves X, but is it really the best choice for a low powered device that needs a responsive UI? Yes :) Any unresponsiveness in the UI is not because of the X. I think maybe I had the wrong impression about the state of the software when I bought it. Probably. It's not a phone product yet, it's a phone in development. From your point of view I can understand the frustration with the other issues, but for me they are just a few things to work on / test fixes. The buzzing / hw issue is really the only thing I'm worried about, since it needs to be fixed and there is no known software fix for it yet. -Timo ___ 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, 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: Buzzing (was :The forbidden topic: Glamo OpenGL)
Le lundi 17 novembre 2008, kimaidou a écrit : About the buzzin issue, I would like to be sure : is it or is it not hardware related ? I heard about a soldering fix of one electronic component which could get rid of the interferences... Has anyone more information ? It is hardware related and discussed on the Hardware mailing list: http://lists.openmoko.org/pipermail/hardware/ Check September, October... it is about half of the traffic there. Minh -- Minh HA DUONG, Chargé de Recherche, CNRS CIRED, Centre International de Recherches sur l'Environnement et le Développement http://minh.haduong.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)
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: Buzzing (was :The forbidden topic: Glamo OpenGL)
So far, on the FR, I remain to be convinced that the use of X is the critical performance issue. In any event, the main issue with optimization efforts is whether they can proceed faster than the introduction of better hardware. If a 400 Mhz machine is too slow, will a 1 Ghz machine be fast enough? Will anything be fast enough? Apparently, from the history of desktops, the answer is no! My own experiments with the FR lead me to believe that memory access and peripheral access are more significant than X performance, but I have yet to do the tests and the math. Carsten Haitzler (The Rasterman) wrote: On Mon, 17 Nov 2008 13:54:55 +0800 John Lee [EMAIL PROTECTED] babbled: On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote: x's internals are definitely up for improvement - callium3d is there to try and fix this by providing a better more organised and better accelerated driver layer - but again - they aren't going to replace x... just clean up internals. what it means is - the rest of us can continue happily writing x apps and just wait for an improvement to pop out the pipeline. indeed x's internal acceleration layer could be improved. it has in the past (especially with xaa) proved an impediment if you have to code AT the driver layer. as such - x was originally designs (as a system - not specifically the xorg tree etc.) to allow full freedom to implement the internals of x any way you like - so as such if you wanted to spend the effort x could accelerate just about everything as long as hardware can do it, somehow - but the points at which that acceleration knowledge need to go into might be much higher up than xaa/exa. you'd have to write a forked x with all sorts of hooks higher up. - but it's possible... and then x client work as they always did - and get more use of the hardware :) MicroXwin ? http://www.microxwin.com/ MicroXwin is binary compatible to the Xlib API. However it is niether client server nor network oriented. Graphics operations are implemented in the linux kernel via a kernel module. An open source Xlib library sends graphics commands to the kernel. There is no network overhead and no context switch from X client to X server. This makes our solution smaller and faster than traditional X Windows. as such - context switching doesn't happen as often as people think.. if you write good x code - its' buffered. but as such this is an interesting solution - that is linux specific. not sure if it handles everything (window management, and not to mention enough of the modern extensions), but for gta03 (as this is framebuffer based) this could be a definite option. i'd say it'd be worth exploring. keeps compatibility AND should give you some speedup. not sure just how much day to day though. but the license seems... opaque - no idea what it is but it looks closed. but as such this would be another valid way of doing things with x. as such x apps just should avoid round-trip calls to x, so while they run they can do all their gfx ops WITHOUT a single round trip (thus no cache flush) and they only flush on final draw of everything - so just once per frame really (for the app). -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
On Mon, Nov 17, 2008 at 7:46 AM, kimaidou [EMAIL PROTECTED] wrote: Ok thanks, I have just read the hundreds if topics on it... the problem is I am no electronicien so I did not understand if a workaround has been found : I read about soldering, sticky tape. If there is a workaround, is there a webpage with clear instructions ? (by clear I mean for non-elecronician guy). Is it doable by a anybody or do we need special devices/skills It does require special skills and tools. If the posts in the hardware list were not enough for you to see the fix then you shouldn't attempt it. Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
It does require special skills and tools. If the posts in the hardware list were not enough for you to see the fix then you shouldn't attempt it. Angus Hum Sorry to ask again, but.. A solution has been found ? Or this solderings and pin things are for tests purposes only ? If the solution is ok, * I know some electronician guys, but they would need proper schemes (not pictures). * or I can send back my FR and try to ask my provider to repair it ? ___ 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: Buzzing (was :The forbidden topic: Glamo OpenGL)
Iain B. Findleton wrote: the main issue with optimization efforts is whether they can proceed faster than the introduction of better hardware. If a 400 Mhz machine is too slow, will a 1 Ghz machine be fast enough? Will anything be fast enough? Apparently, from the history of desktops, the answer is no! Having seen the way the device responds under android compared to the way it responds under OM2008, I'd say they have a way to go on current hardware. I guess I'll try OM2008.11 at some point and see if that's caught up. -- View this message in context: http://n2.nabble.com/The-forbidden-topic%3A-Glamo-OpenGL-tp1495995p1510628.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: The forbidden topic: Glamo OpenGL
Minh Ha Duong [EMAIL PROTECTED] writes: I hope the software stack becomes less of a joke in time for GTA03 or it'll be hard to get much new customers... Actually I have never read any jokes about the software stack. But it is a sign of good mental health when a community is able to make fun of itself. Besides, where else would one share jokes about Openmoko ? Open fire ! Ok I will bite :) Q: Why did OM cross the road? A: To get to another toolkit :) Q: How many OM devs does it take to change a lightbulb? A: Well first we need to abandon the old lightbulb holder because at a later date we may not be able to plug a floodlight in, bring in a new lightbulb holder and adapt it to multiple floodlights, meanwhile the engineering team has realized that this will only run green floodlights and has started rewiring the whole house.. :) The burnt out lightbulb is due to be fixed at a later date :) Please not this is not a cue for a thread on lightbulb analogies :) Q: What is the difference between a professional photographer and OM user? A: The OM user has to flash more often :) Q: Why did the OM newbie log onto #openmoko? A: Because they had not read: a) the wiki and b) the topic As then they would know you slide your finder up on the keyboard to get the numbers to enter your sim pin. I will be here all week, try the salad :) Regards (apologies for posting via gmane moving e-mail around) Tig ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Tim Schmidt wrote: On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul [EMAIL PROTECTED] wrote: Having said that, if someone wants to seriously develop for the glamo, please get in touch with me and we will find a legally correct way to extend the smedia documentation to you. In fact we have done that in a few cases before already, but I'm not sure how much actual codes have come out of that. I think very little ;-) So we need some really serious coders that don't mind a tough challenge. I am not a skilled developer, but I would be more than happy to organize, and participate in a traditional clean room re-implementation of the documentation. As a GTA02 owner, as a founding member of the Open Graphics Project, as a Director of the Open Hardware Foundation, I believe I have the resources to accomplish such a task. I'd love to try. Can we make it happen? --tim I'd certainly be interested in attempting to add OpenGL support to the glamo driver if documentation were to become available, but I'm hesitant to put myself forward for anything that would require Openmoko Inc. to go out of their way by jumping through administrative loop holes to give access to the NDA'd documentation, as I'm unlikely to actually succeed (I have some experience of driver development, and experience of OpenGL from a high level point of view, but no actual experience of graphics driver development). So I think a freely available clean room rewrite of the documentation would be very helpful, as there may well be others in a similar position, people willing to take a look at the problem, but not confident enough to cause OpenMoko Inc. extra hassle/work for what may result in nothing. Cheers, Mike. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
I just wanted to update. I am trying to locate all the information I can relating to the Glamo, including projects using the hardware acceleration features of it on this wiki page [1]. I would like to use that page as a starting point to help organize an effort to get something underway with regard to the Glamo chip. There is not much there at the moment since information is quite hard to come by, but if anyone has further details or updates please put them on the wiki page. Thanks, Jacob [1] http://wiki.openmoko.org/wiki/Smedia_Glamo_3362 On Sat, Nov 15, 2008 at 1:13 AM, Michael Sheldon [EMAIL PROTECTED] wrote: Tim Schmidt wrote: On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul [EMAIL PROTECTED] wrote: Having said that, if someone wants to seriously develop for the glamo, please get in touch with me and we will find a legally correct way to extend the smedia documentation to you. In fact we have done that in a few cases before already, but I'm not sure how much actual codes have come out of that. I think very little ;-) So we need some really serious coders that don't mind a tough challenge. I am not a skilled developer, but I would be more than happy to organize, and participate in a traditional clean room re-implementation of the documentation. As a GTA02 owner, as a founding member of the Open Graphics Project, as a Director of the Open Hardware Foundation, I believe I have the resources to accomplish such a task. I'd love to try. Can we make it happen? --tim I'd certainly be interested in attempting to add OpenGL support to the glamo driver if documentation were to become available, but I'm hesitant to put myself forward for anything that would require Openmoko Inc. to go out of their way by jumping through administrative loop holes to give access to the NDA'd documentation, as I'm unlikely to actually succeed (I have some experience of driver development, and experience of OpenGL from a high level point of view, but no actual experience of graphics driver development). So I think a freely available clean room rewrite of the documentation would be very helpful, as there may well be others in a similar position, people willing to take a look at the problem, but not confident enough to cause OpenMoko Inc. extra hassle/work for what may result in nothing. Cheers, Mike. ___ 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: The forbidden topic: Glamo OpenGL
Tim Schmidt wrote: On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul [EMAIL PROTECTED] wrote: Having said that, if someone wants to seriously develop for the glamo, please get in touch with me and we will find a legally correct way to extend the smedia documentation to you. In fact we have done that in a few cases before already, but I'm not sure how much actual codes have come out of that. I think very little ;-) So we need some really serious coders that don't mind a tough challenge. I am not a skilled developer, but I would be more than happy to organize, and participate in a traditional clean room re-implementation of the documentation. As a GTA02 owner, as a founding member of the Open Graphics Project, as a Director of the Open Hardware Foundation, I believe I have the resources to accomplish such a task. I'd love to try. Can we make it happen? --tim I'd certainly be interested in attempting to add OpenGL support to the glamo driver if documentation were to become available, but I'm hesitant to put myself forward for anything that would require Openmoko Inc. to go out of their way by jumping through administrative loop holes to give access to the NDA'd documentation, as I'm unlikely to actually succeed (I have some experience of driver development, and experience of OpenGL from a high level point of view, but no actual experience of graphics driver development). So I think a freely available clean room rewrite of the documentation would be very helpful, as there may well be others in a similar position, people willing to take a look at the problem, but not confident enough to cause OpenMoko Inc. extra hassle/work for what may result in nothing. Cheers, Mike. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Tim Schmidt wrote: On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul [EMAIL PROTECTED] wrote: I am not a skilled developer, but I would be more than happy to organize, and participate in a traditional clean room re-implementation of the documentation. As a GTA02 owner, as a founding member of the Open Graphics Project, as a Director of the Open Hardware Foundation, I believe I have the resources to accomplish such a task. I'd love to try. Can we make it happen? --tim I'd certainly be interested in attempting to add OpenGL support to the glamo driver if documentation were to become available, but I'm hesitant to put myself forward for anything that would require Openmoko Inc. to go out of their way by jumping through administrative loop holes to give access to the NDA'd documentation, as I'm unlikely to actually succeed (I have some experience of driver development, and experience of OpenGL from a high level point of view, but no actual experience of graphics driver development). So I think a freely available clean room rewrite of the documentation would be very helpful, as there may well be others in a similar position, people willing to take a look at the problem, but not confident enough to cause OpenMoko Inc. extra hassle/work for what may result in nothing. Cheers, Mike. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Tim Schmidt wrote: On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul [EMAIL PROTECTED] wrote: Having said that, if someone wants to seriously develop for the glamo, please get in touch with me and we will find a legally correct way to extend the smedia documentation to you. In fact we have done that in a few cases before already, but I'm not sure how much actual codes have come out of that. I think very little ;-) So we need some really serious coders that don't mind a tough challenge. I am not a skilled developer, but I would be more than happy to organize, and participate in a traditional clean room re-implementation of the documentation. As a GTA02 owner, as a founding member of the Open Graphics Project, as a Director of the Open Hardware Foundation, I believe I have the resources to accomplish such a task. I'd love to try. Can we make it happen? --tim I'd certainly be interested in attempting to add OpenGL support to the glamo driver if documentation were to become available, but I'm hesitant to put myself forward for anything that would require Openmoko Inc. to go out of their way by jumping through administrative loop holes to give access to the NDA'd documentation, as I'm unlikely to actually succeed (I have some experience of driver development, and experience of OpenGL from a high level point of view, but no actual experience of graphics driver development). So I think a freely available clean room rewrite of the documentation would be very helpful, as there may well be others in a similar position, people willing to take a look at the problem, but not confident enough to cause OpenMoko Inc. extra hassle/work for what may result in nothing. Cheers, Mike. ___ 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
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote: x's internals are definitely up for improvement - callium3d is there to try and fix this by providing a better more organised and better accelerated driver layer - but again - they aren't going to replace x... just clean up internals. what it means is - the rest of us can continue happily writing x apps and just wait for an improvement to pop out the pipeline. indeed x's internal acceleration layer could be improved. it has in the past (especially with xaa) proved an impediment if you have to code AT the driver layer. as such - x was originally designs (as a system - not specifically the xorg tree etc.) to allow full freedom to implement the internals of x any way you like - so as such if you wanted to spend the effort x could accelerate just about everything as long as hardware can do it, somehow - but the points at which that acceleration knowledge need to go into might be much higher up than xaa/exa. you'd have to write a forked x with all sorts of hooks higher up. - but it's possible... and then x client work as they always did - and get more use of the hardware :) MicroXwin ? http://www.microxwin.com/ MicroXwin is binary compatible to the Xlib API. However it is niether client server nor network oriented. Graphics operations are implemented in the linux kernel via a kernel module. An open source Xlib library sends graphics commands to the kernel. There is no network overhead and no context switch from X client to X server. This makes our solution smaller and faster than traditional X Windows. - John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Xlib (was :The forbidden topic: Glamo OpenGL)
On Monday 17 Nov 2008 11:24:55 am John Lee wrote: On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote: x's internals are definitely up for improvement - callium3d is there to try and fix this by providing a better more organised and better accelerated driver layer - but again - they aren't going to replace x... just clean up internals. what it means is - the rest of us can continue happily writing x apps and just wait for an improvement to pop out the pipeline. indeed x's internal acceleration layer could be improved. it has in the past (especially with xaa) proved an impediment if you have to code AT the driver layer. as such - x was originally designs (as a system - not specifically the xorg tree etc.) to allow full freedom to implement the internals of x any way you like - so as such if you wanted to spend the effort x could accelerate just about everything as long as hardware can do it, somehow - but the points at which that acceleration knowledge need to go into might be much higher up than xaa/exa. you'd have to write a forked x with all sorts of hooks higher up. - but it's possible... and then x client work as they always did - and get more use of the hardware :) MicroXwin ? http://www.microxwin.com/ MicroXwin is binary compatible to the Xlib API. However it is niether client server nor network oriented. Graphics operations are implemented in the linux kernel via a kernel module. An open source Xlib library sends graphics commands to the kernel. There is no network overhead and no context switch from X client to X server. This makes our solution smaller and faster than traditional X Windows. Looks good and is a direct binary compatible replacement. Perhaps the proprietary licence for the kernel module is what is keeping it from being used? -- Cheers! Kishore ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
On Sat, Nov 15, 2008 at 4:49 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sat, 15 Nov 2008 07:22:29 + Stroller [EMAIL PROTECTED] babbled: On 15 Nov 2008, at 07:08, Kishore wrote: On Friday 14 Nov 2008 8:13:20 pm Gothnet wrote: Also, I know everyone loves X, but is it really the best choice for a low powered device that needs a responsive UI? ... I still would like to know more in terms of performance and memory consumption and scalability. You guys should search some of Raster's previous posts on this subject. Although you may have to go through quite a lot of posts to find his comments (!), I think you will find he has stated more than once that the performance of X is much maligned (as long as programmers are sensible and use appropriate practices). indeed it is. i have seen x (+efl) drastically (by many times) outperform directfb - on the same device. every time someone thinks that the ui sucks and the solution is dump x it is almost always from a position of lack of knowledge just what is the cause of the problem. a bit of analysis and you'll find the problem is almost always one (or more) of 1. just bad hardware (affects everyone x and others) 2. incomplete or just bad drivers (not x itself and the same problem will happen anywhere you try and accelerate so if its within x or somewhere else - same problem). 3. simple bad x apps or toolkits doing things badly, inefficiently or just trying to do things in a way that just reacts badly with the target hardware. whatever you do in replacing x - you will just replace it with the same thing under a different name. you won't improve or solve anything, as long as you want to have more than 1 process be able to display. if it's only one, dumb-fb is an option but you still need to then do the whole toolkit so see the above problem list. and you just lost multi-process access, lost a lot of support for a lot of toolkits, apps etc. if you want to x CAN be used as a dumb-fb with little extra overhead. if you really want to sink a lot of time i can go into gory detail one thing at a time... but you can also just search these lists and save me the effort :) x gives you the ability to share input devices (kbd, ts, etc.) and share the screen. you want that. it is not big and fat. it is rather small and lean. extensions exist to do just about everything. very little does not exist in some x extension these days. I just wanted to second Raster's point with a small bit of data: X was designed with much less powerful devices than the moko in mind. If you're worried about X being fat, it's not X. It's stuff built on top of X, which we don't need. X ran fine on my 8mb 486. -- 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: Buzzing (was :The forbidden topic: Glamo OpenGL)
On Sat, 15 Nov 2008 07:22:29 + Stroller [EMAIL PROTECTED] babbled: On 15 Nov 2008, at 07:08, Kishore wrote: On Friday 14 Nov 2008 8:13:20 pm Gothnet wrote: Also, I know everyone loves X, but is it really the best choice for a low powered device that needs a responsive UI? ... I still would like to know more in terms of performance and memory consumption and scalability. You guys should search some of Raster's previous posts on this subject. Although you may have to go through quite a lot of posts to find his comments (!), I think you will find he has stated more than once that the performance of X is much maligned (as long as programmers are sensible and use appropriate practices). indeed it is. i have seen x (+efl) drastically (by many times) outperform directfb - on the same device. every time someone thinks that the ui sucks and the solution is dump x it is almost always from a position of lack of knowledge just what is the cause of the problem. a bit of analysis and you'll find the problem is almost always one (or more) of 1. just bad hardware (affects everyone x and others) 2. incomplete or just bad drivers (not x itself and the same problem will happen anywhere you try and accelerate so if its within x or somewhere else - same problem). 3. simple bad x apps or toolkits doing things badly, inefficiently or just trying to do things in a way that just reacts badly with the target hardware. whatever you do in replacing x - you will just replace it with the same thing under a different name. you won't improve or solve anything, as long as you want to have more than 1 process be able to display. if it's only one, dumb-fb is an option but you still need to then do the whole toolkit so see the above problem list. and you just lost multi-process access, lost a lot of support for a lot of toolkits, apps etc. if you want to x CAN be used as a dumb-fb with little extra overhead. if you really want to sink a lot of time i can go into gory detail one thing at a time... but you can also just search these lists and save me the effort :) x gives you the ability to share input devices (kbd, ts, etc.) and share the screen. you want that. it is not big and fat. it is rather small and lean. extensions exist to do just about everything. very little does not exist in some x extension these days. -- - 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: The forbidden topic: Glamo OpenGL
On Sat, 2008-11-15 at 07:20 +, Stroller wrote: Having said that, I thought one of your engineers was already working on Glamo or XGlamo or whatever is required to use the chip's hardware acceleration. It would be good for Openmoko to reaffirm its commitment to that, to offer goals for getting it working timeframes in which these will be achieved. Over the next few weeks I shall be working on Xglamo to bring it into the Xorg family of drivers. If people come up with interesting patches while I am working on this I can certainly give them a tryout. Graeme (XorA) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
2008/11/14 Tim Schmidt [EMAIL PROTECTED] I am not a skilled developer, but I would be more than happy to organize, and participate in a traditional clean room re-implementation of the documentation. As a GTA02 owner, as a founding member of the Open Graphics Project, as a Director of the Open Hardware Foundation, I believe I have the resources to accomplish such a task. Up for this request Wolfgang :) Yeah, Wolfgang, hopefully you didn't miss Tim's post, sounds promising :) As do the other offers of help. Minh wrote: To say what ? Skilled OpenGL hw driver developers welcome to join Glamo 3D development efforts, with a link from the to join Glamo 3D development efforts part to http://lists.openmoko.org/pipermail/community/2008-November/035768.html ? (Also, to others, please do not make this topic into another what are the remaining problems with GTA02, but keep with the topic title about OpenGL/Glamo... that said, to have again a bit more of positive feedback, I'm happy (enough) daily user of FreeRunner with the recent echo fix, re-register fix and suspend mostly working, in addition to the joys of completely free phone... waiting for more fixes, of course). -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Great to hear that! Over the next few weeks I shall be working on Xglamo to bring it into the Xorg family of drivers. If people come up with interesting patches while I am working on this I can certainly give them a tryout. Graeme (XorA) ___ 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: Buzzing (was :The forbidden topic: Glamo OpenGL)
On Saturday 15 Nov 2008 3:19:10 pm Carsten Haitzler wrote: On Sat, 15 Nov 2008 07:22:29 + Stroller [EMAIL PROTECTED] babbled: On 15 Nov 2008, at 07:08, Kishore wrote: On Friday 14 Nov 2008 8:13:20 pm Gothnet wrote: Also, I know everyone loves X, but is it really the best choice for a low powered device that needs a responsive UI? ... I still would like to know more in terms of performance and memory consumption and scalability. You guys should search some of Raster's previous posts on this subject. Although you may have to go through quite a lot of posts to find his comments (!), I think you will find he has stated more than once that the performance of X is much maligned (as long as programmers are sensible and use appropriate practices). indeed it is. i have seen x (+efl) drastically (by many times) outperform directfb - on the same device. every time someone thinks that the ui sucks and the solution is dump x it is almost always from a position of lack of knowledge just what is the cause of the problem. a bit of analysis and you'll find the problem is almost always one (or more) of 1. just bad hardware (affects everyone x and others) 2. incomplete or just bad drivers (not x itself and the same problem will happen anywhere you try and accelerate so if its within x or somewhere else - same problem). 3. simple bad x apps or toolkits doing things badly, inefficiently or just trying to do things in a way that just reacts badly with the target hardware. whatever you do in replacing x - you will just replace it with the same thing under a different name. you won't improve or solve anything, as long as you want to have more than 1 process be able to display. if it's only one, dumb-fb is an option but you still need to then do the whole toolkit so see the above problem list. and you just lost multi-process access, lost a lot of support for a lot of toolkits, apps etc. if you want to x CAN be used as a dumb-fb with little extra overhead. if you really want to sink a lot of time i can go into gory detail one thing at a time... but you can also just search these lists and save me the effort :) x gives you the ability to share input devices (kbd, ts, etc.) and share the screen. you want that. it is not big and fat. it is rather small and lean. extensions exist to do just about everything. very little does not exist in some x extension these days. Raster! Wow! Thanks for the detailed response. Really good to know :) Well, I certainly do not think that direct fb is a better option over X. It sure is crippling to not have multiple apps have access to the screen while not having to know about the others existence. What i was considering was X itself and its overhead. Its good to know that X does not add much overhead. I first got thinking about this when reading about gallium3d. I do recollect reading that the developers were developing it with hope to replace *most* of X and use X only as an interface/API. The reason for this they said was that X was bad. Now, I do not personally know much about this. But it is of academic interest to me. -- Cheers! Kishore ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
On Sat, Nov 15, 2008 at 5:36 AM, Timo Jyrinki [EMAIL PROTECTED] wrote: Yeah, Wolfgang, hopefully you didn't miss Tim's post, sounds promising :) As do the other offers of help. I'd just really like to get documentation out into the wild. I understand that performance is unlikely to ever be better than what we have currently. However, if the Haiku or ReactOS folks ever want to port to the GTA02, I'm sure they'd appreciate documentation so they don't have to burrow through our code (as much). If at some time in the future, a rare bug is encountered and OpenMoko is focused on GTA07, documentation might provide a crucial hint to interested developers tracking down the bug. You get the idea... It's just nice to have. --tim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
On Friday 14 November 2008 15:46:34 Yorick Moko wrote: somebody (leinir) on irc suggested you could maybe hire http://www.tungstengraphics.com (leinir Tungsten Graphics being the people behind gallium3d of course) although I don't know how much openmoko is willing to spend on it Unless we want a closed source driver, I don't think that would work. Reading between the lines on the Tungsten Graphics website. it looks to me that they have one core graphics driver, that they keep porting to whatever chip they are asked to write a driver for, so in each case the core engine stays the same and only the hardware specific stuff gets changed. If this is the case, I doubt they would be willing to produce a GPL driver, as that would require them either to publish the source of their entire engine, or to write a new one. -- David Pottage. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
On Sat, 15 Nov 2008 21:07:25 +0530 Kishore [EMAIL PROTECTED] babbled: Raster! Wow! Thanks for the detailed response. Really good to know :) Well, I certainly do not think that direct fb is a better option over X. It sure is crippling to not have multiple apps have access to the screen while not having to know about the others existence. What i was considering was X itself and its overhead. Its good to know that X does not add much overhead. I first got thinking about this when reading about gallium3d. I do recollect reading that the developers were developing it with hope to replace *most* of X and use X only as an interface/API. The reason for this they said was that X was bad. Now, I do not personally know much about this. But it is of academic interest to me. x's internals are definitely up for improvement - callium3d is there to try and fix this by providing a better more organised and better accelerated driver layer - but again - they aren't going to replace x... just clean up internals. what it means is - the rest of us can continue happily writing x apps and just wait for an improvement to pop out the pipeline. indeed x's internal acceleration layer could be improved. it has in the past (especially with xaa) proved an impediment if you have to code AT the driver layer. as such - x was originally designs (as a system - not specifically the xorg tree etc.) to allow full freedom to implement the internals of x any way you like - so as such if you wanted to spend the effort x could accelerate just about everything as long as hardware can do it, somehow - but the points at which that acceleration knowledge need to go into might be much higher up than xaa/exa. you'd have to write a forked x with all sorts of hooks higher up. - but it's possible... and then x client work as they always did - and get more use of the hardware :) -- - 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: The forbidden topic: Glamo OpenGL
On Sat, Nov 15, 2008 at 2:43 PM, David Pottage [EMAIL PROTECTED] wrote: Unless we want a closed source driver, I don't think that would work. Reading between the lines on the Tungsten Graphics website. it looks to me that they have one core graphics driver, that they keep porting to whatever chip they are asked to write a driver for, so in each case the core engine stays the same and only the hardware specific stuff gets changed. If this is the case, I doubt they would be willing to produce a GPL driver, as that would require them either to publish the source of their entire engine, or to write a new one. They've done much of the open source graphics driver development for Intel. --tim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Michele Renda wrote, on 2008-11-14 23:59: PS. Some hints on future OpenGL chips can arrive inside the next GTAXX versions? :) Try http://www.opengraphics.org/ - once the FGPA version is fully debugged, an ASIC version could be produced. Arthur. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Jacob, Glamo is not a forbidden topic. Openmoko actually has learnt a lot from this. First we have learnt to not trust high-level promises as much as before. In fact I would go as far as saying that going forward, we will not trust any promises about 'we will open this up later' anymore. Either it's open and documented at the time we make the decision to use those chips, or we look elsewhere. I believe that's what our customers want. We have a long way to go to come out with kick-ass open phone hardware, but if our community doesn't loose faith and continues to do development together with us, we'll get there. The momentum we have built with the Freerunner is awesome. Please continue to buy Freerunners and to develop for it, same is happening internally. The next phones will build on top of the free platform we have built together, the technology investment will carry over. Having said that, if someone wants to seriously develop for the glamo, please get in touch with me and we will find a legally correct way to extend the smedia documentation to you. In fact we have done that in a few cases before already, but I'm not sure how much actual codes have come out of that. I think very little ;-) So we need some really serious coders that don't mind a tough challenge. Best Regards, Wolfgang On Nov 14, 2008, at 6:48 AM, Jacob Peterson wrote: Sorry to drag this old, over discussed topic up again. However, I am concerned that if action is not taken soon then all GTA02 owners will be left without any real chance to ever get anything in the way of OpenGL support. So I ask the question, what is Openmoko's position on writing an OpenGL driver for the Glamo chip or at least aiding developers with some form of documentation? I have read speculation that it may be possible to do something such as rewrite the documents to get around the NDA. Since it seems rather clear that SMedia has no intention to release the documents to anyone else under NDA, it is solely up to Openmoko to write the driver or at least aid any community members with the ability to write such a driver. Hopefully there is something that can be done, or better yet, something is currently being done on this. Regards, Jacob ___ 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: The forbidden topic: Glamo OpenGL
On Fri, Nov 14, 2008 at 06:11:30PM +0800, Wolfgang Spraul wrote: built with the Freerunner is awesome. Please continue to buy Freerunners and to develop for it, same is happening internally. The next phones will build on top of the free platform we have built together, the technology investment will carry over. I might have to skip GTA03 since I have just spent a huge 300 Euros for a GTA02 :) I hope the software stack becomes less of a joke in time for GTA03 or it'll be hard to get much new customers... Rui -- Fnord. Today is Pungenday, the 26th day of The Aftermath in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
I might have to skip GTA03 since I have just spent a huge 300 Euros for a GTA02 :) I hope the software stack becomes less of a joke in time for GTA03 or it'll be hard to get much new customers... Well said. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul [EMAIL PROTECTED] wrote: Openmoko actually has learnt a lot from this. First we have learnt to not trust high-level promises as much as before. In fact I would go as far as saying that going forward, we will not trust any promises about 'we will open this up later' anymore. Either it's open and documented at the time we make the decision to use those chips, or we look elsewhere. I believe that's what our customers want. Agreed, and awesome. We have a long way to go to come out with kick-ass open phone hardware, but if our community doesn't loose faith and continues to do development together with us, we'll get there. The momentum we have built with the Freerunner is awesome. Please continue to buy Freerunners and to develop for it, same is happening internally. The next phones will build on top of the free platform we have built together, the technology investment will carry over. *crosses fingers and hopes* Having said that, if someone wants to seriously develop for the glamo, please get in touch with me and we will find a legally correct way to extend the smedia documentation to you. In fact we have done that in a few cases before already, but I'm not sure how much actual codes have come out of that. I think very little ;-) So we need some really serious coders that don't mind a tough challenge. I am not a skilled developer, but I would be more than happy to organize, and participate in a traditional clean room re-implementation of the documentation. As a GTA02 owner, as a founding member of the Open Graphics Project, as a Director of the Open Hardware Foundation, I believe I have the resources to accomplish such a task. I'd love to try. Can we make it happen? --tim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Rui Nishit, I might have to skip GTA03 since I have just spent a huge 300 Euros for a GTA02 :) I hope the software stack becomes less of a joke in time for GTA03 or it'll be hard to get much new customers... Wow, this is actually really complicated, let me tell you a bit how I see things. First of all thank you very much for buying a Freerunner! And posting so much good stuff to our mailing lists. The Freerunner is our breadwinner right now, Freerunner sales sustain Openmoko, and more importantly they grow the community around a 100% open mobile platform. You contribute in many ways. If you buy the Freerunner as a normal user for daily use (quite a few people use it as a daily phone), then your main contribution is that you buy the phone, give Openmoko some of your hard earned money to support further development. If you want to use it as a daily phone, but run into too many bugs or don't find a distribution that fits your needs, you contribute by writing up bug reports. Sending critical emails to our mailing lists or blogging about the shortcomings of the phone. Both our community and our internal people work tirelessly to address these bugs. Finally if you buy it as a mobile development platform right away, you won't mind the current bugs and shortcomings, but see them as an opportunity to grow Free Software into the mobile world. Also don't forget documentation. Documentation is super important to really make Free Software valuable. Every contribution to our wiki (wiki.openmoko.org) is a way to help Openmoko. The home page has been translated to 23 languages! We are really building a free mobile platform together. The source codes are 100% Free Software. The schematics are open under Creative Commons license (CC-BY-SA), so is the complete mechanical design. How does all this relate to GTA03? Well, on one hand internally we work around the clock as if we are trying to start mass production of GTA03 next month. Sean would certainly love to mass produce improved hardware _ANY TIME_ :-) Sean always pushes us to work faster and get things done. On the other hand it's such a huge task. A 100% free and open mobile platform. Thousands of details. And a very small internal engineering force. I have around 30 internal engineers. The typical mobile platform (Nokia/Symbian, WinMobile/HTC, Android/HTC, RIMM, Apple) has over 1000. Is Openmoko planning to hire the missing 970? No. We can only hire very carefully as the current sales of GTA02 allow us to do. Otherwise we would endanger the openness of the platform. The other 970 must come from our community, and increasingly they are. So by buying Freerunners, fixing or writing up bugs, helping to document more aspects of the phone, you help us all get to GTA03 faster. When will GTA03 come out? You tell me. You, and the rest of the community influence it more than you can imagine. We have decided to make changes to the hardware only incrementally, along product lines of our current chip vendors whenever possible, so that as much as possible of the software effort can carry over. We have decided to focus our internal software engineering on the low level, so that we leverage our insider knowledge about the hardware and schematics, while relying on the larger Free Software community to help with higher-level software. You say the current software is a 'joke', which is painful for me but I accept it. From where we all want to be it's a joke, yes. Agreed. So that also answers your question when GTA03 will come out. It's a long way, maybe another year. Let's continue to work, join if you haven't joined yet. Best Regards, Wolfgang On Nov 14, 2008, at 7:06 PM, Rui Miguel Silva Seabra wrote: On Fri, Nov 14, 2008 at 06:11:30PM +0800, Wolfgang Spraul wrote: built with the Freerunner is awesome. Please continue to buy Freerunners and to develop for it, same is happening internally. The next phones will build on top of the free platform we have built together, the technology investment will carry over. I might have to skip GTA03 since I have just spent a huge 300 Euros for a GTA02 :) I hope the software stack becomes less of a joke in time for GTA03 or it'll be hard to get much new customers... Rui -- Fnord. Today is Pungenday, the 26th day of The Aftermath in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ 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: The forbidden topic: Glamo OpenGL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thank you for your answer. I bought GTA02 and I am really happy of this buy. I hope to buy the next major revision! I am not still using it as my daily phone (to say the true I hate phones), but I using my free time to develop it. About the lesson, I think it was very important to learn it. To accept closed HW pays a lot in short term, but the true values is something different! Please keep up this great work! Michele Renda PS. Some hints on future OpenGL chips can arrive inside the next GTAXX versions? :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkdfVUACgkQSIAU/I6SkT1SqgCbBDzzNcUjB86NhyW9tEvC6wEh yz8AnR1JiDaauT1yQ8i8J+GfFk03DXQk =ZDDn -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Thank you for the response Wolfgang. The current FreeRunner is already starting to show its potential as a kick-ass phone and defiantly has me excited to see what future version can offer, but it is sad to see the user interface will never be able to support smooth animations or run any applications that require more that a couple simple moving objects without 3D acceleration support for the Glamo. What started me think of this is running Android on the FreeRunner. I noticed that it ran reasonably well, but if it had just a little extra help from the 3D accelerator it would run really well, the same goes for every other UI and application for the phone. I will continue to support Openmoko and I am eagerly awaiting future hardware that do offer proper 3D support, but until then I will try and get all I can out of what is available. -Jacob On Fri, Nov 14, 2008 at 11:11 AM, Wolfgang Spraul [EMAIL PROTECTED]wrote: Jacob, Glamo is not a forbidden topic. Openmoko actually has learnt a lot from this. First we have learnt to not trust high-level promises as much as before. In fact I would go as far as saying that going forward, we will not trust any promises about 'we will open this up later' anymore. Either it's open and documented at the time we make the decision to use those chips, or we look elsewhere. I believe that's what our customers want. We have a long way to go to come out with kick-ass open phone hardware, but if our community doesn't loose faith and continues to do development together with us, we'll get there. The momentum we have built with the Freerunner is awesome. Please continue to buy Freerunners and to develop for it, same is happening internally. The next phones will build on top of the free platform we have built together, the technology investment will carry over. Having said that, if someone wants to seriously develop for the glamo, please get in touch with me and we will find a legally correct way to extend the smedia documentation to you. In fact we have done that in a few cases before already, but I'm not sure how much actual codes have come out of that. I think very little ;-) So we need some really serious coders that don't mind a tough challenge. Best Regards, Wolfgang On Nov 14, 2008, at 6:48 AM, Jacob Peterson wrote: Sorry to drag this old, over discussed topic up again. However, I am concerned that if action is not taken soon then all GTA02 owners will be left without any real chance to ever get anything in the way of OpenGL support. So I ask the question, what is Openmoko's position on writing an OpenGL driver for the Glamo chip or at least aiding developers with some form of documentation? I have read speculation that it may be possible to do something such as rewrite the documents to get around the NDA. Since it seems rather clear that SMedia has no intention to release the documents to anyone else under NDA, it is solely up to Openmoko to write the driver or at least aid any community members with the ability to write such a driver. Hopefully there is something that can be done, or better yet, something is currently being done on this. Regards, Jacob ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
I hope the software stack becomes less of a joke in time for GTA03 or it'll be hard to get much new customers... Actually I have never read any jokes about the software stack. But it is a sign of good mental health when a community is able to make fun of itself. Besides, where else would one share jokes about Openmoko ? Open fire ! Here is a old one: With milestone IV, openmoko-fso-console-image , FSO is getting really close to a workable GNUPhone as described at: http://notnews.today.com/2008/09/22/free-software-foundation-announces-gnuphone/ Yours, Minh ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
On Fri, Nov 14, 2008 at 7:06 PM, Minh Ha Duong [EMAIL PROTECTED]wrote: I hope the software stack becomes less of a joke in time for GTA03 or it'll be hard to get much new customers... Actually I have never read any jokes about the software stack. But it is a sign of good mental health when a community is able to make fun of itself. Besides, where else would one share jokes about Openmoko ? Open fire ! Here is a old one: With milestone IV, openmoko-fso-console-image , FSO is getting really close to a workable GNUPhone as described at: http://notnews.today.com/2008/09/22/free-software-foundation-announces-gnuphone/ Minh, Wolfgang, Please don't misunderstand those of us who seem to have nothing but negative opinions. We bought the phone because we loved the open source ideal. However, having committed good money and not having the ability to make infinite copies of it, those of us who bought it for pure philosophical and utilitarian purposes, rather than academic or career-oriented ones, have been definitely disappointed at the never-ending list of problems. I'd rather not enumerate them. I believe Rui is very correct in his comment on the commercial aspect of this effort and the results it has yielded so far. Here is a great idea with tremendous potential if you set the right goals and direct your energies to achieve them. The open source philosophy has a distinct disadvantage of people developing just for the joy of it without considering the harsh realities of economics and consumerism. You are competing against real products that, if you disregard the deliberate crippling and proprietary technologies, 'Work'. A commodity device should perform its basic functions faultlessly 'Out Of The Box'. I hate these cliches as much as you do, but they fit their purpose perfectly. I am, as other users must probably be, thankful to your team and the community for the effort you have put in, and the support and spirit you have shown. I am glad that the Freerunner is no vapourware. I am glad the Back To Basics program was conceived and started. However, I believe that the GTA02 is your only chance to make the GTA03 and future versions a resounding success. Please concentrate your efforts in curing its shortcomings. Make it reliable and usable at least for us semi-geeks. The path you have followed allows the boys to use it as their toy, but if that remains its only purpose, there will be definitely lesser repeat customers for the GTA03, whenever it comes out, and whatever it turns out to be. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
Hi Wolfgang, i really appreciate the work you and all the OM-folks and the community does, but: You say the current software is a 'joke', which is painful for me but I accept it. From where we all want to be it's a joke, yes. Agreed. Well, for me, the software is not a joke. It's a little bit special, but i can mostly live with that, somehow and i accept it, knowing it is still not production ready. What really is a joke and absolutly unacceptable for me is the Buzzing and even more of a joke is the fact that the OM-folks doesn't recognize this as an absolute 100% Showstopper for GTA02, 03 and whatever comes next. (by Showstopper i mean the immediate stop of mass production until buzzing is fixed) Please go on and find the source and the solution of this Buzzing ASAP and show us how we can fix it. It's your only chance to avoid theses Issues in GTA03 and its successors. As soon as this happens, much more guys will accept it as a (practially) usable phone, more guys will contribute, more companys might recognize this as a an attractive platform. But as long as the GTA-Hardware doesn't match ANY 5$-Cellphone on ebay on its very built purpose (to make and recieve a phonecall..) OM or Freerunner will have very little chance of surving the Year of 2009. So please fix this buzzing issue.. Greetings Torsten ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
To add my two pence-worth about the joke comment - I have a very high tolerance to stuff not working. or not working smoothly. Most of my computers are broken in some way at any given time. However, when forced to rely on it for a month, even I got annoyed with the freerunner running OM software. It really needs work on the basics. I mean, responsiveness is not there, interface is dodgy (the end call button being in the same spot as the accept call button, and being unresponsive, made me hang up s many calls). Echo on calls, battery life... Also, I know everyone loves X, but is it really the best choice for a low powered device that needs a responsive UI? Anyway, I guess what I'm saying is that whilst I love the ideals, it's basically become a toy rather than a phone, until such time as android is available. And I feel really bad for saying that because I so want a small, community involved, properly open platform to be a reality, and I know you guys are doing a lot of work, it's just not ready for prime-time yet. I think maybe I had the wrong impression about the state of the software when I bought it. -- View this message in context: http://n2.nabble.com/The-forbidden-topic%3A-Glamo-OpenGL-tp1495995p1498709.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: The forbidden topic: Glamo OpenGL
Dear Wolfgang, On Fri, Nov 14, 2008 at 09:11:40PM +0800, Wolfgang Spraul wrote: You say the current software is a 'joke', which is painful for me but I accept it. From where we all want to be it's a joke, yes. Agreed. So that also answers your question when GTA03 will come out. It's a long way, maybe another year. If I wasn't such an adept to Free Software, I wouldn't have patience to tolerate the problems. Some of the reasons the software stack is a joke is not even the fault of OpenMoko. Eg, the qtopia^Wqtextended interface has had a lot more years of life and has so little :) I'm so very glad to hear the news that the sales have been good enough, it's really good to know that because it gives me reasonable expectation that this most respectful company (because it dares to provide the unique Free Software cell phone in suck a proprietary market) will be around long enough for the worst bugs to be solved. It was a terrible mistake to use hardware with NDA-only info, and that is hurting a lot of your users. Please keep your focus there :) Please consider that I'm really using it as a daily phone, and you can't do anything else than grow a strong stomach for these critiques because they are real problems: * White Screen of Death means the battery life is somewhere between 4 and 8 hours (depending on number of calls, in extreme cases maybe even less) * Accelerometers that freeze after a short time of reads mean that accelerometer based applications are not useful on the long run (they need to be frequently restarted) * Slow 2D, no 3D * ... I count myself lucky to not have a dead phone most of the time because I'm almost always plugged to the wall, and as such the laptop powers up the Neo. And I do spend an awful long time in front of the computer, the experience is much worse on weekends (where I have to carry the wall charger around with me). I don't care about a good zhone/tichy/paroli/whatever if I can't use it because the phone is out of juice :) By frustrating that reading critiques may be, consider how frustrating it is for me (and people who have the same problems) :) People with less patience are selling their OpenMokos (I hope people with better patience buy them). I'm even willing to tryout experimental images aimed at trying to solve the WSoD bug, as I've stopped importing my contacts (I grew tired of doing it three to four times a week) and other things that take some time. Best, Rui -- Hail Eris! Today is Pungenday, the 26th day of The Aftermath in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
On Fri, Nov 14, 2008 at 02:36:27PM +0100, Minh Ha Duong wrote: I hope the software stack becomes less of a joke in time for GTA03 or it'll be hard to get much new customers... Actually I have never read any jokes about the software stack. But it is a sign of good mental health when a community is able to make fun of itself. Besides, where else would one share jokes about Openmoko ? Open fire ! Actually, most users of OpenMokos I know get mocked for using a brick that sometimes is a phone or other funny remarks. Here is a old one: With milestone IV, openmoko-fso-console-image , FSO is getting really close to a workable GNUPhone as described at: http://notnews.today.com/2008/09/22/free-software-foundation-announces-gnuphone/ Yes, FSO M4 is probably one of the best images OpenMoko Inc put out so far :) Rui -- Or is it? Today is Pungenday, the 26th day of The Aftermath in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
