This is a continuation of the very lengthy thread of The N800 has a 3D accelerator, right?

Instead, this focuses on actually getting the drivers and libraries to play nice. As it really should be possible.

I think we should be focusing on Graphics_SDK/OMAP24xx_MBX_SDK_N8xx/MBX_Linux_KM/embedded/3rdparty/omap24xx_lcd , not the MBX part of it (which looks cross-device).

Now, where do we stand. The first clue is that the OMAPLCD can't get an IRQ. Now, what is this IRQ/interrupt used for? Vsync (omaplcd_linux.c, InstallVsyncISR())

What's Vsync? Some of you may know this from discussions about tearing, etc. In this case, the interrupt it is waiting for, is the signal that it has begun to update the display and we can start filling in the framebuffer with the next frame.

Now, this is what the driver does, except that well, the framebuffer it is filling into, is the one that is 'staging area' for the real LCD framebuffer. In N8x0, this is the old OMAP framebuffer. We have to send a signal to update the LCD framebuffer. This is also why the driver doesn't work for N8x0 as intended but shows results if we really force a framebuffer transfer.

In the old setup, a Vsync interrupt would be the indication to the driver to take a frame from the queue of rendered frames, remove it from the queue and point the framebuffer pointer at it, as I understand it. This is the Flip() stuff mentioned in the kernel.

In our N8x0 setup, we would not have a Vsync interrupt. We might be able to get one through Blizzard though.

We'd be replacing the Flip() command with our own - take a rendered frame from the queue, push it to LCD controller. See blizzard.c in kernel for reference.

However, if we don't have a vsync interrupt, we will have to find some way to push as soon as we get a frame. As far as I can see, omaplcd_ddc_process_vsyncflip is the entry point for the new frames, which gets added into the queue.

So, for starters, I would see if we can hack omaplcd_ddc_process_vsyncflip to do our bidding.

It looks like VSyncFlip takes render items, Flip()s them and then runs a 'command complete' signal.

Now, shouldn't it be in reach to make this driver do our bidding?

EDIT: Wouldn't it work 'for starters' to hack the omaplcd_ddc_process_vsyncflip to flip immediately, not put in queue and have a user process regularly sending the 'update window' ioctl?

Hello. When reading this I feel ashamed that I constantly cannot find any time to work on this and yet I think could do a lot. Too bad the whole Maemo thing didn't start few years earlier. I wish I could give same time to N8x0/N900 that I spent with 770. Now back to the 3d.

There is the http://wiki.maemo.org/MBX_drivers_status page, please update it with your findings if possible. With my last update I see it ends with "TODO - document GPL-ed kernel parts" which means Stskeeps had to figure it out again in the post above :-(

Yes omaplcd is the device dependent part of 3d drivers that needs to be changed.

As for the vsync in N8x0 situation. I think we don't want to hook into vsync interrrupt directly. Current omapfb driver already uses it quite sensibly. You either schedule omapfb update and it is started immediatelly (either for smaller screen parts or if you don't care) or you can set the tearsync flag when doing the update ioctl (fullscreen update in video playback) and the update is fired automatically next time vsync comes. So the omaplcd flip matches to scheduling omapfb update with tearsync flag. But for the start this can be ignored, just scheduling the update would be good start.

Next question is where the 3d frame buffers should be stored and how it relates to already preallocated three omapfb planes. This is related to the current allocation failure. As mentioned in older thread I think it should be doable to steal/render into already allocated planes instead of allocating yet another memory dynamically.

This relates to the
PVRSRV_ERROR GetBackBuffer(OMAPLCD_DEVINFO *psDevInfo, IMG_UINT32 ui32Num) procedure. There is code for static memory (flipbuffers array) and dynamic memory and default is dynamic one.

Current sizes of already allocated memory ( see also this)
omapfb: s1d13745 LCD controller rev 1 initialized (CNF pins 3)
omapfb: region0 phys 80600000 virt ffa01000 size=770048 type=0
omapfb: region1 phys 80700000 virt ffabd000 size=786432 type=0
omapfb: region2 phys 87c00000 virt ffb7d000 size=1572864 type=0
omapfb: Framebuffer initialized. Total vram 3129344 planes 3

I think the last plane is good enough for two 800x480x16bits flipbuffers. Basically I think we should abuse the current way how Xvideo and video output is done but instead of video we should point 3d chip to same memory overwriting the video. This would also allow scaling in the same way it currently works with video etc. Sounds crazy? Maybe it is.

I'l try to get back to documenting what I know about the 3d kernel part in the wiki.

Additionally for anyone working on this it could helpful to be familiar with omapfb driver and how it works with external display controllers. The 770 version is a bit easier to understand. N8x0 version is similar, it just switches sossi for rfbi for transfering the data, hw472.c is replaced with blizzard.c and the biggest difference is adding 3 planes due to OMAP2 chip having native support for 3 planes (named GFX, VID0,VID1?) . It was not clear to me at the time N800 came since there is no OMAP2 documentation but when OMAP3 came recently, it looks to me that the video subsystem of OMAP2 is exactly the same as OMAP3 (planes, tv-out, dispc, rfbi ..) so I finally understand a bit better why there are three planes allocated when in the end all three are merged anyway when transferring display data to the epson chip.

Also maybe it should be useful to study how omaplcd.ko part of SGX driver for OMAP3 works since it could be quite similar.

There is two parameters to the omaplcd module:

module_param(fbsize, long, 0);
MODULE_PARM_DESC(fbsize, "Sets the size of the buffers in a flip chain (default=153600)");
module_param_array(flipbuffers, long, 0, 0);
MODULE_PARM_DESC(flipbuffers, "Sets the address of the buffers in a flip chain (default=0 -> allocated)");

And a piece of code further down, looks a little broken:

#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0))
for(i=0; i < OMAPLCD_MAX_BACKBUFFERS + 1; i++)
{
if(flipbuffers[i])
num_buffers++;
}
#endif

- num_buffers should probably be set to 2 in this case. We can probably hardwire the locations and num_buffers to the video framebuffer

Oh! fanoush just showed up. If he sticks around, this could really start moving forward! If Stskeeps and fanoush start working together on this, we'll have to come up with a superhero team name for them.

Framebuffer flippers? 3D Heroes?

...Avatars?

/me ducks and runs

Crysis please.

P.S. I don't understand any word you wrote, but it seems to be something nice

I hate how the driver works. So omaplcd passes mbxaccess a .so filename which passes it to its clients which dlopen it which use it to access the /dev/omaplcd device node which gets back to omaplcd again which eventually sets omap dss registers on its own or calls mbxaccess.

This is clearly designed so that the author of display class device drivers can choose whether to implement most of the logic in user space or kernel space -- If we could follow this we could create a libomaplcd.so replacement which calls into blizzard/xv/omaplcd/whatever user space library you can think of.

But of course, we can't.

Ah, I almost forgot that other superhero of the 3D drivers, javispedro!

Framebuffer Flippers GO!

My hacking project for tonight, since Finland is on holiday tomorrow - seeing if I can build the driver for our 2.6.33 kernel. Worth knowing how screwed we are on that front.

OK, I've set up a gitorious project at http://gitorious.org/mbx-n8x0/mbx-n8...s/trees/master and a team for it (poke me to get added)

I've cleaned up the build system and am now using normal Linux kernel build system.

That means:

make CROSS_COMPILE=/path/to/cross-compiler KERNELDIR=/where/my/kernel-sources/are ARCH=arm

to compile it. Not the insane TI build system.

Oh, and it dual builds on 2.6.33 and 2.6.21. Could someone replicate the steps please for 2.6.21 and try to use the .ko's resulting?