What is best way to change video controller?

English Hardware
1

I am running Leap 42.1, KDE, on a Dell Ivy Bridge computer. This computer has Intel i915 on board video that I am not using. It came with an AMD Radeon HD7570 (it was marketed as a Win gaming machine but the price was too good to pass up) which I am using with fglrx. Considering that recently Bruno made an announcement that development would be discontinued on the fglrx and that it doesn’t work in 42.2, I think I need to switch to a different video controller. I’m currently using an HDMI cable from AMD to digital screen for audio & video.

I want to switch to using the onboard Intel video controller. I figured I’d start by uninstalling the fglrx, then change my video output from the AMD to the Intel.
What I’m unclear about is if this is the best way, and what should I do when I boot so the the correct drivers are installed?

I’m going to have to deal with the audio, the onboard Intel has an hdmi output so it may be easy to reconfigure.

I’d also like to know if I should instead of above be thinking about replacing the AMD video card with a pci-e card that is more compatible with Leap and not fool with the onboard Intel controller. In that case, what would be a good replacement card?

2

Hi
Just use the radeon driver? Else just leave the card in and switch to the on-board card via BIOS, it should just start using it… if the i915 is working then shutdown and pull the AMD card and carry on.

For a replacement AMD GCN type card, all depends on your hardware/PCIe slot and whether a newer card will function in it… Switch to an Nvidia card suitable for your hardware?

3

I was unaware that there was a radeon driver other than flgrx. So would I uninstall flgrx and then the system would reconfigure to use the libdrm_radeon.so.1 driver that is available?

I did not find a BIOS switch specifically for the intel video controller so I guess it’s ‘on’, no cable is connected to the output. The BIOS setup is rather user-limited compared to other machines I have used. I guess that is good for Dell Support purposes.

For a replacement AMD GCN type card, all depends on your hardware/PCIe slot and whether a newer card will function in it… Switch to an Nvidia card suitable for your hardware?

I have no knowledge if an Nvidia card is suitable. That fact that you bring that up means I have more researching to do.

I guess my problem is I don’t know why I am using the flgrx driver rather than something else to begin with. Back when I installed it I was using a different monitor & v13.1. It’s only 4 yrs but my memory doesn’t go back that far:P

Thanks for your information, it’s given me a place to start.

4

Hi
Yes, if you uninstall the fglrx driver, make sure there is no radeon blacklist file in /etc/X11/xorg.conf.d directory all should be good. If you run the above lspci command it should show radeon, fglrx and kernel module in use fglrx. Once you remove it should just be radeon.

5

There is not a (as in single) driver, but rather a driver stack (i.e. several driver parts which work together).

radeon colloquially refers to the open source software (oss) driver stack that supports a wide range of AMD graphics adapters (but does not extend to the most recent adapters of the “GCN” class). Several of the components in that stack happen to be called a name containing “radeon” (ex. the radeon.ko kernel driver, or the radeon_drv.so xorg driver). I’m sure that contributes to the general/ordinary user’s confusion of there being “a” driver vs. the reality of there being a driver stack.

fglrx is the package for a proprietary driver stack from AMD. Like the case above, “fglrx” is a part of the name of several components within that stack.

So would I uninstall flgrx and then the system would reconfigure to use the libdrm_radeon.so.1 driver that is available?
If you uninstall the fglrx stack, and remove any blacklisting of the radeon compnent that it may have put in place, then yes, the oss radeon driver stack will be used for that adapter.

Note that libdrm_radeon is a piece in the oss driver stack puzzle, and it will be utilised when the fglrx stuff is uninstalled, but it is not “the” driver.

I did not find a BIOS switch specifically for the intel video controller so I guess it’s ‘on’, no cable is connected to the output. The BIOS setup is rather user-limited compared to other machines I have used. I guess that is good for Dell Support purposes.
If the intel adapter is enabled (receiving power), then it will be listed in the output of the following command:

/sbin/lspci -nnk|  egrep 'VGA|3D|Display' -A3

There is also the possibility that having the other adapter installed (AMD in this case) results in the intel device being switched off. You’d want to see if there was anything mentioned about IGD (integrated graphics device) and PEG (PCIe graphics).

I have no knowledge if an Nvidia card is suitable. That fact that you bring that up means I have more researching to do.
You already have two very good choices available to you: the intel or the AMD adapters. Why don’t you see if one of those suffices before you waste time and money on something else.

I guess my problem is I don’t know why I am using the flgrx driver rather than something else to begin with. Back when I installed it I was using a different monitor & v13.1. It’s only 4 yrs but my memory doesn’t go back that far:P
Because, at some point in time, you installed the fglrx driver package. It will configure itself to be used instead of the oss driver stack.

6

Thank you Malcolm & Tyler for the great info,

 sudo /sbin/lspci -nnk|  egrep 'VGA|3D|Display' -A3
root's password:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 7570] [1002:675d]
        Subsystem: Dell Device [1028:2b22]
        Kernel driver in use: fglrx_pci
        Kernel modules: radeon, fglrx

Appears as if the kernel module is loaded, so just the removal of fglrx seems to be the answer?

It makes sense that the AMD is disabling the on board Intel and this is useful info.
Since it seems that the current radeon stack may be sufficient I will certainly try that first.

The only reason I was pondering a new card was that I figured if Dell was marketing my machine with an add-on card then the on board intel must be deficient in some way. I can understand that maybe a gamer may want more graphic capability. I’m not a gamer, maybe Sudoko is the most I ever play, if ever.

I don’t see any blacklisting in /etc/X11/xorg.conf.d but will check again before I make any adjustments.

7

I don’t see any blacklisting in /etc/X11/xorg.conf.d but will check again before I make any adjustments.

No, the .conf file for blacklisting the kernel driver is in /etc/modprobe.d/ directory.

8

yep

It makes sense that the AMD is disabling the on board Intel and this is useful info.
Looks like that is the case with your motherboard.

Since it seems that the current radeon stack may be sufficient I will certainly try that first.

The only reason I was pondering a new card was that I figured if Dell was marketing my machine with an add-on card then the on board intel must be deficient in some way. I can understand that maybe a gamer may want more graphic capability. I’m not a gamer, maybe Sudoko is the most I ever play, if ever.
I think that either will suffice just fine for you … and, yes, a gamer would not be satisfied with the intel’s 3D performance … but for ordinary users, its fine.

I don’t see any blacklisting in /etc/X11/xorg.conf.d but will check again before I make any adjustments.
Oops, meant to address that earlier but forgot, but Deano has corrected the point about it.

9

In 50-blacklist.conf I have an entry “blacklist radeonfb”

So fb likely means frame buffer but is that what I have?

Oh…and…
There is also a file ‘50-fglrx.conf’ and it contains “blacklist radeon”
This is obviously the file/entry referenced. In addition should I also comment out the above radeonfb? That is, I need to remove both entries?

FYI,
Xorg.0.log contains statements for fglrx such as LoadModule: “fb” and shows loading /usr/lib64/xorg/modules/libfb.so

10

yes, that is exactly what it stands for … radeonfb is an old driver for the FBDev (I.e. console framebuffer environment). Just leave it blacklisted … (The vesafb or efifb drivers will be used instead, but themselves give way to the fb driver embedded in the radeon kernel driver, radeondrmfb).

Oh…and…
There is also a file ‘50-fglrx.conf’ and it contains “blacklist radeon”
This is obviously the file/entry referenced.
yep

In addition should I also comment out the above radeonfb? That is, I need to remove both entries?
nope; see above

FYI,
Xorg.0.log contains statements for fglrx such as LoadModule: “fb” and shows loading /usr/lib64/xorg/modules/libfb.so
that’s (libfb) normal to be loaded … It’d be used for software rendering of Xrender operations

11

I’d like to thank Malcolm, Tyler, & Deano for walking me through changing from fglrx to radeon driver. Messing with the system always makes me nervous because one little mistake and it becomes a nightmare.

Regarding the blacklist in modprobe.d, I note that when using YaST to remove fglrx it also removes that blacklisting file.
My situation now is:

sudo /sbin/lspci -nnk|  egrep 'VGA|3D|Display' -A3
root's password:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 7570] [1002:675d]
        Subsystem: Dell Device [1028:2b22]
        Kernel modules: radeon, fglrx
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Turks/Whistler HDMI Audio [Radeon HD 6000 Series] [1002:aa90]

I note that before this change there was no listing for the Audio.

So one major display problem remains. The radeon driver leaves me at 1280x1024 default with no options in the System Settings Display Configuration to change to any other resolution.

In Xorg.0.log the Kernel command line contains video=1280x1024 nomodeset
This makes me wonder if I should change the boot command and if so, what is appropriate.
My monitor is capable of 1920x1080 but I prefer 1680x1050. Now that I am using the radeon driver, is that possible? And if so, how?

With the flgrx driver, Xorg.0.log used to show a large selection of possible resolutions. Now, it shows:

FBDEV(0): Modeline "current"x0.0  131.09  1280 1312 1472 1632  1024 1028 1032 1048 -hsync -vsync -csync (80.3 kHz b)

That indicates to me that I can do 1632x1048, is that correct? If so, what should I do next.

12

Yes, removing the rpm(s) does take care of this.

My situation now is:

sudo /sbin/lspci -nnk|  egrep 'VGA|3D|Display' -A3
root's password:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 7570] [1002:675d]
        Subsystem: Dell Device [1028:2b22]
        Kernel modules: radeon, fglrx
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Turks/Whistler HDMI Audio [Radeon HD 6000 Series] [1002:aa90]

I note that before this change there was no listing for the Audio.

So one major display problem remains. The radeon driver leaves me at 1280x1024 default with no options in the System Settings Display Configuration to change to any other resolution.

No, the radeon driver is not loaded. The lspci output should say something like ‘Kernel driver in use: radeon’. A framebuffer driver is in use currently, which explains the low display resolution.

13

In Xorg.0.log the Kernel command line contains video=1280x1024 nomodeset

You need to remove the ‘nomodeset’ parameter. That is why the KMS radeon driver did not load.

14

Thank you, that was a big help. Also took care of another persistent problem I’ve had. When I went to tty console the vertical edges of the screen were never right, the text was cut off on the left and I would have to do a screen reset. So I found I was using vga=0x31a which is 794. I changed it to 791, 0x317, and now that alignment problem seems to be solved. I need a few more boots to be sure.

Still have a problem tho. Booting now gives me the max screen size of 1920x1080. I reduce it in the Display Settings but it does not maintain itself through a restart. I had this same problem when using flgrx driver. I solved that with edit of /etc/xorg.conf by adding the SubSection “Display”:

Section "Screen"
        Identifier "amdcccle-Screen[1]-0"
        Device     "amdcccle-Device[1]-0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes   "1680x1050" "1280x1024" "1024x768" "640x480"
        EndSubSection
EndSection

That file now seems to have been replaced with /etc/xorg.conf.d and apparently I should modify 50-device.conf
Am I correct? Of course, the above cannot be used, I know I need to make changes (replace amdcccle-* with HDMI-0). I don’t know about depth, maybe not necessary? I just need to know if this is the correct way to force 1680x1050 on bootup. Or is there another way?

15

Reads like progress! :slight_smile:

Still have a problem tho. Booting now gives me the max screen size of 1920x1080. I reduce it in the Display Settings but it does not maintain itself through a restart. I had this same problem when using flgrx driver. I solved that with edit of /etc/xorg.conf by adding the SubSection “Display”:

Section "Screen"
        Identifier "amdcccle-Screen[1]-0"
        Device     "amdcccle-Device[1]-0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes   "1680x1050" "1280x1024" "1024x768" "640x480"
        EndSubSection
EndSection

That file now seems to have been replaced with /etc/xorg.conf.d and apparently I should modify 50-device.conf
Am I correct? Of course, the above cannot be used, I know I need to make changes (replace amdcccle-* with HDMI-0). I don’t know about depth, maybe not necessary? I just need to know if this is the correct way to force 1680x1050 on bootup. Or is there another way?

As long as the file is in /etc/X11/xorg.conf.d/ it doesn’t really matter what it is called (as long as it’s a .conf file of course).

16

Just to remind you of this thread:
https://forums.opensuse.org/showthread.php/517343-How-do-I-lock-my-screen-resolution

You can either make the required display mode changes via a .conf file in /etc/X11/xorg.conf.d/ (and disable the kscreen service as explained already in that thread), or you could just use the ‘Display and Monitor’ utility, which makes a user-level configuration in the ~/.local/share/kscreen/ directory. You might need to remove any existing configurations first

rm -f ~/.local/share/kscreen/*

Then set the desired display mode via System Settings > Display and Monitor, and click ‘Apply’. It should take effect immediately, (but you might end up missing part of your desktop until you make the necessary adjustments). It should also take effect when you next log back in.

17

Hello deano. I just realized you are already in 2017 while I’m still scrapping by in 2016. Happy New Year!

Regarding above, yes I had this problem before, this one is different in 2 ways, but agree that perhaps this should not make a difference.
First, in that thread, the solution was found on the web and involved modifying /etc/X11/x11org.conf, as stated in my prior post of this thread. Second, the driver is now different, flgrx is gone and using radeon. This certainly should not matter but has left me with problems. If the uninstall if flgrx had left a working xorg.conf I may not have these problems?

You can either make the required display mode changes via a .conf file in /etc/X11/xorg.conf.d/ (and disable the kscreen service as explained already in that thread),

I guess it’s not a good idea to disable the kscreen service, I’d probably find problems in the future. I only mentioned the .conf file in xorg.conf.d because I no longer have /etc/X11/xorg.conf file and thought that file was no longer required.

or you could just use the ‘Display and Monitor’ utility, which makes a user-level configuration in the ~/.local/share/kscreen/ directory.

This is what I’ve been doing with every startup since removing flgrx. It only sticks for the current session. The file you reference in kscreen has not updated in almost a year and still shows the max resolution of my screen in the mode: section.

You might need to remove any existing configurations first

rm -f ~/.local/share/kscreen/*

Then set the desired display mode via System Settings > Display and Monitor, and click ‘Apply’.

I deleted that file and performed the same reset of mode as you mention, and as I’ve done every time I’ve restarted. The file is not recreated. The directory remains empty and it still boots with the max resolution as default (which is bigger than my available screen by 1/4"). In addition to changing the resolution, there is a box to the upper left of the resolution slider “Primary Display”. When I start, that shows “No Primary Output”. I change that to the only other available selection “HDMI-0”. I mention this in case it is an important detail.

I cannot get a lower screen resolution to ‘stick’ and the only time I was successful was in the past when I made changes to xorg.conf that flgrx used, a file that is no longer present on my machine.

I have restored the deleted file in kscreen and tried editing the mode section to reduce the resolution. This did not work.

A prior post you made gives me the idea that it’s ok to have an xorg.conf file even though the install of radeon did not create one. Since I know that I can get a lower resolution on boot if I have certain statements in an xorg.conf file that seems to be a possible solution, but I don’t know if I can create one from scratch vs. merely editing one (which I don’t have for editing).

What should I try now?

18

It wasn’t solved by your change, it was resolved by the radeondrmfb driver’s handling of the mode for the monitor.

You don’t need the “vga=…” stuff. That boot option only affects the vesafb (console framebuffer) driver. Recall what I said in my prior post:

The vesafb or efifb drivers will be used … but themselves give way to the fb driver embedded in the radeon kernel driver, radeondrmfb
If you have an (u)efi based system it will be efifb, and, if not, then the vesafb will be utilised by default. However, the hand-off by those fb drivers to the radeondrmfb driver occurs very early. So, yeah, sure, you could set the mode used for the vesafb, but why bother given the KMS radeondrmfb will do a mode set to your monitor’s native resolution half a second later. In fact, you may not even see anything on screen before the radeondrmfb driver has already assumed control (making the user mode set for the vesa driver completely pointless).

To verify the process for yourself, you can read through the output of your dmesg (try “dmesg | more” and use the space bar to move forward one page at a time, or use the cursor keys for finer movement) … You’re likely to see that the hand-off between framebuffer drivers will typically occur within the first 5 seconds. Here, for example, is the process on my desktop/workstation (parsed slightly to contain only relevant output):

$ dmesg | grep -i 'fb\|console\|frame'
    0.000000] Console: colour dummy device 80x25
    0.000000] console [tty0] enabled
    2.186003] vesafb: mode is 1600x1200x32, linelength=6400, pages=0
    2.186003] vesafb: scrolling: redraw
    2.186005] vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0
    2.186018] vesafb: framebuffer at 0xd0000000, mapped to 0xffff9e9ac1000000, using 7552k, total 7552k
    2.224795] Console: switching to colour frame buffer device 200x75
    2.263315] fb0: VESA VGA frame buffer device
    4.762763] [drm] fb mappable at 0xC0247000
    4.762765] [drm] fb depth is 24
    4.762876] radeon 0000:01:05.0: fb1: radeondrmfb frame buffer device
    4.782107] fb: switching to radeondrmfb from VESA VGA
    4.782128] Console: switching to colour dummy device 80x25
    5.902836] [drm] fb mappable at 0xD0263000
    5.902838] [drm] fb depth is 24
    5.902974] fbcon: radeondrmfb (fb0) is primary device
    6.096901] Console: switching to colour frame buffer device 240x75
    6.103557] radeon 0000:02:00.0: fb0: radeondrmfb frame buffer device

My output will be slightly more complicated then what you’ll find simply due to the fact that I have two graphics adapters… but the process will be the same. It should be clear that vesafb begins on fb0 but is replaced by the radeondrmfb. The other console (fb1) that is setup (in parallel) is driven by the radeondrmfb from the get-go. Its interesting to note that fb1 “completes” before fb0 has made the transition.

19

I’m in a bit of a rush now so very quickly:

  • yes, you can still use a full xorg.conf if you wanted
  • the snippet files in the confd directory just make it easier to make minor changes without having to do up a whole full fledged conf file
  • radeon won’t generate a conf file … the configuration of X is done pretty much “auotmagically” these days … the user still has the option to provide other configuration options in the snippet or full fledged conf file.
  • your change should be easily to configure in the snippet, but do note that kcreen will initiate its own settings when the desktop starts
  • you can disable kscreen if you want (turn it off in Configure Desktop > Workspace > startup and shutdown > Background services)
  • wasn’t reading carefully, so not sure why kscreen was being problematic

Cheers

20

This is a bit over my head, I need to study it more carefully, like you, I’m in a bit of a rush also. When I boot, I do see my monitor show “1280x1024” and then when KDE starts it reverts to 1920x1080.

FWIW, this is my dmesg output:

dmesg | grep -i 'fb\|console\|frame'
    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
    0.000000] PM: Registered nosave memory: [mem 0xf8000000-0xfbffffff]
    0.000000] Console: colour dummy device 80x25
    0.000000] console [tty0] enabled
    0.006589] Security Framework initialized
    0.249814] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
    0.249816] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820
    0.305951] system 00:06: [mem 0xf8000000-0xfbffffff] has been reserved
    1.042339] vesafb: mode is 1024x768x16, linelength=2048, pages=0
    1.042339] vesafb: scrolling: redraw
    1.042340] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
    1.042347] vesafb: framebuffer at 0xe0000000, mapped to 0xffffc90001000000, using 1536k, total 1536k
    1.058349] Console: switching to colour frame buffer device 128x48
    1.074293] fb0: VESA VGA frame buffer device
    1.534405] systemd[1]: Starting Setup Virtual Console...
    1.637259] fb: switching to radeondrmfb from VESA VGA
    1.637280] Console: switching to colour dummy device 80x25
    2.581974] [drm] fb mappable at 0xE0475000
    2.581977] [drm] fb depth is 24
    2.582016] fbcon: radeondrmfb (fb0) is primary device
    2.605972] Console: switching to colour frame buffer device 160x64
    2.609440] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device