http://bugs.freedesktop.org/show_bug.cgi?id=17196
--- Comment #3 from Eric Anholt [EMAIL PROTECTED] 2008-08-25 23:16:16 PST ---
Fixed an issue with G965 in 0793456076f8356f1b7fb99e0b76b8e3d1eeb74a in the
kernel that would have manifested in drawpix failing.
Also, please include kernel
http://bugs.freedesktop.org/show_bug.cgi?id=17305
Summary: [GEM]redundant shadow when run doom3-demo
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority:
http://bugs.freedesktop.org/show_bug.cgi?id=17305
--- Comment #1 from liuhaien [EMAIL PROTECTED] 2008-08-26 00:48:43 PST ---
Created an attachment (id=18518)
-- (http://bugs.freedesktop.org/attachment.cgi?id=18518)
xorg.0.log
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=17305
--- Comment #2 from liuhaien [EMAIL PROTECTED] 2008-08-26 00:49:12 PST ---
Created an attachment (id=18519)
-- (http://bugs.freedesktop.org/attachment.cgi?id=18519)
xorg conf file
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=17196
--- Comment #4 from Shuang He [EMAIL PROTECTED] 2008-08-26 00:54:12 PST ---
(In reply to comment #3)
Fixed an issue with G965 in 0793456076f8356f1b7fb99e0b76b8e3d1eeb74a in the
kernel that would have manifested in drawpix failing.
Also,
Hi Thomas,
I've made some changes you might be interested in on the
modesetting-gem branch of the main repo.
1. removed all the TTM interfaces and ioctls from the kernel API.
2. removed drm_bo_lock.c (we need to discuss what we want that for)
3. built a radeon GEM interface on top of the TTM
Dave Airlie wrote:
Hi Thomas,
I've made some changes you might be interested in on the
modesetting-gem branch of the main repo.
1. removed all the TTM interfaces and ioctls from the kernel API.
2. removed drm_bo_lock.c (we need to discuss what we want that for)
3. built a radeon GEM
In drivers/char/drm/drm_sysfs.c:187, function drm_sysfs_device_add():
for (i = 0; i ARRAY_SIZE(device_attrs); i++) {
err = device_create_file(minor-kdev, device_attrs[i]);
if (err)
goto err_out_files;
}
return 0;
err_out_files:
if (i 0)
Does anyone know if the datasheets programming guides for AMD's old R2xx
cards have been released?? If so, where could I find them?
Dee Sharpe
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
On Tue, Aug 26, 2008 at 9:48 AM, [EMAIL PROTECTED] wrote:
Does anyone know if the datasheets programming guides for AMD's old R2xx
cards have been released? If so, where could I find them?
They are not yet available without an NDA.
Alex
On Tue, 26 Aug 2008 11:43:03 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Dave,
This all sounds good.
The drm_bo_lock.c is intended to replace the drm hardware lock on VT
switches when the X server wants to clean
all memory for release to a legacy fbdev driver. It will block all drm
Hi,
Is there any games that run on frame buffer driver?
Thanks!
Chunfeng
-Original Message-
From: Daniel Stone [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2008 9:34 AM
To: Zhao, Chunfeng
Cc: Keith Packard; Michel Dänzer; Kristian Høgsberg; dri-devel
Subject: Re: Load framebuffer
http://bugs.freedesktop.org/show_bug.cgi?id=16850
Nikos Chantziaras [EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
What a shameThanks!
Dee Sharpe
-Original Message-
From: Alex Deucher [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; dri-devel@lists.sourceforge.net
Sent: Tue, 26 Aug 2008 8:54 am
Subject: Re: [Mesa3d-dev] R2xx
On Tue, Aug 26, 2008 at 9:48 AM,
On Tue, Aug 26, 2008 at 1:56 PM, [EMAIL PROTECTED] wrote:
What a shameThanks!
Pretty much everything you would need is already available in the
opensource drivers. AMD may be able to release them without an NDA
eventually, but we are currently busy with the r6xx/r7xx doc release
which has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher wrote:
On Tue, Aug 26, 2008 at 9:48 AM, [EMAIL PROTECTED] wrote:
Does anyone know if the datasheets programming guides for AMD's old R2xx
cards have been released? If so, where could I find them?
They are not yet available
[Forgot to send this out yesterday, the other patches sit on top of it. For
BSD compat we'll probably need a macro to get the IRQ, since they have a
different OS field that contains it.]
We can get this from the PCI device field on Linux (and another structure on
BSD), no need to duplicate it.
The DRM design includes ioctls to allow a userland driver to tell the kernel
driver when to register its interrupt handler and on what IRQ. This is a
really bad idea for several reasons, and fortunately I don't think any DDX
drivers take advantage of the no, use this IRQ aspect of the API (and
On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
The DRM design includes ioctls to allow a userland driver to tell the kernel
driver when to register its interrupt handler and on what IRQ. This is a
really bad idea for several reasons, and fortunately I don't think any
Jesse Barnes wrote:
The DRM design includes ioctls to allow a userland driver to tell the kernel
driver when to register its interrupt handler and on what IRQ. This is a
really bad idea for several reasons, and fortunately I don't think any DDX
drivers take advantage of the no, use this
On Tuesday, August 26, 2008 12:03 pm Stephane Marchesin wrote:
On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes [EMAIL PROTECTED]
wrote:
The DRM design includes ioctls to allow a userland driver to tell the
kernel driver when to register its interrupt handler and on what IRQ.
This is a
On Tuesday, August 26, 2008 12:23 pm Thomas Hellström wrote:
Jesse Barnes wrote:
The DRM design includes ioctls to allow a userland driver to tell the
kernel driver when to register its interrupt handler and on what IRQ.
This is a really bad idea for several reasons, and fortunately I
On Tue, Aug 26, 2008 at 9:36 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Tuesday, August 26, 2008 12:03 pm Stephane Marchesin wrote:
On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes [EMAIL PROTECTED]
wrote:
The DRM design includes ioctls to allow a userland driver to tell the
kernel driver
On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote:
As for the new development model... Things are actually worse than I
thought. There are some fairly large differences between linux-core and
upstream, some of which have been in linux-core for a long time. It's
one thing to
On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote:
As for the new development model... Things are actually worse than I
thought. There are some fairly large differences between linux-core and
upstream, some
On Tuesday, August 26, 2008 1:28 pm Stephane Marchesin wrote:
On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes [EMAIL PROTECTED]
wrote:
On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote:
As for the new development model... Things are actually worse than I
thought. There are
http://bugs.freedesktop.org/show_bug.cgi?id=17315
Summary: unknown chip id 0x71d4, can't guess.
Product: Mesa
Version: 7.0
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
http://bugs.freedesktop.org/show_bug.cgi?id=17315
--- Comment #1 from Adam K Kirchhoff [EMAIL PROTECTED] 2008-08-26 14:52:58
PST ---
You need a newer version of Mesa and the DRM kernel modules to get direct
rendering working on that video card. I know that these are available with
Fedora
On Tue, Aug 26, 2008 at 11:17 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote:
I am outlining the fact that you confuse a problem and its solution.
Problem: merging stuff upstream takes time to Dave
Your solution: have lots of
http://bugs.freedesktop.org/show_bug.cgi?id=17275
--- Comment #4 from Daniel Kasak [EMAIL PROTECTED] 2008-08-26 15:34:44 PST
---
I'm actually getting the same thing exactly with a recent mesa build, on my
Radeon X700 Mobility. Maybe it's a Mobility thing?
I'm on Gentoo, and update mesa
http://bugs.freedesktop.org/show_bug.cgi?id=17315
Alex Deucher [EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
http://bugs.freedesktop.org/show_bug.cgi?id=17275
--- Comment #5 from Alex Deucher [EMAIL PROTECTED] 2008-08-26 15:48:52 PST
---
this looks like it may be related to fallout from this:
http://marc.info/?t=12196946624r=1w=2
try reverting 1724334d7c82abe55b6506dfe369df4facae6f06 in mesa
On Wed, Aug 27, 2008 at 5:23 AM, Thomas Hellström
[EMAIL PROTECTED] wrote:
Jesse Barnes wrote:
The DRM design includes ioctls to allow a userland driver to tell the kernel
driver when to register its interrupt handler and on what IRQ. This is a
really bad idea for several reasons, and
On Tue, 2008-08-26 at 14:17 -0700, Jesse Barnes wrote:
On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote:
On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes [EMAIL PROTECTED]
wrote:
On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote:
As for the new development model...
On Tuesday, August 26, 2008 4:15 pm Dave Airlie wrote:
On Wed, Aug 27, 2008 at 5:23 AM, Thomas Hellström
I've only tested this patch so far on i915, where it's still slightly
broken; I was planning on fixing it once I've sync'd some more
linux-core changes into drm-next (namely the rest of
On Wed, 2008-08-27 at 09:15 +1000, Dave Airlie wrote:
On Wed, Aug 27, 2008 at 5:23 AM, Thomas Hellström
[EMAIL PROTECTED] wrote:
Jesse Barnes wrote:
The DRM design includes ioctls to allow a userland driver to tell the
kernel
driver when to register its interrupt handler and on what
Okay I've put some thoughts up at:
http://dri.freedesktop.org/wiki/DRMProcess
and I've pasted it in below this for discussion.
some other points:
a) People are pushing for a process change, we will have something
change, however this isn't a who shouts loudest competition, so more
than likely
On Tuesday, August 26, 2008 5:13 pm Robert Noland wrote:
I kinda prompted this topic to come back to life... I'm less concerned
with the IRQ bits than I am with the vblank issue, but they are
currently tied together.
What I'm seeing right now, it that at least the intel ddx driver calls
the
On Tuesday, August 26, 2008 5:15 pm Dave Airlie wrote:
DRM Development Process (Proposed)
1. Master branch in Linux tree style with links for BSD etc.
2. Always compatible with current release Linux kernel + with
backwards compat *where* practical for older kernels. We should
probably limit
On Tue, Aug 26, 2008 at 06:20:43PM -0700, Dave Airlie wrote:
linux-core/radeon_encoders.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
New commits:
commit a4167e7b572859a998710ee599298e5131f51620
Author: Dave Airlie [EMAIL PROTECTED]
Date: Wed Aug 27 11:12:19
On Wed, Aug 27, 2008 at 11:35 AM, Ville Syrjälä [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 06:20:43PM -0700, Dave Airlie wrote:
linux-core/radeon_encoders.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
New commits:
commit
On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote:
Okay I've put some thoughts up at:
http://dri.freedesktop.org/wiki/DRMProcess
and I've pasted it in below this for discussion.
some other points:
a) People are pushing for a process change, we will have something
change, however
On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland [EMAIL PROTECTED] wrote:
On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote:
Okay I've put some thoughts up at:
http://dri.freedesktop.org/wiki/DRMProcess
and I've pasted it in below this for discussion.
some other points:
a) People are
On Tue, 2008-08-26 at 18:02 -0700, Jesse Barnes wrote:
On Tuesday, August 26, 2008 5:13 pm Robert Noland wrote:
I kinda prompted this topic to come back to life... I'm less concerned
with the IRQ bits than I am with the vblank issue, but they are
currently tied together.
What I'm
On Tuesday, August 26, 2008 9:03 pm Robert Noland wrote:
On Tue, 2008-08-26 at 18:02 -0700, Jesse Barnes wrote:
On Tuesday, August 26, 2008 5:13 pm Robert Noland wrote:
I kinda prompted this topic to come back to life... I'm less concerned
with the IRQ bits than I am with the vblank
45 matches
Mail list logo
