> Dear all,
> 
> euhm.. you might say i need a bullet for discovering this soo late but i
> just discovered that the Xarm32VIDC doesnt even support 24 bit displays
> even.... and since the old VIDC console *allways* goes to 8 bpp for its
> console it allways just looked like it supported 24 bit colour modes.
> 
Correct it only ever supported 1,8 and 16bit.

> This explains my long queeste to find the bug in the 24 bit mode switching
> that i couldn't find .... I guess it was either never tested or has had
> severe `bit-rot' during its development so it wont work now.
> 
It's probably never been invoked before so may just need a little 
debugging.

> I'll re-instantiate the mode switching code again for the new wscons
> console allthough it shouldn't make any difference.... my advice is only
> not to use the 24 bpp modes for now until we figured out how to program
> the VIDC decently for this mode.
> 
> On thing that is now on my list is getting X to work and looking at a neat
> and clean way to specify monitor types and modes to the system... the
> current way of just embedding these modes in the kernel isnt the way to go
> in my opinion...
> 
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).
> 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. 

Mike