NetBSD Problem Report #59408

From www@netbsd.org  Thu May  8 20:55:15 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 6FD9F1A923D
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  8 May 2025 20:55:15 +0000 (UTC)
Message-Id: <20250508205514.608671A9241@mollari.NetBSD.org>
Date: Thu,  8 May 2025 20:55:14 +0000 (UTC)
From: nia@pkgsrc.org
Reply-To: nia@pkgsrc.org
To: gnats-bugs@NetBSD.org
Subject: machfb picks a really odd console resolution
X-Send-Pr-Version: www-1.0

>Number:         59408
>Category:       port-sparc64
>Synopsis:       machfb picks a really odd console resolution
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 08 21:00:00 +0000 2025
>Last-Modified:  Mon May 12 12:20:01 +0000 2025
>Originator:     nia
>Release:        10.1
>Organization:
The MachBSFB Foundation
>Environment:
NetBSD lilac 10.1_STABLE NetBSD 10.1_STABLE (GENERIC) #0: Thu May  8 19:43:59 CEST 2025  nia@siphon:/encrypt/src/obj/sys/arch/sparc64/compile/GENERIC sparc64
>Description:
machfb sees a 1080p screen and decides it's far too large:

[     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!

The monitor does display this, but a lot of the display is
cut off.

The video chip is capable of handling the native resolution of
the monitor - I know because it uses it when X is started.
>How-To-Repeat:
boot netbsd with framebuffer
>Fix:
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?

>Audit-Trail:
From: nia <nia@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-sparc64/59408: machfb picks a really odd console resolution
Date: Thu, 8 May 2025 21:05:21 +0000

 On Thu, May 08, 2025 at 09:00:00PM +0000, nia@pkgsrc.org wrote:
 > 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?

 Everything works as it should after removing the condition.

From: Julian Coleman <jdc@coris.org.uk>
To: gnats-bugs@netbsd.org
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=
 -- 

Home	PR Database Search