Jesse Barnes wrote:
> 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 f
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 vbl
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
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:
>>
>>
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, how
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 a4167e7b572859a998710ee
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
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
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
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 yo
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 a
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
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 develo
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
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=12196946624&r=1&w=2
try reverting 1724334d7c82abe55b6506dfe369df4facae6f06 in me
http://bugs.freedesktop.org/show_bug.cgi?id=17315
Alex Deucher <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
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 ev
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 o
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
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
Compo
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"... Things are actually worse than I
> >> > thought.
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.
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
>> > up
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 th
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
>> > ker
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
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
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 thi
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 an
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 (an
[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.
S
-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 availab
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
What a shameThanks!
Dee Sharpe
-Original Message-
From: Alex Deucher <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [email protected]
Sent: Tue, 26 Aug 2008 8:54 am
Subject: Re: [Mesa3d-dev] R2xx
On Tue, Aug 26, 2008 at 9:48 AM, <[E
http://bugs.freedesktop.org/show_bug.cgi?id=16850
Nikos Chantziaras <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|NEW |RESOLVED
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 d
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
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
-
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
B
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)
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
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 inte
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.
>
> A
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/userpr
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/userprefs.
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:
46 matches
Mail list logo
