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) <redacted>
Cc: linuxppc-dev@lists.linuxppc.org <redacted>
Date: Tuesday, January 04, 2000 6:09 PM
Subject: Re: Question about the video device driver
On Tue, 4 Jan 2000, Shuangjun Zhu wrote:
quoted
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/
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 [off-list ref].
-----Original Message-----
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Shuangjun Zhu (r44089) <redacted>
Cc: linuxppc-dev@lists.linuxppc.org <redacted>
Date: Tuesday, January 04, 2000 6:09 PM
Subject: Re: Question about the video device driver
quoted
On Tue, 4 Jan 2000, Shuangjun Zhu wrote:
quoted
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/
On Fri, 7 Jan 2000, Geert Uytterhoeven wrote:
On Fri, 7 Jan 2000, Shuangjun Zhu wrote:
quoted
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/
I guess I must have been sleeping when this went around the first time.....
quoted
On Fri, 7 Jan 2000, Shuangjun Zhu wrote:
quoted
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/