On Tue, Mar 1, 2011 at 09:25, Magnus Damm magnus.damm@gmail.com wrote:
On Thu, Feb 24, 2011 at 3:05 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
On Thu, Feb 24, 2011 at 00:28, Magnus Damm magnus.damm@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@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
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@linux-m68k.org wrote:
On Tue, Mar 1, 2011 at 09:25, Magnus Damm magnus.damm@gmail.com wrote:
On Thu, Feb 24, 2011 at 3:05 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
On Thu, Feb 24, 2011 at 00:28, Magnus Damm magnus.damm@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@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 1 Mar 2011 13:31:19 -0800 Corbin Simpson mostawesomedude@gmail.com wrote:
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.
The problem with hiding behind a fake RGB frame buffer is you've then completely stuffed any framebuffer based apps that could use YUV happily (eg framebuffer video playback).
Far better to make the kernel tell the truth in these cases. You'll need to add some tweaks to the fb code for it and a YUV boot penguin.[1]
If you want to run X on it then you can use shadowfb on the X side to do your YUV/RGB adaptation.
Alan -- [1] Am I the only one who thinks the fb code also needs an imagine of an embarassed penguin that has wet itself to go with oops output ?
dri-devel@lists.freedesktop.org
-
Alan Cox -
Corbin Simpson -
Geert Uytterhoeven