On 28/07/2023 09:45, Thomas Zimmermann wrote:
Hi
Am 27.07.23 um 23:34 schrieb Roger Sewell:
Thomas, Jocelyn,
As a result of the collection of the Xorg logs requested by Thomas, I've
realised that at some long-past point upgrade the 1440x900@60 mode
disappeared, and in order to get it back I introduced the file
/etc/X11/xorg.conf.d/20-screen.conf attached.
If I remove this file, then with the unmodified new mgag200 module in
place, on going to Settings->Display I am no longer even offered the
1440x900 option - presumably as a result of
mgag200_mode_config_mode_valid returning MODE_BAD.
With this file in place, and with the unmodified new mgag200 module in
place, I am offered this setting, but if I pick it then it is not used
but *is* written into ~/.config/monitors.xml, and then on next login
graphics fail completely.
Thanks for this information. If you configure a screen and/or modes via
config file, such as 20-screen.conf, it overrides Xorg's autodetection.
So X will happily use whatever you configured. This explains my other
mail's question why Xorg even tries 1440x900 at all.
Hypothesis: there are two different places in the code where mode_valid
is potentially checked, both of which use the mgag200 module, and the
old module only does this check at one of them (deciding which modes to
offer) (which check is bypassed for modes requested in xorg.conf.d),
while the new module does it at both (and hence fails invalid modes
requested in xorg.conf.d) ??
There's mode detection, which does the general test with mode_valid. It
returns a list with possible modes. And there's mode setting, which
tests if the display setting as a whole (mode, color format, outputs,
and more) can can be programmed in the given combination. That's what
fails with the new driver, but worked with the old driver.
I guess that the configured mode of 1440x900 somehow passed testing in
the old driver. And as your chip could handle the overclocked pixelrate
settings, you got a stable output even with 32-bit colors.
I assume that the new driver is somehow more strict in testing and
rejects the overclocked pixel rate. (But I cannot see that in the code
TBH).
I think the culprit is probably this patch:
https://patchwork.freedesktop.org/patch/486242/
before this patch,
mgag200_simple_display_pipe_mode_valid() always return MODE_OK
after this patch, it checks the bandwidth limit too.
Looking for possible reasons why this might be the case (and straying
way beyond my competence), I note that in the old module
mga_vga_mode_valid is made known to other parts of the system in a
different way than mgag200_mode_config_mode_valid is in the new module
(and indeed they have different parameter types). (Might this be
relevant ?)
I'm not quite sure how to proceed here, as the driver is correct and the
problem came from a mismatching config file on your system.
So the bandwidth limit was not really enforced before, and the more
strict behavior breaks the user's configuration that are over the limit.
Best regards
Thomas
Best wishes,
Roger.
