Subject: Re: X on IP22 success
To: None <port-sgimips@NetBSD.org>
From: Christopher SEKIYA <wileyc@rezrov.net>
List: port-sgimips
Date: 01/22/2004 22:24:05
On Thu, Jan 22, 2004 at 03:17:13PM +0200, Ilpo Ruotsalainen wrote:

> What's the problem with colormaps?

It looks like only the high eight bits are used in the colormap (i.e., at
24bpp, things look okay until you try to use something that exceeds 256 colors,
and at 8bpp you're stuck in monochrome).

> This is wrong (I suppose the wrongness is in checking board rev and not
> VC2 rev), my rev 1 board needs x_offset == 21 for correct results.

I think none of us have rev1 boards.  My dmesg shows rev1 for the wscons
driver probe, but rev6 for the X probe.  The wscons newport driver definitely
does not get the board rev correctly.

> Eww, this gives anyone able to mmap() on the newport device access to
> the whole physical memory, yuck.

I said that I wasn't proud of the newport driver changes :)

This needs to become an offset relative to the newport register base, as you
said, which makes the nasty IP22/IP24 hack in the X driver go away.

(linux uses absolute addresses?!?)

> I think we'd need to map this uncached too?

Dunno, actually.  Things look okay with it mapped as cached addresses so far ...

> Shouldn't this just use ioctl(WSDISPLAYIO_GTYPE) to get the display
> type?

That was my thinking as well.  Using sysctl here is just plain wrong.

-- Chris
	GPG key FEB9DE7F (91AF 4534 4529 4BCC 31A5  938E 023E EEFB FEB9 DE7F)