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

[Thomas Zimmermann]

Hi Jocelyn

Am 26.07.23 um 10:10 schrieb Jocelyn Falempe:
[...]
>> So the old kernel already did the right thing.
>>
>>>
>>> In the *new* code the nearest-named function I could see 
>>> issys/class/drm/card1-eDP-1/modes
>>> mgag200_mode_config_mode_valid, which returns MODE_OK at the end of the
>>> function if the bandwidth limit is increased to 30100, and returns
>>> MODE_BAD three lines higher up if it is left at 24400.
>>
>> Nothing has changed in the new kernel.
> 
> That's not completely true, as if I understand correctly, changing only 
> the kernel with the same userspace, breaks the 1440x900 resolution. 
> (Even if MODE_BAD is returned in both cases).

But how so? My understanding is that the kernel's behavior does not 
change. Only userspace. I'm rather puzzled about the details here. Maybe 
the old Xorg uses an entirely different driver, such as the old Xorg 
userspace code.

> 
>>
>>>
>>> Moreover if when using the old code we switch to Wayland instead of
>>> Xorg, it doesn't let me pick the 1440x900 at 60Hz mode at all, but it does
>>> with Xorg (one of the reasons I hadn't used Wayland).
>>
>> You can do
>>
>>    cat /sys/class/drm/card1-VGA-1/modes
>>
>> on the old and new kernel. With a monitor connector, it will tell you 
>> the supported resolutions.
>>
>>>
>>> Therefore I think the reason that the old code allowed use of
>>> 1440x900 at 60Hz was that Xorg somehow didn't properly check the return
>>> value from mga_vga_mode_valid, but Wayland did. Moreover I think that
>>> the latest version of the Xorg stuff does PARTIALLY check that return
>>> value, to the extent that it won't let you actually use that mode, but
>>> does nonetheless present it as a choice when you go to Settings->Display
>>> - and then saves the values it didn't allow you to take in
>>> ~/.config/monitors.xml, and on relogin refuses to give you any graphics
>>> at all because it doesn't like those values. But that, of course, is
>>> nothing to do with the mgag200 driver (if it is indeed true - I haven't
>>> looked at the Xorg source code at all).
>>>
>>> The issue from the point of view of my usage case is that the chip works
>>> just fine in the 1440x900 at 60Hz mode, even though 30318019 > 1024*24400.
>>
>> I don't want to increase that limit in the driver, as it might have 
>> consequences for a lot of other hardware. And if you assume that 
>> 30318019 * 3 / 4 ~= 22738514 , 24-bit color mode fits into the current 
>> limit.
> 
> There are no public hardware specifications, so it's pretty hard to know 
> if the 24400 limit is legitimate or not. At least one hardware is able 
> to overcome that.

That limit has been in the driver since the dawn of time. I'm not going 
to tinker with it.

 
https://cgit.freedesktop.org/xorg/driver/xf86-video-mga/tree/src/mga_driver.c#n3890

> 
> I've already sent a patch to use internally 24bit colors, when userspace 
> can use 32bit that would solve this issue as well. In the end, on the 
> VGA link, 24 or 32 bit colors are the same. That would allow modern 
> userspace to work on par with Xorg. So maybe we can reconsider it ?

No way. We've had IRC flamewars over this topic already. People didn't 
get work done that day; others ragequit-ed in frustration. Ask Javier, 
he'll remember. :)

The consent in DRM-land is: we're not going to mess with color formats 
behind the back of userspace. The only exception is the emulation of 
XRGB8888 iff the hardware does not support that. And only because it's 
the fallback format that is universally supported.

> https://patchwork.freedesktop.org/series/116381/
> I would need to update the bandwidth test to accommodate for 24bit.
> 
>>
>> Jocelyn, should we attempt to make extra resolutions available for 16- 
>> and 24-bit modes? We could do the bandwith test in the primary plane's 
>> atomic_check, where we know the resolution and the color format. The 
>> general mode test would use bpp=8.  IDK how userspace reacts to that, 
>> so it would require some testing.
> 
> That will only work for old userspace (Xorg) able to do 16 or 24 bit 
> modes. Also the driver don't do 8bit, so 16bit is the minimum, and can 
> be used in the general mode test. I can still give it a try.

Mesa still supports 16-bits IIRC. But 24-bit pixels are unaligned, which 
makes it hard.  I'm worried about autodetection here. If the userspace 
fails with 1440x900-32, it needs to test 1440x900-16 next. I wouldn't 
bet on this.

Best regards
Thomas

> 
> Best regards,
> 

-- 
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/20230726/8f271f83/attachment-0001.sig>