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

[Corbin Simpson]

I am slightly curious about this as well; I have a device with only YUV
scanout and was considering KMS, but don't know what the best approach is.

At least one KMS driver, nouveau, has to wrap all accesses to its scanout
buffers on certain chipsets for tiling reasons, so the same strategy might
work.

Sending from a mobile, pardon the brevity. ~ C.
On Mar 1, 2011 12:22 PM, "Geert Uytterhoeven" <geert at linux-m68k.org> wrote:
> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110301/ced251ce/attachment.htm>