[Bug 58033] [r300g] Black gap artifacts when playing WoW

. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/ea04208c/attachment.html>

[Bug 58033] [r300g] Black gap artifacts when playing WoW

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/dfe3588e/attachment.html>

mesa-8.0.x: Cherry-pick "dri/nouveau: don't use nested functions"

Hi I am playing again with llvm/clang v3.2 and patches I adapted from LLVMLinux project. I wanted to test my new toolchain before doing a rough testing of the mainline Linux-kernel. I decided to build the latest mesa-8.0.5 as I am on Ubuntu/precise AMD64 here by making me and my build-deps

[Bug 58033] [r300g] Black gap artifacts when playing WoW

in _mesa_es3_error_check_format_and_type -- 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/20130117/307edf70/attachment.html>

CDF discussions at FOSDEM

On Fri, Jan 11, 2013 at 09:27:03PM +0100, Laurent Pinchart wrote: > Would anyone be interested in meeting at the FOSDEM to discuss the Common > Display Framework ? There will be a CDF meeting at the ELC at the end of > February, the FOSDEM would be a good venue for European developers. We are

Radeon HDMI question

Hi, I experience a strange problem, I don't know whether it's a feature or a bug, and if it's a bug, where. I have a Radeon HD6570. A monitor via DVI and an LCD TV via HDMI are connected. Fedora 18/x86_64 is installed on the computer. (Previously it was F17, F16 and F14.) When playing videos

[pull] radeon drm-fixes-3.8

This might be responsible for the bad r300g MSAA performance results on Phoronix. I have no other explanation. There is an optimization in r300g which forces the VRAM domain for non-staging CB and DB only. Other than that, VRAM|GTT is the default for all textures and GTT is the default for all

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On 2013.01.17 at 13:28 -0500, Jerome Glisse wrote: > On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf > wrote: > > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: > >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf > >> wrote: > >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse

[Bug 58667] Random crashes on CAYMAN

top for more than 5 minutes again. -- 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/20130117/dd2d4bf8/attachment.html>

[Bug 52491] radeon massive screen corruption BARTS HD6870

https://bugzilla.kernel.org/show_bug.cgi?id=52491 --- Comment #15 from Bruno Jacquet 2013-01-17 19:26:36 --- (In reply to comment #14) > Better to try this patch instead first : > http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch With

[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot

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

[Bug 2377] Polygon stipple broken.

UMS. -- 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/20130117/5fae454c/attachment.html>

[PATCH libdrm] radeon: Fix 1D tiling layout on SI.

From: Michel D?nzer Very similar to Evergreen, but slightly different rules for tile / slice alignment. Fortunately, these map quite naturally onto the previous fixes for linear aligned layout on SI. 2D tiling still needs more work here and possibly in the kernel.

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On 2013.01.17 at 12:55 -0500, Jerome Glisse wrote: > On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf > wrote: > > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: > >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf > >> wrote: > >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse

[Bug 58667] Random crashes on CAYMAN

rday and I haven't seen any difference. -- 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/20130117/787696e4/attachment-0001.html>

[Bug 2377] Polygon stipple broken.

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

[Bug 58667] Random crashes on CAYMAN

ent was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/e3456115/attachment.html>

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: > On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf > wrote: > > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: > >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf > >> wrote: > >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:

[Bug 59521] [Serious Sam 3] Missing textures with R600g

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

[Bug 59521] [Serious Sam 3] Missing textures with R600g

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/d25e29cc/attachment.html>

[Bug 59521] New: [Serious Sam 3] Missing textures with R600g

An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/546d8237/attachment.html>

mesa-8.0.5: LLVM-3.2 patchset and request for cherry-picking

On 01/17/2013 04:23 PM, Sedat Dilek wrote: > Hi, > > with the following patchset (13 patches) I was able to build > mesa-8.0.5 with LLVM v3.2. > > There is one big fat patch called "gallivm,draw,llvmpipe: Support > wider native registers." [1] which makes backporting hard. > Jose? > > Regards, > -

mesa-8.0.x: Cherry-pick "dri/nouveau: don't use nested functions"

On 01/17/2013 02:14 PM, Sedat Dilek wrote: > Hi > > I am playing again with llvm/clang v3.2 and patches I adapted from > LLVMLinux project. > > I wanted to test my new toolchain before doing a rough testing of the > mainline Linux-kernel. > > I decided to build the latest mesa-8.0.5 as I am on

[PATCH v2 4/4] drm/i915: Provide the quantization range in the AVI infoframe

From: Ville Syrj?l? The AVI infoframe is able to inform the display whether the source is sending full or limited range RGB data. As per CEA-861 [1] we must first check whether the display reports the quantization range as selectable, and if so we can set the

[PATCH v2 3/4] drm/edid: Add drm_rgb_quant_range_selectable()

From: Ville Syrj?l? drm_rgb_quant_range_selectable() will report whether the monitor claims to support for RGB quantization range selection. The information can be found in the CEA Video capability block. v2: s/quantzation/quantization/ in the comment

[PATCH v3 2/4] drm/i915: Add "Automatic" mode for the "Broadcast RGB" property

From: Ville Syrj?l? Add a new "Automatic" mode to the "Broadcast RGB" range property. When selected the driver automagically selects between full range and limited range output. Based on CEA-861 [1] guidelines, limited range output is selected if the mode is a CEA

[PATCH v3 1/4] drm/i915: Fix RGB color range property for PCH platforms

From: Ville Syrj?l? The RGB color range select bit on the DP/SDVO/HDMI registers disappeared when PCH was introduced, and instead a new PIPECONF bit was added that performs the same function. Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set it

drm/i915: RGB quantization range stuff v3

Third attempt at handling the RGB quantization range for HDMI and DP. Changes since the last time: - Addressed all of Paulo's review comments. I think this is ready to go in, unless someone complains loudly.

[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot

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/20130117/77c82471/attachment.html>

[pull] drm-intel-fixes

Hi Dave More important fixes for 3.9: - error_state improvements to help debug the new scanline wait code added for gen6+ - bug reports started popping up :( patch from Chris Wilson. - fix a panel power sequence confusion between the eDP and lvds detection code resulting in black screens -

[PATCH 4/4] drm/i915: Provide the quantization range in the AVI infoframe

On Thu, Jan 17, 2013 at 10:16:46AM -0200, Paulo Zanoni wrote: > Hi > > 2013/1/16 : > > From: Ville Syrj?l? > > > > The AVI infoframe is able to inform the display whether the source is > > sending full or limited range RGB data. > > > > As per CEA-861 we must first check whether the display

[PATCH v2 5/5] drm/tegra: Implement page-flipping support

On 01/15/2013 12:06 AM, Thierry Reding wrote: > All the necessary support bits like .mode_set_base() and VBLANK are now > available, so page-flipping case easily be implemented on top. > > Signed-off-by: Thierry Reding [...] > + > +static int tegra_dc_page_flip(struct drm_crtc *crtc, struct

[PATCH v2 3/5] drm/tegra: Implement .mode_set_base()

On 01/15/2013 12:05 AM, Thierry Reding wrote: > The sequence for replacing the scanout buffer is much shorter than a > full mode change operation so implementing this callback considerably > speeds up cases where only a new framebuffer is to be scanned out. > > Signed-off-by: Thierry Reding >

[PATCH] drm/nouveau/mc: complain loudly if we can't call a interrupt handler

I noticed that bsp, vp and ppp had no interrupt handler after investigating why 15% of my cpu time went to interrupts. nouveau was silent about it, but it should be an error since we have no way of acking in that case. Signed-off-by: Maarten Lankhorst --- fwiw, the interrupt was 10, the

[PATCH] drm/radeon: fix a bogus kfree

parser->chunks[.].kpage[.] is not always kmalloc-ed by the parser initialization, so parser_fini should not try to kfree it if it didn't allocate it. This patch fixes a kernel oops that can be provoked in UMS mode. Upstream commit-id: a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e Tested on stable 3.7

[pull] radeon drm-fixes-3.8

One more fix on top. Just a revert of the bo placement patch that has been causing corruption for a number of people. Revert "drm/radeon: do not move bo to different placement at each cs" This reverts commit d025e9e2b890db679f1246037bf65bd4be512627. This causes corruption for a

CDF discussions at FOSDEM

On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula wrote: > On Fri, 11 Jan 2013, Laurent Pinchart > wrote: >> Would anyone be interested in meeting at the FOSDEM to discuss the Common >> Display Framework ? There will be a CDF meeting at the ELC at the end of >> February, the FOSDEM would be a good

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf wrote: > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf >> wrote: >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: >> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf

[PATCH] drm/edid: add quirk for Acer 19" display AL1917WA

From: Alex Deucher 1440x900 (native) monitor contains a bogus 1400x1050 at 75Hz mode in the standard timings and fails to flag the first detailed mode as preferred. As such, X picks 1400x1050 at 75Hz which fails to display. Fixes:

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf wrote: > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf >> wrote: >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: >> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf

[PATCH v2 5/5] drm/tegra: Implement page-flipping support

On 01/16/2013 07:53 PM, Lucas Stach wrote: > Am Mittwoch, den 16.01.2013, 19:10 +0800 schrieb Mark Zhang: >> I'm testing the pageflip & vblank change on cardhu. Seems the HDMI >> doesn't work(LVDS only is OK). I'll let you know if I get something. >> > Just to provide another data point: I'm

[PATCH 2/4] drm/i915: Add "Automatic" mode for the "Broadcast RGB" property

Hi 2013/1/16 : > From: Ville Syrj?l? > > Add a new "Automatic" mode to the "Broadcast RGB" range property. > When selected the driver automagically selects between full range and > limited range output. > > Based on CEA-861 guidelines, limited range output is selected if the > mode is a CEA

[Intel-gfx] [PATCH 1/4] drm/i915: Fix RGB color range property for PCH platforms

Hi 2013/1/16 : > From: Ville Syrj?l? > > The RGB color range select bit on the DP/SDVO/HDMI registers > disappeared when PCH was introduced, and instead a new PIPECONF bit > was added that performs the same function. > > Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set > it

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf wrote: > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf >> wrote: >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: >> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf >>

CDF discussions at FOSDEM

On Fri, 11 Jan 2013, Laurent Pinchart wrote: > Would anyone be interested in meeting at the FOSDEM to discuss the Common > Display Framework ? There will be a CDF meeting at the ELC at the end of > February, the FOSDEM would be a good venue for European developers. Yes, count me in, Jani.

[PATCH 4/4] drm/i915: Provide the quantization range in the AVI infoframe

Hi 2013/1/16 : > From: Ville Syrj?l? > > The AVI infoframe is able to inform the display whether the source is > sending full or limited range RGB data. > > As per CEA-861 we must first check whether the display reports the > quantization range as selectable, and if so we can set the approriate

[Intel-gfx] [PATCH 3/4] drm/edid: Add drm_rgb_quant_range_selectable()

Hi 2013/1/16 : > From: Ville Syrj?l? > > drm_rgb_quant_range_selectable() will report whether the monitor > claims to support for RGB quantization range selection. > > The information can be found in the CEA Video capability block. Looks correct (checked against the spec, did not really test).

[PATCH] drm/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()

On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote: > Actually, the code path affected by your patch is not executed in UMS mode > at all. Notice that radeon_cs_parser_fini is only called from > radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c). > > The equivalent of the fix you

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: > On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf > wrote: > > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: > >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf > >> wrote: > >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf

[PATCH v3 1/3] drm: add prime helpers

On Thu, Jan 17, 2013 at 12:36 AM, Aaron Plattner wrote: > Can I consider this a Reviewed-by? Essentially it was just a drive-by bikeshed ;-) I think it'd be good if Maarten takes a look at this and checks whether it complies with his massive prime/dma_buf rework to use fences and ticketing

[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/0a72a81e/attachment.html>

[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback

ttachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/4d08701d/attachment.html>

[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics

because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/4cf8dfd4/attachment.html>

[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback

ttachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/785e88ea/attachment-0001.html>

[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback

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/20130117/f4fc2342/attachment.html>

[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback

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

[drm-intel:drm-intel-nightly 150/152] include/uapi/drm/i915_drm.h:311:1: error: expected identifier or '(' before '<<' token

tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-nightly head: bef8f38486aaeef0818d0b79c797b0d6bbb1ce06 commit: 3f43d56a721d4f2ed29218bb365edc7a2b5a7a25 [150/152] Merge remote-tracking branch 'origin/drm-intel-fixes' into drm-intel-nightly config: x86_64-allyesdebian

[Bug 59492] piglit dlist-color-material test fail

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

[Bug 59492] New: piglit dlist-color-material test fail

eedesktop.org/archives/dri-devel/attachments/20130117/b6961e8a/attachment.html>

[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot

ing the patched module dmesg | grep TITITOTO should tell you if it's the case. -- 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

[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot

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/20130117/4317e866/attachment.html>

[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot

dri-devel/attachments/20130117/dc247a23/attachment.html>

[Bug 58667] Random crashes on CAYMAN

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/74c00f48/attachment.html>

[Bug 52491] radeon massive screen corruption BARTS HD6870

https://bugzilla.kernel.org/show_bug.cgi?id=52491 J?r?me Glisse changed: What|Removed |Added CC||glisse at freedesktop.org ---

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: > On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf > wrote: > > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: > >> On 2013.01.15 at 16:26 +0100, Michel D?nzer wrote: > >> > On Die, 2013-01-15 at 16:23 +0100, Markus Trippelsdorf

[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/37aa5577/attachment.html>

Re: [PATCH v3 1/3] drm: add prime helpers

On Thu, Jan 17, 2013 at 12:36 AM, Aaron Plattner aplatt...@nvidia.com wrote: Can I consider this a Reviewed-by? Essentially it was just a drive-by bikeshed ;-) I think it'd be good if Maarten takes a look at this and checks whether it complies with his massive prime/dma_buf rework to use fences

Re: CDF discussions at FOSDEM

On Fri, 11 Jan 2013, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Would anyone be interested in meeting at the FOSDEM to discuss the Common Display Framework ? There will be a CDF meeting at the ELC at the end of February, the FOSDEM would be a good venue for European developers.

Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.15 at

Re: [Intel-gfx] [PATCH 3/4] drm/edid: Add drm_rgb_quant_range_selectable()

Hi 2013/1/16 ville.syrj...@linux.intel.com: From: Ville Syrjälä ville.syrj...@linux.intel.com drm_rgb_quant_range_selectable() will report whether the monitor claims to support for RGB quantization range selection. The information can be found in the CEA Video capability block. Looks

Re: [PATCH 4/4] drm/i915: Provide the quantization range in the AVI infoframe

Hi 2013/1/16 ville.syrj...@linux.intel.com: From: Ville Syrjälä ville.syrj...@linux.intel.com The AVI infoframe is able to inform the display whether the source is sending full or limited range RGB data. As per CEA-861 we must first check whether the display reports the quantization range

Re: CDF discussions at FOSDEM

On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula jani.nik...@linux.intel.com wrote: On Fri, 11 Jan 2013, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Would anyone be interested in meeting at the FOSDEM to discuss the Common Display Framework ? There will be a CDF meeting at the ELC

Re: [PATCH 4/4] drm/i915: Provide the quantization range in the AVI infoframe

On Thu, Jan 17, 2013 at 10:16:46AM -0200, Paulo Zanoni wrote: Hi 2013/1/16 ville.syrj...@linux.intel.com: From: Ville Syrjälä ville.syrj...@linux.intel.com The AVI infoframe is able to inform the display whether the source is sending full or limited range RGB data. As per CEA-861

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Fix RGB color range property for PCH platforms

Hi 2013/1/16 ville.syrj...@linux.intel.com: From: Ville Syrjälä ville.syrj...@linux.intel.com The RGB color range select bit on the DP/SDVO/HDMI registers disappeared when PCH was introduced, and instead a new PIPECONF bit was added that performs the same function. Add a new

[PATCH] drm/nouveau/mc: complain loudly if we can't call a interrupt handler

I noticed that bsp, vp and ppp had no interrupt handler after investigating why 15% of my cpu time went to interrupts. nouveau was silent about it, but it should be an error since we have no way of acking in that case. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com ---

Re: [PATCH 2/4] drm/i915: Add Automatic mode for the Broadcast RGB property

Hi 2013/1/16 ville.syrj...@linux.intel.com: From: Ville Syrjälä ville.syrj...@linux.intel.com Add a new Automatic mode to the Broadcast RGB range property. When selected the driver automagically selects between full range and limited range output. Based on CEA-861 guidelines, limited

[pull] drm-intel-fixes

Hi Dave More important fixes for 3.9: - error_state improvements to help debug the new scanline wait code added for gen6+ - bug reports started popping up :( patch from Chris Wilson. - fix a panel power sequence confusion between the eDP and lvds detection code resulting in black screens -

drm/i915: RGB quantization range stuff v3

Third attempt at handling the RGB quantization range for HDMI and DP. Changes since the last time: - Addressed all of Paulo's review comments. I think this is ready to go in, unless someone complains loudly. ___ dri-devel mailing list

[PATCH v3 1/4] drm/i915: Fix RGB color range property for PCH platforms

From: Ville Syrjälä ville.syrj...@linux.intel.com The RGB color range select bit on the DP/SDVO/HDMI registers disappeared when PCH was introduced, and instead a new PIPECONF bit was added that performs the same function. Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set it in

[PATCH v3 2/4] drm/i915: Add Automatic mode for the Broadcast RGB property

From: Ville Syrjälä ville.syrj...@linux.intel.com Add a new Automatic mode to the Broadcast RGB range property. When selected the driver automagically selects between full range and limited range output. Based on CEA-861 [1] guidelines, limited range output is selected if the mode is a CEA mode,

[PATCH v2 3/4] drm/edid: Add drm_rgb_quant_range_selectable()

From: Ville Syrjälä ville.syrj...@linux.intel.com drm_rgb_quant_range_selectable() will report whether the monitor claims to support for RGB quantization range selection. The information can be found in the CEA Video capability block. v2: s/quantzation/quantization/ in the comment Reviewed-by:

[PATCH v2 4/4] drm/i915: Provide the quantization range in the AVI infoframe

From: Ville Syrjälä ville.syrj...@linux.intel.com The AVI infoframe is able to inform the display whether the source is sending full or limited range RGB data. As per CEA-861 [1] we must first check whether the display reports the quantization range as selectable, and if so we can set the

Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: On Tue, Jan 15, 2013 at

[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot

https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #19 from Jerome Glisse gli...@freedesktop.org --- Updated patch http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch Still weird that you point to same commit and first patch did not

Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.16 at

[Bug 59521] New: [Serious Sam 3] Missing textures with R600g

https://bugs.freedesktop.org/show_bug.cgi?id=59521 Priority: medium Bug ID: 59521 Assignee: dri-devel@lists.freedesktop.org Summary: [Serious Sam 3] Missing textures with R600g Severity: normal Classification: Unclassified

[Bug 59521] [Serious Sam 3] Missing textures with R600g

https://bugs.freedesktop.org/show_bug.cgi?id=59521 --- Comment #1 from Alex Deucher ag...@yahoo.com --- If the game uses compressed textures, make sure you have libtxc-dxtn installed. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 59521] [Serious Sam 3] Missing textures with R600g

https://bugs.freedesktop.org/show_bug.cgi?id=59521 --- Comment #2 from Laurent carlier lordhea...@gmail.com --- Of course, lib32-libtxc_dxtn is installed: $ pacman -Qs lib32-libtxc_dxtn local/lib32-libtxc_dxtn 1.0.1-3 Texture compression library for Mesa (32-bit) -- You are receiving this

[Bug 58667] Random crashes on CAYMAN

https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #38 from Thomas Rohloff v10la...@myway.de --- (In reply to comment #37) This patch might help: I applied it to a 3.8-rc3 kernel and while I didn't see the message spam till now the GPU crashes extremely often (so often that this

[Bug 2377] Polygon stipple broken.

https://bugs.freedesktop.org/show_bug.cgi?id=2377 --- Comment #7 from Roland Scheidegger srol...@vmware.com --- Looks to me like the offsets for the stipple pattern are wrong. These are set in r200UpdateViewportOffset - which has no callers. I noted this in bug 57842, and tried to address it

Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: On Wed, Jan 16, 2013

[PATCH] drm/edid: add quirk for Acer 19 display AL1917WA

From: Alex Deucher alexander.deuc...@amd.com 1440x900 (native) monitor contains a bogus 1400x1050@75Hz mode in the standard timings and fails to flag the first detailed mode as preferred. As such, X picks 1400x1050@75Hz which fails to display. Fixes:

Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On 2013.01.17 at 12:55 -0500, Jerome Glisse wrote: On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.16 at

[PATCH libdrm] radeon: Fix 1D tiling layout on SI.

From: Michel Dänzer michel.daen...@amd.com Very similar to Evergreen, but slightly different rules for tile / slice alignment. Fortunately, these map quite naturally onto the previous fixes for linear aligned layout on SI. 2D tiling still needs more work here and possibly in the kernel.

[Bug 2377] Polygon stipple broken.

https://bugs.freedesktop.org/show_bug.cgi?id=2377 --- Comment #8 from smoki smoki00...@gmail.com --- I was tested your patch from bug 57842 when you posted it there, but as i remember many random mesa demos i tried started to segfault with it. -- You are receiving this mail because: You are

Re: [PATCH] drm/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()

On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote: Actually, the code path affected by your patch is not executed in UMS mode at all. Notice that radeon_cs_parser_fini is only called from radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c). The equivalent of the fix you are

Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: On Wed, Jan 16, 2013

Re: [pull] radeon drm-fixes-3.8

One more fix on top. Just a revert of the bo placement patch that has been causing corruption for a number of people. Revert drm/radeon: do not move bo to different placement at each cs This reverts commit d025e9e2b890db679f1246037bf65bd4be512627. This causes corruption for a

[Bug 58667] Random crashes on CAYMAN

https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #39 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #38) (In reply to comment #37) This patch might help: I applied it to a 3.8-rc3 kernel and while I didn't see the message spam till now the GPU

Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On 2013.01.17 at 13:28 -0500, Jerome Glisse wrote: On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.16 at

  1   2   >