In drivers/usb/Kconfig "config USB_ARCH_HAS_HCD" is within "if USB_SUPPORT"
statement.
In drivers/gpu/drm/Kconfig "config DRM_USB" depends on USB_ARCH_HAS_HCD
but selects USB_SUPPORT which leads to the error for udl Kconfig:
$ yes "" | make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
drive
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #14 from Alexandre Demers 2012-08-25
03:56:27 UTC ---
MLAA seems to be doing exactly as under Windows. I saw the same thing with
Catalyst on Windows 7 mostly in Messenger. See
http://www.sevenforums.com/software/182520-msn-live-messe
In drivers/usb/Kconfig "config USB_ARCH_HAS_HCD" is within "if USB_SUPPORT"
statement.
In drivers/gpu/drm/Kconfig "config DRM_USB" depends on USB_ARCH_HAS_HCD
but selects USB_SUPPORT which leads to the error for udl Kconfig:
$ yes "" | make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
drive
On Fri, Aug 24, 2012 at 02:56:50PM +0530, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from th
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #13 from Vadim Girlin 2012-08-24 19:24:25 UTC
---
(In reply to comment #12)
> (In reply to comment #11)
> I fully understand what the commit did. But I don't think MLAA should make the
> screen look like this, else nobody should enab
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #12 from Thomas Rohloff 2012-08-24 18:43:22
UTC ---
(In reply to comment #11)
I fully understand what the commit did. But I don't think MLAA should make the
screen look like this, else nobody should enable it, so it's useless. Don't
Changelog v2:
wait for VSYNC instead of BACKPORCH.
Changelog v1:
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem
when drm is released, drm framebuffers are released and all crtcs using
same framebuffer and also all gem buffers used but plane isn't disabled
so when crtc and encoder are turned on, overlay can access to invalid memory
because plane still has memory address released already.
this patch makes sure
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #11 from Vadim Girlin 2012-08-24 18:26:44 UTC
---
(In reply to comment #7)
> Created attachment 66074 [details]
> My .drirc
>
> The bad commit is e7c177ec9e37d0c406c3b0ef8f228159d7ee5d69 ( st/dri: use
> driver
> name for driconf se
https://bugs.freedesktop.org/show_bug.cgi?id=54002
Thomas Rohloff changed:
What|Removed |Added
Summary|Massive screen corruption |Massive screen corruption
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #10 from Thomas Rohloff 2012-08-24 17:39:49
UTC ---
with both, ""pp_jimenezmlaa_color" and "pp_jimenezmlaa" setted to 0 it seems to
be fixed completely. But I don't think activated MLAA should cause this.
--
Configure bugmail: http
Thanks for the comments, will upload patch set
with your comments.
On Fri, Aug 24, 2012 at 11:20 AM, Daniel Vetter wrote:
> On Fri, Aug 24, 2012 at 02:56:50PM +0530, Shirish S wrote:
> > The current logic for probing ddc is limited to
> > 2 blocks (256 bytes), this patch adds support
> > for the
r %s\n",
> > + adapter->name);
> > + break;
> > + }
> > + } while (ret != 3 && --retries);
> >
> > - return ret == 2 ? 0 : -1;
> > + return ret == 3 ? 0 : -1;
> > + }
> > + return -1;
> > }
> >
> > static bool drm_edid_is_zero(u8 *in_edid, int length)
> > --
> > 1.7.0.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Mail: daniel at ffwll.ch
> Mobile: +41 (0)79 365 57 48
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120824/a5ac9def/attachment-0001.html>
Dave Airlie (1):
radeon: add prime import/export support
Kenneth Graunke (1):
intel: Use VG_CLEAR on the context destroy ioctl as well.
Marek Ol??k (3):
radeon: fix allocation of MSAA surfaces on r600-r700
radeon: align r600 msaa buffers to a multiple of macrotile size
* n
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #9 from Thomas Rohloff 2012-08-24 17:04:04
UTC ---
Well, it's reduced to a minimum, not solved. Need some more testing.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #8 from Thomas Rohloff 2012-08-24 17:00:50
UTC ---
If I set "pp_jimenezmlaa_color" to "0" everything is fine.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: -
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #7 from Thomas Rohloff 2012-08-24 16:53:47
UTC ---
Created attachment 66074
--> https://bugs.freedesktop.org/attachment.cgi?id=66074
My .drirc
The bad commit is e7c177ec9e37d0c406c3b0ef8f228159d7ee5d69 ( st/dri: use driver
name fo
NB: still broken in 3.5 as well.
Signed-off-by: Ortwin Gl?ck
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -650,6 +650,12
https://bugzilla.kernel.org/show_bug.cgi?id=38472
--- Comment #8 from Alex Deucher 2012-08-24
16:42:47 ---
I think this is an issue with the drm fb helper. Since fb doesn't handle
multiple heads we only expose the smallest to the fb layer so the "extra" space
on the larger heads never gets
https://bugzilla.kernel.org/show_bug.cgi?id=38472
Alan changed:
What|Removed |Added
Kernel Version|3.0-rc5 |3.5.2
--
Configure bugmail: https://bugzilla.
https://bugzilla.kernel.org/show_bug.cgi?id=36892
--- Comment #9 from Alan 2012-08-24 16:36:07 ---
The page allocation warnings are fine (and just warnings that perhaps the VM
needs further tuning)
The only oddity is this
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
--
C
https://bugzilla.kernel.org/show_bug.cgi?id=36892
Alan changed:
What|Removed |Added
Attachment #78381|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=38472
--- Comment #7 from boris64 2012-08-24
16:29:21 ---
Yes, it's still there on kernel-3.5.2
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the a
https://bugzilla.kernel.org/show_bug.cgi?id=36672
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
From: Alex Deucher
The ordering is important and the current drm code
wasn't cutting it for modern DIG encoders. We need
to have information about crtc before setting up
the encoders so I've shifted the ordering a bit.
Probably we'll need a full rework akin to danvet's
recent intel patchs. This
From: Alex Deucher
Some plls are shared for DP.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/
https://bugzilla.kernel.org/show_bug.cgi?id=39612
Alan changed:
What|Removed |Added
Status|NEW |NEEDINFO
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=38472
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
https://bugzilla.kernel.org/show_bug.cgi?id=38792
Alan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=38622
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=38592
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vi
https://bugzilla.kernel.org/show_bug.cgi?id=38472
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Co
https://bugzilla.kernel.org/show_bug.cgi?id=38432
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vi
https://bugzilla.kernel.org/show_bug.cgi?id=38382
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=37762
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vi
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.
Changes from V2:
Add switch for DDC and E-DDC
Based on drm-next branch
Shirish S (1):
drm: edid: add support for E-DDC
drivers/gpu/drm/drm_edid.c | 87
On Fri, Aug 24, 2012 at 02:13:33PM +1000, Dave Airlie wrote:
> On Mon, Jul 23, 2012 at 7:26 PM, Daniel Vetter
> wrote:
> > Well, actually add some, because currently there's exactly none:
> > - in handle_to_fd we only take the file_priv's prime lock, but the
> > underlying gem object we're expo
https://bugzilla.kernel.org/show_bug.cgi?id=37502
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Fri, Aug 24, 2012 at 07:56:31AM -0400, Calvin Walton wrote:
> This board is incorrectly detected as having an LVDS connector,
> resulting in the VGA output (the only available output on the board)
> showing the console only in the top-left 1024x768 pixels, and an extra
> LVDS connector appearing
https://bugzilla.kernel.org/show_bug.cgi?id=37362
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=37032
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=36892
Niels Ole Salscheider changed:
What|Removed |Added
Attachment #61052|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=36892
Niels Ole Salscheider changed:
What|Removed |Added
Kernel Version|3.0-rc1 |3.6-rc1
--- Comment #7 from N
Checking of the second colorbuffer was skipped on r700, because
CB_TARGET_MASK was 0xf. With r600, CB_TARGET_MASK is changed to 0xff,
so we must set the number of samples of the second colorbuffer to 1 in order
to pass the CS checker.
The DRM version is bumped, because RESOLVE_BOX is always rejecte
On Mon, Jul 23, 2012 at 7:26 PM, Daniel Vetter
wrote:
> Well, actually add some, because currently there's exactly none:
> - in handle_to_fd we only take the file_priv's prime lock, but the
> underlying gem object we're exporting isn't per-file.
> - in each driver's dma_buf->release callback we
https://bugs.freedesktop.org/show_bug.cgi?id=46713
--- Comment #31 from Tvrtko Ursulin 2012-08-24
13:46:28 UTC ---
Just testing with 3.6.0-rc3+ from today's GIT and I can reproduce some sort of
sound corruption depending on the video output resolution.
For example, 1360x768 and audio plays fine
https://bugzilla.kernel.org/show_bug.cgi?id=36892
Alan changed:
What|Removed |Added
Status|NEW |NEEDINFO
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=36672
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vi
https://bugzilla.kernel.org/show_bug.cgi?id=36642
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #6 from Thomas Rohloff 2012-08-24 12:44:33
UTC ---
Okay, found a good commit and am bisecting. :)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You a
https://bugzilla.kernel.org/show_bug.cgi?id=36072
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
From: Alex Deucher
The ordering is important and the current drm code
wasn't cutting it for modern DIG encoders. We need
to have information about crtc before setting up
the encoders so I've shifted the ordering a bit.
Probably we'll need a full rework akin to danvet's
recent intel patchs. This
From: Alex Deucher
Some plls are shared for DP.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/rad
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #13 from Vadim Girlin 2012-08-24 19:24:25 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> I fully understand what the commit did. But I don't think MLAA should make the
> screen look like this, else nobody should enabl
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #5 from Thomas Rohloff 2012-08-24 12:12:28
UTC ---
Created attachment 66063
--> https://bugs.freedesktop.org/attachment.cgi?id=66063
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #4 from Thomas Rohloff 2012-08-24 12:11:38
UTC ---
Created attachment 66062
--> https://bugs.freedesktop.org/attachment.cgi?id=66062
Xorg.0.log
(In reply to comment #3)
> Can you isolate which update caused the problem?
I don't re
mmit,
> + .disable= exynos_drm_encoder_disable,
> };
>
> static void exynos_drm_encoder_destroy(struct drm_encoder *encoder)
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120824/050eff0d/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #3 from Michel D?nzer 2012-08-24 12:02:27
UTC ---
> I just updated mesa, libdrm snd the xf86-video-radeon to the newest git
> versions and now my screen is massivly corrupted (see the attached image).
Can you isolate which update ca
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #12 from Thomas Rohloff 2012-08-24 18:43:22 UTC
---
(In reply to comment #11)
I fully understand what the commit did. But I don't think MLAA should make the
screen look like this, else nobody should enable it, so it's useless. Don't
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #2 from Thomas Rohloff 2012-08-24 11:34:30
UTC ---
Created attachment 66060
--> https://bugs.freedesktop.org/attachment.cgi?id=66060
radeontop
I just noticed that the GPU usage is very high (radeontop), so high that the
desktop ge
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #11 from Vadim Girlin 2012-08-24 18:26:44 UTC ---
(In reply to comment #7)
> Created attachment 66074 [details]
> My .drirc
>
> The bad commit is e7c177ec9e37d0c406c3b0ef8f228159d7ee5d69 ( st/dri: use
> driver
> name for driconf sec
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #1 from Thomas Rohloff 2012-08-24 11:25:09
UTC ---
Created attachment 66059
--> https://bugs.freedesktop.org/attachment.cgi?id=66059
bugs.freedesktop.org with the corruption
--
Configure bugmail: https://bugs.freedesktop.org/user
https://bugs.freedesktop.org/show_bug.cgi?id=54002
Bug #: 54002
Summary: Massive screen corruption on Cayman
Classification: Unclassified
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
On Fri, Aug 24, 2012 at 02:56:50PM +0530, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from th
On Fri, 24 Aug 2012 09:42:44 +0300
Jani Nikula wrote:
> Another reference to raw_edid field of struct drm_display_info was
> added in gma500 while the whole field was being removed, causing build
> failure. Remove the hopefully last references to raw_edid.
>
> Reported-by: Fengguang Wu
> Signed
From: Inki Dae
this patch ensures that each plane connected to encoder is disabled
when released, by adding disable callback function of encoder helper
we had faced with one issue that invalid memory is accessed by dma
once drm is released and then the dma is turned on again. actually,
in our ca
From: Inki Dae
this patch ensures that each plane connected to encoder is disabled
when released, by adding disable callback function of encoder helper
we had faced with one issue that invalid memory is accessed by dma
once drm is released and then the dma is turned on again. actually,
in our ca
https://bugs.freedesktop.org/show_bug.cgi?id=54002
Thomas Rohloff changed:
What|Removed |Added
Summary|Massive screen corruption |Massive screen corruption
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #10 from Thomas Rohloff 2012-08-24 17:39:49 UTC
---
with both, ""pp_jimenezmlaa_color" and "pp_jimenezmlaa" setted to 0 it seems to
be fixed completely. But I don't think activated MLAA should cause this.
--
Configure bugmail: http
On Fri, Aug 24, 2012 at 8:27 AM, Marek Ol??k wrote:
> Checking of the second colorbuffer was skipped on r700, because
> CB_TARGET_MASK was 0xf. With r600, CB_TARGET_MASK is changed to 0xff,
> so we must set the number of samples of the second colorbuffer to 1 in order
> to pass the CS checker.
> T
art --
A non-text attachment was scrubbed...
Name: 0001-siliconmotion-kernel-driver-initial-patch.patch
Type: application/octet-stream
Size: 256220 bytes
Desc: 0001-siliconmotion-kernel-driver-initial-patch.patch
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120824/b9303d69/attachment-0001.obj>
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #9 from Thomas Rohloff 2012-08-24 17:04:04 UTC
---
Well, it's reduced to a minimum, not solved. Need some more testing.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #8 from Thomas Rohloff 2012-08-24 17:00:50 UTC
---
If I set "pp_jimenezmlaa_color" to "0" everything is fine.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: -
https://bugs.freedesktop.org/show_bug.cgi?id=54002
--- Comment #7 from Thomas Rohloff 2012-08-24 16:53:47 UTC
---
Created attachment 66074
--> https://bugs.freedesktop.org/attachment.cgi?id=66074
My .drirc
The bad commit is e7c177ec9e37d0c406c3b0ef8f228159d7ee5d69 ( st/dri: use driver
name fo
2012/8/24 Paul Menzel :
> Dear Inki,
>
>
> Am Freitag, den 24.08.2012, 18:27 +0900 schrieb Inki Dae:
>
> You can shorten the commit summary by leaving out the word issue, which
> is redundant. Maybe one of the following? I do not understand the
> process of releasing so it might be wrong.
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=38472
--- Comment #8 from Alex Deucher 2012-08-24 16:42:47
---
I think this is an issue with the drm fb helper. Since fb doesn't handle
multiple heads we only expose the smallest to the fb layer so the "extra" space
on the larger heads never gets
https://bugzilla.kernel.org/show_bug.cgi?id=38472
Alan changed:
What|Removed |Added
Kernel Version|3.0-rc5 |3.5.2
--
Configure bugmail: https://bugzilla.
https://bugzilla.kernel.org/show_bug.cgi?id=36892
--- Comment #9 from Alan 2012-08-24 16:36:07 ---
The page allocation warnings are fine (and just warnings that perhaps the VM
needs further tuning)
The only oddity is this
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
--
C
https://bugzilla.kernel.org/show_bug.cgi?id=36892
Alan changed:
What|Removed |Added
Attachment #78381|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=38472
--- Comment #7 from boris64 2012-08-24
16:29:21 ---
Yes, it's still there on kernel-3.5.2
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the a
Hi guys (but mainly ajax)
I have a bunch of EDID and quirk stuff outstanding,
I've made a bundle on patchwork for it
https://patchwork.kernel.org/bundle/airlied/edid-review/
Dave.
Another reference to raw_edid field of struct drm_display_info was added in
gma500 while the whole field was being removed, causing build
failure. Remove the hopefully last references to raw_edid.
Reported-by: Fengguang Wu
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/gma500/cdv_intel_dp.c |
On Thu, Aug 23, 2012 at 8:52 PM, Alan Cox wrote:
> On Thu, 23 Aug 2012 12:03:59 +0200
> Laurent Pinchart wrote:
>
>> Hi Alan,
>>
>> On Tuesday 17 July 2012 17:21:06 Alan Cox wrote:
>> > On Tue, 17 Jul 2012 17:09:25 +0200 Laurent Pinchart wrote:
>> > > On Wednesday 16 May 2012 16:10:37 Alan Cox wr
On Fri, Aug 24, 2012 at 7:51 AM, Andy Lutomirski wrote:
> mgag200 hangs like this on startup, on a Dell PowerEge 12g box. The
> serial console says:
You can apply this
https://patchwork.kernel.org/patch/1298651/
it should be in stable at some point, I expect its the same bug, it
not get back t
NB: still broken in 3.5 as well.
Signed-off-by: Ortwin Glück
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -650,6 +650,1
This board is incorrectly detected as having an LVDS connector,
resulting in the VGA output (the only available output on the board)
showing the console only in the top-left 1024x768 pixels, and an extra
LVDS connector appearing in X.
It's a desktop Mini-ITX board using an Atom D525 CPU with an NM
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.
Changes from V2:
Add switch for DDC and E-DDC
Based on drm-next branch
Shirish S (1):
drm: edid: add support for E-DDC
drivers/gpu/drm/drm_edid.c | 87
Another reference to raw_edid field of struct drm_display_info was added in
gma500 while the whole field was being removed, causing build
failure. Remove the hopefully last references to raw_edid.
Reported-by: Fengguang Wu
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/gma500/cdv_intel_dp.c |
https://bugzilla.kernel.org/show_bug.cgi?id=36672
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 f
https://bugs.freedesktop.org/show_bug.cgi?id=43698
--- Comment #13 from Joseph Spiros 2012-08-24
08:34:33 UTC ---
I'm running into this bug as well, with an iMac G5 containing a Radeon 9600
(rv350) chip. It's been a few months since this bug has seen any activity; is a
fix still forthcoming? Is
https://bugzilla.kernel.org/show_bug.cgi?id=39612
Alan changed:
What|Removed |Added
Status|NEW |NEEDINFO
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=38472
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #6 f
Dave Airlie (1):
radeon: add prime import/export support
Kenneth Graunke (1):
intel: Use VG_CLEAR on the context destroy ioctl as well.
Marek Olšák (3):
radeon: fix allocation of MSAA surfaces on r600-r700
radeon: align r600 msaa buffers to a multiple of macrotile size
* n
https://bugzilla.kernel.org/show_bug.cgi?id=38792
Alan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=38622
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=38592
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|Video
https://bugzilla.kernel.org/show_bug.cgi?id=38472
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|Conso
https://bugzilla.kernel.org/show_bug.cgi?id=38432
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|Video
1 - 100 of 137 matches
Mail list logo
