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

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)
xrandr --verbose (modesetting/FreeBSD)
Xorg.0.log (radeon/Linux)
Xorg.0.log (modesetting/Linux)

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


Unfortunately, I only have the answer to your alternative question. The proper channel to report this bug is the Linux Kernel Mailing List. Instructions on how to send a message, proper etiquette, and how to subscribe (or get replies to your message if you don't want the huge volume that comes with subscribing) can be found here:


The level of detail you've given is excellent and will be very helpful for the bug report, but don't be surprised if they require even more information.

  • Whenever these people ask for more details, they always have a good reason for that. And in my experience they very well know what they are talking about (or what they ask for). So I am perfectly fine with that.
    – Keve
    Nov 25 '21 at 20:08
  • I followed ZedHeadTed's advice. Read the excruciatingly long and detailed FAQ of the Linux Kernel Mailing List. Transformed most of this post into a plaintext e-mail. Then sent it to the LKML. I did not subscribe, which is fine according to the FAQ, and did indicate this fact in my e-mail asking specifically to be CC-ed directly if my assistance is needed. Overall, this was a strange experience with some mixed feelings.
    – Keve
    Dec 12 '21 at 17:42
  • The FAQ at many points appears to be outdated and unmaintained. Until I receive a reply (if I ever receive one) I have no way of knowing whether my post reached the LKML, got held-up by a filter, or vanished into the vastness of the Internet.
    – Keve
    Dec 12 '21 at 17:43
  • Mind you, I also e-mailed the supposed maintainer of the FAQ, pointing out broken links and other outdated contents. He has a FAQ-of-sorts of his own, explaining how he combats junk e-mails, how his mailbox will likely reject my e-mail, and how it will respond with instructions on how to get passed this protection. I received no response, nor any automated reply with mentioned instructions. Again, not really knowing if my effort was in vain or not.
    – Keve
    Dec 12 '21 at 17:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.