Arjan van de Ven wrote:
On Mon, Aug 16, 2004 at 10:43:34AM +0100, Keith Whitwell wrote:
If we can manage to support FreeBSD and Linux from one codebase, surely
supporting 2.4 and 2.6 isn't too difficult?
It for sure is possible.
However the DRM codebase proves that it's incapable of even doing
Dave Airlie wrote:
DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER,
DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my
god...
Heh. I actually find those ones pretty innocuous and easy to work with,
compared to some of the stuff in there. Nothing
Arjan van de Ven wrote:
On Mon, Aug 16, 2004 at 12:42:51PM +0100, Keith Whitwell wrote:
Dave's hit the nail on the head here. If you'd like some changes, feel
free to make suggestions.
once the new intel DRM driver hits Linus' tree I want to start an experiment
to make it look like a linux
Brian Paul wrote:
At this point, given that the X.Org tree is still monolithic, our Mesa
usage is somewhat independent of Mesa releases in my view. I chose to
integrate the development branch because of the great advances made in
the DRI drivers in general (though we have some issues to resolve
John Baldwin wrote:
On Wednesday 11 August 2004 07:07 am, Alexey Dokuchaev wrote:
Hi there,
Judging from /sys/dev/drm/ contents, and listed kernel options in NOTES,
there's currently evidence of support for i810/830 chips in FreeBSD,
which (I suspect) is the probable reason why DRI is not enabled
Dave Airlie wrote:
Okay I've gotten myself a 9200 card that can do 8x, and I've a
motherboard that can do it.. now I know some people will tell me 8x is of
no practical use (but then neither is my mach64 :-)
I spotted a patch from Hui Yu via Michael at
Alexey Dokuchaev wrote:
On Thu, Aug 12, 2004 at 08:48:09AM +0100, Keith Whitwell wrote:
John Baldwin wrote:
On Wednesday 11 August 2004 07:07 am, Alexey Dokuchaev wrote:
Hi there,
Judging from /sys/dev/drm/ contents, and listed kernel options in NOTES,
there's currently evidence of support
Alexey Dokuchaev wrote:
On Thu, Aug 12, 2004 at 03:49:14PM +0700, Alexey Dokuchaev wrote:
On Thu, Aug 12, 2004 at 08:48:09AM +0100, Keith Whitwell wrote:
John Baldwin wrote:
On Wednesday 11 August 2004 07:07 am, Alexey Dokuchaev wrote:
Hi there,
Judging from /sys/dev/drm/ contents, and listed
Philipp Klaus Krause wrote:
Since the driver supports GL_NV_texture_retangle,
GL_EXT_texture_retangle and probably soon will GL_ARB_texture_retangle
I wonder why GL_ARB_texture_non_power_of_two isn't supported.
Because nobody's done the work to support it. It shouldn't be that hard - the
main
Alan Cox wrote:
On Mer, 2004-08-11 at 01:29, Dave Airlie wrote:
Can the VIA DRI stuff get pushed through to the kernel with the S3
stuff please, even if we mark VIA as experimental
the DRM stuff? We need to mark as insecure, I really don't want anything
that the authors consider insecure to go
Dave Airlie wrote:
The latest patch against the drmfntbl-0-0-1 branch of the DRM is at
http://www.skynet.ie/~airlied/patches/dri/drm_ftbl_latest.diff
This will be checked into the branch when fd.o gets sorted out...
It dumps:
DRIVER_CTX_[CD]TOR
HAVE_KERNEL_CTX_SWITCH
DRIVER_BUF_PRIV_T
Ian Romanick wrote:
Jon Smirl wrote:
The only case I see a problem is when drm-core is compiled into the
kernel. Why don't we just change the Makefile to default to copying the
CVS code into the kernel source tree and tell the user to rebuild his
kernel?
I don't think that will fly with Joe-user
Jon Smirl wrote:
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Jon Smirl wrote:
The only case I see a problem is when drm-core is compiled into
the kernel. Why don't we just change the Makefile to default to
copying the CVS code into the kernel source tree and tell the
user
The key here is that distributions release new kernels at a rapid pace.
This is not X where we get a new release every five years. The standard
mechanism for upgrading device drivers in Linux is to add them to the
kernel and wait for a release.
So, people have to reboot to install a new
Dave Airlie wrote:
Just wondering what peoples opinions on dropping some of the myriad of
typedefs in the DRM? I know the kernel has try to this direction of late,
should we follow?
I'd rather just use struct drm_device * instead of drm_device_t * ...
Oh, yes please, please remove them.
Keith
Dave Airlie wrote:
Keith,
Have Intel supplied you with any info on the zone rendering stuff
in their chipsets or if we can avail of it .. it sounds like it might be
worth a frame or two ...
I had access to it for i915, I don't think they had any issues with it. It
does look like a fair
Ian Romanick wrote:
I think this is the right place to start. A couple of these look easier
to get rid of than others. __HAVE_MTRR and __HAVE_AGP are enabled in
every driver except ffb. It should be easy enough to get rid of them.
It looks like __HAVE_RELEASE, __HAVE_DMA_READY,
Dave Airlie wrote:
Okay at
http://www.skynet.ie/~airlied/patches/dri/drm_fn_tbl.diff
is my first attempt at swatting the low hanging fruit in the DRM,
this moves the driver macros into a function table which the driver can
work off.. i've only done the radeon on Linux (no point going too far
Dave Airlie wrote:
Okay now I've gotten it to probe my i865 but X kills it stone dead.. I've
checked in the changes..
Have you been able to run the version on the i865 branch?
Keith
---
This SF.Net email is sponsored by OSTG. Have you noticed
Dave Airlie wrote:
Have you been able to run the version on the i865 branch?
I've just been comparing the branchs at source level, I'm not sure I have
a DDX for FreeBSD that will use it ...
The whole tree should compile install just fine off that branch...
shouldn't it?
Keith
Ian Romanick wrote:
Keith Whitwell wrote:
We've actually managed to do a fair bit of cleanup already - if you
look at the gamma driver, there's a lot of stuff in there which used
to be shared but ifdef'ed out between all the drivers. The
__HAVE_MULTIPLE_DMA_QUEUES macro is a remnant
Philipp Klaus Krause wrote:
Since the drivers have to use software fallback instead of
hardware tcl in some cases anyways, why don't they expose
GL_ARB_vertex_blend and GL_ARB_vertex_program?
No reason not to. Bear in mind that our current implementations of these are
less optimized than the
ian: what about splitting the current memory management code into a
module that can be swapped for your new version?
AFAIK, the only drivers that have any sort of in-kernel memory manager
are the radeon (only used by the R200 driver) and i830. That memory
manager only exists to support an
Dave Airlie wrote:
I've just checked in the basics of the i915 DRM for FreeBSD but nothing
happens... I'm running FreeBSD 5.2.1,
After I kldload i915.ko I see nothing in the dmesg... am I missing
something? or as the AGP driver stolen the card?
Oh, yes. This is something you need to look at.
Adam Jackson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 23 July 2004 00:04, Eric Anholt wrote:
The point is that the DRI is merging into X.Org and there won't be a
separate tree any more. I still need to merge the development drivers
(mach64, savage), but my testbox is down
Adam Jackson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've got DRI and GLX working with the libdl module loader under current Xorg
CVS. It works well enough to run glxgears (both direct and indirect) and
quake3. The patch isn't quite finished, for two reasons. One, and rather
Mike A. Harris wrote:
On Fri, 16 Jul 2004, Alex Deucher wrote:
Date: Fri, 16 Jul 2004 09:06:26 -0400
From: Alex Deucher [EMAIL PROTECTED]
To: Dave Airlie [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: [EMAIL PROTECTED]
Subject: Re: i830 driver
Jon Smirl wrote:
Context creation in DRM is marked as needing root access. Is this to
prevent a process from doing a DOS attack by creating too many
contexts? Couldn't I do the same DOS attack simply by creating lots of
processes each with their own context?
Is there a hardware limit on contexts?
Dave Airlie wrote:
I've get that for r200 too. Seems to be related to the t_vertex.c codegen
addition. Maybe t_vertex_c.o doesn't get linked in?
Yes, it's my fault. I can't wait until we can stop trying to track Mesa
directly from DRI cvs.
I'll commit the fixes once I've rebuilt a DRI tree.
not
Roland Scheidegger wrote:
Thomas Hellström wrote:
Hi!
I'm trying to compile the unichrome_dri.so driver in the xc tree with
latest Mesa cvs. When the driver is loaded I get a missing symbol
_tnl_init_c_codegen.
Something new I've left out?
I've get that for r200 too. Seems to be related to the
Sasayama wrote:
Is there any free test suite for OpenGL? We'd like to test our DRI
implementation, but don't need a trademark license at this time.
glean.sf.net
Keith
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend
Eric Anholt wrote:
I am definitely in favor of the DRI X tree stuff being a branch on the
X.Org tree.
I'd prefer to look at it slightly differently:
1) I'd like to get the current work in the DRI tree to a stable state, meaning:
a) finish (or part finish) Ian's NEW_INTERFACE work
b) import a
Dave Airlie wrote:
Oh yes, and it wouldn't be outside the realms of possibility to consider
supporting the i810 in this driver as well, though that might take a little
bit of hammering on stuff.
I might get time to take the hammer out in a few weeks, one i810 board is
running DOS, the other has a
OK, the 3D and drm components are in CVS now. It'll be a little while before
it can be used by anyone as we need to get the DDX changes in somewhere as well.
It's worth a look. Some features include:
- Fragment programs in hardware
- All GL rasterization proceeds through some sort of
Keith Whitwell wrote:
OK, the 3D and drm components are in CVS now. It'll be a little while
before it can be used by anyone as we need to get the DDX changes in
somewhere as well.
It's worth a look. Some features include:
- Fragment programs in hardware
- All GL rasterization proceeds
José Fonseca wrote:
Dave,
On Wed, Jun 09, 2004 at 06:48:10AM +0100, Dave Airlie wrote:
This file is pretty much a copy of tnl_dd/t_dd_vbtmp.h with what looks
like some experimental MACH64_PREMULT_TEXCOORDS code I think,
Is this experiment finished? the code isn't use as mach64 has a native
vertex
Dave Airlie wrote:
test at the end won't do the _tnl_install_attrs because v0 is the same
as it was before, even though the tnl code would have changed to emit
the specular instead of the pad.
Huh... Well spotted. One possibility is to record the old value of 'index'
and use that in addition to
Dave Airlie wrote:
BUT nothing uses it. Since it's broken, I'd like to remove all traces of it
(from both user mode and kernel mode). Is there any reason not to? If we
need that functionality later, we can design a better interface for it that
will less fragile.
Roland Scheidegger wrote:
So, when I updated radeon_maos_arrays.c and compiled that (btw really
brave souls can try it out, just define RADEON_OLD_PACKETS to 0 in
radeon_context.h and RADEON_MAOS_VERTS to 0 in radeon_maos.c, that
codepath was only enabled in april 2002 for 9 days and probably
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Here's the deal. glXGetProcAddress *NEVER* returns NULL. It returns a
pointer to a dispatch function. If you request an unknown function, it
will dynamically generate a dispatch for it. Try calling
'glXGetProcAddressARB((const
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the DRI
copies. Since
Keith Whitwell wrote:
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the
DRI
Alex Deucher wrote:
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
I'm going to try and wrap up the remaining issues preventing a
single
driver binary. As part of that, I'm going to move the Mesa copies
of
dri_util.[ch
Vladimir Dergachev wrote:
Hi Nikolai,
I merged your patches - thank you very much !
I wonder if a similar approach could allow us to reset the radeon/r200 after
lockups?
There's historically been code which tried to do that, but it just never ever
worked...
Keith
Eric Anholt wrote:
I think I've noticed a problem in i830_tris.c, in i830RenderStart.
Let's say you've got fog turned on but not specular. Then v0 has
VRTX_HAS_SPEC set, and you're emitting the fog factor and a 3-byte pad.
If you then turn on specular, v0 still has VRTX_HAS_SPEC set, so the
Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define
Mike Mestnik wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Assembly dispatch stubs are only generated for x86 and SPARC. It looks
like the #if test in dispatch.c is wrong, so that stubs don't even get
used on SPARC. In any case, Jakub's patch did modify the x86 assembly,
not the C version.
André Ventura Lemos wrote:
On Mon, 2004-05-24 at 11:15, Dave Airlie wrote:
doesn't happen for me,
00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics
Device (rev 02)
:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated
Graphics Device (rev 02)
[drm]
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATCH(FUNC, ARGS, MESSAGE) \
Alan Cox wrote:
On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
There are two types of VTs - text and graphical. It is only practical to have a
single graphical VT because of the complexity of state swapping a graphical VT
at VT swap.
Could have fooled me. I can switch between multiple DRI using X
Michel Dnzer wrote:
On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote:
--- Jon Smirl [EMAIL PROTECTED] wrote:
There are two types of VTs - text and graphical. It is only practical to
have a
single graphical VT because of the complexity of state swapping a
graphical VT
at VT swap.
Right now we can
Nicolai Haehnle wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking
whether the caller actually holds the global lock. There is no
LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has
no check in it
Mike Mestnik wrote:
Lets just say that this is good fault tolorance. What ever can go wrong
will, all drivers are faulty. This sounds like a good idea and should be
implemented for ordinary use or something like it.
Unless you thing we should KP on a lock being held for more then a given
time(30
Also, when the VT is switched away from the X server, I believe that the
hardware lock remains grabbed - for minutes or hours at a time.
This is a multi-user OS bug. I'l not even pretend it's a feature that we
should keep.
Just making you aware of the issues.
Keith
André Ventura Lemos wrote:
Not at all...
This only happens with 2.6 kernels. Prior do the lockup, everything
works (I can see it through ssh), but the display gets blank, and never
comes back.
On Fri, 2004-05-21 at 18:07, Keith Whitwell wrote:
Do you mind if I take this to dri-devel?
What happens
Alan Hourihane wrote:
I emailed Keith regarding this a while back and he had some concerns
over the patches used, but I just wanted to bring to light both RedHat
and now Mandrake are shipping with the TLS versions of libGL and cause
the binary DRI packages to break.
Is there someone looking to
Dave Airlie wrote:
It has been pointed out to me by Andrew and Fernando Pablo Lopez-Lezcano
that we do a lot of sleeping in code that probably should reschedule
rather than sleep,radeon_do_wait_for_idle being a prime example, this has
a DRM_UDELAY(1), this messes up audio latencys,
Now I'm not
I don't think this needs to be that complex. We only need a few working
functions in the kernel:
* identification (In particular unique identifier to pass via X to apps
so they can find the head again)
* event reporting (i.e. IRQs and anything else that is relevant)
* mode setting
*
Holger Waechtler wrote:
Keith Whitwell wrote:
I don't think this needs to be that complex. We only need a few
working functions in the kernel:
* identification (In particular unique identifier to pass via X to
apps
so they can find the head again)
* event reporting (i.e. IRQs
As I've said, I don't have a deep grasp of the requirements of a putative
future mode-setting API, but in the course of other reading I came across
MLdc, which is a part of the OpenML environment. This is a library API which
seems to give comprehensive control of mode-setting to an
Jon Smirl wrote:
I'm looking at the OpenML spec and it covers the areas that we have been
discussing plus a lot more. But the Khronos Group doesn't appear to be very Open
Source friendly. It seems that I have to apply for membership and return signed
documents to get a Linux SDK. But some of
Jon Smirl wrote:
I'm looking at the OpenML spec and it covers the areas that we have been
discussing plus a lot more. But the Khronos Group doesn't appear to be very Open
Source friendly. It seems that I have to apply for membership and return signed
documents to get a Linux SDK. But some of
Brian Paul wrote:
I guess I don't feel to strongly about the Mesa bug database. The
SourceForge tracker has been good enough for me but others much prefer
Bugzilla. I could move to Bugzilla if that's the concensus.
Keith?
Bugzilla's certainly the more usable system, but my feelings one way
Ian Romanick wrote:
James Simmons wrote:
1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. (Basic to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I
couldn't never win this
Sottek, Matthew J wrote:
Sottek, Matthew J writes:
I agree. I think we are on the same page. A minimal set of features
is
all that would be part of the defined mode setting API. It is just a
question of if some of the multi-head concepts are generic enough to
be part of that defined set.
That's
Ian Romanick wrote:
Ian Romanick wrote:
The one caveat with this patch is the x86 SSE codegen is disabled
for all TexCoord and MultiTexCoord commands. If you look at the
changes to r200_vtxfmt_c.c, you'll see that I had to make some changes
to the way those routines work.
The previous
Jon Smirl wrote:
--- Jens Owen [EMAIL PROTECTED] wrote:
Six years ago, most devices could not handle this type of restriction
efficiently. Things have improved on the high end; but the low end
devices, are still very similar to what we had back in the day. Even
today, I would be very
Martin Spott wrote:
Vladimir Dergachev wrote:
Also, I would venture an opinion that, at the moment, the only Unices we
care about is Linux, BSD and Hurd - all open source. The current design
of XFree86 (with everything done in userspace) was motivated by the need
to support commercial Unices
Dave Airlie wrote:
In Keiths bunch of changes to make the drivers build in Mesa tree he
changed the i810_dri .h from using drm_+clip_rect_t to XF86DRIClipRectRec,
this break solo, if I change it back it'll probably break dri target...
which is correct?
Well, it depends...
The recent patch
Here's a diff that basically gets all the *_dri.so's compiling in the Mesa tree.
Unfortunately, they don't actually work, but I'm looking into that.
Keith
Index: configs/linux-dri
===
RCS file: /cvs/mesa/Mesa/configs/linux-dri,v
I've committed a patch to allow people to build DRI drivers directly in Mesa
CVS. There are still a couple of gotchas, so I'm going to give some build
instructions here:
1) Update your mesa CVS...
2) Ensure you have a checkout of DRM cvs somewhere.
3) Edit MesaCVS/config/linux-dri to set
Ronny V. Vindenes wrote:
tor, 29.04.2004 kl. 14.59 skrev Keith Whitwell:
I've committed a patch to allow people to build DRI drivers directly in Mesa
CVS. There are still a couple of gotchas, so I'm going to give some build
instructions here:
1) Update your mesa CVS...
2) Ensure you have
Ronny V. Vindenes wrote:
0x002a9579b885 in DoBindContext (dpy=0x5045a0, draw=52428802,
read=52428802, ctx=0x511070, modes=0x50c4d0, psp=0x50ed40)
at dri_util.c:480
480 DRM_SPINLOCK(psp-pSAREA-drawable_lock,
psp-drawLockID);
OK, it looks like there might be some x86_64
Vladimir Dergachev wrote:
Keith - do these drivers work with XFree86 4.4.0, or do they require
something newer ?
Also, if one is starting on a new driver do you recommend using 4.4.0
codebase or something different ? (the simpler the better..)
At the moment, we're trying to get them working at
[EMAIL PROTECTED] wrote:
diff -urN /tmp/wiki.23iQYm/wiki/text/FrontPage /home/groups/d/dr/dri/wiki/text/FrontPage
--- /tmp/wiki.23iQYm/wiki/text/FrontPage 2004-04-25 04:19:27.0 -0700
+++ /home/groups/d/dr/dri/wiki/text/FrontPage 2004-04-27 02:24:02.0 -0700
@@ -49,6 +49,7 @@
*
Ian Romanick wrote:
Keith Whitwell wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
Here's an updated version of the patch. It incorporates most of
Keith's code. It seems to mostly work with 2 exceptions.
- r200PointsBitmap is still broken. I'm not sure what the right way
is going
Andreas Stenglein wrote:
here is a new snapshot for R100 based cards
(only for testing, isn't ready for merging)
It seems to work ok with most apps I tested,
but it doesn't work for yuvrect.
Do we need the _radeon_render_stage or
should the _tnl_render_stage be enough?
_radeon_render_stage is a
I'm still waiting for the request to have both drivers handle interrupts. I'm
sure that will be fun to implement. The correct solution is to take the source
for FB and DRM, copy them to the same directory and edit until everything works
in a single driver. That single driver may end up shipping
jIan Romanick wrote:
Here's an updated version of the patch. It incorporates most of Keith's
code. It seems to mostly work with 2 exceptions.
- r200PointsBitmap is still broken. I'm not sure what the right way is
going to be to fix that.
- Colors are wrong. The cylinder in gloss is
Keith Whitwell wrote:
jIan Romanick wrote:
Here's an updated version of the patch. It incorporates most of
Keith's code. It seems to mostly work with 2 exceptions.
- r200PointsBitmap is still broken. I'm not sure what the right way
is going to be to fix that.
- Colors are wrong
Felix Kühling wrote:
On Tue, 20 Apr 2004 10:46:36 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
[snip]
Right now both your latest patch and my patch seem to be totally hosed.
I haven't changed any of my code since Friday (when it mostly worked),
but there have been some changes since then in
Keith Whitwell wrote:
Ian Romanick wrote:
This is what I have done so far to convert the R200 driver to use
t_vertex. It is only a conversion for SW TCL, and it's not quite
complete. I've managed to clean up all the crashes that I could find,
but I've only tested with gears, geartrain
Andreas Stenglein wrote:
sorry..
I missed to set tcl_mode=0,
so the programs were running in HW-TCL mode.
After setting tcl_mode to 0, glxgears and quake3 didnt work as expected.
Ah gack, my r200 changes haven't been tested for similar reasons...
Keith
Ian Romanick wrote:
This is what I have done so far to convert the R200 driver to use
t_vertex. It is only a conversion for SW TCL, and it's not quite
complete. I've managed to clean up all the crashes that I could find,
but I've only tested with gears, geartrain, and tunnel. There are some
Ian Romanick wrote:
This is what I have done so far to convert the R200 driver to use
t_vertex. It is only a conversion for SW TCL, and it's not quite
complete. I've managed to clean up all the crashes that I could find,
but I've only tested with gears, geartrain, and tunnel. There are some
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
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
OK, I can now build run i830_dri.so from the Mesa tree using 'make linux-dri'.
It's a bit hacked together, but people who are interested should cast their
eyes over:
configs/linux-dri
src/mesa/drivers/dri/Makefile.template
src/mesa/drivers/dri/dri_client/*
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.
Well, I've just committed a 'linux-dri' target which will build currently only
the i830_dri.so
Michel Dnzer wrote:
Does anything speak against repo-moving Makefile.{bsd,linux} to
Makefile?
I can't think of any reason not to.
Keith
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel
ajax wrote:
I've successfully installed the various libraries and modules from DRI CVS on
top of an X.org build, and it appears to work. (No great surprise that
they're binary compatible still, I suppose.) Instructions are on the
Building page on the wiki, along with suitably scary warning
Ian Romanick wrote:
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
Jacek Rosik wrote:
Hi,
For some time i haven't been paying much attention to dri development.
I'm need to do some work now but I'm little lost. From my little
investigation I presume that situation looks more less like this.
* 3d driver development was moved to mesa tree, bu it needs dri tree in
Ian Romanick wrote:
Michel Dnzer 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
Felix Kühling wrote:
Hi,
when linking the radeon and r200 drivers I get these errors:
radeon_vtxtmp_x86.o(.data+0x18c): In function `_x86_Vertex3fv':
: multiple definition of `_x86_Vertex3fv'
../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x80): first defined here
Felix Kühling wrote:
Hi,
in the DRI build system t_vtx_x86_gcc.S ends up being compiled this
command:
gcc -c -o t_vtx_x86_gcc.o t_vtx_x86_gcc.S
The defined like -DUSE_X86_ASM are not there because they are defined as
CFLAGS which are not used for compiling assembler sources files. Because
of the
John Dennis wrote:
Hmm... I can't seem to find a working bugzilla for DRI, instead things
seem to be directed here. I just opened the following bug for xorg, it
fixes various pieces of code that need to set execute permission on data
memory. Some of these are in DRI and Mesa, it would be great if
Ian Romanick wrote:
If the code in t_vtx_x86.c is not built, then t_vtx_x86_gcc.S must not
be built either. The code in the .S references symbols in the .c.
That's why I put the #ifdef around all the code in the .S in version
1.3. I guess my cvs log message wasn't clear enough. :( I'm fixing
Ian Romanick wrote:
Craig Sowadski wrote:
I am getting the following error when trying to run any DRI/GL program
using snapshots staring at with radeon-20040304-linux.i386.tar.bz2
until present:
X Error of failed request: BadValue (integer parameter out of range
for operation)
Major opcode
ajax wrote:
On Tuesday 30 March 2004 16:52, Brian Paul wrote:
CVSROOT:/cvs/mesa
Module name:Mesa
Repository: Mesa/src/mesa/main/
Changes by: [EMAIL PROTECTED] 04/03/30 14:52:00
Log message:
these files now live in the shader directory
Removed files:
301 - 400 of 1368 matches
Mail list logo
