> 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.
Thats good. This is one of the reasons for the new fbdev API to have
standard console wrapper around accelerations a card can support. This
also deals with the latency problem some people have been having.
> 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.
Well libGGI as well as the X server for fbdev uses the fb_fix_screeninfo
type field to deal with how to write to the framebuffer if not a standard
mode. So yes it can handle non traditional framebuffer formats.
> 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?
Actually the accel wrappers I'm designing for fbcon are being designed to
work outside of fbcon so cards without the traditional framebuffer will
work with this code. If you look at some of the fbcon code it depends on
the existence of a framebuffer. This lead me to make sure the accel
wrapper work with fbcon but can also work without.
> 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.
I see. Well I'm willing to go the extra mile. Show me the macros and
headers and I will implement it. Also someone will need to write docs on
this and place it on our web site.
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of the message to [EMAIL PROTECTED]
