1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

AMD Intentionally Crippled Their HDMI Adapters

AMD

Published on 08 October 2013 09:16 AM EDT
Written by Michael Larabel in AMD
52 Comments

For some AMD Radeon graphics cards when using the Catalyst driver, the HDMI audio support isn't enabled unless using the simple DVI to HDMI adapter included with the graphics card itself... If you use another DVI-to-HDMI adapter, it won't work with Catalyst. AMD intentionally implemented checks within their closed-source driver to prevent other adapters from being used, even though they will work just fine.

In another loss for binary blobs like the recent news of NVIDIA removing features from their Linux driver that wasn't found in the NVIDIA Windows driver in order to maintain "feature parity" -- news that Phoronix was first to point out -- AMD has a stinky move of their own. Included with many graphics cards are DVI-to-HDMI adapters for running an HDMI monitor off a DVI port on modern graphics cards. However, for whatever reason, if you want to use HDMI audio, AMD only wants you using the adapters included with the graphics card itself. AMD has intentionally blocked third-party HDMI adapters from being used with HDMI audio on their Catalyst driver under Linux and Windows.

One of the open-source Linux developers who has been working on the Radeon HDMI open-source driver support, Rafał Miłecki, has been confused why HDMI audio wouldn't work for his older Radeon HD 4850 with Catalyst/fglrx when using some generic/cheap HDMI adapter. After research, it appears to be a fairly common problem and affects not only Linux users but Windows users too.

Rafał Miłecki ended up finding out and writing to the DRI developers' list, "it appears that ATI's proprietary adapter include some tiny I2C protocol that allows identifying them! It seems that Catalyst / fglrx uses some simple I2C talk to check if the adapter is made by ATI and allows or refuses to use HDMI mode."

In response to that mailing list, Christian König, an open-source developer who originally reverse-engineered the Radeon HDMI support in the days of the "RadeonHD" driver, confirmed this news. Christian König ended up being hired by AMD to work on their open-source graphics driver team after his independent contributions to the driver and he noted in a follow-up post, "I've figured this out over five years ago by applying brute force to one of the 'magic' DVI->HDMI adapters that came with my original RV635. And it indeed contains an extra EEPROM on the I2C bus ;)"

So long story short, AMD clearly went out of their way to try to prevent their customers from using Radeon HD graphics cards with DVI to HDMI adapters that weren't provided by ATI/AMD. They added an extra EEPROM to the I2C bus of these adapters that their closed-source Catalyst driver on Windows and Linux then checks for in determining whether to enable HDMI audio. It's not that other adapters are incompatible as these artificial checks aren't found in the open-source Radeon DRM driver so there any DVI-to-HDMI adapter will be supported and it's been confirmed to work fine. This could theoretically be related to High-bandwidth Digital Content Protection (HDCP) requirements, but doesn't make too much sense with AMD being the only vendor of such HDMI adapters and only their Catalyst software driver forcing such checks. This is good news if you use the open-source driver, but bad news if you're using the Catalyst binary blob.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Intel Xeon E5-1680 v3 & E5-2687W v3 Compared To The Core i7 5960X On Linux
  2. Intel 120GB 530 Series SSD Linux Performance
  3. Btrfs/EXT4/XFS/F2FS RAID 0/1/5/6/10 Linux Benchmarks On Four SSDs
  4. AMD's Windows Catalyst Driver Remains Largely Faster Than Linux Drivers
Latest Linux Articles
  1. NVIDIA vs. Nouveau Drivers With Linux 3.18 + Mesa 10.4-devel
  2. Is The Open-Source NVIDIA Driver Fast Enough For Steam On Linux Gaming?
  3. Linux 3.18 File-System Performance Minimally Changed But Possible Regressions
  4. AMD Radeon Gallium3D Is Catching Up & Sometimes Beating Catalyst On Linux
Latest Linux News
  1. Linux 3.18 Kernel: Not Much Change With Intel Haswell Performance
  2. More File-System Tests Of The Linux 3.18 Kernel
  3. Using NVIDIA's NVENC On Linux With FFmpeg
  4. There's Talk Again About An "Open To The Core" Ubuntu Laptop
  5. PowerVR SGX Driver Code Gets Leaked
  6. V2 Of KDBUS Published For Linux Kernel Review
  7. VirtualBox 4.3.20 Arrives, Still No Sign Of VirtualBox 4.4
  8. Scientific Linux 6.6 vs. Scientific Linux 7.0 Benchmarks
  9. Qualcomm Looks To Get Into The ARM Server Business
  10. HHVM 3.4 Adds New Features, Support
Latest Forum Discussions
  1. Debian Developer Resigns From The Systemd Maintainership Team
  2. Roadmap to Catalyst 14.10 ?
  3. Updated and Optimized Ubuntu Free Graphics Drivers
  4. Cant get working Kaveri APU - A10-7850k
  5. Script for Fan Speed Control
  6. Debian Init System Coupling Vote Results
  7. The Slides Announcing The New "AMDGPU" Kernel Driver
  8. Ubuntu Developers Still Thinking What To Do About Adobe Flash Support