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

Jocelyn Falempe jfalempe at redhat.com
Fri Jul 28 08:09:13 UTC 2023


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

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



More information about the dri-devel mailing list