https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #65 from udo ---
Running kernel 3.9.x (3.9.4 now), git mesa, git ati driver I had no issues with
these adjustments:
# cat /etc/environment
LIBGL_DRIVERS_PATH=/opt/xorg/lib/dri/
R600_DEBUG=nodma
and:
# git diff
diff --git a/src/gal
https://bugs.freedesktop.org/show_bug.cgi?id=65438
--- Comment #8 from had...@gmx.de ---
Created attachment 80567
--> https://bugs.freedesktop.org/attachment.cgi?id=80567&action=edit
xfce with RADEON_DUMP_SHADERS=1
heres the output with RADEON_DUMP_SHADERS
Rafael: I can reclock the card, but i
Hi Dave,
Two fixes for memory leaks split into Cedarview and Poulsbo versions,
and a fix for properly setting the pipe base when using fbdev. It's on
my todo-list to start unifying the chips since they are very similar,
but until then I'd like to split them up in case there are side-effects
on Ced
https://bugs.freedesktop.org/show_bug.cgi?id=65377
--- Comment #7 from Bastian Triller ---
The problem also exists if I boot in bios mode.
I didn't mention that, when using the intel card there only is the apple_gmux
interface.
--
You are receiving this mail because:
You are the assignee for t
This is version 2 of my DRM driver. Changes since the previous version:
1. It's now called Armada not Dove, because the "LCD controllers" aka CRTCs
are found in Armada 16x as well as Armada 510 Dove. The Armada 16x is
preliminary work.
2. Cursor support is now a separate patch. I've trie
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dr
When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation. One such case encountered is the VIP output
mux register. This defaults to 0x24 on powerup, but other drivers may
set this to 0x12. Thi
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index cd1526c..c0d17ae 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 308 -
include/drm/i2c/tda998x.h | 30
2 files changed, 331 insertions(+), 7 deletions(-)
create mode 100644 include/drm/i2c/tda998x.h
diff --git a/drivers/gpu/drm/i2c/tda998x
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/Kconfig |9 +++
drivers/gpu/drm/armada/armada_drv.c | 42 +++
2 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index
On Sun, Jun 09, 2013 at 08:06:12PM +0100, Russell King - ARM Linux wrote:
> This is version 2 of my DRM driver. Changes since the previous version:
Okay, patch 1 got removed from this set, so some people won't see it
(it shouldn't have been sent). Patch 2 is in moderation, which is
probably the
https://bugs.freedesktop.org/show_bug.cgi?id=64913
--- Comment #3 from Krzysztof A. Sobiecki ---
Created attachment 80585
--> https://bugs.freedesktop.org/attachment.cgi?id=80585&action=edit
Way to big patch to "fix" this small problem
I was too lazy to fix all pipe_sampler_view_reference so i
https://bugs.freedesktop.org/show_bug.cgi?id=64913
Krzysztof A. Sobiecki changed:
What|Removed |Added
Attachment #80585|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=65091
--- Comment #5 from Kamil Bar ---
Thanks, it works fine now, I added memory clocking, and I will try to create OC
possibilities using debugfs.
I have two questions, will new system have overclocking capabilities, in ex.
passing values to debugfs
On 06/09/2013 09:32 PM, Russell King wrote:
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
---
Russell, Rob,
I have patches fixing TDA998x sync generation for p
https://bugs.freedesktop.org/show_bug.cgi?id=64913
--- Comment #5 from Krzysztof A. Sobiecki ---
Created attachment 80590
--> https://bugs.freedesktop.org/attachment.cgi?id=80590&action=edit
A little shorter one
Not tested yet.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=64913
Krzysztof A. Sobiecki changed:
What|Removed |Added
Attachment #80590|A little shorter one|Nope
description|
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #29 from Erdem U. Altınyurt ---
Error is still true.
Could you diagnose what the problem is?
Latest error message of bfgminer is:
EmitRawText called on an MCStreamer that doesn't support it, something must
not be fully mc'ized
On Sat, Jun 08, 2013 at 02:34:20PM +0200, Daniel Vetter wrote:
> On Sat, Jun 8, 2013 at 9:08 AM, Chris Wilson wrote:
> > On Wed, Jun 05, 2013 at 10:59:23PM +0100, Chris Wilson wrote:
> >> It is useful for userspace to know when it may be able to skip a forced
> >> detection cycle as the connector
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #30 from Tom Stellard ---
(In reply to comment #29)
> Error is still true.
> Could you diagnose what the problem is?
> Latest error message of bfgminer is:
>
> EmitRawText called on an MCStreamer that doesn't support it, something m
Drivers may need to make policy decisions based on the OS that the firmware
believes it's interacting with. ACPI firmware will make a series of _OSI
calls, starting from the oldest OS version they support and ending with the
most recent. Add a function to return the last successful call so that
dri
Windows 8 leaves backlight control up to individual graphics drivers rather
than making ACPI calls itself. There's plenty of evidence to suggest that
the Intel driver for Windows doesn't use the ACPI interface, including the
fact that it's broken on a bunch of machines when the OS claims to support
Windows 8 introduced new policy for backlight control by pushing it out to
graphics drivers. This appears to have coincided with a range of vendors
adding Windows 8 checks to their backlight control code which trigger either
awkward behaviour (Lenovo) or complete brokenness (some Dells). The simple
From: "Lee, Chun-Yi"
There have some situation we unregister whole acpi/video driver by downstream
driver just want to remove backlight control interface of acpi/video. It caues
we lost other functions of acpi/video, e.g. transfer acpi event to input event.
So, this patch add a new function, fin
On 2013년 06월 07일 20:24, Maarten Lankhorst wrote:
> Op 07-06-13 04:32, 김승우 schreef:
>> Hello Maarten,
>>
>> On 2013년 06월 05일 22:23, Maarten Lankhorst wrote:
>>> Op 31-05-13 10:54, Seung-Woo Kim schreef:
dma-buf attachment has only exporter private data, but importer private
data
ca
https://bugs.freedesktop.org/show_bug.cgi?id=65254
--- Comment #11 from adam ---
This is probably same as bug #60389
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
h
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/3d57ab2c/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/91d90a6e/attachment-0001.html>
org/archives/dri-devel/attachments/20130609/5bcc1d66/attachment.html>
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/1a0ba7cd/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/0c5e369b/attachment.html>
Hey,
Op 06-06-13 09:28, Fengguang Wu schreef:
> Hi Maarten,
>
> Thanks for the patch! I'll queue it for the tests.
>
>
I haven't heard back from you yet, did it fix all lockdep issues you were
having?
If so I'll get it queued.
~Maarten
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/fa891721/attachment.html>
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/6cec0ade/attachment.html>
Hi Dave,
Two fixes for memory leaks split into Cedarview and Poulsbo versions,
and a fix for properly setting the pipe base when using fbdev. It's on
my todo-list to start unifying the chips since they are very similar,
but until then I'd like to split them up in case there are side-effects
on Ced
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/2916969a/attachment.html>
This is version 2 of my DRM driver. Changes since the previous version:
1. It's now called Armada not Dove, because the "LCD controllers" aka CRTCs
are found in Armada 16x as well as Armada 510 Dove. The Armada 16x is
preliminary work.
2. Cursor support is now a separate patch. I've trie
This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 SoCs. This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
acceleration
- dual lcd0 and lcd1 crt operation
- video o
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dr
When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation. One such case encountered is the VIP output
mux register. This defaults to 0x24 on powerup, but other drivers may
set this to 0x12. Thi
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index cd1526c..c0d17ae 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 308 -
include/drm/i2c/tda998x.h | 30
2 files changed, 331 insertions(+), 7 deletions(-)
create mode 100644 include/drm/i2c/tda998x.h
diff --git a/drivers/gpu/drm/i2c/tda998x
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/Kconfig |9 +++
drivers/gpu/drm/armada/armada_drv.c | 42 +++
2 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index
On Sun, Jun 09, 2013 at 08:06:12PM +0100, Russell King - ARM Linux wrote:
> This is version 2 of my DRM driver. Changes since the previous version:
Okay, patch 1 got removed from this set, so some people won't see it
(it shouldn't have been sent). Patch 2 is in moderation, which is
probably the
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/dd3c8963/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/19d17040/attachment.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/608a6104/attachment.html>
On 06/09/2013 09:32 PM, Russell King wrote:
> The npix/nline registers are supposed to be programmed with the total
> number of pixels/lines, not the displayed pixels/lines, and not minus
> one either.
>
> Signed-off-by: Russell King
> ---
Russell, Rob,
I have patches fixing TDA998x sync generati
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/f3cab26e/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130609/1ccc04d1/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130609/f2d8408e/attachment.html>
On Sat, Jun 08, 2013 at 02:34:20PM +0200, Daniel Vetter wrote:
> On Sat, Jun 8, 2013 at 9:08 AM, Chris Wilson
> wrote:
> > On Wed, Jun 05, 2013 at 10:59:23PM +0100, Chris Wilson wrote:
> >> It is useful for userspace to know when it may be able to skip a forced
> >> detection cycle as the connect
27; on function '@search'
> Aborted
Rebuilding libclc should fix this.
--
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/20130609/347729b6/attachment.html>
Drivers may need to make policy decisions based on the OS that the firmware
believes it's interacting with. ACPI firmware will make a series of _OSI
calls, starting from the oldest OS version they support and ending with the
most recent. Add a function to return the last successful call so that
dri
Windows 8 leaves backlight control up to individual graphics drivers rather
than making ACPI calls itself. There's plenty of evidence to suggest that
the Intel driver for Windows doesn't use the ACPI interface, including the
fact that it's broken on a bunch of machines when the OS claims to support
Windows 8 introduced new policy for backlight control by pushing it out to
graphics drivers. This appears to have coincided with a range of vendors
adding Windows 8 checks to their backlight control code which trigger either
awkward behaviour (Lenovo) or complete brokenness (some Dells). The simple
From: "Lee, Chun-Yi"
There have some situation we unregister whole acpi/video driver by downstream
driver just want to remove backlight control interface of acpi/video. It caues
we lost other functions of acpi/video, e.g. transfer acpi event to input event.
So, this patch add a new function, fin
59 matches
Mail list logo
