[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: vesa display codes (Etch Xorg memory leak?)



On Tue, 2007-05-22 at 09:33 +0300, Andrei Popescu wrote:
> On Mon, May 21, 2007 at 07:44:14PM -0500, Owen Heisler wrote:
> > Anyway, I tried some other video= lines and nothing makes any
> > difference.  I tried vesafb, rivafb, and nvidiafb for the driver and
> > both 1024x768 (vga=791 works fine) and 1280x960 for the resolution (all
> > combinations for rivafb and nvidiafb, not vesafb:1024x768 I think).  I
> > don't know if it is relevant, but once the system is booted, I can load
> > a nvidiafb module, but not either of vesafb and rivafb.
> 
> That's normal. vesafb is compiled in (not a module) and rivafb is not 
> compiled at all.

Okay

> > Like I said, this isn't really a problem; if I just need to make a
> > custom kernel, I'll drop it for now and maybe later... sometime...
> 
> Here is what I would try:
> 
> 1. A simple vga=  to the kernel (vga=791 should give 1024x764-16bpp). If 
> this works you only need to find the correct parameter to get the right 
> resolution (though it is already better than 640x480).

There doesn't seem to be a correct vga= parameter for 1280x960.

> 2. Find out what the correct driver for your video card is. AFAIR rivafb 
> is only for *very* old cards. The newer ones should work with the 
> nvidiafb.

Mine is not old, so nvidiafb should be correct.

> 3. Put nvidiafb in your initrd and boot with the correct 
> video=nvidiafb:... option. You must google for the exact parameters to 
> pass as they might be different from other drivers.

I've tried video=nvidiafb:1280x960 and I seem to just get the default
resolution.  So I need a full framebuffer mode line, I guess.  In order
to figure out what I need to use, I need this information (as provided
by XFree86):
Modeline  "1280x960" DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
see http://www.linux.com/howtos/Framebuffer-HOWTO-18.shtml (old)

> 1. with the correct parameter might be enough, but if it doesn't work or 
> doesn't give the desired resolution you might experiment with 2. and 3.  
> None of them involves kernel compilation.

3 it is.

Thanks

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: