This drop fixes a few issues in the reset code.
Please ignore the previous version, it has a bug on some cards that can disable
them on startup.
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Tax Center - File online by April
Jon Smirl wrote:
--- Michel Dänzer [EMAIL PROTECTED] wrote:
As Alan pointed out on IRC, it won't. But providing the means to do it
I'm using code extracted from the reset function in Xfree. It seems to work for
Xfree, why shouldn't it work for me?
cleanly is certainly good basically. The
Hello everyone,
I am offically throwing in my hat to volunteer for
testing and code merging for the gatos/dri/linux
kernel 2.6 effort that I have seen as I lurk through
the DRI and GATOS mailing lists.
My current config:
Debian Testing (sarge) Xfree 4.3.0 configuration
Using: Kernel 2.6.5 at the
On Thu, 2004-04-15 at 04:50, Jon Smirl wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
As Alan pointed out on IRC, it won't. But providing the means to do it
I'm using code extracted from the reset function in Xfree. It seems to work for
Xfree, why shouldn't it work for me?
Where did I
I had a good fix for this in one of my patches. Only BSD needs the names
but both need the IDs and linux even had a hotplug struct. This was geard
and enginered with both OSes being treated as eaquils and other OSes made
easy to acommidate. What I did was had some macroes that took
My problem with your changes is that I really don't know how to evaluate them.
Secondly, there seem to be people who know what they're talking about who have
real objections to some of them.
I think Keith has put it the best, most of my concerns about this work are
that it is maybe before its
On Wed, 2004-04-14 at 06:45, Dave Airlie wrote:
Hi,
I've a Radeon M7 running at 800x600-32bit, and have built solo and
X/DRI drivers out of the same tree, when I run the manytex (one from
miniglx and other from tests) under X/DRI the screen is rock solid and
manytex runs, however under
I've been down the branch path before. I have many thousands of lines of
changes. If I do all of them on a branch sometime in the future people might
decide to merge them. When that happens everyone will say there is too much code
and it is too complex to understand, break it up into small patches
On Thu, 2004-04-15 at 17:13, Alex Deucher wrote:
Speaking of merging, what are everyone's thoughts on merging the DDX
trees (drivers at least, I don't know about the rest, especially with
the licensing)? I was thinking mostly DRI-xfree86 but I suppose we
could look at gatos too. Specifically
On Thu, 2004-04-15 at 17:44, Jon Smirl wrote:
I've been down the branch path before. I have many thousands of lines of
changes. If I do all of them on a branch sometime in the future people might
decide to merge them. When that happens everyone will say there is too much code
and it is too
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Thu, 2004-04-15 at 17:13, Alex Deucher wrote:
Speaking of merging, what are everyone's thoughts on merging the
DDX
trees (drivers at least, I don't know about the rest, especially
with
the licensing)? I was thinking mostly DRI-xfree86 but I
Hi,
Here are my plans to split the binary snapshot into a device-specific
and a common (device-independent) part. This was discussed briefly on
the last IRC meeting. I attached a patch to the snapshot scripts. ATM
it's only to illustrate the idea, it is completely untested.
After Ian's
Felix Kühling wrote:
I added a new Meta-driver to the dripkg.sh script called COMMON. If
the driver name is COMMON then dripkg.sh would package only libGL and
the XFree86 core modules. Otherwise it packs only the DDX and DRI
modules and the DRM sources. The install script detects which
Do you mean something like...
sed 's/0x111, 0x/0x111, 0x, The dev name/'
You could do this in place or on a radeon-ids.h.
I'm sure it would be better ro use an awk script to prune the info from
radeon.h and just have it distributed by default. My vote is to have it
bloat the kernel
And don't forget that pci.ids and the code that uses it could be portet to
BSD as part of the DRM.
--- Mike Mestnik [EMAIL PROTECTED] wrote:
Do you mean something like...
sed 's/0x111, 0x/0x111, 0x, The dev name/'
You could do this in place or on a radeon-ids.h.
I'm sure it
I finally have access to an x86 SMP box, and I have a few cycles to look
at the SMP related problems. I'm using an AGP G400 and quake3-smp.
Like Dieter, I get a black screen and a hung program. When I break in
with GDB, here is the stack trace. Dieter, does this match what you see?
This is a diff for drivers/char/drm to make r128 use userland-loadable
firmware. It's completely untested (since I don't *have* an r128, I don't
see any way to test it), but I bet it'll work; the firmware loading interface
seems remarkably easy to use.
Following that (in the form of a diff) is
Ian Romanick wrote:
I finally have access to an x86 SMP box, and I have a few cycles to look
at the SMP related problems. I'm using an AGP G400 and quake3-smp. Like
Dieter, I get a black screen and a hung program. When I break in with
GDB, here is the stack trace. Dieter, does this match
Nathanael Nerode wrote:
This is a diff for drivers/char/drm to make r128 use userland-loadable
firmware. It's completely untested (since I don't *have* an r128, I don't
see any way to test it), but I bet it'll work; the firmware loading interface
seems remarkably easy to use.
Following that (in
On Thu, 15 Apr 2004, Nathanael Nerode wrote:
This is a diff for drivers/char/drm to make r128 use userland-loadable
firmware. It's completely untested (since I don't *have* an r128, I don't
see any way to test it), but I bet it'll work; the firmware loading interface
seems remarkably easy to
On Thu, 2004-04-15 at 22:00, Nathanael Nerode wrote:
This is a diff for drivers/char/drm to make r128 use userland-loadable
firmware.
Sigh, is this really necessary? :\ Anyway, I'll offer some technical
comments.
It's completely untested (since I don't *have* an r128, I don't
see any way
--- Dave Airlie [EMAIL PROTECTED] wrote:
I can extract the code from Xfree for doing everything I need from user
space and I can add this code into the mesa linux-solo project without a
lot of hassle.
Are you going to get solo so it doesn't require an fb device? if so that
is defintely
22 matches
Mail list logo
