[PATCH] drm/mgag200: Increase bandwidth for G200se A rev1

[Thomas Zimmermann]

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 at 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).

> 
> 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.

Best regards
Thomas

> 
> Best wishes,
> Roger.
> 
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230728/4d852f91/attachment.sig>