On Fri, Oct 21, 2005 at 07:15:00PM +0200, Cagdas Ogut wrote: > > 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?
No. DirectFB is hardcoded to use YUV BT.656 mode. The RGB output mode of CRTC2 isn't BT.656 compatible. The sub-picture layer works only when CRTC2 is configured for planar YUV. > >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! Actually it does but DirectFB takes control of both heads so you must run a DirectFB app on the primary head too. I always use XDirectFB on the primary head and watch videos on the TV. > Which makes more sense do you think: > > - Adding functionality to DirectFB allowing a surface can be used for > more than one layers. This would be nice. But it would need some thought as to what's the best approach. Maybe surface allocation should be delayed until IDirectFBDisplayLayer::GetSurface() is called. That way only the "master" layer would do a GetSurface() and the other would do SetSurface() or something like that. Or maybe the surface could be created with CreateSurface() and all layers would do SetSurface(). Also it would have to check that the layers have a compatible configuration. > - Adding support to kernel/matroxfb that both CRTC's can use the same > system/video memory Should be rather easy to add. > and export this to an ioctl that DirectFB can set. I don't think I controlling this from DirectFB makes much sense without proper multihead support. > >>>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'. So you want to convert the planar texture to packed with a multi-pass algorithm handling one plane at a time? Sounds really complicated and it wastes a lot of mmeory. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
