FOSDEM2013: DevRoom or not?

Hello, I believe that the audience at FOSDEM might be interested in a general course about the graphics infrastructure under Linux. What I have in mind would be a talk that explains : what's X, why do we need it, what is so special about 3D applications that you need a "driver" to run any of

[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

On 09/28/2012 09:42 PM, Thomas Hellstrom wrote: > On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: >> Hey, >> >> Op 28-09-12 14:41, Maarten Lankhorst schreef: >>> Documentation says that code requiring dma-buf should add it to >>> select, so inline fallbacks are not going to be used. A link error

[Intel-gfx] [PATCH 3/3] drm/i915: Add HDMI vendor info frame support

On Thu, Sep 27, 2012 at 3:41 PM, Damien Lespiau wrote: > From: Damien Lespiau > > When scanning out a 3D framebuffer, send the corresponding infoframe to > the HDMI sink. > > See http://www.hdmi.org/manufacturer/specification.aspx for details. > > Signed-off-by: Damien Lespiau > --- >

[PATCH 2/3] drm: Parse the HDMI cea vendor block for 3D present

Reviewed-by: Rodrigo Vivi Tested-by: Rodrigo Vivi On Thu, Sep 27, 2012 at 3:41 PM, Damien Lespiau wrote: > From: Damien Lespiau > > For now, let's just look at the 3D_present flag of the CEA HDMI vendor > block to detect if the sink supports a small list of then mandatory 3D > formats. > >

[Intel-gfx] [PATCH 1/2] lib: Dump information about the supported 3D stereo formats

Reviewed-by: Rodrigo Vivi Tested-by: Rodrigo Vivi On Thu, Sep 27, 2012 at 3:42 PM, Damien Lespiau wrote: > From: Damien Lespiau > > When dumping the details of a mode, let's add the 3D formats the mode > supports. > > Signed-off-by: Damien Lespiau > --- > lib/drmtest.c | 13 +++-- >

[Intel-gfx] [PATCH 1/3] drm: Add an "expose 3d modes" property

Reviewed-by: Rodrigo Vivi Tested-by: Rodrigo Vivi On Thu, Sep 27, 2012 at 3:41 PM, Damien Lespiau wrote: > From: Damien Lespiau > > The "expose 3D modes" property can be attached to connectors to allow > user space to indicate it can deal with 3D modes and that the drm driver > should expose

[PATCH 2/2] tests/testdisplay: Test the stereo 3D modes

On Thu, Sep 27, 2012 at 3:42 PM, Damien Lespiau wrote: > From: Damien Lespiau > > Now that modes have flags to describe which 3d formats the sink > supports, it's time to test them. > > The new test cycles through the supported 3D formats and paint 3D > stereoscopic images taken from publicly

[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: > Hey, > > Op 28-09-12 14:41, Maarten Lankhorst schreef: >> Documentation says that code requiring dma-buf should add it to >> select, so inline fallbacks are not going to be used. A link error >> will make it obvious what went wrong, instead of

[PATCH 0/3] [RFC] DRM Render Nodes

On Fri, Sep 28, 2012 at 8:42 PM, Ilija Hadzic wrote: > > > On Fri, 28 Sep 2012, Daniel Vetter wrote: > >> On a quick look the rendernode Kristian propose and your work seem to >> attack slightly different issues. Your/Dave's patch series seems to >> put large efforts into (dynamically) splitting

[PATCH 0/3] [RFC] DRM Render Nodes

On Fri, Sep 28, 2012 at 7:59 PM, Ilija Hadzic wrote: > > > On Fri, 28 Sep 2012, Alex Deucher wrote: >> >> >> I haven't read through your patches yet, but Dave and Ilija already >> did something similar a while back: >> >> http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html >> >

[PATCH 14/14] drm: exynos: hdmi: remove drm common hdmi platform data struct

exynos-drm-hdmi need context pointers from hdmi and mixer. These pointers were expected from the plf data. Cleaned this dependency by exporting i/f which are called by hdmi, mixer driver probes for setting their context. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_drm_hdmi.c |

[PATCH 13/14] drm: exynos: hdmi: add support for exynos5 hdmi

This patch adds support for exynos5 hdmi with device tree enabled. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_hdmi.c | 83 -- 1 files changed, 79 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c

[PATCH 12/14] drm: exynos: hdmi: replace is_v13 with version check in hdmi

This patch removed the is_v13 variable from the hdmi driver context. It is replaced with condition check for the hdmi version. This cleans the way for handling further hdmi versions. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_hdmi.c | 40 +-

[PATCH 11/14] drm: exynos: hdmi: add support for exynos5 mixer

This patch adds support for exynos5 mixer with device tree enabled. Signed-off-by: Rahul Sharma Signed-off-by: Fahad Kunnathadi --- drivers/gpu/drm/exynos/exynos_mixer.c | 41 ++-- drivers/gpu/drm/exynos/regs-mixer.h |2 + 2 files changed, 40 insertions(+),

[PATCH 10/14] drm: exynos: hdmi: add support to disable video processor in mixer

This patch adds support for disabling the video processor code based on the platform type. This is done based on a field in the mixer driver data which changes with the platform variant. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_mixer.c | 151

[PATCH 09/14] drm: exynos: hdmi: add support for platform variants for mixer

This patch adds the support for multiple mixer versions avaialble in various platform variants. Version is passed as a driver data field instead of paltform data. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_mixer.c | 28 1 files changed, 28

[PATCH 08/14] drm: exynos: hdmi: add support for exynos5 hdmiphy

This patch adds support for exynos5 hdmi phy with device tree enabled. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_hdmiphy.c | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c

[PATCH 07/14] drm: exynos: hdmi: add support for exynos5 ddc

This patch adds support for exynos5 ddc with device tree enabled. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_ddc.c | 22 +- 1 files changed, 17 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c

[PATCH 06/14] drm: exynos: remove drm hdmi platform data struct

This patch removes the drm hdmi platform data structure which is no longer in use by drm hdmi driver after this patch set get merged. s5p hdmi platform data structure is used instead. Signed-off-by: Rahul Sharma --- include/drm/exynos_drm.h | 13 - 1 files changed, 0

[PATCH 05/14] drm: exynos: hdmi: turn off HPD interrupt in HDMI chip

From: Tomasz Stanislawski The plug/unplug interrupt are handled by a separate interrupt. So there is no need to replicate this mechanism in HDMI core. Signed-off-by: Tomasz Stanislawski Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_hdmi.c |5

[PATCH 04/14] drm: exynos: hdmi: use s5p-hdmi platform data

From: Tomasz Stanislawski The 'exynos-drm-hdmi' driver makes use of s5p-tv platform devices. Therefore the driver should use the same platform data to prevent crashes caused by dereferencing incorrect types. This patch corrects the exynos-drm-hdmi driver to the

[PATCH 03/14] drm: exynos: hdmi: fix interrupt handling

From: Tomasz Stanislawski This patch fixes 'unsigned < 0' check in probe. Moreover it releases an interrupt at remove. Signed-off-by: Tomasz Stanislawski Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_hdmi.c |5 +++-- 1 files changed, 3

[PATCH 02/14] drm: exynos: hdmi: support for platform variants

From: Tomasz Stanislawski This patch implements check if HDMI is version 1.3 by using a driver variant instead of platform data. Signed-off-by: Tomasz Stanislawski Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_hdmi.c | 25 -

[PATCH 01/14] media: s5p-hdmi: add HPD GPIO to platform data

From: Tomasz Stanislawski This patch extends s5p-hdmi platform data by a GPIO identifier for Hot-Plug-Detection pin. Signed-off-by: Tomasz Stanislawski Signed-off-by: Kyungmin Park --- include/media/s5p_hdmi.h |2 ++ 1 files changed, 2 insertions(+), 0

[PATCH 00/14] drm: exynos: hdmi: add dt based support for exynos5 hdmi

This patch set adds the DT based support for Samsung's Exynos5250 in DRM-HDMI. It includes disabling of hdmi internal interrupt, suppport for platform variants for hdmi and mixer, support to disable video processor based on platform type and removal of drm common platform data. Rahul Sharma (9):

[PATCH 4/5] reservation: cross-device reservation support

Op 28-09-12 17:29, Thomas Hellstr?m schreef: > On 9/28/12 2:43 PM, Maarten Lankhorst wrote: >> This adds support for a generic reservations framework that can be >> hooked up to ttm and dma-buf and allows easy sharing of reservations >> across devices. >> >> The idea is that a dma-buf and ttm

FOSDEM2013: DevRoom or not?

On Fri, Sep 21, 2012 at 11:35:12AM +0200, Luc Verhaegen wrote: > On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote: > > Hi, > > > > The FOSDEM organizers have sent out a call for devrooms. FOSDEM this > > year is on the weekend of the 2nd and 3rd of February 2013. > > > > After the

[PATCH 4/5] reservation: cross-device reservation support

On 9/28/12 2:43 PM, Maarten Lankhorst wrote: > This adds support for a generic reservations framework that can be > hooked up to ttm and dma-buf and allows easy sharing of reservations > across devices. > > The idea is that a dma-buf and ttm object both will get a pointer > to a struct

[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: > Documentation says that code requiring dma-buf should add it to > select, so inline fallbacks are not going to be used. A link error > will make it obvious what went wrong, instead of silently doing > nothing at runtime. > The whole patch

[PATCH] drm: call connector->dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 3:36 PM, Alex Deucher wrote: > Thinking about modern hw, I'd probably only expose connectors and > monitors (or maybe call them displays). You could hang backlight > controls and brightness, etc on the monitor objects. Also you could > have a multiple monitors connected

[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

On Fri, Sep 28, 2012 at 02:41:48PM +0200, Maarten Lankhorst wrote: > Documentation says that code requiring dma-buf should add it to > select, so inline fallbacks are not going to be used. A link error > will make it obvious what went wrong, instead of silently doing > nothing at runtime. > >

[PATCH] drm: call connector->dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 01:55:19PM +0200, Daniel Vetter wrote: > On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark wrote: > > Maybe it just makes sense to always do connector->dpms(OFF) before > > unhooking the chain, rather than directly calling dpms on the > > encoder/crtc? > > Well, that makes the

[PATCH] drm: call connector->dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 2:52 PM, Alan Cox wrote: > On Fri, 28 Sep 2012 09:27:18 +0200 > Rob Clark wrote: > >> From: Rob Clark >> >> When disabling unused connectors, be sure to call connector->dpms(OFF), >> so if there is actually some IP to turn off (such as external bridge >> chips, etc),

[Bug 55421] [llvm] glxgears discolored and flickering

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/660c47e6/attachment.html>

[Bug 55421] [llvm] glxgears discolored and flickering

You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/2763e1f0/attachment-0001.html>

[PATCH 5/5] reservation: Add lockdep annotation and selftests

Signed-off-by: Maarten Lankhorst --- The self-tests will fail if the commit "lockdep: Check if nested lock is actually held" from linux tip core/locking is not applied. --- drivers/base/reservation.c | 46 +- include/linux/reservation.h | 29 +++- lib/Kconfig.debug |1

[PATCH 4/5] reservation: cross-device reservation support

This adds support for a generic reservations framework that can be hooked up to ttm and dma-buf and allows easy sharing of reservations across devices. The idea is that a dma-buf and ttm object both will get a pointer to a struct reservation_object, which has to be reserved before anything is

[PATCH 3/5] seqno-fence: Hardware dma-buf implementation of fencing (v3)

This type of fence can be used with hardware synchronization for simple hardware that can block execution until the condition (dma_buf[offset] - value) >= 0 has been met. A software fallback still has to be provided in case the fence is used with a device that doesn't support this mechanism. It

[PATCH 2/5] fence: dma-buf cross-device synchronization (v9)

A fence can be attached to a buffer which is being filled or consumed by hw, to allow userspace to pass the buffer without waiting to another device. For example, userspace can call page_flip ioctl to display the next frame of graphics after kicking the GPU but while the GPU is still rendering.

[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. Signed-off-by: Maarten Lankhorst --- include/linux/dma-buf.h | 99

[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

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/20120928/b00e8ead/attachment.html>

[PATCH] drm: call connector->dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 1:55 PM, Daniel Vetter wrote: > On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark wrote: >> Maybe it just makes sense to always do connector->dpms(OFF) before >> unhooking the chain, rather than directly calling dpms on the >> encoder/crtc? > > Well, that makes the entire

[Bug 55421] New: glxgears discolored and flickering

. No errors are emitted. -- 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/20120928/bb474a45/attachment.html>

[Bug 55416] [R600g] Torchlight gives GPU lockup

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/0fcbb7a1/attachment.html>

[PATCH] drm: call connector->dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark wrote: > Maybe it just makes sense to always do connector->dpms(OFF) before > unhooking the chain, rather than directly calling dpms on the > encoder/crtc? Well, that makes the entire (optional) ->disable stuff a bit more awkward. The thing imo really

[PATCH] drm: call connector->dpms(OFF) when disabling

On Fri, 28 Sep 2012 09:27:18 +0200 Rob Clark wrote: > From: Rob Clark > > When disabling unused connectors, be sure to call connector->dpms(OFF), > so if there is actually some IP to turn off (such as external bridge > chips, etc), these actually do get turned off. That's a fairly drastic and

[Bug 55416] [R600g] Torchlight gives GPU lockup

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/46ea6b10/attachment.html>

[PATCH 0/3] [RFC] DRM Render Nodes

On Fri, Sep 28, 2012 at 12:35 PM, Kristian H?gsberg wrote: > Here's the patch to implement render nodes as discussed in the "DRM2" > talk at XDC: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 > > The core problem is that DRM security is compromised in the face of > VT switching

[PATCH 0/3] [RFC] DRM Render Nodes

On Fri, 28 Sep 2012, Daniel Vetter wrote: > On a quick look the rendernode Kristian propose and your work seem to > attack slightly different issues. Your/Dave's patch series seems to > put large efforts into (dynamically) splitting up the resources of a > drm device, including the modeset

[PATCH 1/3] drm: Fix DRM_MINOR limits for control and render nodes

On Fri, 28 Sep 2012, Kristian H?gsberg wrote: if (type == DRM_MINOR_CONTROL) { base += 64; -limit = base + 127; +limit = base + 64; } else if (type == DRM_MINOR_RENDER) { base += 128; -limit =

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/34cd012f/attachment.html>

[PATCH 0/3] [RFC] DRM Render Nodes

On Fri, 28 Sep 2012, Alex Deucher wrote: > > I haven't read through your patches yet, but Dave and Ilija already > did something similar a while back: > > http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html > Actually, there is a, a newer series of patches here (applied few

[Bug 55416] New: [R600g] Torchlight gives GPU lockup

chment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/b9734214/attachment.html>

[PATCH] drm: call connector->dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 11:56 AM, Daniel Vetter wrote: > On Fri, Sep 28, 2012 at 09:27:18AM +0200, Rob Clark wrote: >> From: Rob Clark >> >> When disabling unused connectors, be sure to call connector->dpms(OFF), >> so if there is actually some IP to turn off (such as external bridge >> chips,

[PATCH 2/3] drm: Add support for render nodes

This patch introduces a new kind of drm device node: the render node. A render node exposes a safe subset of the legacy drm device ioctls and can only be used for rendering. The legacy node supports modesetting, DRI1 and global buffer sharing, while the render node only supports rendering and

[PATCH 1/3] drm: Fix DRM_MINOR limits for control and render nodes

We got the minor number base right, but limit is too big and causes the minor numer ranges for the control and render nodes to overlap. Signed-off-by: Kristian H?gsberg --- drivers/gpu/drm/drm_stub.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 0/3] [RFC] DRM Render Nodes

Here's the patch to implement render nodes as discussed in the "DRM2" talk at XDC: http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 The core problem is that DRM security is compromised in the face of VT switching and multiple DRM masters. Any local user can access all shared buffers

[PATCH] drm: call connector->dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 09:27:18AM +0200, Rob Clark wrote: > From: Rob Clark > > When disabling unused connectors, be sure to call connector->dpms(OFF), > so if there is actually some IP to turn off (such as external bridge > chips, etc), these actually do get turned off. > > Signed-off-by: Rob

[ 192/262] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

From: Greg KH 3.5-stable review patch. If anyone has any objections, please let me know. -- From: Paul Menzel commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b upstream. Connecting an ASUS VW222S [1] over VGA a

[PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()

Op 28-09-12 09:29, Rob Clark schreef: > From: Rob Clark > > We never really clarified if unmap could be done in atomic context. > But since mapping might require sleeping, this implies mutex in use > to synchronize mapping/unmapping, so unmap could sleep as well. Add > a might_sleep() to clarify

[PATCH] drm: call connector->dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 8:19 AM, Rob Clark wrote: > On Fri, Sep 28, 2012 at 1:55 PM, Daniel Vetter wrote: >> On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark wrote: >>> Maybe it just makes sense to always do connector->dpms(OFF) before >>> unhooking the chain, rather than directly calling dpms on

[PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()

From: Rob Clark We never really clarified if unmap could be done in atomic context. But since mapping might require sleeping, this implies mutex in use to synchronize mapping/unmapping, so unmap could sleep as well. Add a might_sleep() to clarify this. Signed-off-by: Rob Clark

[PATCH] drm: call connector->dpms(OFF) when disabling

From: Rob Clark When disabling unused connectors, be sure to call connector->dpms(OFF), so if there is actually some IP to turn off (such as external bridge chips, etc), these actually do get turned off. Signed-off-by: Rob Clark Tested-by: Roger Quadros ---

FOSDEM2013: DevRoom or not?

On Fri, 28 Sep 2012 17:44:27 +0200 Luc Verhaegen wrote: > On Fri, Sep 21, 2012 at 11:35:12AM +0200, Luc Verhaegen wrote: > > On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote: > > > Hi, > > > > > > The FOSDEM organizers have sent out a call for devrooms. FOSDEM this > > > year is

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

ing 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/20120928/58b6f9e3/attachment.html>

[Bug 55217] [RS880] opengl not working anymore

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20120928/bcba536d/attachment.html>

hot CPU with 3.6.0-rc7+ and intel graphic

On 27.09.2012 17:42, Toralf F?rster wrote: > I'm observing a high CPU usage at my ThinkPad T420 (i5-2540M CPU), w/ > integrated intel graphic. > > Powertop-2.1 shows that the GPU is always at 100%, although I've defined > these settings : > $> cat /etc/modprobe.d/i915.conf > options i915

[PATCH v5 3/3] drm: Add EDID quirk for LG L246WP

This display is apparently confused by any InfoFrames (see https://bugzilla.redhat.com/show_bug.cgi?id=806091). Tested on a ThinkPad T510 (nVidia GT218 [NVS 3100M]). Signed-off-by: Ian Pilcher --- drivers/gpu/drm/drm_edid.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v5 2/3] drm: Add EDID quirk to disable HDMI InfoFrames

EDID_QUIRK_DISABLE_INFOFRAMES turns off all HDMI-specific functionality (audio, HDCP, 3D, etc.). Intended for displays that are confused by *any* InfoFrames. Signed-off-by: Ian Pilcher --- drivers/gpu/drm/drm_edid.c | 10 ++ 1 file changed, 10 insertions(+) diff --git

[PATCH v5 1/3] drm: Add user-defined EDID quirks capability

Add the ability for users to define their own EDID quirks via a module parameter or sysfs attribute. Signed-off-by: Ian Pilcher --- Documentation/EDID/edid_quirks.txt | 126 ++ drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_edid.c | 500

[PATCH v5 0/3] Enhanced EDID quirk functionality

As promised, this patch series does only the following: * Add user-defined EDID quirks -- via sysfs or a module parameter * Add an EDID quirk flag to disable all HDMI functionality (InfoFrames) * Add a quirk to disable HDMI InfoFrames for the LG L246WP

[Bug 55217] [RS880] opengl not working anymore

https://bugs.freedesktop.org/show_bug.cgi?id=55217 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Status|NEW |RESOLVED

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote: On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund and...@anarazel.de wrote: On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote: -Original Message- From: Andres Freund [mailto:and...@anarazel.de]

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #7 from Fede fed...@yahoo.com --- Created attachment 67811 -- https://bugs.freedesktop.org/attachment.cgi?id=67811action=edit radeon errors in dmesg while playing DC Universe Online in wine As I run the game, wine is complaining

[PATCH v5 0/3] Enhanced EDID quirk functionality

As promised, this patch series does only the following: * Add user-defined EDID quirks -- via sysfs or a module parameter * Add an EDID quirk flag to disable all HDMI functionality (InfoFrames) * Add a quirk to disable HDMI InfoFrames for the LG L246WP

[PATCH v5 1/3] drm: Add user-defined EDID quirks capability

Add the ability for users to define their own EDID quirks via a module parameter or sysfs attribute. Signed-off-by: Ian Pilcher arequip...@gmail.com --- Documentation/EDID/edid_quirks.txt | 126 ++ drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_edid.c | 500

[PATCH v5 2/3] drm: Add EDID quirk to disable HDMI InfoFrames

EDID_QUIRK_DISABLE_INFOFRAMES turns off all HDMI-specific functionality (audio, HDCP, 3D, etc.). Intended for displays that are confused by *any* InfoFrames. Signed-off-by: Ian Pilcher arequip...@gmail.com --- drivers/gpu/drm/drm_edid.c | 10 ++ 1 file changed, 10 insertions(+) diff

[PATCH v5 3/3] drm: Add EDID quirk for LG L246WP

This display is apparently confused by any InfoFrames (see https://bugzilla.redhat.com/show_bug.cgi?id=806091). Tested on a ThinkPad T510 (nVidia GT218 [NVS 3100M]). Signed-off-by: Ian Pilcher arequip...@gmail.com --- drivers/gpu/drm/drm_edid.c | 4 1 file changed, 4 insertions(+) diff

[PATCH] drm: call connector-dpms(OFF) when disabling

From: Rob Clark r...@ti.com When disabling unused connectors, be sure to call connector-dpms(OFF), so if there is actually some IP to turn off (such as external bridge chips, etc), these actually do get turned off. Signed-off-by: Rob Clark r...@ti.com Tested-by: Roger Quadros rog...@ti.com ---

[PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()

From: Rob Clark r...@ti.com We never really clarified if unmap could be done in atomic context. But since mapping might require sleeping, this implies mutex in use to synchronize mapping/unmapping, so unmap could sleep as well. Add a might_sleep() to clarify this. Signed-off-by: Rob Clark

Re: [PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()

Op 28-09-12 09:29, Rob Clark schreef: From: Rob Clark r...@ti.com We never really clarified if unmap could be done in atomic context. But since mapping might require sleeping, this implies mutex in use to synchronize mapping/unmapping, so unmap could sleep as well. Add a might_sleep() to

Re: [PATCH] drm: call connector-dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 11:56 AM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Sep 28, 2012 at 09:27:18AM +0200, Rob Clark wrote: From: Rob Clark r...@ti.com When disabling unused connectors, be sure to call connector-dpms(OFF), so if there is actually some IP to turn off (such as external

Re: [PATCH] drm: call connector-dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark rob.cl...@linaro.org wrote: Maybe it just makes sense to always do connector-dpms(OFF) before unhooking the chain, rather than directly calling dpms on the encoder/crtc? Well, that makes the entire (optional) -disable stuff a bit more awkward. The

Re: [PATCH] drm: call connector-dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 01:55:19PM +0200, Daniel Vetter wrote: On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark rob.cl...@linaro.org wrote: Maybe it just makes sense to always do connector-dpms(OFF) before unhooking the chain, rather than directly calling dpms on the encoder/crtc? Well, that

Re: [PATCH] drm: call connector-dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 1:55 PM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark rob.cl...@linaro.org wrote: Maybe it just makes sense to always do connector-dpms(OFF) before unhooking the chain, rather than directly calling dpms on the encoder/crtc? Well,

[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com ---

[PATCH 2/5] fence: dma-buf cross-device synchronization (v9)

A fence can be attached to a buffer which is being filled or consumed by hw, to allow userspace to pass the buffer without waiting to another device. For example, userspace can call page_flip ioctl to display the next frame of graphics after kicking the GPU but while the GPU is still rendering.

[PATCH 3/5] seqno-fence: Hardware dma-buf implementation of fencing (v3)

This type of fence can be used with hardware synchronization for simple hardware that can block execution until the condition (dma_buf[offset] - value) = 0 has been met. A software fallback still has to be provided in case the fence is used with a device that doesn't support this mechanism. It is

[PATCH 5/5] reservation: Add lockdep annotation and selftests

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- The self-tests will fail if the commit lockdep: Check if nested lock is actually held from linux tip core/locking is not applied. --- drivers/base/reservation.c | 46 +- include/linux/reservation.h | 29 +++-

Re: [PATCH] drm: call connector-dpms(OFF) when disabling

On Fri, 28 Sep 2012 09:27:18 +0200 Rob Clark rob.cl...@linaro.org wrote: From: Rob Clark r...@ti.com When disabling unused connectors, be sure to call connector-dpms(OFF), so if there is actually some IP to turn off (such as external bridge chips, etc), these actually do get turned off.

[Bug 55416] New: [R600g] Torchlight gives GPU lockup

https://bugs.freedesktop.org/show_bug.cgi?id=55416 Priority: medium Bug ID: 55416 Assignee: dri-devel@lists.freedesktop.org Summary: [R600g] Torchlight gives GPU lockup Severity: normal Classification: Unclassified OS: Linux

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #8 from Alex Deucher ag...@yahoo.com --- Is this still an issue with a newer version of mesa? git master or a 9.0 snapshot? -- You are receiving this mail because: You are the assignee for the bug.

Re: [PATCH] drm: call connector-dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 2:52 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Fri, 28 Sep 2012 09:27:18 +0200 Rob Clark rob.cl...@linaro.org wrote: From: Rob Clark r...@ti.com When disabling unused connectors, be sure to call connector-dpms(OFF), so if there is actually some IP to turn off

Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

On Fri, Sep 28, 2012 at 02:41:48PM +0200, Maarten Lankhorst wrote: Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime.

Re: [PATCH] drm: call connector-dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 8:19 AM, Rob Clark rob.cl...@linaro.org wrote: On Fri, Sep 28, 2012 at 1:55 PM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark rob.cl...@linaro.org wrote: Maybe it just makes sense to always do connector-dpms(OFF) before unhooking the

[Bug 55416] [R600g] Torchlight gives GPU lockup

https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #1 from Laurent carlier lordhea...@gmail.com --- Here is a trace that i can reproduce the lockup: http://pkgbuild.com/~lcarlier/trace/Torchlight.bin.x86_64.trace.tar.gz -- You are receiving this mail because: You are the assignee

Re: [PATCH] drm: call connector-dpms(OFF) when disabling

On Fri, Sep 28, 2012 at 3:36 PM, Alex Deucher alexdeuc...@gmail.com wrote: Thinking about modern hw, I'd probably only expose connectors and monitors (or maybe call them displays). You could hang backlight controls and brightness, etc on the monitor objects. Also you could have a multiple

[Bug 55416] [R600g] Torchlight gives GPU lockup

https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #2 from Laurent carlier lordhea...@gmail.com --- Mesa is built with: ./autogen.sh --prefix=/usr --sysconfdir=/etc --with-dri-driverdir=/usr/lib/xorg/modules/dri --with-gallium-drivers=r300,r600,radeonsi,nouveau,swrast,svga

[Bug 55421] New: glxgears discolored and flickering

https://bugs.freedesktop.org/show_bug.cgi?id=55421 Priority: medium Bug ID: 55421 Assignee: dri-devel@lists.freedesktop.org Summary: glxgears discolored and flickering Severity: normal Classification: Unclassified OS: Linux

Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. The whole patch

  1   2   >