a few of us over at gentoo using 2.6.5love4 kernel
(http://forums.gentoo.org/viewtopic.php?t=160332&start=0)
are finding that the ATI drivers are not compiling on this kernel...
hopefully this is the right address to send this to, it was
listed on the changelog for mm4 @kernel.org
-
On Mon, 2004-04-12 at 06:45, Dave Airlie wrote:
>
> Log message:
> Import mach64 into trunk - still insecure but don't build it by default..
I'm not sure it's as simple as that... this means it'll get merged into
other trees, and may end up in releases.
--
Earthling Michel DÃnzer |
On Mon, 2004-04-12 at 12:13, Nick Borrego wrote:
> a few of us over at gentoo using 2.6.5love4 kernel
> (http://forums.gentoo.org/viewtopic.php?t=160332&start=0)
> are finding that the ATI drivers are not compiling on this kernel...
> hopefully this is the right address to send this to,
It's not;
On Mon, 2004-04-12 at 06:35, Dave Airlie wrote:
> While working on the DRM merge, I picked up on a tool called cvsmonitor,
>
> I have it running on my skynet a/c at:
> http://www.skynet.ie/~airlied/cgi-bin/cvsmonitor/cvsmonitor.pl
>
> and have imported the DRM module into it from fd.o, it gives v
On Mon, 12 Apr 2004 13:06:51 +0200
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-04-12 at 06:45, Dave Airlie wrote:
> >
> > Log message:
> > Import mach64 into trunk - still insecure but don't build it by default..
>
> I'm not sure it's as simple as that... this means it'll get merge
On Wed, 2004-04-07 at 11:49, Felix Kühling wrote:
> On Wed, 07 Apr 2004 08:17:52 +0200
> Svante Signell <[EMAIL PROTECTED]> wrote:
>
> > Additional info, this shows up in the XFree86.0.log file:
> > (II) SAVAGE(0): [drm] Could not create dummy context
>
> Could you try restoring your distro's ori
Michel DÃnzer wrote:
Thanks again for your work on this Dave.
BTW, what's your (and everyone's, for that matter) opinion on
video-reset and the libsysfs copy being in the drm module? I still don't
see the point of the former being there, much less the latter.
I agree with Dave. libsysfs should g
I'll whack libsysfs. That will make us vunerable to the volatility in that
library's interface; it hasn't been very stable over the last six months.
Video-reset statically links the libysysfs code to support early boot. It would
probably just be easier to ignore libsysfs and manipulate /sys directl
The main purpose of this patch is to provide DRM driver support for initializing
secondary adapters. This will all us to remove the corresponding code from
Xfree. Xfree is doing all of this from user space without letting the kernel
know what is happening.
The patch implements:
1) getvbios ioctl
I've been gone for a few weeks, what's the current state of getting the the DRI
mesa drivers bulding in mesa tree? It seems to me like this would make the build
process much simpler.
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yah
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
4:00PM EST or 1:00PM PST, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous IR
Jon Smirl wrote:
I've been gone for a few weeks, what's the current state of getting the the DRI
mesa drivers bulding in mesa tree? It seems to me like this would make the build
process much simpler.
It has stalled, and that's my fault. I should be able to get back to
that tomorrow. Once I get
Ian Romanick wrote:
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
4:00PM EST or 1:00PM PST, if you prefer).
Since "we" are on daylight savings time now, this should re
Hello,
Yesterday I finally decided to get HW acceleration running on my laptop
(Vaio PCG-Z600LEK). The graphics card needs the mach64 driver. I am
running Debian unstable 2.4.25 with XFree86 4.3.0-7
In the past I have tried compiling from the DRI cvs, but first it was
broken, then I found out
>
> 3) It implements the normal Linux mechanism for associating a device driver with
> the hardware; that's what caused the changes in the PCI ID tables. If it
> discovers that an FB driver is already loaded it stops probing and reverts to
> the old scheme.
My main worry is that this stuff break
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
> My main worry is that this stuff break BSD compat, and without Eric around
> I'd say fixing it mightn't be the easiest, also for the 2.6 merge I've
> removed all the device ID strings as as Dave J pointed out they are
> duplicating pci.ids, can we not ge
Hello. I'm using a Radeon IGP320m. Kernel version 2.6.5, XFree86 version
4.4.0, Dri snapshot 20040408. This is the output i recieve from programs
that run with dri. Any help would be great. If I use
20040205 DRI works fine, slow but fine. I've tried the last 20 releases, all
seem to be broken.
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2004-04-12 23:33 ---
(In reply to comm
revert libdri.a to the version from your distro.
Alex
--- Matthew Adams <[EMAIL PROTECTED]> wrote:
> Hello. I'm using a Radeon IGP320m. Kernel version 2.6.5, XFree86
> version
> 4.4.0, Dri snapshot 20040408. This is the output i recieve from
> programs
> that run with dri. Any help would be gre
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> It will build but it won't work. To make it work I would have to relax the
> restriction about X not being able to change the DRM AddMaps for
> registers/framebuffers. Can we try to get all of the driver to implement
> postinit, it's only about 10 lines of
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
> My main worry is that this stuff break BSD compat, and without Eric
> around
> I'd say fixing it mightn't be the easiest, also for the 2.6 merge I've
> removed all the device ID strings as as Dave J pointed out they are
> duplicating pci.ids, can we not
21 matches
Mail list logo
