Xorg problem with Radeon Mobility X1600 on a 20" iMac LCD from 2006

My attempt to give a meaningful purpose to a 20-inch 2006 iMac 4.1 choked on an odd Xorg problem. Tried **FreeBSD 13.0 Release/amd64** and **elementaryOS 6.0 Odin** as up-to-date systems with their respective **Xorg** packages. Using the **radeon** driver *(only under Linux, as this driver was not present under FreeBSD, nor was it available as a separate package or in ports)* seems to provide the correct graphics mode with the native resolution of the built-in LCD screen. Windows, icons, panels look all fine, but the background picture *(or the desktop background in general, even as a solid colour)* shows broken artifacts.  Its peculiarity is that ONLY the background is drawn flawed, and any GUI object over that looks perfectly fine, including translucent windows, menubars, icons, etc.  Using the **modesetting** driver seems to be unable to render the graphics screen properly, with the entire display drawn with off-shifted lines.  As the **modesetting** driver exists *(and behaves exactly the same way)* on both FreeBSD and Linux *(talking about recent releases as in late 2021)*, and also being the obvious way forward, I would prefer to get this working instead of relying on **radeon**. So, I started by extracting the native resolution details from the EDID data of this 2006 iMac's built-in LCD.

Identifier "Color LCD"
	ModelName "Color LCD"
	VendorName "APP"
	# Monitor Manufactured week 0 of 2005
	# EDID version 1.3
	# Digital Display
	DisplaySize 430 270
	Gamma 2.20
	Modeline 	"Mode 0" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 -hsync -vsync

The suggested **modeline** matches what **xorg** auto-detects when started without an **xorg.conf** file. As the graphics screen works well under this computer's intended *(and outdated, no longer supported)* operating system **Mac OS X 10.6** Snow Leopard, and looks fine under **Windows 10** too, I used a program named [PowerStrip](http://www.fredshack.com/docs/x.html) to collect whatever screen details I could under Windows. This allowed me to fabricate some promising custom modelines.

Section "Modes"
	Identifier "LTM201M1-MODELINES"
	###ModeLine   "1680x1050" 147.136 1680 1784 1968 2256 1050 1051 1054 1087 +hsync +vsync
	ModeLine   "1600x1000" 133.142 1600 1704 1872 2144 1000 1001 1004 1035 +hsync +vsync
	###ModeLine   "1400x1050" 122.614 1400 1488 1640 1880 1050 1051 1054 1087 +hsync +vsync
	ModeLine   "1664x936"  128.373 1664 1760 1936 2208  936  937  940  969 +hsync +vsync
	Modeline   "1664x1040" 143.715 1664 1768 1944 2224 1040 1041 1044 1077 +hsync +vsync
	ModeLine   "1696x1060" 149.543 1696 1800 1984 2272 1060 1061 1064 1097 +hsync +vsync
	###ModeLine   "1678x1050" 146.745 1678 1784 1964 2250 1050 1051 1054 1087 +hsync +vsync
	###ModeLine   "1678x1048" 146.475 1678 1784 1964 2250 1048 1049 1052 1085 +hsync +vsync
	###ModeLine   "1680x1048" 146.866 1680 1784 1968 2256 1048 1049 1052 1085 +hsync +vsync
	###ModeLine   "k1" 119.000 1680 1728 1760 1840 1050 1053 1059 1080 +hsync +vsync
	###ModeLine   "k2" 149.543 1680 1800 1984 2272 1050 1061 1064 1097 +hsync +vsync
EndSection

Those with the triple hashtag comments, do not work well with the modesetting driver. They switch the display into an unreadable line-shifted mode as shown on the 3rd picture above. The last two lines were not produced by PowerStrip data, those were assembled by me manually, using one of the above lines but altering one detail or two in the hope that I can get the native resolution working. Interestingly, the native resolution of 1680x1050 never seems to work using the **modesetting** driver. Not even the **modeline** that is read from EDID, which is what Windows 10, Mac OS X, and the **radeon** Xorg driver under Linux use successfully. Also interesting that **the "1664x1040" and "1696x1060" modes work perfectly**, giving a nice, flicker free, solid display. These are one smaller, and larger resolutions than the native 1680x1050 while keeping the 16:10 aspect ratio. I am surprised that the 1696x1060 works fine too (obviously, the last few pixels are off screen, hence not visible, but the display is solid without any shifted/running lines). Here is what the PCI details show.

vgapci0@pci0:1:0:0:     class=0x030000 rev=0x00 hdr=0x00 vendor=0x1002 device=0x71c5 subvendor=0x106b subdevice=0x0080
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'RV530/M56-P [Mobility Radeon X1600]'
    class      = display
    subclass   = VGA

The Xorg.0.log from both FreeBSD and Linux, using either the radeon or the modesetting driver, shows nothing wrong. As far as Xorg is concerned, everything runs fine. The problem is that my human eyes see something I am not able to process (shown on the 3rd picture above). [xrandr --verbose (radeon/Linux)](http://keve.maclab.org/pub/xrandr--verbose.imac41.radeon.linux.txt) [xrandr --verbose (modesetting/FreeBSD)](http://keve.maclab.org/pub/xrandr--verbose.imac41.modesetting.fbsd.txt) [Xorg.0.log (radeon/Linux)](http://keve.maclab.org/pub/xorg.0.log.iMac41.radeon.linux.txt) [Xorg.0.log (modesetting/Linux)](http://keve.maclab.org/pub/xorg.0.log.iMac41.modesetting.linux.txt) As I am unable to get the native 1680x1050 working with modesetting (failing the same way under FreeBSD and Linux), while the same settings are known to work with the proprietary ATI driver under Windows 10 and Mac OS X, plus the open source radeon driver under Linux, my conclusion is that something may be wrong with the modesetting driver (or the radeonkms module). **Do you have any suggestion on what to try in order to get the native resolution working with the modesetting driver?** Alternatively, **what would be the proper channel to report this issue to the developers of the modesetting driver** (or the radeonkms module)**?**