On Fri, Oct 21, 2005 at 03:38:30PM +0200, Cagdas Ogut wrote: > > Ville Syrjälä wrote: > >On Wed, Oct 19, 2005 at 04:53:21PM +0200, Cagdas Ogut wrote: > > > >With DirectFB controlling the TV-out the resolution is fixed 720x576 > >or 720x480 so if you want to maintain the correct aspect ratio you > >need to downscale horixontally. > > I noticed that this resolution is hardcoded. Is there any particular > reason? I wished this size could had been configurable.
The reason is that I dumped the Maven registers in Windows and that's what was used there. > >Another way to display the same stuff on both heads would be to use > >just one CRTC and send the data to both outputs. But that won't work > >with DirectFB since we program CRTC2 to output BT.656 data that the > >DAC doesn't understand. matroxfb doesn't use BT.656 mode so it might > >actually work with matroxfb controlling the TV-out. I'm not sure if > >matroxfb actually lets you do this on G450/G550 but on G400 it works. > >On G450/G550 only CRTC2 can drive the TV-out whereas on G400 either > >CRTC can drive the TV-output. Either CRTC can drive the primary DAC > >on both chip types. > > I tried to clone CRTC1 to secondary output but didn't work at G450. > Querying output was still showing PAL but it was outputing 'monitor'. As I said only CRTC2 can drive the TV encoder on G450/G550. > Later I tried attaching CRTC2 to both outputs but primary display had > very weird blue pattern only (TVout was ok with con2fb). It would be > a great solution to use CRTC2 for TVout and primary display at the same > time. I think that should work. But your parimary display must be able to handle the TV-out timings. > Can I set the refresh rates of both outputs same at G450? or at G400? > > 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. > >If you want to stick with DirectFB controlling the TV-out you could > >convert the planar data to packed and write it to the CRTC1 layer's > >surface. Then you could StretchBlit() it to the CRTC2 layer's > >surface. > > It would be opposite of stretching (compressing 768-704). StretchBlit() can scale to any direction.. > Instead of > computational scalling TVout DAC can trace faster and all the pixels can > be used for maximum quality. That's why I want to change hardcoded 720 > to 768 or better make it adjustable. 1023x576 would be very crisp on > widescreen TV. 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?)... Anyway it would involve mucking around with the maven registers. It would be nice to have signal analyzing equiment for that... > >AFAIK matroxfb does support changing the horizontal resolution on the > > TV-out of G450/G550 since it's just a matter of changing the timing. > > Vertical resolution can't be changed so freely. > > I had the same impression from matroxset/fbset etc. > > >The TV-out component of G400 is more capable it's G450/G550 > >counterpart. The main difference is the hardware scaler which is > >present on the G400 and missing from G450/G550. So you can display > >arbitrary resolutions on the G400 TV-out. > > 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. > If I could had documentation I > would go for adding this. I guess wind0w$ driver does this somehow. > > >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. -- 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
