Graphics Driver Issues - Onboard Mobility Radeon HD 4225/4250

tallowwood · June 25, 2014, 6:19pm

I wish to run openSUSE 13.1 x86-64 OS on HP ProLiant MicroServer G7 N54L for use as a general purpose PC and home server. I have KDE and LXDE-QT installed while I try to sort out setup issues.

Net-install from CD failed initially (no screens). Added “nomodeset” boot parameter and proceeded to install with fbdev driver loaded. Current GRUB2 boot parameters seem to include: “Video=800x600, nomodeset”. Deleting “Video=800x600” makes no difference, deleting “nomodeset” yields blank screen.

I am loath to try installing the AMD legacy driver (discussed here) without understanding more and first resolving the issues I have with the opensouce radeon driver. The radeon driver is installed but I am unable to load the driver module.

I have carefully avoided ATI/AMD graphics in the past, so my ignorance is very deep. After a few days reading here and elsewhere I am now just going round in circles. Hence this request for support.

Processor: 2.2-GHz AMD Turion II Neo N54L Dual-Core Processor
Total memory (RAM): 1.8 GiB; Free swap: 12.0 GiB (propose more RAM later …)
VGA controller: Integrated in the AMD RS785E chipset [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250]
OS: openSUSE 13.1; Linux 3.11.10-17-desktop x86_64 with KDE: 4.11.5
Display Driver: fbdev
Radeon driver (libdrm_radeon1 2.4.46-3.2.2) is installed but not loaded.

 # xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1152 x 864, current 1152 x 864, maximum 1152 x 864
default connected primary 1152x864+0+0 0mm x 0mm  1152x864  76.0* 

# lspci
1:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250]

# lspci -s 1:05.0 -v
01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250] (prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company Device 1609
        Flags: bus master, fast devsel, latency 0, IRQ 10
        Memory at f0000000 (32-bit, prefetchable) [size=128]
        I/O ports at e000 [size=256]
        Memory at fe8f0000 (32-bit, non-prefetchable) [size=64]
        Memory at fe700000 (32-bit, non-prefetchable) [size=1]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [50] Power Management version 3
        Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Kernel modules: radeon

# modprobe -v radeon
insmod /lib/modules/3.11.10-17-desktop/kernel/drivers/gpu/drm/radeon/radeon.ko 
FATAL: Error inserting radeon (/lib/modules/3.11.10-17-desktop/kernel/drivers/gpu/drm/radeon/radeon.ko): Invalid argument

Trust this is enough information for an initial assessment of this issue.[/size][/size][/size][/size]

wolfi323 · June 25, 2014, 6:32pm

The AMD legacy driver does not work any more in openSUSE 13.1 (and 12.3 already) because the included kernel and Xorg is too new.

# modprobe -v radeon
insmod /lib/modules/3.11.10-17-desktop/kernel/drivers/gpu/drm/radeon/radeon.ko 
FATAL: Error inserting radeon (/lib/modules/3.11.10-17-desktop/kernel/drivers/gpu/drm/radeon/radeon.ko): Invalid argument

The radeon driver only supports Kernel Mode Settings, so you cannot load/use it as long as you have “nomodeset” on the kernel line.

The radeon driver should actually work for you though (if you remove “nomodeset”).

You say that you get a blank screen when removing “nomodeset”?
Have you tried with all updates installed already?
Check that you have kernel-firmware installed, this contains firmware necessary for some Radeon chips. If you don’t have it, please install it and run “sudo /sbin/mkinitrd”.

When do you get the black screen? When X starts? Do you see the boot splash before that?

Try to disable plymouth by adding “plymouth.enable=0” to the boot options instead of “nomodeset”.

tallowwood · June 25, 2014, 7:08pm

Thanks. I was referring to the more recent ‘catylist’ 12.6 discussed in the sticky in this sub-forum. Still confused about terms.

Yes. Realised that, but not what to do about it.

Yes and yes.

Kernel-firmware is installed.

After booting I see no screens at all. No boot-splash.

I tried that. (edited GRUB2 boot param) On booting I saw 2 lines then nothing but blank screen - no boot-splash.

Thanks for responding.

PS. Late here, must sleep. Will follow up tomorrow.

wolfi323 · June 25, 2014, 7:45pm

Catalyst and fglrx are the same thing (fglrx is the short form for “FireGL and Radeon for X”).
The 12.6 discussed there is no legacy driver (although that version is long outdated, we’re at 14.11 now ;)) and doesn’t support your card. In fact that sticky warns about updating to the 12.6 driver in case you have a HD4xxx GPU.
And the old legacy driver that would support your card doesn’t work any more on 12.3 and up as mentioned.

I tried that. (edited GRUB2 boot param) On booting I saw 2 lines then nothing but blank screen - no boot-splash.

At that point already?

Maybe your monitor’s resolution is not detected correctly?

Instead of your “video=800x600” try something like “video=800x600@60”.

Or try to add this to the boot options: (instead of “nomodeset”)

drm_kms_helper.edid_firmware=edid/1024x768.bin

At that point where your screen goes blank, there is no graphics driver loaded yet. So it’s probably a kernel issue.
Try to install and boot the latest kernel from here:
http://download.opensuse.org/repositories/Kernel:/stable/standard/

(you should still find the standard kernel in “Advanced Options” in the boot menu, if the 3.15 should not work)

wolfi323 · June 25, 2014, 8:00pm

Sorry, the latest stable version is 14.4 and the latest beta 14.6. I forgot to correct that before submitting the post.

tallowwood · June 26, 2014, 10:43am

AMD Legacy Linux Driver. Thanks for advice. I am still not clear about this but prefer to get radeon driver working for now.

At that point already? Maybe your monitor’s resolution is not detected correctly?

Monitor is Samsung S20A300B. I have had problems in past. Claimed max resolution 1600x900@60.

Instead of your “video=800x600” try something like “video=800x600@60”. Or try to add this to the boot options: (instead of “nomodeset”) drm_kms_helper.edid_firmware=edid/1024x768.bin

Tried “video=800x600@60” improved display but still low resolution and not full screen. Tried both together and had 1024x768 screen (no options to change in display manager) but was able to load radeon driver with modprobe. This is real progress. Can you tell me more? What setting should be used to allow full capabilities of HD 4200? What setting should be used to allow Claimed max resolution 1600x900@60 of this monitor?

At that point where your screen goes blank, there is no graphics driver loaded yet. So it’s probably a kernel issue. Try to install and boot the latest kernel.

Patch upgrade yesterday provided kernel-desktop-3.11.10-17.2 and a mass of radeon related components.

 The following NEW package is going to be installed:
  kernel-desktop-3.11.10-17.2 
The following 11 NEW patches are going to be installed:
  openSUSE-2013-879 openSUSE-2013-992 openSUSE-2014-109 openSUSE-2014-157 openSUSE-2014-212 
  openSUSE-2014-307 openSUSE-2014-322 openSUSE-2014-377 openSUSE-2014-423 openSUSE-2014-441 
  openSUSE-2014-78 
[snip]
Additional rpm output:
Kernel image:   /boot/vmlinuz-3.11.10-17-desktop
Initrd image:   /boot/initrd-3.11.10-17-desktop
KMS drivers:     radeon
Root device:    /dev/disk/by-id/ata-WDC_WD2003FZEX-00Z4SA0_WD-WMC1F1408634-part2 (/dev/sda2) (mounted on / as ext4)
Resume device:  /dev/disk/by-id/ata-WDC_WD2003FZEX-00Z4SA0_WD-WMC1F1408634-part1 (/dev/sda1)             
Microcode: Adding AMD microcode microcode_amd.bin
Kernel Modules: thermal_sys thermal processor fan scsi_dh scsi_dh_emc scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw i2c-algo-bit drm drm_kms_helper ttm radeon xhci-hcd hid-logitech-dj hid-holtek-kbd hid-lenovo-tpkbd hid-ortek hid-roccat hid-roccat-common hid-roccat-arvo hid-roccat-isku hid-samsung ohci-pci 
Firmware:       radeon/R520_cp.bin radeon/RS600_cp.bin radeon/RS690_cp.bin radeon/R420_cp.bin radeon/R300_cp.bin radeon/R200_cp.bin radeon/R100_cp.bin radeon/SUMO2_me.bin radeon/SUMO2_pfp.bin radeon/SUMO_me.bin radeon/SUMO_pfp.bin radeon/SUMO_rlc.bin radeon/PALM_me.bin radeon/PALM_pfp.bin radeon/CYPRESS_smc.bin radeon/CYPRESS_rlc.bin radeon/CYPRESS_me.bin radeon/CYPRESS_pfp.bin radeon/JUNIPER_smc.bin radeon/JUNIPER_rlc.bin radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin radeon/REDWOOD_smc.bin radeon/REDWOOD_rlc.bin radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin radeon/CEDAR_smc.bin radeon/CEDAR_rlc.bin radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/R700_rlc.bin radeon/R600_rlc.bin radeon/RV710_smc.bin radeon/RV710_me.bin radeon/RV710_pfp.bin radeon/RV740_smc.bin radeon/RV730_smc.bin radeon/RV730_me.bin radeon/RV730_pfp.bin radeon/RV770_smc.bin radeon/RV770_me.bin radeon/RV770_pfp.bin radeon/RS780_me.bin radeon/RS780_pfp.bin radeon/RV670_me.bin radeon/RV670_pfp.bin radeon/RV635_me.bin radeon/RV635_pfp.bin radeon/RV620_me.bin radeon/RV620_pfp.bin radeon/RV630_me.bin radeon/RV630_pfp.bin radeon/RV610_me.bin radeon/RV610_pfp.bin radeon/R600_me.bin radeon/R600_pfp.bin radeon/ARUBA_rlc.bin radeon/ARUBA_me.bin radeon/ARUBA_pfp.bin radeon/CAYMAN_smc.bin radeon/CAYMAN_rlc.bin radeon/CAYMAN_mc.bin radeon/CAYMAN_me.bin radeon/CAYMAN_pfp.bin radeon/CAICOS_smc.bin radeon/CAICOS_mc.bin radeon/CAICOS_me.bin radeon/CAICOS_pfp.bin radeon/TURKS_smc.bin radeon/TURKS_mc.bin radeon/TURKS_me.bin radeon/TURKS_pfp.bin radeon/BTC_rlc.bin radeon/BARTS_smc.bin radeon/BARTS_mc.bin radeon/BARTS_me.bin radeon/BARTS_pfp.bin radeon/HAINAN_smc.bin radeon/HAINAN_rlc.bin radeon/HAINAN_mc.bin radeon/HAINAN_ce.bin radeon/HAINAN_me.bin radeon/HAINAN_pfp.bin radeon/OLAND_smc.bin radeon/OLAND_rlc.bin radeon/OLAND_mc.bin radeon/OLAND_ce.bin radeon/OLAND_me.bin radeon/OLAND_pfp.bin radeon/VERDE_smc.bin radeon/VERDE_rlc.bin radeon/VERDE_mc.bin radeon/VERDE_ce.bin radeon/VERDE_me.bin radeon/VERDE_pfp.bin radeon/PITCAIRN_smc.bin radeon/PITCAIRN_rlc.bin radeon/PITCAIRN_mc.bin radeon/PITCAIRN_ce.bin radeon/PITCAIRN_me.bin radeon/PITCAIRN_pfp.bin radeon/TAHITI_smc.bin radeon/TAHITI_rlc.bin radeon/TAHITI_mc.bin radeon/TAHITI_ce.bin radeon/TAHITI_me.bin radeon/TAHITI_pfp.bin radeon/BONAIRE_uvd.bin radeon/TAHITI_uvd.bin radeon/SUMO_uvd.bin radeon/CYPRESS_uvd.bin radeon/RV710_uvd.bin radeon/KABINI_sdma.bin radeon/KABINI_rlc.bin radeon/KABINI_mec.bin radeon/KABINI_ce.bin radeon/KABINI_me.bin radeon/KABINI_pfp.bin radeon/BONAIRE_sdma.bin radeon/BONAIRE_rlc.bin radeon/BONAIRE_mc.bin radeon/BONAIRE_mec.bin radeon/BONAIRE_ce.bin radeon/BONAIRE_me.bin radeon/BONAIRE_pfp.bin 
Features:       acpi amd_microcode kms plymouth block usb resume.userspace resume.kernel

Perhaps that helped. I will stick with kernel-desktop-3.11.10-17.2 for now, trusting that improved boot parameters and some understanding of how the radeon driver works may allow me to proceed.

Thank you very much to taking time to assist.

wolfi323 · June 26, 2014, 11:36am

Well, it’s easy: the proprietary driver (no matter which version) will not work for you.

Tried “video=800x600@60” improved display but still low resolution and not full screen.

Well, of course. This sets the resolution to 800x600 (but it has no effect when “nomodeset” is specified as well).
You could try “video=1024x768@60” or even “video=1600x900@60” (not sure if that one would work, but you can try).

Tried both together and had 1024x768 screen (no options to change in display manager) but was able to load radeon driver with modprobe.

You don’t need both.
The drm_kms_helper.edid_firmware option overrides what the monitor reports as its native resolution. As you specified the 1024x768.bin EDID file, the system thinks now that your monitor only supports 1024x768.

This is real progress. Can you tell me more? What setting should be used to allow full capabilities of HD 4200? What setting should be used to allow Claimed max resolution 1600x900@60 of this monitor?

OK, so it definitely seems to be an EDID problem.
It’s not about the capabilities of your graphics card, but about the capabilities of your monitor.

But the kernel unfortunately does not ship with 1600x900 data. The available options are only 800x600, 1024x768, 1280x1024, 1600x1200,1680x1050, 1920x1080.
If you are satisfied with one of those, specify it instead of 1024x768.bin, f.e.:

drm_kms_helper.edid_firmware=edid/1680x1050.bin

It is possible to create and supply your own EDID file, preferably with the correct data specifically for your monitor though (the one that the monitor should report in the first place).

But first, is your monitor connected directly to the computer, or via a KVM switch? Some of those switches won’t route through the EDID data correctly. In that case it would be the easiest to just connect the monitor directly, read out the EDID data to a file and supply that to the kernel. Then it would work the same when it is connected via the switch.

If you don’t care much about the text mode resolution, just stick with one of the predefined one. It should be possible to just add an Xorg modeline with your preferred resolution for graphics mode in any case, see here f.e.:
https://en.opensuse.org/SDB:Configuring_graphics_cards_and_monitor_settings

tallowwood · June 26, 2014, 5:35pm

wolfi323:

OK, so it definitely seems to be an EDID problem.
It’s not about the capabilities of your graphics card, but about the capabilities of your monitor.

But the kernel unfortunately does not ship with 1600x900 data. The available options are only 800x600, 1024x768, 1280x1024, 1600x1200,1680x1050, 1920x1080. If you are satisfied with one of those, specify it instead of 1024x768.bin, f.e.:
drm_kms_helper.edid_firmware=edid/1680x1050.bin

It is possible to create and supply your own EDID file, preferably with the correct data specifically for your monitor though (the one that the monitor should report in the first place).

But first, is your monitor connected directly to the computer, or via a KVM switch? Some of those switches won’t route through the EDID data correctly. In that case it would be the easiest to just connect the monitor directly, read out the EDID data to a file and supply that to the kernel. Then it would work the same when it is connected via the switch.

If you don’t care much about the text mode resolution, just stick with one of the predefined one. It should be possible to just add an Xorg modeline with your preferred resolution for graphics mode in any case, see here f.e.:
https://en.opensuse.org/SDB:Configuring_graphics_cards_and_monitor_settings

Thanks for your valuable advice. The optimum and maximum resolution of the S20A300B monitor is 1600x900@60, so from available kernel options, seems I need to stick with 1024x768 for now. Thanks also for pointers on EDID. I will investigate that further.

The monitor provides DVI-D and 15pin D-sub input connectors. It is connected directly to the PC via 15pin-to-15pin D-sub cable since PC (onboard radeon graphics) does not provide DVI-D output socket. Could this compound the EDID issue?

I use both text and graphics screens. Even with drm_kms_helper.edid_firmware=edid/1024x768.bin set at boot and the radeon driver then loaded the 1024x768 screen is centered within the monitor and unsatisfactory for regular use in either text or graphic modes. Images and text are out of focus and overflow off screen at each edge. I will try adding an Xorg modeline to improve graphic display, as you suggest.

Your advice about the drm_kms_helper.edid_firmware=edid/1024x768.bin boot setting has enabled me to get the radeon driver loaded (the purpose of this thread) and your thoughtful diagnosis has confirmed the souce of the problem, the monitor in this case.

Thank you for taking time to assist me.

wolfi323 · June 26, 2014, 6:04pm

No.
EDID works fine via 15 pin D-sub VGA. That’s what it was designed for originally.

Unless there is something wrong with the cable of course. The EDID data is transferred via a dedicated line, maybe that is missing/broken?
But you should get at least a display then, with some basic resolution.

I use both text and graphics screens. Even with drm_kms_helper.edid_firmware=edid/1024x768.bin set at boot and the radeon driver then loaded the 1024x768 screen is centered within the monitor and unsatisfactory for regular use in either text or graphic modes. Images and text are out of focus and overflow off screen at each edge.

This should not happen.
You should be able to adjust your monitors settings accordingly, actually it should adjust itself automatically.

You could of course also try a newer kernel as already suggested.
Maybe there was/is a bug in the 3.11 one that affects you. But I don’t know how probable that is.

gogalthorp · June 26, 2014, 6:54pm

I have had the problem because I use a KVM switch. It can be corrected in xorg so follow instruction on the page Wolfi suggested.

https://en.opensuse.org/SDB:Configuring_graphics_cards_and_monitor_settings

tallowwood · June 27, 2014, 6:45am

Thanks kind responders. I have not tried kernel update yet. That led me into some trouble in the past. Very ignorant ‘general user’ here, despite many years using openSUSE OS ‘just working’ on my main machine. No KVM switch, but will try xorg mod as suggested.

When I connect S20A300B monitor to my laptop via D-Sub running openSUSE 13.1 x86_64 with onboard INTEL graphics the monitor starts with optimum 1600x900@60 resolution and performs well, with a range of available resolutions shown in KDE Display Manager, all switchable. So maybe monitor EDID is not the only problem. Perhaps the D-sub connector on the HP N54L MicroServer could be faulty? Or perhaps the problem is indeed kernel related?

Would it be useful to try to reinstall the OS using Full DVD. Are there useful boot parameters I should try that may force EDID read or otherwise overcome the blank screen issue after startup menu without preventing the radeon driver loading?

tallowwood · June 27, 2014, 9:14am

Sorry to spam this thread but further to previous post. Tried running openSUSE 13.1 x86_64 KDE_Live CD without boot parameters, result blank screen. Tried running openSUSE 11.4 x86_64 KDE_Live CD without boot parameters, result success.

Status report:
Processor (CPU): AMD Turion™ II Neo N54L Dual-Core Processor
Total memory (RAM): 1.8 GiB
OS: Linux 2.6.37.1-1.2-desktop x86_64 (openSUSE 11.4 (x86_64) KDE: 4.6.00 (4.6.0) “release 6”
Display: Vendor ATI Technologies Inc, Model: ATI Mobility Radeon HD Graphics, 2D driver: radeon, 3D driver: swrast (7.10)

System detected and applied S20A300B monitor optimal resolution 1600x900@60 automatically. Ah, the joys of older hardware

wolfi323 · June 27, 2014, 9:16am

openSUSE keeps more than one kernel.
So if you would have problems with the new one, you could still boot the older one in “Advanced Options” in the boot menu.

When I connect S20A300B monitor to my laptop via D-Sub running openSUSE 13.1 x86_64 with onboard INTEL graphics the monitor starts with optimum 1600x900@60 resolution and performs well, with a range of available resolutions shown in KDE Display Manager, all switchable. So maybe monitor EDID is not the only problem. Perhaps the D-sub connector on the HP N54L MicroServer could be faulty? Or perhaps the problem is indeed kernel related?

Ok, then the monitor’s EDID seems to be ok.

Well, then I only see two possible issues:

the connector on your laptop is broken (or some other hardware problem there)
a bug in the radeon kernel module

For the first one there wouldn’t be much you can do except for providing a file with the correct EDID. You could try to read the EDID manually to see whether this is the problem. See below for instructions.
If yes, you could extract the correct one on your other system and specify this on the kernel command line, then your monitor should work perfectly.

For the second one, the updated kernel might help.

Would it be useful to try to reinstall the OS using Full DVD. Are there useful boot parameters I should try that may force EDID read or otherwise overcome the blank screen issue after startup menu without preventing the radeon driver loading?

Not that I know of, except that drm_kms_helper.edid_firmware one.

A possible way to read the EDID data from the monitor:

switch to root:

su

install the “i2c-tools” if they are not installed:

zypper in i2c-tools

Load the “i2c-dev” kernel module:

modprobe i2c-dev

Run this to find out the correct i2c adapter:

i2cdetect -l

I get this f.e.:

amiga:/home/wolfi # i2cdetect -l
i2c-0   i2c             Radeon i2c bit bus DVI_DDC              I2C adapter
i2c-1   i2c             Radeon i2c bit bus VGA_DDC              I2C adapter
i2c-2   i2c             Radeon i2c bit bus MONID                I2C adapter
i2c-3   smbus           SMBus Via Pro adapter at 0400           SMBus adapter
i2c-4   i2c             B2C2 FlexCop I2C to demod               I2C adapter
i2c-5   i2c             B2C2 FlexCop I2C to eeprom              I2C adapter
i2c-6   i2c             B2C2 FlexCop I2C to tuner               I2C adapter
i2c-7   i2c             CX24123 tuner I2C bus                   I2C adapter

So in my case “i2c-1” is the correct one, as the monitor is connected via VGA.

You can then display the EDID data with the command:

i2cdump 1 0x50

You should replace the ‘1’ with the number from the previous command of course. If the correct i2c adapter is i2c-0 in your case f.e., you should use “i2cdump 0 0x50” and so on.

Please post the output, I could have a look at it then.

wolfi323 · June 27, 2014, 9:29am

Ok, I guess we can rule out a hardware problem then.

But I think on 11.4 the “radeon” driver did not support your graphics card yet, I suppose the “radeonhd” driver was used there which is a no-KMS one.
Or maybe just fbdev/mesa.

Edit: Oops, I just saw that it was indeed radeon, but without 3D support.

Anyway, I suppose this would pin it down to a bug in the “radeon” kernel module in 3.11.
As already said, the latest kernel might help then.

tallowwood · June 28, 2014, 3:05pm

Vielen Dank für eure Hilfe Wolfi323

FWIW: I noted the same sort of issues with CentOS 6.5 and Ubuntu Server 14.01. I lack the skill to scope ‘bugs’ like this and cannot find similar issues reported elswhere. I could see no signs of recent updates on the Xorg radeon developers list since late 2013. I wonder if the problem is complicated by specific S20A300B monitor issues in some way, so may just be a fault, not be a bug. I am reinstalling now. I will check latest kernel and report back if that helps, just to close this thread. I am sure your advice on EDID issues in particular will be of help to other users.

I am very grateful to all the skilled and helpful responders who make this support forum such a valuable resource for openSUSE users.

rrdonovan · July 1, 2014, 10:57pm

I have the same problem. An HP Prolient Microserver with the Radeon 4250 graphics card. It has been shear torture. Especially running around in circles. OK, fine. If there is no support for this card in Bottle-13.1, simply say, not useable. That would end hours and hours of hunting and trying everything under the sun. I pretty much had Nvidia squared away. I had heard good things about ATi/AMD so I figured it would be good. Wrong. I found it hard to believe that running Precise Puppy from a flash drive will automatically set me to 1024x768. After running Xorgwizard, I can get 1600x1200. Video has always been problematic with openSUSE. I love the brand, but I must say that there must be a better way for taking care of our video problems.

Master Rod

wolfi323 · July 2, 2014, 11:33am

File a bug report. Or use something else.

For me video has never been problematic with openSUSE.

oldcpu · July 3, 2014, 4:44pm

Hopefully a bug report will help.

I also never had openSUSE specific graphic problems. When I have had graphic problems with openSUSE, the same problems also affected other distributions. Sometimes other distributions had different work around approaches set up to run automatically, or had different kernel versions, but in all such cases it was possible for me to adopt same approach (by same approach I mean adopt same work around as other distro, or change kernel version on my distro to one where driver worked better).

Example-1: I had a case with old Intel graphic hardware where Intel driver support was mostly broken. The work around there was to use the vesa driver , or to disable special desktop effects. This was a GNU/Linux distribution wide problem.

Example-2 : I had a case where nouveau driver was broken for openSUSE for old FX-5200 hardware (and also broken for all other distros). I spotted a purported fix for this on the web, passed it to the openSUSE bug report that I raised, the fix was applied to openSUSE test kernel, some of us tested it and it worked, and then it was applied to openSUSE baseline kernel before most other distributions applied the same fix .

… I could go on with other examples, but in all cases there was no ‘problematic’ with openSUSE graphics problem. I type this noting between my wife and myself, we currently have 2-laptops, and four desktop PCs, all with different graphic hardware. All the graphic hardware just works with openSUSE. Over the years, we also have disposed of more than the above PCs/laptops, all with different hardware, and I never had any ‘problematic’ graphic issues unique to openSUSE.

As a long-in-the-tooth openSUSE user, I am very appreciative of the support from the openSUSE packagers and developers. In particular, I am very appreciate of the support wolfi323 has given in graphics to our forum. His support in graphics has been a blessing, in quickly helping users to resolve their problems.