Re: Amiga screen modes in wscons

On Sun, 12 Nov 2023 at 16:08, Carlos Mil=C3=A1n Figueredo
<[email protected]> wrote:
>
> Hi David,
>
> From: David Brownlee <[email protected]>
> Sent: Sunday, November 12, 2023 12:52
>
> > If you have a fast cross build box the time to rebuild a new kernel
> > with adjusted values is approximately nothing (though the time to copy
> > to the Amiga and for it to reboot into it is very much not :)
>
> I have the cross build box. Indeed it takes more time to scp the kernel t=
o the Amiga and reboot than the compilation itself :) If for wrong paramete=
rs I cannot see the screen and I have to hard-reset the Amiga, the fsck wil=
l take easily 15 minutes. I could go around that by blindly writing or seri=
al console...

If NetBSD on the amiga is set to come up to multi-user with networking
then you could automate it from the build box
- Run ssh-keygen on the build box, and add the generate pub key into
/root/.ssh/authorized_keys on the amiga
- Create a script on the build box which builds a test kernel, then
runs ssh $amiga cp -p /netbsd /onetbsd; scp netbsd $amiga:/; ssh
$amiga reboot (onetbsd so can recover manually from a kernel which
locks up)

If NetBSD on the amiga is set to come up in single user, then you
should be able to blind type ENTER reboot ENTER :)

> > Looking for a more general solution - the values could be optionally
> > passed in at boot time from the bootloader, either as parameters or by
> > reading from a boot.cfg file
>
> Not sure if that would be worth as they are really low-level, mostly for =
debugging. I think what would make sense is to give the user the option to =
select the screen mode as parameter from bootloader. I can see there are se=
veral screenmodes defined in grfabs_cc.c: GRF_PAL, GRF_NTSC, GRF_AGA, GRF_A=
GA_VGAONLY, GRF_SUPER72, GRF_A2024...
>
> I think the -A kernel parameter -though nice- is not fine-grained enough.

OK, though those are currently compile time options, so we would need
to make them runtime selectable first - possibly by defining a struct
to hold the affected values, and then making a sysctl machdep option
to switch between them (there may also be some untangling to ensure
they could usefully be adjusted at runtime without everything breaking
around them :) Extending that to allow a bootloader option should then
be "not much work"

> > Actually - are these values which would make sense to be able to
> > adjust dynamically at runtime - so via sysctl or ioctl the screenmode
> > could be tweaked while running?
>
> In that case, yes, low-level welcome! It would really help to adjust scre=
en issues such as the one I am experiencing.

It should not be *too* difficult to expose some values under sysctl
machdep, caveats similar to the GRF_ options applying...

David