Ville Syrjälä wrote:
By the way is BT.656 data RGB or YUV? My data is RGB and I need to avoid
all conversions (probably I will use scart RGB for that reason).
It's YUV. I'm not entirely sure why since AFAIK BT.656 supports RGB data
as well. It may be due to the funky loopback from the the CRTC2 output to
the video grabber on G400. The grabber understands YUV only.
Does DirectFb currently let it is used as RGB? does GRAPHICS capability
of layers CRTC2 and 03 CRTC2 Sub-Picture mean this?
I guess it depends on the dot pitch of the mask. On my normal TV the
horizontal dot pitch approximately matches the normal 720 resolution
(minus overscan of course) so feeding it more pixels is pretty much
pointless. Anyone know if the mask in wide screen TVs generally match some
more accurate resolution? The 18 MHz pixel clock 960x576 and 960x480
variants are at least specified in some standard (ITU-R BT.601?)...
You are very right about this.
Anyway it would involve mucking around with the maven registers. It would
be nice to have signal analyzing equiment for that...
I will try to generate some test patterns to show the resolution of the
TV used. Cheaper than signal analyser, kind a works ;-))
This is important functionality but I already collect data in exact
resolution of PAL active lines. It is a pitty that CRTC1 cannot drive
TVout at G450/G550. Matroxfb driver writer known to mention a
possibility to duplicate a small (upto 1023x625) framebuffer from CRTC1
to CRTC2 requiring extra code in kernel.
It would just involve pointing CRTC2 at the same memory location as CRTC1.
That way you could have the same output on both heads and you could run
the primary monitor at a higher refresh rate. It would be the same thing
as using the same surface for two layers in DirectFB.
Can DirectFB keep primary display active during TVout???? mplayer -vo
dfbmga doesn't!
Which makes more sense do you think:
- Adding functionality to DirectFB allowing a surface can be used for
more than one layers.
- Adding support to kernel/matroxfb that both CRTC's can use the same
system/video memory and export this to an ioctl that DirectFB can set.
There is a comment about planar textures in the G400 specs but I
don't really know what it means since I don't see any way to actually
tell the hardware that a texture is planar.
It can well be that planar textures are blended on the fly
as A8's that you don't even need to tell hardware about it.
I don't know what you mean by that.
We can think that each RGB plane is residing as an alpha/mono 8 bit
framebuffer. If we can colorize each of those buffers with corresponding
RGB colors and blend them together on a layer, we are supposed to end up
with something like RGB24/32 as the view. So you may not need to say
anything about those 'planes' to the hardware. They can stay as RGB
'alphas'.
I really need to access some 'developer documentation' at least of G400.
I had no chance about matrox developer connection, which is gone by now.
Can anybody or place have the once open G400 specs? or any documentation
about reverse engineered G450/G550 internals?
thanks a lot,
Cagdas
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
