DSS output question

It is possible to have two indepedent displays from the OMAP3, one on the analog and one on the digital output, however these would require independent frame buffers of the appropriate size for the image (i.e. the scaling down functionality is not in place in the display pipeline, at least not in the current software). This being said you should be able to get the output you want, however you would have to do extra work with the CPU to get two frame buffers of the proper sizes to display on the analog and digital outputs.

There may also be additional driver limitations as you have mentioned, however the current driver package does allow you to switch the video and graphics pipelines to either output independently.

Looking at Documentation/arm/OMAP/DSS inside linux-omap-2.6.28 we see this video path:

___________________________________________________________________

Clone GFX overlay to LCD and TV
-------------------------------

tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
w=`echo $tvline | cut -d " " -f 5 | cut -d ":" -f 2 | cut -d "/" -f 1`
h=`echo $tvline | cut -d " " -f 6 | cut -d ":" -f 2 | cut -d "/" -f 1`

echo "1 t:none" > omapfb/framebuffers
echo "0 t:gfx,vid1" > omapfb/framebuffers
echo "gfx e:1" > omapfb/overlays
echo "vid1 t:tv w:$w h:$h e:1" > omapfb/overlays
echo "tv e:1" > omapfb/displays

After this the configuration looks like (only relevant parts shown):

FB0 +-- GFX  ---- LCD ---- LCD
     \- VID1 ---- TV  ---- TV

______________________________________________________________

This is possible only with omap3530 and not with omap3503?

Or better, FB0 has to be "good" for the both outputs (rescaling not needed), for example PAL or NTSC could be good ?

The 2.6.28 kernel is still declared "unstable", isn't it?

Can you give me the kernel roadmap?

OMAP3530 and OMAP3503 have the same display subsystem capabilities.

It is possible for them to use different framebuffers and different resolutions.  If they use the same framebuffer, yes, the output would have to be good for both display devices.

2.6.28 is stable, but the upstream kernel.org version does not include the updated DSS driver you are utilizing for dual-display.  That driver is not yet upstream/stable.

Take a look at the user's guide and release notes for the PSP kernel to get a feeling for the kernel roadmap.

Thanks for your answer.

So, starting a product today I'm going to use 2.6.28 compiled (and patched) using openembedded (today I'm still using -r14 version because I'm not working full time on omap3).

Or, if I would prefer a Ti certified kernel, I have to use 2.6.26 from Ti. This is a second choose only if I'll find big troubles in 2.6.28.

I'm obviously interested in an upstream kernel  stable in all normal peripherals, I mean spi,i2c,dss,serials,usb host,usb otg,ethernet,audio and so on.

Dual display in this moment is not mandatory for me, but Apple Store usb to ethernet interface is obviously extremely important, so it has to work with 2.6.26 ti kernel.

I'm trying to come to ESC, but only with a miracle I'll be albe to come.

Thx

Then I'll read the kernel roadmap, I promise.

The hardware has three source paths, one is graphics and two are video. The graphics path can convert from indexed color to RGB and the video paths can convert from YUV to RGB. Additionally both path types support RGB frame buffers.

The video paths both have scalers but the graphics path does not.

Now, these three paths can point to anywhere in memory, so they could be the same frame buffers, completely different buffers or even parts of the same buffers (i.e. a clipped region of a buffer).

There are two possible outputs, the LCD output and the TV output. Each of the source paths can only feed one of the outputs, but it can be either. This means that you can have the graphics path feeding the LCD output and a video path feeding the TV output. The other video path can be used to overlay on EITHER the LCD output or the TV output but not both at the same time.

Given that the frame buffer pointers can point to anywhere in memory it is possible then to have a single frame buffer output on the LCD and also scaled down for the TV output.

Another example is if the video pipe1 is used to feed the LCD output and the video pipe2 is used to feed the TV output then the frame buffer could contain one resolution but the LCD and TV outputs can have yet independently different scaled outputs.

I do not know how well this flexibility is supported in the Linux code at the moment, but I believe that the upcomming DSS2 framework will make this much simpler to configure.

I have some slides which detail the hardware capabilities but can't upload them to the forum. In the meantime please feel free to e-mail me at sclynes@ti.com and I will send them to you.

Kind regards,

Steve

OK, here are the slides [:)]

Kind regards,

Steve

Where is the image stored after overlay?

For example, if both video pipe 1 and graphics pipe connect to overlay manager 1 and then output to LCD, can we have the same image output to TV as well ?

The resultant output is not stored anywhere but is constructed on the fly as necessary.

If you are blending any of the frame buffers then you will only be able to send the resultant display to one destination.

There are three possible source processing pipes. Each processing pipe can only go to one of either the TV output or the digital output.

Please have a look at the following Wiki page which has more detailed information on the possible combinations and limitations.

http://wiki.omap.com/index.php/Display_Subsystem

BR,

Steve

Thanks for the replying.

How about rotation? Suppose we have one frame buffer but outputing to both LCD and TV. The one to LCD, it requires VRBF rotation; but the one to TV, it does not need rotation but scaling. Will that work in this DSS system?

What is the actual resolution of the LCD you want to use?

What orientation do you want the LCD to be configured in (portrait or landscape)?

If rotation is enabled then it is possible to have different memory views of the frame buffer with different rotations, with one "window" being 0 rotation.

BR,

Steve

We want to have the LCD display in landscape (640x480). There will be a 90 degree rotation. However, the TV output (720x480) does not need rotation.

It looks like the video pipe supports scaling. Therefore, I am thinking to scale up from (640x480) to (720x480) if it is possible.

Thanks,

Alvin

Alvin,

Are you using the LCD on the EVM, which is actually a 480x640 LCD, or do you have a different LCD in mind?

For the TV out I recommend not scaling up to 720 since most if not all TVs do what is called overscan. If you completely fill the 720x480 output then you will find that there is about 10% border on the TV which you can't actually see.

If you truly do want to fill the 720x480 then yes, you can use a scaler on the video pipe to do this.

BR,

Steve

Steve,

Thanks for the advice. Currently, my tests are on OMAP3 EVM, but eventually, the LCD will be replaced by another one with QVGA resolution.

So far, the output to the LCD seems correct. But still cannot get the right output on TV. Try to use the clone example as below. The first problem is, it only works on /dev/fb1, but not on /dev/fb0. The second one is about the rotation. Both outputs to LCD and to TV are rotated. We don't want the output to TV being rotated. I am not sure whether this is possible to so : one is roated, and the other one is not. Is it a hardware limitation or becuase of software? Appreciated for your information.

Best regards,

Alvin

Clone GFX overlay to LCD and TV
-------------------------------

tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
w=`echo $tvline | cut -d " " -f 5 | cut -d ":" -f 2 | cut -d "/" -f 1`
h=`echo $tvline | cut -d " " -f 6 | cut -d ":" -f 2 | cut -d "/" -f 1`

echo "1 t:none" > omapfb/framebuffers
echo "0 t:gfx,vid1" > omapfb/framebuffers
echo "gfx e:1" > omapfb/overlays
echo "vid1 t:tv w:$w h:$h e:1" > omapfb/overlays
echo "tv e:1" > omapfb/displays

After this the configuration looks like (only relevant parts shown):

FB0 +-- GFX  ---- LCD ---- LCD
     \- VID1 ---- TV  ---- TV

Unfortunately I can't comment too much from the software side since I am more a hardware person.

I do believe this is a software limitation though. The hardware should be able to do this.

BR,

Steve