Re: How to submit patches?

[tlaronde%polynum.com@localhost]

Le Sun, May 07, 2023 at 06:14:35PM +0200, Martin Husemann a écrit :
> On Sun, May 07, 2023 at 04:56:33PM +0200, tlaronde%polynum.com@localhost wrote:
> > I'm a bit reluctant to put all the platform lists in copy, since this
> > is typically generic: it deals with the monitor capacities, updating
> > the VESA DMT specs...
> 
> I pointed a few people at your mail, but maybe you could describe the
> motivation of the changes a bit more verbosly - at first it all looked
> like a lot of churn for no particular reason (but that is probably because
> I don't know anything about that part of the source).

With NetBSD 10 beta, there was a change in resolution picked-up for the
framebuffer compared to 9.3: I have a 16:9 ratio LCD; 9.3 picked-up this
ratio and a correct resolution and font for the framebuffer, while
10 beta does not (on the very same hardware).

Trying to investigate why this difference, I found nothing obvious.

So I started to track back, starting from the end: the monitor.

Since I didn't know anything about this stuff, I started to download the
published specs by VESA and read the specs.

So the first step was to update to the latest VESA DMT and to fix
some things that were wrong: there are discrepancies about
the Mac monitors "modelines"; some historical modes were missing; Xorg
(the source used in NetBSD at least) is not up to date either and
was used as a reference for the VESA DMT modes, while with the VESA DMT,
de facto and de jure, it should not.

Since I can work on that only on very scarce hours, instead of waiting
(how long?) to finish all, I prefer to commit a step that is an
independant unit by itself and is finished, without breaking anything
(it adds modes; it corrects---printing "800x600x60" for a mode is
multiplying apples by bananas,
since 60 is a frequency so now it appears as "800x600@60Hz" for example;
it removes unused things that just complexify things for someone
who tries to update the code; etc.) so that at least, _this_, will
not have to be done by someone else.

Of course, some of the fields added from the VESA DMT would be needed
in the future when updating code about EDID. So it is not gratuitous.

Next step will be to review the EDID code and I will continue back
(praying to not have to deal with drm...) until I find why it doesn't
work correctly and understanding the framebuffer stuff.

Is this clearer?
-- 
        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