An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131015/0d9ed1cd/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131015/2116cb4d/attachment.html>
output.
try:
force_glsl_extensions_warn=true disable_blend_func_extended=true
unigine-sanctuary
--
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/20
https://bugzilla.kernel.org/show_bug.cgi?id=63101
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
cro expanded and every macro thereafter undef'd). See the comments
in the test.
--
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/
nc. [AMD/ATI] RV670
GL [FireGL V7700] (prog-if 00 [VGA controller])
--
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/20131015/d3a9efea/attachment.html>
On Tue, Oct 15, 2013 at 02:00:50PM -0400, Pavel Roskin wrote:
> Hi Chris,
>
> It's almost certainly stack corruption. This "patch" fixes X for me.
> The first DRM_IOCTL_MODE_GETCONNECTOR in sna_output_init() must be
> overwriting the implied memory bounds.
>
> diff --git a/src/sna/sna_display.c
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131015/b6690a2e/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131015/6dba3ec1/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131015/f7df622e/attachment-0001.html>
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 an invalid format, leaving the
user scratching his head trying to figure out why addfb failed
On Tue, Oct 15, 2013 at 06:25:27PM +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.
>
Daniel likes to have the v2,v3,etc. changes listed here in the commit
msg.
> Signed-off-by: Thomas Wood
> ---
>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131015/2790a478/attachment.html>
dri-devel/attachments/20131015/8cfd190c/attachment.html>
same llvm assert (comment #2)
--
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/20131015/c0ebb36e/attachment.html>
From: Christian K?nig
This only seem to work for H.264 but not for VC-1 streams.
Need to investigate further why exactly.
This reverts commit 4b40e5921230beb1951f04d2b1b92c4c88fbad43.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c | 3 +--
drivers/gpu/drm/radeon/radeo
On Wed, 16 Oct 2013 00:39:34 +0100
Chris Wilson wrote:
> > However, I feel uneasy about that patch. I tried to debug the
> > problem, and it looked not as a data corruption, but as something
> > opposite. The kernel writes correct data to the userspace, but the
> > userspace gets the old value.
https://bugzilla.kernel.org/show_bug.cgi?id=63101
Bug ID: 63101
Summary: Hard lockup whel launching games like TF2 on kernels
3.11.5 and 3.12 rc4 and above
Product: Drivers
Version: 2.5
Kernel Version: 3.11.5
Hardware:
https://bugzilla.kernel.org/show_bug.cgi?id=60827
--- Comment #9 from archiesix at gmail.com ---
The bug was introduced in kernel 3.9.11. With kernels 3.9.9 and 3.9.10 when
hibernating I get the error :
No irq handler for vector (irq -1)
displayed on the console, but otherwise everything seems o
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.
Signed-off-by: Thomas Wood
---
drivers/gpu/drm/drm_edid.c | 105 +
1 file changed, 96 insertions(+), 9 deletions(-)
diff --git a/drive
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #6 from Alex Deucher ---
Do you have dpm enabled (radeon.dpm=1 on the kernel command line in grub,
etc.)? dpm is disabled by default so unless you have enabled it, none of that
new code added in that patch gets executed. You might be
On Tue, Oct 15, 2013 at 2:06 PM, 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 an invalid format, leaving the
> user scra
2056 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131015/6f7d6a3b/attachment.bin>
Hi,
At FOSDEM on the 1st and 2nd of February 2014, there will be a graphics
DevRoom. URL https://fosdem.org/2014/
The focus of this DevRoom is the same as the X.org DevRooms of yore;
anything to do with graphics on open source software goes.
This includes:
* Graphics drivers: from display to m
On Tue, Oct 15, 2013 at 2:12 PM, 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.
>
> This reverts commit 4b40e5921230beb1951f04d2b1b92c4c88fbad43.
>
Applied.
Thanks.
Alex
> Signed-off-by
On Fri, 11 Oct 2013, Jani Nikula wrote:
> On Thu, 10 Oct 2013, Fred New wrote:
>> I have found that I need to use i915.invert_brightness=1 for my HP
>> Envy 17 with a Haswell processor (i7-4702MQ). The lspci command shows
>> the following information about this device:
>
> I am surprised... until
On Tue, Oct 15, 2013 at 11:12:24AM -0400, Pavel Roskin wrote:
> On Sun, 13 Oct 2013 15:00:04 +0100
> Chris Wilson wrote:
>
> > On Sun, Oct 13, 2013 at 12:40:10AM -0400, Pavel Roskin wrote:
> > > I won't see that system until Tuesday. I'll give you the
> > > information you ask, I'm just trying t
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #5 from Mikko Rapeli ---
This partial revert aka hack seems to fix the issue though I have no idea what
it does :)
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -686,7 +686,6 @@ int ni_init_microcode(struct ra
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #4 from Mikko Rapeli ---
Git bisect is complete and I verified it a few extra times:
6596afd48af4d07c8b454849b2fe7e628974f3ef is the first bad commit
commit 6596afd48af4d07c8b454849b2fe7e628974f3ef
Author: Alex Deucher
Date: Wed Ju
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131015/2136b248/attachment.html>
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_encoder.c
>>> +++ b/drivers/gpu/dr
Hi Chris,
It's almost certainly stack corruption. This "patch" fixes X for me.
The first DRM_IOCTL_MODE_GETCONNECTOR in sna_output_init() must be
overwriting the implied memory bounds.
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 28151ab..dac834f 100644
--- a/src/sna/sna_disp
On 11 October 2013 12:12, Ville Syrjälä wrote:
> On Thu, Oct 10, 2013 at 02:19:15PM +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.
>>
>> Signed-off-by: Thomas Wood
>> ---
>> drivers/gpu/drm/drm_
art --
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 13854 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131015/30b5ace7/attachment.bin>
On 10/15/2013 02:33 AM, Thierry Reding wrote:
> On Mon, Oct 14, 2013 at 12:16:48PM -0600, Stephen Warren wrote:
>> On 10/14/2013 07:55 AM, Thierry Reding wrote:
>>> On Fri, Oct 11, 2013 at 04:43:35PM -0600, Stephen Warren
>>> wrote:
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> This comm
: application/octet-stream
Size: 70050 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131015/3da71fc0/attachment-0001.obj>
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 13742
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, Oct 14, 2013 at 08:58:34AM +0300, Terje Bergstr?m
>>> wrote:
On 12.10.2013 01:43, Stephen Warren wrote:
> On 10/07/20
On 10/14/2013 1:02 PM, David Herrmann wrote:
> Hi
>
> On Mon, Oct 14, 2013 at 6:19 PM, Gary Mort wrote:
>> Is there a repository for the SimpleFB drivers[the DRI driver and the plain
>> framebuffer driver]?
> Which drivers are you exactly talking about? Do you have links to the
> patches? There're
On 10/15/2013 02:13 AM, Thierry Reding wrote:
> On Mon, Oct 14, 2013 at 12:10:21PM -0600, Stephen Warren wrote:
>> On 10/12/2013 05:41 AM, Thierry Reding wrote:
>>> On Fri, Oct 11, 2013 at 04:19:19PM -0600, Stephen Warren
>>> wrote:
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> From: Mik
On 10/14/2013 11:51 PM, Terje Bergstr?m wrote:
> On 14.10.2013 21:14, Stephen Warren wrote:
>> On 10/14/2013 08:00 AM, Thierry Reding wrote:
>>> Yes, as long as the device tree files includes the most specific
>>> value in the compatible this should still be possible. So we'd have
>>> this:
>>>
>>>
They are not lockups. X just freezes in GEM_WAIT. The only way to
reproduce it is to apply the patches, use the computer and wait. It
looks like a fence is not signalled and the process calling GEM_WAIT
is not woken up.
Marek
On Tue, Oct 15, 2013 at 11:11 AM, Christian König
wrote:
> Mhm hard to
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #15 from Christian König ---
> Note: Everything works correctly with 3.11.5. 'radeon.audio=1' works with
> and without DPM.
Then please bisect what patch introduced this problem since it doesn't seems to
be releated to the xrandr pro
Mhm hard to say what's going wrong this time, but we probably need to
fix it before the final release.
Do you have a kernel backtrace from the lockups? Or at least some way to
reproduce it?
Christian.
Am 14.10.2013 21:34, schrieb Marek Olšák:
Ooops, the new problem is not so rare. It has no
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, Oct 14, 2013 at 08:58:34AM +0300, Terje Bergström wrote:
> >> On 12.10.2013 01:43, Stephen Warren wrote:
> >>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> The gr2d ha
On Mon, Oct 14, 2013 at 12:16:48PM -0600, Stephen Warren wrote:
> On 10/14/2013 07:55 AM, Thierry Reding wrote:
> > On Fri, Oct 11, 2013 at 04:43:35PM -0600, Stephen Warren wrote:
> >> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> >>> This commit adds support for both DSI outputs found on Tegra.
On Mon, Oct 14, 2013 at 12:10:21PM -0600, Stephen Warren wrote:
> On 10/12/2013 05:41 AM, Thierry Reding wrote:
> > On Fri, Oct 11, 2013 at 04:19:19PM -0600, Stephen Warren wrote:
> >> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> >>> From: Mikko Perttunen
> >>>
> >>> Tegra114 TMDS configuratio
On Mon, Oct 14, 2013 at 12:05:18PM -0600, Stephen Warren wrote:
> On 10/12/2013 05:32 AM, Thierry Reding wrote:
> > On Fri, Oct 11, 2013 at 04:14:27PM -0600, Stephen Warren wrote:
> >> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> >>> From: Mikko Perttunen
> >>>
> >>> The Tegra114 display contr
On Mon, Oct 14, 2013 at 08:30:28AM +0300, Terje Bergström wrote:
> On 12.10.2013 14:24, Thierry Reding wrote:
> > Yeah, I don't like very much how this is currently done. I mean about
> > half of this is actually duplicate code because of the static inline
> > functions used for register defines. A
On Mon, Oct 14, 2013 at 12:07:33PM -0600, Stephen Warren wrote:
> On 10/12/2013 05:24 AM, Thierry Reding wrote:
> > On Fri, Oct 11, 2013 at 04:13:07PM -0600, Stephen Warren wrote:
> >> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> >>> Tegra114 uses a slightly updated version of host1x with an
> >
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross
Cc: Andy Gross
Cc: DRI Development
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers
50 matches
Mail list logo
