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

Intel Drops Mode-Setting Rework Patch Bomb

Intel

Published on 03 July 2012 12:46 PM EDT
Written by Michael Larabel in Intel
35 Comments

Daniel Vetter of Intel published a massive "patch bomb" of 43 patches to the Intel open-source Linux graphics driver development list as they prepare to re-work mode-setting within their DRM/KMS driver.

These 43 patches, while large in size, isn't the full workload. The 43 patches are just "part one" as the developers do the prep work for the actual mode-setting changes. "The goal of this little adventure is to move away from the crtc helper code, which has the fundamental assumption that encoders and crtc can be enabled/disabled in any order, as long as we take care of depencies. Our hw works differently. We already have tons of ugly cases where crtc code enable encoder hw (or encoder->mode_set enables stuff that should only be enabled in enocder->commit) to work around these issues. But on the disable side we can't pull off similar tricks - there we actually need to rework the modeset sequence that controls all this."

As some of this work there is a rework of the DPMS (Display Power Management Signalling) code, infrastructure for reading the current hardware state, various clean-ups, etc.

The work right now is only lightly tested with more test coverage of TV-Out and DVO encoders needed. Daniel Vetter hopes to submit the actual mode-setting change patches within the next few days as he seeks comment.

For those interested in the changes on the technical side to Intel's Linux DRM driver, see this mailing list thread.

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. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
  2. Sumo's Omni Gets Reloaded
  3. AMD A10-7800 & A6-7400K APUs Run Great On Linux
  4. Radeon Gallium3D Is Running Increasingly Well Against AMD's Catalyst Driver
Latest Linux Articles
  1. Intel's Latest Linux Graphics Code Competes Against OS X 10.9
  2. Intel Sandy Bridge Gets A Surprise Boost From Linux 3.17
  3. Open-Source Radeon Graphics Have Some Improvements On Linux 3.17
  4. CPUFreq Scaling Tests With AMD's Kaveri On Linux 3.16
Latest Linux News
  1. Steam Now Supports VA-API For In-Home Game Streaming
  2. GNOME 3.14 Beta Released
  3. Mesa 10.3 Branched & RC1 Released, Mesa 10.4 On Master
  4. Intel Sandy Bridge Gains On Linux 3.17 Extend Beyond Graphics
  5. LinuxCon: What's Going On With Fedora.Next
  6. Canonical Joined The Khronos Group To Help Mir/Wayland Drivers
  7. EFL 1.11 Is A Big Milestone For Enlightenment Users
  8. DirectFB Updates GTK3 Support, Working Towards DirectFB 1.8
  9. Userptr Support Set For AMD Radeon GPUs In Linux 3.18
  10. NVIDIA Releases CUDA 6.5 As A Huge Update
Latest Forum Discussions
  1. Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs
  2. Systemd 216 Piles On More Features, Aims For New User-Space VT
  3. OSS radeon driver for A10-7850K (Kaveri)
  4. Updated and Optimized Ubuntu Free Graphics Drivers
  5. AMD Offers Mantle For OpenGL-Next, Pushes Mantle To Workstations
  6. ATI CrossFire Does Not Support On This Platform When Enabling (Ubuntu Lucid)
  7. Dead Island for Linux (?)
  8. The dangers of Linux kernel development