It is temporary workaround until memory is allocated early in boot sequence. I wonder whether it needs the memory at all. omapfb already has three 800x480 framebuffer planes allocated maybe they can be reused for MBX framebuffer as is. Anyway, if we really need two more 800x480 framebuffers/flipbuffers it can be allocated in omapfb driver directly at kernel boot time(wasting another 1.5MB). Or does the mbx driver need more later? (for textures etc)

I know. Just being a bit sarcastic and frustrated that, no matter what I do, I just cant get it to work.

There is in fact way too magic here :P, as you'll see if you get any sample to run.

I personally just create a libXau.so.0 symlink pointing to libXau.so.6.


Basically, things to be worked on:
- Most visible: it's rendering to the Xomap buffer, but not sending changes to omapfb. (that's why I also ask showing/hiding the applications menu since it refreshes a large part of the screen). Manually refreshing entire screen after every frame works (and doesn't crash, even when running for long periods), but it's far from an ideal solution.
- 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.
- After the screen turns off everything goes crazy or black.
- Performance ( :P ).

Thanks, missed the '.0' part.

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?

Is it known what part leaks, kernel side or userspace (mbxdaemon or whatever)?
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?

Here is initial version of wiki page documenting current status http://wiki.maemo.org/MBX_drivers_status Feel free to expand it.

started
Heh, last time I created garage project it was epic failure. But we need some coordination and this thread is already long and messy.

Personally I know next to nothing about 3D/opengles. I also expect to be the slowest person of you all. I also expect there are a lot of bright people already involved. I have moderate and rusty knowledge of omapfb/rfbi/dispc/blizzard drivers but maybe you already know more than me so there is no point in explaining that? With a mailing list or some other non-volatile place (no irc) I could check what are the issues and see if I can help. Trying stuff others already tried is not ideal. Just trying to save my time as much as possible, shame on me :-P

Well, the GLES expert here is javispedro, I know next to none about omapfb or kernel issues, just did a couple of good guesses

A mailing list would be in order under a garage project I think

I use rootfs on SD.
Ok. I flash provided kernel, boot from internal flash, umount all SD, load provided modules, create device and start mbxdaemon.
glinfo
dmesg
[ 867.476562] No flipbuffers
[ 867.476562] mbxdaemon: page allocation failure. order:8, mode:0xd0
[ 867.476562] [<c002c178>] (dump_stack+0x0/0x14) from [<c0082084>] (__alloc_pages+0x2c0/0x2d4)
[ 867.476562] [<c0081dc4>] (__alloc_pages+0x0/0x2d4) from [<c002dd40>] (__dma_alloc+0x184/0x3e4)
[ 867.476562] [<c002dbbc>] (__dma_alloc+0x0/0x3e4) from [<c002dfc4>] (dma_alloc_coherent+0x24/0x30)
[ 867.476562] [<c002dfa0>] (dma_alloc_coherent+0x0/0x30) from [<bf069c2c>] (AllocContiguousMemory+0x30/0x6c [omaplcd])
[ 867.476562] [<bf069bfc>] (AllocContiguousMemory+0x0/0x6c [omaplcd]) from [<bf069d3c>] (GetBackBuffer+0xa8/0xc0 [omaplcd])
[ 867.476562] r6 = 00000001 r5 = 00000000 r4 = 00000000
[ 867.476562] [<bf069c94>] (GetBackBuffer+0x0/0xc0 [omaplcd]) from [<bf06943c>] (InitMain+0x19c/0x250 [omaplcd])
[ 867.476562] r6 = C88FD00C r5 = C88FD000 r4 = 00000000
[ 867.476562] [<bf0692a0>] (InitMain+0x0/0x250 [omaplcd]) from [<bf06a580>] (OMAPLCDBridgeDispatch+0x408/0x460 [omaplcd])
[ 867.476562] [<bf06a178>] (OMAPLCDBridgeDispatch+0x0/0x460 [omaplcd]) from [<c00a9c6c>] (do_ioctl+0x74/0x84)
[ 867.476562] r6 = BEE581AC r5 = FFFFFFE7 r4 = C1B10A80
[ 867.476562] [<c00a9bf8>] (do_ioctl+0x0/0x84) from [<c00a9f14>] (vfs_ioctl+0x298/0x2b8)
[ 867.476562] r6 = 00000000 r5 = BEE581AC r4 = C1B10A80
[ 867.476562] [<c00a9c7c>] (vfs_ioctl+0x0/0x2b8) from [<c00a9fa0>] (sys_ioctl+0x6c/0x94)
[ 867.476562] r7 = 00000008 r6 = BEE581AC r5 = 00000000 r4 = C1B10A80
[ 867.476562] [<c00a9f34>] (sys_ioctl+0x0/0x94) from [<c0027be0>] (ret_fast_syscall+0x0/0x2c)
[ 867.476562] r8 = C0027D88 r7 = 00000036 r6 = 00009190 r5 = 0000B478
[ 867.476562] r4 = 41022DB8
[ 867.476562] Mem-info:
[ 867.476562] DMA per-cpu:
[ 867.476562] CPU 0: Hot: hi: 42, btch: 7 usd: 5 Cold: hi: 14, btch: 3 usd: 11
[ 867.476562] Active:13679 inactive:10272 dirty:0 writeback:0 unstable:0
[ 867.476562] free:2226 slab:2415 mapped:5925 pagetables:572 bounce:0
[ 867.476562] DMA free:8904kB min:1440kB low:1800kB high:2160kB active:54716kB inactive:41088kB present:130048kB pages_scanned:0 all_unreclaimable? no
[ 867.476562] lowmem_reserve[]: 0 0
[ 867.476562] DMA: 86*4kB 102*8kB 82*16kB 65*32kB 42*64kB 3*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 8904kB
[ 867.476562] Swap cache: add 0, delete 0, find 0/0, race 0+0
[ 867.476562] Free swap = 0kB
[ 867.476562] Total swap = 0kB
[ 867.476562] Free swap: 0kB
[ 867.500000] 32768 pages of RAM
[ 867.500000] 2578 free pages
[ 867.500000] 2730 reserved pages
[ 867.500000] 2415 slab pages
[ 867.500000] 27476 pages shared
[ 867.500000] 0 pages swap cached
[ 867.500000] AllocContiguousMemory: unable to allocate contiguous memory of bb800
[ 867.500000] request OMAPLCD IRQ failedrequest OMAPLCD IRQ failed<6>PVR_KERNLError): Failed to find offset struct (KVAddress=c8abd000)
[ 868.773437] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 868.773437] PVR_KERNLError): Failed to find offset struct (KVAddress=c891c000)
[ 868.773437] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 868.781250] PVR_KERNLError): Failed to find offset struct (KVAddress=c8916000)
[ 868.781250] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 868.781250] PVR_KERNLError): Failed to find offset struct (KVAddress=c8914000)
[ 868.781250] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 1793.078125] request OMAPLCD IRQ failedrequest OMAPLCD IRQ failed<6>PVR_KERNLError): Failed to find offset struct (KVAddress=c8abd000)
[ 1794.390625] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 1794.390625] PVR_KERNLError): Failed to find offset struct (KVAddress=c891c000)
[ 1794.390625] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 1794.390625] PVR_KERNLError): Failed to find offset struct (KVAddress=c8916000)
[ 1794.390625] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]
[ 1794.390625] PVR_KERNLError): Failed to find offset struct (KVAddress=c8914000)
[ 1794.390625] [567, /home/carsten/powervr/embedded/services/env/linux/mmap.c]

A question for fanoush, stskeeps, and javispedro,. If there is no source code for the TI 3D driver, how are we to hack it any further? Does this mean that the current omapfb driver will change, and in what way? Excuse my ignorance.

The parts that are most problematic is in the kernel and open source. Rest, we have a line to TI to ask about things.