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@xxxxxxxxxxxxxx> wrote:
> On Tue, Mar 1, 2011 at 09:25, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
>> On Thu, Feb 24, 2011 at 3:05 PM, Geert Uytterhoeven
>> <geert@xxxxxxxxxxxxxx> wrote:
>>> On Thu, Feb 24, 2011 at 00:28, Magnus Damm <magnus.damm@xxxxxxxxx> 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@xxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> On Tue, Mar 1, 2011 at 09:25, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
>> On Thu, Feb 24, 2011 at 3:05 PM, Geert Uytterhoeven
>> <geert@xxxxxxxxxxxxxx> wrote:
>>> On Thu, Feb 24, 2011 at 00:28, Magnus Damm <magnus.damm@xxxxxxxxx> 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@xxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
