https://bugs.freedesktop.org/show_bug.cgi?id=55217
Fabio Pedretti changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund wrote:
> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
> >> > -Original Message-
> >> > From: Andres Freund [mailto:and...@anarazel.de]
> >> > Sent: W
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #7 from Fede ---
Created attachment 67811
--> https://bugs.freedesktop.org/attachment.cgi?id=67811&action=edit
radeon errors in dmesg while playing DC Universe Online in wine
As I run the game, wine is complaining of:
radeon: The
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
---
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
---
drivers/gpu/drm/drm_edid.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm
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 a/drivers/gpu/drm
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
---
drivers/gpu/drm/drm_crtc_helper.c
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
Acked-by: Daniel
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 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
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, et
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 i
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 e
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 (optio
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 -
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. T
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
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 done
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
l
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
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 ---
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.
___
d
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), thes
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.
>
> Sign
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 the
https://bugs.freedesktop.org/show_bug.cgi?id=55416
--- Comment #1 from Laurent carlier ---
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 for the bug.
_
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 t
https://bugs.freedesktop.org/show_bug.cgi?id=55416
--- Comment #2 from Laurent carlier ---
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
--with-egl-platforms=x11,wayla
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 s
https://bugs.freedesktop.org/show_bug.cgi?id=49981
graham changed:
What|Removed |Added
CC||grhm.pe...@gmail.com
--- Comment #3 from graham
https://bugs.freedesktop.org/show_bug.cgi?id=55421
Michel Dänzer changed:
What|Removed |Added
Summary|glxgears discolored and |[llvm] glxgears discolored
https://bugs.freedesktop.org/show_bug.cgi?id=55421
--- Comment #2 from Stanisław Halik ---
Yes, LLVM only. It happens on 'radeon' and 'r600g' the same.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing lis
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 reservation_object, w
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 s
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 objec
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 on
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):
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 deletions(-)
diff --git a/include/m
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 -
1 files changed, 24 inser
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 platform data from s5p-hdmi.
Sign
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 insertions(+), 2 deletions(-)
diff
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 insertions(+),
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 +
1 files changed, 1 inse
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 insert
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
b/drivers/gpu/drm/exynos/exyno
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 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
b/drivers/gpu/drm/exynos/ex
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(+), 3
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 +-
1
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
b/drivers/gpu/d
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 |
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 from
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 a/drivers/gpu/drm/drm_s
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 limi
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++--
drivers/gpu/drm/i915/i915_drv.c |3 ++-
2 files changed, 20 inser
On Fri, Sep 28, 2012 at 6:07 PM, Jesse Barnes wrote:
> 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 h
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 and
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 comments
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 = ba
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
>>
>
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 stuff.
Co
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 u
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 silently doing
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
will make it ob
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 them
Hi
This is revision 2 of the manpages for libdrm. I converted everything to docbook
XML. This makes it easier to write them (troff is really hard to read) and
allows us to integrate it into other documentation.
Other than that I only fixed typos and the small corrections you guys mentioned.
Thank
If we want to use the manpages in external documentation other than normal
manpages, we should rather use XML. Furthermore, almost no-one knows troff
today, anyway, and XML allows others to easily add more pages without
having to learn troff.
Signed-off-by: David Herrmann
---
.gitignore
The drm.xml file compiles to drm.7 and is meant as a global overview page
for libdrm. It is targeted to new users of libdrm and redirects to all
other main man-pages.
Signed-off-by: David Herrmann
Reviewed-by: Jesse Barnes
---
man/Makefile.am | 1 +
man/drm.xml | 137 +
This is an overview page for KMS. It is again targeted at novice users
that need redirection to the correct function man-pages.
Signed-off-by: David Herrmann
Reviewed-by: Jesse Barnes
---
man/Makefile.am | 1 +
man/drm-kms.xml | 342
2
This adds an overview page that describes Dumb-Buffers, TTM and GEM. It
does not describe chipset-specific features. You should do that in the
driver-manpages.
Signed-off-by: David Herrmann
Reviewed-by: Jesse Barnes
---
man/Makefile.am| 9 +-
man/drm-memory.xml | 430 +
On Fri, Sep 28, 2012 at 05:44:27PM +0200, Luc Verhaegen wrote:
>
> Final reminder: the deadline is tonight.
>
> So far there are three speakers who lined up, and my feeling is that
> Matthieu and Marc lined up just so that the deadline and requirement
> will be met. So only a single person is i
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 ava
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 t
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
>
> 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.
>
> See
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
> ---
> drivers/g
https://bugs.freedesktop.org/show_bug.cgi?id=55416
--- Comment #3 from Anthony Waters ---
I bisected this a few days ago, the commit that causes the issue is
c8b06dccff9cb89e20378664f3cbc202876a180f
r600g: atomize framebuffer state
--
You are receiving this mail because:
You are the assignee f
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 i915_enab
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20120928/bcba536d/attachment.html>
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/58b6f9e3/attachment.html>
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 ++
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 a/drivers/gpu/drm
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
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 a/drivers/gpu/drm
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
---
drivers/gpu/drm/drm_crtc_helper.c
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
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
Acked-by: Daniel
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
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, et
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 i
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 e
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 (optio
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 -
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. T
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
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 done
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
l
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
1 - 100 of 158 matches
Mail list logo
