Signed-off-by: Ben Widawsky bwida...@gmail.com
---
tools/intel_decode.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tools/intel_decode.c b/tools/intel_decode.c
index b344e21..596ecfc 100644
--- a/tools/intel_decode.c
+++ b/tools/intel_decode.c
@@ -91,6 +91,7 @@
On Thu, 2011-02-17 at 22:38 +1000, Ted Phelps wrote:
Ivan Bulatovic writes:
I've done a little digging and maybe this could be related ?
https://patchwork.kernel.org/patch/296822/
That looks promising, but I've tried explicitly disabling and enabling
that patch (#define
The gma500 driver currently includes its own IGD opregion implementation.
Rework it to use the generic one instead. Note that this is missing a
certain level of functionality - the driver does nothing to enable
opregion interrupts right now, and so will simply poll for updates rather
than doing
On Tue, 22 Feb 2011 15:03:13 -0500
Matthew Garrett m...@redhat.com wrote:
The Integrated Graphics Device opregion specification defines a mechanism
for the OS and system firmware to collaborate on various graphics-related
functionality. This is currently implemented in the i915 driver but
On 2011.02.22 09:33:22 -0800, Eric Anholt wrote:
While I originally hacked it up this way where libdrm intuits what kind
of buffer it is from the name of the buffer, it's a bad way to design an
interface. We should really have a command that marks (an area) of a
buffer object as being a
On Tuesday, February 22, 2011 05:49:57 PM Zhenyu Wang wrote:
[snip]
We also can't commit code to Mesa that just writes into some arbitrary
file based on an environment variable -- keep in mind that our Mesa
driver is loaded from the X Server which is running as root.
yeah, I wasn't aware
