Re: Question about the video device driver

Re: Question about the video device driver

[Shuangjun Zhu]

The video of MPC823 FADS board only support YCbYCr mode,
so how can I write a device driver for the video of MPC823 FADS board,
to enable the X?

Any suggestion? 
Thanks in advanced.

-----Original Message-----
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Shuangjun Zhu (r44089) <r44089@email.sps.mot.com>
Cc: linuxppc-dev@lists.linuxppc.org <linuxppc-dev@lists.linuxppc.org>
Date: Tuesday, January 04, 2000 6:09 PM
Subject: Re: Question about the video device driver


>
>On Tue, 4 Jan 2000, Shuangjun Zhu wrote:
>> If the data format in the video memory is CbYCrY,
>> the above layer application like Xserver can handle this?
>
>XFree86 doesn't do YCbCr.
>
>Gr{oetje,eeting}s,
>--
>Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org
>
>In personal conversations with technical people, I call myself a hacker. But
>when I'm talking to journalists I just say "programmer" or something like that.
>     -- Linus Torvalds
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Question about the video device driver

[Geert Uytterhoeven]

On Fri, 7 Jan 2000, Shuangjun Zhu wrote:
> The video of MPC823 FADS board only support YCbYCr mode,
> so how can I write a device driver for the video of MPC823 FADS board,
> to enable the X?
> 
> Any suggestion? 
> Thanks in advanced.

This sounds like an interesting project.

How many bits per pixel are available? If it's not too much you can create a
staticcolor visual and consider it to be a simple paletted video mode (with a
static palette). However, IIRC, XFree86 doesn't support staticcolor hardware,
but support for that is probably closer than support for YCbCr.

I see you write YCbYCr? So the color components are subsampled like digital
broadcast video? In that case things become more complex because of the
different resolutions for the luminance and chrominance channels.

All this combined, I think the best solution is to use the virtual frame buffer
feature of XFree86 3.9.x (draw in a piece of memory as large as the screen) and
update the screen image by converting the changed parts from RGB to YCbYCr.

Does the MPC823 FADS have accelerated graphics? Accelerated RGB to YCbYCr
conversion?

I'm moving the discussion to XFree86 Devel <devel@XFree86.Org>.

> -----Original Message-----
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> To: Shuangjun Zhu (r44089) <r44089@email.sps.mot.com>
> Cc: linuxppc-dev@lists.linuxppc.org <linuxppc-dev@lists.linuxppc.org>
> Date: Tuesday, January 04, 2000 6:09 PM
> Subject: Re: Question about the video device driver
> 
> 
> >
> >On Tue, 4 Jan 2000, Shuangjun Zhu wrote:
> >> If the data format in the video memory is CbYCrY,
> >> the above layer application like Xserver can handle this?
> >
> >XFree86 doesn't do YCbCr.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Question about the video device driver

[Mark Vojkovich]

On Fri, 7 Jan 2000, Geert Uytterhoeven wrote:

> On Fri, 7 Jan 2000, Shuangjun Zhu wrote:
> > The video of MPC823 FADS board only support YCbYCr mode,
> > so how can I write a device driver for the video of MPC823 FADS board,
> > to enable the X?
> > 
> > Any suggestion? 
> > Thanks in advanced.
> 
> This sounds like an interesting project.
> 
> How many bits per pixel are available? If it's not too much you can create a
> staticcolor visual and consider it to be a simple paletted video mode (with a
> static palette). However, IIRC, XFree86 doesn't support staticcolor hardware,
> but support for that is probably closer than support for YCbCr.

   We support static color visuals just fine.  But there will be
a problem if the hardware doesn't have a macroblock size of 1x1.
It's required that you can get read the data back without losing
information.  If you are sharing chroma between pixels that's
not going to work.

> 
> I see you write YCbYCr? So the color components are subsampled like digital
> broadcast video? In that case things become more complex because of the
> different resolutions for the luminance and chrominance channels.
> 
> All this combined, I think the best solution is to use the virtual frame buffer
> feature of XFree86 3.9.x (draw in a piece of memory as large as the screen) and
> update the screen image by converting the changed parts from RGB to YCbYCr.

   Yes, shadowfb should work fine for this if the hardware can do the
conversion from RGB data stored in system memory.


				Mark.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Question about the video device driver

[Shuangjun Zhu]

I'm a newbie in the X domain,
where can I get the information about showfb?
As I know, there is no hardware for MPC823 FADS that can do the
conversion from RGB data stored in system memory,
we must do it using software.

So, where I should start?
Any suggestion?

>
>On Fri, 7 Jan 2000, Geert Uytterhoeven wrote:
>
>> On Fri, 7 Jan 2000, Shuangjun Zhu wrote:
>> > The video of MPC823 FADS board only support YCbYCr mode,
>> > so how can I write a device driver for the video of MPC823 FADS board,
>> > to enable the X?
>> > 
>> > Any suggestion? 
>> > Thanks in advanced.
>> 
>> This sounds like an interesting project.
>> 
>> How many bits per pixel are available? If it's not too much you can create a
>> staticcolor visual and consider it to be a simple paletted video mode (with a
>> static palette). However, IIRC, XFree86 doesn't support staticcolor hardware,
>> but support for that is probably closer than support for YCbCr.
>
>   We support static color visuals just fine.  But there will be
>a problem if the hardware doesn't have a macroblock size of 1x1.
>It's required that you can get read the data back without losing
>information.  If you are sharing chroma between pixels that's
>not going to work.
>
>> 
>> I see you write YCbYCr? So the color components are subsampled like digital
>> broadcast video? In that case things become more complex because of the
>> different resolutions for the luminance and chrominance channels.
>> 
>> All this combined, I think the best solution is to use the virtual frame buffer
>> feature of XFree86 3.9.x (draw in a piece of memory as large as the screen) and
>> update the screen image by converting the changed parts from RGB to YCbYCr.
>
>   Yes, shadowfb should work fine for this if the hardware can do the
>conversion from RGB data stored in system memory.
>


>
> Mark.
>
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Question about the video device driver

[Mark Vojkovich]

On Mon, 10 Jan 2000, Shuangjun Zhu wrote:

> I'm a newbie in the X domain,
> where can I get the information about showfb?
> As I know, there is no hardware for MPC823 FADS that can do the
> conversion from RGB data stored in system memory,
> we must do it using software.
> 
> So, where I should start?
> Any suggestion?


   Shadowfb is a "layer" (using the X terminology) which 
is initialized after framebuffer rendering is setup.  It
is given a callback function when initialized.

typedef void (*RefreshAreaFuncPtr)(ScrnInfoPtr, int, BoxPtr);

Bool
ShadowFBInit (
    ScreenPtr           pScreen,
    RefreshAreaFuncPtr  refreshArea
);

  The shadowfb encapsulates all rendering into that buffer
and gives the driver a callback telling it which rectangles
of the buffer have been updated.

   What can be done is that one can setup a framebuffer in 
system memory and get callbacks telling which parts need to
be copied into the real hardware framebuffer, hence the
name - you have a buffer and its shadow.   It is safe to
copy areas larger than the rectangles you are told to update.
That way you can reduce your refreshArea function to copying
and translating only macroblocks.

   There are examples in some other drivers such as the
glide driver which uses it on a write-only framebuffer or
the MGA driver which uses it for effects like rotating
the screen.

   What format is the hardware buffer in?  What macroblock
size?
 

			Mark.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Question about the video device driver

[Shuangjun Zhu]

>
>
>On Mon, 10 Jan 2000, Shuangjun Zhu wrote:
>
>> I'm a newbie in the X domain,
>> where can I get the information about showfb?
>> As I know, there is no hardware for MPC823 FADS that can do the
>> conversion from RGB data stored in system memory,
>> we must do it using software.
>> 
>> So, where I should start?
>> Any suggestion?
>
>
>   Shadowfb is a "layer" (using the X terminology) which 
>is initialized after framebuffer rendering is setup.  It
>is given a callback function when initialized.
>
>typedef void (*RefreshAreaFuncPtr)(ScrnInfoPtr, int, BoxPtr);
>
>Bool
>ShadowFBInit (
>    ScreenPtr           pScreen,
>    RefreshAreaFuncPtr  refreshArea
>);
>
>  The shadowfb encapsulates all rendering into that buffer
>and gives the driver a callback telling it which rectangles
>of the buffer have been updated.
>
>   What can be done is that one can setup a framebuffer in 
>system memory and get callbacks telling which parts need to
>be copied into the real hardware framebuffer, hence the
>name - you have a buffer and its shadow.   It is safe to
>copy areas larger than the rectangles you are told to update.
>That way you can reduce your refreshArea function to copying
>and translating only macroblocks.
>
>   There are examples in some other drivers such as the
>glide driver which uses it on a write-only framebuffer or
>the MGA driver which uses it for effects like rotating
>the screen.
>
>   What format is the hardware buffer in?  What macroblock
>size?
> 


For the MPC823 FADS board, video controller is in the CPM, part of 
the CPU, and video encoder is ADV7176, video memory is map to 
the system memory.  It can support NTSC/PAL display.

MPC823 can support RGB and YCr Cb, but for Analog Devices ADV7176
video encoder,  it can only support 4:2:2 YCr Cb(CCIR 601) format.

I do not know what the macroblock's meaning is.

>
> Mark.
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Question about the video device driver

[Mark Vojkovich]

On Mon, 10 Jan 2000, Shuangjun Zhu wrote:

> >   What format is the hardware buffer in?  What macroblock
> >size?
> > 
> 
> 
> For the MPC823 FADS board, video controller is in the CPM, part of 
> the CPU, and video encoder is ADV7176, video memory is map to 
> the system memory.  It can support NTSC/PAL display.
> 
> MPC823 can support RGB and YCr Cb, but for Analog Devices ADV7176
> video encoder,  it can only support 4:2:2 YCr Cb(CCIR 601) format.
> 
> I do not know what the macroblock's meaning is.
> 

  I meant the Cr and Cb sampling intervals.  It's 4:2:2 so it's
2x1 pixel blocks.  That means you have to do some sort of
shadowfb method since X requires that you can read back
the data without loss.  If there were Cb and Cr samples for each
luma, then you could have used a StaticColor visual and rendered
directly into the framebuffer.  StaticColor is like pseudocolor
but with a fixed lookup table.


			Mark.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Question about the video device driver

[Dan Malek]

I guess I must have been sleeping when this went around the first time.....


> > On Fri, 7 Jan 2000, Shuangjun Zhu wrote:
> > > The video of MPC823 FADS board only support YCbYCr mode,


Really?  Why is that?  The 823 supports an 8-bit index into a 12-bit
colormap for LCD panels.  Why wouldn't the FADS support this?

Yes, it also supports RGB, and CCIR-601 (4:4:4 and 4:2:2) with NTSC/PAL
resolution through the CCIR-656 port.  It seems the LCD panel would
be easier to support with X......and if you are really working on
that, let me know :-).



	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/