On Thu Jan 22 2004 at 20:50:05 +0900, Christopher SEKIYA wrote:
> 1280x1024 geometry doesn't work, and the colormaps are really messed
> up (24bpp mostly works, 8bpp is pretty broken).  These fail, I think,
> because of conflicts between the wscons setup and the X driver, but
> nevertheless it works.

You can only use whatever mode ARCS setup for us, both with the wscons
driver and XFree86, as there's no video mode setup in either of them
(sadly). Another funny thing is, my ARCS seems to setup 1296x1024
instead of 1280x1024 (and some reports around the web give even more
strange horizontal modes...) but it shouldn't matter since we're not
touching the framebuffer directly but using coordinates for all the
primitive ops.

What's the problem with colormaps?

> Patches against sys/arch/sgimips/gio/newport.c and the xfree tree are
> appended for the daring.  Feel free to hack at them and make things
> work better -- I'll commit what I have once I get the colormap things
> working right, but help is _always_ appreciated (the newport X driver
> is very very far from optimal, and I'm not proud of what I had to do
> to the newport driver to make things work).

The newport X driver could use some cleanup and fixing, and it probably
has the same trouble with cursor as mentioned in next comment...

> -		if (dc->dc_boardrev < 6)
> +		if (dc->dc_boardrev == 1)
> +			x_offset = 29;
> +		else if ( dc->dc_boardrev < 6 )
>  			x_offset = 21;
>  		else
>  			x_offset = 31;

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. As
mentioned earlier I was going to write some test patches but due my move
I haven't been able to use my Indy yet...

>  static paddr_t
>  newport_mmap(void *c, off_t offset, int prot)
>  {
> -	return -1;
> +	return mips_btop(offset);
>  }

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

We should just deny offset > GIO regs size (can't remember what it was
and whether we had a define for it but that's trivial stuff) and map
within the GIO device space. Ie. mapping offset == 0xf0000 would give
you the newport regs.

Something like

static paddr_t
newport_mmap(void *c, off_t offset, int prot)
{
	struct newport_devconfig *dc = c;

	if (offset >= GIO_DEVREGS_SIZE)
		return -1;

	return mips_btop(dc->dc_addr + offset);
}

or so, and of course fix the X driver to mmap() on the device with
offset == 0xf0000 (the REX3 registers on newport are offset into the GIO
device space for some reason). This way the X driver doesn't need to
know which GIO slot the device is in either...

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

>  NewportHWProbe(unsigned probedIDs[])
>  {
> +	unsigned hasNewport = 0;
> +#if defined(__NetBSD__)
> +	int mib[2];
> +        size_t len;
> +        char *p;
> +
> +        mib[0] = CTL_HW;
> +        mib[1] = HW_MODEL;
> +
> +        sysctl(mib, 2, NULL, &len, NULL, 0);
> +        p = malloc(len);
> +        sysctl(mib, 2, p, &len, NULL, 0);
> +	if (!strcmp("SGI-IP22", p))
> +	{
> +		hasNewport = 1;
> +		probedIDs[0] = 0;
> +	}
> +        free(p);
> +#else

Shouldn't this just use ioctl(WSDISPLAYIO_GTYPE) to get the display
type? (I know it isn't implemented in the kernel driver but it's trivial
to add...)

-- 
Ilpo Ruotsalainen - <lonewolf@iki.fi> - http://www.iki.fi/lonewolf/