Re: port-sparc64/59408: machfb picks a really odd console resolution

["Julian Coleman via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-sparc64/59408; it has been noted by GNATS.

From: Julian Coleman <jdc%coris.org.uk@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-sparc64/59408: machfb picks a really odd console resolution
Date: Mon, 12 May 2025 14:15:49 +0200

 Hi,
 
 > The video chip is capable of handling the native resolution of
 > the monitor - I know because it uses it when X is started.
 
 > machfb.c contains the following line:
 > 
 > #define MODE_IS_VALID(m) ((sc->ramdac_freq >= (m)->dot_clock) && \
 >                           ((m)->hdisplay <= 1280))
 > 
 > This line can be adjusted, but I'm unsure of the rationale for
 > it existing. Saving memory?
 
 It looks like we're checking the maximum frequency of the ramdac on this
 chip against the frequency specified in the mode, and also the maximum
 display width.  The former makes sense, but I wonder if the latter only
 makes sense for some early revisions of the chip?  We can then reduce
 this to just check the frequency (or use the same checks that the X driver
 uses).
 
 > [     1.000000] machfb0: unable to use EDID preferred mode (1920 x 1080)
 > [     1.000000] machfb0: initializing the DSP
 > [     1.000000] machfb0: initial resolution 1280x800 at 8 bpp
 > 
 > then picks 1280x800, despite the aspect ratio being wrong!
 
 I'm guessing that we're using a mode from sort_modes() but maybe the logic
 there needs changing?  Adding some debug there to print out the sorted list
 of modes would help us to see what the list looks like.
 
 Regards,
 
 Julian
 
 sort_modes() references:
   https://nxr.netbsd.org/search?q=sort_modes&project=src&defs=&refs=&path=&hist=
 --