Final output of Display FB0 contains Alpha values as always 255

Friedrich, Eugen (ADITG/SW1) efriedrich at de.adit-jv.com
Thu Mar 17 10:34:40 EDT 2016


Hi ,

You should check the native format of you FB0 it seems to be XRGB so alpha is ignored.
I don’t have much experience with X11 but maybe you can setup this with Depth 32 , But most probably X11 will not support, having “transparent display” is not an use-case for X11, then you would need  to change the rendering in X11.

Best regards

Eugen Friedrich
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6921
From: genivi-ivi-layer-management-bounces at lists.genivi.org [mailto:genivi-ivi-layer-management-bounces at lists.genivi.org] On Behalf Of arunkrish20 .
Sent: Donnerstag, 17. März 2016 15:10
To: genivi-ivi-layer-management at lists.genivi.org; genivi-projects at lists.genivi.org
Subject: Final output of Display FB0 contains Alpha values as always 255

Hi All,
In our applications, we are using X11,LayerManager, Open GL to update the display.
We have 1 X11 windows and added to a layer and to a screen. Screen is nothing but X final output to a display. Here is our application FB0 (Hardware frame buffer). FB1 is used for Video informations. FB0 and FB1 will be composited by Image processing Unit inbuilt in the chip itself.

screen 0 (0x0)
---------------------------------------
- resolution:           x=1280, y=480
- hardware layer count: 0
- layer render order:   1000(0x3e8)

    layer 1000 (0x3e8)
    ---------------------------------------
    - created by pid:       182
    - original size:        x=800, y=480
    - destination region:   x=0, y=0, w=800, h=480
    - source region:        x=0, y=0, w=800, h=480
    - orientation:          0 (up is top)
    - opacity:              1
    - visibility:           1
    - type:                 2 (software 2d)
    - chromakey:            disabled (r=0, g=0, b=0)
    - surface render order: 100 (0x64)
    - on screen:            0(0x0)


        surface 100 (0x64)
        ---------------------------------------
        - created by pid:       330
        - original size:      x=800, y=480
        - destination region: x=0, y=0, w=800, h=480
        - source region:      x=0, y=0, w=800, h=480
        - orientation:        0 (up is top)
        - opacity:            1
        - visibility:         1
        - pixel format:       2 (RGBA-8888)
        - native surface:     6291457
        - accepts input from: keyboard mouse touch
        - has keyboard focus: true
        - chromakey:          disabled (r=0, g=0, b=0)
        - counters:           frame=837, draw=0, update=0
        - on layer:           1000(0x3e9)

Xorg conf

section "Device"
    Identifier  "i.MX Accelerated Framebuffer Device"
    Driver      "vivante"
    Option      "fbdev"     "/dev/fb0"
    Option      "vivante_fbdev" "/dev/fb0"
    Option      "HWcursor"  "false"
    Option      "mode_settings" "false"
EndSection

Section "ServerFlags"
    Option "BlankTime"  "0"
    Option "StandbyTime"  "0"
    Option "SuspendTime"  "0"
    Option "OffTime"  "0"
EndSection

section "screen"
    Identifier "Screen0"
    Device "i.MX Accelerated Framebuffer Device"
    Monitor "Monitor0"
    DefaultDepth 24
    DefaultFbBpp 32
    SubSection "Display"
        Viewport 0 0
        Depth 24
        FbBpp 32
        Modes "1024x768"
    EndSubSection
EndSection

So from our application we are updating each pixel with R - 0 G - 0 B - 0 A - 0 to the window. Same thing when i dumped(modified the save to file function with RGBA 32 bit formate in LayerManager code) the screen 0 to a file same pixel values R - 0 G - 0 B - 0 A - 0 updated. But when i dumped the data of FB0 R - 0 G - 0 B - 0 A - 255.
So there is no transparency.
I just doubt that X may be blocking Alpha content update 255.
So i just tried without Layer manager doing the same thing we are getting R - 0 G - 0 B - 0 A - 0 in FB0.
So i dont understand Where could be the problem? Please help me to find out and which area, i need to look for this issue to fix.
Thanks in advance,
Arunkumar R



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20160317/1109b80a/attachment.html>


More information about the genivi-projects mailing list