Bug 41265

Updated to correct component

You most likely have a mux-less system which means the radeon card is not actually connected to any physical displays as such there is no way for you to switch to the radeon card with vgaswitcheroo.  In order to support mux-less systems the xserver needs support for decoupling display and rendering and the drm needs support for sharing buffers between drivers.  This is a large amount of work and probably won't happen in the short term.

(In reply to comment #2)
> You most likely have a mux-less system 

I'm not so sure about that.
First off, the ATI card is in a "Media Dock" which is not part of the laptop and is connected via Intel's Thunderbolt connector.
Second, the laptop and media dock have separate vga/hdmi ouputs, the HDMI on the media dock doesn't work, the HDMI on the laptop always works so I suspect the HDMI ports are not on a shared bus.
Third, in Windows, when a monitor is connected to the media dock it shows as connected to the ATI card (according to the hardware info) while the laptop screen is shown as connected to the Intel card.
And lastly, from the attached log:

[drm:intel_dsm_platform_mux_info], MUX info connectors: 7
[drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010100
[drm:intel_dsm_platform_mux_info],   port id: Analog VGA
[drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[drm:intel_dsm_platform_mux_info],   hpd mux info: unknown

I am not so certain this is really a hybrid system in the sense we've seen so far. I think the cards might be separate and drive the monitors independently. This would mean that I don't need vgaswitcheroo to switch to the radeon card and would be able to just use xinerama with 2 cards.

I will try to connect 2 different monitors to the 2 HDMI ports tonight and see what windows thinks is connected to what.

In Windows, if a monitor is connected to a port on the laptop then it is shown as connected to the Intel card. If the monitor is connected to the external media dock then Windows shows it as connected to the Radeon card.

I played around with the fglrx proprietary driver (latest version 11.9) and I got two different results when my xorg.conf has 2 separate cards defined (fglrx and intel) vs only 1 card (fglrx only)

When defining 2 cards in xorg.conf I get this:

[  2060.069] (II) Loading sub module "fglrxdrm"
[  2060.069] (II) LoadModule: "fglrxdrm"
[  2060.069] (II) Loading /usr/lib/xorg/modules/linux/libfglrxdrm.so
[  2060.069] (II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
[  2060.069] 	compiled for 1.4.99.906, module version = 8.89.4
[  2060.072] ukiDynamicMajor: found major device number 252
[  2060.072] ukiDynamicMajor: found major device number 252
[  2060.072] ukiOpenByBusid: Searching for BusID PCI:22:0:0
[  2060.072] ukiOpenDevice: node name is /dev/ati/card0
[  2060.072] ukiOpenDevice: open result is 11, (OK)
[  2060.072] ukiOpenByBusid: ukiOpenMinor returns 11
[  2060.072] ukiOpenByBusid: ukiGetBusid reports PCI:22:0:0
[  2060.073] (==) fglrx(0): NoAccel = NO
[  2060.073] (==) fglrx(0): ATI 2D Acceleration Architecture enabled
[  2060.073] (--) fglrx(0): Chipset: "AMD Radeon HD 6700M Series" (Chipset = 0x6740)
[  2060.073] (--) fglrx(0): (PciSubVendor = 0x104d, PciSubDevice = 0x9084)
[  2060.073] (==) fglrx(0): board vendor info: third party graphics adapter - NOT original ATI
[  2060.073] (--) fglrx(0): Linear framebuffer (phys) at 0xb0000000
[  2060.073] (--) fglrx(0): MMIO registers at 0xc0200000
[  2060.073] (--) fglrx(0): I/O port at 0x00005000
[  2060.073] (==) fglrx(0): ROM-BIOS at 0x000c0000
[  2060.073] (II) fglrx(0): AC Adapter is used
[  2060.084] (II) fglrx(0): Invalid ATI BIOS from int10, the adapter is not VGA-enabled
[  2060.084] (EE) fglrx(0): Invalid video BIOS signature!
[  2060.084] (EE) fglrx(0): GetBIOSParameter failed
[  2060.084] (EE) fglrx(0): PreInitAdapter failed
[  2060.084] (EE) fglrx(0): PreInit failed


The invalid bios message.
However, when I only try to use 1 fglrx card (on pcibus 22:0:0), the driver correctly detects there an intel card and loads drivers for it but then blows up with another message:

[  1920.534] (WW) Falling back to old probe method for fglrx
[  1920.538] (II) Loading PCS database from /etc/ati/amdpcsdb
[  1920.538] (--) Chipset Supported AMD Graphics Processor (0x6740) found
[  1920.538] (WW) fglrx: No matching Device section for instance (BusID PCI:0@22:0:1) found
[  1920.538] (II) fglrx: intel VGA device detected, load intel driver.
[  1920.538] (II) LoadModule: "intel"
[  1920.539] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[  1920.539] (II) Module intel: vendor="X.Org Foundation"
[  1920.539] 	compiled for 1.11.0, module version = 2.16.0
[  1920.539] 	Module class: X.Org Video Driver
[  1920.539] 	ABI class: X.Org Video Driver, version 11.0
[  1920.540] ukiDynamicMajor: found major device number 252
[  1920.540] ukiDynamicMajor: found major device number 252
[  1920.540] ukiOpenByBusid: Searching for BusID PCI:22:0:0
[  1920.540] ukiOpenDevice: node name is /dev/ati/card0
[  1920.540] ukiOpenDevice: open result is 8, (OK)
[  1920.540] ukiOpenByBusid: ukiOpenMinor returns 8
[  1920.540] ukiOpenByBusid: ukiGetBusid reports PCI:22:0:0
[  1920.542] (WW) PowerXpress feature is not supported on A+I Mux platform. Please uninstall fglrx driver.
[  1920.542] (EE) No devices detected.

I have the same laptop, so I can second this. It would be really nice to have this working. 

As Varban has pointed out, the media dock does indeed have it's own HDMI and VGA ports.

And just to clarify, it's the Sony Vaio VPCZ2 model in question here.

Same issue here on the same hardward Sony Vaio VPCZ21 Power Media Dock. The USB and disk drive work. Just not the ATI video.

DoTheDog

I did some further testing on the matter of the ATI card in the PMD.

In windows, it's actually possible to have two screens connected via HDMI - one to the ATI card in the PMD, which is then "promoted" to be the primary graphics adapter, and one in the intel card.

So i guess this suggests that the ATI card is simply "another graphics card" connected to the computer? Only twist is that it's conneted via LightPeak/Thunderbolt...

I can confirm that. My Setup is a Sony VPC-Z21 (detail: VPCZ21C5321B) with the external PMD-Station.
The network, usb, diskrive are working. Only the graphic card refuses to get to work.

I am not sure, that theproblem is that the card is connect via LightPeak/Thunderbolt.

On this Site http://www.notebookcheck.net/Review-Sony-Vaio-VPC-Z21Q9E-B-Subnotebook.61141.0.html the author is mentioning that the ati card (they say it is a "HD 6650M") is controlled with the AMD XGP technology.

The FSC Amilo Sa3650 notebook uses the same technology.

With the ati-driver in windows i can configure how the system uses the PMD. 
1. as a gpu for the internal screen
2. as a graphic card for the external display

I think, that the card can used in both modes.

windows supports decoupled display and rendering.

Is it possible to use the external connectors with the intel card?
I am only wanting to use the external dockingstation for the additionals connectors.
So if i can use vga and hdmi port from the dockingstaion with the intel card i would be very happy.


[   22.377284] [drm:intel_dsm_platform_mux_info], MUX info connectors: 7
[   22.377287] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010100
[   22.377290] [drm:intel_dsm_platform_mux_info],   port id: Analog VGA
[   22.377292] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377295] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377298] [drm:intel_dsm_platform_mux_info],   hpd mux info: unknown
[   22.377301] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010400
[   22.377303] [drm:intel_dsm_platform_mux_info],   port id: LVDS
[   22.377305] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377308] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377311] [drm:intel_dsm_platform_mux_info],   hpd mux info: unknown
[   22.377313] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010300
[   22.377315] [drm:intel_dsm_platform_mux_info],   port id: DisplayPort_B
[   22.377318] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377320] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377323] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between iGPU and dGPU
[   22.377326] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010301
[   22.377328] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_B
[   22.377331] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377334] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377336] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between iGPU and dGPU
[   22.377339] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010302
[   22.377342] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_C
[   22.377344] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377347] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377349] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between iGPU and dGPU
[   22.377352] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010303
[   22.377354] [drm:intel_dsm_platform_mux_info],   port id: DisplayPort_D
[   22.377357] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377360] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377362] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between iGPU and dGPU
[   22.377365] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010304
[   22.377367] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_D
[   22.377370] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377373] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377375] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between iGPU and dGPU
[   22.377383] [drm:intel_dsm_pci_probe], no _DSM method for intel device

I have a very similar issue to gyhor.

The driver gets really confused with the PCI busid.

lspci reports the ID as 16, but the driver thinks it's on 22.

(In reply to comment #13)
> The driver gets really confused with the PCI busid.
> 
> lspci reports the ID as 16, but the driver thinks it's on 22.

they are the same.  0x16 (hex) = 22 (decimal)

I also have an affected Sony VAIO laptop, and the failure mode is the same: cannot read BIOS on the AMD card. Is there any debugging information that I can provide (from Windows or from Linux)? Is the BIOS even supposed to be readable?

As per comment #15, I also have an affected Sony Vaio Z Series (model SVZ13115GGXI). Anything logs/debugs/tests I can provide to assist resolve this issue?

Probably need to ask Sony where they store the discrete vbios on these systems.

Hi Alex,

what specific information do we need from sony? if I got through the first help desk, i should know what to ask :)

Where the vbios (video bios) for the discrete card is stored (on a rom on the board, in the sbios (system bios), etc.).  If it's part of the sbios, there's probably an ACPI method (ROM or ATRM) to access it.

I think that the card does have its BIOS, and the problem is really related to a misconfigured PCI bridge. Please take this with a grain of salt, as I am not a kernel hacker.

Some snippets from my dmesg that IMHO confirm this:

(just an interesting line, I didn't try this suggestion)
[    0.701044] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug

(here is the Radeon card)
[    0.722007] pci 0000:16:00.0: [1002:6740] type 00 class 0x030000
[    0.722073] pci 0000:16:00.0: reg 10: [mem 0xb0000000-0xbfffffff 64bit pref]
[    0.722125] pci 0000:16:00.0: reg 18: [mem 0xc0200000-0xc021ffff 64bit]
[    0.722159] pci 0000:16:00.0: reg 20: [io  0x5000-0x50ff]
[    0.722226] pci 0000:16:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref]
[    0.722395] pci 0000:16:00.0: supports D1 D2

(and this is the bridge before it)
[    0.723054] pci 0000:15:03.0: PCI bridge to [bus 16-16]
[    0.723124] pci 0000:15:03.0:   bridge window [io  0x5000-0x5fff]
[    0.723132] pci 0000:15:03.0:   bridge window [mem 0xc0200000-0xc02fffff]
[    0.723149] pci 0000:15:03.0:   bridge window [mem 0xb0000000-0xbfffffff 64bit pref]

(this is vgaarb)
[    0.743085] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.743186] vgaarb: device added: PCI:0000:16:00.0,decodes=io+mem,owns=none,locks=none
[    0.743265] vgaarb: loaded
[    0.743313] vgaarb: bridge control possible 0000:16:00.0
[    0.743367] vgaarb: no bridge control possible 0000:00:02.0

(here the kernel complains about the bug that ultimately leads to unreadability of the ROM)
[    0.773497] pci 0000:16:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref]

(and tries to fix it up? still not good enough)
[    0.775668] pci 0000:16:00.0: BAR 6: assigned [mem 0xc0240000-0xc025ffff pref]
[    0.775745] pci 0000:15:03.0: PCI bridge to [bus 16-16]
[    0.775805] pci 0000:15:03.0:   bridge window [io  0x5000-0x5fff]
[    0.775872] pci 0000:15:03.0:   bridge window [mem 0xc0200000-0xc02fffff]
[    0.775937] pci 0000:15:03.0:   bridge window [mem 0xb0000000-0xbfffffff 64bit pref]

(so we still end up with lost resources)
[    0.778723] pci_bus 0000:15: resource 0 [io  0x3000-0x5fff]
[    0.778725] pci_bus 0000:15: resource 1 [mem 0xb0000000-0xc02fffff]
[    0.778726] pci_bus 0000:15: resource 2 [mem 0xd4400000-0xd44fffff 64bit pref]
[    0.778728] pci_bus 0000:16: resource 0 [io  0x5000-0x5fff]
[    0.778730] pci_bus 0000:16: resource 1 [mem 0xc0200000-0xc02fffff]
[    0.778731] pci_bus 0000:16: resource 2 [mem 0xb0000000-0xbfffffff 64bit pref]

So the main question is: why doesn't vgaarb (or who really has this job) reconfigure the bridge so that radeon can read the ROM?

pci=nocrs doesn't help, and, if it is not clear from the previous comment, the ROM should be here:

16:00.0 0300: 1002:6740 (prog-if 00 [VGA controller])
        Subsystem: 104d:9084
        Physical Slot: 1-2
        Flags: fast devsel, IRQ 17
        Memory at b0000000 (64-bit, prefetchable) [size=256M]
        Memory at c0200000 (64-bit, non-prefetchable) [size=128K]
        I/O ports at 5000 [size=256]
        Expansion ROM at c0240000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [150] Advanced Error Reporting

The same problem with the bridge is present in the dmesg attached by the original poster.

Sorry for the noise about bridges. Of course the necessary address space for the ROM is in pci_bus 0000:15: resource 1, it's just strange that linux doesn't show the ROM on pci bus 0000:16: as a resource in dmesg.

The patch on bug 26891 might help if this is a UEFI system.

i don't know why, but it don't get the VFCT Table.
this returns false:
(!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))

(In reply to comment #25)
> i don't know why, but it don't get the VFCT Table.
> this returns false:
> (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))

Then your system doesn't have the table.

My Sony VAIO currently boots via MBR, in BIOS mode. There is nothing about UEFI in the BIOS setup screen. I am willing to convert the system and test the patch only if someone provides instructions how to test beforehand whether UEFI booting is supported on my system at all, without downloading files larger than 20 megabytes total. I have a 4gb USB flash drive with no important data that can be used as a test boot device.

If you are not using UEFI and the system supports legacy mode, then there's no need to try the patch.

Under Windows 7 Professional x64, I tried to use the "RW-Everything" tool to get information about the ROM of the AMD card. It failed, however, I don't know if it really means "you should not read this ROM" or just an incompatibility with Windows x64. Just for the record, it shows 0x00000000 as the expansion ROM base address for all PCI-like devices in the system.

However, in the "Option ROM information", it shows the PnP header and three option ROMs correctly. However, they are for the following vendor id / device id pairs, none of which seems relevant: 0x8086/0x0126 (the Intel graphics chip), 0x11ab/0x6121 (the Marvell IDE controller) and 0x8086/0x282a (the Intel fakeraid).

(In reply to comment #17)
> Probably need to ask Sony where they store the discrete vbios on these systems.

pfff... no hope here.
i wrote multiples mails and phoned the support service: They have no idea how to help us.

Created attachment 65558 [details]
acpidump output

In http://mjg59.dreamwidth.org/15948.html , Matthew Garrett asked me to post acpidump output somewhere. So I am attaching it to this bug.

Could you add the full output of lspci -vvv when booted with the dock connected?

Created attachment 65580 [details]
lspci -vvv output when booted with the dock

In the acpidump output, there is ATRM method. I will try to add debug printks to  radeon_atrm_call() and report back.

Function radeon_atrm_call() would not be called, because 
if (!radeon_atrm_supported(rdev->pdev)) 
returns false.

Thats because this is returns null:
(!radeon_atpx_priv.atpx_detected)

OK. So the bug is that the Sony BIOS provides ATRM, but not ATPX.

I am not sure. In function radeon_atpx_pci_probe_handle() do get the DEVICE_ACPI_HANDLE:

dhandle = DEVICE_ACPI_HANDLE(&pdev->dev);

It fails with 
status = acpi_get_handle(dhandle, "ATPX", &atpx_handle);


btw it is kernel 3.5RC7

Please try the acpi_patches branch of my git tree:
http://cgit.freedesktop.org/~agd5f/linux/
Specifically this patch:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=acpi_patches&id=6c0775d89cf6a39f4d155c8ad53067a0768e31e0

Unfortunately, your specific patch does not apply to the 3.5 kernel, so I cannot test this quickly. Now downloading your tree.

I have built the kernel from your source tree. It found the card, found the HDMI-connected monitor and displayed boot text messages over it for some time (until it decided to move to the inteldrmfb framebuffer). Will test X a bit later.

X works on radeon, too

What settings did you use for the X server config or do the additional monitors just show as part of the intel card?

Any ideas when this patch will make it in the main line?

Did you try hotplugging the media dock rather than boot with it attached?

Thanks for the effort on troubleshooting this!

The card is a completely separate card. One can create a very old-fashioned Xinerama-based dual-head setup using this (save as /etc/X11/xorg.conf.d/60-dualhead.conf):


Section "Device"
    Identifier "radeon"
    Driver "radeon"
    BusID "PCI:22:00:0"
EndSection

Section "Device"
    Identifier "intel"
    Driver "intel"
    BusID "PCI:00:02:0"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device "radeon"
EndSection

Section "Screen"
    Identifier "Screen1"
    Device "intel"
EndSection

Section "ServerLayout"
    Identifier "DualHead"
    Screen "Screen0"
    Screen "Screen1" RightOf "Screen0"
    Option "Xinerama" "On"
EndSection


This is, however, deprecated, and I'd also like to know the modern way of doing this :)

(In reply to comment #42)
> Any ideas when this patch will make it in the main line?

No idea.

> Did you try hotplugging the media dock rather than boot with it attached?

No, and with the static config above it doesn't make sense. Besides, GPU hotplug is not in the current X server.

(In reply to comment #42)
> Any ideas when this patch will make it in the main line?

I've got it tentatively set for 3.7, but if I have time, I'll try and respin the patches for stable.

Created attachment 65659 [details] [review]
fix for all kernels

Here's the patch broken out which should apply to all recent kernels.

(In reply to comment #44)
> No, and with the static config above it doesn't make sense. Besides, GPU
> hotplug is not in the current X server.

If the card is separate then I'll probably play around with running two xservers that share a session, or something like it, so that I can kill one when I disconnect the media dock.

There do seem to be some issues around hotplugging and thunderbolt that are causing the USB hub in the media dock not to work but I hope they don't affect the GPU or they were caused by the GPU audio device crashing.

(In reply to comment #46)
> Created attachment 65659 [details] [review] [review]
> fix for all kernels
> 
> Here's the patch broken out which should apply to all recent kernels.

for kernel 3.5rc7 i needed additional this part in radeon_bios.c:
*** 32,37 ****
--- 32,40 ----
  
  #include <linux/vga_switcheroo.h>
  #include <linux/slab.h>
+ #ifdef CONFIG_ACPI
+ #include <linux/acpi.h>
+ #endif
  /*
   * BIOS.
   */

Created attachment 65692 [details] [review]
upstream 1/2

This set of stable patches will apply cleanly.

Created attachment 65693 [details] [review]
upstream 2/2

Second patch.

With this xorg.conf i can use two external monitor connected to the dockingstation.
Additionally the internal screen of the notebook is in textmode.
--
$cat /etc/X11/xorg.conf
Section "Device"
  Identifier "radeon"
  Driver "radeon"
  BusID "PCI:22:00:0"
EndSection

Section "Device"
  Identifier "intel"
  Driver "intel"
  BusID "PCI:00:02:0"
EndSection

Section "Screen"
  Identifier "Screen0"
  Device "radeon"
EndSection

Section "Screen"
  Identifier "Screen1"
  Device "intel"
EndSection

A patch referencing this bug report has been merged in Linux v3.6-rc3:

commit c61e2775873f603148e8e998a938721b7d222d24
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Aug 16 15:39:09 2012 -0400

    drm/radeon: split ATRM support out from the ATPX handler (v3)

Does AMD need to make a change to the proprietary fglrx drivers in order for the kernel patch to work with their drivers and if so has a bug been opened with them? I'm using Ubuntu 12.10 with kernel 3.6.9 and no problem getting this to work with the gallium (radeon) drivers, however when I try the fglrx drivers I get the following messages in kern.log:

Dec 27 13:07:11 gnunn-laptop2 kernel: [   11.925204] <3>[fglrx:hal_read_VBIOS] *ERROR* Invalid AMD VBIOS!
Dec 27 13:07:11 gnunn-laptop2 kernel: [   11.925207] <3>[fglrx:hal_init_gpu] *ERROR* Failed to read VBIOS!
Dec 27 13:07:11 gnunn-laptop2 kernel: [   11.925208] <6>[fglrx] device open failed with code -1

Which sounds like a similar issue to what was described here. While I generally find the gallium drivers to be more stable and reliable then fglrx, unfortunately fglrx significantly outperforms the open source drivers when it comes to gaming.

(In reply to comment #53)

Gerald, we can only support the open source drivers here. For fglrx issues you'll have to turn to fglrx support resources.