On 9/25/07, Steven Le Roux <[EMAIL PROTECTED]> wrote: > > > On Tue, 25 Sep 2007 10:32:46 +0200, "Dani Anon" <[EMAIL PROTECTED]> wrote: > > On 9/25/07, Lorn Potter <[EMAIL PROTECTED]> wrote: > >> > >> > >> Carlo E. Prelz wrote: > >> > Subject: Re: Qtopia coming for Neo1973 > >> > Date: mar 25 set 07 08:18:31 +0200 > >> > > >> > Quoting Dani Anon ([EMAIL PROTECTED]): > >> > > >> >> - But QT is not free (as in beer) for commercial usage > >> > > >> > This is not the only reason why Qtopia is sub-optimal. > >> > >> It's not a reason at all. Neo is a "free" phone! If I wanted commercial > >> applications, I could easily use any other phone out there. The reason > >> why we are all here, is because the Neo is 'free software'. Would the > >> Neo interest you as much if it wasn't as 'free'? > > > > Tell that to all the people using Wine under Linux. > > I Don't think there are so much... I fully agree with him to say > Neo/OpenMoko goal is to become a *FREE* user friendly phone. Even if Qtopia > could give bigger range, or bigger "celebrity", it will not change the > OpenMoko/OpenEmbedded mission, to provide a free framework/os
People keep saying that but really, are you sure that openmoko goals exclude proprietary software? http://wiki.openmoko.org/wiki/Commercial_models Linux is a perfectly free operative system but support for proprietary software isn't discouraged. Think of Oracle, Opera, vmware to name a few. In fact, one could argue that an open platform that makes proprietary development expensive is less free than a closed platform that makes proprietary development (as well as free development) free, so I think you are very wrong about this. FIC is a company after all and I'm pretty sure that to them, the non-free nature of qtopia for proprietary usage would be a concern but that is good. In fact I would prefer qtopia as a developer but I'm willing to use openmoko, I really want. > > > >> They haven't progressed that much in the last 6 years. Slower cpu uses > >> less power. > > > > strongly agree with all these points. With mobile devices, direct > > access to the hardware is everything because it might mean an extra > > hour of battery. the main problem right now is I'm not sure about the > > future of openmoko if they keep using X. When I learnt openmoko was > > using an X server it surprised me a lot, its a very weird decision. > > Most of Linux powered extramobile devices that I know of (please > > correct me if I'm wrong) have some kind of framebuffer environment in > > which you can directly draw stuff on screen with little overhead. > > > > Dani > > Ok, I am not a developper, but, I think the accelorometer has the goal to > provide a good video rendering. > If you see forward, the hardware will be improved, and I think there will be > some "eyeglasses" effect or any "eye candy" things that won't not be possible > with frame buffer... > I think you are confused about the framebuffer thing. A frame buffer is always used, it's used by X too. (You are taking about the *Linux* Framebuffer, a particular feature of linux). And yes, X adds an overhead, that's why there are projects like FBUI or directFB. These people aren't lunatic or morons, they started such efforts specifically to remove the X overhead and have something as responsive as Microsoft and Apple have. This is very well known, so stop pretending that it's not an issue. It's either one of the following: 1) Application asks to draw a line and waits. X sees that request and uses a driver to draw the line, then sends confirmation. Now the application waits and when the confirmation is received it's ready for the next operation. 2) Application uses a driver to print the line. Note that in the second option we are already ready for the next operation.,, Which one would you choose for performance? Apparently most of the phones are using the second. The mind boggles... > -- > Steven Le Roux > [EMAIL PROTECTED] > xmpp:[EMAIL PROTECTED] > > > _______________________________________________ > OpenMoko community mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/community > _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
