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 :) _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
