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
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
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
> ---
>
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.
>
>
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 +++--
>
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
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
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
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
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
>>
>
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 |
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
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 +-
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(+),
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
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
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
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
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
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
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
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
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 -
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
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):
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
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
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
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
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
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.
>
>
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
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),
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/660c47e6/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/20120928/2763e1f0/attachment-0001.html>
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
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
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
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.
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
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>
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
. 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>
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>
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
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
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/46ea6b10/attachment.html>
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
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
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 =
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/34cd012f/attachment.html>
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
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/b9734214/attachment.html>
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,
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
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
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
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
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
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
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
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
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
---
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
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>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20120928/bcba536d/attachment.html>
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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=55217
Fabio Pedretti fabio@libero.it changed:
What|Removed |Added
Status|NEW |RESOLVED
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]
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
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
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
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
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
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
---
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
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
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
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
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
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,
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
---
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.
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
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 +++-
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.
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
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.
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
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.
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
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
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
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
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
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 - 100 of 142 matches
Mail list logo