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 ;)
Hi, 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. Cheers, Daniel
signature.asc
Description: Digital signature
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
