Solved! Go to Solution.
I'm not enough of a kernel expert to say either. We were reduced to empiracal results and, since going to DirectFB, we've had 0 pixel corruption or seg fault behavior that couldn't be attributed to our application and fixed. We (5 of us) literally spent weeks looking at this. The group included a PhD that has extensive kernel experence and four VERY experienced Linux developers (driver and application level) and could never identify the issue.
I totally agree that the problem appears to be a memory protection issue (mmap). However having now had a stable application with a complex GUI (50+ GUI pages with fast changing data and animations) running for over a year on this kernel, with the only change being Microwindows Vs DirectFB, I feel pretty comfortable with this kernel (after our fix anyway!!).
I would be VERY interested if you find a kernel issue. Please post if you do.
Hi jkimble.It's good to hear that DirectFB is working very well with large no of applications.Is the PCI DMA working properly? I mean function like BitBlt is extensively using DMA for pixel writting?Also did you try USB mouse rapid movement along the DirectFB?
Now I am not working on that board.As far as I remember when I was working that BSP I found kernel memory allocations were not DMA allocation.I am not sure whether this is the reson of the problem when data transfer huge,and DMA needs to be used.
Segmentetion Fault was due to the memory protection bug in MMAP as I mentioned in my previous post. (BTW my profile name is changed from nabendu to nbm ).
I will forward your comments on to the Microwindows maintainer.
I see the DirectFB license is LGPL. This may be an issue given LGPL requires you provide to the end user all the Linux code you use plus your application object files so it can be relinked.