OVERLAY2 outside LCD driver

Hello,
Since the PXA BSP I have does not support overlay2 or DD in the LCD
driver, and sources are not provided to even add overlay2 and DD into
driver, the decision was to implement, as proof of concept, overlay2
support outside the LCD driver plotting directly to FB. We don't care
about seeing the base plane, just the camera thru Overlay2 in
fullscreen.
Doing so, everything works fine, since the YCbCr camera we're using
plots on an overlay2 and is visible. But the issue we're having is
that when overlay2 is used with YCbCr 4:2:2, we're getting a greenish
screen with/behind my image.

I read that Overlay2 is not transparent in YCbCr format, so it can't
be that the green is coming from base plane since 565 is now 555. So
it is that 4:2:2 is now RGB 8:8:8? Any suggestions where this green is
coming from and how to fix it?

Thanks

Valter
Wed Mar 26 09:15:16 PDT 2008

SchumiImor@gmail.com wrote in
news:6f84210f-5dcd-4838-ae2c-076b5871bb94@n58g2000hsf.googlegroups.co
m:

> Hello,
> Since the PXA BSP I have does not support overlay2 or DD in the
> LCD
> driver, and sources are not provided to even add overlay2 and DD
> into driver, the decision was to implement, as proof of concept,
> overlay2 support outside the LCD driver plotting directly to FB.
> We don't care about seeing the base plane, just the camera thru
> Overlay2 in fullscreen.
> Doing so, everything works fine, since the YCbCr camera we're
> using plots on an overlay2 and is visible. But the issue we're
> having is that when overlay2 is used with YCbCr 4:2:2, we're
> getting a greenish screen with/behind my image.
>
> I read that Overlay2 is not transparent in YCbCr format, so it
> can't be that the green is coming from base plane since 565 is now
> 555. So it is that 4:2:2 is now RGB 8:8:8? Any suggestions where
> this green is coming from and how to fix it?

To use the overlay2 in YUV422 mode on the PXA you will have to force
the base frame at RGB 555 and not 565, you can do that by changing the
pixel masks used inside the driver provided with the BSP.
You should find assignment of R,G and B "masks" inside the driver
initialization code.
I think that the "greenish" tone depends on the fact that the previous
green most significant bit is used as red LSB. This will result in
some fancy color effects.
IIRC the mainstone II display driver provided some support for
enabling/disabling OV2 even if it was not very reliable...


--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

3rware
Wed Mar 26 10:24:40 PDT 2008

On Mar 26, 12:15 pm, Valter Minute
<v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
> SchumiI...@gmail.com wrote innews:6f84210f-5dcd-4838-ae2c-076b5871bb94@n58g2000hsf.googlegroups.co
> m:
>
>
>
> > Hello,
> > Since the PXA BSP I have does not support overlay2 or DD in the
> > LCD
> > driver, and sources are not provided to even add overlay2 and DD
> > into driver, the decision was to implement, as proof of concept,
> > overlay2 support outside the LCD driver plotting directly to FB.
> > We don't care about seeing the base plane, just the camera thru
> > Overlay2 in fullscreen.
> > Doing so, everything works fine, since the YCbCr camera we're
> > using plots on an overlay2 and is visible. But the issue we're
> > having is that when overlay2 is used with YCbCr 4:2:2, we're
> > getting a greenish screen with/behind my image.
>
> > I read that Overlay2 is not transparent in YCbCr format, so it
> > can't be that the green is coming from base plane since 565 is now
> > 555. So it is that 4:2:2 is now RGB 8:8:8? Any suggestions where
> > this green is coming from and how to fix it?
>
> To use the overlay2 in YUV422 mode on the PXA you will have to force
> the base frame at RGB 555 and not 565, you can do that by changing the
> pixel masks used inside the driver provided with the BSP.
> You should find assignment of R,G and B "masks" inside the driver
> initialization code.
> I think that the "greenish" tone depends on the fact that the previous
> green most significant bit is used as red LSB. This will result in
> some fancy color effects.
> IIRC the mainstone II display driver provided some support for
> enabling/disabling OV2 even if it was not very reliable...
>
> --
> Valter Minutewww.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)

Thanks, thought so, but since the driver is provided to us as binary,
is there a way to change that from outside the driver? or directly
onto the FB? I saw some code in the Zylonite BBU code that goes
directly into the base frame and shifts pixel bits around, but I don't
understand how this will last if done only once, shouldn't it be done
for every frame?

Thanks

Valter
Wed Mar 26 10:34:28 PDT 2008

3rware@gmail.com wrote in
news:5ffaa909-f3c7-476a-97c0-55d8d692ebe1@e60g2000hsh.googlegroups.co
m:

[...]
> Thanks, thought so, but since the driver is provided to us as
> binary, is there a way to change that from outside the driver?

AFAIK there's no way to change this from the outside, at least on the
original BSPs.
Did you check if the driver's registry settings allow you to setup a
mask for RGB channels?
I suspect that the RGB 565 encoding is hard-coded inside the driver.

You may try to replace it with the one provided inside the mainstone
III BSP in CE (5 or 6?) or re-write your own GPE based driver (the PXA
display controller does not provide hardware acceleration etc, so you
shouldn't see huge performance issues).

> or
> directly onto the FB? I saw some code in the Zylonite BBU code
> that goes directly into the base frame and shifts pixel bits
> around, but I don't understand how this will last if done only
> once, shouldn't it be done for every frame?

You can't shift pixels at such an high rate, or, at least you can't do
that and use your CPU to do something useful at the same time...

--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)