http://bugzilla.kernel.org/show_bug.cgi?id=13454
Gordon Jin changed:
What|Removed |Added
Status|NEW |NEEDINFO
CC|
On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote:
> 2009/9/16 Michel Dänzer :
> > From: Michel Dänzer
> >
> > diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> > index 2ba61e1..341c21a 100644
> > --- a/include/drm/radeon_drm.h
> > +++ b/include/drm/radeon_drm.h
> > @@ -802,11
http://bugzilla.kernel.org/show_bug.cgi?id=13490
Gordon Jin changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://bugzilla.kernel.org/show_bug.cgi?id=13714
Gordon Jin changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://bugzilla.kernel.org/show_bug.cgi?id=13740
Gordon Jin changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://bugzilla.kernel.org/show_bug.cgi?id=13776
Gordon Jin changed:
What|Removed |Added
Priority|P1 |P2
CC|
http://bugzilla.kernel.org/show_bug.cgi?id=13811
Gordon Jin changed:
What|Removed |Added
Priority|P1 |P2
CC|
http://bugzilla.kernel.org/show_bug.cgi?id=13844
Gordon Jin changed:
What|Removed |Added
Priority|P1 |P2
CC|
http://bugzilla.kernel.org/show_bug.cgi?id=14091
Gordon Jin changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://bugzilla.kernel.org/show_bug.cgi?id=14176
Gordon Jin changed:
What|Removed |Added
CC||[email protected],
|
http://bugs.freedesktop.org/show_bug.cgi?id=23670
--- Comment #12 from Shuang He 2009-09-15 20:37:59 PST
---
Created an attachment (id=29580)
--> (http://bugs.freedesktop.org/attachment.cgi?id=29580)
another small case
This case simply render two points through glDrawPixels(GL_DEPTH_COMPO
http://bugs.freedesktop.org/show_bug.cgi?id=23670
--- Comment #11 from Shuang He 2009-09-15 20:34:59 PST
---
(In reply to comment #10)
> (In reply to comment #9)
> > Created an attachment (id=29361)
--> (http://bugs.freedesktop.org/attachment.cgi?id=29361) [details] [details]
> > small cas
From: Dave Airlie
This should in theory fix the problem with a mode set being required
for adjusting the color depth.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 29 +++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/d
http://bugs.freedesktop.org/show_bug.cgi?id=23402
--- Comment #18 from David Ronis 2009-09-15 18:18:25
PST ---
I tried setting up KMS as described in the wiki. I'm not sure I was
successful, but if so, there's no change with the bug. Couple of things:
1. I didn't activate any of the dev
Now that the cache flushing of the memory based overlay regs works,
we can safely switch off the overlay. Beforehand it was only disabled
(like in userspace).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_overlay.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff
This just waits until the hw passed the current ring position with
cmd execution. This slightly changes the existing i915_wait_request
function to make uninterruptible waiting possible - no point in
returning to userspace while mucking around with the overlay, that
piece of hw is just too fragile.
As long as the gpu can keep up, neither the cpu (waiting for gpu)
nore the gpu (waiting for vblank to do an overlay flip) stalls.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |3 ++
drivers/gpu/drm/i915/i915_gem.c |4 +-
drivers/gpu/drm/i915/intel_drv.h
It's not needed anymore.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c | 18 --
2 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8
It is identical to I85X. Use that one instead.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_display.c |4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i
On Tue, Sep 15, 2009 at 08:57:28PM +0100, Dave Airlie wrote:
> > Novell did not have to upstream itself, so please stop suggesting that
> > this was Novell doing stuff behind closed doors.
>
> If Greg did this as part of staging I also objected to this on lkml at
> one time.
Huh? I added this c
I've wasted half a day hunting a bug that could easily be spotted by
gcc. Prevent this from reoccurring.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/d
At least for the common case of userspace ioctls. When doing a
modeset operation, the wait is still uninterruptible. But considering
that failing to turn off the overlay when switching off the crtc it's
running on hangs the chip, it doesn't complicate matters _very_
much. There's just an unkillable
This implements intel overlay support for kms via a device-specific
ioctl. Thomas Hellstrom brought up the idea of a general ioctl (on
dri-devel). We've reached the conclusion that such an infrastructure
only makes sense when multiple kms overlay implementations exists,
which atm don't (and it does
Hi all,
Latest version of my overlay kms work. I've added the new stuff as separated
patches for easier testing in case something blows up.
Please review.
Thanks, Daniel
Daniel Vetter (8):
[drm]: make drm_mode_object_find typesafe
[drm/i915]: add i915_lp_ring_sync helper
[drm/i915]: kill
http://bugs.freedesktop.org/show_bug.cgi?id=9468
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Wed, 16 Sep 2009 00:12:21 +0200
Michel Dänzer wrote:
> On Wed, 2009-09-16 at 08:02 +1000, Dave Airlie wrote:
> > 2009/9/16 Michel Dänzer :
> > > From: Michel Dänzer
> > >
> >
> > This one confuses me, the bit depth and stuff should
> > all be setup in the set base function, I wonder
> > is
2009/9/16 Michel Dänzer :
> On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote:
>> 2009/9/16 Michel Dänzer :
>> > From: Michel Dänzer
>> >
>> > Now that we can handle 16 bpp on big endian as well, we can save VRAM like
>> > this
>> > and probably also improve console output speed. The console o
On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote:
> 2009/9/16 Michel Dänzer :
> > From: Michel Dänzer
> >
>
> >
> > @@ -200,6 +201,7 @@ void radeon_object_kunmap(struct radeon_object *robj)
> >}
> >robj->kptr = NULL;
> >spin_unlock(&robj->tobj.lock);
> > + radeo
On Wed, 2009-09-16 at 08:03 +1000, Dave Airlie wrote:
> 2009/9/16 Michel Dänzer :
> > From: Michel Dänzer
> >
> > Now that we can handle 16 bpp on big endian as well, we can save VRAM like
> > this
> > and probably also improve console output speed. The console only uses a
> > limited
> > numbe
On Wed, 2009-09-16 at 08:02 +1000, Dave Airlie wrote:
> 2009/9/16 Michel Dänzer :
> > From: Michel Dänzer
> >
>
> This one confuses me, the bit depth and stuff should
> all be setup in the set base function, I wonder
> is there a bug somewhere that we aren't dealing with.
There's definitely a b
2009/9/16 Michel Dänzer :
> From: Michel Dänzer
>
>
> @@ -200,6 +201,7 @@ void radeon_object_kunmap(struct radeon_object *robj)
> }
> robj->kptr = NULL;
> spin_unlock(&robj->tobj.lock);
> + radeon_object_check_tiling(robj, 0, 0);
> ttm_bo_kunmap(&robj->kmap);
>
2009/9/16 Michel Dänzer :
> From: Michel Dänzer
>
> Now that we can handle 16 bpp on big endian as well, we can save VRAM like
> this
> and probably also improve console output speed. The console only uses a
> limited
> number of colours anyway. (8 bpp might be even better, but that doesn't seem
2009/9/16 Michel Dänzer :
> From: Michel Dänzer
>
This one confuses me, the bit depth and stuff should
all be setup in the set base function, I wonder
is there a bug somewhere that we aren't dealing with.
Dave.
> Signed-off-by: Michel Dänzer
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 2 +
http://bugs.freedesktop.org/show_bug.cgi?id=22271
--- Comment #14 from Krzysztof A. Sobiecki 2009-09-15
13:29:17 PST ---
It looks like commit 70ba2a374704e00df8868a7ac3d7350329d28924 in
drm-next(drm-2.6) fixed this bug. I will close it, after merging of this commit
into main tree.
--
Co
http://bugs.freedesktop.org/show_bug.cgi?id=23901
--- Comment #8 from Adam K Kirchhoff 2009-09-15 13:29:41
PST ---
After a brief discussion with airlied on #radeon, I checked the contents of
/sys/class/drm/card0-*/dpms and both monitors had "On".
--
Configure bugmail: http://bugs.freede
On Tue, 2009-09-15 at 12:38 -0600, Brian Paul wrote:
> Robert Noland wrote:
> > The following commit causes texture issues on r600 at least, I haven't
> > tried other hardware currently. Running engine demo starts out
> > correctly, but when cycling 'm' the issue appears.
> >
> > bcb62ae78a9d2f4d
> Are you saying "Yes, it is right to carry version information in the
> drm.h file"?
No I'm still in no way convinced of this, the fact Thomas doesn't see it
as a requirement either, and *no* other drm driver does it, is all
pointing towards its unnecessary. You seem to think its obvious but we
http://bugs.freedesktop.org/show_bug.cgi?id=23965
--- Comment #7 from Phil Armstrong 2009-09-15 11:48:26
PST ---
Created an attachment (id=29571)
--> (http://bugs.freedesktop.org/attachment.cgi?id=29571)
Bad rendering of coin edges in neverball 1.4
--
Configure bugmail: http://bugs.free
Robert Noland wrote:
> The following commit causes texture issues on r600 at least, I haven't
> tried other hardware currently. Running engine demo starts out
> correctly, but when cycling 'm' the issue appears.
>
> bcb62ae78a9d2f4d08001e9f207b6f1291443968 is first bad commit
> commit bcb62ae78a9
http://bugs.freedesktop.org/show_bug.cgi?id=23965
--- Comment #6 from Phil Armstrong 2009-09-15 11:29:26
PST ---
(In reply to comment #5)
> C'set possible.
or C'est even.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail becaus
http://bugs.freedesktop.org/show_bug.cgi?id=23965
--- Comment #5 from Phil Armstrong 2009-09-15 11:29:01
PST ---
C'set possible.
neverball version 1.5.2 here.
Just tried 1.4: The level exits are correctly rendered with that version, but
looking closely, the edges of the rotating coins are
The following commit causes texture issues on r600 at least, I haven't
tried other hardware currently. Running engine demo starts out
correctly, but when cycling 'm' the issue appears.
bcb62ae78a9d2f4d08001e9f207b6f1291443968 is first bad commit
commit bcb62ae78a9d2f4d08001e9f207b6f1291443968
Aut
http://bugs.freedesktop.org/show_bug.cgi?id=23965
--- Comment #4 from Alex Deucher 2009-09-15 11:02:23 PST ---
Seems to work fine here with neverball 1.4.0. I wonder if this is a bug in
your version of neverball.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
-
http://bugs.freedesktop.org/show_bug.cgi?id=23965
--- Comment #3 from Phil Armstrong 2009-09-15 10:41:41
PST ---
Created an attachment (id=29570)
--> (http://bugs.freedesktop.org/attachment.cgi?id=29570)
Correct software rendering
--
Configure bugmail: http://bugs.freedesktop.org/userpr
http://bugs.freedesktop.org/show_bug.cgi?id=23965
--- Comment #2 from Phil Armstrong 2009-09-15 10:37:15
PST ---
Sorry, that posted by accident.
Extra information: r600 DRI driver from drm-agd5f with kernel 2.6.30, git mesa
as of today.
$ lspci
...
01:00.0 VGA compatible controller: ATI T
http://bugs.freedesktop.org/show_bug.cgi?id=23965
Phil Armstrong changed:
What|Removed |Added
OS/Version|All |Linux (All)
Platform|Other
http://bugs.freedesktop.org/show_bug.cgi?id=23965
--- Comment #1 from Phil Armstrong 2009-09-15 10:36:17
PST ---
Created an attachment (id=29569)
--> (http://bugs.freedesktop.org/attachment.cgi?id=29569)
Exit appears over foreground objects
--
Configure bugmail: http://bugs.freedesktop.
http://bugs.freedesktop.org/show_bug.cgi?id=23965
Summary: radeonBackground objects appear in front of foreground
ones in neverball
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Hi,
It looks like the radeon kernel command checker blocks some of
gl(x)info's 32 bit commands. Here's dmesg output
ioctl32(glxinfo:5153): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4}
arg(ff9b517c) on /dev/dri/card0
ioctl32(glinfo:5184): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4} arg(ff86c5dc)
2009/9/15 Thierry Vignaud :
> Hi,
>
> It looks like the radeon kernel command checker blocks some of
> gl(x)info's 32 bit commands. Here's dmesg output
>
> ioctl32(glxinfo:5153): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4}
> arg(ff9b517c) on /dev/dri/card0
> ioctl32(glinfo:5184): Unknown cmd fd(4)
From: Michel Dänzer
Fixes leak hidden in commit 9f022ddfb23793b475ff7e57ac08a766dd5d31bd
('drm/radeon/kms: convert r4xx to new init path').
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_cs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/d
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_connectors.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 6435861..5ee81b6 100644
--
From: Michel Dänzer
It may indirectly call radeon_set_clock_gating() which relies on the VRAM info.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_device.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/driv
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/drm_crtc_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ff447f1..eaed0f5 100644
--- a/drivers/gpu/drm/drm_crtc_he
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/r100.c |5 ++
drivers/gpu/drm/radeon/radeon_fb.c | 121 +---
drivers/gpu/drm/radeon/radeon_object.c |2 +
include/drm/radeon_drm.h | 11 ++--
4 files cha
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0b8d184..12f5990 100644
--- a/drivers/gpu/drm/radeon/r
From: Michel Dänzer
Now that we can handle 16 bpp on big endian as well, we can save VRAM like this
and probably also improve console output speed. The console only uses a limited
number of colours anyway. (8 bpp might be even better, but that doesn't seem to
work properly yet)
This will require
From: Michel Dänzer
Fixes RMX problems on older Apple laptops which don't have an x86 BIOS ROM.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_combios.c| 12 ++---
drivers/gpu/drm/radeon/radeon_connectors.c | 34 +++-
2 files changed, 41 inse
On Fri, Sep 11, 2009 at 11:00:27PM +0100, Dave Airlie wrote:
>
> Okay incompatible interfaces are not acceptable unless they are major
> version number changes. Minor or patch version changes should not break
> the kernel interface in any way unless its a major security hole being
> solved, and
http://bugs.freedesktop.org/show_bug.cgi?id=23234
--- Comment #12 from Ioannis Koutras 2009-09-15
02:09:59 PST ---
I confirm that SWcursor is working, as well as the xrandr commands Kevin
DeKorte gave in #10: xrandr in two commands (off and auto with placement
setting) is working just fine,
On Tue, 2009-09-15 at 15:54 +0800, Rafał Miłecki wrote:
> OK, you provided me fair amount of texts to read :)
>
> W dniu 15 września 2009 09:43 użytkownik Zhang Rui
> napisał:
> > And I think it may work for you as well, i.e. two backlight sysfs I/F
> > may co-exist, it's the user space to decid
http://bugs.freedesktop.org/show_bug.cgi?id=23402
--- Comment #17 from Pauli 2009-09-15 01:58:10 PST ---
It doesn't reproduce with KMS and kernel memory manager. So if you want to test
in your system yo ucan upgrade to 2.6.31 kernel and enable stagging drivers to
build KMS support. You will
http://bugs.freedesktop.org/show_bug.cgi?id=23402
Pauli changed:
What|Removed |Added
Attachment #29548|application/octet-stream|text/plain
mime type|
On Tue, 2009-09-15 at 14:24 +0800, Rafał Miłecki wrote:
> Hi,
>
> There are some unfunny cases, when ACPI can not be used for
> controlling backlight level.
>
> Example can be my Sony VAIO
> (http://bugzilla.kernel.org/show_bug.cgi?id=11682) where bl control
> doesn't work with sony-laptop. This
GART static one time initialization was mixed up with GART
enabling/disabling which could happen several time for instance
during suspend/resume cycles. This patch splits all GART
handling into 4 differents function. gart_init is for one
time initialization, gart_deinit is called upon module unload
OK, you provided me fair amount of texts to read :)
W dniu 15 września 2009 09:43 użytkownik Zhang Rui
napisał:
> And I think it may work for you as well, i.e. two backlight sysfs I/F
> may co-exist, it's the user space to decide which I/F to use.
Could you explain, please, how does work Fn+F5
66 matches
Mail list logo
