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/modesmgag200_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@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/modeson 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@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@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)
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
