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

[From: Siarhei Siamashka]

On Thursday 03 May 2007 12:58, Eero Tamminen wrote:

> ext Siarhei Siamashka wrote:
> > What problem with using framebuffer directly? Everything should be
> > fine, you can get notifications from xserver when your window becomes
> > obscured, so you can stop drawing. I suggest you to try MPlayer on
> > Nokia 770 to check how it interacts with xserver. The worst thing that
> > can happen is some garbage data left on screen on fast applications
> > switching. That can happen because there is no support to synchronize
> > access to framebuffer in a reliable way (application using framebuffer
> > directly may get notification from the xserver about getting inactive
> > too late and overwrite some other application window).
> >
> > Adding support to xserver for proper synchronization with direct
> > framebuffer access applications should be quite possible. It already
> > synchronizes access to framebuffer with DSP (Xsp API for registering
> > DSP area). Almost all the necessary changes will probably have to be
> > added at the same places in xserver which support interaction with
> > DSP.
>
> AFAIK Xserver requests & waits DSP to stop updating the framebuffer
> before proceeding.  This works with HW, but you cannot expect it to
> work reliably with misc X clients as there are no guarantees about
> what they do. If client is not processing X events, the response would
> be waited forever and device freezes.  If X server has some timeout for
> the client reply, then the server and client can be updating the
> framebuffer at the same time and that was what we wanted to avoid
> in the first place.

Timeout is a perfectly valid solution in my opinion. It just requires that
xserver and some thin wrapper library used by misc clients (SDL) both 
interact correctly. Interface of this wrapper library should be designed
in such a way, that it is safe and hard to be misused (special timeout 
code which automatically terminates the process which refuses to give
framebuffer back to xserver).

I may provide some extra details about my vision of implementation 
details if anybody is interested.

> > I guess it can't be helped and I will make an example application for
> > using framebuffer directly and some kind of tutorial. Don't know when
> > I will have enough free time to do this though.
> >
> > I'm pretty much confident that direct framebuffer access (also with
> > pixel doubling support) is quite possible for SDL. I don't care much
> > if you believe me or not :) Someone just needs to do the dirty work
> > and implement all this stuff.
>
> 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 ;)

It is not quite related, but games also need a reliable and low latency method
to play sounds. Current esd daemon solution is not very good for games. Maybe
modifying SDL to deal with dsp tasks directly can provide some improvement.
Also it would be very nice if SDL_Mixer could use dsp codecs transparently
without any extra hacks to play mp3 music.

> But for hackers it's enough that it works when it works I guess. :-)

I'm not sure if I can consider myself a hacker :) Something that just works
is perfectly enough for a prototype. But a production system needs a reliable
solution, hence I'm trying to start discussing the implementation details.

SDL optimization for Nokia 770 might be an interesting task for some student
with lots of free time.

In any case, trying alternative solutions is a good thing, it drives the
progress, allows us to improve our skills and gain experience. We get 
the best solution (whatever it would be) and everyone benefits as a 
result :)