port-mac68k/60695: genfb console is drawn at the wrong pitch when Mac OS leaves the display in a colour mode

["raytran08%gmail.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60695
>Category:       port-mac68k
>Synopsis:       genfb console is drawn at the wrong pitch when Mac OS leaves the display in a colour mode
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-mac68k-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 08 10:35:00 +0000 2026
>Originator:     Ray Tran
>Release:        NetBSD 11.0; the patch applies unchanged to -current (11.99.8)
>Organization:
Diamond Creek Digital
>Environment:
NetBSD/mac68k 11.0
Tested on: Macintosh IIcx (68030, NuBus "Toby" video), Centris 650 (68040, onboard "Wombat" DAFB)
>Description:
On mac68k the wsdisplay console attached through genfb_grfbus is drawn at the
wrong pitch whenever Mac OS has left the display in a colour mode. Rows are laid
down at a shorter pitch than the hardware scans them, so the console tiles into
columns and is unreadable.

The cause is a mismatch in where the geometry comes from. grf_nubus() reads
NUBUS_RSRC_FIRSTMODE out of the card's declaration ROM, which describes the
board's first advertised mode, not the mode the board is currently in. On a
machine that Mac OS booted into 256 colours, the depth and stride taken from the
declaration ROM therefore describe a different layout from the one in force, and
rasops renders against the wrong stride.

The Booter already passes the geometry Mac OS actually programmed, in
mac68k_video. That is by definition the correct description of the console
display, because it is the display the Booter measured.
>How-To-Repeat:
Set Mac OS to 256 colours. Boot NetBSD/mac68k with a kernel configured for
the wsdisplay framebuffer console (WSFB.common). The console is drawn but skews
progressively across the screen and is unreadable.

Booting with Mac OS set to black and white does not show the problem, which is
why this can go unnoticed.
>Fix:
The attached patch prefers the Booter-supplied geometry in mac68k_video over the
declaration ROM values, but only for the console device and only when the Booter
actually supplied depth and stride. Non-console displays and machines where the
Booter passed nothing are unaffected, so the change cannot regress a
configuration that works today.

The 16-to-15 depth adjustment reflects that Mac OS reports 16 bits per pixel for
what is a 5/5/5 direct-colour mode with one bit unused, which is what rasops
expects to be told.

Tested on a Macintosh IIcx with NuBus "Toby" video and a Centris 650 with onboard "Wombat" DAFB.
Console renders correctly in 256-colour mode on both, and black-and-white mode is
unchanged. In daily use on the Centris 650 under NetBSD 11.0; applies to
-current with no fuzz, and that kernel boots under qemu -M q800.

Applies with "patch -p1" from the top of usr/src; verified with -F0
(no fuzz) against NetBSD-current 11.99.8 (20260830003849Z) and 11.0.

--- a/sys/arch/mac68k/dev/genfb_grfbus.c
+++ b/sys/arch/mac68k/dev/genfb_grfbus.c
@@ -256,6 +256,25 @@
 	sc->sc_stride = gm->rowbytes;
 	sc->sc_paddr = ga->ga_phys + gm->fboff;
 	sc->sc_vaddr = (vaddr_t)gm->fbbase + gm->fboff;
+
+	if (genfb_grfbus_is_console(sc->sc_paddr) &&
+	    mac68k_video.mv_depth != 0 && mac68k_video.mv_stride != 0) {
+		sc->sc_width = mac68k_video.mv_width;
+		sc->sc_height = mac68k_video.mv_height;
+		sc->sc_depth = mac68k_video.mv_depth == 16 ?
+		    15 : mac68k_video.mv_depth;
+		sc->sc_stride = mac68k_video.mv_stride;
+	}
 	sc->sc_set_mapreg = ga->ga_set_mapreg;
 	sc->sc_parent = ga->ga_parent;