BitBlt in Froyo

[Guest gusthy]

To be short: it is not true that Froyo pulse doesn't have a working copybits at all.

I made a minor change in kernel, installed a working live wallpaper, and I could see, that copybits worked happily when it used the msm_fb driver.

For some reason YouTube uses mdp_ppp driver, it seems that it is which is not working.

[Guest BigBearMDC]

To be short: it is not true that Froyo pulse doesn't have a working copybits at all.

I made a minor change in kernel, installed a working live wallpaper, and I could see, that copybits worked happily when it used the msm_fb driver.

For some reason YouTube uses mdp_ppp driver, it seems that it is which is not working.

I still don't now what the problem is :lol:

What is copybit? I guess it is related to the framebuffer?

[Guest gusthy]

I still don't now what the problem is :lol:

What is copybit? I guess it is related to the framebuffer?

The problem with video playback is, that there is a call called CopyBits in (among other things) by EGL, which copies an image from a source to a destination. It is not a trivial thing, since they can be different size, resolution, color depth etc.

This copybits thing in pulse currently translates to different driver calls, and that is our luck - we have the driver source. Now I am print-debugging it.

Edit: I tried the camera app too. It produces the same error as YouTube.

Edited September 25, 2010 by gusthy

[Guest gusthy]

To be short: it is not true that Froyo pulse doesn't have a working copybits at all.

I made a minor change in kernel, installed a working live wallpaper, and I could see, that copybits worked happily when it used the msm_fb driver.

For some reason YouTube uses mdp_ppp driver, it seems that it is which is not working.

S*t.

The nomenclature of blitter has changed from 2.1 to 2.2. Therefore it sometimes works, sometimes not.

[Guest BigBearMDC]

S*t.

The nomenclature of blitter has changed from 2.1 to 2.2. Therefore it sometimes works, sometimes not.

Don't worry. I'll just quick upload a few changes to flibble's repo and then we'll solve that problem :lol:

[Guest gusthy]

Don't worry. I'll just quick upload a few changes to flibble's repo and then we'll solve that problem :lol:

B)) look at drivers/video/msm/mdp_ppp.c and msm_fb.c

The important part is function mdp_ppp_blit. The problem with it is that

- huawei version has 4 parameters, aurora has 2

- it fails (sometimes, typically in Camera and YouTube) in the function above, called get_img.

this "if" should be true, but it is false in this case:

if (MAJOR(file->f_dentry->d_inode->i_rdev) == FB_MAJOR) {

Edit:

on the other hand, get_img is the same in codeaurora and pulse kernel sources, and even the beginning of mdp_ppp_blit is the same.

Edited September 25, 2010 by gusthy

[Guest BigBearMDC]

:lol:) look at drivers/video/msm/mdp_ppp.c and msm_fb.c

The important part is function mdp_ppp_blit. The problem with it is that

- huawei version has 4 parameters, aurora has 2

- it fails (sometimes, typically in Camera and YouTube) in the function above, called get_img.

this "if" should be true, but it is false in this case:

if (MAJOR(file->f_dentry->d_inode->i_rdev) == FB_MAJOR) {

Edit:

on the other hand, get_img is the same in codeaurora and pulse kernel sources, and even the beginning of mdp_ppp_blit is the same.

Hold on only a few minutes; there is not much left I have to patch in our .29 kernel B)

[Guest DanWilson]

Hold on only a few minutes; there is not much left I have to patch in our .29 kernel :lol:

You mean no space left?

Or nothing to fix / improve / add?

I could find a million and nine things to fix / improve / add. B)

[Guest gusthy]

Hold on only a few minutes; there is not much left I have to patch in our .29 kernel :lol:

I am on hold B)

[Guest BigBearMDC]

What exactly does this affect?

Do you think we could fix it by porting the code aurora source?

[Guest gusthy]

What exactly does this affect?

Do you think we could fix it by porting the code aurora source?

from the user point of view it affects the video and camera apps.

from technical point of view it means that feoyo calls the eclair kernel with two random parameters.

[Guest BigBearMDC]

from the user point of view it affects the video and camera apps.

from technical point of view it means that feoyo calls the eclair kernel with two random parameters.

Okay, so if we'd merge the code aurora driver bits into our source we might get a working camera in FroYo, but we might also break our camera in Eclair

Do we [you] know what those additional 2 parameters are good for in our driver? Maybe we could just overload this function with that one from the code aurora source, thus we might be able to prevent our camera applications from crashing in Eclair, even if we use the same kernel.

Best regards,

BB

[Guest gusthy]

Okay, so if we'd merge the code aurora driver bits into our source we might get a working camera in FroYo, but we might also break our camera in Eclair

Do we [you] know what those additional 2 parameters are good for in our driver? Maybe we could just overload this function with that one from the code aurora source, thus we might be able to prevent our camera applications from crashing in Eclair, even if we use the same kernel.

Best regards,

BB

I guess, in order to make cam & video working, we need to split the two kernels, but I don't think it is a big problem. Well, it would be better to have one.

TBH I guess, that that two parameters are not the cause of the problem, the problem is that because of them merging the two branches is not so trivial (They are two pointers to file buffers, that are used at the calling place, that is also in the driver.)

Edit:

A little bit deeper analysis shows that the procedure that is dying is waiting for a file with MAJOR=29 (FB_MAJOR), but gets one with MAJOR and MINOR=10,45 which is ashmem, so it is an android shared memory instead of a frame buffer.

Edited September 26, 2010 by gusthy

[Guest BigBearMDC]

I guess, in order to make cam & video working, we need to split the two kernels, but I don't think it is a big problem. Well, it would be better to have one.

TBH I guess, that that two parameters are not the cause of the problem, the problem is that because of them merging the two branches is not so trivial (They are two pointers to file buffers, that are used at the calling place, that is also in the driver.)

Edit:

A little bit deeper analysis shows that the procedure that is dying is waiting for a file with MAJOR=29 (FB_MAJOR), but gets one with MAJOR and MINOR=10,45 which is ashmem, so it is an android shared memory instead of a frame buffer.

So now that you even now which values it gets, you could easily fix it -> MAJOR=29 || MAJOR=10 || MAJOR=45

Should work?

Edit: Does this mean that in Eclair shared memory is used instead of a framebuffer??

[Guest gusthy]

So now that you even now which values it gets, you could easily fix it -> MAJOR=29 || MAJOR=10 || MAJOR=45

Should work?

Edit: Does this mean that in Eclair shared memory is used instead of a framebuffer??

You mean MAJOR=10, MINOR=45, but yes, I will try it, however it is a question if an ashmem block device works the same as an fb one, we shall see.

I don't know what Eclair does, it seems that FROYO uses ashmem, this is why froyo is way faster than Eclair. This is the kernel feature that is designed for Android lowmem devices, and Froyo utilizes it very well.

Nah, I tried it. It didn't solve the problem, but the result is very funny :lol:

Edited September 26, 2010 by gusthy

[Guest BigBearMDC]

You mean MAJOR=10, MINOR=45, but yes, I will try it, however it is a question if an ashmem block device works the same as an fb one, we shall see.

I don't know what Eclair does, it seems that FROYO uses ashmem, this is why froyo is way faster than Eclair. This is the kernel feature that is designed for Android lowmem devices, and Froyo utilizes it very well.

Nah, I tried it. It didn't solve the problem, but the result is very funny :lol:

What happened?

[Guest gusthy]

What happened?

It refreshed the screen with random content. So we only need to find how to extrect te image source from that ashmem thing.

(The destination seems to be always good.)

[Guest BigBearMDC]

It refreshed the screen with random content. So we only need to find how to extrect te image source from that ashmem thing.

(The destination seems to be always good.)

LoL B)

Okay, so we might get a working camera in FroYo soon :lol:

[Guest DanWilson]

LoL B)

Okay, so we might get a working camera in FroYo soon :lol:

Then it'll be about 85% working (if video comes with it).

Then we'll have these two left...

*#*# Codes don't work #*#*

A2DP (stereo bluetooth audio)

That GPS thing people are talking about, that I've never got...

[Guest gusthy]

Hmmm, I am not the first with this problem:

http://apt.rikers.org/%23htc-linux/20100828.html.gz

Edit: Well, it seems that we are on our own.

Cyanogen uses his own and totally different mdp implementation.

And there are not too many working mdp devices with Froyo.

Edited September 26, 2010 by gusthy

[Guest gusthy]

@TomG:

The problem seems to be that gralloc occasionally reverts to allocating ashmem buffers, and mdp cannot blit that. The question is if an implementation of gralloc w/o ashmem exists for Froyo?

[Guest AdamBaker]

@TomG:

The problem seems to be that gralloc occasionally reverts to allocating ashmem buffers, and mdp cannot blit that. The question is if an implementation of gralloc w/o ashmem exists for Froyo?

Assuming this is triggered by the patch at http://android.git.kernel.org/?p=platform/...e7cefecd1036472 then my question is why it is falling back to ashmem anyway as it seems it should only do that if there isn't enough pmem. I'm running eclair ATM so could someone confirm if the line

[0, swapper] [ 0.000000] allocating 8388608 bytes at c0732000 (10732000 physical) for mdp pmem arena

is present in the dmesg output when booting froyo.

[Guest Andy Veliz]

Assuming this is triggered by the patch at http://android.git.kernel.org/?p=platform/...e7cefecd1036472 then my question is why it is falling back to ashmem anyway as it seems it should only do that if there isn't enough pmem. I'm running eclair ATM so could someone confirm if the line

[0, swapper] [ 0.000000] allocating 8388608 bytes at c0732000 (10732000 physical) for mdp pmem arena

is present in the dmesg output when booting froyo.

dmesg | grep swapper

<6>[0, swapper] [15089.312182] wakeup wake lock: SMD_RPCCALL

<6>[0, swapper] [15092.821855] audio_dsp_event: PCMDMAMISSED 32

<6>[0, swapper] [15098.874440] usb cable connected

<6>[0, swapper] [15125.839729] usb_lpm_exit(): USB exited from low power mode

<6>[0, swapper] [15125.841422] usb cable connected

<6>[0, swapper] [15126.466607] hsusb suspend interrupt

<6>[0, swapper] [15126.712902] hsusb reset interrupt

<6>[0, swapper] [15126.715172] hsusb resume: speed = HIGH

<6>[0, swapper] [15126.903750] hsusb reset interrupt

<6>[0, swapper] [15126.906032] hsusb resume: speed = HIGH

it's not there, using flbmod2.0 w/oc kernel

[Guest gusthy]

Assuming this is triggered by the patch at http://android.git.kernel.org/?p=platform/...e7cefecd1036472 then my question is why it is falling back to ashmem anyway as it seems it should only do that if there isn't enough pmem. I'm running eclair ATM so could someone confirm if the line

[0, swapper] [ 0.000000] allocating 8388608 bytes at c0732000 (10732000 physical) for mdp pmem arena

is present in the dmesg output when booting froyo.

Interesting point.

This kernel does contain pmem, at least as pmem kernel option compiled in.

But I did never try to check if it actually works.

Edit: I can check if is it the kernel or Android who should init this pmem pool? But now I will transport the kids to school

Edited September 28, 2010 by gusthy

[Guest gusthy]

Bad news, it is there:

<6>[0, swapper] [ 0.000000] allocating 8388608 bytes at c072f000 (1072f000 physical) for mdp pmem arena

<6>[0, swapper] [ 0.000000] allocating 12582912 bytes at c072f000 (1072f000 physical) for adsp pmem arena

<6>[0, swapper] [ 0.000000] allocating 8388608 bytes at c1100000 (11100000 physical) for gpu1 pmem arena

What if I increase the size? I try it out now.

I doubled it, didn't help.

So next step is to check deeply why it falls back to ashmem.

Edited September 28, 2010 by gusthy