View Single Post
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#514
Originally Posted by javispedro View Post
I personally just create a libXau.so.0 symlink pointing to libXau.so.6.
Thanks, missed the '.0' part.

Originally Posted by javispedro View Post
Basically, things to be worked on:
- Most visible: it's rendering to the Xomap buffer, but not sending changes to omapfb.
Right, that needs work. Maybe when buffers are flipped omapfb update can be called. If I understand it correcly omaplcd.ko implements device independent framebuffer for the rest of powervr code and now implements two 800x480 'flipbuffers'. So in theory omaplcd.ko is the only device specific part we need to change, correct?

Originally Posted by javispedro View Post
- Also very visible: periodic freezes.
- The driver leaks like if there was no tomorrow. Just restart a GLES app a few times until everything crashes/hangs. I can load a single 800x480 texture; next one causes everything to freeze.
Is it known what part leaks, kernel side or userspace (mbxdaemon or whatever)?
Originally Posted by javispedro View Post
- After the screen turns off everything goes crazy or black.
well when screen is off, the hardware (lcd panel, epson controller, omap display controller) is off and maybe powervr driver (omaplcd.ko part) is not aware of that and blindly writes some dispc registers? Hmm, I need to check whole omapfb/rfbi/blizzard code again, I guess powervr's omaplcd.ko assumes too much and expects omap display controller to actually drive the display and messes with lot of its registers, this seems wrong to me but how comes it even works as is?
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.

Last edited by fanoush; 2010-02-23 at 00:41.
 

The Following 3 Users Say Thank You to fanoush For This Useful Post: