[Bug 74190] scrypt doesn't do anything with bfgminer on CAYMAN

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=74190

--- Comment #1 from slicksam at gmx.com ---
This may be the same issue I reported in
https://bugs.freedesktop.org/show_bug.cgi?id=74140

If you check CPU usage, you should see a thread stuck at 100% - this is
apparently it trying to compile the opencl program.  I have not tried waiting a
long time to see if it does eventually fire up.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/fcfe7414/attachment.html>

[Bug 70651] cannot write to power_dpm_force_performance_level: invalid argument (radeon 7730m)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=70651

--- Comment #5 from Fabio Sangiovanni  ---
hi, I'm sorry but the patch doesn't seem to work to me.
I've applied it to 3.13.3:


root at darkstar:/usr/src/linux# patch -p1 < patch.txt 
patching file drivers/gpu/drm/radeon/radeon_pm.c
Hunk #7 succeeded at 1580 (offset -20 lines).


This is what I get:

root at darkstar:~# cat /sys/kernel/debug/vgaswitcheroo/switch 
0:DIS: :DynOff::01:00.0
1:IGD:+:Pwr::00:02.0

root at darkstar:~# cat /sys/class/drm/card0/device/power_dpm_state 
balanced

root at darkstar:~# cat
/sys/class/drm/card0/device/power_dpm_force_performance_level 
auto

root at darkstar:~# echo 'high' >
/sys/class/drm/card0/device/power_dpm_force_performance_level 
-bash: echo: write error: Invalid argument
root at darkstar:~# echo 'low' >
/sys/class/drm/card0/device/power_dpm_force_performance_level 
-bash: echo: write error: Invalid argument
root at darkstar:~# echo 'auto' >
/sys/class/drm/card0/device/power_dpm_force_performance_level 
-bash: echo: write error: Invalid argument

root at darkstar:~# cat /sys/kernel/debug/dri/0/radeon_pm_info 
default engine clock: 575000 kHz
current engine clock: 210280 kHz
default memory clock: 90 kHz
current memory clock: 00 kHz
voltage: 825 mV
PCIE lanes: 16


Plus, I've noticed this (unsure if it's missing some sort of parsing):
root at darkstar:~# echo 'battery' >
/sys/class/drm/card0/device/power_dpm_state 
root at darkstar:~# cat /sys/class/drm/card0/device/power_dpm_state
battery

(Same result with 'performance' and 'balanced')

It's ok with random letters as prefix:
root at darkstar:~# echo 'battery' >
/sys/class/drm/card0/device/power_dpm_state
-bash: echo: write error: Invalid argument

Please let me know if I can help somehow.

Thanks!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75400] regression in OpenCL since commit cc3aeac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75400

--- Comment #8 from Bruno Jim?nez  ---
Hi,

I'm afraid that that patch doesn't help. I have also tried the patch you have
sent to the Mailing List (
http://lists.freedesktop.org/archives/mesa-dev/2014-February/054780.html ) but
also nothing.

If there's anything else I can do, just ask.
Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/43b9b234/attachment.html>

[Bug 75400] regression in OpenCL since commit cc3aeac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75400

--- Comment #7 from Bruno Jim?nez  ---
Hi Francisco,

The segfaults were caused because 'clGetPlatformIDs' returned an strange error
(-1001), and when passed to 'clUtilErrorString' (from 'cl_util.c') it meant an
unhandled error case. So it returned nothing, and when fprintf tries to write
it it gives a segfault.


Emil,

I'll try that patch as soon as I can.


Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/6c53aa82/attachment.html>

[Bug 75400] regression in OpenCL since commit cc3aeac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75400

--- Comment #6 from Emil Velikov  ---
(In reply to comment #5)
> 
> Most likely you're getting that segfault somewhere in the ICD loader because
> it's unable to load Mesa's ICD library.  I guess that this hunk:
> 
> +if NEED_WINSYS_XLIB
> +AM_CPPFLAGS += -DHAVE_WINSYS_XLIB
> +endif
> 
> pulls in the XLIB pipe-loader back-end that was previously ifdef-ed out in
> Clover builds, leading to undefined symbols in the resulting library.

Would that not cause the build/link to fail ? Hmm guess not, since the opencl
target is missing -no-undefined.

Francisco,
Is there any particular reason why we do not use -no-undefined for opencl ?

Bruno,
Feel free to grab the patch from bug 75356, which should handle the symbol
problems and continue from there.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/b432f126/attachment.html>

[Intel-gfx] [PATCH 0/6] Intel Color Manager Framework

[Stéphane Marchesin]

On Fri, Feb 21, 2014 at 7:49 PM, Sharma, Shashank  wrote:

>On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrj?l? <
> ville.syrjala at linux.intel.com> wrote:
>
> On Thu, Feb 20, 2014 at 06:07:21PM +0530, Shashank Sharma wrote:
> >> Color manager is a new framework in i915 driver, which provides
> >> a unified interface for various color correction methods supported
> >> by intel hardwares. The high level overview of this change is:
>
> >Would have been good to discuss this idea before implementing it. The
> >plan is to use kms properties for this kind of stuff which allows us
> >to hook it up with the upcoming atomic modeset API. Just yesterday there
> >was some discussion on #dri-devel about exposing user settable blob
> >properties even before the atomic modeset API lands (it was always the
> >plan for the atomic modeset API anyway). So based on a cursory glance,
> >this looks like it's going in the wrong direction.
>
>
>
> +1. We'e looking into hooking up color correction controls, and if the
> interface isn't standard our user space won't be portable across drivers.
> There are multiple reasons for using drm properties:
>
> - the KMS interface already provides a way to set the gamma ramp, which
> this code seems to replicate.
>
>
>
> The current KMS interface just initializes the gamma soft LUT palette
> registers, in 8 bit mode corresponding to unit gamma. It's impossible to
> apply accurate values corresponding to gamma=2.2 or 1.5 from KMS
>
> Because for that we need to program palette registers in 10.6 bit mode of
> hardware.
>

Then the existing interface should be extended. Otherwise you have two ways
to do the same thing...



>   >- the KMS interface allows us to name properties independently and
> enumerate them. It seems like right now you can't enumerate properties or
> guess what "property 0" is. I'd rather set the "Color conversion matrix"
> than remember to set >"property 0" (and even then, I'm not really sure it
> exists).
>
>
>
> All the properties are getting enumerated in color manager register
> function. The framework defines proper identifiers and mapping for each
> property, and every property is having a corresponding soft-lut to be
> loaded with correction values.
>

Correct me if I'm wrong, but I don't see a way for user space to query the
presence/absence of a given property. KMS allows that.



>
>
> - you can reuse the get/set infrastructure which is already in place
>
>
>
>
>
> >Another thing that came out of the discussion on irc is that we should
> standardize the properties. For example we could use a text file describing
> the name of the controls and the format of the data (something similar to
> the device tree >bindings). That way user space can expect "color
> conversion matrix" to mean the same thing everywhere, to get the same data
> as input, and to work the same way on all platforms.
>
> If you can please have a look on the header file, we are almost doing the
> same thing, in form of a protocol.
>

This protocol however is not extensible. With the KMS interface I can
already do the following from user space:
- query the existence of a given property
- set each property in a portable fashion (for example the same gamma ramp
code works on all DRM drivers)
- easily match properties to a given crtc

St?phane
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/10e2a914/attachment-0001.html>

[Bug 75400] regression in OpenCL since commit cc3aeac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75400

--- Comment #5 from Francisco Jerez  ---
(In reply to comment #4)
> I am also very surpised of what commit seems to start this. I have done the
> bisect making Arch packages, installing and then testing them. So, unless I
> have missed something, which is also possible, that's it.
> 
> I have recompiled at commit cc3aeac with debug information, but for some
> strange reason, gdb don't want to step into OpenCL functions.
> 
> Here's what I have guessed:
> 
> - Actually, the segfault comes from a fprintf with a "%s" and a null
> pointer. It can be solved by just adding a default case to
> 'clUtilErrorString'.
> 
> - The real problem happens with 'clGetPlatformIDs', which returns an error
> value of '-1001'.
> 
> I have triggered the return of 'CL_INVALID_VALUE', and tried various
> combinations of parameters to see if it changed anything. And seems to be
> one thing or the other.
> 
> I have checked the code at
> mesa/src/gallium/state_trackers/clover/api/platform.cpp (where
> clGetPlatformIDs is) and have no clue how it can be possible.
> 
> Sorry if this isn't enough information, but I completely clueless of what
> can be happening.
> 
> I will check again my packages to see if I have compiled some version and
> have called it other.
> 
> If I can help with anything else, just ask.

Most likely you're getting that segfault somewhere in the ICD loader because
it's unable to load Mesa's ICD library.  I guess that this hunk:

+if NEED_WINSYS_XLIB
+AM_CPPFLAGS += -DHAVE_WINSYS_XLIB
+endif

pulls in the XLIB pipe-loader back-end that was previously ifdef-ed out in
Clover builds, leading to undefined symbols in the resulting library.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/c4c2adc2/attachment-0001.html>

[Bug 75400] regression in OpenCL since commit cc3aeac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75400

--- Comment #4 from Bruno Jim?nez  ---
I am also very surpised of what commit seems to start this. I have done the
bisect making Arch packages, installing and then testing them. So, unless I
have missed something, which is also possible, that's it.

I have recompiled at commit cc3aeac with debug information, but for some
strange reason, gdb don't want to step into OpenCL functions.

Here's what I have guessed:

- Actually, the segfault comes from a fprintf with a "%s" and a null pointer.
It can be solved by just adding a default case to 'clUtilErrorString'.

- The real problem happens with 'clGetPlatformIDs', which returns an error
value of '-1001'.

I have triggered the return of 'CL_INVALID_VALUE', and tried various
combinations of parameters to see if it changed anything. And seems to be one
thing or the other.

I have checked the code at
mesa/src/gallium/state_trackers/clover/api/platform.cpp (where clGetPlatformIDs
is) and have no clue how it can be possible.

Sorry if this isn't enough information, but I completely clueless of what can
be happening.

I will check again my packages to see if I have compiled some version and have
called it other.

If I can help with anything else, just ask.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/63751f99/attachment.html>

[Bug 75400] regression in OpenCL since commit cc3aeac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75400

--- Comment #3 from Emil Velikov  ---
Strange I do not see how the commit will cause other than compilation issues.
FWIW might be worth double-checking that the bisect went fine and attaching a
back trace of the segfault.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/b3cbd16c/attachment.html>

[Bug 75400] regression in OpenCL since commit cc3aeac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75400

--- Comment #2 from Bruno Jim?nez  ---
Hi Emil,

No, it's not a compilation error, nor for mesa nor for opencl code. It's just
that OpenCL programs crash with segfaults.

Every test from http://cgit.freedesktop.org/~tstellar/opencl-example/ fails and
its 'hello_world' program crash with a segfault.

As the code changed in that bug has nothing to do with clover, maybe the
problem is with my configuration?

Here's what I pass to autogen.sh, surely there's something I don't need, but I
took them from a PKGBUILD:

  --prefix=/usr \
  --sysconfdir=/etc \
  --with-dri-driverdir=/usr/lib/xorg/modules/dri \
  --with-gallium-drivers=r600,swrast\
  --with-dri-drivers=swrast \
  --enable-gallium-llvm \
  --enable-egl \
  --enable-gallium-egl \
  --with-egl-platforms=x11,drm,wayland \
  --enable-shared-glapi \
  --enable-gbm \
  --enable-gallium-gbm \
  --enable-glx-tls \
  --enable-dri \
  --enable-glx \
  --enable-osmesa \
  --enable-texture-float \
  --enable-xa \
  --enable-vdpau \
  --enable-omx \
  --with-llvm-shared-libs \
  --enable-opencl --enable-opencl-icd \
  --with-clang-libdir=/usr/lib

If there's anything else I can do to help, just ask.
Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/52f2c700/attachment.html>

[Bug 75400] regression in OpenCL since commit cc3aeac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75400

--- Comment #1 from Emil Velikov  ---
Hi Bruno

What you mean with "broken" here ? If you're talking about a compilation
problem take a look at bug 75356, which has a patch to resolve it.

If you are having different a problem let us know what it is :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/fdcd3c8b/attachment.html>

[Bug 64443] Oil Rush (Steam version) crashes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64443

Marek Ol??k  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Marek Ol??k  ---
(In reply to comment #7)
> Radeonsi and r600g in master mesa now support OpenGL 3.3 and GLSL 3.30. This
> is enough to run unigine-heaven, unigine-valley and oilrush normaly. Bug may
> be closed?

Yes. Closing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/19e2fcbc/attachment.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75112

--- Comment #3 from Marek Ol??k  ---
The variable is called R600_DEBUG. Type: "R600_DEBUG=help glxgears"

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/da61bffe/attachment-0001.html>

[Bug 75400] New: regression in OpenCL since commit cc3aeac

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75400

  Priority: medium
Bug ID: 75400
  Assignee: dri-devel at lists.freedesktop.org
   Summary: regression in OpenCL since commit cc3aeac
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: brunojimen at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Hi,

This morning I recompiled mesa and found that the OpenCL support was broken. I
have managed to bisect the regresion back to commit cc3aeac (
http://cgit.freedesktop.org/mesa/mesa/commit/?id=cc3aeacab64a6928a903f1dbfeaa7c880a8de5a6
) Strangely, it's nothing related to clover.

I am using Arch linux with kernel 3.13.4 and a AMD HD5470. Nothing interesting
in dmesg or Xorg logs.

If I can give you any more information, just ask.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/df821c15/attachment.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75112

--- Comment #2 from commiethebeastie at gmail.com ---
How to set R600_HYPERZ=1 by default in Unity 7?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/89847a16/attachment.html>

nouveau graphical corruption in 3.13.2

[Daniel J Blueman]

On 23 February 2014 11:48, Ilia Mirkin  wrote:
> On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman  
> wrote:
>> On 9 February 2014 02:57, Ilia Mirkin  wrote:
>>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman  
>>> wrote:
 Interestingly, there was graphical failure booting 3.6.11, even
 nvidia-current fails to initialise, but these two issues could be due
 to running the Xorg stack in Ubuntu 14.04 pre-release. Using
 nouveau.noaccel=1 works great for the first X session, but after
 logging out, lightdm and the next session experiences this consistent
 screen corruption:

 http://quora.org/nouveau-corruption.jpg
>>>
>>> Does that just happen in 3.6.11 or even in 3.13? If the latter, that.
>>> points to some key lack of understanding of... something. With
>>> noaccel, we're not using pgraph or anything fancy -- it's just a
>>> framebuffer, basically. So if we can't even render _that_ right...
>>>
>>> Hopefully someone else will pipe up re your other issues -- my
>>> knowledge base on this is exhausted :(
>>
>> Interestingly, it turns out that the screen corruption occurs on every
>> boot (booting with nouveau.noaccel=1 for now), and I can consistently
>> work around it by one suspend-resume cycle.
>
> Does booting with nouveau.config=NvForcePost=1 help?

Still no cigar with nouveau.config=NvForcePost=1.

I meant to add that restarting X or changing resolutions doesn't
resolve the issue. The corruption is consistently 16-pixel wide by 1
high stippling on a consistent address range of the framebuffer.

Thanks,
  Daniel
-- 
Daniel J Blueman

nouveau graphical corruption in 3.13.2

[Daniel J Blueman]

On 9 February 2014 02:57, Ilia Mirkin  wrote:
> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman  wrote:
>> Interestingly, there was graphical failure booting 3.6.11, even
>> nvidia-current fails to initialise, but these two issues could be due
>> to running the Xorg stack in Ubuntu 14.04 pre-release. Using
>> nouveau.noaccel=1 works great for the first X session, but after
>> logging out, lightdm and the next session experiences this consistent
>> screen corruption:
>>
>> http://quora.org/nouveau-corruption.jpg
>
> Does that just happen in 3.6.11 or even in 3.13? If the latter, that.
> points to some key lack of understanding of... something. With
> noaccel, we're not using pgraph or anything fancy -- it's just a
> framebuffer, basically. So if we can't even render _that_ right...
>
> Hopefully someone else will pipe up re your other issues -- my
> knowledge base on this is exhausted :(

Interestingly, it turns out that the screen corruption occurs on every
boot (booting with nouveau.noaccel=1 for now), and I can consistently
work around it by one suspend-resume cycle.

To that effect, I've captured kernel message output booting 3.14-rc3
with 'nouveau.noaccel=1 nouveau.debug=trace,DEVINIT=spam drm.debug=0x6
log_buf_len=16M', and performed a suspend-resume cycle:
http://quora.org/nouveau-log.txt

Ben et al, would some specific register tracing or otherwise help to
locate the issue?
-- 
Daniel J Blueman

3.13 i915 brightness settings broken when going from docked -> undocked

[Josh Boyer]

On Thu, Feb 20, 2014 at 07:31:41PM -0500, Josh Boyer wrote:
>On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer  
>wrote:
>> Hi All,
>>
>> We've had a rather weird report[1] of the brightness adjustments being
>> broken in a specific case with Thinkpad x220 hardware (SandyBridge
>> based).  If you boot the machine with it in a dock and then undock,
>> the brightness adjustments do not work.  That is with either the FN
>> keys or the GNOME brightness slider.
>>
>> I can see that the value of
>> /sys/class/backlight/acpi_video0/brightness increases/decreases but
>> /sys/class/backlight/intel_backlight/brightness doesn't reflect any
>> changes.  With 3.12 this works, and oddly with 3.14-rc1 it works
>> (specifically, it starts working around v3.13-10231-g53d8ab2 which is
>> right after the first DRM merge for 3.14).  With 3.13, if I undock and
>> echo a higher value in the intel_backlight_brightness sysfs entry, the
>> brightness will actually increase so it can be done manually, but it
>> does not work as you'd expect.
>>
>> I'm in the middle of trying to do a reverse bisect for which patch
>> fixes it in the 3.14-rcX series, but that's taking a while.  I thought
>> I'd email and see if anyone already knows about this situation, what
>> patch in 3.13 broke this, and which one then fixed it again.  Thus far
>> all I've gathered is that backlight handling is confusing.
>
>The reverse bisect between 3.13 and 3.14-rc1 didn't prove fruitful,
>either because I messed it up or there's a combination of things that
>fix the issue.  So instead I did a regular git bisect between 3.12 and
>3.13 to see which commit _broke_ things and caused the above behavior.
> That landed me at:
>
>Author: Jesse Barnes 
>Date:   Thu Oct 31 18:55:49 2013 +0200
>
>drm/i915: make backlight functions take a connector
>
>I have no idea if that makes sense or not, but it's at least something
>that seems to be in a relevant area of code.  Does anyone involved in
>that know why it would cause the above symptoms on 3.13, and which
>commit(s) fix it in 3.14-rc1?

Since nobody is replying I poked around a bit myself.  The one commit
that looks somewhat relevant in 3.14-rc1 seems to be:

commit c91c9f32843a1b433de5a1ead4789a6bc8d3d914
Author: Jani Nikula 
Date:   Fri Nov 8 16:48:55 2013 +0200

drm/i915: make asle notifications update backlight on all connectors

That doesn't apply cleanly on 3.13 because of the other reworks that
went in first, so I came up with the patch below.  It seems to fix it
for my machine, but I'm waiting for confirmation from the original bug
reporter still.  Maybe this will elicit some comments?

josh

Backport of upstream commit c91c9f328

---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_opregion.c | 31 ++-
 drivers/gpu/drm/i915/intel_panel.c|  4 
 3 files changed, 11 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 221ac62..d6d4349 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1371,6 +1371,7 @@ typedef struct drm_i915_private {

/* backlight */
struct {
+   bool present;
int level;
bool enabled;
spinlock_t lock; /* bl registers and the above bl fields */
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 6d69a9b..b2a51ae 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -414,38 +414,19 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
return ASLC_BACKLIGHT_FAILED;

mutex_lock(>mode_config.mutex);
-   /*
-* Could match the OpRegion connector here instead, but we'd also need
-* to verify the connector could handle a backlight call.
-*/
-   list_for_each_entry(encoder, >mode_config.encoder_list, head)
-   if (encoder->crtc == crtc) {
-   found = true;
-   break;
-   }
-
-   if (!found) {
-   ret = ASLC_BACKLIGHT_FAILED;
-   goto out;
-   }

-   list_for_each_entry(connector, >mode_config.connector_list, head)
-   if (connector->encoder == encoder)
-   intel_connector = to_intel_connector(connector);
-
-   if (!intel_connector) {
-   ret = ASLC_BACKLIGHT_FAILED;
-   goto out;
+   DRM_DEBUG_KMS("updating opregion backlight %d/255\n", bclp);
+   list_for_each_entry(connector, >mode_config.connector_list, head) {
+   intel_connector = to_intel_connector(connector);
+   if (dev_priv->backlight.present)
+   intel_panel_set_backlight(intel_connector, bclp, 255);
}

-   DRM_DEBUG_KMS("updating opregion backlight %d/255\n", bclp);
-   intel_panel_set_backlight(intel_connector, bclp, 255);
  

[Bug 75361] freeze in Mass Effect 3 (wine)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75361

Vladimir Ysikov  changed:

   What|Removed |Added

  Attachment #94560|text/plain  |application/x-tar
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/abe6ce90/attachment.html>

[Bug 64443] Oil Rush (Steam version) crashes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64443

--- Comment #7 from Vladimir Ysikov  ---
Radeonsi and r600g in master mesa now support OpenGL 3.3 and GLSL 3.30. This is
enough to run unigine-heaven, unigine-valley and oilrush normaly. Bug may be
closed?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140223/7d38aa28/attachment.html>