About the PixelFormat mappings in drm_gralloc

[Chih-Wei Huang]

2015-10-08 1:28 GMT+08:00 <bugzill...@freedesktop.org>:
> Comment # 22 on bug 91596 from Rob Clark
>
> (In reply to Chih-Wei Huang from comment #20)
>> (In reply to Rob Clark from comment #17)
>> > (In reply to Emil Velikov from comment #15)
>> > > Upon closer look the mappings in drm_format_from_hal and
>> > > get_pipe_format
>> > > look very funny.
>>
>> What does it mean? What's funny?
>
> well, mapping both HAL_PIXEL_FORMAT_RGB_888 and HAL_PIXEL_FORMAT_BGRA_8888
> to
> DRM_FORMAT_XRGB8888, for example..
>
> tbh I'm not sure what "endianess" HAL_PIXEL_FORMAT_* thinks about, but if
> HAL_PIXEL_FORMAT_RGBA_8888 -> DRM_FORMAT_RGBA8888, then it seems odd that
> HAL_PIXEL_FORMAT_RGBX_8888 -> DRM_FORMAT_XBGR8888..

Hi Tapani,
Recently the Mesa developers (Emil and Rob) pointed out
there are some funny mapping defined in drm_format_from_hal
of drm_gralloc. (see above discussion)

Checking the git history, I found you made a change
to this mapping at 2012/08/31 (submitted by Daniel Leung):

https://sourceforge.net/p/android-x86/external_drm_gralloc/ci/28d19f649f276ed8302a7d3bab078f692a84e6d9/

The mapping of HAL_PIXEL_FORMAT_RGB_888 and
HAL_PIXEL_FORMAT_BGRA_8888 was silently changed
from DRM_FORMAT_ARGB8888 to DRM_FORMAT_XRGB8888

Could you explain it? Is there any rationale?
Shouldn't it be DRM_FORMAT_BGRA8888?





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

[Chih-Wei Huang]

2015-10-27 16:56 GMT+08:00 Tapani Pälli <tapani...@intel.com>:

> On 10/27/2015 10:41 AM, Chih-Wei Huang wrote:
>>
>>
>> Hi Tapani,
>> Recently the Mesa developers (Emil and Rob) pointed out
>> there are some funny mapping defined in drm_format_from_hal
>> of drm_gralloc. (see above discussion)
>>
>> Checking the git history, I found you made a change
>> to this mapping at 2012/08/31 (submitted by Daniel Leung):
>>
>>
>> https://sourceforge.net/p/android-x86/external_drm_gralloc/ci/28d19f649f276ed8302a7d3bab078f692a84e6d9/
>>
>> The mapping of HAL_PIXEL_FORMAT_RGB_888 and
>> HAL_PIXEL_FORMAT_BGRA_8888 was silently changed
>> from DRM_FORMAT_ARGB8888 to DRM_FORMAT_XRGB8888
>>
>> Could you explain it? Is there any rationale?
>> Shouldn't it be DRM_FORMAT_BGRA8888?
>>
>

> Sorry, I can't recall what has been the motivation for this. What I do know
> is that some of the code is buggy and some of the fixes we had internally
> were never pushed/released when I stopped working on that project.
>
> Fortunately Google has picked up on this code and has made several fixes +
> updated functionality in to how gralloc+hwcomposer combo is defined today
> (kms pieces should not live in gralloc anymore).
>
> https://android.googlesource.com/platform/external/drm_gralloc
>
> My recommendation is to check if this issue is fixed there.

Tapani, thank you for the suggestion.

Originally I prefer not to use google's branch
since it's pulled from an old commit of drm_gralloc
from android-x86 repository.
We have a lot of improvements since that point.
Simply merging them results in many conflicts.

But I decide to give it a try as you suggested.
However, there are some building errors.
Google's drm_hwcomposer uses an old
drm atomic apis, while we use the (almost) latest libdrm.
I tried to replace the old apis by the new apis
( drmModePropertySetPtr -> drmModeAtomicReqPtr,
drmModePropertySetAdd -> drmModeAtomicAddProperty, ...)
Not sure if I did it correctly. But finaly it built ok.

However, SurfaceFlinger crashed on hwcomposer.drm
initializing. The call failed (in drmresources.cpp):

ret = drmSetClientCap(fd_, DRM_CLIENT_CAP_ATOMIC, 1);

Tracing kernel drm and i915 module, seems I need to set
drm.atomic=1 and i915.nuclear_pageflip=1 to make it work.
But then it failed again:

10-29 07:26:23.966 1639 1639 E hwc-drm-resources: Failed to get
properties for 19/cccccccc
10-29 07:26:23.966 1639 1639 E hwc-drm-crtc: Failed to get ACTIVE property
10-29 07:26:23.966 1639 1639 E hwc-drm-resources: Failed to initialize crtc 19
10-29 07:26:23.966 1639 1639 E hwcomposer-drm: Can't initialize Drm object -19

The failed call is (also in drmresources.cpp):

props = drmModeObjectGetProperties(fd_, obj_id, obj_type);

Due to my limited knowledge about drm/hwc,
I was unable to debug further.


My impression is Google's hwcomposer uses the relative
new drm atomic apis which are not supported well in
our current drm and i915 drivers of kernel 4.0.
Is it true? Should I try a newer kernel, say 4.3-rcX?

Please advice how to proceed.

PS. The pixelformat mapping defined in Google's hwcomposer
is different than ours. Looks more reasonable.

https://android.googlesource.com/platform/external/drm_hwcomposer/+/marshmallow-release/drmgenericimporter.cpp#68

(Emil, Rob, how do you think about it?)

[Mauro Rossi]

Hi,
I have always wondered why all Hal_pixel_format have labels reversed compared to associated drm_fourcc, except RGBA, could some expert explain this?

Also interested to know the reason why they are all reversed.
Thanks
M.

[Chih-Wei Huang]

2015-10-29 22:25 GMT+08:00 Rob Clark <robd...@gmail.com>:

> I think we do want to move to using drm_hwcomposer eventually..

Yes, I think so. But now I stuck.
Don't know how to proceed.

> although that might be a bigger task. You would want as new a kernel
> version as possible for i915, but I think atomic is still disabled by
> default (ie. without i915.nuclear_pageflip=y).

Hmm, OK.
I wonder what the kernel requirement of Google's drm_hwcomposer.
Most android devices still use older kernel like 3.10...

Let's ask the help from Google engineers...

>> However, SurfaceFlinger crashed on hwcomposer.drm
>> initializing. The call failed (in drmresources.cpp):
>>
>> ret = drmSetClientCap(fd_, DRM_CLIENT_CAP_ATOMIC, 1);
>>
>> Tracing kernel drm and i915 module, seems I need to set
>> drm.atomic=1 and i915.nuclear_pageflip=1 to make it work.
>> But then it failed again:
>>
>> 10-29 07:26:23.966 1639 1639 E hwc-drm-resources: Failed to get
>> properties for 19/cccccccc
>> 10-29 07:26:23.966 1639 1639 E hwc-drm-crtc: Failed to get ACTIVE property
>> 10-29 07:26:23.966 1639 1639 E hwc-drm-resources: Failed to initialize crtc 19
>> 10-29 07:26:23.966 1639 1639 E hwcomposer-drm: Can't initialize Drm object -19
>

> hmm, maybe the 'ACTIVE' property came in after 4.0?

Oh, I don't know what it is...

[Chih-Wei Huang]

2015-10-30 14:41 GMT+08:00 Tapani Pälli <tapani...@intel.com>:

> I did not understand from original mail if there was some bug/problem
> related to the format mapping (in drm_format_from_hal) or was it just that
> Rob pointed out that it is wrong and if you change it then things break? Did
> you try using the mapping from drm_hwcomposer?

Ah, OK. Sorry I didn't mention the whole story clearly.
Let me do it.

The long story in short.
I'm porting android 6.0 marshmallow to android-x86.
The first priority thing is to bring Mesa to work, of course.
(Yes, we still use Mesa. I know Intel has switched to
the proprietary closed source ufo libs since Kitkat.
That make Intel can't co-work with the community unfortunately.
I wonder if Intel has a plan to switch back to Mesa in the future.
But that's another story that we can talk later)

However, there is a big change in android 6.0
that breaks Mesa:

https://android.googlesource.com/platform/frameworks/native/+/733a80754786d39cdc0fee09509b194472c320bc%5E%21/

Originally we needed to apply WORKAROUND_BUG_10194508
to make Mesa live. Removing the workaround breaks Mesa
because RenderEngine::chooseEglConfig just fails
that results in SurfaceFlinger crashing.

At first I thought it's because Mesa doesn't support
HAL_PIXEL_FORMAT_RGBA_8888.
(I noticed you made a related patch before:
https://github.com/android-ia/platform_frameworks_native/commit/a53a2bab5356e8d8ea8b8bdb3db31a6d7378888d
)
However, after discussion other Mesa developers thought
the mapping of hal pixelformat to drm format may simply be wrong.
That's why I sent you this email to ask
why you made the mapping table before.

Then you suggested me to try Google's
drm_gralloc and drm_hwcomposer (good suggestion)
I did but got more troubles...

To answer your last question.
It's the change of android 6.0 (removing workaround 10194508)
that makes Mesa broken. The effort I'm trying to do
is to bring it back.

So here are some open questions:

* Is there any way to make Mesa to support
HAL_PIXEL_FORMAT_RGBA_8888?
Is it simply a wrong pixelformat mapping issue
or is there any limitation (hw or sw) to
prevent Mesa from supporting it?

* A related and more essential question is,
how to make Google's drm_hwcomposer work?
What's the prerequisite to make it work?
Since I still can't make it pass the initialization stage
so I can't tell whether if has the pixelformat mapping
issue or not.
I've sent another email Google's developers
to ask help. We can discuss the topic there.

* One thing I have not tested is to use the
current drm_gralloc implementation of android-x86
(refer http://sf.net/p/android-x86/external_drm_gralloc/ci/marshmallow-x86/tree/
)
but change pixelformat mapping as drm_hwcomposer uses.
If anyone thinks it is worth, I can give it a try.