Re: iPhone 4G display for Openmoko?
On Tue, 8 Jun 2010 07:17:55 -0700 jeremy jozwik jerjoz.for...@gmail.com said: On Tue, Jun 8, 2010 at 7:11 AM, Martix martix...@gmail.com wrote: I think that AMOLED display is better upgrade for our FRs and small form factors AMOLEDs aren't much expensive. AMOLED displays have similar data interfaces as TFT LCDs, but perhaps we'll need to modify power supply. now this is all interesting to me, as my wife put a nice nick in my freerunners screen. im going to need to swap it out at some point. so i would really like to know about any movement in this area. all pointless as the maximum resolution glamo can drive is 640x480 (or 480x640). you'll never be able to go above that as long as you have a freerunner. (and note that that is even far beyond what glamo is designed to handle properly. its a qvga gpu. not vga). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: why not xip?
On Sat, 01 May 2010 15:12:00 +0200 Bartlomiej Zimon uz...@o2.pl said: Hi all! I want ask why we not use execution in place? Is is possible in Neo - i think it could work only on flash? It could improve some things e.g. booting and apps launching. What do You think? it doesn't work with nand flash - nor will it work with jffs2 (compression)... or any compressed fs. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
On Sun, 18 Apr 2010 11:22:24 +0200 Ed Kapitein e...@kapitein.org said: Hi Carsten, Thanks for all the time you take, answering questions about glamo in this list, i really appreciate it. I am sure i don't understand half of the technology bottle necks that the glamo has, but if the limit is 512x512 for 3D and 2D, would it be possible to just use 480x512 on the FR? or even 480x480? 480x512 would leave +/- 12 mm screen unused, but i think that could be a fair trade-off if the rest of the screen is much faster ( for video and such ) And perhaps the unused space could be used as status bar or top shelf. Is this at all possible? i have no deep knowledge about graphic chips, so the simpler the answer, there more likely it is that i will understand it :-) i didn't look that far. if you can't use all of the tiny 2.8 u have - it's useless. imho. waste of time. you could try rendering in multiple passes with 2 buffers and piece them together i guess - but by that stage it was plain - glamo wasnt intended for vga. qvga was its intended resolution. run at qvga and you'll be ok. but that will be the case with software rendering too. Kind regards, Ed On 04/18/2010 03:53 AM, Carsten Haitzler (The Rasterman) wrote: On Sun, 18 Apr 2010 03:05:24 +0200 mobi phil m...@mobiphil.com said: Thanks for the detailed answer... You told me what I did not find out in weeks :)... nevertheless: if you are talking of directfb accelerated on top of glamo - good luck. last i checked it wasn't and you'd have something a LOT slower. No.. there is nothing... was thinking to write sthg. on top of Thomas White's: http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html drm/kms work. My main point was to have sthg. that is common to both X world, and fb (Qt, non-X elf etc, other lightweight fb apps), the lowest c. denominator. And that could have been directfb, but I am more convinced that not. One of usage of this c. denominator would have been to have a global keyboard, that would cold be rendered on top of any application. taping the rendering engine, probably would have been easy. dfb isnt common to fb and x11 - it is an enitre display system of its own. there is a specific xdirectfb server on top of dfb. but it is not a common component. i think you misunderstand directfb... :) but - you'd need all the acceleration written and even then the chip simply is not capable of many ops you need or it makes them needlessly complex (you will need to go via the 3d unit and that limits all pixel primitives to 256x256 as a source and output cant be more than 512x512 for any buffer - you'd need to do complex tiling of all input and output and that will wreak havoc on things like transforms/scaling to make it look right - and effectively make it impossible). trust me - have full hw docs. had them from the day i started with glamo long before gta02 came out. after some reading i went from excited to despondent. glamo does not live up to what it seems to appear reading its checklist features. sure - it's possible to go accelerate some things and get some benefit. for each of those you now have a downside as u need a software fallback for the ones you can't - and... those now get more complex WITH more overhead. you make operation a 2x faster and operation b gets half the speed. and so on. my bet is that even if you do it all as optimally as possible with glamo+gta02 arch - you will have spent a mountain of effort going nowhere. ie not be able better in general. some things improved, some worse. and now you have a monster of complexity that has no future. glamo is a dead end chip. openmoko a dead end product line. a source base that will not be useful for any future hardware developed nor even todays hardware. the future is mostly opengl-es2 based with the ability to punt off preparation pipeline stages to multiple cpu cores - or if you are lucky, some dsp cores. as such even without this punting off to multiple cores, with gl-es2 - things work damned well - silky smooth on a modern soc. thats including rendering everything at 32bpp, compositor in x11, and more. the hardware there is a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if not better. in this situation, I admit, no point to have nor directfb nor sdl. Just a broken illusion, that efl on top of directfb would make things faster. :) But I can draw very fast the conclusion that in case of glamo, running illume and other apps, there is no point to have X windows... i disagree. how do u think you get a vkbd up on screen separate to the app, or the top-shelf (place for app name, battery, reception etc.) ? i think you are under the illusion also that somehow windows have some massive
Re: Fwd: Glamo secrets, acceleration, X11, directfb, was: [E-devel] X11 dependencies hardcoded in ecore_evas
almost instantly. then you need to do meshes. and thats a pain - also suffers quality-wise and complexity (and thus speed due to complexity overhead). max dest buuffer - 512x512 - also limited. cant even cover the screen. that alone is enough for me to say the 3d unit is useless for anyting other than trinkety little qvga 3d games with low resolution textures (where if you have a TEXTURE for a game you wrap around a model - you can afford to have it degrade to lower res - and display quality simply duffers with blurry textures, but this not possible in 2d - you cant make such tradeoffs. howd you like your text to be blurry and buttons to be blurry/blocky blobs? due to the images being used being dropped to 1/2 or 1/4 resolution etc. etc. - in 3d you have triangles define the shapes and outlines of your primitives and textures simply add skin. in 2d - not so. and the 3d unit n the glamo is at best useful for such simple 3d game-lets and tasks, nothing vaguely serious. it's interesting that 2d actually is relatively demanding on 3d units mostly due to it not being able to make such quality tradeoffs very often. ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com Spendito time ergo sum ( I spent time therefore I am -- in very vulgar latin :) ) Well... thanks for all the clarifications... Well openmoko and glamo will remain a playground to learn how not to do things, with less chance to learn how to do :) sure. if it's a playground - go play, but beware - your time will be wasted on a dead architecture and working around stupid in the limits. things like 256x256 textures when even the mbx in the iphone 2g offered 1024x1024 - and u had only 320x480 to worry about. that was a SENSIBLE hardware design decision. correct screen resolution given the grunt powering it and desired ui. the 3gs i think offers 2048x2048 - and some more modern embedded gpus go even higher. life is sane to go using gl there - and this is when evas's design decisions really come to the fore - it works wonderfully as its 100% in-line with how modern gpu's work. ) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
in software. -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
make such tradeoffs. howd you like your text to be blurry and buttons to be blurry/blocky blobs? due to the images being used being dropped to 1/2 or 1/4 resolution etc. etc. - in 3d you have triangles define the shapes and outlines of your primitives and textures simply add skin. in 2d - not so. and the 3d unit n the glamo is at best useful for such simple 3d game-lets and tasks, nothing vaguely serious. it's interesting that 2d actually is relatively demanding on 3d units mostly due to it not being able to make such quality tradeoffs very often. -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
On Sat, 17 Apr 2010 02:18:45 +0200 Bernd Prünster bernd.pruens...@gmail.com said: ever heard of the touchbook?! or joojoo... or one of the 1894 mee too ipad clones coming out (varying from arm based to x86 based). there is no room for a freerunner core based pad... - pushing that many pixels means more grunt. the gta02 already couldnt handle what it had. by a large margin. just buy one of these me-too pads and fidddle with it. hell if tangogps is the killer app - does an open os matter? as long as you can compile it and install it (toouchbook is there already for that - and it's open. not the schematics - though if you look carefully its actually a slightly modified beagleboard - so design is open actually), and os is open. the other me-too's on x86 will be pretty much just as open as any other netbook (give or take) - and yes. we know. imgtec, sgx, closed gpu. that's the case everywhere. no news there and no solution to is unless you design your own gpu... good luck. :)) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: false stamentent on http://www.enlightenment.org ?
On Wed, 14 Apr 2010 15:55:47 +0200 mobi phil m...@mobiphil.com said: On the page: http://www.enlightenment.org/p.php?p=aboutl=en The Openmoko Freerunner http://wiki.openmoko.org/wiki/Neo_FreeRunner sold thousands of devices with EFL on them. Maybe I am wrong, but the default software was never with EFL, or? I suppose no reseller changed the software etc Well the statement is really ambiguous, but however you take it it is false. If so, EFL guys, please change (I am sure they tapped the list :) ). Or am I wrong? om2008 - and it was shipped on devices. many of them. it used e17 + qt apps - e17 uses efl. launcher was part of illume. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
On 09 Apr 2010 12:37:00 +0200 openm...@pulster.de (Christoph Pulster) said: Perhaps I should clarify that I don't mean to make fun of your situation. We're all in the same boat here. No problem Werner, all your optinions and comments are very welcome. As you already said, companiess who built a solution based on the Openmoko need a reliable product AND a reliable company behind. The product, Freerunner, had a lot severe bugs (GPS not working, GSM buzzing, #1024 suspend problems). Also after fixing this with new revisions and third partys (Dr.Nikolaus), the product is not ready to compete in the market. Very poor battery life to mention just one serious no-go. The company Openmoko Inc. missed to give customers a reliable support and long-term concept. The open idea stopped behind the doors, no info about stock availability, spare parts supply etc. CEO Sean is an visionary, not a sales guy. Steve Mosher's part of the game was not evident. (BTW, what is the status of Steve according Qi ?) I had a project asking for 2500 units as a first order only. Openmoko Inc. failed to provide this customer a infrastructure. this is the problem with phones. the big boys are beginng to get it - but for them 2500 units is what they do for a verification run - and then throw out. they don't get up out of bed in the morning for a request for 2500 units. :) they will want at least 2 or 3 zeros added to that to even give you the time of day. openmoko never made it to be big enough to continue - and ye once you get big enough, the kind of thing you talk about no longer make business sense (as you are busy shopping around to telcos who will order millions of devices). catch 22 :-S I can confirm sold units worldwide is 20.000 maximum. which is a very poor result and can not give a living for anyone. The game openmoko was only possible with the financial injection of FIC. the funds are gone, the Wikireader is an anachronistic product and will not give any cashback. Not to misunderstand, the game opensource is just starting. if you need to, remember Openmoko as a early hero. Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
On Mon, 12 Apr 2010 12:19:43 -0300 Werner Almesberger wer...@openmoko.org said: Carsten Haitzler wrote: day. openmoko never made it to be big enough to continue - and ye once you get big enough, the kind of thing you talk about no longer make business sense (as you are busy shopping around to telcos who will order millions of devices). catch 22 :-S This is where an Open hardware design can help :-) No matter which role you play, you always have the purchase power of the whole group behind you. Openmoko Inc. found many doors open that would normally be closed for such a flyspeck of a company, because it promised manufacturers access to the Linux market. too late for that. the others are in on the game. and now being open enough is all that's needed. window of opportunity for om and the likes has closed - or at the best is very close to closed. The Open hardware design also increases the scalability - the small garage company that makes 100 customized phones for the local shopping mall has access to the same design resources and can have access to much of the production resources as the largest member of the group. depends on who is buying the units to make it scale - if it's a telco, chances are they want it far from being open - that includes the hw design. chaning that doesn't come from a small company like om screaming. it comes from someone big enough to change the rules and power balance so its you have to come to us and beg for a phone - then we set the rules. apple are in such a position right now for example. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customer
On Mon, 12 Apr 2010 17:39:28 -0300 Werner Almesberger wer...@openmoko.org said: Christoph Pulster wrote: Good luck. Maddog made a lot words about the Brasilian universitary which should continue the Openmoko project. Nothing happend. I think it's Sao Paulo you're talking about. USP never promised to continue the project (even though the press may have mis-interpreted this) but to give gta02-core free use of their SMT line, which is more than generous by any standard. It's not USP's fault that nothing happened so far. We still need to obtain the components, make the layout, produce the PCB, and only then we can use the SMT facility at the university. ah. components - where so much fun happens :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
On Mon, 12 Apr 2010 16:52:03 -0300 Werner Almesberger wer...@openmoko.org said: Carsten Haitzler wrote: too late for that. the others are in on the game. and now being open enough is all that's needed. window of opportunity for om and the likes has closed - or at the best is very close to closed. I think the advantage is still there, it's just harder to communicate. Also in this regard, Open Design Hardware helps: you still don't get anything like this from the now open players. if it's hard to communicate - you don't have a sales point. if someone is to spend money on something they need to be able to be told a simple thing and get it and go aha! that's just what we want!. until the market is actively seeking the kind of freedom you want to provide (schematics, cad design, 100% open source os in all ways), you are the guy in the street with a sign i have anchovie flavored chocolate. you really want some. the problem here is the market is happy with good enough. at least the market that buys millions of units. :) (that's why i mean by market btw - ie the mass market. of course niches will exist!) :) And from what I've heard and keep on hearing, there are lots of project customers who want to modify the hardware. They often also have the engineering resources to perform their changes. But also doing the rest of the phone would be too much for them. The Open phones would be sort of a reference designs created by the Open hardware development process, but not the one and only results. sure - but it seems those project customers want to feed off a stable supply line - and for that you need a mass market to consume it to have that production and thus supply line run to keep costs down, ensure basic quality of build, design, components etc. (thus why i focus on mass market). depends on who is buying the units to make it scale - if it's a telco, chances are they want it far from being open - that includes the hw design. chaning that doesn't come from a small company like om screaming. A small telco may be happy enough to finally be able to brand their products, too. I wouldn't try to deal with large telcos for now. Don't sleep with a girl who eats more than your own weight for breakfast :-) hahahahahahahahahhaha! :) maybe - the the small telcos are competing with bigger ones. the big ones get to attract customers with oooh we have an iphone! or check out this droid. branding is a nice to have... *IF* you can match the competition. you need to get there first before small telco might consider it. remember telco is trying to sell these phones to average joes - and those average joes see shiny sexy iphone, then see a freerunner... guess which one (and which telco) they choose? :) i know that to you, or to many freedom advocates all this fancy eyecandy, sexy design, high end components etc. seems all irrelevant to the goal of freedom - and if anything makes it harder, and you have a point - but that point imho vanishes with the market realities - to produce enough units to keep cost down, keep production flowing etc. you need mass market appeal. and that means matching, or beating, the competition in h i like that for the average joe. that means sexy swishy animations, beautiful graphics, good screen, responsive touch surface (capacitive), nice case/design, powerful cpu/gpu to power all the sexiness, 3g, and then apps and lots of them and so on... you need to at least provide what people now EXPECT from a phone. yes... even make and receive calls from reliably from day 1 the phone ships. :) it's a tough spot. what i see as more viable is making those that already produce phones, more open, and gradually prying things open. getting schematics is likely to simply never happen - you are talking different cultures even within such companies. the hardware sides just don't even want to hear the arguments. the software sides either get it already (and fight internally politically, or have tough tradeoffs to make - like making it more open will make your big customers go away as they can't close it down as easily), or are beginning to get it. life would be easy if they all already got it and did it. but... that's not the case. the closest to an open production-level phone today is the n900 - and it has been a pretty rocky start there. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customer
, they would probably run out of parts. It would have been unprofitable for them. In the end I recommended that the company not try to produce the Openmoko V7, even though I had spent a lot of time and money helping them evaluate the possibilities. So from my viewpoint, if there was one thing that killed the Openmoko project, it was lack of a thorough, over-all, realistic business plan that showed how the project was going to be sustainable into the future. And the lack of agreement among all of the people involved as to what the marketplace was for the phone. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 3D in EFL (Rolling dices on OpenMoko)
On Wed, 24 Mar 2010 11:56:50 +0100 Xavier Cremaschi omega.xav...@gmail.com said: Le 24/03/2010 01:22, Carsten Haitzler (The Rasterman) a écrit : On Mon, 22 Mar 2010 10:00:56 +0100 Xavier Cremaschiomega.xav...@gmail.comsaid: EFL can use opengl for its rendering (not on openmoko, because it seems we don't have an opengl-es driver). What do you mean by 3d ? Can I modelize cube, sphere, and do some projective geometry ? In elementary I cannot find an equivalent of an opengl context (QGLWidget in qt4), if someone has an idea ? see evas_map stuff - u can apply a map (a (texture)map). you define 4 points in space (3d), 4 texture u,v co-ordinates (that map the given object geometry to these 4 points - just like opengl). you cat rotate these points around the 3 axes (x, y and z) by number of degrees and you now can apply a perspective transform + lighting to this map (the 4 points). see expedite or elementary - they use this. the elm flip widget does just this to flip in 3d between a front and back side of a card. expedite crates its spinning cubes this way. it's not intended for full 3d - like making complex 3d apps/games. it's meant for 3d effects in 2d ui's. like spinning, rotating and flipping. it can be used a bit more extensively to do single geometric stuff like cubes - it could do spheres given enough faces made out of multiple objects, but that's pushing it. it could do simple 3d needed for things like mapping/navigation apps. but no - there is no qglwidget thing in evas - this imho is throwing in the towel and just do it all in opengl which is a very different api concept to evas - it means you NEEED opengl or it just doesnt work. evas provides its map feature with or without opengl present. it works (fast) in software as well as opengl. it's an always-on and always-working feature. Thanks for you answer. I just need to modelize simple dices I think (d4,6,8,10,12,20... I could see later to add the exotic ones), so if I understand what you wrote and how evas_map works, I need to : - use many evas_map to describe a dice (evas_map being 4 points, it's easy for d4...for d6 with 8 vertexes I could use 2 maps) - use available rotate functions (and own translate functions) to animate that For a d4, something like : - Evas_Map *m = evas_map_new(4); - I give my four 3d points, using evas_map_point_coord_set(..) - I do myself a projection to determine where these points are in the 2d texture (if I want a top view for example) - I set these four 2d points with evas_map_point_image_uv_set(..) - Now I can use rotate/translate to move the dice ? look at expedite and its cubes - u dont need to do the projection etc. evas has these for you - move your stuff in 2d space as u please (the 4 point x, y coords) and set z as u like. u can use the map util funcs to rotate around any point/axis. you can use the perspective call to do the projection (if you want 3d perspective) and lighting too. if you want. with a point lightsource. when done u set the map for the obj (well enable it too). you can free it now as the obj has its own copy of that map - u want to make a new one and modify it for the next frame/change -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 3D in EFL (Rolling dices on OpenMoko)
On Mon, 22 Mar 2010 10:00:56 +0100 Xavier Cremaschi omega.xav...@gmail.comsaid: EFL can use opengl for its rendering (not on openmoko, because it seems we don't have an opengl-es driver). What do you mean by 3d ? Can I modelize cube, sphere, and do some projective geometry ? In elementary I cannot find an equivalent of an opengl context (QGLWidget in qt4), if someone has an idea ? see evas_map stuff - u can apply a map (a (texture)map). you define 4 points in space (3d), 4 texture u,v co-ordinates (that map the given object geometry to these 4 points - just like opengl). you cat rotate these points around the 3 axes (x, y and z) by number of degrees and you now can apply a perspective transform + lighting to this map (the 4 points). see expedite or elementary - they use this. the elm flip widget does just this to flip in 3d between a front and back side of a card. expedite crates its spinning cubes this way. it's not intended for full 3d - like making complex 3d apps/games. it's meant for 3d effects in 2d ui's. like spinning, rotating and flipping. it can be used a bit more extensively to do single geometric stuff like cubes - it could do spheres given enough faces made out of multiple objects, but that's pushing it. it could do simple 3d needed for things like mapping/navigation apps. but no - there is no qglwidget thing in evas - this imho is throwing in the towel and just do it all in opengl which is a very different api concept to evas - it means you NEEED opengl or it just doesnt work. evas provides its map feature with or without opengl present. it works (fast) in software as well as opengl. it's an always-on and always-working feature. Le 09/03/2010 02:04, Steven Le Roux a écrit : EFL does 3D too :) On Mon, Mar 8, 2010 at 10:47 PM, Xavier Cremaschi omega.xav...@gmail.com mailto:omega.xav...@gmail.com wrote: On 08/03/2010 19:43, Davide Scaini wrote: give a try asking to mokomaze developer... I think he should give you lots of answers... maybe :) d Thanks, very good idea indeed ! Mokomaze can be a perfect model, I will read the source :) ___ Openmoko community mailing list community@lists.openmoko.org mailto:community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Steven Le Roux Jabber-ID : ste...@jabber.fr mailto:ste...@jabber.fr 0x39494CCB ste...@le-roux.info mailto:ste...@le-roux.info 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Fri, 26 Feb 2010 14:59:18 -0600 Eric Olson e...@ericanddebbie.com said: Carsten Haitzler (The Rasterman) wrote: On Thu, 25 Feb 2010 11:41:24 -0800 (PST) Rafael Ignacio Zurita rizur...@yahoo.com said: ... i'm getting at the fact that the hw side is stuck - it wont work without a pot of gold. the hw side that WORKS are the big companies with lots of pots of gold already. if you want to make something work - work with them on the software side... but you are free to ignore this advice and continue with your idea that you need to work on the process as you'll be working on it without anything being produced for a vry long time (read - never) unless you find a pot of gold. it's the hw side that has these costs that unlike software, can't be replaced by someone simply spending their time on evenings/weekends. it costs real money - get your pot of gold and it can happen, or ork with those who already have the pots of gold - and produce hardware. until then you're an armchair sportsman. you can yell about how that pass was bad or whatever... you won't affect the game - ever. you'll just cover your tv with spittle. :) Doom and gloom :) I still like the idea of a modular 3g modem in your phone. Design your next openmoko/qi/openwhatever linux pda and leave in a usb port and a cavity for the smallest 3G usb stick. Maybe place it on the end of the phone and reduce the case size later. It's not perfect, but it allows replacement of the cell module which gives you lots of flexibility. Similar things already happen -- QI's Ben gets wifi for free with an SD card slot. It just became much more useful. This is just an example that you don't need a pot of gold for everything. These solutions aren't for everyone, and neither is GNU/Linux on the desktop, but for some it will be the preferred choice. Open hardware is still fairly new -- and you _can_ make progress without pots of gold. You won't be able to get everything, but you might get more (look at GNU/Linux's progress, although I know big companies support some of its development now). Thank you to gta02-core, QI, and other people for working on open hardware. as ken young said - 95% of your gnu/linux market just went away if the above is your solution. 95% of already a small market. they are interested in a real production-level device that is in the same ballpark as everyone else in price,, design and features... BUT that runs linux (not android - android is not linux and very far from it). and that linux needs to be open enough to not get in the way - if u cant recompile a kernel or cant fix a bug .. then thats bad. the people who demand open all the way to the bottom including hw schematics are tiny subset (the 5%) and suddenly your niche market just got a hell of a lot more niche - and thats going to kill most models. but if thats what you like - good luck and enjoy. you will have a very limited selection of devices - if any and be always fighting against the grain. your costs will be high. choice low. :( but.. to each their own. the vast majority of those interested in om were interested in the above - and that included me. the rest (open hw) is just an added ooh nice but not a necessity. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 08:41:42 + Rui Miguel Silva Seabra r...@1407.org said: Em 25-02-2010 01:39, Carsten Haitzler (The Rasterman) escreveu: boys with the big pots of money are surprisingly close there. rome wasn't built in one day. fight the battles you can win - dont fight the impossible ones. sure - it's not as glorious. it's not as sexy. but it gets you one small step closer to where you'd like to be. you may never get it. that's the nature of compromises. but you can get some of it at least. Oh come on, don't beat them with a stick, if you don't have people working on this now, then when the time comes there will be pretty much nothing to show and all the time of development will have to start *then* instead of now :) The beauty of these communities thing is that one resource spent in developping gta02-core is not one resource not spent in SHR because (and I might be wrong here because I'm not into gta02-core) most likely gta02-core people don't feel as excited writing software for a smartphone environment (PIM, call support, other apps, etc...). As such, gta02-core people are not diminishing SHR people, but complementing. ask werner. he's waiting for the pot of gold to make gta02-core go from files and plans to product. waiting and waiting for it... and he's right - he needs the pot of gold. and while he waits - the design ages, components become rarer ads they age... unlike software - which has pretty much 0 cost of entry, modification and distribution other than time and effort - hardware doesn't. thats a fundamental difference. anyone - if they have source, can modify, improve or whatever some code with the only real cost being time, production, distribution is basically free (via compiling+tarring up+download/internet). hardware is not. every Download is a hefty cost - and that cost is also entirely based on how much stock you prepare for download first (100, 1000, 10,000, 100,000, 1,000,000 etc.) and for the lower numbers sometimes production just wont happen as no one is willing to produce so few. minimum production numbers etc. you could do a fully open phone 1 at a time. it'd cost $1mil+ per phone. got the pot of gold to make your own $1mil+ phone? :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 11:07:54 +0100 ri...@happyleptic.org said: Community can be another pot of gold. You can preorder the phones, raise funds, etc (see blender, or wikipedia...). That's how the small team behind the openpandora was successful. Yes, the openpandora is not a phone and thus needs less paperwork, administrative authorization and license fees, but on the other hand they build a gadget that was top-notch technology at the time of design (and still far from being outperformed by competition). successful? when they took your money 1.5 years ago promised to ship 1.25 years ago.. and still have not? sitting on your money? aweesome. trust me - it's already outperformed by things like the nexus-1 or a slew of other htc stuff - the new snapdragon based soc's and more. by double or more. and it still has yet to ship a single unit. these others have been shipping for ages (1ghz shnapragon windows mobile toshiba phone been going for a while now). openpandora is a wonderful example of a big fat FAIL on this. it's last time my money goes to any such group/venture. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 11:50:36 +0100 ri...@happyleptic.org said: -[ Thu, Feb 25, 2010 at 09:20:56PM +1100, Carsten Haitzler ] openpandora is a wonderful example of a big fat FAIL on this. it's last time my money goes to any such group/venture. The fact is they proved community does not need to be backed up by an industrial pot of gold to build this kind of hardware. Your personal feelings about the overall outcome is not on topic but as far as I can tell from the gp32x forums many people do not consider the project as a failure. they created a pot of gold by lieing to people and getting them to part with their money. they said it would be shipped by a date (2 or 3 months after you paid). it still has not shipped. i dont call that a success. i dont care how much it might be but that was unexpected delays. a few weeks ok - a few months. ok. almost 1.5 years of delay and still not shipped - after asking for money and giving a shipping date almost 1.5 years ago - fail. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 02:36:22 -0800 (PST) ghislain ghisl...@basetrend.nl said: What about the Ben NanoNote (http://en.qi-hardware.com/wiki/Main_Page). They showed how the process is done, from the beginning to the end (I don't know about the funding). i dont need yet another mini pda. i have a small army of them - that dont replace the phone junk in my pocket. i - and i would say the vast majority of people, dont want multiple things in their pockets - why do u think pda's are dead? they want 1, and the phone trumped all of it for communications reasons. if you dont have a phone you instantly made your potential market a lot smaller. if it doesnt fit in a pocket easily - you just shrunk your market significantly. the more you move your product into a market niche, the more likely it is to fail due to just not making enough volume. open products is already a niche. Although it's not a phone, I do have a working ultra-portable now for a reasonable price :) (It just needs some software-ports, but that is part of the fun). Ghislain http://www.basetrend.nl BaseTrend - http://www.openmobile.nl openmobile.nl -- View this message in context: http://n2.nabble.com/gta02-core-was-Re-OM-future-tp4628177p4631684.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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 03:10:21 -0800 (PST) ghislain ghisl...@basetrend.nl said: Carsten Haitzler (The Rasterman)-2 wrote: On Thu, 25 Feb 2010 02:36:22 -0800 (PST) ghislain ghisl...@basetrend.nl said: What about the Ben NanoNote (http://en.qi-hardware.com/wiki/Main_Page). They showed how the process is done, from the beginning to the end (I don't know about the funding). i dont need yet another mini pda. i have a small army of them - that dont replace the phone junk in my pocket. i - and i would say the vast majority of people, dont want multiple things in their pockets - why do u think pda's are dead? they want 1, and the phone trumped all of it for communications reasons. if you dont have a phone you instantly made your potential market a lot smaller. if it doesnt fit in a pocket easily - you just shrunk your market significantly. the more you move your product into a market niche, the more likely it is to fail due to just not making enough volume. open products is already a niche. nanonote is a fair bit simpler than a phone - much less RF, no complex fcc testing (and every body on the planet) to get certification, no modem at all so skipping one of the big problem areas - its very simple. its not a bad little toy - but its a far cry from a phone. ask wolfgang - he's behind nanonote - ex openmoko. he didnt learn from nanonote - he learned from om to make nanonote. why do u think its not a phone? because a phone is way more expensive - and harder. It was not an example of what you need, it was an example of how they did it and what we can learn of it. Also, it's not 'yet another mini pda', because of it's openness you can use it the way you want, just use your imagination and your programming skills :) sure - i can do that with my smartq5 too and my other myriad of toys. none of them replace my phone - and making a phone is complex and expensive. Your statement 'open products is already a niche' is the exact statement I heard 15-years ago about open-software. We are just at the beginning, just give it some time. :) and it *IS* a niche. by open products i mean the ones where you open up everything - source and hardware and the target market DEMANDS open or you wont sell anything. that market will remain niche for a very long time - if ever. the general i dont care much as long as it has cool apps and makes calls and does its job market will be 95% (number pulled out of arse - meaning vast majority) of the market. thats that's what the big boys cater to. and thats where all the best hardware is - the kind nerds so dearly want to be open so they too can play with it. the way to go (imho) is to make that 95% have more openness to it - android was a big start - maemeo is also a big positive there - as is moblin.. and now the meego. no - not 100% open, but its working its way there. if you are going to hanging out and wait for gta02-core to make a p0hone - you may be waiting forever. if it does happen you'll find yourself comparing to iphone 4g or nexus 2 or whatever is now out in the 95% of the market. and then crying why it sucks so much in comparison. that was already the case for freerunner. like it or not there is an expectation of at least being in the same ballpark - and as such the big-boys ballpark keeps drifting further away from the open one. i think it's better to make the big ballpark have more open in it than to stick to the dminishing distant pure open island far from everything interesting :( Ghislain http://www.basetrend.nl BaseTrend - http://www.openmobile.nl openmobile.nl -- View this message in context: http://n2.nabble.com/gta02-core-was-Re-OM-future-tp4628177p4631828.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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 11:16:46 + Wolfgang Spraul wolfg...@sharism.cc said: Ghislain, They showed how the process is done, from the beginning to the end (I don't know about the funding). even that is open :-) (scroll down to second part) http://en.qi-hardware.com/pipermail/developer/2010-February/001918.html and it's rather cute. :) Although it's not a phone, I do have a working ultra-portable now for a reasonable price :) (It just needs some software-ports, but that is part of the fun). Phone is super hard. I finally agree with rasterman on something and share most of what he said earlier in this thread about the economics of getting an 'open' hardware project going. It's tough. And the phone is the toughest of them all. wow! woflgang... we agree? next the earth will spin backwards... :) (seriously- nice work on nanonote. i'm just being harshly realistic here to not let people get too optimistic - all for open devices... but its hard. hyper-hard if its a phone. the simpler the device, the easier it is). OpenPandora took 4000 pre-orders and financed it that way, hopefully they will make it, they still have a long way to go, product wise and company wise. indeed. 4000 orders at $330 each - no modem to deal with either and much less pain wrt RF and miniaturisation to make it small. thats $1.3mil in the bank just to get it oign.. and then it's still 1.5 years and no product. a phone to make 40k units would be easily double that - if not triple. and thats 2g only. 3g will bump that up again. i did the sums - to do an open phone equivalent to iphone/pal pre/n900 etc. world - it'd cost about $13mil - and that was to get to being profitable (ie your profits now pay to run the operation. so u'd need to find $13mil of money to make it happen. otherwise u will eventually run yourself out of money and cease operation. $13mil would get you over the hump - just. this is why i too gave up on trying to do an open phone - the money needed was just astronomical. and that money didnt include marketing, sales, logisitcs, etc. etc. - it assumes word-of-mouth publicity (and hoping to get onto digg/reddit/slashdot etc.), an expensive $600-700 or so unit price and direct sales - not allowing for margins for resellers. (wolfgang - would i be far off the mark here? i don't think so). For the phone, what do you guys think about the osmocom project by Harald and friends? http://bb.osmocom.org interesting - from a research point of view. the real question is.. what is the reality of getting it onto a real 3g (hspa+) or lte capable chipset in the future. even then there is the fear that the hw is so raw and able to be squeeze by code, that such code should never be open as mobile networks are very fragile - and no company wants to be known as the one that sells phones that can easily bring down the telcos networks with some malicious firmware. the best i see here is firmware being open, but its signed and only signed binaries get run - do in the end this thwarts a major goal of being open anyway. i wish it would be better, but i wouldnt hold out a lot of hope here beyond this being a cool research project or ending up as above - signed only binaries will run. :( From what I understand so far, they will continue to hack their way to make a GPL GSM stack work with Calypso RF/DSP chips, and later maybe MTK chips. The RF chips themselves are way out of reach for any of us (to make our own open version), even way harder than the GPL'ed Milkymist SoC I think we will get eventually [1] [2]. So to build a phone around osmocom, we have to reuse MTK RF/DSP chips? Anybody interested in financing it? :-) raster - do you want to pre-order one osmocom phone for 1M USD as you said? hahahahaha.. yeah right :) thats my point :) the prices get so silly in small volume - u'd have to be a mark shuttleworth to do this. i am not in that league by a long shot :) if theres a multi-squillionaire floating here with nothing better to do with their money.. by all means! make this elusive open phone! it can be done - price tag above for a modern one (map3 based, 3g hspa module etc.) is about $13mil. get that money together and you have a shot. :) You have OpenPandora experience already, this one could only be better. On steroids! What do you think? Wolfgang [1] http://www.milkymist.org [2] http://en.qi-hardware.com/wiki/Milkymist_One if you can get your milkymist as an asic with good speed - we might be talking. add in a good cotrex-a8 soc.. and you have a possible open acceleration engine (can be used for 3d, 2d etc.) and a powerful soc - u can leave out the 3d unit from it so not to confuse people (or keep it in for those that are happy with a closed driver). but again - need the pot of gold above :) On Thu, Feb 25, 2010 at 02:36:22AM -0800, ghislain wrote: What about the Ben NanoNote (http://en.qi-hardware.com/wiki/Main_Page). They showed how the process is done, from the beginning
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 11:54:35 + Wolfgang Spraul wolfg...@sharism.cc said: raster, may be waiting forever. if it does happen you'll find yourself comparing to iphone 4g or nexus 2 or whatever is now out in the 95% of the market. and then crying why it sucks so much in comparison. that was already the case for freerunner. like it or not there is an expectation of at least being in the same ballpark - and as such the big-boys ballpark keeps drifting further away from the open one. i think it's better to make the big ballpark have more I do think there is a 3rd way. The gigahertz/gigabyte race is not the only race in town. Let them have it. A product that just works very well always has a chance. Usability race. Put people and their real needs and real ability to understand and use products in the center. Don't give a damn if everybody around you goes from 2GHz to 3GHz. Again, no hard feelings, let them have it their way. But there is room for slow made (but still high-tech) products. Product cycles that are so long that they allow real feedback to trickle back from users to creators. What we have now is that most feedback is ignored because by the time it reaches the creators, they are already 2 generations ahead. Plus I have to say - the industry is turning into a produce trash throw-away trash industry so fast I couldn't even imagine. Even I gave in now: When I shop for a DVD player, I buy the cheapest. Absolutely the cheapest. No prisoners taken. Inevitably, some X months later, I run into the first (officially bought) DVD with latest-and-greatest DRM tricks on it that won't play. Now I throw away my player and get a new one (of course cheapest again). This system works quite well. But it's insane! The phone industry is cranking out 1+ billion phones a year. Very soon they need to increase the crappiness and won't fix features in their products so they have a chance to sell the billions more already in the pipeline. There definitely is another way. Must be. Business opportunity! Let's see how long people will be using their FreeRunners, and how long they will be using their N900... If the FreeRunner would be bug free, I'm sure people would still use them in 10+ years, easily. Way to go gta02-core, and way to go osmocom! Wolfgang aaah - the race to the bottom. indeed. thats one way - but that kind of solves itself - whatever the smartphones used 3-4 years ago now is cheap as chips. also remember - dvds havent changed. its the same requirement as when they came out. phones and pc's are in a different world - well if the phone does more than just make calls. they have to deal with apps.. and worse - the internet. the web. and that evolves and changes every day - needing more and more resources on your interface to the internude. were it to be like dvd's where the requirements dont change... it'd get awesomely cheap - but luckily for the hw industry.. thats not the case... so they get to sell u faster/bigger/better.. just to keep up with the internet how it is now. :) let's see - if things get smaller/faster/more efficient web etc. wise.. this may change - but i dont see that happening any time soon. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 16:00:49 +0100 ri...@happyleptic.org said: -[ Thu, Feb 25, 2010 at 10:47:35PM +1100, Carsten Haitzler ] a phone to make 40k units would be easily double that - if not triple. and thats 2g only. 3g will bump that up again. I don't know for other countries, but here in France the majority of 3g subscribers never use it. All day long you can see adds on TV trying to sell video calls, TV on phone, etc, yet you could pack in a bus all the people that actually _use_ these services. internet. need i say more. as such its actually used here in australia, and in japan, and korea, and the usa, etc. - people really do use phones for looking up stuff, maps (yes downloading the maps as you go), blogging, instant messaging and email - oh god email. sure - video calls, tv etc. are pretty moot - but the other things definitely use 3g - there is a big difference between 2g and 3g for speed when it comes to loading web pages. not to mention cost-wise - 2g and 3g get priced differently with 3g being much much much cheaper for data in au than 2g generally (cheapest telco for data is 3 and they are 3g only - 2g data rates are just silly. 3g data is cheap). but - u'd need a phone that actually uses such things nicely and still most people dont have one. you'd need an iphone, modern android or palm webos device for this to really work. then it becomes a different game as your phone can make use of all that data... -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Fri, 26 Feb 2010 07:31:48 +0800 William Kenworthy bi...@iinet.net.au said: but - u'd need a phone that actually uses such things nicely and still most people dont have one. you'd need an iphone, modern android or palm webos device for this to really work. then it becomes a different game as your phone can make use of all that data... Also dont forget progress - here in Western Australia GSM coverage is static and may even be shrinking, where 3G is already far greater and expanding. The freerunner is a phone only as long as a network is available to connect to - as I found out when on holiday last year. Think driving hundreds of kilometers with no connection at all, where a 3G phone at least had a connection at many places. GSM obsolete here :( just wait until the LTE (or whatever comes after 3.5g) craze comes. gsm likely will start being dismantled - i know if i travel to korea or japan i NEED a 3g phone. 2g just doesnt work as they have no gsm/gprs etc. networks at all - only 3g. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 22:18:31 +0530 rakshat hooja raks...@gmail.com said: but - u'd need a phone that actually uses such things nicely and still most people dont have one. you'd need an iphone, modern android or palm webos device for this to really work. then it becomes a different game as your phone can make use of all that data... Lets take the desktop analogy further I use a 2004 Tosiba laptop with a celeron processor (ubuntu ) as my main laptop still. 6 years down the line the modern internet runs perfectly on it (modern games pretty much don't :). Firefox renders pretty much everything, Java works, maps, banking, server hosted apps, social networking sites; everything really does work. probably because you're a nerd and don't use what regular people do - regular peolpe use sites covered in flash - and with a 2ghz celeron and 2gb of ram... things bog down... and i hear the whingeing all the time. i keep saying close firefox - dont have 12 tabs open each with 5 flash ads and so on but that doesnt change. behavior doesnt change - there is an insistence that no matter what they do - things work properly. and it gets worse month after month. yes - it's linux. people do more and want more. and the internet requires more. i 100% disagree that the itnernet of 1997 uses the same browser and local resources of the internet 2010 for the vast majority of people. it squarely does not. and every year those resources needed goes up. Now I have two employees in my 3 people company and both my employees have had their laptops upgraded (at my cost). One has a fancy HP with one of the latest intel processors and the other a macbook. Did they really need these upgardes to use the modern evolving web? No. But they definitely felt that they needed the latest hardware to be productive in their work. Why am i mentioning all these anecdotes. Because I feel that they highlight the fact that people will always want the latest and fanciest hardware they can afford but at the sametime its just BS to say you need the latest hardware to run the evolving internet. Snapdragon is cool but the 233 MHz samsung in the Neo 1973 is still more than capable of handling anything the mobile internet has thrown up till now (if designed properly - like raster is right about the qvga screen in the OM phones). but at vga.. it's pushing it. and as more stuff becomes js and ajax.. html5 - this wil change. as you dont have flash - you havent noticed. add flash in and you'll think otherwise. and dont go blaming flash - flash uses those resoruces because of the richer things it does and people like and WANT those. and as js +html5/ajax etc. do more of what flash has been doing you will see the same resource issues in regular browsers. I do buy the 3G module and lisense cost issues and till date I don't see how this can be worked around for a fully open phone. Anyway Qi's roadmap does say Open Phone in 2012 http://en.qi-hardware.com/wiki/Roadmap aaah roadmaps. how many i have seen and how many of them are filled with complete bunk - by this i mean there is little to no REALITY behind them - they are wishlists, not firm schedules that can be done. i do hope qi manages to get there - i wish wolfgan all the best in getting there - but i know how hard it really is - he does too. it's monumentally difficult. and its difficult even if you have a pot of gold. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 11:04:26 -0500 Gay, John (GE Infra, Energy, Non-GE) john@ge.com said: As rasterman knows quite a bit more about hardware than most people I know, I'm curious to know his opinion on the Flow G1.5 and up-coming G2 from Gizmo for you? http://www.gizmoforyou.net/site/ Sounds at least as open hardware-wise and Openmoko was and seems to actually be available for a price, though a rather high one. I also find the game platform and general-purpose daughter card rather interesting. i think it's interesting. it's about the closest you can come to the guys with a pot of gold and some hw. but - comparing it to a normal smartphone is hard. it'd rough/ its bulky - very bulky. it's pretty old technology - except for the cpu *gumstix) unit. the 3g unit seems decent. no idea of reception etc. that price of 586 eur ($793 - lets say $800) (plus shipping etc.) is also double the freerunner. and people bitched on how expensive it was (it wasn't really they are just used to subsidised prices). now it's unclear if they include the gumstix daughterboards or not as its the same price. i think you need to buy them in addition (add $219 or $149 + shipping for these from gumstix (the $219 will approximate a phone like the pre/n900 etc. as you get bt, wifi 3d and dsp - the $149 earth has no wifi, bt, dsp or 3d - so you lose all of them for the drop in price). so... $800 + $220 + 2 lots of shipping (lets say $20 shipping for each - really generous as it can be a LOT more (or a little less))... so... $800 + $220 + $20 + $20 - $1060. so.. thats your price for a rough phone - yes. it's pretty open. yes - it's a tinkerers dream. but its more than 2x the price of an n900 - and the n900 is even a little smaller (same thickness) and comes with hw keyboard and better resolution screen, mountains more onboard flash (32m) as well as the micro-sd slot. so as such just comparing the devices - the n900 is 50% of the price and a better unit - but it's not open. and the n900 is one of the bulkiest things around in recent times. also you get no warranty :) but thats the price of tinkerability. so - flow - interesting. rather cool actually, but pretty rough and ugly, expensive, troublesome (need to put it together yourself). also it's android - so you'll need to port shr/debian/whatever to it (well get it up) if you dont want android (if all you want is android theres lots more nicer devices that are cheaper - but you may be a i must have open hardware guy so who knows). so all in all it's as close as you get if you must have open hw you can swizzle - but you pay a hefty premium for it. it's also bulky and rather rough (looks-wise). i don't think i'd pay for it. but thats my choice. it simply doesnt present good value compared to the hardware that's there. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
On Thu, 25 Feb 2010 11:41:24 -0800 (PST) Rafael Ignacio Zurita rizur...@yahoo.com said: Hello, --- On Thu, 2/25/10, Rui Miguel Silva Seabra r...@1407.org wrote: Em 25-02-2010 01:39, Carsten Haitzler (The Rasterman) escreveu: boys with the big pots of money are surprisingly close [snip] compromises. but you can get some of it at least. Oh come on, don't beat them with a stick, if you don't have people working on this now, then when the time comes there will be pretty much nothing to show and all the time of development will have to start *then* instead of now :) The beauty of these communities thing is that one resource spent in developping gta02-core is not one resource not spent in SHR because (and I might be wrong here because I'm not into gta02-core) most likely gta02-core people don't feel as excited writing software for a smartphone environment (PIM, call support, other apps, etc...). As such, gta02-core people are not diminishing SHR people, but complementing. You are right and that is my point. The other bits around about big companies with money doing propietary stuff is off topic; since the original thread mail was intended to talk about community projects which learn the proper software/hardware development processes needed for an open mobile phone, no about who is going to do a product for the 95% of the market and which is that product. Sorry for my english guys, maybe I did not explain the idea very well. i'm getting at the fact that the hw side is stuck - it wont work without a pot of gold. the hw side that WORKS are the big companies with lots of pots of gold already. if you want to make something work - work with them on the software side... but you are free to ignore this advice and continue with your idea that you need to work on the process as you'll be working on it without anything being produced for a vry long time (read - never) unless you find a pot of gold. it's the hw side that has these costs that unlike software, can't be replaced by someone simply spending their time on evenings/weekends. it costs real money - get your pot of gold and it can happen, or ork with those who already have the pots of gold - and produce hardware. until then you're an armchair sportsman. you can yell about how that pass was bad or whatever... you won't affect the game - ever. you'll just cover your tv with spittle. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
browser, a few tools for photo manipulation and multimedia, and which could not have any additional software installed. With smart phones, the industry has a chance to replay history. They can make the platform closed, and largely prevent the whole malware nightmare. They can reduce the universe of software configurations they have to support. It makes sense for them to do that. Sad as it is for us, the most sensible approach for phone makers is probably Apple's. I enjoy playing with my Freerunners, and my Neo 1973. Others do too. But be honest with yourself - these phones are a dead end. At this point we are like the nut-cases who want to run linux on their iPods. Ken ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
of ram, high end gpu's runing multiple screens with smooth 3d although res... and 802.111n. every month that gta02-core sits as a design and doesnt go into production is another step in the above direction. sure. you may argue that i dont need multiple screens. and i dont need more than 640k of ram or i dont need more than 75baud etc... but you know how silly that sounds if you said it now. 99.999% of the world can't live on that for their COMPUTER needs. so - you now have to keep finding new soc's to design for and new modem modules and keep re-designing gta02-core every few months to keep up with the world - but you're doing this all in theory without any production. and production takes money. who's going to pay for it? there are no small steps here. there's a big costly step of getting the thing produced at all. it costs millions of $ just to get there. who here has that in their pocket and is willing to risk it all in making some gta02-core's in the name of openness? thats your problem - thats what you need to address. if you dont have your pot of gold - you're spinning forever going nowhere becoming obsolete. the openmoko pot of gold is gone. you're not getting that back. the way i see it is - make your compromises and work with those who have the big pots of gold and bring them over to your side one bit at a time. you''d be surprised how much elements already are on your side - there are just others fighting to keep things where they are. there are some things you will never get open - i doubt u'll ever see a schematic or case cad design - ever. thats an almost impossible battle. the easier battle that CAN be won on most fronts is in the software side - kernel, drivers, userspace, open standards, infra, core, toolkits, etc. and the big boys with the big pots of money are surprisingly close there. rome wasn't built in one day. fight the battles you can win - dont fight the impossible ones. sure - it's not as glorious. it's not as sexy. but it gets you one small step closer to where you'd like to be. you may never get it. that's the nature of compromises. but you can get some of it at least. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
as little effort as possible that is not going to port onto newer soc's and platforms. that's what i've been doing - and it's paid off - as above. gl-es2.0 engine - does video textures, rotations.. hell e17 even has a opengl-es capable compositor module now that works quite decently. and there is a definite future. :) Extract from http://lists.shr-project.org/pipermail/shr-devel/2009-December/001702.html - see the thread for context. --- If you're only talking about the X protocol overhead, then that's true - although I haven't yet seen any numbers... However, it's not the driver's fault. By the time (say) GTK's rendering instructions get to our driver (i.e. xf86-video-glamo), they've been turned into a series of tiny rectangle operations which are almost impossible to accelerate in any useful way. In this sense, the way X requires programs to send their rendering commands, and the way GTK/Cairo sends its commands, and the way the X server core communicates with the driver, are hurting us. Essentially, that's why E is so much faster: it prepares larger chunks of data at a higher level where acceleration can be much more meaningful, then sends them to the server in one big block. The price of this is that the acceleration done by the driver is hardly used in most cases, so we still don't get the best out of our hardware. well that depends what engine - software - yes. cpu generates everything - all pixels and blasts them to x the fastest way it can. for xrender everything is prepared and then blasted as a series of xrender ops. for gl - same. prepared and evas blasts lots of gldrawarrays worth of triangles. it lets the gpu pipeline take it from there. as such - this is pretty much how most modern hw likes it - it likes to be given large batches of commands in a pipeline, not piecemeal ones-ies and twos-ies. :) A more fundamental redesign could potentially allow such pitfalls to be side-stepped, but this also comes at a price: Hardware-dependent code would end up existing at a higher level in the software [1], reducing the reusability of code. [1] In the extreme case, hardware-dependent code can be moved all the way up the the individual client program, abstracted by a library. This is what DRI does, in which case that abstraction library is usually Mesa, providing an OpenGL API. --- My decision about this was simple: Since I enjoy the development work, it doesn't make any difference to me that the hardware will go away in time. Nothing is forever, and this is a perfect opportunity to learn about driver development on a relatively tame piece of hardware. I don't have any immediate plans for world domination [2].. and that's totally fair enough. good to know you know what you're looking at and its usefulness etc. etc. i'm just happy that your expectations are realistic. me - i'm less about the exercise and more about the end result... but that's me :) /me goes back to whooshing his smooth lists around his screen Tom [2] ... or is that just what I want you to believe? Mwahahahaha... -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tue, 16 Feb 2010 17:33:32 +0100 David Garabana Barro da...@garabana.com said: On Tuesday 16 February 2010 17:18:27 Carsten Haitzler wrote: as for GL.. there is gl-es1.1 - but only minimally useful. can't do vga rendering - so u need to drop to qvga anyway. max texture size of 256x256? Wasn't max texture size 512x512? that was max rendering viewport (max gl buffer). this can't do vga (as vga is 640x... 640 512). maybe u can start rendering by rendering 2 buffers then combining them in 2 output blits. it's not going to be pretty for performance... or for the driver internals. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Illume2 Screenshot ???
On Mon, 18 Jan 2010 02:30:16 +0100 Bernd Prünster bernd.pruens...@gmail.com said: i just stumbled upon this screenshot [1] could whoever took it elaborate? br [1] http://scap.linuxtogo.org/files/cf45ae4ee48f88d6f74504253f905843.png illume is being worked on in svn... if u havent noticed. hell e27 even has a compositor module - really nice and simple one too that should work reliably as it requires no acceleration to work - i need to add acceleration as an option next. illume has been split into lots of modules with core layout just one, home screen (launcher) is another module or can be provided by an external app - internal kbd for e is also another module - or as before can also be provided by external app window - same for top bar (indicator). as such there is also a dual-app mode where u can display 2 apps at once (it splits the screen horizontally or vertically) and illume now properly supports multiple screens etc. etc. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Illume2 Screenshot ???
On Mon, 18 Jan 2010 02:49:58 +0100 Bernd Prünster bernd.pruens...@gmail.com said: Carsten Haitzler (The Rasterman) wrote: illume is being worked on in svn... if u havent noticed. hell e27 even has a compositor module - really nice and simple one too that should work reliably as it requires no acceleration to work - i need to add acceleration as an option next. read that on irc somwhere... so i guess praised be samsung an their money? possibly. mind u- compositor will only work on 24/32bpp so its useless for freerunner. but useful for devices capable of 24/32bpp (and thats a lot of them modern ones now) illume has been split into lots of modules with core layout just one, home screen (launcher) is another module or can be provided by an external app - internal kbd for e is also another module - or as before can also be provided by external app window - same for top bar (indicator). as such there is also a dual-app mode where u can display 2 apps at once (it splits the screen horizontally or vertically) and illume now properly supports multiple screens etc. etc. coolio! i tried activating all the modules on shr-u and nothing worked as expected (yes software not software_16 used). i played around with enlightenment_remote to avoid segfaults, still no indicator, no homescreen, no nothing. i hope the person who took that screenshot can explain how he got it to work on the neo.. i dont know how recent shr's build is - but in the wizard - select the illume-home profile. that is the one that sets your config up right for illume2 +friends -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Quick e-mail poll: Still using your Freerunner?
On Tue, 29 Dec 2009 22:30:53 +0200 Risto H. Kurppa ri...@kurppa.fi said: Do you use FR as your daily/primary phone? no. gathering dust. Do you use FR as your primary PDA? no. gathering dust. What distribution you run most of the time? no to both the above. but on other devices a mix of openembedded, debian, ubuntu or do it yourself. If you don't use FR as your daily phone/PDA, what phone did you change over to, and why? 1. i'd like something not crawlingly slow 2. i'd like to use the 3g data rates telcos offer here, but where their 2g data rates are much more expensive 3. i'd like it to work when i travel (going to korea and japan for example only 3g phones will work). 4. i want a touchscreen that is large enough to be really usable (as such the 2.8 lcd is really more like 2.2 or 2.4 thanks to the bezel - for input). 5. again speed, capacity, screen, baseband, usability. Thank you :) r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Shr-User mailing list shr-u...@lists.shr-project.org http://lists.shr-project.org/mailman/listinfo/shr-user -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tracking down reasons for segvaulting applications
On Mon, 28 Dec 2009 23:43:12 +0100 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com said: 2009/12/28 Patrick Beck pb...@yourse.de: Hi, is that not a normal enlightenment (window manager) error message? I think it will be useful to start the script from the command line. Then you get the error output directly from the python interpreter. enlightenment pops up these dialogs whenever a child it is tracking (that it would have exec'ed) exitsabnormally. either non-zero exit codes (this is meant to imply an error at the higher levels of the app - missing file, missing config, etc. etc. but the app exits with a non-zero exit code) or exits where it died due to a signal (segfault, abort etc.) e also nicely is capturing stdout and stderr and will provide that for you if it has any so maybe the app went help! no config! on stderr and then exit(-1)'ed). this is what you get as opposed to the window mysteriously vanishing and you process having vanished and you have no idea why. Ok, all irony aside, I will start with a test session from the command line and see what I can find. Then after that I'll throw some strace at it. The downside of this all is that I will have to have a GPS fix, which will force me to go outside in wintertime :/ you don't need a whole session from the cmd-line, just tun your app from it under gdb (yes it is installable on the device if your oe repositories are complete enough - or you use debian). i.e. just ssh in, then export DISPLAY=:0 to work on the local display and run app and debug as u would anywhere on linux on a desktop. (sshing in just gets you a sane kbd and desktop screen to use as your debug console :)) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Which Java JRE?
On Thu, 26 Nov 2009 15:06:35 + Arigead captain.dea...@gmail.com said: Hello all, I'm working on a project and I think it'd be cool as to show off the project's work on a phone. The OpenMoko phone ;-) Unfortunately the project is implemented in Java, which I'm no fan of on anything but a web server or browser but that's a discussion for another day. I tried our system, which is running in an OSGi Container, on Jamvm on the OpenMoko. It works but it sucks up 95% of the CPU when it's idle. Not Good! I tried the same on my eeePC and with Sun's JRE our system uses 1% of CPU whilst JamVM on the eeePC uses 40%. Obviously JamVM does not suit our system. So I was thinking of taking a look at one of Sun's ARM JRE's but I'm a bit confused by the CPU in the FreeRunner. I've read that it's an ARM920T core which uses the ARMv4 Instruction set and is ARM7 Binary Compatible. I'm totally confused as to whether this means I need an arm moves in versions of their instruction set, v4, v5, v6, v7 for example. the 2442 in the gta02 is an ooold armv4 based cpu core, and is armv4. v5, v6, v7 compiled binaries likely wont work (if they use newer instructions). any assembly for v5,v6,v7 etc. wont work. Arm4, 7, or 9 JRE. Sun don't have too many JRE's for ARM so I'm probably not going to get one that suits. I might try Cacao. If anybody could advise me which ARM Jre I need I'd be very greatful. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: future phones that you can hack. news.
On Mon, 23 Nov 2009 20:58:02 + Michael mich...@photorequest.co.uk said: The main questions will be will it need a binary only video driver for acceleration and are other binary only drivers needed for the other hardware. If this is the case, then it does not matter how smooth the graphics are, because you will eventually end up being stuck with an old and crufty kernel. here's your dose of reality. you have no choice here - in fact samsung has no choice. talk to imgtec. they are the ones keeping their driver closed. but... your point on crufty kernel is wrong - becaus is not opense the kernel components of their driver are open... but, in principle you're riight because should there be an a.out - elf style userspace chnage or oabi - eabi - you'll be stufffed too. but - as i said. this is something not even the device makers can do anything about. right now the modern soc's almost all use an imgtec 3d unit. the only other possible competitor was a samsung 6410 3d unit. as of the s5pc110 that has been replaced with an imgtec sgx540. so - it's all imgtec now. ... with the exception of some hot-off-the-press cortex-a9 soc's that use the mali-400 - an soc from ARM and guess what! this is not open either. right now there is no viable 3d accel unit option in production that is open (the old 3d unit in the s3c6410 is deprecated, so... that makes it not viable). and before you start - and say something like but samsung make the phones and the soc's you need to realise - samsung != samsung. it's a conglomerate with a parent holder, but the samsung that makes the cpu's - its a separate company to the samsung that makes phones, or tv's hell.. there's a samung that makes cars. they are separate companies, and thus are treated as such. samsung uses not just samsung soc's - they have omap, pxa, msm and others. so look at samsung like you see motorola or nokia or others. it's not a special case where they get to design the soc that is in their products. your beef is with the core licensors of 3d units. that's right now mostly imgtec (sgx, mbx etc.) and new kid on the block - arm (mali). i suggest you try and convince them to be open. and just whining won't do it. give them good business reasons. money talks. (also remember most of them wouldn't even pick up the phone for small orders of maybe 10,000 or 20,000 units. these guys will begin to listen when you talk of millions of units). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Mon, 23 Nov 2009 21:06:30 + Rui Miguel Silva Seabra r...@1407.org said: On Mon, Nov 23, 2009 at 07:26:57PM +, Neil Jerram wrote: 2009/11/7 Neil Jerram neiljer...@googlemail.com: Thanks. I think I'll look at adding this into the e17 WM. I have some code ready to share now. What would be the best way to do that - bearing in mind that the aim is to facilitate contributions and new packages for the Freerunner? If the E project is still interested in illume changes, I guess I could send changes there. But if illume isn't of ongoing interest now, maybe some Debian or SHR repository would be better, or maybe I should set up a new repository somewhere? FWIW, as well as the discussed rotation support, I'd also like to - add a GPRS/PDP toggle to the GSM gadget - add a fast charge menu to the battery gadget - fix the battery gadget so that it it goes up to 100%. So I think there's a strong case for an ongoing FR-focussed e17/illume codebase. There's an illume2 project at enlightenment, perhaps a good spot for it? It has seen some action recently, perhaps thanks to Samsung's sponsoring? who knows... but... contributions are welcome. like always - they may be accepted ax-is or punted back to the contributor with fixme's or just patched and fixed anyway... it depends on the content. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: future phones that you can hack. news._
On 18 Nov 2009 09:00:00 +0200 openm...@pulster.de (Christoph Pulster) said: a major electronics manufacturer are now sponsoring us. Sponsoring us = buying your souls ? openmoko bought yours? (well you have been pimping their products!) :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: future phones that you can hack. news.
On Wed, 18 Nov 2009 10:48:50 +0100 David Reyes Samblas Martinez da...@tuxbrain.com said: who said bada was even relevant? :) the cuestion will be, how open is bada? David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/11/18 Nicola Mfb nicola@gmail.com: On Wed, Nov 18, 2009 at 10:23 AM, Sebastian Reichel elektra...@gmail.com wrote: [...] For those of you not reading phoronix, they identifed their new sponsor as Samsung. You can read the article here: http://www.phoronix.com/scan.php?page=news_itempx=NzcxNQ Oh! now it's not anymore a secret :) Niko ___ 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
future phones that you can hack. news.
Just an FYI here. I can officially leak this. We (over in Enlightenment land) are working with a major electronics manufacturer (one that happens to pump out 100's of millions of phones every year of pretty top-notch hardware quality - and who also happens to like making phones high-spec with nice screens, good SoC's and 3G. If what we do is a phone, or a TV, or a game system, or a DVD player... who knows!). What does this mean? Well - no guarantees, but they are now sponsoring us. That says something. If we are working on something you can guess the rest I'd say. Who it is - will wait for future announcements. What, when and where will also need to wait. How open it is, will also need to wait. But you can guess that if we are fiddling with it - it's already partly open. So... just dropping a keep your eyes peeled. P.S. No glamos were hurt during this work. Actually they were not even involved. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Tue, 10 Nov 2009 16:11:40 + Dave Ball openm...@underhand.org said: Warren Baird wrote: perhaps the landscape / portrait flag should just contrain the rotation? So if you flip the phone 180 degrees, you get the 'expected' behaviour, but if you just flip it 90 degrees nothing changes? Given that these properties are for the orientation an application requests (to the WM) should ideally be used, I'm not sure how the actual rotation would help? Working from rotation would also complicate the behaviour on devices that are normally landscape - such as the Nokia N900. What I'm suggesting is that the application just says landscape or portrait, and then the WM would decide the most appropriate way to orient the screen for that device. If an application doesn't request either landscape or portrait, then the WM would rotate the screen according to the device orientation, through each of the positions the device could be held (including inverted). So the WM definitely needs to know the actual orientation of the device (such as from the FSO api), but I think the application itself only needs to request Landscape, Portrait or neither. you want a bitmask for 4 rotations as well as flips. why? because this is what xrandr supports. you want to give a mask for which rotations the app wants why do u need both 90 and 270 degrees for example? look at a g1. u slide kbd open to one side of the screen. now imaging if u slid the screen the other way you have a different button set along the other side. eg a set of psp-style game-pad controllers for games. so games would request 270 and aps rthat are built for text input with hw kbd are 90. etc. etc. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Mon, 9 Nov 2009 15:49:24 + Rui Miguel Silva Seabra r...@1407.org said: On Mon, Nov 09, 2009 at 01:28:48PM +0100, Helge Hafting wrote: But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Of course conflicting signals need to be ignored. What conflicting signals? A proper implementation won't have conflicts? app1 prefers landscape1 app2 prefers landscape2 app3 prefers portrait1 thats why i said 1. put it as properties on a window (you now know precisely which windows want what - or dont care - 1 app can create more than 1 window remember) 2. the wm knows which windows are around doign what and their properties. it can decide what to do. :) In such a system, while app1 will have to prevail and the others will have to wait. (...) There are no conflicts, but whatever software you have managing the display must be able to change orientation at exactly the right moment. Of course you see, then, that rotation is a job best served by the Window Manager, yes? :) Daemons that rotate the screen (like my omnewrotate) are simpler hacks... Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, 08 Nov 2009 09:48:23 +0100 Matthias Huber matthias.hu...@wollishausen.de said: in my oppinion, it is not necessary, because one has all needed information already in -- man XSizeHints if a window says, for exampe 800x600, and says maybe in the aspect ratios 4:3, the rotation preference is quite clear, i think. 800x600 doesn;'t even fit. its a minimum size. it's not sane to use such a property as this doesn't tell you the original rotation - just a size. you are overloading a property here that isn't meant for this information. ther's also a window aspect ratio property - again, this isn't rotation. a wm may interpret this by scrolling the window around, not rotating. or just make the window smaller if it likes it or not (eg what e and matchbox do for example). can you give us a hint where this (rotation) property can be found ? perhaps hint on manual page ? see my other mails. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 10:20:37 + Rui Miguel Silva Seabra r...@1407.org said: On Fri, Nov 06, 2009 at 08:24:13PM +, Neil Jerram wrote: 2009/11/6 Rui Miguel Silva Seabra r...@1407.org: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: Well, you cannot expect every app to have such preferences, this device runs generic linux apps that aren't made specially for the freerunner. Now, of course the app loader can do this, similiar to how we already request the cpu/backlight when launching some apps. But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Thanks to everyone for your replies on this topic. I agree with Helge, in that I don't think DBUS is a good solution, because I really want a solution that works for existing apps. You have no solution for existing apps other than causing a full stop on rotation once you get the desired rotation (which is what I do for apps that work better on landscape). I suppose for existing apps there could be a DBUS proxy that somehow works out the best orientation and then sends a DBUS signal on the app's behalf. But that seems complicated. Not smart either, because you'd have a buttload of work for little gain, and there will always be one more app which isn't supported yet, etc... Also I'm not sure why DBUS helps at all. Once a program somewhere has worked out the best orientation, why not just call xrandr directly? DBUS helps a lot because you can define a standard set of signals: 1. screen rotation apps could listen for specific screen rotation signals 2. apps which have specific needs can broadcast said needs to DBUS This means minimal aditional work for everyone. Another thought that occurred to me is that if this was a window manager responsibility, perhaps the window manager could infer preferred orientation simply from the requested window size? (i.e. requesting width height implies a preference for landscape). The only way this could be the window manager's job, was if the window manager had auto-rotation routings. AFAICT, E doesn't yet. the wm is who knows the properties of all windows - and knows which one(s) are active. it is by far ion the best position to make a decision. a stand-alone rotator is asking for trouble. it will be hell as any app can just ask for whatever rotation they want irrespective if they are active or not. it's everyone fighting over a single resource. the right place for this is as properties of a window and part of the windowing system setup - thus a matter between apps and the wm. Of course rotator apps only come up because people feel the need and writing a simple daemon is simpler than patching a quite evolved window manager. actually it's much more work doing a stand-alone rotator. That should often work for apps that were designed for the desktop. I would guess that apps written for the FR might not request specific sizes, because they'd know that they will always be fullscreen anyway - so for those apps some explicit configuration would be needed somewhere (prefer-portrait, prefer-landscape, or auto-rotate). So rotators would need to parse all the configurations? I still think DBUS is the way to do it well, but I'm open for proof otherwise. dbus is by far and wide NOT the way to do it. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 08:33:35 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Carsten Haitzler ras...@rasterman.com: no. the proper way is to set properties on your window. How exactly does that (setting a property) happen though? Is it how does setting the title? or the min/max size of the window happen? the name and class, window role, if its a dialog, transient for which window, if the app would like it to be borderless... all of these are properties. try xprop and clikc on a window. any window (freerunner or desktop - doesn't matter). THOSE are properties. you can add/create/define any properties you like. they hang onto the window until they are modified or deleted or the window is deleted. something that the app would normally do in its own startup code? (I yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. presume yes.) For apps that don't already do this - and which we'd ideally like to support without having to modify them all - is there a way that a proxy could do it for them? if an app has rotation preferences, it should set them. if it has none - it gets whatever the screen has right now - or whatever the wm chooses to implement as policy. yes - you modify apps to have them indicate their preferences. otherwise they are deemed to not care which is the case now, for example. you modify the apps - thats the right way to do it. you don't post-mortem find a way to hack things in. :) Also do you know if there's already a well-known window property for preferred rotation, or would we be inventing a new one? you'd be inventing it. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 10:14:34 + Rui Miguel Silva Seabra r...@1407.org said: On Sat, Nov 07, 2009 at 11:49:18AM +1100, Carsten Haitzler wrote: On Fri, 6 Nov 2009 20:24:13 + Neil Jerram neiljer...@googlemail.com said: 2009/11/6 Rui Miguel Silva Seabra r...@1407.org: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: Well, you cannot expect every app to have such preferences, this device runs generic linux apps that aren't made specially for the freerunner. Now, of course the app loader can do this, similiar to how we already request the cpu/backlight when launching some apps. But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Thanks to everyone for your replies on this topic. I agree with Helge, in that I don't think DBUS is a good solution, because I really want a solution that works for existing apps. I suppose for existing apps there could be a DBUS proxy that somehow works out the best orientation and then sends a DBUS signal on the app's behalf. But that seems complicated. Also I'm not sure why DBUS helps at all. Once a program somewhere has worked out the best orientation, why not just call xrandr directly? Another thought that occurred to me is that if this was a window manager responsibility, perhaps the window manager could infer preferred orientation simply from the requested window size? (i.e. requesting width height implies a preference for landscape). That should often work for apps that were designed for the desktop. I would guess that apps written for the FR might not request specific sizes, because they'd know that they will always be fullscreen anyway - so for those apps some explicit configuration would be needed somewhere (prefer-portrait, prefer-landscape, or auto-rotate). repeating... property on window. the rotation preferences are a property of a window - like min and max size are, its title, etc. etc. - stick it on the window. ignore dbus. this is not something you do by dbus. if something is related to the display - especially something is related to your window, your domain for advertising state, information, making requests and getting replies is the x11 domain as long as you are using x11. :) I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? 1. App wants to be landscape, sets property on window 2. rotator determines the phone is in portrait, rotates. Now what happens? 3. App is landscape, but screen is portrait: fail or 3. Window manager overrides rotation 3.1 but rotator determines portrait, rotates again 3.2 go to 3: fail rotate and wm should work closely together or be the same. the wm reads ande knows all the properties of all windows. the rotator can do this independantly - but its a fair bit of work. the wm makes decisions which rotation to use based on app properties and rotation preference (preference maybe being set by the user explicitly or automatically by accelerometers - how, doesn't much matter). rotator doesnt go off and do whatever it likes irrespective of app hints. it needs to take them into account - put hints on window as properties. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 156, Issue 27, Ideal screen rotation
On Sat, 7 Nov 2009 03:41:28 -0600 Jared Maddox absinthdr...@gmail.com said: On Fri, 6 Nov 2009 17:22:27 + Rui Miguel Silva Seabra r...@1407.org said: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: Rui Miguel Silva Seabra wrote: On Wed, Nov 04, 2009 at 01:55:29PM +0100, Helge Hafting wrote: [...] The software that control rotation need to know if the foreground app should run in landscape, portrait or auto mode. (And perhaps the upside-down variants as well.) Or, what I think would be the proper way to do it, the application should broadcast to dbus that it prefers no rotation, or one of the 4 possible rotation states and omnewrotate could listen to such requests and not rotate while there is such a message in the bus. Well, you cannot expect every app to have such preferences, this device runs generic linux apps that aren't made specially for the freerunner. Now, of course the app loader can do this, similiar to how we already request the cpu/backlight when launching some apps. But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Of course conflicting signals need to be ignored. no. the proper way is to set properties on your window. this is a display system thing. dbus is orthogonal to it. you set properties. you let the wm figure out what to do with the active window(s) based on their properties. Which window property, a 'no resize' flag? Is the property stored by X, the window manager, or something else? Is the code that does the rotations in the window manager? properties are stored in x - attached to the window in question. wm's listen for property changes and fetch these properties on window show and property changes. the wm may do whatever it wants then. the title of your window is a property. use xprop and click on a window. find out. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 19:46:28 + Rui Miguel Silva Seabra r...@1407.org said: On Sat, Nov 07, 2009 at 11:46:28PM +1100, Carsten Haitzler wrote: if something is related to the display - especially something is related to your window, your domain for advertising state, information, making requests and getting replies is the x11 domain as long as you are using x11. :) I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? 1. App wants to be landscape, sets property on window 2. rotator determines the phone is in portrait, rotates. Now what happens? 3. App is landscape, but screen is portrait: fail or 3. Window manager overrides rotation 3.1 but rotator determines portrait, rotates again 3.2 go to 3: fail rotate and wm should work closely together or be the same. the wm reads ande knows all the properties of all windows. the rotator can do this independantly - but its a fair bit of work. the wm makes decisions which rotation to use based on app properties and rotation preference (preference maybe being set by the user explicitly or automatically by accelerometers - how, doesn't much matter). It can do *your*way* with more work than the WM, but then, if the WM *doesn't* do rotation according to accelerometers, this is a moot point :) then do it with dbus if you insist. it's the wrong way. it's like putting drivers in your wm, or putting your email client as a module in the kernel. it's wrong. rotator doesnt go off and do whatever it likes irrespective of app hints. it needs to take them into account - put hints on window as properties. Of course, but there has to be a standard way to take their needs in account :) Being X properties or DBUS, it's the same for me. DBUS seems more natural as there's probably less pooling, but then I know only a bit more of DBUS than of X11 (which AFAIR was a bunch of huge books) :) no. dbus is far from natural or correct. that's what i keep saying. this is not something for dbus. it's something for properties on a window. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 14:53:18 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Rui Miguel Silva Seabra r...@1407.org: You have no solution for existing apps other than causing a full stop on rotation once you get the desired rotation (which is what I do for apps that work better on landscape). I imagine WM configuration for this, and a shelf gadget to make it easy to add to the configuration for an app that doesn't yet have it. DBUS helps a lot because you can define a standard set of signals: 1. screen rotation apps could listen for specific screen rotation signals Agree there. The frequency of the new DBUS orientation interface seems high enough for omnewrotate to use it instead of reading accelerometer data directly. 2. apps which have specific needs can broadcast said needs to DBUS Interesting idea, but different apps can have different specific needs, and only the WM knows which app is in the foreground. Another thought that occurred to me is that if this was a window manager responsibility, perhaps the window manager could infer preferred orientation simply from the requested window size? (i.e. requesting width height implies a preference for landscape). The only way this could be the window manager's job, was if the window manager had auto-rotation routings. AFAICT, E doesn't yet. I think my other response has covered this. Of course rotator apps only come up because people feel the need and writing a simple daemon is simpler than patching a quite evolved window manager. Yes, good point. And I also admit that the work needed for my so-called ideal solution is non-trivial, and that the result might only be a little better than the existing solution - i.e. to run omnewrotate nearly all the time, and only stop it when using an app with which it interferes in a bad way. But I think I might have a go anyway at patching the e17 WM. With Debian, and 'apt-get source', and gcc on the phone, it shouldn't be as hard as it might sound. e has a whole subsystem for this... modules. you don't need to patch anything. modules are runtime patches for the wm. :) That should often work for apps that were designed for the desktop. I would guess that apps written for the FR might not request specific sizes, because they'd know that they will always be fullscreen anyway - so for those apps some explicit configuration would be needed somewhere (prefer-portrait, prefer-landscape, or auto-rotate). So rotators would need to parse all the configurations? No, the WM (or whatever hook the WM calls out to). Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 19:57:25 + Rui Miguel Silva Seabra r...@1407.org said: On Sat, Nov 07, 2009 at 02:23:01PM +, Neil Jerram wrote: 2009/11/7 Rui Miguel Silva Seabra r...@1407.org: I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? My thinking is evolving with this discussion, but my current idea of the solution is that the WM controls whether omnewrotate is running (or equivalent, but for simplicity let's just say omnewrotate). Actually, screen rotation *should* be the job of the WM. For me, as a relative yup! that's what i was saying :) just helping people who have spent far less time than me, for example, dealing with desktop standards, properties, x11, wm's, multiple separare clients etc. etc. :) begginer, it was easier to startup with the first rotate.c written by Chris Ball and step by step improving (for instance, drop fork and link to libxrandr for better performance, control speed of reading from device, give tolerance, etc. But if it was the WM, the WM could even do nifty special effects (in graphics card that would allow it), etc... if the wm was a compositor too - which some are, yes. correct. it could animate the transitions etc. etc. OMNewRotate is a hack satisfying one need. To keep it going it needs a smart way to do it (like DBUS). X properties is probably not so good for this kind of programs. (...) As above, omnewrotate wouldn't actually be running, so wouldn't do this. If you have two applications handling screen rotation at the same time, then you're just bound to a disaster fuse. Either the WM does it (hint for more experienced E developers), or it should keep it's hands off of it :) I hope that helps to clarify what I have in mind! Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 07 Nov 2009 16:56:13 +0100 Matthias Huber matthias.hu...@wollishausen.de said: 07.11.2009 14:44, Nicola Mfb : On Sat, Nov 7, 2009 at 1:55 PM, Carsten Haitzler ras...@rasterman.com wrote: [...] yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. [...] if an app has rotation preferences, it should set them. if it has none - it gets whatever the screen has right now - or whatever the wm chooses to implement as policy. yes - you modify apps to have them indicate their preferences. otherwise they are deemed to not care which is the case now, for example. you modify the apps - thats the right way to do it. you don't post-mortem find a way to hack things in. :) Also do you know if there's already a well-known window property for preferred rotation, or would we be inventing a new one? you'd be inventing it. i don't think so, see below I agree that window properties is the right way to implement that, but we need a way to get rotation preferences now, while that may be proposed and discussed as a standard for the future. So a couple of questions: * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? in my oppinion, it is not necessary, because one has all needed information already in -- man XSizeHints if a window says, for exampe 800x600, and says maybe in the aspect ratios 4:3, the rotation preference is quite clear, i think. 800x600 doesn;'t even fit. its a minimum size. it's not sane to use such a property as this doesn't tell you the original rotation - just a size. you are overloading a property here that isn't meant for this information. ther's also a window aspect ratio property - again, this isn't rotation. a wm may interpret this by scrolling the window around, not rotating. or just make the window smaller if it likes it or not (eg what e and matchbox do for example). the only thing, i think, we need, is a little patch in the window-manager. i don't say it is easy, but this is the only right place. In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. But this seems weight as the Exec in .desktop files may be a relative path, a link etc, for sure there is a better way, may you explain them? these things are workarrounds for not having to patch the window manager, i think. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 14:33:25 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Nicola Mfb nicola@gmail.com: I agree that window properties is the right way to implement that, but we need a way to get rotation preferences now, while that may be proposed and discussed as a standard for the future. Yes, exactly. So a couple of questions: * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? I don't know (yet). * supposing the above is possible, we may add a custom configuration entry in .desktop files and delegate the launcher to set window properties Yes, that seems like a good option. * if that is not possible the wm or an ewmh app helper (the launcher itself?) may get the active current window and perform the screen rotation as needed I don't think the launcher itself can do it, because it doesn't know when the app gets mapped to the foreground. Some apps take so long to appear that you can switch to several other screens and write a short program while waiting for them :-) I wouldn't want the launcher to spuriously change the orientation of those existing screens. What is an ewmh helper? In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. Well the .desktop file can have StartupWMClass, and I think the idea is that that is sufficient to identify the resulting window. it isn't actually - it can help, but it's not sufficient. it can be ambiguous. in fact often is. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 17:31:58 +0100 Nicola Mfb nicola@gmail.com said: On Sat, Nov 7, 2009 at 4:56 PM, Matthias Huber matthias.hu...@wollishausen.de wrote: [...] * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? in my oppinion, it is not necessary, because one has all needed information already in -- man XSizeHints if a window says, for exampe 800x600, and says maybe in the aspect ratios 4:3, the rotation preference is quite clear, i think. Good point! it may be if preferred widthprefferred height then use landscape else use portrait. How may we handle the case for apps that are able to auto relayout according to screen orientation? An idea may be if ratio is in a 1 +/- x than use autorotate else use the previous pseudo snippet. correct. these apps will have minimu8m window sizes too - often set by the toolkit. the information here is now bogus and unintended and doesn't want to tell you to keep an orientation specifically. this hint is not intended for this. creasting a new atom for a hint and setting it is very easy. you are not materially saving work by overloading existing properties which as you already can see - will cause problems. We should gather if generic apps uses xsizehints at all in the proper way, I guess yes. the only thing, i think, we need, is a little patch in the window-manager. i don't say it is easy, but this is the only right place. Agree, and this should be more feasible than other heavy implementation. In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. But this seems weight as the Exec in .desktop files may be a relative path, a link etc, for sure there is a better way, may you explain them? these things are workarrounds for not having to patch the window manager, i think. Exactly! I'm writing a small apps that interact with the window manager via ewmh and it works well (tested on matchbox), i'm able to raise, activate, close windows, manage the stacking list and so on, so the idea is to add randr code to rotate them, in that way should work with every wm ewmh compliant. I'm searching for a way to retrieve the .desktop entry of a Window ID to have a nice app switcher with localized names, nice graphics and so on, and it seems that the wm class may help me in that, finally we may use XSizeHint + .destkop custom overrides when necessary? Oh last time I checked Illume about that I found it's not ewmh compliant, just curious if it is now implemented? Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 14:44:53 +0100 Nicola Mfb nicola@gmail.com said: On Sat, Nov 7, 2009 at 1:55 PM, Carsten Haitzler ras...@rasterman.com wrote: [...] yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. [...] if an app has rotation preferences, it should set them. if it has none - it gets whatever the screen has right now - or whatever the wm chooses to implement as policy. yes - you modify apps to have them indicate their preferences. otherwise they are deemed to not care which is the case now, for example. you modify the apps - thats the right way to do it. you don't post-mortem find a way to hack things in. :) Also do you know if there's already a well-known window property for preferred rotation, or would we be inventing a new one? you'd be inventing it. I agree that window properties is the right way to implement that, but we need a way to get rotation preferences now, while that may be proposed and discussed as a standard for the future. thats the job of the wm to implement the rotation and a policy (preferences) *IF* an app desires something specific - it is up to the app to say so. until it does it can be assumed to have no preference. So a couple of questions: * is it possible/safe/correct to set a window properties of a window/xclient by an external app (e.g. a launcher)? it is. but it's wrong. it's silly. it's a horrible hack. you do not need it. that app HAS no preferences. it was never written to be just landscape or just portrait. it HAD to have been written to work in either mode. it had no choice. your assumption here is wrong :) * supposing the above is possible, we may add a custom configuration entry in .desktop files and delegate the launcher to set window properties this is just silly. you are modifying the app - you are modifying the .desktop file. the code here is several times bigger than modifying the app. it's a horrible hack. don't do it. * if that is not possible the wm or an ewmh app helper (the launcher itself?) may get the active current window and perform the screen rotation as needed as such - until an app window hints otherwise - rotate as desired. if it hints that it would like to be a specific rotation, then enforce that rotation if it is not in effect yet. :) In every case and going a bit ot, is anyway possibile having a generic Window ID to retrieve the .desktop file originating the owning app? this is a complicated mess. a window id is like a pointer. knowing who allocated it is tricky. as such its not guaranteed to be able to know UNLESS the app alrady does a chunk of work and sets a bunch of properties etc. etc. and the wm tracks pid's launch id's matches these up with window properties etc. etc. - e does this. .desk to files are NOT the place for things like this. absolutely not the place. you will be abusing a mechanism not designed for this. i can tell you that i'd never accept a patch that does this - and most wm authors i know would not. you'd never get this through as a standard on freedesktop.org. because it's wrong. I'm just guessing to retrieve the pid from window properties, retrieve the executable (like /proc/pid/exe) and back search in the .desktop file definitions. not always possible. setting pid is optional for an app. even then - if the pid of the app is not the pid of what you launched (you launched a shell script that runs 1 or more child procs - thus have different pid's) you are screwed. it's an inexact breakable mechanism. i repeat. don't use it. not going to send more mails about not using it. i've said it often enough. :) But this seems weight as the Exec in .desktop files may be a relative path, a link etc, for sure there is a better way, may you explain them? the app sets the property if it cares. it it's code. otherwise - too bad. thats the better way. Thanks and Regards Nicola ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 15:04:46 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Carsten Haitzler ras...@rasterman.com: On Sat, 7 Nov 2009 08:33:35 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Carsten Haitzler ras...@rasterman.com: no. the proper way is to set properties on your window. How exactly does that (setting a property) happen though? Is it how does setting the title? or the min/max size of the window happen? the name and class, window role, if its a dialog, transient for which window, if the app would like it to be borderless... all of these are properties. try xprop and clikc on a window. any window (freerunner or desktop - doesn't matter). THOSE are properties. you can add/create/define any properties you like. they hang onto the window until they are modified or deleted or the window is deleted. something that the app would normally do in its own startup code? (I yes. see above. apps are doing it all the time. it's about the most standard way to provide information about your window, from title to minimum and maximum size to aspect ratios and more. rotation preferences are just yet more properties like this. if its a property of the window - put it as a property of the window. use the mechanism created for precisely this kind of thing. dbus is not that mechanism. Thanks. I think I'll look at adding this into the e17 WM. If you can recommend a good place in the code to starting working on this (i.e. checking for a rotation property, and invoking xrandr or omnewrotate accordingly), that would be great. 1. dont invoke any commands. a fork+exec is expensive when you can just issue a protocol request to x. the most you will do is exec omnewrotte and give omnewrotate the ability to report rotation via dbus or vis stdout. hell maybe just put it in a thread and write current rotation, if it changes, down a pipe () to the main loop. 2. look at modules in general. this is how you patch the wm. :) 3. look at conf_display module - it does resolution changes and rotation preferences already 4. look at pager module for tracking new windows (or window deletes, the currently active window etc. 5. look at e_hints.c for getting hints. some of this is wrappers around existing well known icccm and netwm properties, some is getting custom properties not wrapped. 6. look at e_border.c for more info on tracking property changes (set up a handler for the event) etc. etc. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sat, 7 Nov 2009 14:23:01 + Neil Jerram neiljer...@googlemail.com said: 2009/11/7 Rui Miguel Silva Seabra r...@1407.org: I'm definitely not following you... I envision the following scenario according to what you say, could you please elaborate on why it wouldn't happen this way? My thinking is evolving with this discussion, but my current idea of the solution is that the WM controls whether omnewrotate is running (or equivalent, but for simplicity let's just say omnewrotate). So for the current foreground app, the WM determines (from properties, or width:height, or configuration, or some customization hook, or from user direction via a shelf gadget) which of the following applies. 1. App works best in landscape. 2. App works best in portrait. 3. App can adapt to either landscape or portrait, and user should choose by turning the phone round. Then, for (1) and (2), the WM itself calls xrandr to set the correct orientation, and kills omnewrotate if it was running. For (3) the WM starts omnewrotate if it isn't already running, and omnewrotate then handles autorotation. no. this is way too ugly. 1. omnewroatte ONLY listens to accelerometers and talks to the wm (via any mechanism you like) telling it what position the phone is in. that is all it does. nothing else. all other decisions are made by the wm base on as you said above, the properties of the window - which app is currently active (change apps between one that wants to be portrait wants to be landscape, the wm has to flip orientation when you flip apps. etc. for example - e already has a config dialog for changing screen resoltion and rotation. it already handles this stuff - it's missing the logic of reading some as-yet-uninvented property from a window and 2. handling that property with respect to rotation. any wm can do this. this is definitely a job that belongs in properties of a window and the wm to read them, follow their changes, and do the right thing) Given that... 1. App wants to be landscape, sets property on window WM would call xrandr itself. 2. rotator determines the phone is in portrait, rotates. omnewrotate wouldn't be running, so this wouldn't happen. Now what happens? 3. App is landscape, but screen is portrait: fail WM calls xrandr to go to landscape. or 3. Window manager overrides rotation 3.1 but rotator determines portrait, rotates again As above, omnewrotate wouldn't actually be running, so wouldn't do this. I hope that helps to clarify what I have in mind! Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, 08 Nov 2009 02:03:47 + Dave Ball openm...@underhand.org said: Carsten Haitzler (The Rasterman) wrote: On Sat, 7 Nov 2009 19:46:28 + Rui Miguel Silva Seabra r...@1407.org said: Being X properties or DBUS, it's the same for me. DBUS seems more natural as there's probably less pooling, but then I know only a bit more of DBUS than of X11 (which AFAIR was a bunch of huge books) :) no. dbus is far from natural or correct. that's what i keep saying. this is not something for dbus. it's something for properties on a window. Sounds like we should be using window properties for passing hints to the WM, and dbus for getting orientation information from the accelerometers. that is sane. :) Maybe it's time for omnewrotate to retire, with the WM talking to FSO's orientation API [1] directly? perhaps. whatever the mechanism 1. the wm is the right place to make the decision. 2. the wm is in the best position to easily gather information about an application's window and know what window is active 3. the wm is already talking to the xserver as part of its job - and it's always hanging around 4. all the wm needs to know is some external input has decded that the screne should be rotated. be this an accelerometer, or like the g1, opening up the screen, so be it. as long as 4.1 the current status of this rotation state can be queried at any time (you can ask what position the device is in or the screen is opened up or not etc. etc.) 4.2 you can get an event when this state changes really quickly (not have to wait a while). if it were me... i'd even have the current desired rotation state be a property on the root window too... but at this point its moot - dbus or property. it's the same. from my view - the property is simpler to do. it takes significantly less code in most languages/toolkits. trust me on this one. it does. but.. as i said - at this point it's moot. individal apps preferences for rotation should be properties on their own windows. app - window properties - wm - dbus - fso WM making the decision on what direction to orient the display, based on window properties and device actual orientation etc. yes. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, 08 Nov 2009 03:14:54 + Dave Ball openm...@underhand.org said: Carsten Haitzler (The Rasterman) wrote: On Sun, 08 Nov 2009 02:03:47 + Dave Ball openm...@underhand.org said: Sounds like we should be using window properties for passing hints to the WM, and dbus for getting orientation information from the accelerometers. that is sane. :) Maybe it's time for omnewrotate to retire, with the WM talking to FSO's orientation API [1] directly? perhaps. whatever the mechanism 1. the wm is the right place to make the decision. 2. the wm is in the best position to easily gather information about an application's window and know what window is active 3. the wm is already talking to the xserver as part of its job - and it's always hanging around 4. all the wm needs to know is some external input has decded that the screne should be rotated. I think what you meant here is the WM decides whether the screen should be rotated or not - all the 'external input' provides to the WM is some hint that e.g. the _device_ has been rotated? WM could decide to NOT rotate the screen, if the current app only works in one orientation. be this an accelerometer, or like the g1, opening up the screen, so be it. as long as 4.1 the current status of this rotation state can be queried at any time (you can ask what position the device is in or the screen is opened up or not etc. etc.) 4.2 you can get an event when this state changes really quickly (not have to wait a while). Indeed. I've not played with the fso orientation API, but it looks like that is exactly what it's designed to provide. It seems sensible for this to be over dbus - given that it's an abstraction of hardware. if it were me... i'd even have the current desired rotation state be a property on the root window too... but at this point its moot - dbus or property. If the root window will only work in one orientation, specifying that orientation through a window property would be consistent - but ideally wouldn't we want the root window to be able to cope with being rotated to work in either orientation? Or have i missed something special about the root window? root window i special. it's generally got properties for the display/screen(s) as a whole. as such the desired rotation of the device is implicitly a property of the screen (device accelerometres and screen are tied in this case). thus it makes sense to set desired device rotation on the root window and desired app window rotation on the individual app windows. wm needs to track both and determine which one takes precedence based on policy and th en implement that rotation, if needed. policy is what a wm implements - that's the nature of the beast. that policy may be hard-coded in the wm or configuration for it. so to me - it makes perfect sense for such a desired state to be put into the x domain entirely as the property is related directly to the display/screen. gsm makes no sense being properties/events of x11. neither does wifi, or bt but brightness of screen, current abient lighting sensor data, etc. makes sense. as such x also covers input devices (kbd, mouse), thus anything you can deem to be an input device (touchscreen, buttons on the device, accelerometrs etc.) makes sense to put via x11, not dbus. its within the logical domain for its functionality. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, 8 Nov 2009 04:15:52 +0100 Nicola Mfb nicola@gmail.com said: On Sun, Nov 8, 2009 at 2:13 AM, Carsten Haitzler ras...@rasterman.com wrote: [...] Raster, I understand perfectly that the best way is having apps setting an XAtom and the wm managing it. But if all those people are asking for a weird or wrong solution is becouse the good way is not but the apps are asking for nothing right now. there is no standard. there is no info. thus.. it's moot. they get the behavior they get now. screen rotates if they like it or not -0 the window resizes and it is the job of an application to handle a window resize. if they like the size or not, under x11, it is the task of the app to adjust to a resize as it sees fit. it gets no explicit control over the window size. it only gets hints and to ask nicely. the answer to those hints may be no. it can and does happen. standardized, is not implemented in the WMs and is unknown to existing apps, so we are just doing a bit of brainstorming to find a feasable solution *now*. apps that don't ask - have their windows rotated if they like it or not. they NEVER have had the choice before. they NEVER knew about rotation before. they don't know or care. they never had the ability TO care before. Patching E/Illume and a dozen of apps is easy but I think peoples want use existing linux apps with their preferred WM too. 1. come up with a workable standard - 2. make sure it's clean and well thought through, 3. propose it to fdo as a new standard, 4. wait and over time it will actually be supported in apps and... the problem will go away permanently. anything else is a hack. well it doesnt need to go to fdo - but as long as it exists as a documented standard that anyone can choose to support or not, it doesn't matter. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
On Sun, 08 Nov 2009 04:37:07 + Dave Ball openm...@underhand.org said: Carsten Haitzler (The Rasterman) wrote: wm needs to track both and determine which one takes precedence based on policy and th en implement that rotation, if needed. policy is what a wm implements - that's the nature of the beast. that policy may be hard-coded in the wm or configuration for it. Is there a quick-start guide for writing an e module, maybe some simple code / example? Dave http://www.rasterman.com/files/logo-0.0.1.tar.gz http://www.youtube.com/watch?v=abNsVyYTSkU umm... and otherwise look at the modules already in e (src) and the files i pointed to :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Mon, 02 Nov 2009 14:26:24 +0100 Helge Hafting helge.haft...@hist.no said: Evgeniy Karyakin wrote: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of data flowing through it? Sure you can lower the amount of data flowing through it. Lowering the resolution is one option that several has mentioned. Another way is to draw less stuff overall: * Don't draw anything that need several passes, i.e. transparency * Don't draw anything unnecessary, i.e. cute animations * Don't ecen think of 3D. * Optimize the user interface. Never redraw the screen when drawing a smaller portion will suffice. Don't highlight an icon by changing the background color. (Lots of pixels).- Just draw a 1-pixel wide square around it, for example. (And make sure your drawing library doesn't do anything excessive behind your back, such as drawing the entire icon with that border - because that was simpler to implement. The situation is not hopeless. The entire 640x480 16-bit display is 614400 byte, or 0.6MB. 7MB/s means the entire display can be updated 11 times per second if need be. In theory, anyway. Anything updating a smaller portion of the screen could be even more responsive. 11 fps assumes zero cpu left to actually do the drawing. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, 31 Oct 2009 09:34:17 +0100 Laszlo KREKACS laszlo.krekacs.l...@gmail.com said: On Sat, Oct 31, 2009 at 9:21 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. In that case you just killed any application which are drawing oriented. So no Xournal, Sketchbook or any such application. no you didnt. your stroke would go from the dotty broken one to a continuous one - like your finger actually traced on the screen. the sensors just didnt pick it up. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, 31 Oct 2009 09:21:13 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Carsten Haitzler (The Rasterman) schrieb: On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Laszlo KREKACS schrieb: To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. the problem is not differentiating between slide and click - e and elementary have this too. it's that if you drag horizontally for example, your actual events often look something like: ++ +--+ +--+ +-+ ++-++ +--+ + + + +---+ that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. and that's what i told you e and elementary have too. the problem is your finger moves the entire length of that line. the actual input events you see are the discontinuous stutters as above. see the + by itself? that's a press +release on the same spot. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. that's what i said... and it should be done in tslib/x - every toolkit and app should not have to go implement this again and again. the lower layers should sanitise input by the time it gets to x clients. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. well not wm. wm's dont intercept or modify events in any way. each x app (the wm, or the app listening to the events on the window where the events are going) gets them. so the choice is. 1. every toolkit+app does it (every game using sdl, every GL app (tho this is hypotherical - this is just the general case, not gta02), elementary, e, gtk, qt - they all need to repeat the same logic to filter these. elementary and e have logic to know the difference between a tap and a drag. the values are configurable and tunable. the problem is all the dirty input. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, 31 Oct 2009 11:38:59 +0100 Michal Brzozowski ruso...@poczta.fm said: 2009/10/31 Carsten Haitzler ras...@rasterman.com you pressed just once - or you think you did. but you actually had a press, a release, and a press , release etc. again because your pressure went above, below and above the pressure level needed to register a click. What's the pressure level? Is it in the the hardware? Is it possible to adjust it? nothing in software i have seen. if it was possible it would have been adjusted long ago... the driver already has code to de-jitter the input (smooth it out) it may as well de-jitter the temporal information too. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Laszlo KREKACS schrieb: To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. the problem is not differentiating between slide and click - e and elementary have this too. it's that if you drag horizontally for example, your actual events often look something like: ++ +--+ +--+ +-+ ++-++ +--+ + + + +---+ if you dont press firmly with a sharp point (stylus, fingernail etc.). you can go to every app and start trying to add filtering to close such gaps, but now you duplicate that code everywhere. IMHO tslib/x should filter it so the input to clients is the intended input by the user. also you will have unintended clicks (drawing press/release over time): + +-+ +-+ you pressed just once - or you think you did. but you actually had a press, a release, and a press , release etc. again because your pressure went above, below and above the pressure level needed to register a click. imho there should be some filtering on the input events that patches these gaps. and that filtering should go in x or tslib. capacitivie screens are much more sensitive and have a different problem - but their events are filtered too as you dont get a point - you get an area that is pressed, so they have a hysterisis on how big the area has to be first to start a press registering and then it has to get much smaller that this area to stop. eg: press start @ 8x8 pixels, press stop at 3x3 pixels. as long as your press area, once registered, is 3x3 pixels, it will continue to be pressed until it gets below. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 11:37:06 +0100 Petr Vanek van...@penguin.cz said: @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... i have been trying gry* lately and more less like it. btw can you already change the background image in Illume settings? i still get the Enlightenment was unable to import the image due to conversion errors ? u are probably missing edje_cc from the distro -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 11:12:29 +0100 Bernd Prünster bernd.pruens...@gmail.com said: Petr Vanek wrote: lots of alpha blending - if you have the 16bit engine you get no scale cache (thats 32bit engine only). but worst.. is the font style. check carefully. text has a soft dropshadow. that is drawn by 1. drawing the shadow first and that draw 25 copies of the text with very faint alpha. THEN draw the text on top. that is a pretty big expense. there is no text effect cache in evas at the moment, so this really hits you. turn off the soft dropshadow effect in the theme.. and watch it get 3 or 4 times faster (expedite has a test just for this - on a desktop (in fps) i get 128 and 489 fps respectively just by having no soft shadow on the text). thats pushing on close to 4 times faster. it's an effect - that doesn't come cheaply. the alternative (an actual blur filter) isn't too cheap either. but it's something that can be improved for sure. you want it fast? turn it off. :) Thank you for all the explanation. I think the 32bit engine is the only to go with now. Perhaps the optimization is is already done, maybe not. @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... even that can be slow. in this case, the text will be drawn 5 times to produce that effect. i started a rewrite- illume2 is in svn. its much cleaner and leaner designed to allow for replacable home screens (ie a home window provides by either another e module or another process). as well as top shelf (inf act any corner/region of the screen) can also be a window provided by.. another module... or another process etc. its much more like the kbd code. it's started. it's not usable. it's on the backburner until a bunch of other tasks are done that are much higher priority. ok, will hope for better times to come developed? What do you use on small device? Illume was ditched long time ago, is there not a replacement with attention? Anything you could recommend? can't talk about it :) perhaps we can benefit from it in (near?) future... :) thank you Petr ___ 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 15:38:46 +0100 Bernd Prünster bernd.pruens...@gmail.com said: Carsten Haitzler (The Rasterman) wrote: gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... even that can be slow. in this case, the text will be drawn 5 times to produce that effect. rater, would you mind to elaborate? (is outline the fastest effect if you want to enable the user to set a custom background while maintaining the labels readable?) yes, but it's still 5x slower to draw than no outline. a suggestion: just put a semi-translucent black box under the text and have white test. this will be readable everywhere and be fastest. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, 28 Oct 2009 10:09:36 +0100 Petr Vanek van...@penguin.cz said: As an important but overlooked side effect, the more capable the graphics toolkit is and the more bloated and unfriendly the resulting end user interface will be. While we were at replacing the original gnome mobile desktop, I would have liked to start from a minimalist but inovative toolkit more adapted to limited hardware like the freerunner or the many other gadget with only a small touchscreen that will keep getting out, instead of having one more toolkit for the same device range for which we already have dozens. my 2 cents: we can have lighter themes in E (as for example gry is, thanks the author for that!), but then need to have the X11-16 working - at this point, it has been recommended by Raster not to use it and even the new SHR phoneui apps cannot work with X11-16. So we are going back to the even slower engine. you dont need it for lighter themes to work. it wont have as good an effect though. but see below. Could this be looked at and revised? We need X11-16 for the Freerunner, the 32bit rendering is way too slow on Freerunner. i'm not going to do anything to the 16bit engine. why? it's 100% parallel code to the 32bit. and it's more work to do it as the format is more complex. every operation is in 16bit or 16bit + alpha plane mask. it doubles maintenance work. i have enough work just making 1 engine fast and maintaining accelerated engines (xrender, gl, ...). :( 32bit engine is much mroe stable and more capable. it is slower. but unless someone steps up to the plate and does the work, it's not going to get done. 16bit engine was never complete from the start, as it was written to make 1 specific app fast, and only what it used was implemented. Illume is absolutely unmaintained - as Raster pointed, it hasn't been actively touched for a long time. Please see list of Illume immediate issues [1]. correct. as it simply hasnt been on a list of priorites in the last year. it's far backburner stuff :) Raster, are you using Illume yourself somewhere? Could Illume get some attention? Otherwise it's going to die with the Freerunner users getting another phones (Pré etc). no it isn't :) trust me on that one. :) nothing to do with freerunner. as for illume - i am not using it. there is an illume2 module in svn that is a skeleton rewrite that just does window arrangement in a very primitive way right now. i don't have time to work on it right now either. As i see it, if the above will not happen, users will slowly drift away to solution perhaps not so optimized but feeling lighter and maintained. So the wish for E being THE toolkit for mobile devices will disappear. And we can see this already. SHR has been asked several times for more options in window managers. And as SHR has no manpower to provide this, Debian might start gaining attention, proper deb packaging of FSO will help this a lot. from that point of view... i'll disagree. you'll know why at some point. :) it'd love to chat about it... but i can't. :( Petr [1] http://wiki.openmoko.org/wiki/Illume#Issues ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, 28 Oct 2009 11:27:03 +0200 Michael 'Mickey' Lauer mic...@vanille-media.de said: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? good words mickey. good words. :) (i have a todo item for the scrole rto have a page mode. it already has a page mode actually - but its a scrolling one much like iphone's N pages of icons - but it's infra to simple provide some theme elements that you press and they jump up/down/left/right a page and then do the jump - so it's mostly there. it just hasn't been any priority for me - am working on an oldie request to get rotatable objects.. which now works. under flux.. but works and renders... image and text objects so far are working. in theory all other basic object types too, but smart objects - not yet). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, 28 Oct 2009 11:15:46 +0100 Davide Scaini dsca...@gmail.com said: This discussion is _very very_ interesting! And for sure we'll have progress... quote: if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. I will ;) please give me and my staff a couple of months... hehehe :) OK, we -as freerunner users- have a lot of patience, we'll see (we need manpower (community power)! wtf!). d indeed. indeed. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
of the world. ... I will. I can recall you previous posts on the topic. go for it. they exist. but not in most of the world. in some corners. find a faster alpha blender or a faster super-sampling/sub-sampling scaler or... :) (i am excluding neon asm here as its off topic and not on gta02, but if you had something with neon you wouldnt have this conversation as performance would be fine) 7. but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. and these don't suck with EFL. i'd not compromise the future if i were smart. Frankly speaking you never developed for GTA02, yes? you aim seem always were in future, and this is ok. I am sure that for example scrolling area pre-rendering if good for future. wait? never? maybe you forget. i WORKED at openmoko before gta02 was released, during and after. i very much did develop on and for it. i was kicking glamo around long before it was sold. there were REASON why i punted questions to this list like what would you guys say if we dropped to qvga? as there was a replacement lcd with the same dimensions but qvga. i stopped fiddling with my gta02 some time late last year/early this year as i got hardware that is much better in my hands. 8. ... most games i know of are written to work on the highest end graphics cards at the time. why? ... Best games are written with other objectives in mind, this games are really interesting for anyone from time to time and for sure will live in ages (chess, nethack and so), our grandchilds will play nethack, be sure. Is it better to make pefrect things? And optimization is always good - you can feel that 10ms latency and 100ms latency is different even both are more than enoght for UI, but you feel that 10ms latency is much better. ok. talking different worlds of games here. i'm talking the ones that come out for ps3, xbox, and the pc games you buy on a shelf - not chess or solitaire. regardless.. there's a multi-billion dollar industry for the quakes of this world. not so much for chess or solitaire :) so maybe i didnt explain that well - i apologize. i was thinking THESE as games, not chess etc. :) 9. ... BUSINESS CHOICE ... Everyone here follows it's goals. Carlsen make E. Other want to do hardware. Others want to use free hardware. Others want to increase development skills and hack that HW. Others just feel fun reading this book. Others have this job. Someone even makeing money from OM. ;) All this is ok, and I see nothing bad on making some great E developer to think a bit about optimizations - nobody loose from optimizing of E and writing a bit of technical descriptions :) trust me. optimisation is what i do. i have an xrender engine for evas. it's complete. it does everything. why isn't it used? because my own software rendering code has outperformed xrender year on year. i am still waiting for xrender with its partial hardware or claimed full hardware acceleration to beat the software i wrote. i have been waiting for years. i have an OpenGL and GLES engine. i have benchmark suites that compare engines.. apples vs apples. they do the exact same operations. the same drawing (within the limits of their system). and yes - OpenGL on my desktop (Nvidia 8600GTS vs core2-duo 3ghz). opengl... is 2x the speed of software. but considering thats software... thats not too bad. a modern high end dedicated gpu is only doing 2x the software speed. i know something of optimising. i know something of playing tricks to avoid work. in fact evas is avoiding work all over the place. but none of the themes are apples vs apples. i know just where evas has performance problems, and some of them i just chalk up to well.. it is simply not worth my time and effort to try as frankly.. the problem is already solved - newer systems are fast enough were it doesn't matter. some others its more a matter of just not pushing efl so far. if you have to sit and compare. make sure your comparison is fair. apples vs apples. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 10:01:58 +0100 DJDAS dj...@djdas.net said: AHAHAHAHAH.Guy, please go home I followed this thread and read too much bul***it but now it's very very interesting your position! So E it's a very optimized-full_of_fancy-magical-biggest window manager BUT all of his stuff works like Qt only if you don't use them! :D VERY FUNNY! Please stop spitting sh*t on the Glamo and the Freerunner, E is simply a pain-in-the-a** and nothing more. It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card Be serious please... you show and immense amount of knowledge here, both of the hardware, of software and graphics in general. i'm amazed. i shall take your advice as you obviously are someone of massive experience. i see that people reporting that its faster and better on a gta01 @ 266 mhz (2/3 the cpu powerd), same screen and no glamo are obviously wrong. you indeed know much more. the smooth rendering on a 206mhz strong arm is obviously just incorrect and i'm a fool to think so. i shall be quiet and let your amazing skills make everything blindingly fast and smooth. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 11:11:04 +0100 DJDAS dj...@djdas.net said: Carsten Haitzler (The Rasterman) wrote: you show and immense amount of knowledge here, both of the hardware, of software and graphics in general. i'm amazed. i shall take your advice as you obviously are someone of massive experience. i see that people reporting that its faster and better on a gta01 @ 266 mhz (2/3 the cpu powerd), same screen and no glamo are obviously wrong. you indeed know much more. the smooth rendering on a 206mhz strong arm is obviously just incorrect and i'm a fool to think so. i shall be quiet and let your amazing skills make everything blindingly fast and smooth. Given that I never said to be an expert but simple telling my point of well.. you're telling the one that wrote the graphics code, that has read the glamo hw docs, has worked on it long before freerunner was on sale, who has written graphics code for many platforms, manye cpus of many varying levesl of speed (from 7mhz 68k up), many gpu's from old console hardware to 3d gl... that he's talking bullshit (and being very rude about it, providing no evidence, numbers or anything else to back anything you say up) about exactly the things he's deeply involved in. thus.. you must be an expert beyond my experience and abilites. you, sir, are rude. that much i definitely know about you. the rest. you have no idea of what you speak. you showed it in your previous mail. your opinions on this are the equivalent of me giving my opinions on tcp stack design. worthless. the other people in this thread have actually read what i said and gotten it right. but you, have not. you have simply resorted to an incredibly rude and disrespectful outburst. with no provocation. if you are an IT manager, i am amazed you got that far and stayed. it's one thing to be frank and be factual. it's another to behave like you. if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. i have been factual, realistic and constructive. i have stated that freerunner is a limited platform. it's one of the slowest (if running at its native resolution i have ever worked on, and i've worked on a fair few. there is a limited amount you'll get out of it. and it's not an architecture you're going to see again. so how much effort do you put into a 1 -off that will not gain more units in the general user population over time? you find quick ways to make it do what you want. i have constructively suggested those - 1. simplify theme so its solid rects and text and it will look like qtopia.. and begin to run like qtopia does. but it is NOT being used like that. people are using themes that have scaled image backgrounds and buttons and list items with multiple layers of graphics rendered on top of eachother. make this simple and.. speed will follow. no one has to go change their toolkits and listen to you. the other easy and feasible option is lower resolution - draw fewer pixels and you'll get more speed. these are developers talking to other developers. i am telling 1. the users and developers that insist on vga, that they are paying a high price for their insistence. the hardware simply wasnt designed to be optimal on vga. trust me. i've read the glamo docs. vga is the top LIMIT of its capabilities. it's being stretched. these developers ALSO decide the themes they use as part of building SHR for example. the default is a generic default - it's not tuned for really slow systems. tune away for what you have. i havent shut anyone up. i have told them they are stuck with slow hardware. don't expect miracles. make a sacrifice. the device, the theme or the resolution. choose the lamb for the slaughtering. enlightenment and illume have seen pretty close to zero attention since i left openmoko. it's a BUSINESS CHOICE. no one is paying me to work on it. i am getting paid to put EFL on significantly superior devices that handle it wonderfully. everyone i talk to in the world of actually producing products, and with whom i work, aim far beyond openmoko. they want gui's that are smooth, silky, fluid and beautiful. they have ui designer requirements for things like translucent lists with static backgrounds. EFL does for them what no other toolkit can do. MEET BUSINESS REQUIREMENTS. if you like to use that word. and it's doing that wonderfully for them. the benefit to the openmoko users and community is that the work to improve things there gives them improvements too. it also paves the way for when SHR and so on are fully ported to better devices, like the palm pre for example. GTA02 in comparison to a palm pre is a very very very weak device... except in 1 respect. screen resolution. as for e17 not runing on any desktop acceptably. i really have to laugh at that, as i have had it run acceptably on an hp mini-note 2133. 1 ghz via c3. really slow. e is just fine on it. just compile and run. compiz doesn't even
Re: Centralization of graphical awesomeness
will live in ages (chess, nethack and so), our grandchilds will play nethack, be sure. Is it better to make pefrect things? And optimization is always good - you can feel that 10ms latency and 100ms latency is different even both are more than enoght for UI, but you feel that 10ms latency is much better. ok. talking different worlds of games here. i'm talking the ones that come out for ps3, xbox, and the pc games you buy on a shelf - not chess or solitaire. regardless.. there's a multi-billion dollar industry for the quakes of this world. not so much for chess or solitaire :) so maybe i didnt explain that well - i apologize. i was thinking THESE as games, not chess etc. :) 9. ... BUSINESS CHOICE ... Everyone here follows it's goals. Carlsen make E. Other want to do hardware. Others want to use free hardware. Others want to increase development skills and hack that HW. Others just feel fun reading this book. Others have this job. Someone even makeing money from OM. ;) All this is ok, and I see nothing bad on making some great E developer to think a bit about optimizations - nobody loose from optimizing of E and writing a bit of technical descriptions :) trust me. optimisation is what i do. i have an xrender engine for evas. it's complete. it does everything. why isn't it used? because my own software rendering code has outperformed xrender year on year. i am still waiting for xrender with its partial hardware or claimed full hardware acceleration to beat the software i wrote. i have been waiting for years. i have an OpenGL and GLES engine. i have benchmark suites that compare engines.. apples vs apples. they do the exact same operations. the same drawing (within the limits of their system). and yes - OpenGL on my desktop (Nvidia 8600GTS vs core2-duo 3ghz). opengl... is 2x the speed of software. but considering thats software... thats not too bad. a modern high end dedicated gpu is only doing 2x the software speed. i know something of optimising. i know something of playing tricks to avoid work. in fact evas is avoiding work all over the place. but none of the themes are apples vs apples. i know just where evas has performance problems, and some of them i just chalk up to well.. it is simply not worth my time and effort to try as frankly.. the problem is already solved - newer systems are fast enough were it doesn't matter. some others its more a matter of just not pushing efl so far. if you have to sit and compare. make sure your comparison is fair. apples vs apples. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 15:51:48 +0100 DJDAS dj...@djdas.net said: Christophe M wrote: Hi guys ! I don't want to feed the troll but lets compare what's comparable ... You compare Qt framebuffer with E over Xorg ... In one case you have a Xorg who is running in the other it's directly accessed ... Not true, because if Raster was right the only problem would be the Glamo chip so I would like to say why there are so many differences between Qt and E ;) i never claimed the glamo was the only problem. get your facts right. try reading first. it's a handy skill. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 15:47:02 +0100 DJDAS dj...@djdas.net said: Carsten Haitzler (The Rasterman) wrote: well as i said. it works fine and fluidly on many other devices. Even Windows Vista works fine and fluidly on 3000$ desktops this doesn't mean it's optimized ;) but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. and these don't suck with EFL. i'd not compromise the future if i were smart. Let me you know that in nowadays payments system about 70-75% POS terminals run on Z80 processor or Motorola 68k family...when you stripe your card the system reads the magnetic stripe/microchip (handling security encryption stuff) calls the banking server, communicates with the cash register shows you the PIN request and prints the receipt...there is no need for a quad core to do these things concurrently ;) Personally, before buying the Freerunner I had a Nokia 3650 for 4 years, so I'm not one of those who need the latest hardware to run the latest software which does nothing more than add fancy icons providing the same functionalities and costing double than the previous one...so when I'll have the need to buy a new device probably OM or someone else will provide me a new OPEN hardware (this is what I really need, nothing more) to develop, and use, OPEN software :) why are you not complaining that linux sucks on an 8086 on your desktop? Because Linux doesn't sucks on an 8086 ;) because Linux is well designed, is scalable, is optimized and can run even on a 8086...Desktop i think you just illustrated my point where i don't think you know what you are talking about. an intel 8086 can't run linux. a linux requires a minimum of an 386 with mmu. the 8086 was a 16bit precursor to it. is another thing, I don't need compiz or E to show a window with two buttons to connect my wifi or calculate my monthly expenses, this is only a commercial stuff, not for me ;) because hardware moved on. most games i know of are written to work on the highest end graphics cards at the time. why? Because software houses and hardware manufacturers have to sell something to stay on business ;) we are talking about an open platform to develop and use open software on, not on selling an iPhone ;) by the time the game is out and is selling - everyone has finally upgraded to those cards. they were top end 3 years ago when game design started. now they are low to middle end. gta02 is a a middle end device that came out 4-5 years after its components were middle end - except the LCD. you have a 4-5 year old set of components driving a high end screen. you will pay a cost. the developers are smart if they look forward to where hardware will be in N years and make sure they are on the right path for that. if it works now with some tuning and simplification of things like themes - then great. their code, apis and logic dont need a rewrite every few years. This is only commercial stuff, I don't want to sell nothing to anyone, just develop for fun and use my Freerunner as a phone without the need to wait 3 seconds to answer a call... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness [ot]
On Wed, 28 Oct 2009 00:38:28 +0100 Michal Brzozowski ruso...@poczta.fm said: 2009/10/27 Marcel tan...@googlemail.com Am Mittwoch, den 28.10.2009, 02:02 +1100 schrieb Carsten Haitzler: [...] why are you not complaining that linux sucks on an 8086 on your desktop? Because Linux doesn't sucks on an 8086 ;) because Linux is well designed, is scalable, is optimized and can run even on a 8086...Desktop i think you just illustrated my point where i don't think you know what you are talking about. an intel 8086 can't run linux. a linux requires a minimum of an 386 with mmu. the 8086 was a 16bit precursor to it. owned. scnr :) have you googled linux 8086 ? with linux i'm not lumping in uclinux, elks, etc. as they do come under different names :) notice.. i included desktop... and at least i'd hope to imply that would be the desktop he speaks of... ie how great compiz is and so much better than e17. :) (just using context). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin anthropophag...@gmail.com said: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of none. it's a hardware issue. you simply cant read or write to video ram faster than that. andy tried timing stuff all that happened was instability from memory. glamo is most likely also the cause for the cpu runnig at 400 not 500mhz. the extra load on the memory bus (because glamo is hooked there externally providing another addressable chip) probably caused the instability. remove it and there is a big change the cpu could run at 500mhz instead of 400. it's rated to do 500. (yes power consumption would go up - but it'd only be up while its on. when suspended it wont matter). data flowing through it? There's one neighbor unanswered thread with a render on the device - and this will then limit what you can render. evas can't be fully accelerated by the glamo. it has too many opretations. a bit like asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx chip ever was designed to do and you will hit software fallbacks. evas has multiple engnines. software (which is what is used - the 16bit renderer as opposed to the full 32bit one). it has xrender - if xrender were fully accelerated this should be better, but glamo cannot fully accelerate all the ops evas uses, so... it will rely on software fallbacks. thus slow down. my bet is you'll end up same speed as the pure software engine, or worse. aftera bunch of hard work you'll have gone nowhere. evas also has a gl and gles2 engine - but thats no use on glamo. it's gles1.1 and very limited (from memory texture size is 256x256 which is pretty useless for 2d as most data you deal with breaks these bounds). question on how to start the kernel with qvga resolution. Aside of no need to do that - just configure x for qgva. :) this, what can be reduced, for example amount of available colours (256 or even 16)? And if this [too] low throughput only of video memory channel? 256 won't help. it increases complexity and really reduces display quality through the floor. the best best is qvga 16bpp. its simple. it doesn't require any hard work. it is actually the most common resolution for most phones and devices out there so the software is more portable if you work on that (and then higher). but... in the past everyone has moaned and complained and refused to use it, and insisted on their vga resolution... and then complained about speed. if people don't believe me that the gta02 is just plain a bad bit of hardware and you have few choices here's some examples. here'es an ooold efl demo app i did: http://www.rasterman.com/files/eem.avi and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, qvga(240x320). it's from like 2001/2002 (from memory). its ancient. and watch it run evas: http://www.rasterman.com/files/eem-live.avi here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m ram, and 800x480 (higher res than gta02): http://www.rasterman.com/files/ello-elementary-smartq5.mp4 everywhere i look... theres much better hardware. if you look at performance vs age of hardware (when it was released) gta02 is almost at the bottom of the pile. :( you simply have a bad piece of hardware if you want graphics performance. as soon as you acknowledge that and either downgrade the device resolution for example to bring it in line with its performance, or just use different hardware, the better life will be :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
will be :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 14:53:50 +0100 Marcel tan...@googlemail.com said: Am Dienstag, den 27.10.2009, 00:11 +1100 schrieb Carsten Haitzler: On Mon, 26 Oct 2009 12:23:51 + Vasco Névoa vasco.ne...@sapo.pt said: Downgrading to QVGA is something that should have been done a long time ago. There's no point in trying to force a badly designed system. How do we do it? Which files must be changed? last i checked... 1. xmd-line option to xglamo (kdrive) server to select it, 2. xrandr to runtime select it. note that toushcreen driver didn't account for res change so ts coords were still assuming 480x640 - this is a small fix needed for it to be totally usable. not sure if this was ever fixed, but if it hasn't been - this is a good indicator of how no one has bothered with qvga. thus the complaints. try it. you'll find it significantly faster. see videos below - 206mhz ipaq3660.. smooth. I tried to got to qvga for graphics performance testing about a week ago. This is needed (tested on SHR's 2.6.29-rc3): echo qvga-normal /sys/bus/spi/devices/spi2.0/state xrandr -s 240x320 To return to vga: echo normal /sys/bus/spi/devices/spi2.0/state xrandr -s 480x640 Problems: - SHR's pin entry dialogue and shr-today have a too large font so they're hard to read, but still (kinda) usable, didn't try other apps http://scap.linuxtogo.org/files/3a88e6beb3253362d14384ec3f3a3dfe.png (yes, that's the whole screen) - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg If our software would run well in that resolution and if the display would make it (better than now), I would clearly prefer qvga for performance. I was about to write a little game, but that's impossible with that horrible vga rendering performance. did dpi get adjusted too? still 285dpi? check e's scaling settings. it can adapt to dpi if it is set up to do so. it also has a manual scale switch to set it to whatever u want. whatever e sets, elementary inherits too, unless the theme has been done in such a way not to allow scaling (the default does). custom written edje files with font may also not scale for the same reason a different elm theme may not. if things are done right it should just magically work on qvga and look wonderful. as for display artifacts - maybe its a refresh issue or a screen timing issue. not sure. i remember those screen artifacts long ago (like before freerunner was even released). looks like nothing has been fixed since :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 20:33:12 + Rui Miguel Silva Seabra r...@1407.org said: On Mon, Oct 26, 2009 at 11:16:45PM +0300, Gennady Kupava wrote: http://www.rasterman.com/files/ello-elementary-smartq5.mp4 Thank you for videos, but on high-resolution one we can see exactly same slowness as on FreeRunner - exactly! See how top bar slides out on close of clock and button test - exacly as on my FreeRunner. Look how slow scroll is, again as on FreeRunner! I thought it was pretty snappy in comparison with my FreeRunner. But then... I'm with 16bit software engine, a light theme... so maybe I've even a bit less peeved at the performance than you are... just what i was saying! :) Regardless, it's a lot better than in the FreeRunner! indeed. considering its got even more pixels to draw. and thats the 32bit engine there. not the 16bit one. thus you take a hit for the quality (which is far beyond qt's quality which is much like the 16bit engine where it does everything in 16bpp). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 16:23:54 -0400 Tony McKeehan mck...@rpi.edu said: Would this only work with SHR/QtMoko, etc, or would this also work on Android? I guess my question is, can this be solved from the kernel, or is it done through the distribution itself? you won't get smooth unless you run at vga all the time. you could fake resolution changes in the xserver by using the glamos' scale blit to pixel-double from a shadow fb to the real one. this may have performance impacts - beware. as not glamo has to spin actually updating everything on the screen by doubling its dimensions and copying it. but this is about the only way you'll get smooth. as for some apps can use vga is already possible - xrandr. uc an request a resoltuion change (and/or rotate) vis this x extension protocol. as long as the xserver offers the desired resolutions and implements them correctly. -Tonym Yogiz wrote: Anyway, I agree we should make QVGA work well, and I would use it for most apps. We should also keep in mind ways to allow use of the high res screen -- maybe picking certain apps (like browsers) that could switch to VGA automatically, and making sure the transition between resolutions is a smooth, fast, and automatic (where desired). Here's an idea I'm not sure I've heard before and I think it should be pointed out. When there was discussion whether to use VGA or move over to QVGA I was for the higher resolution, because viewing maps, terminal, pdfs and browsing at higher resolution was more important for me then speed. If however we could have everything at QVGA by default and change smoothly to VGA when required we could have all of the good and none of the bad. Sounds very good to me. ___ 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 21:43:47 +0100 Marcel tan...@googlemail.com said: Am Montag, den 26.10.2009, 20:33 + schrieb Rui Miguel Silva Seabra: On Mon, Oct 26, 2009 at 11:16:45PM +0300, Gennady Kupava wrote: http://www.rasterman.com/files/ello-elementary-smartq5.mp4 Thank you for videos, but on high-resolution one we can see exactly same slowness as on FreeRunner - exactly! See how top bar slides out on close of clock and button test - exacly as on my FreeRunner. Look how slow scroll is, again as on FreeRunner! I thought it was pretty snappy in comparison with my FreeRunner. But then... I'm with 16bit software engine, a light theme... so maybe I've even a bit less peeved at the performance than you are... Regardless, it's a lot better than in the FreeRunner! Indeed - the top bar struggles a bit when the button demo with clouds runs in the background which seems quite logical to me, the other times its so smth. indeed. u have 2 processes competing for cpu, competing for io and memory bandwidth, competing for access to the xserver (a 3rd process) which is also competing for cpu. e is very agressive at reducing its memory footrpint. evas and edje for example have caches to cache previously used data (fonts, images, caches scaled versions of images, edje groups and file content indexes etc.). it's a caching bonanza in there. the result its.. memory footprint will expand as the caches fill. e - every N seconds (see config dialogs for what it is set to there, but let's say 60 seconds) will flush caches. that means empty them out to make room for other apps if they need the memory. the linxu kernel hasno way to do caching like it does in the fs caches for userspace. ie please use all unused memory for caching and if any of it is needed, just throw that memory out. that doesn't exist outside of the kernels buffer/file cache, so you need to limit your caches yourself and reduce them whenever possible in case someone else may need the memory. when you see hiccups like that, it's probably because caches got flushed and things are having to be repopulated from disk, decoded and scaled etc. again. if you think e is so bad... look at android. everyone seems to think its the bees knees. go use 1 or 2 big apps for a while, then go 'home'. and wait 30sec or so for everything to appear. home app has unloaded most of its data or just some of it and you can wait many many many seconds for it to load it all back up and re-init the home screen etc. this is a faster device than the freerunner. it takes 16 seconds to come back to working during which it halts, pauses and otherwise isnt usable until its loaded everything. look at: http://www.youtube.com/watch?v=STE_bznazPU this is a similar effect you are seeing in e - but it's only nuking its caches not everything. it's a bit rich to complain about something other apps/gui's do too and yet not complain about them too. the downside of not doing it is.. bigger memory footprint, or smaller caches. (p.s. not directed at you marcel, more just to the thread in general). fyi... e brings bonuses you don't even know you have. here is a memory footprint comparison (no apps running) of mer's default gtk+matchbox+ etc. tools desktop to e17 - they are about functionally equivalent. e is missing wifi management, and mer is missing a bunch of config and things e has. mer: @ 5:27AM ~ free -m total used free sharedbuffers cached Mem: 110107 2 0 5 45 -/+ buffers/cache: 57 52 e17: @ 9:45AM ~ free -m total used free sharedbuffers cached Mem: 110 73 37 0 4 38 -/+ buffers/cache: 30 80 of we shut down x to see what the footprint is just before x starts: @ 4:32PM /usr/share/icons free -m total used free sharedbuffers cached Mem: 110 62 48 0 7 40 -/+ buffers/cache: 14 95 so do the math. that's 16m footprint with wallpaper, icons, gfx and more, vs 43m of memory footprint. e is agressive at saving on memory. you pay a small price for that - these blips when it has to re-fetch and populate caches. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
it? There's one neighbor unanswered thread with a render on the device - and this will then limit what you can render. evas can't be fully accelerated by the glamo. it has too many opretations. a bit like asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx chip ever was designed to do and you will hit software fallbacks. evas has multiple engnines. software (which is what is used - the 16bit renderer as opposed to the full 32bit one). it has xrender - if xrender were fully accelerated this should be better, but glamo cannot fully accelerate all the ops evas uses, so... it will rely on software fallbacks. thus slow down. my bet is you'll end up same speed as the pure software engine, or worse. aftera bunch of hard work you'll have gone nowhere. evas also has a gl and gles2 engine - but thats no use on glamo. it's gles1.1 and very limited (from memory texture size is 256x256 which is pretty useless for 2d as most data you deal with breaks these bounds). question on how to start the kernel with qvga resolution. Aside of no need to do that - just configure x for qgva. :) this, what can be reduced, for example amount of available colours (256 or even 16)? And if this [too] low throughput only of video memory channel? 256 won't help. it increases complexity and really reduces display quality through the floor. the best best is qvga 16bpp. its simple. it doesn't require any hard work. it is actually the most common resolution for most phones and devices out there so the software is more portable if you work on that (and then higher). but... in the past everyone has moaned and complained and refused to use it, and insisted on their vga resolution... and then complained about speed. if people don't believe me that the gta02 is just plain a bad bit of hardware and you have few choices here's some examples. here'es an ooold efl demo app i did: http://www.rasterman.com/files/eem.avi and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, qvga (240x320). it's from like 2001/2002 (from memory). its ancient. and watch it run evas: http://www.rasterman.com/files/eem-live.avi here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m ram, and 800x480 (higher res than gta02): http://www.rasterman.com/files/ello-elementary-smartq5.mp4 everywhere i look... theres much better hardware. if you look at performance vs age of hardware (when it was released) gta02 is almost at the bottom of the pile. :( you simply have a bad piece of hardware if you want graphics performance. as soon as you acknowledge that and either downgrade the device resolution for example to bring it in line with its performance, or just use different hardware, the better life will be :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 16:42:24 -0400 (EDT) Ken Young r...@cfa.harvard.edu said: Gennady Kupava g...@bsdmn.com wrote: [...] Yes, freerunner device is slow, but it is embedded device, and it's impossible to continue kicking glamo which is already dead, as only reason of slowness. People with GTA01 have no glamo and that? Is it better? As far as I know - not. Actually, yes the GTA01 is very noticeably faster in graphics. I've got both, and I've run 'em side-by-side. The glamo actually is a graphics DEcellerator. That's why GTA02-core is kicking it out. Ken Young nice work. and gta01 is at a wonderful 266mhz vs 400 on the gta02. if u think you could have gotten 500mhz out of gta02 without glamo (most likely). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: E17 default scaling factor
On Mon, 26 Oct 2009 17:18:38 +0100 Marcel tan...@googlemail.com said: Am Montag, den 26.10.2009, 16:19 +0100 schrieb Thomas Zimmermann: Am Montag 26 Oktober 2009 16:08:26 schrieb jeremy jozwik: On Mon, Oct 26, 2009 at 7:57 AM, Marcel tan...@googlemail.com wrote: Moin, I played around with E's scaling too much, can someone tell me the default dpi set in E's scaling settings? Setting 285dpi gives a far too small gui... might not help but i know its less then 177dpi [what i run] did you do this from the gui options or via a command? The slider in the E wrench is set to 140dpi The 4th column of icons fits from 141dpi on. Thanks! 142dpi is the Design default. tho i think that may actually be technically incorrect, but it works well on gta02 it's not setting dpi. .its setting the dpi the theme was DESIGNED for. it's reverse. imho it makes more sense. you cant SET the dpi of your screen. it's fixed. (well until screens become rubber stretchie things), but what does matter is the dpi something was designed to look right at. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 06:31:26 +0100 ri...@happyleptic.org said: -[ Tue, Oct 27, 2009 at 11:52:04AM +1100, Carsten Haitzler ] E is nice thing, but it look like highly unoptimized. i beg to differ. it's more optimised than pretty much anything out there. scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is very much like GL. you get a lot of power and abilities with it, but you do pay a price for it. unlike qt, efl's scrollers have smoothly scaled item contents, backgrounds, translucency and everything. So, probably unoptimized is not the right term. Maybe it's just _inapropriate_ to do these things on such a device, and that E, because it does so many things, is not such a good choice however optimized it may be ? Or maybe people really want it that way, unusable but good looking ? well as i said. it works fine and fluidly on many other devices. you are free to ditch efl and use gtk or qt if you want. it's your choice. of course if you are not developing apps... it's kind of not your choice :) but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. and these don't suck with EFL. i'd not compromise the future if i were smart. the point even before gta02 was out that.. it was not an end, but a start of something. you don't build your world around your first bit of hardware. if that was the case why are you not complaining that linux sucks on an 8086 on your desktop? because hardware moved on. most games i know of are written to work on the highest end graphics cards at the time. why? by the time the game is out and is selling - everyone has finally upgraded to those cards. they were top end 3 years ago when game design started. now they are low to middle end. gta02 is a a middle end device that came out 4-5 years after its components were middle end - except the LCD. you have a 4-5 year old set of components driving a high end screen. you will pay a cost. the developers are smart if they look forward to where hardware will be in N years and make sure they are on the right path for that. if it works now with some tuning and simplification of things like themes - then great. their code, apis and logic dont need a rewrite every few years. Personnaly I'm using H1 partly because it feels faster (not that this gnome desktop is particularly fast either, but at least the device do not enter sleep mode while an app is redrawing). well efl doesnt draw that slowly... so you're talking of something else :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Wikireader] Any news on Wikireader ?
On Thu, 22 Oct 2009 11:14:25 -0700 Doug Jones dj...@frombob.to said: This device is perfect for Free Software purists and for people who, for whatever reason, don't carry Internet access in their pockets. (As the global collapse deepens, I expect more and more people will be unable to justify the monthly cost of carrying around Internet access.) just fyi... the global collapse is likely past its bottom point. everything i see is either bumping aong the bottom or well on its way up. in australia/asia at any rate thats for sure. i don't think you're going to see any deepening in the west (australia excluded - it's hooking into the asian supply line so it's economy is more affected now the panic has gone, by supply and demand, and china's demand - india's too is on the up). no point panicing about deepenging problems. the usa though is in some deep poo poo and likely will see its currency devalue further. massive debt doesn't make the us economy look strong. especially as investors are over the panic now and need a safe haven for their money, it's a self-fulfilling prophecy that as the dollar goes down, moving money to a currency not tied to the dollar thats on the rise, makes sense, thus putting up the # of dollars being sold and unless someone picks up the slack and buys the extra multi-billions of dollars as fast as they are sold, means that the dollar will go down further due to investors trying to go to another currency for safety. but then again, as the dollar drops, things will drift back to on-shore as the usa simply becomes cheaper and thus helping create jobs in making use produced goods + services cheaper. it'll reach equilibrium at some point... but that won't be for a while. (sorry. just had to point this out as the above didnt seem incredibly accurate given current world economic circumstances) :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Wikireader] Any news on Wikireader ? [OT]
On Thu, 22 Oct 2009 16:39:40 -0700 Doug Jones dj...@frombob.to said: Carsten Haitzler (The Rasterman) wrote: On Thu, 22 Oct 2009 11:14:25 -0700 Doug Jones dj...@frombob.to said: This device is perfect for Free Software purists and for people who, for whatever reason, don't carry Internet access in their pockets. (As the global collapse deepens, I expect more and more people will be unable to justify the monthly cost of carrying around Internet access.) just fyi... the global collapse is likely past its bottom point. everything i see is either bumping aong the bottom or well on its way up. in australia/asia at any rate thats for sure. i don't think you're going to see any deepening in the west (australia excluded - it's hooking into the asian supply line so it's economy is more affected now the panic has gone, by supply and demand, and china's demand - india's too is on the up). no point panicing about deepenging problems. Who's panicking? hahahahah! well... more the words global collapse deepens might incite panic. :) it's not global anymore. australia is on its way out. stock market has been on the up for months. unemployment - it generally large as an indicator is now going down again and the reserve bank is raising interest rates. :) On the back of my WikiReader, I'm planning to write Don't Panic in big friendly letters the usa though is in some deep poo poo and likely will see its currency devalue further. massive debt doesn't make the us economy look strong. especially as investors are over the panic now and need a safe haven for their money, it's a self-fulfilling prophecy that as the dollar goes down, moving money to a currency not tied to the dollar thats on the rise, makes sense, thus putting up the # of dollars being sold and unless someone picks up the slack and buys the extra multi-billions of dollars as fast as they are sold, means that the dollar will go down further due to investors trying to go to another currency for safety. but then again, as the dollar drops, things will drift back to on-shore as the usa simply becomes cheaper and thus helping create jobs in making use produced goods + services cheaper. it'll reach equilibrium at some point... but that won't be for a while. (sorry. just had to point this out as the above didnt seem incredibly accurate given current world economic circumstances) :) Yes, let us know how that works out :-) which one? moving money to other currencies? already have long ago. i dont live in the usa. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] e and illume: how to configure launcher icons?
On Thu, 24 Sep 2009 17:28:26 +0100 Al Johnson openm...@mazikeen.demon.co.uk said: On Thursday 24 September 2009, arne anka wrote: I'm pretty sure Illume does not have support for categories or the ability to hide apps (especially not through a menu). Workarounds: If you delete the .desktop file from /usr/share/applications/, it won't be displayed. If your .desktop file doesn't contain Type=Application, I don't think it'll be displayed. i remember distinctly a dialog popping up first time with a listing of apps and a checkbox for every app, to enable it. can't get to that dialog again. additionally: i want to add my very own apps to the launcher -- and that as _normal_ user. since linux is a _multiuser_ operating system with separation of rights, it's unreasonable to expect _normal_ users to create/modify _global_ files (which the .desktop files in /usr/share/applications/ are). I think that selection dialog is for the enlightenment menu or something. It has no effect on what apps appear on the illume launcher as far as I can tell. The illume launcher is rather lacking in functionality as you have found. I'm sure Raster will gladly accept patches to improve the situation, but afaik nobody has written any. launcher was basic to get the job done, and it id. it hasn't been touched since though. :) i'm slowly gettign around to splitting illume up into policy (window layout) vs shelf (the top bar), vkbd and launcher and other bits. u'll see illume2 in svn as a module name, but its really more of a testbed for me cleaning up the code and doing it right. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-contacts/messages/dialer: window size and further issues
On Thu, 17 Sep 2009 09:49:26 +0400 Nikita V. Youshchenko yo...@debian.org said: WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 198 by 350 program specified maximum size: 198 by 350 ... the way the contents are specified for the window, it isnt resizable. the app is in control of this. All SHR apps have these values defined as above. That means that all SHR apps will get non-resizable 198x350 windows under any stardards-compliant window manager. This is definitly a bug that should be fixed. not all standards compliant wm's. e+illume will be fine. matchbox probably too. the standards allow the wm to happily ignore min/max window size hints if the wm wants to. :) WM hints is *the* standard way for app to request it's size constraints. So if app sets hints, while not wanting to get these size constraints, it is a bug in app. i have said that several times. but the standards do not REQUIRE that a wm MUST keep a window between its min and max sizes. it is an optional behavior. thus they may be resizable under standards compliant wm's. it's up to the wm. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-contacts/messages/dialer: window size and further issues
On Wed, 16 Sep 2009 11:28:18 +0200 arne anka openm...@ginguppin.de said: evas_object_resize(win-win, 480, 600); is what we do. yepp. and it does not resize correetly on at least LXDE and apparently IceWM -- in my LXDE it is far from 480x600, less than a quarter (approx 80x120). May this be dpi-related? Could you please try with different X server dpi settings? was one of the first ideas i got and tried already (with startx), but will try again with normal X startup (nodm). but i don't really believe it -- lxterminal frinst came up with a huge font compared to normal startup, while messages still was the same size. it's simply that by default the window will be its minimum size given its content unless sized to something else. illume with e will always maximize windows (and dialogs get maximized horizontally but minimum size vertically, centered over window). this is just the wm's policy. icewm, etc. etc. are not implementing any touchscreen small screen policy. they implement a desktop policy. you should expect this if you stick them on a smallscreen ts device with no changes to their management policy. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-contacts/messages/dialer: window size and further issues
On Wed, 16 Sep 2009 12:00:33 +0200 Michal Brzozowski ruso...@poczta.fm said: If the WM takes into account these values, you'll never be able to resize the window. From my experience they don't depend on dpi. r...@om-gta02 ~ $ wmctrl -l 0x0102 0 om-gta02 Notifier r...@om-gta02 ~ $ xprop -id 0x0102 ... WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 198 by 350 program specified maximum size: 198 by 350 ... the way the contents are specified for the window, it isnt resizable. the app is in control of this. 2009/9/16 arne anka openm...@ginguppin.de evas_object_resize(win-win, 480, 600); is what we do. yepp. and it does not resize correetly on at least LXDE and apparently IceWM -- in my LXDE it is far from 480x600, less than a quarter (approx 80x120). May this be dpi-related? Could you please try with different X server dpi settings? was one of the first ideas i got and tried already (with startx), but will try again with normal X startup (nodm). but i don't really believe it -- lxterminal frinst came up with a huge font compared to normal startup, while messages still was the same size. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-contacts/messages/dialer: window size and further issues
On Wed, 16 Sep 2009 14:00:47 +0200 Klaus 'mrmoku' Kurzmann m...@mnet-online.de said: Am Mittwoch 16 September 2009 13:37:28 schrieb Nikita V. Youshchenko: WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 198 by 350 program specified maximum size: 198 by 350 ... the way the contents are specified for the window, it isnt resizable. the app is in control of this. All SHR apps have these values defined as above. That means that all SHR apps will get non-resizable 198x350 windows under any stardards-compliant window manager. This is definitly a bug that should be fixed. and what is the proposed fix? Use XSetWMSizeHints? no. just pack things so some window resize object is resizable. actually so all of them are (weight 1.0 1.0). otherwise non-resizable resize objects for the window will constrain its size to min size of these elements. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-contacts/messages/dialer: window size and further issues
On Wed, 16 Sep 2009 15:37:28 +0400 Nikita V. Youshchenko yo...@debian.org said: WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 198 by 350 program specified maximum size: 198 by 350 ... the way the contents are specified for the window, it isnt resizable. the app is in control of this. All SHR apps have these values defined as above. That means that all SHR apps will get non-resizable 198x350 windows under any stardards-compliant window manager. This is definitly a bug that should be fixed. not all standards compliant wm's. e+illume will be fine. matchbox probably too. the standards allow the wm to happily ignore min/max window size hints if the wm wants to. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-contacts/messages/dialer: window size and further issues
On Wed, 16 Sep 2009 13:21:10 +0100 Rui Miguel Silva Seabra r...@1407.org said: On Wed, Sep 16, 2009 at 04:13:16PM +0400, Nikita V. Youshchenko wrote: Am Mittwoch 16 September 2009 13:37:28 schrieb Nikita V. Youshchenko: WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 198 by 350 program specified maximum size: 198 by 350 ... the way the contents are specified for the window, it isnt resizable. the app is in control of this. All SHR apps have these values defined as above. That means that all SHR apps will get non-resizable 198x350 windows under any stardards-compliant window manager. This is definitly a bug that should be fixed. and what is the proposed fix? Use XSetWMSizeHints? I've never written a line using E libraries, but quick search suggests evas_object_size_hint_min_set() / evas_object_size_hint_max_set() Like those are of much use when you can turn from portrait to landscape. NOT a solution! it's not an issue if your wm is like e+illume or matchbox and maximises apps regardless of min/max size.if its a desktop wm rotate is irrelevant here as the wm wont go resizing the window on rotate anyway, even if it is rotatable. (or is very unlikely to do this - move the window maybe, resize - unlikely). you need to differentiate between a wm setting up a sane windowing policy for such screen sizes and uses and a desktop wm and is policies. i agree the apps should not be relying on the wms ignoring their hints to work right - they should have their content packed in such a way that they are resizable. that is the correct solution. then a nice friendly resize of the window object to a nice size is good too (remember to get the min/max hints first and respect them in your resize as he resize is not going to respect them) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ETK] Problem running etk hello world.
On Tue, 15 Sep 2009 17:52:49 +0200 Adolph J. Vogel ajvo...@tuks.co.za said: I`m trying to run some of the examples from enlightenment trunk on my laptop with pyhton-etk installed, but it appears i`ve been a naughty programmer. :) *** ECORE ERROR: Ecore Magic Check Failed!!! *** IN FUNCTION: ecore_evas_window_get() Input handle pointer is NULL! *** NAUGHTY PROGRAMMER!!! *** SPANK SPANK SPANK!!! *** Now go fix your code. Tut tut tut! Certainly one of the most creative tracebacks i`ve ever seen, but meaningless to me. Does anybody have an idea to rectify this? the input part is null - that means likely it created the ecore_evas canvas +window but this failed and return asnt checked. something else checked it and was unhappy spanking he who wrote the code for not checking. so a create failed. could be because of missing engine, missing api support for than env or more. this can depend on your efl build and what it enabled when things compiled -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
