Subject: Re: New snapshot of ATI Mach64 framebuffer driver
To: None <eeh@netbsd.org>
From: Bang Jun-Young <junyoung@mogua.com>
List: tech-kern
Date: 03/14/2002 11:51:13
On Wed, Mar 13, 2002 at 08:43:46PM -0000, eeh@netbsd.org wrote:
> There are definite endianness problems on sparc64.  The characters 
> are garbled and in a funny violet color.
> 
> Rasops probably needs fixing.  Right now it tries to determine what
> endianness to use for stamps by checking `#if BYTE_ORDER == BIG_ENDIAN'
> which is not true for PCI devices.  If I pretend the machine is 
> little-endian then the font is legible but remains in a funny color.  
> So this probably needs to be configured dynamically or bus_space-ified.

The funny color bug is due to wrong color map values. While rasops_cmap
is R:G:B=8:8:8, mach64_cmap is 6:6:6 and lower 2 bits are ignored in 8
bpp mode for VGA compatibility. As a result, green appears as cyan on
the screen, light gray as yellow, ... 

> 
> The second issue is that the screen is cleared when wscons attaches.
> I don't know if you're doing this or the wscons code itself.  I expect

This is intended but now classified as a bug. ;-) You can avoid 
it by removing `ri_flg = RI_CLEAR' for now. 

> it's the latter.  We really should query the firmware and use the current
> settings for font, width, height, and cursor position if any they way 
> the SBus frame buffer drivers do.  With those you can't tell visually
> when you stop using firmware I/O and switch to rasops for I/O.

It's on my to-do list. A problem with i386 port is mach64_attach
function should be called at the very beginning of kernel initialization
even before the pci subsystem it depends on is initialized. So pcdisplay
is used until mach is initialized. That's not good and should be fixed
anyway.

Jun-Young

-- 
Bang Jun-Young <junyoung@mogua.com>