drm/exynos: mixer blending and layer order

drm/exynos: mixer blending and layer order

[Tobias Jakobi]

Hello,

I've noticed some inconsistency in what is currently exported as 'zpos' 
DRM propery to userspace. Currently we create three planes, where the 
zpos maps to the mixer 'win' (is this simply short for window?).

But this is wrong since the mixer layer configuration is currently done 
in this way (in mixer_win_reset()):
layer1 (win[1]) > layer0 (win[0]) > video (win[2])

So layer1 is at the top of our stack, and the video layer is at the 
bottom. So regardless on how you interpret the zpos property (0 being 
the top, or 0 being bottom), it doesn't give you accurate information on 
how the planes are ordered.

Related to this is the issue of how to blend planes. When should 
blending of layer be enabled? We probably want to based this on three 
states:
- which layer are enabled
- which pixelformats are associated to the layers
- in which order are the layers (*)

(*) So in the case of 'layer1 > layer0 > video', layer1 disabled, 
layer0/video enabled, layer0 having alpha-pixelformat, we want to blend 
layer0 and the video layer (so effectively making layer0 translucent).

I'm trying to come up with a proposition for that issue in the next 
days, but it would really help to hear thoughts of you guys.

With best wishes,
Tobias

Re: drm/exynos: mixer blending and layer order

[Joonyoung Shim]

Hi Tobias,

On 04/23/2015 09:28 PM, Tobias Jakobi wrote:
> Hello,
> 
> I've noticed some inconsistency in what is currently exported as 'zpos' DRM propery to userspace. Currently we create three planes, where the zpos maps to the mixer 'win' (is this simply short for window?).
> 
> But this is wrong since the mixer layer configuration is currently done in this way (in mixer_win_reset()):
> layer1 (win[1]) > layer0 (win[0]) > video (win[2])
> 
> So layer1 is at the top of our stack, and the video layer is at the bottom. So regardless on how you interpret the zpos property (0 being the top, or 0 being bottom), it doesn't give you accurate information on how the planes are ordered.
> 

I know, actually here zpos doesn't mean order priority of layer, it is
just real hardware layer. Exynos mixer has 3 hardware layer, graphic0
layer, graphic1 layer and video layer, so zpos 0 means graphic0 layer,
zpos 1 means graphic1 layer, zpos 2 means video layer.

Thanks.

> Related to this is the issue of how to blend planes. When should blending of layer be enabled?

Current mixer codes permit blending about all layers except bottom layer
(just above background layer).

> We probably want to based this on three states:
> - which layer are enabled
> - which pixelformats are associated to the layers

This idea is ok but as i said, there is blending issue of background
layer.

> - in which order are the layers (*)

Now we don't permit to change order priority of layer.

> 
> (*) So in the case of 'layer1 > layer0 > video', layer1 disabled, layer0/video enabled, layer0 having alpha-pixelformat, we want to blend layer0 and the video layer (so effectively making layer0 translucent).
> 
> I'm trying to come up with a proposition for that issue in the next days, but it would really help to hear thoughts of you guys.
> 
> With best wishes,
> Tobias
> 
> 

Thanks.

Re: drm/exynos: mixer blending and layer order

[Tobias Jakobi]

Hello Joonyoung,

On 2015-04-24 04:13, Joonyoung Shim wrote:
> Hi Tobias,
> 
> On 04/23/2015 09:28 PM, Tobias Jakobi wrote:
>> Hello,
>> 
>> I've noticed some inconsistency in what is currently exported as 
>> 'zpos' DRM propery to userspace. Currently we create three planes, 
>> where the zpos maps to the mixer 'win' (is this simply short for 
>> window?).
>> 
>> But this is wrong since the mixer layer configuration is currently 
>> done in this way (in mixer_win_reset()):
>> layer1 (win[1]) > layer0 (win[0]) > video (win[2])
>> 
>> So layer1 is at the top of our stack, and the video layer is at the 
>> bottom. So regardless on how you interpret the zpos property (0 being 
>> the top, or 0 being bottom), it doesn't give you accurate information 
>> on how the planes are ordered.
>> 
> 
> I know, actually here zpos doesn't mean order priority of layer, it is
> just real hardware layer. Exynos mixer has 3 hardware layer, graphic0
> layer, graphic1 layer and video layer, so zpos 0 means graphic0 layer,
> zpos 1 means graphic1 layer, zpos 2 means video layer.
I'm aware of that, but that doesn't solve the issue at hand: The 'zpos' 
property is completly meaningless at ths point, since it tells the DRM 
user absolutely nothing about the z-ordering of the planes. Either that 
should be fixed (what I'm looking into) or the property should just be 
dropped.



> 
> Thanks.
> 
>> Related to this is the issue of how to blend planes. When should 
>> blending of layer be enabled?
> 
> Current mixer codes permit blending about all layers except bottom 
> layer
> (just above background layer).
> 
>> We probably want to based this on three states:
>> - which layer are enabled
>> - which pixelformats are associated to the layers
> 
> This idea is ok but as i said, there is blending issue of background
> layer.
Any suggestions on how to fix that bg issue?

Ville has pointed out that, under the condition that bg is a simple 
color, that it could be exported as a crtc property, see [1]. We would 
need another 'bg_enabled' flag as well I guess.


> 
>> - in which order are the layers (*)
> 
> Now we don't permit to change order priority of layer.
That's not what I mean (see my example). What I mean is that it should 
make a difference if the layer with alpha-pixelformat is on top of some 
layer, or below.

Something like this:
- if layer[i] has non-alpha-pixelformat, don't enable any blending for 
that layer
- if layer[i] has alpha-pixelformat, and layer[i] is a the bottom of our 
layer-stack, don't enable any blending for that layer (*)
- if layer[i] has alpha-pixelformat, and there exists layer[j] which is 
located right below layer[i] in our stack, then enable blending

The configuration in (*) then would be the default setup, when just the 
primary plane is enabled, and no other planes are active.

The background would then just become another (virtual) layer.

I hope this is less confusing than my previous description. :)


> 
>> 
>> (*) So in the case of 'layer1 > layer0 > video', layer1 disabled, 
>> layer0/video enabled, layer0 having alpha-pixelformat, we want to 
>> blend layer0 and the video layer (so effectively making layer0 
>> translucent).
>> 
>> I'm trying to come up with a proposition for that issue in the next 
>> days, but it would really help to hear thoughts of you guys.
>> 
>> With best wishes,
>> Tobias
>> 
>> 
> 
> Thanks.

With best wishes,
Tobias


[1] http://article.gmane.org/gmane.comp.video.dri.devel/127749

Re: drm/exynos: mixer blending and layer order

[Joonyoung Shim]

Hi Tobias,

On 04/24/2015 05:29 PM, Tobias Jakobi wrote:
> Hello Joonyoung,
> 
> On 2015-04-24 04:13, Joonyoung Shim wrote:
>> Hi Tobias,
>>
>> On 04/23/2015 09:28 PM, Tobias Jakobi wrote:
>>> Hello,
>>>
>>> I've noticed some inconsistency in what is currently exported as 'zpos' DRM propery to userspace. Currently we create three planes, where the zpos maps to the mixer 'win' (is this simply short for window?).
>>>
>>> But this is wrong since the mixer layer configuration is currently done in this way (in mixer_win_reset()):
>>> layer1 (win[1]) > layer0 (win[0]) > video (win[2])
>>>
>>> So layer1 is at the top of our stack, and the video layer is at the bottom. So regardless on how you interpret the zpos property (0 being the top, or 0 being bottom), it doesn't give you accurate information on how the planes are ordered.
>>>
>>
>> I know, actually here zpos doesn't mean order priority of layer, it is
>> just real hardware layer. Exynos mixer has 3 hardware layer, graphic0
>> layer, graphic1 layer and video layer, so zpos 0 means graphic0 layer,
>> zpos 1 means graphic1 layer, zpos 2 means video layer.
> I'm aware of that, but that doesn't solve the issue at hand: The 'zpos' property is completly meaningless at ths point, since it tells the DRM user absolutely nothing about the z-ordering of the planes. Either that should be fixed (what I'm looking into) or the property should just be dropped.
> 

The zpos was not for layer order priority and now user cannot select hw
layer which user wants to output without it.

> 
> 
>>
>> Thanks.
>>
>>> Related to this is the issue of how to blend planes. When should blending of layer be enabled?
>>
>> Current mixer codes permit blending about all layers except bottom layer
>> (just above background layer).
>>
>>> We probably want to based this on three states:
>>> - which layer are enabled
>>> - which pixelformats are associated to the layers
>>
>> This idea is ok but as i said, there is blending issue of background
>> layer.
> Any suggestions on how to fix that bg issue?
> 
> Ville has pointed out that, under the condition that bg is a simple color, that it could be exported as a crtc property, see [1]. We would need another 'bg_enabled' flag as well I guess.
> 

First, i'm not sure whether it's right to enable blending of bottom
layer and bg layer. Now current code doesn't permit it. If we allow
it, i think it's ok to use crtc property but it is increased exynos
specific property.

> 
>>
>>> - in which order are the layers (*)
>>
>> Now we don't permit to change order priority of layer.
> That's not what I mean (see my example). What I mean is that it should make a difference if the layer with alpha-pixelformat is on top of some layer, or below.
> 
> Something like this:
> - if layer[i] has non-alpha-pixelformat, don't enable any blending for that layer
> - if layer[i] has alpha-pixelformat, and layer[i] is a the bottom of our layer-stack, don't enable any blending for that layer (*)

The layer[i] is bottom, then why don't other all layers enable blending?

If The layer[0] is bottom and layer[1] is right above layer[0] and
alpha-pixelformat, i think it's possible blending of layer[1] and
layer[0].

Thanks.

> - if layer[i] has alpha-pixelformat, and there exists layer[j] which is located right below layer[i] in our stack, then enable blending
> 
> The configuration in (*) then would be the default setup, when just the primary plane is enabled, and no other planes are active.
> 
> The background would then just become another (virtual) layer.
> 
> I hope this is less confusing than my previous description. :)
> 
> 
>>
>>>
>>> (*) So in the case of 'layer1 > layer0 > video', layer1 disabled, layer0/video enabled, layer0 having alpha-pixelformat, we want to blend layer0 and the video layer (so effectively making layer0 translucent).
>>>
>>> I'm trying to come up with a proposition for that issue in the next days, but it would really help to hear thoughts of you guys.
>>>
>>> With best wishes,
>>> Tobias
>>>
>>>
>>
>> Thanks.
> 
> With best wishes,
> Tobias
> 
> 
> [1] http://article.gmane.org/gmane.comp.video.dri.devel/127749
> 
> 

Re: drm/exynos: mixer blending and layer order

[Tobias Jakobi]

Hello Joonyoung,

On 2015-04-27 08:52, Joonyoung Shim wrote:
> Hi Tobias,
> 
> On 04/24/2015 05:29 PM, Tobias Jakobi wrote:
>> Hello Joonyoung,
>> 
>> On 2015-04-24 04:13, Joonyoung Shim wrote:
>>> Hi Tobias,
>>> 
>>> On 04/23/2015 09:28 PM, Tobias Jakobi wrote:
>>>> Hello,
>>>> 
>>>> I've noticed some inconsistency in what is currently exported as 
>>>> 'zpos' DRM propery to userspace. Currently we create three planes, 
>>>> where the zpos maps to the mixer 'win' (is this simply short for 
>>>> window?).
>>>> 
>>>> But this is wrong since the mixer layer configuration is currently 
>>>> done in this way (in mixer_win_reset()):
>>>> layer1 (win[1]) > layer0 (win[0]) > video (win[2])
>>>> 
>>>> So layer1 is at the top of our stack, and the video layer is at the 
>>>> bottom. So regardless on how you interpret the zpos property (0 
>>>> being the top, or 0 being bottom), it doesn't give you accurate 
>>>> information on how the planes are ordered.
>>>> 
>>> 
>>> I know, actually here zpos doesn't mean order priority of layer, it 
>>> is
>>> just real hardware layer. Exynos mixer has 3 hardware layer, graphic0
>>> layer, graphic1 layer and video layer, so zpos 0 means graphic0 
>>> layer,
>>> zpos 1 means graphic1 layer, zpos 2 means video layer.
>> I'm aware of that, but that doesn't solve the issue at hand: The 
>> 'zpos' property is completly meaningless at ths point, since it tells 
>> the DRM user absolutely nothing about the z-ordering of the planes. 
>> Either that should be fixed (what I'm looking into) or the property 
>> should just be dropped.
>> 
> 
> The zpos was not for layer order priority and now user cannot select hw
> layer which user wants to output without it.
I don't understand this. The 'zpos' property is not necessary for the 
user to select a plane. I mean, it's not even a required property of a 
plane. Or did this change with atomic?

Anyway, all I'm saying here is that 'zpos' is meaningless at this point. 
To restore meaning to the property it should reflect the order of the 
layers, or to use mixer terminology, the layer priority.


>>> Thanks.
>>> 
>>>> Related to this is the issue of how to blend planes. When should 
>>>> blending of layer be enabled?
>>> 
>>> Current mixer codes permit blending about all layers except bottom 
>>> layer
>>> (just above background layer).
>>> 
>>>> We probably want to based this on three states:
>>>> - which layer are enabled
>>>> - which pixelformats are associated to the layers
>>> 
>>> This idea is ok but as i said, there is blending issue of background
>>> layer.
>> Any suggestions on how to fix that bg issue?
>> 
>> Ville has pointed out that, under the condition that bg is a simple 
>> color, that it could be exported as a crtc property, see [1]. We would 
>> need another 'bg_enabled' flag as well I guess.
>> 
> 
> First, i'm not sure whether it's right to enable blending of bottom
> layer and bg layer. Now current code doesn't permit it. If we allow
> it, i think it's ok to use crtc property but it is increased exynos
> specific property.
I think I can design the code in such a way that we can easily extend it 
once this feature appears. And it wouldn't be Exynos specific at all 
(since it originates from the Intel developers).


>>>> - in which order are the layers (*)
>>> 
>>> Now we don't permit to change order priority of layer.
>> That's not what I mean (see my example). What I mean is that it should 
>> make a difference if the layer with alpha-pixelformat is on top of 
>> some layer, or below.
>> 
>> Something like this:
>> - if layer[i] has non-alpha-pixelformat, don't enable any blending for 
>> that layer
>> - if layer[i] has alpha-pixelformat, and layer[i] is a the bottom of 
>> our layer-stack, don't enable any blending for that layer (*)
> 
> The layer[i] is bottom, then why don't other all layers enable 
> blending?
Because it's wrong. If a layer has no alpha component, then it means 
that the layer is opaque. You can't see through an opaque layer, hence 
everything 'behind' it (which means that it has a lower plane priority) 
is not visible.

If you enable blending regardless of the present of alpha, you also 
introduce subtle bugs. If a user specifies that his buffer has 
pixelformat XRGB, then this is an explicit request to ignore the content 
in 'X'. The user should be able to assume any data in 'X' is not 
considered by the DRM. If we now silently enable blending, we break that 
assumption.

This in turn then leads to userspace having to deal with this mess:
https://github.com/endlessm/xf86-video-armsoc/commit/53ac6858071e8e2db92cdea28422beafee481cb6



> If The layer[0] is bottom and layer[1] is right above layer[0] and
> alpha-pixelformat, i think it's possible blending of layer[1] and
> layer[0].
This plane setup is currently resolved in my code in the way you 
describe. I just need to do some cleaning up, so it might take some more 
time. :)


With best wishes,
Tobias

Re: drm/exynos: mixer blending and layer order

[Joonyoung Shim]

Hi Tobias,

On 04/28/2015 09:58 PM, Tobias Jakobi wrote:
> Hello Joonyoung,
> 
> On 2015-04-27 08:52, Joonyoung Shim wrote:
>> Hi Tobias,
>>
>> On 04/24/2015 05:29 PM, Tobias Jakobi wrote:
>>> Hello Joonyoung,
>>>
>>> On 2015-04-24 04:13, Joonyoung Shim wrote:
>>>> Hi Tobias,
>>>>
>>>> On 04/23/2015 09:28 PM, Tobias Jakobi wrote:
>>>>> Hello,
>>>>>
>>>>> I've noticed some inconsistency in what is currently exported as 'zpos' DRM propery to userspace. Currently we create three planes, where the zpos maps to the mixer 'win' (is this simply short for window?).
>>>>>
>>>>> But this is wrong since the mixer layer configuration is currently done in this way (in mixer_win_reset()):
>>>>> layer1 (win[1]) > layer0 (win[0]) > video (win[2])
>>>>>
>>>>> So layer1 is at the top of our stack, and the video layer is at the bottom. So regardless on how you interpret the zpos property (0 being the top, or 0 being bottom), it doesn't give you accurate information on how the planes are ordered.
>>>>>
>>>>
>>>> I know, actually here zpos doesn't mean order priority of layer, it is
>>>> just real hardware layer. Exynos mixer has 3 hardware layer, graphic0
>>>> layer, graphic1 layer and video layer, so zpos 0 means graphic0 layer,
>>>> zpos 1 means graphic1 layer, zpos 2 means video layer.
>>> I'm aware of that, but that doesn't solve the issue at hand: The 'zpos' property is completly meaningless at ths point, since it tells the DRM user absolutely nothing about the z-ordering of the planes. Either that should be fixed (what I'm looking into) or the property should just be dropped.
>>>
>>
>> The zpos was not for layer order priority and now user cannot select hw
>> layer which user wants to output without it.
> I don't understand this. The 'zpos' property is not necessary for the user to select a plane. I mean, it's not even a required property of a plane. Or did this change with atomic?
> 

Without zpos, user may select hw layer only via plane resources order on
latest exynos drm driver, but zpos can give obvious information to user.
Of course we can improve zpos property or remove it or as you said
change meaning for layer priority for better usage, but i just say what
current codes mean.

> Anyway, all I'm saying here is that 'zpos' is meaningless at this point. To restore meaning to the property it should reflect the order of the layers, or to use mixer terminology, the layer priority.
> 
> 
>>>> Thanks.
>>>>
>>>>> Related to this is the issue of how to blend planes. When should blending of layer be enabled?
>>>>
>>>> Current mixer codes permit blending about all layers except bottom layer
>>>> (just above background layer).
>>>>
>>>>> We probably want to based this on three states:
>>>>> - which layer are enabled
>>>>> - which pixelformats are associated to the layers
>>>>
>>>> This idea is ok but as i said, there is blending issue of background
>>>> layer.
>>> Any suggestions on how to fix that bg issue?
>>>
>>> Ville has pointed out that, under the condition that bg is a simple color, that it could be exported as a crtc property, see [1]. We would need another 'bg_enabled' flag as well I guess.
>>>
>>
>> First, i'm not sure whether it's right to enable blending of bottom
>> layer and bg layer. Now current code doesn't permit it. If we allow
>> it, i think it's ok to use crtc property but it is increased exynos
>> specific property.
> I think I can design the code in such a way that we can easily extend it once this feature appears. And it wouldn't be Exynos specific at all (since it originates from the Intel developers).
> 
> 
>>>>> - in which order are the layers (*)
>>>>
>>>> Now we don't permit to change order priority of layer.
>>> That's not what I mean (see my example). What I mean is that it should make a difference if the layer with alpha-pixelformat is on top of some layer, or below.
>>>
>>> Something like this:
>>> - if layer[i] has non-alpha-pixelformat, don't enable any blending for that layer
>>> - if layer[i] has alpha-pixelformat, and layer[i] is a the bottom of our layer-stack, don't enable any blending for that layer (*)
>>
>> The layer[i] is bottom, then why don't other all layers enable blending?
> Because it's wrong. If a layer has no alpha component, then it means that the layer is opaque. You can't see through an opaque layer, hence everything 'behind' it (which means that it has a lower plane priority) is not visible.
> 

I mean it can be invalidated when the layer has any above layers. To
enable blending of layer can do regardless of opaque of behind layer,
right? Please fix me if i misunderstand.

> If you enable blending regardless of the present of alpha, you also introduce subtle bugs. If a user specifies that his buffer has pixelformat XRGB, then this is an explicit request to ignore the content in 'X'. The user should be able to assume any data in 'X' is not considered by the DRM. If we now silently enable blending, we break that assumption.
> 

I already said it's ok to decide blending feature on/off of layer by
pixel format.

Thanks.

> This in turn then leads to userspace having to deal with this mess:
> https://github.com/endlessm/xf86-video-armsoc/commit/53ac6858071e8e2db92cdea28422beafee481cb6
> 
> 
> 
>> If The layer[0] is bottom and layer[1] is right above layer[0] and
>> alpha-pixelformat, i think it's possible blending of layer[1] and
>> layer[0].
> This plane setup is currently resolved in my code in the way you describe. I just need to do some cleaning up, so it might take some more time. :)
> 
> 
> With best wishes,
> Tobias
> 
> 
> 

Re: drm/exynos: mixer blending and layer order

[Tobias Jakobi]

Hey Joonyoung,

On 2015-04-29 08:49, Joonyoung Shim wrote:
> Without zpos, user may select hw layer only via plane resources order 
> on
> latest exynos drm driver, but zpos can give obvious information to 
> user.
> Of course we can improve zpos property or remove it or as you said
> change meaning for layer priority for better usage, but i just say what
> current codes mean.
Ok, I think I have some good idea how to properly fix this, but I guess 
I should wait for Gustavos's plane cleanup to happen.


> I mean it can be invalidated when the layer has any above layers. To
> enable blending of layer can do regardless of opaque of behind layer,
> right? Please fix me if i misunderstand.
The plan is the following:
- For the bottom-most (enabled) layer we always disable any kind of 
blending. We can make this more generic if we should expose 
configuration of the background layer to userspace (but this is for the 
future).
- For all other (enabled) layers we setup blending depending on the 
pixelformat. If it's an alpha format, we enable blending, if not, 
disable blending.

Does this sound correct?

Something we can keep in mind for the future:
Attach a 'global alpha' DRM property to each plane so that we can setup 
blending even for non-alpha pixelformats. Range would be -1 to 0xff, 
where -1 would mean 'disable global-alpha. This would expose the 
MXR_GRP_CFG_WIN_BLEND_EN functionality.



> I already said it's ok to decide blending feature on/off of layer by
> pixel format.
Sorry, I misunderstood you there!


Also, maybe you can help me with this. The SoCs with no video processor 
(so 'is_vp_enabled=0'), how many layers does the mixer support there? Is 
it just one layer less (so no video layer), or is the video layer 
replaced by a normal non-video layer? The current code implies that 
there is one layer less, but I want to make sure I get this right! :)




With best wishes,
Tobias

Re: drm/exynos: mixer blending and layer order

[Joonyoung Shim]

Hi Tobias,

On 04/29/2015 10:13 PM, Tobias Jakobi wrote:
> Hey Joonyoung,
> 
> On 2015-04-29 08:49, Joonyoung Shim wrote:
>> Without zpos, user may select hw layer only via plane resources order on
>> latest exynos drm driver, but zpos can give obvious information to user.
>> Of course we can improve zpos property or remove it or as you said
>> change meaning for layer priority for better usage, but i just say what
>> current codes mean.
> Ok, I think I have some good idea how to properly fix this, but I guess I should wait for Gustavos's plane cleanup to happen.
> 
> 
>> I mean it can be invalidated when the layer has any above layers. To
>> enable blending of layer can do regardless of opaque of behind layer,
>> right? Please fix me if i misunderstand.
> The plan is the following:
> - For the bottom-most (enabled) layer we always disable any kind of blending. We can make this more generic if we should expose configuration of the background layer to userspace (but this is for the future).
> - For all other (enabled) layers we setup blending depending on the pixelformat. If it's an alpha format, we enable blending, if not, disable blending.
> 
> Does this sound correct?
> 

Right.

> Something we can keep in mind for the future:
> Attach a 'global alpha' DRM property to each plane so that we can setup blending even for non-alpha pixelformats. Range would be -1 to 0xff, where -1 would mean 'disable global-alpha. This would expose the MXR_GRP_CFG_WIN_BLEND_EN functionality.
> 

Yeah, i think it's possible.

> 
> 
>> I already said it's ok to decide blending feature on/off of layer by
>> pixel format.
> Sorry, I misunderstood you there!
> 
> 
> Also, maybe you can help me with this. The SoCs with no video processor (so 'is_vp_enabled=0'), how many layers does the mixer support there? Is it just one layer less (so no video layer), or is the video layer replaced by a normal non-video layer? The current code implies that there is one layer less, but I want to make sure I get this right! :)
> 

Mixer supports three hw layers - graphic0, graphic1, video.

Exynos4 SoC series has video processor and it gets video data from DRAM
and after any processing, transfers to mixer video layer.

Exynos5 SoC series doesn't have video processor but there is gscaler
(general scaler) hw. It is generic M2M(memory to memory) hw to gets data
from DRAM and after any processing, transfer to memory, but it also can
transfer processing data to mixer video layer if changes some
configuration(call local path). Unfortunately, I heard local path from
gscaler to mixer video layer wasn't verified from exynos chip vender, so
there is no way to enable mixer video layer on exynos5 now.

Thanks.