mike lewis wrote: > On 1/13/07, mike lewis <[EMAIL PROTECTED]> wrote: >> On 1/13/07, Duncan Webb <[EMAIL PROTECTED]> wrote: >>> Lucian Muresan wrote: >>>> Jason Tackaberry wrote: >>>>> On Fri, 2007-01-12 at 23:31 +0800, mike lewis wrote: >>>>>> Before I go off to bed I just have to say that I figured out what the >>>>>> issue was. vidix wasn't detecting the RAm size of my card. So I hard >>>>>> coded the RAM size (from 16 to 32) and now there is not more artifacts >>>>>> on the screen. >>>>> Where did you hardcode this? >>>> I think the proper way is not to hardcode it, but to apply the so-called >>>> "matroxfb-full-memory" kernel patch. Another useful patch might be the >>>> one called "matroxfb-g400-clock", I don't know why they haven't made it >>>> into the kernel for such a long time. You can find older versions of >>>> them in the 'patches' directory of the DirectFB source, and I guess they >>>> apply to recent kernels too, or you can easily adapt them by hand. If >>>> you prefer, you can use mine attached in this message, already adapted >>>> for 2.6.18 (should also apply to 2.6.19), the one called >>>> linux-2.6.18_matroxfb-address-ioctl_v3.diff is necessary for newer >>>> versions of DirectFB. >>> I wouldn't use the "matroxfb-g400-clock" patch, Villi recommended to use >>> it and I tried it recently and it fucked up the driver big time. May be >>> it depends on the card a bit, mines a DH with sdram. >>> >>> The "matroxfb-full-memory" is good though. >>> >> Hmm, Not sure about this one.. I'm not useing FB just mga_vid under X?? >> > I just had another look at mga_vid.c in under vidix and I still can't > work out how they are working out the RAM size. But I'm sure these > two feature (matroxfb and mga_vid) are not one in the same...
All depends if the mga_vid driver sits on top of the framebuffer or access the hardware directly. If it sits on the framebuffer then the full memory patch should make a difference. Having said this a quick look at the code and it seems that mga_vid access the hardware directly. From my configuration I see: # dmesg | grep mga mga_vid: Found MGA G400/G450 at 0000:01:00.0 mga_vid: MMIO at 0xe39e0000 framebuffer: 0xF6000000 mga_vid: OPTION word: 0x40040120 mem: 0x00 SDRAM mga_vid: detected RAMSIZE is 16 MB mga_vid: 1 supported cards found mga_vid: using major: 83 (assigned or default!) So it would seem that my card has 16MB of SDRAM. which is a bit strange as the memory chips are SGRAM. This has determined by the PCI config of the card. May be updating the card's firmware changed this. The size can be overridden by the modprobe options: # modinfo mga_vid filename: /lib/modules/2.6.18.5-hawk-r1/extra/mga_vid.ko author: Aaron Holtzman <[EMAIL PROTECTED]> license: GPL parmtype: mga_ram_size:array of int parmtype: mga_top_reserved:array of int parmtype: mga_brightness:array of int parmtype: mga_contrast:array of int parmtype: major:int vermagic: 2.6.18.5-hawk-r1 preempt mod_unload PENTIUMIII gcc-3.4 depends: I think that a: modprobe mga_vid mga_ram_size=32 should do the trick then I see: mga_vid: Found MGA G400/G450 at 0000:01:00.0 mga_vid: MMIO at 0xe39e0000 framebuffer: 0xF6000000 mga_vid: OPTION word: 0x40040120 mem: 0x00 SDRAM mga_vid: RAMSIZE forced to 32 MB mga_vid: 1 supported cards found mga_vid: using major: 83 (assigned or default!) HTH Duncan ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
