[PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support

[Geert Uytterhoeven]

On Tue, Mar 1, 2011 at 09:25, Magnus Damm <magnus.damm at gmail.com> wrote:
> On Thu, Feb 24, 2011 at 3:05 PM, Geert Uytterhoeven
> <geert at linux-m68k.org> wrote:
>> On Thu, Feb 24, 2011 at 00:28, Magnus Damm <magnus.damm at gmail.com> wrote:
>>> Please ditch the SH_FB_YUV constant all together. No need to build
>>> some abstraction on top of a hackish interface. Just check if nonstd
>>> is non-zero in the driver and assume that means YUV for now. That's
>>> good enough.
>>
>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new FB_VISUAL_*
>> type instead, which indicates the fb_var_screeninfo.{red,green,blue} fields are
>> YCbCr instead of RGB.
>> Depending on the frame buffer organization, you also need new FB_TYPE_*/FB_AUX_*
>> types.
>
> I'm all for extending the common code instead of hiding code in
> drivers. But I wonder how much overlap there is with V4L2 for
> instance. I remember adding support for some NVxx formats for V4L2
> some years ago. It's mainly used for Video input on Renesas SoCs
> though:
>
> http://kerneltrap.org/mailarchive/git-commits-head/2008/12/31/4560474
>
> So I was hoping that something like the above could be added to fbdev
> too, but it looks like more code is needed.
>
> Do you have any idea on how to tie in the valid range of each color
> channel? The LCDC hardware block can select between 0->255 range or
> 16->235/240 for the YUV channels. In V4L2 this is handled by
> v4l2_colorspace, the 0->255 maps directly to V4L2_COLORSPACE_JPEG.

Unfortunately not. Unlike for the YCbCr visual, I don't see a field we
can easily
(ab)use for that. Except if it's limited to standard 16-235/240 Y vs.
full 0-255 Y,
for which we could just have 2 different visual types.

> And how does all this relate to KMS? I'd prefer to keep this code in
> one place if possible.

Good question!

I'm still puzzled about this KMS thing. If the name "Kernel Mode Setting"
covers it, then how does it compare to plain fbdev? Just additional frame buffer
memory management?

Furthermore, everybody states that "future X/desktop" will require KMS drivers.
How do/will we handle this on dumb frame buffers? It's not like we can't do
"advanced" things like compositing using the CPU. Transparency may stretch
it a bit on lower end CPUs, but you don't always need that.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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