Alpha channel on external display interface?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Alpha channel on external display interface?

1,260 Views
sidebranch
Contributor II

When the framebuffers are in 32-bit ARGB mode, can the i.MX53 bring out the alpha channel to the external display interface carry an alpha channel?

I.e. ARGB instead of RGB?

Regards,

Leon.

Labels (1)
0 Kudos
6 Replies

897 Views
sidebranch
Contributor II

This last idea was impossible, as the DP cuts of 24-bits of the 32-bit prior to splitting the 24-bit in 3 components.

A new idea is to use the "DS3" dataflow that flows directly from memory to display, without going through the DP, which is think is what Philip Hatcher meant.

This is called GENERIC_DATA mode and is meant to stream any arbitrary data / format (such as JPEG) over the display bus.

However, I could not find any info or example driver under Linux on how to use this mode. Any pointers or app notes on this?

0 Kudos

897 Views
sidebranch
Contributor II

Philip,

another idea: we do only need 25 Hz. I am thinking of running at 50 Hz and then change the IPU mapping registers on each vertical sync, so that alternating "AR" and "GB" are available on the 24-bit LCD output interface.

Regards,

Leon.

0 Kudos

897 Views
sidebranch
Contributor II

Hello Philip, Freescalers,

I have read the IPU section of the i.MX53 datasheet and reference manual. Two things look like a possible solution to export ARGB to an external "smart display" or better "external graphics accelerator".

1) Synchronous mode, fooling the IPI into sending ARGB32 as two 16-bit

2) Asynchronous mode.

page 2635 of the i.MX53 Reference Manual Rev 2

Asynchronous Access:
This is the main mode used for communicating with an external display controller
(possibly in a smart display or a graphics accelerator). In this mode, the IPU performs
random access - read/write - to the memory and registers of the controller.
Two types of addressing methods are supported
• Generic linear addressing of pixels and generic data
• 2-dimensional (X/Y) addressing of pixels
The following access types are provided:
• Data transfer to the external device, after on-the-fly processing in the
• Data transfer (DMA) - read/write - between the host's system memory and the
external device, through the IPU's memory port (controlled by the IDMAC), such as
the transfer of a rectangular block of pixels (possibly full screen).
• Host access - read/write - to an external device, through the AHB-slave port
• Access types
• Direct access - emulating a directly-addressed access (see below) This
includes burst access (incremental; up to 8 words/burst)
• Low-level access - leaving to the host the explicit generation of the access
protocol
• The possible accessing modules include the ARM platform and the system DMA
controller (as well as any other AHB master connected to the ARM's cross-bar
switch).

We have seen that the Display Port is very versatile, it can even read from the display.

45.4.6.1 Display ports channels
The display port send data to the display over several channels. The data source may be
the system's memory (via the IDMAC) the IC block and the ARM platform. The display
port can read data from the display and send it to the ARM platform or IDMAC.

Is this more internal documentation available that helps me implement this mode? I have an NDA in place with Freescale.

Regards,

Leon.

0 Kudos

897 Views
sidebranch
Contributor II

Hello Philip,

thanks, I will certainly look into this, as we have something connected that is a bit smarter than an LCD, we use an external FPGA that allows an additional overlay. Would be nice to support per-pixel alpha in real-time.

See here: http://imxcommunity.org/photo/trisendo-2d-3d-video-board

Regards,

Leon.

0 Kudos

897 Views
Philip_FSL
Contributor IV

Hello Leon,

The Display interface implicitly drops the alpha component as this is not something used by an LCD.  If you would like to get the alpha information out of the IPU, it might be possible to fool the IPU into sending the data as 16bpp data in two clock cycles per pixel.  This does imply some restrictions as you would not be able to use the DP to manipulate the image (color space conversion, alpha blending) on the way to the DI since the IPU "thinks" it is handling 16bpp pixel data.

Philip

0 Kudos

897 Views
sidebranch
Contributor II

For example, at 30 Hz, is it possible to use the external display interface in 16-bit mode,

and send "AR" (16-bit) then "BG" (16-bit)?

0 Kudos