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: 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: 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: 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)
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)
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 I understood it is not official, but I am not against some Mac Guiver playing... ___ 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: 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: 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: 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: 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 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: 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: 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: 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: Buzzing (was :The forbidden topic: Glamo OpenGL)
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). Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
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 am just curious about this. I hope someone can comment on this. My thought is that X is used because most apps that already exist on the desktop can be used here and the applications remain portable. I still would like to know more in terms of performance and memory consumption and scalability. -- 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 Fri, Nov 14, 2008 at 9:58 PM, Angus Ainslie <[EMAIL PROTECTED]>wrote: > On Fri, Nov 14, 2008 at 9:14 AM, Jacob Peterson <[EMAIL PROTECTED]>wrote: > >> I know the buzzing issue had quite a bit of attention from the Openmoko >> team, judging from watching the traffic on the Hardware and Kernel mailing >> lists. So I don't think they have given up on that, but it doesn't seem >> like there is any set solution for current devices, only anecdotal reports >> of alsa volume tweaks. >> >> > Anecdotally I can also report that with a little soldering you can get rid > of the buzz. It is not for the faint of heart and is detailed in this > thread: > > http://lists.openmoko.org/pipermail/hardware/2008-October/000775.html > > I understand from the posts flying around they have found the cause for buzzing, especially when using a headset, and a fix for that. I believe OM should quickly demonstrate their commitment to their committed customers by recalling the handsets and fixing the hardware (including the GPS/SD card fix) immediately under warranty. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
On Fri, Nov 14, 2008 at 9:14 AM, Jacob Peterson <[EMAIL PROTECTED]> wrote: > I know the buzzing issue had quite a bit of attention from the Openmoko > team, judging from watching the traffic on the Hardware and Kernel mailing > lists. So I don't think they have given up on that, but it doesn't seem > like there is any set solution for current devices, only anecdotal reports > of alsa volume tweaks. > > Anecdotally I can also report that with a little soldering you can get rid of the buzz. It is not for the faint of heart and is detailed in this thread: http://lists.openmoko.org/pipermail/hardware/2008-October/000775.html -- Angus Ainslie http://www.handheldshell.com/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
Jacob Peterson wrote: > > I know the buzzing issue had quite a bit of attention from the Openmoko > team, judging from watching the traffic on the Hardware and Kernel mailing > lists. So I don't think they have given up on that, but it doesn't seem > like there is any set solution for current devices, only anecdotal reports > of alsa volume tweaks. > I've not actually suffered the infamous buzzing, my problem was that, mostly on incoming calls, the other party had their words echoed back to them at full volume a second or so after they spoke. One of the 2008 updates fixed it, but then it came back in the next one. I've tried using various folks' gsmhandset.state files to no avail, in fact some of them killed sound altogether. Android doesn't seem to suffer from it, but of course I've only been able to make outgoing calls. -- View this message in context: http://n2.nabble.com/The-forbidden-topic%3A-Glamo-OpenGL-tp1495995p1499227.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: Buzzing (was :The forbidden topic: Glamo OpenGL)
I know the buzzing issue had quite a bit of attention from the Openmoko team, judging from watching the traffic on the Hardware and Kernel mailing lists. So I don't think they have given up on that, but it doesn't seem like there is any set solution for current devices, only anecdotal reports of alsa volume tweaks. On Fri, Nov 14, 2008 at 3:43 PM, Gothnet <[EMAIL PROTECTED]>wrote: > > 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 > ___ 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: 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
