2

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.
radeon01
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.
radeon02
Using the modesetting driver seems to be unable to render the graphics screen properly, with the entire display drawn with off-shifted lines.
modesetting01

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

Improve this question

2 Answers 2

Reset to default
1

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:

http://vger.kernel.org/lkml/#s3

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.

Improve this answer
4
  • 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. Commented Nov 25, 2021 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. Commented Dec 12, 2021 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. Commented Dec 12, 2021 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. Commented Dec 12, 2021 at 17:43
0

Here follows an update to this topic.

As of early 2024, it can be said that all major problems regarding the Apple iMac line from 2006 and the R300 Mesa Radeon driver are resolved.  I can confirm this for an iMac 5,1 model running Lubuntu 22.04 LTS when X11 is used.  Even better, it is effectively possible to run a 32-bit Linux, like MX Linux, in native EFI mode on those Apple models (!).  This will improve, for example, the speed of the SSD / hard-disk, which is limited under CSM "Bios emulation" aka "Boot Camp" to standard ATA.

It turned out that the R300 driver was already quite flawed.  This was especially true for R500 class hardware.  But, thanks to the open-source community, and especially two very skilled and "retro-hardware" interested persons, most R300 bugs were fixed.  Even better, some useful new features and optimizations were introduced.  For example, probably we will see in the near future even native D3D9 support via Gallium Nine on R500 hardware. ;-)

Long story short: I started at my iMac 5,1 with Kubuntu 20.04 LTS.  But, because of some flaws, I had to enforce in KWin the EGL / OpenGL ES rendering by adding export KWIN_COMPOSE=O2ES in sudo nano /etc/profile.d/kwin.sh.  This made KDE usable at all.

However, although recommended for old hardware, it looks like, at least in later Mesa versions after 22.0, this seems to be no longer needed.  Currently I am on Mesa 24.1 devel installed via the oibaf PPA.

Currently, the sole problem is a higher GPU temperature.  For whatever reason, it rises past 73 °C on Lubuntu, while it stays around 65 °C on Mac OS.  Some further investigation shows that the corresponding power saving capabilities like power_method and power_profile are not exposed.  This could be a (recent) regression.

So much for now. The next exciting new feature will be full hardware accelerated support via Glamor on R400 and R500 hardware. ;-)

Edit: When the "mode-setting" capability is active, then there is still a problem present with some resolutions.  This is also true when the "Glamor" 2D acceleration is enforced (which is strongly recommended for Xwayland).  More information can be found in Mesa issue 2780.

Edit: Since the mid of March 2024 Glamor works thanks to Mesa MR 28209 correctly on R500 hardware. So this has now effectively resolved the long standing problem described here. Note, that is true for the "ati" and "radeon" X11 drivers. The generic "modesetting" one seems to be still affected by some other flaws.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.