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: 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: 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 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 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
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: 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
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: 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: 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: [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: 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: [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: 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: 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)
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: 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: 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: 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: 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 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: [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: [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: 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: 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