Subject: Re: Shocking news: no 24 bits colour
To: Mike Pumford <mpumford@mpc-data.co.uk>
From: David Brownlee <abs@netbsd.org>
List: port-arm32
Date: 04/10/2001 09:15:10
On Mon, 9 Apr 2001, Mike Pumford wrote:

> Okay IMO this is how it should work:
>
> Create an IOCTL interface which allows the specification of a video
> mode using the parameters provided in a RISC OS monitor definition file.
> I agree that the kernel should have no hardwired modes except maybe a
> basic 640x480 default configuration.
>
> The bootloader should provide some default mode parameters based on
> either user configuration or RISC OS mode at time of boot.
>
> Create a userland application which can read a RISC OS monitor
> definition file and select video modes based on the values in it. The
> default install should ship a monitor definition file which will work
> reasonably well with basic VGA monitors (640x480@60Hz).

	The amiga port also has custom graphics chipsets that are
	configured from a userland tool. While there are bound to differ
	somewhat, it might make sense to use a common API for
	communicating the information to the kernel, and ideally use the
	same ws* tool - though it would obviously have to understand
	RiscOS and AmigaOS format monitor files as well as maybe some
	superset format.

> > We either need to use : 1) a userland process gives the parameters (like
> > setdisplay) and only pass it enough information from the bootloader to
> > survive and print stuff until a user sets the display *or* 2) let a set be
> > specified by the bootloader at startup... allthough less flexible i am
> > looking at this too ...
> >
> Having the resolution fixed a boot time would really suck and would be
> a step back to the time when NetBSD/arm32 was just being created.

	Would it make sense to default to the RiscOS mode, and have a
	userland tool able to load a given mode into the bootloader/kernel
	for those who prefer that?

		David/absolute		-- www.netbsd.org: No hype required --