View Single Post
Stskeeps's Avatar
Posts: 1,663 | Thanked: 11,365 times | Joined on Jun 2008 @ Warsaw, Poland
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?
As you go on to other communities, remember to build them around politeness, respect, trust and humility. Be wary of poisonous people and deal with them before they end up killing your community.. Seen it happen to too many IRC channels, forums, open source projects.

Last edited by Stskeeps; 2010-05-11 at 20:53.

The Following 41 Users Say Thank You to Stskeeps For This Useful Post: