[PATCH] drm/radeon/kms: Fix I2C mask definitions

Commit 9b9fe724 accidentally used RADEON_GPIO_EN_* where RADEON_GPIO_MASK_* was intended. This caused improper initialization of I2C buses, mostly visible when setting i2c_algo_bit.bit_test=1. Using the right constants fixes the problem. Signed-off-by: Jean Delvare jdelv...@suse.de Cc: Alex

RE: [PATCH] drm/radeon/kms: Fix I2C mask definitions

-Original Message- From: Jean Delvare [mailto:jdelv...@suse.de] Sent: Thursday, October 06, 2011 12:16 PM To: David Airlie Cc: Deucher, Alexander; dri-devel@lists.freedesktop.org; Jerome Glisse Subject: [PATCH] drm/radeon/kms: Fix I2C mask definitions Commit 9b9fe724 accidentally

Re: [PULL] drm-intel-fixes (drm/i915 driver)

Keith Packard wrote: On Thu, 6 Oct 2011 10:12:57 -0700, Linus Torvaldstorva...@linux-foundation.org wrote: [drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH Thanks. I've got a patch series that fixes a pile of refclk bugs which is still out for review that should fix this.

Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On 10/07/2011 12:42 AM, Marek Olšák wrote: On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org wrote: In any case, I'm not saying fences is the best way to flush but since the bo code assumes that signaling a sync object means make the buffer contents available for CPU read

Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

Oh, and one more style comment below: On 08/07/2011 10:39 PM, Marek Olšák wrote: +enum ttm_buffer_usage { +TTM_USAGE_READ = 1, +TTM_USAGE_WRITE = 2, +TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE +}; Please don't use enums for bit operations. #define

[PATCH -next 0/2] more vmwgfx updates

Two fixes on top of previous patches. The first removes a DOS vulnerabilty. The second one implements some screen object fixes. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] vmwgfx: Implement memory accounting for resources

Contexts, surfaces and streams allocate persistent kernel memory as the direct result of user-space requests. Make sure this memory is accounted as graphics memory, to avoid DOS vulnerabilities. Also take the TTM read lock around resource creation to block switched-out dri clients from allocating

[PATCH 2/2] vmwgfx: Don't use virtual coords when using screen objects

From: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Thomas Hellstrom thellst...@vmware.com --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 272 +++ 1 files changed, 215 insertions(+), 57 deletions(-) diff --git

Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom tho...@shipmail.org wrote: On 10/07/2011 12:42 AM, Marek Olšák wrote: On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org  wrote: In any case, I'm not saying fences is the best way to flush but since the bo code assumes that

Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom tho...@shipmail.org wrote: On 10/07/2011 12:42 AM, Marek Olšák wrote: On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org  wrote: In any case, I'm not saying fences is the best way to flush but since the bo code assumes that

Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Fri, Oct 7, 2011 at 9:38 AM, Jerome Glisse j.gli...@gmail.com wrote: On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom tho...@shipmail.org wrote: On 10/07/2011 12:42 AM, Marek Olšák wrote: On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org  wrote: In any case, I'm not

Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On 10/07/2011 03:24 PM, Alex Deucher wrote: On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstromtho...@shipmail.org wrote: On 10/07/2011 12:42 AM, Marek Olšák wrote: On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org wrote: In any case, I'm not saying fences

Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On 10/07/2011 03:38 PM, Jerome Glisse wrote: On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstromtho...@shipmail.org wrote: On 10/07/2011 12:42 AM, Marek Olšák wrote: On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org wrote: In any case, I'm not saying

Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Fri, Oct 7, 2011 at 10:05 AM, Thomas Hellstrom tho...@shipmail.org wrote: On 10/07/2011 03:24 PM, Alex Deucher wrote: On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstromtho...@shipmail.org  wrote: On 10/07/2011 12:42 AM, Marek Olšák wrote: On Wed, Oct 5, 2011 at 7:54 AM, Thomas

[Bug 41561] New: Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 Summary: Hotplug detect does not work for HDMI monitor on Fusion E-350 board Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status:

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 Simon Farnsworth simon.farnswo...@onelan.co.uk changed: What|Removed |Added Summary|Hotplug detect does not |[r600

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #1 from Alex Deucher ag...@yahoo.com 2011-10-07 08:59:22 PDT --- If you are getting HPD interrupts, radeon_hotplug_work_func() should be getting scheduled. From there drm_helper_hpd_irq_event() gets called which actually generates

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #2 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-10-07 09:07:40 PDT --- drm_helper_hpd_irq_event() isn't generating uevents, because connector-status is not being updated somewhere, and is remaining at

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #6 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-10-07 10:53:04 PDT --- I've applied both patches, and am testing on a machine with DVI-I and DisplayPort. Test sequence: 1) Boot system with no outputs connected. 2)

[Bug 40252] No udev event for disconnecting VGA/HDMI cable

https://bugs.freedesktop.org/show_bug.cgi?id=40252 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 Alex Deucher ag...@yahoo.com changed: What|Removed |Added CC||q...@gmx.de --- Comment

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #8 from Alex Deucher ag...@yahoo.com 2011-10-07 11:16:14 PDT --- (In reply to comment #6) Results: DVI-D hotplug works fine. There is a delay on the first DVI-D hotplug after the connector has been used for VGA, but I get an

[PATCH 1/2] drm/radeon/kms: bail early in dvi_detect for digital only connectors

From: Alex Deucher alexander.deuc...@amd.com DVI-D and HDMI-A are digital only, so there's no need to attempt analog load detect. Also, skip bail before the !force check, or we fail to get a disconnect events. The next patches in the series attempt to fix disconnect events for connectors with

[PATCH 2/2] drm/radeon/kms: handle !force case in connector detect more gracefully

From: Alex Deucher alexander.deuc...@amd.com When force == false, we don't do load detection in the connector detect functions. Unforunately, we also return the previous connector state so we never get disconnect events for DVI-I, DVI-A, or VGA. Save whether we detected the monitor via load

[Bug 41569] New: [r600 KMS] Asus A35T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 Summary: [r600 KMS] Asus A35T A4-3400 Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 Robert Nelson robertcnel...@gmail.com changed: What|Removed |Added Summary|[r600 KMS] Asus A35T|[r600 KMS] Asus

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #1 from Robert Nelson robertcnel...@gmail.com 2011-10-07 11:25:48 PDT --- Created an attachment (id=52095) -- (https://bugs.freedesktop.org/attachment.cgi?id=52095) dmesg -- Configure bugmail:

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #2 from Robert Nelson robertcnel...@gmail.com 2011-10-07 11:26:04 PDT --- Created an attachment (id=52096) -- (https://bugs.freedesktop.org/attachment.cgi?id=52096) Xorg log -- Configure bugmail:

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #52095|application/octet-stream|text/plain mime

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #3 from Robert Nelson robertcnel...@gmail.com 2011-10-07 11:26:21 PDT --- Created an attachment (id=52097) -- (https://bugs.freedesktop.org/attachment.cgi?id=52097) lspci -- Configure bugmail:

[PATCH] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES = COMPONENTS}

Date: Fri, 16 Sep 2011 20:45:30 + The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to specify the size of an array, each element of which looks like this: struct radeon_debugfs { struct drm_info_list*files; unsignednum_files; };

Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glisse j.gli...@gmail.com wrote: I should have look at the patch long ago ... anyway i think a better approach would be to expose fence id as 64bits unsigned to each userspace client. I was thinking of mapping a page readonly (same page as the one gpu

[PATCH 0/2] RFC: Potential improvements in edid detection timings (v2)

(Resending with small improvements - also sending to dri-devel for feedback). This is the the forth iteration of potential fixes for slow edid detection issues over non-existent outputs (https://bugs.freedesktop.org/show_bug.cgi?id=41059) - the previous versions were posted to the bug and were

[PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

This allows to avoid talking to a non-existent bus repeatedly until we finally timeout. The non-existent bus is signalled by -ENXIO error, provided by i2c_algo_bit:bit_doAddress call. As the advantage of such change, all the other routines which use drm_get_edid would benefit for this timeout.

Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom tho...@shipmail.org wrote: OK. First I think we need to make a distinction: bo sync objects vs driver fences. The bo sync obj api is there to strictly provide functionality that the ttm bo subsystem is using, and that follows a simple set of

[PATCH 2/2] Check if the bus is valid prior to discovering edid.

This adds a new function intel_drm_get_valid_edid, which is used instead of drm_get_edid within the i915 driver. It does a similar check to the one in previous patch, but it is limited to i915 driver. The check is similar to the first part of EDID discovery performed by the

[Bug 41579] New: R300 Segfaults when using mupen64plus

https://bugs.freedesktop.org/show_bug.cgi?id=41579 Summary: R300 Segfaults when using mupen64plus Product: Mesa Version: 7.11 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority:

[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom wrote: > In any case, I'm not saying fences is the best way to flush but since the bo > code assumes that signaling a sync object means "make the buffer contents > available for CPU read / write", it's usually a good way to do it; there's > even a

[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On 10/07/2011 12:42 AM, Marek Ol??k wrote: > On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom > wrote: > >> In any case, I'm not saying fences is the best way to flush but since the bo >> code assumes that signaling a sync object means "make the buffer contents >> available for CPU read /

[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

Oh, and one more style comment below: On 08/07/2011 10:39 PM, Marek Ol??k wrote: > > +enum ttm_buffer_usage { > +TTM_USAGE_READ = 1, > +TTM_USAGE_WRITE = 2, > +TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE > +}; > > Please don't use enums for bit operations. #define

[PATCH -next 0/2] more vmwgfx updates

Two fixes on top of previous patches. The first removes a DOS vulnerabilty. The second one implements some screen object fixes.

[PATCH 1/2] vmwgfx: Implement memory accounting for resources

Contexts, surfaces and streams allocate persistent kernel memory as the direct result of user-space requests. Make sure this memory is accounted as graphics memory, to avoid DOS vulnerabilities. Also take the TTM read lock around resource creation to block switched-out dri clients from allocating

[PATCH 2/2] vmwgfx: Don't use virtual coords when using screen objects

From: Jakob Bornecrantz Signed-off-by: Jakob Bornecrantz Signed-off-by: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 272 +++ 1 files changed, 215 insertions(+), 57 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c

[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote: > On 10/07/2011 12:42 AM, Marek Ol??k wrote: >> >> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom >> ?wrote: >> >>> >>> In any case, I'm not saying fences is the best way to flush but since the >>> bo >>> code assumes that signaling a sync

[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote: > On 10/07/2011 12:42 AM, Marek Ol??k wrote: >> >> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom >> ?wrote: >> >>> >>> In any case, I'm not saying fences is the best way to flush but since the >>> bo >>> code assumes that signaling a sync

[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Fri, Oct 7, 2011 at 9:38 AM, Jerome Glisse wrote: > On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom > wrote: >> On 10/07/2011 12:42 AM, Marek Ol??k wrote: >>> >>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom >>> ?wrote: >>> In any case, I'm not saying fences is the best way to

[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On 10/07/2011 03:24 PM, Alex Deucher wrote: > On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom > wrote: > >> On 10/07/2011 12:42 AM, Marek Ol??k wrote: >> >>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom >>> wrote: >>> >>> In any case, I'm not saying fences is the

[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On 10/07/2011 03:38 PM, Jerome Glisse wrote: > On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom > wrote: > >> On 10/07/2011 12:42 AM, Marek Ol??k wrote: >> >>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom >>> wrote: >>> >>> In any case, I'm not saying fences is the

[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

On Fri, Oct 7, 2011 at 10:05 AM, Thomas Hellstrom wrote: > On 10/07/2011 03:24 PM, Alex Deucher wrote: >> >> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom >> ?wrote: >> >>> >>> On 10/07/2011 12:42 AM, Marek Ol??k wrote: >>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom

[Bug 41561] New: Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 Summary: Hotplug detect does not work for HDMI monitor on Fusion E-350 board Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status:

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 Simon Farnsworth changed: What|Removed |Added Summary|Hotplug detect does not |[r600 KMS] Hotplug detect

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #1 from Alex Deucher 2011-10-07 08:59:22 PDT --- If you are getting HPD interrupts, radeon_hotplug_work_func() should be getting scheduled. From there drm_helper_hpd_irq_event() gets called which actually generates the uevent. --

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #2 from Simon Farnsworth 2011-10-07 09:07:40 PDT --- drm_helper_hpd_irq_event() isn't generating uevents, because connector->status is not being updated somewhere, and is remaining at connector_status_connected, when it should be

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #3 from Simon Farnsworth 2011-10-07 09:26:08 PDT --- So, I think I see the proximate cause of the bug, but not the reason for it: In radeon_dvi_detect at radeon_connectors.c:962, I see: if (!force) { ret =

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #4 from Alex Deucher 2011-10-07 10:35:06 PDT --- Created an attachment (id=52093) View: https://bugs.freedesktop.org/attachment.cgi?id=52093 Review: https://bugs.freedesktop.org/review?bug=41561=52093 1/2: fix the digital only

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #5 from Alex Deucher 2011-10-07 10:35:43 PDT --- Created an attachment (id=52094) View: https://bugs.freedesktop.org/attachment.cgi?id=52094 Review: https://bugs.freedesktop.org/review?bug=41561=52094 2/2: fix the mixed and

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #6 from Simon Farnsworth 2011-10-07 10:53:04 PDT --- I've applied both patches, and am testing on a machine with DVI-I and DisplayPort. Test sequence: 1) Boot system with no outputs connected. 2) Attach a DVI-D monitor, then

[Bug 40252] No udev event for disconnecting VGA/HDMI cable

https://bugs.freedesktop.org/show_bug.cgi?id=40252 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 Alex Deucher changed: What|Removed |Added CC||qjn at gmx.de --- Comment #7 from Alex

[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board

https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #8 from Alex Deucher 2011-10-07 11:16:14 PDT --- (In reply to comment #6) > Results: > > DVI-D hotplug works fine. There is a delay on the first DVI-D hotplug after > the > connector has been used for VGA, but I get an event

[PATCH 1/2] drm/radeon/kms: bail early in dvi_detect for digital only connectors

From: Alex Deucher DVI-D and HDMI-A are digital only, so there's no need to attempt analog load detect. Also, skip bail before the !force check, or we fail to get a disconnect events. The next patches in the series attempt to fix disconnect events for connectors with

[PATCH 2/2] drm/radeon/kms: handle !force case in connector detect more gracefully

From: Alex Deucher When force == false, we don't do load detection in the connector detect functions. Unforunately, we also return the previous connector state so we never get disconnect events for DVI-I, DVI-A, or VGA. Save whether we detected the monitor via load

[Bug 41569] New: [r600 KMS] Asus A35T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 Summary: [r600 KMS] Asus A35T A4-3400 Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 Robert Nelson changed: What|Removed |Added Summary|[r600 KMS] Asus A35T|[r600 KMS] Asus A53T

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #1 from Robert Nelson 2011-10-07 11:25:48 PDT --- Created an attachment (id=52095) --> (https://bugs.freedesktop.org/attachment.cgi?id=52095) dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #2 from Robert Nelson 2011-10-07 11:26:04 PDT --- Created an attachment (id=52096) --> (https://bugs.freedesktop.org/attachment.cgi?id=52096) Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 Alex Deucher changed: What|Removed |Added Attachment #52095|application/octet-stream|text/plain mime type|

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #3 from Robert Nelson 2011-10-07 11:26:21 PDT --- Created an attachment (id=52097) --> (https://bugs.freedesktop.org/attachment.cgi?id=52097) lspci -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 Alex Deucher changed: What|Removed |Added Attachment #52096|text/x-log |text/plain mime type|

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 Alex Deucher changed: What|Removed |Added Attachment #52097|application/octet-stream|text/plain mime type|

[PATCH] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES => COMPONENTS}

Date: Fri, 16 Sep 2011 20:45:30 + The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to specify the size of an array, each element of which looks like this: struct radeon_debugfs { struct drm_info_list*files; unsignednum_files; };

[PATCH 0/2] RFC: Potential improvements in edid detection timings (v2)

(Resending with small improvements - also sending to dri-devel for feedback). This is the the forth iteration of potential fixes for slow edid detection issues over non-existent outputs (https://bugs.freedesktop.org/show_bug.cgi?id=41059) - the previous versions were posted to the bug and were

[PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

This allows to avoid talking to a non-existent bus repeatedly until we finally timeout. The non-existent bus is signalled by -ENXIO error, provided by i2c_algo_bit:bit_doAddress call. As the advantage of such change, all the other routines which use drm_get_edid would benefit for this timeout.

[PATCH 2/2] Check if the bus is valid prior to discovering edid.

This adds a new function intel_drm_get_valid_edid, which is used instead of drm_get_edid within the i915 driver. It does a similar check to the one in previous patch, but it is limited to i915 driver. The check is similar to the first part of EDID discovery performed by the

[Bug 41579] New: R300 Segfaults when using mupen64plus

https://bugs.freedesktop.org/show_bug.cgi?id=41579 Summary: R300 Segfaults when using mupen64plus Product: Mesa Version: 7.11 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: