:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/4f40d8ee/attachment.html>
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/20131016/6596408c/attachment.html>
On Wed, Oct 16, 2013 at 04:34:57PM -0400, Joseph Salisbury wrote:
> BugLink: http://bugs.launchpad.net/bugs/1195483
>
> This reverts commit 657445fe8660100ad174600ebfa61536392b7624.
>
> Signed-off-by: Joseph Salisbury
> Cc: Daniel Vetter
> Cc: Paulo Zanoni
> Cc: David Airlie
> Cc: stable at v
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131016/297e6627/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/03e007b7/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/5118ce03/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=63181
Elmar Stellnberger changed:
What|Removed |Added
Attachment #111361|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=63181
--- Comment #1 from Elmar Stellnberger ---
Created attachment 111371
--> https://bugzilla.kernel.org/attachment.cgi?id=111371&action=edit
screenshot of the kernel panic
--
You are receiving this mail because:
You are watching the assignee of t
https://bugzilla.kernel.org/show_bug.cgi?id=63181
Bug ID: 63181
Summary: Amilo Xi 2550: kernel panic during normal operation
Product: Drivers
Version: 2.5
Kernel Version: 3.11.1-1.g1383321-desktop
Hardware: x86-64
OS: Linux
The amount of data wanted by the userspace caller is encoded in the
ioctl number. Generic drm ioctls were ignoring it.
As a result, Intel Xorg driver didn't work for i386 userspace on x86_64
kernel on some systems. sizeof(struct drm_mode_get_connector) is 76
bytes on i686 and 80 bytes on x86_64
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/20f00766/attachment.html>
On Wed, Oct 16, 2013 at 06:07:30PM +0300, Ville Syrj?l? wrote:
> On Wed, Oct 16, 2013 at 03:58:50PM +0100, Thomas Wood wrote:
> > Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
> > Specific Data Block to expose more stereo 3D modes.
> >
> > v2: Use (1 << 0) for consistency. (Vill
Embedding a mutex inside drm_crtc structure evokes a
subtle and rare corruption in drm_crtc_helper_set_config
failure-recovery path.
Namely, if drm_crtc_helper_set_config takes the
path under 'fail:' label *and* some other process
has attempted to grab the crtc mutex (and got blocked),
restoring t
n new bug?
--
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/20131016/d5cbb549/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/08edbbfe/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/7a76a8c4/attachment-0001.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/472655ad/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/981fb60f/attachment.html>
Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
HDMI Vendor Specific Block.
Signed-off-by: Thomas Wood
---
edid-decode.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/edid-decode.c b/edid-decode.c
index 4265843..8441dec 10064
On Wed, Oct 16, 2013 at 3:26 PM, Sean Paul wrote:
> This patch removes all of the suspend/resume logic from the individual
> drivers and consolidates it in drm_drv. This consolidation reduces the
> number of functions which enable/disable the hardware to just one -- the
> dpms callback. This ensur
BugLink: http://bugs.launchpad.net/bugs/1195483
This reverts commit 657445fe8660100ad174600ebfa61536392b7624.
Signed-off-by: Joseph Salisbury
Cc: Daniel Vetter
Cc: Paulo Zanoni
Cc: David Airlie
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp.c | 18 ++
1 f
Hi Daniel,
A bug was opened against the Ubuntu kernel[0]. It was found that reverting the
following commit resolved this bug:
commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter
Date: Sat May 4 10:09:18 2013 +0200
Revert "drm/i915: revert eDP bpp clamping code changes"
https://bugzilla.kernel.org/show_bug.cgi?id=63011
Mikko Rapeli changed:
What|Removed |Added
Attachment #111241|0 |1
is obsolete|
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.
v2: Use (1 << 0) for consistency. (Ville Syrj?l?)
Skip adding any modes if 3D_MASK is indicated as being present but
the length only includes 3D_Structure_ALL. (Ville Syrj?l
https://bugzilla.kernel.org/show_bug.cgi?id=62681
--- Comment #1 from Rich Coe ---
I found https://bugs.freedesktop.org/show_bug.cgi?id=69982
which suggests booting with nouveau.config=NvMSI=0
I haven't tried it yet, as I've been currently running under
boot parameter nouveau.noaccel=1, and t
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #12 from Alex Deucher ---
Created attachment 111341
--> https://bugzilla.kernel.org/attachment.cgi?id=111341&action=edit
make missing smc ucode non-fatal
This patch should fix the issue if the smc ucode is missing.
--
You are rece
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #11 from Alex Deucher ---
You need to install the new SMC ucode for your card. The driver is failing to
initialize without it so you are ending up with the vesa driver.
[3.519520] smc: error loading firmware "radeon/CAICOS_smc.bi
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #10 from Mikko Rapeli ---
Created attachment 111331
--> https://bugzilla.kernel.org/attachment.cgi?id=111331&action=edit
dmesg with 3.11.5
dmesg from plain 3.11.5 attached.
The horizontal stripes also appear on the laptop display,
This patch removes all of the suspend/resume logic from the individual
drivers and consolidates it in drm_drv. This consolidation reduces the
number of functions which enable/disable the hardware to just one -- the
dpms callback. This ensures that we always power up/down in a consistent
manner.
Si
This patch separates the fimd_activate function into poweron/poweroff
functions to be more consistent with the other drivers in exynos drm. It
also properly cleans up after failures in poweron. The functions have
also been shuffled around such that they are all in the same
spot in the file and powe
This patch implements the dpms display callback for the DP driver.
Signed-off-by: Sean Paul
---
Changes in v2:
- Added to the patchset
drivers/gpu/drm/exynos/exynos_dp_core.c | 173
drivers/gpu/drm/exynos/exynos_dp_core.h | 1 +
2 files changed, 85 in
This patch moves the display-timings node from fimd to dp to reflect the
device tree bindings change.
Signed-off-by: Sean Paul
---
Changes in v2: None
arch/arm/boot/dts/exynos5250-arndale.dts | 7 ---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 7 ---
arch/arm/boot/dts/exynos5250-snow
This patch moves the exynos_drm_display implementation from fimd into
the dp driver. This will allow for tighter integration of the dp driver
into the exynos drm driver.
Signed-off-by: Sean Paul
---
Changes in v2: None
.../devicetree/bindings/video/exynos_dp.txt| 17 +++
.../devicetre
This patch moves the code from video/ to drm/
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exynos/Kconfig |7 +
drivers/gpu/drm/exynos/Makefile |1 +
drivers/gpu/drm/exynos/exynos_dp_core.c | 1213 ++
drivers/gpu/drm/exyn
This patch removes a few fimd_context members which are either entirely
unused or unneeded.
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_
This patch uses the mode passed into mode_set to configure fimd instead
of directly using the panel from context. This will allow us to move
the exynos_drm_display implementation from fimd into the DP driver
where it belongs.
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exy
This patch adds a new manager callback for mode_fixup and pipes it
through exynos_drm_crtc.
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 7 ++-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 4
2 files changed, 10 insertions(+), 1 deletion(-)
This patch adds a mode_set callback to the manager operations which
sets the crtc's current mode to the manager driver.
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++
2 files changed, 7 inser
This patch moves the code which disables unused crtc planes from the
encoder to the crtc. Since there is a 1:1 encoder/crtc mapping in
exynos, the only valid crtc change the pre-existing code could catch is
disconnecting an active crtc from the encoder. Thus it is functionally
equivalent to just di
This patch changes the manual copying of mode to adjusted_mode in
mode_fixup to use drm_mode_copy instead of handling things manually.
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --g
This patch trims exynos_drm_hdmi out of the driver. The reason it
existed in the first place was to make up for the mixture of
display/overlay/manager ops being spread across hdmi and mixer. With
that code now rationalized, mixer and hdmi map directly to
exynos_drm_crtc and exynos_drm_encoder, resp
From: Daniel Kurtz
The i2c client was previously being passed into the hdmi driver via a
dedicated i2c driver, and then a global variable. This patch removes all
of that and just uses the device tree to get the i2c_client. This patch
also properly references the client so we don't lose it before
This patch splits display and manager from subdrv. The result is that
crtc functions can directly call into manager callbacks and encoder
functions can directly call into display callbacks. This will allow
us to remove the exynos_drm_hdmi shim and support mixer/hdmi & fimd/dp
with common code.
Sig
Change all instances of possible_crtcs in the exynos drm driver to be
unsigned long. This matches the type used in the drm layer.
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 2 +-
drivers/gpu
This patch removes the dpms state tracking in encoder. This
state is at best confusing and at worst incorrect since the display
drivers can turn on and off without propagating the value.
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 17 -
This patch renames the display_op power_on to dpms to accurately reflect
what the function does.
The side-effect of this patch is that the new hdmi dpms callback is now
invoked twice in the dpms path. This is safe and will be dealt with when
the exynos_drm shim goes away.
Signed-off-by: Sean Paul
This patch removes the call from encoder dpms into connector dpms (which
will then call back into encoder dpms through the helper function). The
callback is likely to keep connector->dpms in the right state when
initiating dpms from crtc or encoder, but this isn't the right way to do
it. This patch
This patch removes the apply() manager callback in favor of putting the
relevant commits in the individual drivers. This will mitigate some of
the difference between the suspend/resume path and the dpms path
Signed-off-by: Sean Paul
---
Changes in v2:
- This was previously in another pat
This patch changes the manager ops callbacks from accepting the subdrv
device pointer to taking a pointer to the manager. This will allow us
to move closer to decoupling manager/display from subdrv, and subsequently
decoupling the crtc/plane from the encoder.
Signed-off-by: Sean Paul
---
Changes
This patch implements the initialize callback in the hdmi and mixer
manager. This allows us to get rid of drm_dev in the drm_hdmi level and
track it in the mixer and hdmi drivers. This is one of the things
holding back the complete removal of the drm_hdmi layer.
Signed-off-by: Sean Paul
---
Chan
This patch implements the intitialize manager op in fimd.
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/d
This patch adds an initialize function to the manager and display
operations. This allows them to keep track of drm_device in their
local context, as well as adds an initialization hook right after
the encoder is created.
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exynos/
This patch merges overlay_ops into manager_ops. In all cases,
overlay_ops is implemented in the same place as manager ops, it doesn't
serve a functional purpose, and doesn't make things more clear.
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/exynos/exynos_drm_drv.h |
From: St?phane Marchesin
Signed-off-by: St?phane Marchesin
Signed-off-by: Sean Paul
---
Changes in v2: None
drivers/video/exynos/exynos_dp_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c
b/drivers/video/exynos/exynos_dp_core.c
index 12bbede..0
This patchset refactors parts of the exynos driver to move it closer to a proper
drm driver (rather than just implementing a drm layer on top of the hardware
drivers). The hope is to get to a point where the dp/hdmi drivers can implement
drm_connector/drm_encoder directly, and fimd/mixer can direct
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #9 from Alex Deucher ---
Does adding the smc ucode for your chip to the filesytem (and initrd if you are
using one) fix the issue?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #8 from Alex Deucher ---
Please attach your dmesg output without the patch applied.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 16.10.2013 11:48, Thierry Reding wrote:
> On Tue, Oct 15, 2013 at 09:19:18AM -0600, Stephen Warren wrote:
>> Taking advantage of new functionality isn't the issue. The issue is
>> whether a driver that was written purely to the spec of Tegra20 can
>> successfully operate on the HW. If it can't,
On Wed, 16 Oct 2013, Chris Wilson wrote:
> On Wed, Oct 16, 2013 at 01:14:53PM +0300, Jani Nikula wrote:
>> > --- a/include/uapi/drm/drm_mode.h
>> > +++ b/include/uapi/drm/drm_mode.h
>> > @@ -223,6 +223,8 @@ struct drm_mode_get_connector {
>> >__u32 connection;
>> >__u32 mm_width, mm_height
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/30c52a79/attachment.html>
On Wed, Oct 16, 2013 at 11:22:44AM +0100, Chris Wilson wrote:
> Apply the protections from
>
> commit 1b2f1489633888d4a06028315dc19d65768a1c05
> Author: Dave Airlie
> Date: Sat Aug 14 20:20:34 2010 +1000
>
> drm: block userspace under allocating buffer and having drivers overwrite
> it (v
Strange. I tested X with ~120 glxgears instances which got killed and
restarted every 60-120 seconds for the whole night, but without any
lockup or freeze.
What's the kernel backtrace when this happens? If I understand you
correctly X is killable in that situation, is that right?
Please try th
On Wed, 16 Oct 2013, Chris Wilson wrote:
> Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
> the 4 bytes beyond the end of its structure with a 32-bit userspace
> running on a 64-bit kernel. This is due to the padding gcc inserts as
> the drm_mode_get_connector struct inclu
On Wed, Oct 16, 2013 at 09:49:02AM +0100, Chris Wilson wrote:
> Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
> the 4 bytes beyond the end of its structure with a 32-bit userspace
> running on a 64-bit kernel. This is due to the padding gcc inserts as
> the drm_mode_get_co
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/29bf5e5e/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/30264687/attachment.html>
system becomes unresponsive after few minutes.
--
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/20131016/f35b5a06/attachment-0001.html>
On Wed, Oct 16, 2013 at 01:14:53PM +0300, Jani Nikula wrote:
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -223,6 +223,8 @@ struct drm_mode_get_connector {
> > __u32 connection;
> > __u32 mm_width, mm_height; /**< HxW in millimeters */
> > __u32 subp
Apply the protections from
commit 1b2f1489633888d4a06028315dc19d65768a1c05
Author: Dave Airlie
Date: Sat Aug 14 20:20:34 2010 +1000
drm: block userspace under allocating buffer and having drivers overwrite
it (v2)
to the core ioctl structs as well, for we found one instance where there
i
2013/10/16 Sean Paul :
> On Tue, Oct 15, 2013 at 12:09 AM, Inki Dae wrote:
>> 2013/10/15 Inki Dae :
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index c417c90..ba63c72 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_enco
On 10/16/2013 02:48 AM, Thierry Reding wrote:
> On Tue, Oct 15, 2013 at 09:19:18AM -0600, Stephen Warren wrote:
>> On 10/15/2013 02:37 AM, Thierry Reding wrote:
>>> On Mon, Oct 14, 2013 at 12:14:47PM -0600, Stephen Warren
>>> wrote:
On 10/14/2013 08:00 AM, Thierry Reding wrote:
> On Mon, O
On 10/16/2013 02:40 AM, Thierry Reding wrote:
...
> Just to follow up with what we've discussed on IRC: I'll take a
> stab at refactoring the debugfs file output into something more
> generic that can possibly be leveraged by regmap as well. That
> should provide a somewhat more lightweight alterna
issue. The issue is
> whether a driver that was written purely to the spec of Tegra20 can
> successfully operate on the HW. If it can't, then the HW is not
> compatible with Tegra20. Terje's previous comments sounded like the HW
> is not backwards-compatible, although his
discussed on IRC: I'll take a stab at
refactoring the debugfs file output into something more generic that can
possibly be leveraged by regmap as well. That should provide a somewhat
more lightweight alternative to regmap for implementations that don't
need regmap for anything else while at the same time providing something
so not every driver has to come up with something custom.
Does that sum it up correctly?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/1b6f5a1e/attachment.pgp>
Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
the 4 bytes beyond the end of its structure with a 32-bit userspace
running on a 64-bit kernel. This is due to the padding gcc inserts as
the drm_mode_get_connector struct includes a u64 and its size is not a
natural multiple o
Am 16.10.2013 00:05, schrieb Grigori Goronzy:
> On 15.10.2013 20:12, Christian K?nig wrote:
>> From: Christian K?nig
>>
>> This only seem to work for H.264 but not for VC-1 streams.
>>
>> Need to investigate further why exactly.
>>
>
> Thanks for the quick investigation. This is really strange. Th
On Wed, Oct 16, 2013 at 03:58:50PM +0100, Thomas Wood wrote:
> Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
> Specific Data Block to expose more stereo 3D modes.
>
> v2: Use (1 << 0) for consistency. (Ville Syrjälä)
> Skip adding any modes if 3D_MASK is indicated as being p
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #7 from Mikko Rapeli ---
Created attachment 111241
--> https://bugzilla.kernel.org/attachment.cgi?id=111241&action=edit
dmesg with 3.11.5+patch
(In reply to Alex Deucher from comment #6)
> Do you have dpm enabled (radeon.dpm=1 on th
https://bugzilla.kernel.org/show_bug.cgi?id=63101
--- Comment #5 from Kertesz Laszlo ---
Created attachment 111231
--> https://bugzilla.kernel.org/attachment.cgi?id=111231&action=edit
x crashlog
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=63101
--- Comment #4 from Kertesz Laszlo ---
X crashed right after i posted the previous comment. Attached xorg log with the
crash.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=63101
--- Comment #3 from Kertesz Laszlo ---
Created attachment 111221
--> https://bugzilla.kernel.org/attachment.cgi?id=111221&action=edit
dmesg of 95167aad6761ec8a0fc76506ed00439483208ee1
--
You are receiving this mail because:
You are watching th
https://bugzilla.kernel.org/show_bug.cgi?id=63101
--- Comment #2 from Kertesz Laszlo ---
Going back to commit 95167aad6761ec8a0fc76506ed00439483208ee1
- GPU lockup only, somewhat recoverable error, gpu locked in highest power
state.
lots of errors like
[ 523.602078] radeon :00:01.0: 88
On Friday, October 11, 2013 09:27:42 PM Aaron Lu wrote:
> v5:
> 1 Introduce video.use_native_backlight module parameter and set its
> value to false by default as suggested by Rafael. For Win8 systems
> which have broken ACPI video backlight control, the parameter can be
> set to 1 in kernel
On Tue, Oct 15, 2013 at 05:45:52PM -0400, Pavel Roskin wrote:
> On Tue, 15 Oct 2013 21:59:08 +0100
> Chris Wilson wrote:
>
> > Yikes, that implies we have a size mismatch with the kernel - ideally
> > we construct the struct to have the same size when compiled with 32
> > or 64 bits.
> >
> > Ple
On Tue, Oct 15, 2013 at 09:06:51PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> drm_fb_get_bpp_depth() likes to complain about unsupported pixel formats
> but doesn't bother telling us what the format was. Also format_check()
> just returns an error when it encouters
On 15.10.2013 20:12, Christian K?nig wrote:
> From: Christian K?nig
>
> This only seem to work for H.264 but not for VC-1 streams.
>
> Need to investigate further why exactly.
>
Thanks for the quick investigation. This is really strange. The
corruption looks very similar to what I saw with VC-1
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/3fb856aa/attachment-0001.html>
ts.freedesktop.org/archives/dri-devel/attachments/20131016/74bd36ec/attachment.html>
88 matches
Mail list logo
