Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My system has hybrid (and I believe muxless,i.e. only the integrated card is actually connected to the display) graphics. The first card is an Intel HD 4400, and the second card is the AMD Radeon HD 8670M (solar system series, not OLAND). Thus, currently the open-source radeon driver does not support the card, and I am forced to use the proprietary fglrx driver.

Why not just turn the dGPU card off without fglrx?

I have no need of fancy graphics and would be happy to simply turn the discrete ATI card off, so long as it was properly switched off and was not overheating/eating battery. The options to do this without fglrx and pxpress seemed limited to me: I have no vgaswitcheroo switch (even before fglrx was ever installed) and I can only deduce this was because the radeon driver does not yet support my card/does not properly load it yet, see my question here for more on that and the things I tried. Other methods like acpi_call have been reported as at best "proof of concept" and at worst dangerous, so I'd rather not venture into using them. More reliable projects like bumbleebee are nividia only.

Simply leave the AMD card driverless

Relying on just the i915 intel driver works flawlessly, no bugs, no problems, however the AMD card is then left UNCLAIMED and could possibly lead to overheating/battery drain, so I am not so happy about that.

Ubuntu 12.04 LTS with fglrx

I started here, and experienced a bug when the iGPU was selected. This bug manifests itself whenever the screen is locked, the laptop lid is closed, or even when the computer is left inactive with something like xscreensaver installed instead with no lockscreen enabled. It causes a black screen with a moveable cursor only; switching tty and back does not recover, and a restart from the tty is needed. It does not happen every single time but happens pretty regularly, at least once or twice day. All saved work is lost.

I tried both the fglrx in the repos, and the latest 13.10 from the AMD website. No change.

When the dGPU is selected instead (from the AMD Catalyst control centre, or ultimately by pxpress) this bug does not occur, but I had another bug which I won't bother getting into here.

Ubuntu 13.10 with fglrx

A very similar bug here but not quite as severe. Exactly the same conditions, namely lockscreen, lidclose, inactivity (if xscreensaver is being used). This time the frozen screen is not black, but a picture of your desktop at the moment of the freeze, again with moveable cursor. Here I only tried the latest fglrx AMD drivers 13.10.

Again no problems with just the i915 driver (no fglrx) and again no problems with dGPU selected.

Some things I tried:

1) Disabling vsync. I tried this both in compiz settings manager, and by aticonfig --sync-vsync=off followed by reboot. No change.

2) Turning DPMS off. Option "DPMS" "false" in the xorg.conf monitor stanza. (Of course, I also changing gnome settings "Do Nothing/Don't suspend" for battery and AC too).No change.

3) Option "AIGLX" "off" in server flags of xorg.conf. No change.

4) Modifying the atieventsd so it worked properly for Ubuntu, see my post here. And also, running without it. No change.

5) Booting with the options

Option      "Capabilities" "0x00000800"
Option      "KernelModuleParm" "locked-userpages=0"
Option      "NoAccel" "True"

in the xorg.conf Device stanza. No change.

6) Booting with nomodeset as kernel parameter. No change.

7) Turning off acpi interaction from aticonfig:


No change.

Why does it work with just intel?

One thing I don't understand is why it works with the just the intel i915 driver. I thought pxpress would just hand over control to that driver on bootup, so if it worked with the i915 alone, I'd have expected it to work with pxpress selecting igpu.

I know fglrx installs its own libGl implemenation also, but it switches back to the old stock MESA libGL implementation when the intel card is selected (c.f. /usr/lib/fglrx/switchlibGL python script).

So when igpu selected, it should be exactly equivalent to life before fglrx after a reboot?

share|improve this question
First off, what hardware is it? Ive been fighting to get 12.04 to install drivers for a newer edition radeon, and ive seen all of the outputs youve posted, and ive seen them all change with different drivers ruinning. dont know how drivers affect detection that much but apparantly they do. I think you should decide based on what hardware is ACTUALLY in there and what you need it to do( hardware acceleration, 3d stuff, etc – drunkScientist Jan 24 '14 at 6:20
Well it's a Radeon HD 8670M (Mars XT, solar system series). the open source radeon driver does not support my card yet anyway (not to be confused with OLAND), so I pretty much had no choice but to use fglrx drivers. I upgraded to Ubuntu 13.10, and use the latest AMD Catalyst 13.12, and they work OK, bar the fact that when I choose the iGPU I get a freeze on lockscreen/lid close which switching to a tty and back cures (on 12.04 this freeze needed a restart from the tty) – fpghost Jan 24 '14 at 7:34
Still experiencing issues? What about a live cd? – Braiam Jan 25 '14 at 2:44
I would try to remove completely the fglrx (since it doesn't happens with a live cd) and then install it again following the same principle as the live cd (you may want to check the driver used by the live cd) or try to upgrade to 13.10. If that doesn't work you should consider reinstallation. – Braiam Jan 25 '14 at 12:57
I rewrote this question to reflect the current state of my efforts... – fpghost Jan 25 '14 at 17:30
up vote 1 down vote accepted

After a long time looking into this, I came to release the key point: when fglrx/pxpress loads the Intel driver, it does so with the UXA acceleration method, whereas by default (on a Haswell system running 13.10, pre-fglrx install) the Intel driver would load with the SNA acceleration method.

I tested by booting with an xorg.conf that looked like:

Section "Device"
        Identifier      "Intel Graphics"
        Driver          "intel"
        Option          "AccelMethod"  "UXA" # (fglrx uses this) I can see the bug
        #Option          "AccelMethod"  "SNA" #(default) no bug!

Section "Monitor"
           Identifier      "Configured Monitor"

Section "Screen"
        Identifier      "Default Screen"
        Monitor         "Configured Monitor"
        Device          "Configured Video Device"

Now even this Intel xorg.conf gave the freeze bug after a lid close or two. Yet booting with the exact same config file, only with

Option          "AccelMethod"  "SNA" 

I got no bug whatsoever, no matter how many lid closes/screen locks (this is the default method for the driver anyway, and this is why I was perplexed, because it fooled me into thinking all was good with the intel driver and fglrx was tainting things).

Now that I realised this was a intel driver problem, some googling led me to discover a fix. Create a file ~/.drirc to config the DRI settings, containing

<device screen="0" driver="dri2">
        <application name="Default">
                <option name="vblank_mode" value="0"/>

This turns off vsync (the setting that makes your GFX card sync to the screen refresh rate, rather than speeding away at its intrinsic framerate, to avoid tearing). Note: there is no point turning off vsync with aticonfig as in my OP as this will just turn it off for the dGPU not the Intel card. I'm not sure why my attempt at turning it off with Compiz Settings Manager did not work though.

Even with the UXA method, turning off vsync this way stopped the crash, even for the fglrx xorg.conf.

Even better would be to somehow configure pxpress to load the Intel driver with the SNA options, see my post here

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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