Re: framebuffer oddities, cont'd...

[Helge H. <hel...@hi...>]

Hugo Vanwoerkom wrote:

>--- Helge Hafting <hel...@hi...> wrote:
>
>  
>
>>You don't really assign framebuffers yourself.  It
>>usually
>>happens automatically, if you have framebuffer
>>drivers for
>>your cards.
>>
>>I have a matrox G550 dualhead card, and my kernel
>>is compiled with two framebuffers for it, one for
>>each head.
>>    
>>
>
>I see that option for "matrox" and "dualhead". But I
>have a nVidia TNT2 on AGP and a nVidia MX-440 on PCI.
>  
>
Then you need framebuffer drivers for those nvidia cards,
if such drivers exists.  (Or do without framebuffers.)

>Like I said, I patched in the vesafb-tng patch. That
>  
>
I don't know what kind of driver this is, vesa
is probably some kind of generic framebuffer driver?
Such drivers tend to be unaccelearated (ok but slow)
and usually only works with the first graphichs card
in the system.  The second one tend to go unused.
A driver made specifically for one kind of card have a better
chance for working for a secondary card too.

>gives you on the kernel config a default resolution
>which I set to 1280x1024-32@85 AND I compile in
>SUN12x22 fonts, but nothing else. Then I get a good
>screen. The "only" thing is on boot, after the initial
>vga stuff, the fbcon starts up with a big white blob
>that moves up and disappears.
>
>Now when I disable vesafb and enable nVidia Riva,
>everything turns to s**t. The screen becomes black
>with tiny little green things above (that's the part
>where the penguin shows) and then afterwards the
>characters become huge (because of the selection of
>the sun12x22 font).
>
>  
>
>>Therefore, /dev/fb0 is the first head and /dev/fb1
>>is the second.
>>cat something > /dev/fb0 cause garbage to appear on
>>the
>>first screen, while cat somthing > /dev/fb1 cause
>>garbage on
>>the other screen. Using /dev/fb2 gives me ENODEV
>>because
>>there is no third framebuffer at this time. There
>>will be when I get my radeon pci card though.
>>
>>
>>    
>>
>>>I do "cat <something> > /dev/fb0 or /dev/fb1 and it
>>>always ends up on the primary console...
>>> 
>>>
>>>      
>>>
>>Very strange.  Only one of them should refer to
>>the primary console.  Have you tried higher numbers,
>>such as fb2, fb3, and so on?
>>
>>Try "ls -l /dev/fb*" and see
>>if the device numbers are correct.  You should
>>get something like this:
>>crw-rw----  1 root video 29, 0 2004-08-16 15:33
>>/dev/fb0
>>crw-rw----  1 root video 29, 1 2004-08-16 15:33
>>/dev/fb1
>>crw-rw----  1 root video 29, 2 2004-08-16 15:33
>>/dev/fb2
>>    
>>
>
>I get:
>
>crw-rw----  1 root video 29,   0 Sep 16 07:07 /dev/fb0
>crw--w----  1 root video 29,   1 Mar 14  2002
>/dev/fb0autodetect
>crw--w----  1 root video 29,   0 Mar 14  2002
>/dev/fb0current
>crw-rw----  1 root video 29,   1 Sep 16 07:07 /dev/fb1
>crw--w----  1 root video 29,  33 Mar 14  2002
>/dev/fb1autodetect
>crw--w----  1 root video 29,  32 Mar 14  2002
>/dev/fb1current
>crw-rw----  1 root video 29,   2 Sep 16 07:07 /dev/fb2
>crw--w----  1 root video 29,  65 Mar 14  2002
>/dev/fb2autodetect
>crw--w----  1 root video 29,  64 Mar 14  2002
>/dev/fb2current
>crw-rw----  1 root video 29,   3 Sep 16 07:07 /dev/fb3
>crw--w----  1 root video 29,  97 Mar 14  2002
>/dev/fb3autodetect
>crw--w----  1 root video 29,  96 Mar 14  2002
>/dev/fb3current
>crw-rw----  1 root video 29,   4 Sep 16 07:07 /dev/fb4
>crw--w----  1 root video 29, 129 Mar 14  2002
>/dev/fb4autodetect
>crw--w----  1 root video 29, 128 Mar 14  2002
>/dev/fb4current
>crw-rw----  1 root video 29,   5 Sep 16 07:07 /dev/fb5
>crw--w----  1 root video 29, 161 Mar 14  2002
>/dev/fb5autodetect
>crw--w----  1 root video 29, 160 Mar 14  2002
>/dev/fb5current
>crw-rw----  1 root video 29,   6 Sep 16 07:07 /dev/fb6
>crw--w----  1 root video 29, 193 Mar 14  2002
>/dev/fb6autodetect
>crw--w----  1 root video 29, 192 Mar 14  2002
>/dev/fb6current
>crw-rw----  1 root video 29,   7 Sep 16 07:07 /dev/fb7
>crw--w----  1 root video 29, 225 Mar 14  2002
>/dev/fb7autodetect
>crw--w----  1 root video 29, 224 Mar 14  2002
>/dev/fb7current
>
>But only catting to /dev/fb0 has any effect.
>
><snip>
>
>I now see that I ought to try nVidia riva in the
>kernel without the sun font or vesafb driver and see
>if he changes the number of framebuffers.
>
>Aivils uses the vesafb-tng patch and if he reads this
>maybe he can say whether that gets him framebuffers
>for all his cards OK. See if he replies.
>
>All in all: 
>1. Obviously framebuffers are much slower than direct
>drivers (like SVGATextMode)
>  
>
SVGATextMode uses the vga text console.  It is fast because an
entire character is written by writing two bytes only. (A character byte
and a color byte.)  Downsides:
* Can't display graphichs on it, obviously
* Limited to 256 or 512 simultaneous different characters on screen, so
   chinese text is tricky at best
* No multicolored fonts
* Font limitations, a character must be 8 or 9 pixels wide.

A framebuffer have to paint each character as graphichs. That is always
more than 2 bytes:
Best case: 1-bit color depth (monochrome) 8x8 font, -> 8 byte per character.
Bad case:  12x22 font, 24-bit color: 792 byte per character!

It doesn't have to be slow though, some framebuffer drivers use the
on-chip graphichs accelerator.  (Same as X uses) They may then match
vgacon for speed. :-) I don't think any VESA thing can use the 
accelerator though.


Other message:

>Result:
>Only catting to /dev/fb0 produces green speckles on
>the screen. Anything else gets "no such device".
>  
>
This shows that the framebuffer driver for your first screen is fine,
and you have no framebuffer driver loaded for the other screen.

If the _same_ driver is supposed to be able to drive both cards, then
you might need to tell it by giving it the right parameters.
I don't know your cards but they have different names,
perhaps they need different drivers?  One way of testing
is to temporarily remove the AGP card and see if the
driver then is capable of driving the PCI card as /dev/fb0.

If so, look at documentation (or source) and try to find
parameters that makes the driver drive two cards.

Helge Hafting