--- 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 d
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 wa
> 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
This is just open source, there are no short-cuts, if you
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
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 th
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 wha
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 th
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?
0x00162c3
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 -ids.h.
>
> I'm sure it
Do you mean something like...
sed 's/0x111, 0x/0x111, 0x, "The dev name"/'
You could do this in place or on a -ids.h.
I'm sure it would be better ro use an awk script to prune the info from
.h and just have it distributed by default. My vote is to have it
bloat the kernel source, just
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
subdire
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 driinterfa
--- 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<->xf
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
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. Specifi
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
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 the radeon driver has some new
fixes in the xfree86
On Thu, 2004-04-15 at 05:29, John Frisk wrote:
> 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.
For all I know, there's nothing in the
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 u
>
> 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
> 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 para
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
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 m
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 que
24 matches
Mail list logo
