Nouveau - Feb 2020 - where to report modesetting DDX bug?

Video and input drivers Subgroups and projects on gitlab does not list
modesetting
DDX, presumably because it's not packaged separately from the server.
Where's the
right place to report a modesetting DDX bug that manifests only on an NVidia
GPU?
Directly against the server https://gitlab.freedesktop.org/xorg/xserver?

Here are some particulars:
How can I tell whether this should be reported to kernel tracker or to
freedesktop
tracker as driver or server problem? HDMI output on GT218 10de:0a65 GPU is
limited
to 1920x1200. When connected to 2560x1440 display, vttys are supported at
display's supported 1920x1080 mode, but X with modesetting DDX puts display
in
unsupported mode (functionally asleep) regardless of various attempts to force
1920x1080 at 60 or 1600x900 at 60, while with nouveau DDX, or 1920x1200 display,
or
2560x1440 display with Dual-link DVI cable, display behavior is as expected.

openSUSE 15.1/kernel 4.12.14	OK
openSUSE 15.2/kernel 5.3.18	bad
Tumbleweed/kernel 5.4.14	bad
Debian Buster/kernel 4.19.x	OK
Fedora 31/5.5.5 kernel		bad

http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log-gt218-stw-modesetting-OOR-0x1e
http://fm.no-ip.com/Tmp/Linux/Xorg/gt218-dmesg-stw.txt
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

On Fri, Feb 28, 2020 at 11:06 AM Felix Miata <mrmazda at earthlink.net>
wrote:
> Video and input drivers Subgroups and projects on gitlab does not list
modesetting
> DDX, presumably because it's not packaged separately from the server.
Where's the
> right place to report a modesetting DDX bug that manifests only on an
NVidia GPU?
> Directly against the server https://gitlab.freedesktop.org/xorg/xserver?
I don't know if anyone (from nouveau) looks at gitlab, so mailing list
is probably best anyways.
>
> Here are some particulars:
> How can I tell whether this should be reported to kernel tracker or to
freedesktop
> tracker as driver or server problem? HDMI output on GT218 10de:0a65 GPU is
limited
> to 1920x1200. When connected to 2560x1440 display, vttys are supported at
> display's supported 1920x1080 mode, but X with modesetting DDX puts
display in
> unsupported mode (functionally asleep) regardless of various attempts to
force
> 1920x1080 at 60 or 1600x900 at 60, while with nouveau DDX, or 1920x1200
display, or
> 2560x1440 display with Dual-link DVI cable, display behavior is as
expected.
>
> openSUSE 15.1/kernel 4.12.14    OK
> openSUSE 15.2/kernel 5.3.18     bad
> Tumbleweed/kernel 5.4.14        bad
> Debian Buster/kernel 4.19.x     OK
> Fedora 31/5.5.5 kernel          bad
>
>
http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log-gt218-stw-modesetting-OOR-0x1e
> http://fm.no-ip.com/Tmp/Linux/Xorg/gt218-dmesg-stw.txt
Those HDMI mode clocks are too high against the nominal single-link
165MHz TMDS. You can set your own maximum with nouveau.hdmimhz=300
(for example) to allow it. I believe the connectors aren't rated for
that though. The commit which fixed this is

commit d1084184789d677df4e9c110f38cb3f3d709195d
Author: Ben Skeggs <bskeggs at redhat.com>
Date:   Wed May 29 09:58:18 2019 +1000

    drm/nouveau/kms: disallow dual-link harder if hdmi connection detected

and went into v5.3. I'm not sure where this got broken... I think it
would have been

commit 9340d77f5327ea673a7f95f58139123d7a278243
Author: Ilia Mirkin <imirkin at alum.mit.edu>
Date:   Mon Sep 3 20:57:37 2018 -0400

    drm/nouveau/disp: take sink support into account for exposing 594mhz

which went into v4.20, but it could also have been

commit 1a0c96c075bb4517d4ce4fb6750ee0a3cf38714c
Author: Ilia Mirkin <imirkin at alum.mit.edu>
Date:   Tue Nov 3 21:00:11 2015 -0500

    drm/nouveau/kms: allow 225/297MHz pixel clocks for HDMI on Fermi/Kepler

which went into v4.5 and lines up with your timeline better, but seems
like it shouldn't be handing out those high frequencies to HDMI
connectors on tesla...

Cheers,

  -ilia

> Felix Miata wrote in
https://lists.freedesktop.org/archives/nouveau/2020-February/035583.html:
	OS	Kernel		State	/boot/vmlinuz timestamp
>> openSUSE 15.1/kernel 4.12.14    OK	2019-12-06
Fedora 31/5.3.16 kernel		OK	2019-12-13
openSUSE 15.2/5.3.16 kernel	OK	2019-12-31
Tumbleweed/5.4.7 kernel		OK	2020-01-08
Mageia 7/5.4.10 kernel		OK	2020-01-09
Mageia 8/5.4.11 kernel		OK	2020-01-13
>> Debian Buster/kernel 4.19.x     OK	2020-01-26
>> Tumbleweed/kernel 5.4.14        bad	2020-02-02
Fedora 31/5.4.20 kernel		OK	2020-02-17
Fedora 30/5.4.21 kernel		OK	2020-02-19
>> Fedora 31/5.5.5 kernel          bad	2020-02-19
>> openSUSE 15.2/kernel 5.3.18     bad	2020-02-21
Does this expanded timeline help any?
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/