[maemo-developers] Xsp pixel-doubling solutions for Nokia 770?

From: Daniel Stone daniel.stone at nokia.com
Date: Mon May 7 15:39:27 EEST 2007
On Sun, May 06, 2007 at 04:57:58PM +0300, ext Siarhei Siamashka wrote:
> On Thursday 03 May 2007 12:58, Eero Tamminen wrote:
> > Yes, it just cannot be done safely / reliably.  
> I can't be completely sure, but I think it is possible to do safely/reliably.
> At least it is worth trying in my opinion. The difference in our views is
> that you see xserver as the only valid Nokia 770 citizen and everything
> else looks like a very ugly hack to you. 
> I see the problem from the completely different perspective. For many 
> games xserver is irrelevant, they use SDL API and that is what they care
> about (xserver is just an additional extra layer). Game developers would like
> to have a fast and reliable SDL implementation which could make efficient use
> of all the hardware features that can benefit games. If xserver can provide
> all of this with some standard or nonstandard extensions, that's fine. We only
> need to estimate the amount of development resources and time needed to 
> do these modifications to xserver and SDL to make use of these features. As
> games are not a primary target for Internet Tablets, I doubt that anything
> like this will be officially done any time soon (at least before the Nokia 770
> end of life). Am I wrong?
> In this case tweaking SDL to use framebuffer directly may have a much
> lower cost. Especially considering that you have already solved this
> framebuffer sharing problem for DSP video playback. I did not suggest
> anything completely new ;)

This is sort of my blanket reply to all the mails on the issue.

There are two main issues here, of which the first is design.  It's
simple: we picked one window system, which happened to be X.  We
could've written our window system that simply performed arbitration for
fb access, but we didn't, and for a pretty good reason.  We chose X as a
good abstract windowing system that solved all our problems.  The
framebuffer was an implementation detail, primarily based on the
expertise available to us.

The second, and most important, is portability.  Not only are you tying
your app to the internet tablets, but you're tying them to the _current
generation_.  We don't guarantee any APIs below X.  If you want to hit
the framebuffer, that's your choice, but I'm not going to guarantee that
X won't be fiddling the framebuffer underneath you.  It's not designed to
play nice with other apps sharing the same framebuffer, and it won't be.

Future releases of X may stomp the framebuffer more often.  They may use
acceleration, which you'll miss out on.  They may not use the
framebuffer at all, which will leave you high and dry.

You're turning a portable app (hell, the point of SDL is portability, so
you can run it anywhere), into one that's dependent on the mixture of X,
an OMAP display controller supported by omapfb, and an external LCD
controller also supported by omapfb.  Not only is this setup quite
unique to the internet tablets (due to the high resolution), but it's
specific to this line of internet tablets.

There are any number of changes we can make in future products (such as
removing the LCD controller, moving to a purely X driver, using a
different display setup, whatever) that will torpedo your app.

I appreciate your zeal for faster-running games.  There are certainly
ways you can make it faster, but everything has an associated cost.  You
can bypass X and go straight to the framebuffer, but it might not work
correctly, and that will be your problem.  It's not guaranteed to be
portable to future internet tablets, let alone other platforms.  It
won't even necessarily interoperate with things like dialog boxes and
info popups.

In short, you can do what you like, but you get to keep both pieces.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.maemo.org/pipermail/maemo-developers/attachments/20070507/14a2bc9c/attachment.pgp 
More information about the maemo-developers mailing list