Froyo 32bpp fixes

132 views
Skip to first unread message

mtx512

unread,
Aug 2, 2010, 3:48:41 AM8/2/10
to Android-x86
Hi,

Has anyone worked out the 32bpp fixes for Froyo. The patches for that
I had for Eclair (EGLDisplaySurface.cpp) won't work in Froyo.

many thanks!

mtx512

unread,
Aug 8, 2010, 10:41:43 AM8/8/10
to Android-x86
The initial patches to get the screen displayed correctly are below. I
think a similar patch may need to be applied to some of the
applications to get them to display correctly.

project hardware/libhardware/
diff --git a/modules/gralloc/framebuffer.cpp b/modules/gralloc/
framebuffer.cpp
index 0195103..213af32 100644
--- a/modules/gralloc/framebuffer.cpp
+++ b/modules/gralloc/framebuffer.cpp
@@ -174,7 +174,7 @@ int mapFrameBufferLocked(struct private_module_t*
module)
/*
* Explicitly request 5/6/5
*/
- info.bits_per_pixel = 16;
+/* info.bits_per_pixel = 16;
info.red.offset = 11;
info.red.length = 5;
info.green.offset = 5;
@@ -183,6 +183,16 @@ int mapFrameBufferLocked(struct private_module_t*
module)
info.blue.length = 5;
info.transp.offset = 0;
info.transp.length = 0;
+*/
+ info.bits_per_pixel = 32;
+ info.red.offset = 24;
+ info.red.length = 8;
+ info.green.offset = 16;
+ info.green.length = 8;
+ info.blue.offset = 8;
+ info.blue.length = 8;
+ info.transp.offset = 0;
+ info.transp.length = 0;

/*
* Request NUM_BUFFERS screens (at lest 2 for page flipping)
@@ -347,7 +357,8 @@ int fb_device_open(hw_module_t const* module,
const char* name,
const_cast<uint32_t&>(dev->device.width) = m->info.xres;
const_cast<uint32_t&>(dev->device.height) = m->info.yres;
const_cast<int&>(dev->device.stride) = stride;
- const_cast<int&>(dev->device.format) =
HAL_PIXEL_FORMAT_RGB_565;
+// const_cast<int&>(dev->device.format) =
HAL_PIXEL_FORMAT_RGB_565;
+ const_cast<int&>(dev->device.format) =
HAL_PIXEL_FORMAT_RGBA_8888;
const_cast<float&>(dev->device.xdpi) = m->xdpi;
const_cast<float&>(dev->device.ydpi) = m->ydpi;
const_cast<float&>(dev->device.fps) = m->fps;

Yi Sun

unread,
Aug 8, 2010, 2:17:22 PM8/8/10
to andro...@googlegroups.com, Android-x86
How about the performance?
Yi

> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-x86...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-x86?hl=en.
>

mtx512

unread,
Aug 8, 2010, 3:54:00 PM8/8/10
to Android-x86
We're still depend on finding a OpenGL ES driver for adequate
performance.

On Aug 8, 7:17 pm, Yi Sun <beyo...@gmail.com> wrote:
> How about the performance?
> Yi
>

Yi Sun

unread,
Aug 9, 2010, 12:35:14 AM8/9/10
to andro...@googlegroups.com
I assume that you have test this patch somehow, do you mind that I put
this patch on to the android-x86.org downloading page? And we could
merge it into the foyo tree later.
Yi

--
Android-x86
http://www.android-x86.org

mtx512

unread,
Aug 9, 2010, 8:40:13 AM8/9/10
to Android-x86
Yes you can put the patch on android-x86.org.

I'm testing for x86 by building the source from the main repo
(android.git.kernel.org), unfortunately the trunk for froyo has now
been restricted to build a 64 bit OS only. Therefore I'm currently
using the tag android-2.2_r1.1. I'm currently trying to fix
touchscreen for my board as well explore an OpenGL ES solution for
GMA500.
> Android-x86http://www.android-x86.org- Hide quoted text -
>
> - Show quoted text -

Yi Sun

unread,
Aug 9, 2010, 2:51:15 PM8/9/10
to andro...@googlegroups.com
On Mon, Aug 9, 2010 at 5:40 AM, mtx512 <mtx5...@gmail.com> wrote:
> Yes you can put the patch on android-x86.org.
>
> I'm testing for x86 by building the source from the main repo
> (android.git.kernel.org), unfortunately the trunk for froyo has now
> been restricted to build a 64 bit OS only. Therefore I'm currently
> using the tag android-2.2_r1.1. I'm currently trying to fix
> touchscreen for my board as well explore an OpenGL ES solution for
> GMA500.
>
Just a double confirm, you did tested your patch with android-2.2_r1.1
and it works, right?

--
Android-x86
http://www.android-x86.org

mtx512

unread,
Aug 9, 2010, 4:03:04 PM8/9/10
to Android-x86
Yes have tested, my screen now displays correctly.

On Aug 9, 7:51 pm, Yi Sun <beyo...@gmail.com> wrote:

Yi Sun

unread,
Aug 9, 2010, 11:58:55 PM8/9/10
to andro...@googlegroups.com
Done
https://sites.google.com/a/android-x86.org/web/download/32bpp.patch?attredirects=0&d=1

I guess we will push it to repo as soon as we have a solution on the
performance.
Yi

> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-x86...@googlegroups.com.

Chih-Wei Huang

unread,
Aug 20, 2010, 5:16:47 AM8/20/10
to andro...@googlegroups.com
Hi,
I'm testing the 32bpp patch.
It seems work, but the color is wrong.
Test on both on vm (uvesafb) and eeepc(i915),
with kernel 2.6.35.

Finally I found I have to change the pixel format
to BGRA_8888 to have the correct color:

const_cast<int&>(dev->device.format) = HAL_PIXEL_FORMAT_BGRA_8888;

Do you know what the problem is?


2010/8/10 mtx512 <mtx5...@gmail.com>:


> Yes have tested, my screen now displays correctly.
>

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

Jack

unread,
Aug 22, 2010, 10:57:43 PM8/22/10
to Android-x86
It is a way to hard code for 32bpp. That is not good if we want to
support devices which could not support it. Is there a way to
automatically detect current depth and initialize the framebuffer for
it?

On 8月20日, 下午5时16分, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> Hi,
> I'm testing the 32bpp patch.
> It seems work, but the color is wrong.
> Test on both on vm (uvesafb) and eeepc(i915),
> with kernel 2.6.35.
>
> Finally I found I have to change the pixel format
> to BGRA_8888 to have the correct color:
>
> const_cast<int&>(dev->device.format) = HAL_PIXEL_FORMAT_BGRA_8888;
>
> Do you know what the problem is?
>
> 2010/8/10 mtx512 <mtx51...@gmail.com>:

Chih-Wei Huang

unread,
Aug 22, 2010, 11:46:21 PM8/22/10
to andro...@googlegroups.com
Hmm, good suggestion.
I just checked the code.
Yes, it's possible to detect the bpp
at runtime.

在 2010年8月23日上午10:57,Jack <jlee...@gmail.com> 寫道:
> It is a way to hard code for 32bpp. That is not good if we want to
> support devices which could not support it. Is there a way to
> automatically detect current depth and initialize the framebuffer for
> it?

Reply all
Reply to author
Forward
0 new messages