On Thu, Jan 21, 2010 at 01:59:26PM +0100, Thomas Hellstrom wrote:
Jerome Glisse wrote:
On Thu, Jan 21, 2010 at 04:49:39AM +0100, Luca Barbieri wrote:
We had to do a similar thing in the
Poulsbo driver and it turned out that we could save a significant amount of
CPU by using a delayed
On Thu, Jan 21, 2010 at 04:14:39PM +0100, Luca Barbieri wrote:
I'm not sure I understand your proposal correctly.
It seems your proposoal is similar to mine, replacing the term fence
nodes with ttm transactions, but I'm not sure if I understand it
correctly
Here is some pseudocode for a
On Mon, Jan 25, 2010 at 04:02:37PM +1000, Dave Airlie wrote:
On Sat, Jan 23, 2010 at 1:56 AM, Jerome Glisse jgli...@redhat.com wrote:
If an error happen in r600_blit_prepare_copy report it rather
than WARNING and keeping execution. For instance if ib allocation
failed we did just warn about
On Sun, Jan 24, 2010 at 11:04:33PM +0100, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.32. Please verify if it still should be listed and let
http://bugzilla.kernel.org/show_bug.cgi?id=14924
Jérôme Glisse gli...@freedesktop.org changed:
What|Removed |Added
Status|NEW |NEEDINFO
http://bugs.freedesktop.org/show_bug.cgi?id=26199
--- Comment #2 from Alex Deucher ag...@yahoo.com 2010-01-25 08:00:17 PST ---
Please attach your xorg log and config.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
http://bugs.freedesktop.org/show_bug.cgi?id=26214
Summary: HDMI Audio with r600 KMS doesn't survive suspend to ram
Product: DRI
Version: DRI CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
http://bugs.freedesktop.org/show_bug.cgi?id=23993
--- Comment #20 from Dennis Nezic denn...@dennisn.dyndns.org 2010-01-25
09:33:39 PST ---
That bug report referenced in Comment #17 suggests that downgrading mesa gets
rid of the bug, I tried compiling many many git snapshots from the current
http://bugs.freedesktop.org/show_bug.cgi?id=26185
--- Comment #7 from Rafał Miłecki zaj...@gmail.com 2010-01-25 09:43:37 PST
---
Hm, the same bug happens on different notebook with RV620... Maybe it's
something in openSUSE that causes this? Both run this distribution.
--
Configure
On Thu, 2010-01-21 at 09:09 +0800, Zhenyu Wang wrote:
On 2010.01.20 13:14:23 +, James Simmons wrote:
It's just adding the backlight api to the intel driver. In fact it gives
the user the ablity to control the brightness of the backlight which I
see
is lacking in the
On Sun, 24 Jan 2010 00:55:59 +0100
Rafael J. Wysocki r...@sisk.pl wrote:
From: Rafael J. Wysocki r...@sisk.pl
If a non-KMS graphics driver is used, the kernel carries out a VT
switch during suspend/resume to avoid possible problems with freezing
X at a wrong time and to cause X to repaint
This probably belongs in the core DRM KMS code instead of the driver.
I can imagine that there may be some X driver code that still needs to
be executed on suspend/resume for some drivers, so this may introduce
bugs, but it's definitely the right way to go.
You can have a mix of KMS and non
On Mon, 25 Jan 2010 18:43:50 +
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
This probably belongs in the core DRM KMS code instead of the
driver. I can imagine that there may be some X driver code that
still needs to be executed on suspend/resume for some drivers, so
this may introduce
On Sun, 24 Jan 2010 00:55:59 +0100, Rafael J. Wysocki r...@sisk.pl wrote:
From: Rafael J. Wysocki r...@sisk.pl
If a non-KMS graphics driver is used, the kernel carries out a VT
switch during suspend/resume to avoid possible problems with freezing
X at a wrong time and to cause X to repaint
http://bugzilla.kernel.org/show_bug.cgi?id=14924
Kieran Clancy codebeard+ker...@gmail.com changed:
What|Removed |Added
CC|
Jerome Glisse wrote:
On Thu, Jan 21, 2010 at 01:59:26PM +0100, Thomas Hellstrom wrote:
Jerome Glisse wrote:
On Thu, Jan 21, 2010 at 04:49:39AM +0100, Luca Barbieri wrote:
We had to do a similar thing in the
Poulsbo driver and it turned out that we could save a significant
http://bugzilla.kernel.org/show_bug.cgi?id=14924
--- Comment #3 from Rafael J. Wysocki r...@sisk.pl 2010-01-25 21:00:36 ---
On Monday 25 January 2010, David wrote:
Américo Wang wrote:
On Sun, Jan 24, 2010 at 11:04:33PM +0100, Rafael J. Wysocki wrote:
This message has been generated
http://bugzilla.kernel.org/show_bug.cgi?id=14924
Rafael J. Wysocki r...@sisk.pl changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
http://bugzilla.kernel.org/show_bug.cgi?id=14924
Rafael J. Wysocki r...@sisk.pl changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure
On Monday 25 January 2010, Jesse Barnes wrote:
On Mon, 25 Jan 2010 18:43:50 +
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
This probably belongs in the core DRM KMS code instead of the
driver. I can imagine that there may be some X driver code that
still needs to be executed on
http://bugs.freedesktop.org/show_bug.cgi?id=26199
--- Comment #3 from Peter Hercek pher...@gmail.com 2010-01-25 13:41:38 PST
---
I cannot simulate the bug as it was when I reported the error. I'll attach the
exact xorg.conf I used, but I do not have Xorg.0.log any more. But I looked at
it
http://bugs.freedesktop.org/show_bug.cgi?id=26199
Peter Hercek pher...@gmail.com changed:
What|Removed |Added
Attachment #32812|application/octet-stream|text/plain
http://bugs.freedesktop.org/show_bug.cgi?id=26199
--- Comment #5 from Peter Hercek pher...@gmail.com 2010-01-25 13:47:29 PST
---
Created an attachment (id=32813)
-- (http://bugs.freedesktop.org/attachment.cgi?id=32813)
Xorg.log (not when the eroror happend, everything the same except
On Monday 25 January 2010, Alan Cox wrote:
But in that case we should be able to disable the VT switch disable
path; we just have to check each driver as it's loaded.
OK, what the right sequence of checks would be in that case and where to
place
them?
Why are we even driving a
http://bugs.freedesktop.org/show_bug.cgi?id=26087
Shawn Starr shawn.st...@rogers.com changed:
What|Removed |Added
Summary|IRQ stalls with RV635 when |Stalls with RV635
http://bugs.freedesktop.org/show_bug.cgi?id=26087
--- Comment #8 from Shawn Starr shawn.st...@rogers.com 2010-01-25 13:56:47
PST ---
Resolution of screen is: 1920 x 1200
XRandr info:
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192
DVI-0 disconnected (normal left
http://bugzilla.kernel.org/show_bug.cgi?id=14924
--- Comment #4 from Jérôme Glisse gli...@freedesktop.org 2010-01-25 22:11:14
---
Well i don't think we can treat GPU hw lockup as regression, sadly we always
had such issue, sometimes we add change that makes it more likely to happen,
Obviously I'd like to clean it up, though.
So, what device should handle this in your opinion?
My guess would be the relevant device driver for the hardware layer
So fbcon would probably not switch because it can put video modes back,
KMS obvious likewise. The text console might do something
http://bugs.freedesktop.org/show_bug.cgi?id=26051
--- Comment #8 from ken moffat zarniwhoo...@googlemail.com 2010-01-25
17:08:43 PST ---
The problem (specifically, glxgears locks up before showing any gear wheels)
still exists in HEAD from last Friday
On Mon, 2010-01-25 at 06:46 +, Dave Airlie wrote:
Hi Linus,
Please pull the 'drm-linus' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
I was out last week for sick kid + LCA dash so stuff queued up behind me,
I've booted this across a few
30 matches
Mail list logo
