Hi
I try to compile 2.6.32-rc5-git3 with enabled CONFIG_DRM_I915_KMS, but got
black screen on boot. After short investigation, i notice that i915.modeset=0
is fine for me.
Here is what i got with modeset=1
[1.053570] [drm] Initialized drm 1.1.0 20060810
[1.063552] [drm] set up 7M of
http://bugs.freedesktop.org/show_bug.cgi?id=24734
Jesus Rodriguez faibis...@gmail.com changed:
What|Removed |Added
CC||faibis...@gmail.com
http://bugs.freedesktop.org/show_bug.cgi?id=24734
--- Comment #3 from Chris Wilson ch...@chris-wilson.co.uk 2009-10-27
02:36:18 PST ---
Indeed, looks like a compilation/distribution issue. If you are only using
packaged components, please raise the issue with your packagers.
--
Configure
http://bugs.freedesktop.org/show_bug.cgi?id=16692
--- Comment #5 from Fabio fabio@libero.it 2009-10-27 03:02:55 PST ---
This appears to be fixed since mesa 7.6 at least on my RV530. Can someone
confirm it?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
http://bugs.freedesktop.org/show_bug.cgi?id=16692
--- Comment #6 from Alexey Kuznetsov a...@axet.ru 2009-10-27 03:03:53 PST ---
ya. f12 x1600 done
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
http://bugs.freedesktop.org/show_bug.cgi?id=24734
Tormod Volden bugzi07.fdo.tor...@xoxy.net changed:
What|Removed |Added
CC|
http://bugs.freedesktop.org/show_bug.cgi?id=24734
--- Comment #6 from Roland Scheidegger srol...@tungstengraphics.com
2009-10-27 06:44:21 PST ---
Created an attachment (id=30741)
-- (http://bugs.freedesktop.org/attachment.cgi?id=30741)
possible fix
Looks like this function was also used
http://bugs.freedesktop.org/show_bug.cgi?id=24734
--- Comment #5 from Tormod Volden bugzi07.fdo.tor...@xoxy.net 2009-10-27
06:33:38 PST ---
$ grep -r intel_miptree_image_offset src/mesa/drivers/dri
src/mesa/drivers/dri/i915/i830_texstate.c:
intel_miptree_image_offset(intelObj-mt, 0,
http://bugs.freedesktop.org/show_bug.cgi?id=24761
Summary: Text corruption in Unreal Tournament 2004 under KMS
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
http://bugs.freedesktop.org/show_bug.cgi?id=24761
--- Comment #1 from had...@gmx.de 2009-10-27 08:59:56 PST ---
Created an attachment (id=30752)
-- (http://bugs.freedesktop.org/attachment.cgi?id=30752)
Xorg.0.log
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
http://bugs.freedesktop.org/show_bug.cgi?id=24761
--- Comment #2 from had...@gmx.de 2009-10-27 09:01:19 PST ---
Created an attachment (id=30753)
-- (http://bugs.freedesktop.org/attachment.cgi?id=30753)
A screenshot showing the corruption
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=24761
--- Comment #3 from had...@gmx.de 2009-10-27 09:05:12 PST ---
Created an attachment (id=30754)
-- (http://bugs.freedesktop.org/attachment.cgi?id=30754)
another screenshot
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=24761
had...@gmx.de changed:
What|Removed |Added
Attachment #30753|0 |1
is obsolete|
A couple of small modesetting fixes.
Alex
From 84248ff437864aab1d0d3aba971aa4d32c248526 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Tue, 27 Oct 2009 11:16:09 -0400
Subject: [PATCH] drm/radeon/kms/atom: loosen pll min output limits
Limiting the pll output range is a
http://bugs.freedesktop.org/show_bug.cgi?id=24734
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
From 89f132ea7ebe3b513835a1a975e4524caa26c691 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Mathias=20Fr=C3=B6hlich?= mathias.froehl...@gmx.net
Date: Tue, 27 Oct 2009 15:08:01 -0400
Subject: [PATCH] drm/radeon/kms/atom: Make card_info per device
Make the struct card_info, which is a per struct
On Thu, 8 Oct 2009, Dave Airlie wrote:
Please pull the 'drm-linus' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
Its had a recent merge because it was definitely getting non-trivial to
fixup,
non-radeon-kms: adds proper fb layer colormap
I don't think you tested this very extensively.
I'm bisecting a bug where my new Dell Inspiron 11z has corrupted LUT or
gamma tables or something. And while I have a lot of commits left to go,
only two of them still touch the i915 driver. And the two commits are:
Ive got a fix already,
For those of you having issues with the spread spectrum patch, this
patch should fix it up. If not, we should probably get rid the ss
patch until it's gotten some more testing.
Alex
From 4a5d68c399f950bd603e7af752ac7eb430ee1d19 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
I believe this is a typo.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9c92461..dc8e374 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -707,7 +707,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
http://bugs.freedesktop.org/show_bug.cgi?id=24643
--- Comment #4 from Paul Heldens pheld...@planet.nl 2009-10-27 14:33:56 PST
---
fwiw r600 git doesn't work either, it lacks GL_ARB_occlusion_query at detection
time
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
Hi!
This patch takes a little explaining. After the cleaned up of the fbdev
api a few years back I realized the fbdev api had many short comings. One
of them was the mapping of 1 to 1 for the framebuffer to display. So I
started to move that way gradually. What ended up was a new struct
http://bugzilla.kernel.org/show_bug.cgi?id=14331
--- Comment #9 from Alex Villacis Lasso avill...@ceibo.fiec.espol.edu.ec
2009-10-28 00:49:41 ---
Still present in 2.6.32-rc5.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail
So for drm KMS we wrote a bunch of ioctls that were 64-bit clean in theory.
They used uint64_t to represent userspace pointers and userspace
casted into those and the kernel casts back out and passes it to copy_*_user
Now I thought cool I don't need to worry about compat ioctl hackery I can
run
Hi Linus,
Please pull the 'drm-fixes' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes
This is just 3 fast track fixes, one for the colormap issues with 1.7 and
2.9.0 intel driver (note final 1.7 + 2.9.1 is fine, and 1.6 is fine with
any Intel). The
From: Dave Airlie airl...@gmail.com
Date: Wed, 28 Oct 2009 11:22:18 +1000
Is there really no way to avoid compat ioctls? was I delusional in
thinking there was?
If you use pointers in your interfaces in any way, no.
And for this drm_radeon_info thing the pointer is pointless,
you're just
On Wed, Oct 28, 2009 at 12:25 PM, David Miller da...@davemloft.net wrote:
From: Dave Airlie airl...@gmail.com
Date: Wed, 28 Oct 2009 11:22:18 +1000
Is there really no way to avoid compat ioctls? was I delusional in
thinking there was?
If you use pointers in your interfaces in any way, no.
On Wed, Oct 28, 2009 at 12:53 PM, Andi Kleen a...@firstfloor.org wrote:
Dave Airlie airl...@gmail.com writes:
They used uint64_t to represent userspace pointers and userspace
casted into those and the kernel casts back out and passes it to copy_*_user
uint64_t is actually dangerous due to
Dave Airlie airl...@gmail.com writes:
They used uint64_t to represent userspace pointers and userspace
casted into those and the kernel casts back out and passes it to copy_*_user
uint64_t is actually dangerous due to different alignment on x86-32 vs 64,
better use compat_u64/s64
Now I
On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
We've designed that into a/c also, we pad all 64-bit values to 64-bit
alignment on all the
ioctls we've added to the drm in the past couple of years. Just because of
this particular insanity.
That's actually not needed, just use
On Wed, Oct 28, 2009 at 1:19 PM, Andi Kleen a...@firstfloor.org wrote:
On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
We've designed that into a/c also, we pad all 64-bit values to 64-bit
alignment on all the
ioctls we've added to the drm in the past couple of years. Just because
On Wed, Oct 28, 2009 at 01:28:10PM +1000, Dave Airlie wrote:
You mean its impossible to design a 32/64-bit safe ioctl no matter what?
Not impossible, but there's always a rate of mistakes.
and we should live with having compat ioctls? This isn't something that was
very
clearly stated or
From: Andi Kleen a...@firstfloor.org
Date: Wed, 28 Oct 2009 03:53:17 +0100
Dave Airlie airl...@gmail.com writes:
Now I thought cool I don't need to worry about compat ioctl hackery I can
run 32 on 64 bit apps fine and it'll all just work.
Now Dave Miller points out that I'm obivously
From: Dave Airlie airl...@gmail.com
Date: Wed, 28 Oct 2009 13:05:08 +1000
DrNick on irc suggested just doing:
if (is_compat_task()) ptr = 0x;
Is there a one liner I can just do in the actual ioctls instead of
adding 20 compat
ones?
Just do the right thing and pass all
From: Dave Airlie airl...@gmail.com
Date: Wed, 28 Oct 2009 13:28:10 +1000
On Wed, Oct 28, 2009 at 1:19 PM, Andi Kleen a...@firstfloor.org wrote:
On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
We've designed that into a/c also, we pad all 64-bit values to 64-bit
alignment on all
From: Andi Kleen a...@firstfloor.org
Date: Wed, 28 Oct 2009 04:34:55 +0100
On Wed, Oct 28, 2009 at 01:28:10PM +1000, Dave Airlie wrote:
Well this was what I was trying to gather, so maybe I just need to write
something up to state that compat_ioctl is always required for new ioctls
that pass
DrNick on irc suggested just doing:
if (is_compat_task()) ptr = 0x;
Is there a one liner I can just do in the actual ioctls instead of
adding 20 compat
ones?
Just do the right thing and pass all userland compat pointers
through the correct compat_*() macros.
I
From: Dave Airlie airl...@linux.ie
Date: Wed, 28 Oct 2009 03:43:07 + (GMT)
we already opencoded this (probably before it was macroisied or we just
pasted it), so the radeon one is buggy, I should just go and compat_* all
of these then and we should be all happy?
It should be, it's only
On Tue, Oct 27, 2009 at 08:45:30PM -0700, David Miller wrote:
From: Dave Airlie airl...@linux.ie
Date: Wed, 28 Oct 2009 03:43:07 + (GMT)
we already opencoded this (probably before it was macroisied or we just
pasted it), so the radeon one is buggy, I should just go and compat_* all
we already opencoded this (probably before it was macroisied or we just
pasted it), so the radeon one is buggy, I should just go and compat_* all
of these then and we should be all happy?
It should be, it's only working because:
1) A malicious userland hasn't put garbage in the
On Tue, Oct 27, 2009 at 08:37:09PM -0700, David Miller wrote:
On sparc64, in order to make debugging easier, we trap any time
the kernel does a userspace access to a compat task and any
of the upper 32-bits are non-zero.
Interesting. That definitely means Dave needs a special path.
However
Looks like the issue was actually a potential oops. New patch attached.
Alex
On Tue, Oct 27, 2009 at 4:44 PM, Alex Deucher alexdeuc...@gmail.com wrote:
For those of you having issues with the spread spectrum patch, this
patch should fix it up. If not, we should probably get rid the ss
From: Dave Airlie airl...@linux.ie
Date: Wed, 28 Oct 2009 03:54:34 + (GMT)
we already opencoded this (probably before it was macroisied or we just
pasted it), so the radeon one is buggy, I should just go and compat_* all
of these then and we should be all happy?
It should be,
From: Andi Kleen a...@firstfloor.org
Date: Wed, 28 Oct 2009 05:36:11 +0100
On Tue, Oct 27, 2009 at 08:37:09PM -0700, David Miller wrote:
On sparc64, in order to make debugging easier, we trap any time
the kernel does a userspace access to a compat task and any
of the upper 32-bits are
Please don't do this.
This is exactly what I feared people would do when is_compat_task()
was added. is_compat_task() is for situations where there is
otherwise no other way to handle the compat situation properly.
It's not that much work for you to hook up the compat ioctls properly,
From d8a247c57fddc2dc01b41320988c25aa5dfcb0d7 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Wed, 28 Oct 2009 01:46:54 -0400
Subject: [PATCH] drm/radeon/kms: add quirk for hp dc5750
Doesn't have a tv-out port
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
46 matches
Mail list logo
