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

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



On Sun, May 20, 2007 at 12:01:18PM EDT, Greg Folkert wrote:

[..}

> Mind if I add snippets of you two posts to Owen to that Vesa Mode Page?

Not in principle naturally. 

Just that I'd be a little concerned about the contents of my posts
possibly misleading others ..  A clear case of I don't understand it
well enough to explain it .. to paraphrase A.  Einstein, I think. 

I wish I had more solid knowledge of these aspects.

Obviously, since I have not one but two systems that work flawlessly
with the atyfb driver and a mach64, albeit somewhat differently (see
below) .. I am in a good position to provide you with any files on my
system that you think might be of interest.

In any event, I should probably mention one other thing that I have
read/heard on the subject, which is that if both vesa and the native
driver are enabled in your kernel config, the native driver wins. 

This may be useful since grub lets you easily change your boot options
on the fly .. eg. to recover from a messed up situation.

Also, I am currently setting up an etch system on the same laptop and
after my posting late last night, I noticed that my grub menu entries
for the etch system do not specify anything regarding the fb console at
all..!  No video=atyfb or specifying the dimensions of my display in
pixels.  And yet, the laptop boots by default into its native 1400x1050
mode.  No artifacts .. a perfect display as on a bran new high-end
hardware terminal.

This, btw is with the more recent 2.6.20 kernel (I typically run sarge
with a 2.4.27 custom kernel).  

I also vaguely remember that, much to my delight, the 1400x1050 mode was
already defined in the source file that contains all the modelines.  But
I had to compile custom kernels over and over for a number of other
reasons .. so I'm not sure any more whether the kernel config I started
off with had "ati" support enabled by default or if I had to enable it
myself.  The former, I think.

Rather revealing of the maturity of the atyfb driver..! I requested from
the ubuntu folks that they add this mode to their live system cd at
least .. and possibly the installer .. to no avail .. that was about two
years ago.

Do you have access to a system where you could run some tests with
possibly another video card than my old mach64..?  I was thinking if you
had some hands-on experience of this not so well documented area ..
it might help clarify the process .. correct possible errors and
omissions on my part .. make sure there is no miscommunication .. as
well as .. if you are successful .. being able to add at least one video
card to your database of video cards that we know for a fact are fully
supported by a "native" driver.

I should also add that from the user angle the results in my case were
well worth the effort since the only (major where I am concerned) visual
difference between my linux console and a full-screen xterm on my etch
system is the fact that the linux console is limited to 16 colors rather
than xterm's 256.

Unfortunately, although I have fiddled with a couple of programs that
let you dump an fb console to a file I have not been successful and so I
do not have screenshots to prove it.

Sorry about the vagueness/verbosity of the above but that's just about
all I have been able to figure out so far.  If I understood the fb
console a bit better, I would be a lot more terse and I might consider
updating that obsolete Framebuffer Console HOWTO. 

Regrettably, I have never had the time to work and play with the code
of at least my own video card's driver.

Oh, if you do decide to add something to your web page, please let me
know and I'll be glad to take a look.

Thanks,
cga



Reply to: