Baslinux mailing list

[sindi keesan <keesan AT sdf.lonestar.org>]

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.