Qtopia coming for Neo1973

[Dani Anon]

On 9/25/07, Steven Le Roux <steven at le-roux.info> wrote:
>
>
> On Tue, 25 Sep 2007 10:32:46 +0200, "Dani Anon" <mrtitor at gmail.com> wrote:
> > On 9/25/07, Lorn Potter <lpotter at trolltech.com> wrote:
> >>
> >>
> >> Carlo E. Prelz wrote:
> >> >       Subject: Re: Qtopia coming for Neo1973
> >> >       Date: mar 25 set 07 08:18:31 +0200
> >> >
> >> > Quoting Dani Anon (mrtitor at gmail.com):
> >> >
> >> >> - 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
> steven at le-roux.info
> xmpp:steven at jabber.fr
>
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>