Re: NetBSD 10.0 BETA kernel testing: framebuffer

[tlaronde%polynum.com@localhost]

Le Sun, Jan 29, 2023 at 03:59:45PM +0100, tlaronde%polynum.com@localhost a écrit :
> Le Sun, Jan 29, 2023 at 02:54:39PM +0100, tlaronde%polynum.com@localhost a écrit :
> > Le Sun, Jan 22, 2023 at 02:56:47PM +0100, tlaronde%polynum.com@localhost a écrit :
> > > 
> > > Context: I'm testing NetBSD 10.0 BETA on an isolated node (not
> > > production). Only kernel and modules (not userland); and kernel is not
> > > GENERIC but a special config one matching the previous 9.2 config
> > > running on the node.
> > > 
> > > No problem so far. As a user (and as advertised), I had simply to use
> > > audiocfg(1) to set the new correct default for audio in order to have
> > > sound back where I used to expect it.
> > > 
> > > The main difference is about the framebuffer: previous kernel version
> > > picked the correct mode. NetBSD 10.0 does not and use "entry level"
> > > mode 640x480x67, resulting streched fat big characters; message:
> > > 
> > > no data for est. mode 640x480x67
> > 
> > I think we are looking at the wrong place. The problem is the depth
> > in the mode looked for: 67! The only depths the cards new about are
> > multiple of 2^3.
> > 
> > So where does this come from?
> 
> Replying to myself: it is not the depth, but the frequency and it comes
> from sys/dev/videomode/edid.c.
> 
> Now trying to find why, at least, it does not find 640x480x60, which
> exists---and 720x400x70 that exists also.

I have it backward: the failure is displayed, for DIAGNOSTIC, for one
mode that is not found, but this does not mean that others are not
found.

The monitor EDID advertizes only two modes: 640x480x60 and 720x400x70
(while it can do others).
The screen being 16:9 (nominal resolution is 1600x900), the VESA mode
chosen leads to this "ugly" rendering with stretched, fat
characters---which was not the case with 9.2. But is correct with the
logics implemented if I'm not (this time) mistaken.

I will look (silently) to dev/pci/radeonfb.c to understand better the
logics and try to find if there is a way to obtain a better console
display.

BTW, the problem is with VGA and DVI(-D) connections. With another monitor
connected with HDMI (so more recent than this present 16:9 monitor, that
have only VGA and DVI-D connectors and was manufactured in
2012 according to the EDID), the framebuffer has a better resolution.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C