Skip to Content.
Sympa Menu

baslinux - Re: [BL] framebuffer

baslinux AT lists.ibiblio.org

Subject: Baslinux mailing list

List archive

Chronological Thread  
  • From: sindi keesan <keesan AT sdf.lonestar.org>
  • To: baslinux AT lists.ibiblio.org
  • Subject: Re: [BL] framebuffer
  • Date: Thu, 31 Mar 2005 14:14:53 +0000 (UTC)

On Thu, 31 Mar 2005, David Moberg wrote:

----- Original Message -----
From: "sindi keesan" <keesan AT sdf.lonestar.org>

Xvesa appears to work fine with everything EXCEPT most VESA 2.0 (it
works with one of my three PCI cards and one of two AGP cards so
far) and Chips and Technologies on two laptops. Your kernel worked
nicely with the two PCI VESA 2.0 cards that did not work with Xvesa
so it is useful and should not be removed, however you might want
to compile it to be more like BL2 (handle vfat and cdrom) since
computers with VESA 2.0 generally have enough RAM.

I think that would be better fulfilled by one of the thousands of other
Linuxes floating around the Internet.

But since you have already compiled it, and some people may prefer BL even if they have a newer computer (circa 1996 and 1997, I think), why not leave it at your site? Or James may have space for it.

>
Why did you include mdacon in the package? Slackware already has it.
And what is vfb.o?

I wasn't sure that the Slackware mdacon would work. vfb allows you to
make a fake framebuffer. It's nearly pointless, don't ask why I included
it.

I was using mdacon.o with BL1, works fine. I put in switches to use mdacon with vt1 and vt2 instead of 13-16. Will delete all but xfbdev and the matrox modules and fbset, but I think we need MORE matrox modules and/or a different kernel.

YOur vesafb kernel does work with matrox, so does xfbdev. Matrox
is the best of these cards in that respect, and does not work with
Xvesa so should be used with framebuffer.

OK, but any other kernel with VesaFB support may work better.

I can go look for one that does Matrox, at Slackware.
I think the vesafb kernel and a matrox kernel are mutually incompatible.

I thought I needed to compile a different kernel for matrox. YOu
said to 'boot normally' which I am guessing means the
non-framebuffer kernel.

It means without a vga= command.

Your kernel, but without vga=? I think that is what I tried (after the normal kernel) that but will do so again next time it is cold and rainy.


When I direct-dial the bbs and ssh from there to another shell
account and use Pine the fonts stay exactly the same size and are
located in a smaller box, and after pine it stays that way. If I
dial the ISP and use kermit to ssh directly to the second shell
account instead, the fonts are the same size but the box fills the
whole screen.

Reset, or stty cols x rows y, where x and y are size you want, one of
the two may fix it.

stty is something I have not used. I think I tried reset.

Different options for mdacon? Did you get the latest source code?

I would hardly call 2.2.16 "latest". The different options were in the
kernel config, I don't remember them. There are quite a few things that
can affect module size.
I will take a look some time. I thought maybe you got a patch for that part of the kernel.


I was not able to change the resolution but I don't know what I am doing.

Fbset is the way to change resolution.
Yes but I only for matrox and that would not work.


Is this xfbdev the same as Kdrive?

It is a Kdrive X server. Xvesa is, too. The big X servers, like XF86Mono,
XF86Mach64, those ones are not Kdrive servers. Kdrive is small.

That explains why they work in the same way. One website said to try one if the other did not work, which is why it would be helpful to have a framebuffer kernel and yours is probably half the size of whatever Slackware offers and boots much faster. I don't like using even bare.i .


There is large free software, too. I've read, though, that Gnome and KDE,
(or KDE, at least,) is/are getting smaller all the time.

I notice that some packages of freeware actually have smaller and smaller source code for the first few versions, before adding bigger features.


Do the fbcons have something to do with low-level drivers, mono, 2bpp etc?

Not quite sure. I would consider low-level to be vesafb, atyfb, matroxfb,
that sort of thing.

It said to choose low-level drivers and then also 2bpp 4 8 16 24 32 and I think you chose only the first two of these and matroxfb complained about not finding the others. And many other unresolved symbols probably related to framebuffer support (when I was using the standard BL2 kernel), but the vesafb support in your kernel may be what crashed it.

How would I use ATI as framebuffer? I did not see an aty* module.
I downloaded but did not look at the config file. They tend to
confuse me and I am confused enough for one day trying to read man
pages.

I know what you mean. A different kernel, not one I've made, is
probably what is needed for ATI. The support in 2.2.16 was for Mach64s,
and I removed it because I didn't think you had one.

I returned it because mach64 won't work with svgalib (broken driver) and it was VESA 1.2 anyway. But I think vesafb, matrox, and ati all need separate kernels, not an all-purpose one.


xfbdev worked with 2 of three cards, which were the 2 cards NOT
supported by Xvesa. So they are not that equivalent, though they
do both choke on 8-bit color.

Regarding that, take a look at what I stumbled on:

http://www.tuxscreen.net/wiki/view/tinyx

Does that sound like the problem?
I will look.

I may find the energy to try the matrox with normal kernel and
modules tonight. This is not how one should spend the second nice
spring day after a very long winter.

Usually, it's easier to get a distribution that has everything set up
to go.

No fun and besides they don't work on my hardware. DSL would not even work without 1024 resolution. SuSE put on all sorts of processes that ran at intervals, and a random-number generator. Even Slackware assumed everone wanted vi.




Archive powered by MHonArc 2.6.24.

Top of Page