Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=1803
[EMAIL PROTECTED] changed:
What|Removed |Added
---
On Fri, 31 Dec 2004 06:28:24 + (GMT), Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> Okay some people have commented on the DRM CVS of late, and are unsure of
> what is happening with it,
>
> I'm very willing to drop the shared and linux directories into an archived
> area but that will stop all
Okay some people have commented on the DRM CVS of late, and are unsure of
what is happening with it,
I'm very willing to drop the shared and linux directories into an archived
area but that will stop all support for Linux 2.4,
but at the moment I'm getting the impression more people are using th
Okay I've rebuilt the via drm tree (bk://drm.bkbits.net/drm-via)
It should work but I've no way to test it, I think the drm is close to
secure now if not already, and if I get the nod from the people who know
these things (Thomas, Erdi and Keith - consider yourselves the people),
I'll try and hav
On Thu, 30 Dec 2004 22:03:56 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > If we proceed down the X on
> > GL path this problem would go away since X would stop using libdrm.
>
> No, it won't. For X on GL, the server still loads a DRI driver. It's just
> already loaded early during eglCreat
On Thursday 30 December 2004 21:44, Jon Smirl wrote:
> I've been out of the DRI loop for a while since all I do is help feed
> and change two crying babies, but we also need think about the GL
> standalone case. libdrm is linked into the dri.so's so that they can
> be used standalone. Wouldn't anot
I've been out of the DRI loop for a while since all I do is help feed
and change two crying babies, but we also need think about the GL
standalone case. libdrm is linked into the dri.so's so that they can
be used standalone. Wouldn't another solution be to just fix the
DRI.so's to not export the li
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
> And this definitely doesn't happen with the
> linux-2.6 drm or the 2.6.10
> one? I can't imagine there being any major
> differences .. as far as I know
> on SMP the radeon has had issues before... not sure
> if they've all been fixed...
The linux-2.6
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> > >
> > I know, this causes a problem for any one building Xfree86 DRI. We
> need
> > to fold the DRI xc tree into Xfree86 or stop using Xfree86
> alltogether.
>
> > I'm talking about 2d Xdrivers, where current MergedFB is built. I
> think
> > th
> >
> I know, this causes a problem for any one building Xfree86 DRI. We need
> to fold the DRI xc tree into Xfree86 or stop using Xfree86 alltogether.
> I'm talking about 2d Xdrivers, where current MergedFB is built. I think
> these can be built with the Mesa/lib/r200_dri.so files that live in
> There are also three client-side pieces: libGL, *_dri.so, and (uh-oh) drm.
> 'drm' here is libdrm, which lives in /cvs/dri/drm and is occasionally
> imported into X as hw/xfree86/os-support/$(uname)/drm. libdrm is identical
> on both sides, modulo wrapping some things like malloc to use either
>
> This patch looks to be along similar lines, but for buffers in video
> memory. Is it worth including?
>
> https://bugs.freedesktop.org/show_bug.cgi?id=1668
I'll probably check this in the next couple of days.. I'm just catching up
on any drm bugs logged now...
Dave.
--
David Airlie, Softwa
>
> It seems this was related to limiting the max_address. Anythingh other
> than 0xUL makes pci_alloc_consistent allocate pages with GFP_DMA
> which is intended for ISA DMA < 16MB. I don't think we're ever going to
> need this in a DRM driver. I attached an updated patch that uses
> drm_p
>
> I wasn't doing anything too taxing at the time - just
> taking a trip to Pluto and Charon via 'celestia'.
>
> (And although I say "locked up the X server", I was
> still able to move the mouse cursor around. However,
> the cursor graphic stopped changing, and the screen
> was no longer being up
On Thu, 30 Dec 2004 08:36:51 + (GMT), Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> I'm a bit behind on this area, the patch looks fine, I'm just wondering
> should it intersect with the drm_pci.c stuff for the mach64
>
This patch looks to be along similar lines, but for buffers in video
me
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
> in my mind linux-2.6 and others are dead wood,
> future features in the main
> drm should happen in linux-core, driver features are
> usually added to both trees for ppl running 2.4
FYI, I have just tried the linux-core/ drivers
(drm.ko, radeon.ko), a
Hi
i found out what was wrong, i used the wrong drm driver. Now the gears
are rotating.
Good work and a happy new year
Jan
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt f
Hi
i just tried again the r300_driver, compiled and installed it on
FedoraCore3 x86_64. I updated Xorg via cvs to the latest version and
also downloaded latest mesa-cvs and drm-cvs. I compiled the kernel
module and compiled the driver as stated in the instructions.
glxinfo is working, but only aft
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2004-12-29 at 17:46 -0800, Mike Mestnik wrote:
> > --- Philip Armstrong <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Dec 28, 2004 at 06:41:38PM -0600, John Lightsey wrote:
> > > > First let me say that if anyone would like to take over updat
Personally I lean towards 2 or 3. The nice bit about making libdrm a real
DSO
is that it removes the need to have the libdrm source around when building
the -dri targets in Mesa, or when building the server; you just need to have
built it already. You have to handle libdrm versioning anyway. We
On Fri, 31 Dec 2004, Ben Skeggs wrote:
Cool ! Can you resize the window without lockups as well ?
No, I can't. I didn't think to test that until after my last email.
Okay, that wasn't quite true. I was just attempting to get the drm log of
what happened on the lockup and it was quite hard to p
The goal: Load DRI drivers from the server's libglx, rather than the
software-based libGLcore.
Currently there are four server-side modules: dri, drm, glx, and GLcore.
There are also three client-side pieces: libGL, *_dri.so, and (uh-oh) drm.
'drm' here is libdrm, which lives in /cvs/dri/drm
Cool ! Can you resize the window without lockups as well ?
No, I can't. I didn't think to test that until after my last email.
Okay, that wasn't quite true. I was just attempting to get the drm log
of what happened on the lockup and it was quite hard to produce with drm
debugging on. I'm gues
Cool ! Can you resize the window without lockups as well ?
No, I can't. I didn't think to test that until after my last email.
This is very interesting - I see no artifacts on my computer. Could
you tell what resolution/colordepth are you running at ? How much
memory does your card have ?
Perha
On Fri, 31 Dec 2004, Ben Skeggs wrote:
Hello,
Well, this has progressed nicely since last time I checked in on it. Well
done.
I've tested the latest CVS on RV350 AP(0x4150) and it works without lockups.
Cool ! Can you resize the window without lockups as well ?
Although, while glxgears is runni
Am Do, den 30.12.2004 schrieb Felix Kühling um 15:06:
> Am Do, den 30.12.2004 schrieb Dave Airlie um 13:19:
> > >
> > > drm_pci_alloc allows limiting the maximum address. Would it be too
> > > hackish to pass this via map->offset to the drm_addmap ioctl?
> >
> > Probably no need for the Xserver ma
Am Do, den 30.12.2004 schrieb Dave Airlie um 13:19:
> >
> > drm_pci_alloc allows limiting the maximum address. Would it be too
> > hackish to pass this via map->offset to the drm_addmap ioctl?
>
> Probably no need for the Xserver maps to care about a max address I'd hate
> to overload anything in
Hello,
Well, this has progressed nicely since last time I checked in on it.
Well done.
I've tested the latest CVS on RV350 AP(0x4150) and it works without
lockups. Although, while glxgears is running I seem to have artifacts
around the rest of my screen.
Also, vertex_shader.h and pixel_shade
>
> drm_pci_alloc allows limiting the maximum address. Would it be too
> hackish to pass this via map->offset to the drm_addmap ioctl?
Probably no need for the Xserver maps to care about a max address I'd hate
to overload anything in the addmap ioctl...
Dave.
--
David Airlie, Software Engineer
Am Do, den 30.12.2004 schrieb Dave Airlie um 9:36:
> I'm a bit behind on this area, the patch looks fine, I'm just wondering
> should it intersect with the drm_pci.c stuff for the mach64
Hmm, drm_pci.c looks like a OS-independent mechanism for allocating PCI
memory from within a DRM module. Ho
Hi all,
New snapshot of r300_driver is available. Get it from CVS, tag
"rotating_gears"
Changes:
* code cleanup, do not clobber hardware state as much as before
* hook up projection matrix - displays actually rotating gears
* vertex buffer mode (not used by defaul)
P
Hi Kevin,
This is probably due to recent changes in Mesa, I did not have this
error when compiling, but another popped up.
best
Vladimir Dergachev
On Wed, 29 Dec 2004, Kevin Hessels wrote:
Hi,
I ran into a bit of trouble compiling the r300 mesa d
On Wed, 2004-12-29 at 17:46 -0800, Mike Mestnik wrote:
> --- Philip Armstrong <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Dec 28, 2004 at 06:41:38PM -0600, John Lightsey wrote:
> > > First let me say that if anyone would like to take over updating the
> > > dri-trunk-sid packages on a semi-regular ba
I'm a bit behind on this area, the patch looks fine, I'm just wondering
should it intersect with the drm_pci.c stuff for the mach64
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
-
Has anyone got a Matrox MGA running with the latest Xorg/DRM...
bug 2125 is open and I'm can't help..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
--
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=969
[EMAIL PROTECTED] changed:
What|Removed |Added
36 matches
Mail list logo
