I agree that longer term, this is a good candidate for hardware
abstraction. For the nearer term, I do have a patch to
EGLDisplaySurface.cpp that prefers PAN and if PAN is unavailable drops
back to PUT_VSCREENINFO. This patch also provides a fallback to
memcpyh if necessary. The patch is needed on some x86 platforms. We
are working thru the final steps of our internal legal reviews to let
us contribute to Android Open source (see
http://groups.google.com/group/android-porting/msg/bb9e38d8caa62441)
and hope I hope we can start submitting soon.
Thanks,
Chris
On Nov 17, 1:27 am, Mathias Agopian <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 17, 2008 at 12:11 AM, Sean McNeil <[EMAIL PROTECTED]> wrote:
>
> > Benno wrote:
> >> On Nov 4, 1:01 pm, Mathias Agopian <[EMAIL PROTECTED]> wrote:
>
> >>> Hi Ben,
>
> >>> On Nov 1, 8:11 pm, "Ben Leslie" <[EMAIL PROTECTED]> wrote:
>
> >>>> The current documentation implies that everything should work on
> >>>> devices where double buffering (panning) isn't supported by the
> >>>> underlying driver.
>
> >>>> However, swapBuffers() doesn't actually seem to support PAGE_FLIP:
>
> >>>> uint32_t EGLDisplaySurface::swapBuffers()
> >>>> {
> >>>> if (!(mFlags & PAGE_FLIP)) {
> >>>> return 0;
> >>>> }
> >>>> ....
>
> >>>> }
>
> >>>> If I add a memcpy() in there things seem to work correctly (at least
> >>>> on the neo 1973).
>
> >>>> Do I need to add this, or should non page flip work some other way?
>
> >>>> Cheers,
>
> >>>> Benno
>
> >>> You are perfectly right. The code is incomplete and doesn't work
> >>> without page-flipping.
> >>> It is intended to work by performing a memcpy() as you have suggested.
>
> >>> We have actually fixed the non-page flipping case; but the code has
> >>> not been submitted yet.
>
> >> Thanks Mathias! Good to see I'm not completely off track!
>
> > This is irrelevant on Freerunner now as I've implemented page flipping
> > in the kernel. I still have to change to use FBIOPAN_DISPLAY, though, as
> > the other ioctl does a complete refresh of settings and causes flashing.
>
> Sounds good.
> Eventually, we'll need to abstract this out because there is no way to
> know which ioctl to use. And in fact, one could imagine a board
> without a /dev/graphics/fb driver at all. It sounds more and more like
> a good candidate for the upcoming hardware abstraction layer.
>
> mathias- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
