From: "Petr Vandrovec Ing. VTEI" <[EMAIL PROTECTED]>
Date: Tue, 14 Dec 1999 19:40:02 MET-1
Kernel should be able to print message on console at any time. So
it should at least know which format is used for display.
Kernel uses font rasterizing and rect filling acceleration on nearly
all Sun cards, it never needs to touch the frame buffer.
It is not problem for Creator, as I see from your and Dave's
description, but it is problem for other hardware.
And just "dumb frame buffer you can directly write pixels to in n-bpp
with R/G/B components in X format" is just an aweful assumption. Can
the library handle cards with no traditional frame buffer at all? I
believe there is an Intel graphics chipset like this.
Logically, even with the Linux /dev/fb mmap semantics, if the card has
no framebuffer in the traditional sense, mmap at offset zero should
fail. This is what makes me feel like the whole scheme is pointless,
it's semantics fall apart for any piece of hardware which is in any
way out of the ordinary. See?
Unfortunately, it creates two APIs, one linux-except-sparc32,64 and
one linux-sparc-32,64+sunos. Is it possible to get these offsets
somewhere (except Sun X server)?
The best we could do is provide them via kernel header files.
And even then they would be macros describing the physical offsets you
would pass to mmap for each area of the cards I/O and framebuffer
space, and GGI would need to know the name of these macros for each
card and the meaning behind what is mapped at that offset.
Face it, you're going to need to put explicit knowledge of the mmap
offset scheme of each card as well as the details of the hardware
programming itself to support Sun framebuffers in the library.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of the message to [EMAIL PROTECTED]
