At this point all the drivers seam to have there own little quirks. The radeon
driver being vary difrent from the rest. The mga driver is missing code like
that of r128_context.c Line 199. I am wondering if we need both Destroy AND
SwapOut, could there not be just a genaric Remove that would de
This function's use is not consistant betwean drivers, I think this code should
change vary littl from driver to driver. I have a fue questions about the use
of DestroyTexObj.
This lookes valid to me. Maby to remove later redundancy this should be in
SwapOutTexObj? Right now this only appers
Minor correction.
Opps: 002
--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> This function's use is not consistant betwean drivers, I think this code
> should
> change vary littl from driver to driver. I have a fue questions about the
> use
> of DestroyTexObj.
>
What dose square of t have to do with falling objects?
It's recursive addition (Multiplication), t * 9.8 = "speed at t".
you might take the root of speed but only to find how long it has been falling
(Incorrect thought because you would also have to account for initial
velocity).
if gravity accel
I have a good start on a Linux DRM update. Alan was right all linux-drm-2.4.0
needed was rming Make.linux Imake mv Make.kernel to Make, theses are a given
for any and Linux DRM update, and *** FIX ME ***
*** removing agpgart dependency on radeon ***
was the only big change I made. Other changes m
--- Jens Owen <[EMAIL PROTECTED]> wrote:
> > Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > *** FIX ME ***
> > *** removing agpgart dependency on radeon ***
> > was the only big change I made.
>
> Was this because the PCI GART functionality was added to
--- Thomas Winischhofer <[EMAIL PROTECTED]> wrote:
> Jens Owen wrote:
> >
> > Mike Mestnik wrote:
> > >
> > > sis renamed to i830 (or one was removed and the other added),
> >
> > I recommend leaving the SiS support in the kernel, for now.
It lookes like there is some one making changes that I think we should be aware
of. This could be something done by the back-port project. In any case it
looks like this should be put into the CVS, if not all ready there. I'm going
to start pruning my patch of things that get removed, and keepin
--- Jens Owen <[EMAIL PROTECTED]> wrote:
> Finally, it looks like it would also be a good idea to review and
> possibly move the kernel development changes back into our repository.
> Specifically, I'm talking about changes to the schedule wait queses as
> were done to drm_fops.h; changes to the
For the Radeon7500 I'm using the tcl-0-0-branch, I can't even get GATOS to
build. There is several modifications in the tcl branch I don't know if I can
just merge, Replace things like radeon_drm.c(fron the GATOS CVS) with the one
fron the tcl-0-0-branch.
I'd be happy to get serious and start re
--- Micah Galizia <[EMAIL PROTECTED]> wrote:
> No. I couldn't get it to compile under 2.4, but I think I was compiling
> against 2.5 headers. More importantly, where should I be getting source
> from? The source code at http://www.xfree86.org/~alanh/ is 1.1.1; Is
> that right?
That is the
--- Micah Galizia <[EMAIL PROTECTED]> wrote:
> Which source should i be modifying. The source available online at
> http://www.xfree86.org/~alanh/ has radeon 1.1.1; however, when I made my
> patch, it was against 1.2.0. I'm a little confused!
>
> Micah
>
I don't think at this time it would
Using the following code in lib/GL/mesa/src/drv/radeon_ioctl.c
static int radeonWaitForFrameCompletion( radeonContextPtr rmesa )
{
unsigned char *RADEONMMIO = rmesa->radeonScreen->mmio.map;
RADEONSAREAPrivPtr sarea = rmesa->sarea;
CARD32 max_outstanding;
int wait = 0;
max_outstand
--- Michael <[EMAIL PROTECTED]> wrote:
> What is the problem you're trying to fix?
>
> --
> Michael.
"Incroment 2Was Not Idle!"
See how the fprintf call was interupted.
I found ought after some testing that there is a set amount of bytes that can
be put into the buffer. Being less verbose fix
--- Michael <[EMAIL PROTECTED]> wrote:
> Can we repair the damage? That doesn't seem to have been that successful
> in the past in terms of recovery / carrying on running the 3d app -
> others have more knowledge here. If anything, cleanly exiting from 3d
> and, if recovery is possible or the 2d
--- Jens Owen <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
> >
> > --- Michael <[EMAIL PROTECTED]> wrote:
> > > Can we repair the damage? That doesn't seem to have been that successful
> > > in the past in terms of recovery / carrying on run
I was going to CC Ian but coulden't get his address.
--- Jacek Pop³awski <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 07, 2002 at 09:42:22AM -0400, Al Tobey wrote:
> > I don't forsee a big problem performance wise if the textures are mangled
> > during the loading stage, but I'm still learning ...
>
--- Jacek Pop³awski <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 09, 2002 at 12:11:58AM -0700, Mike Mestnik wrote:
> > Are there any cards or drivers that actually upload textures every frame?
>
> I don't know any technical details, but AFAIK some emulators (snes9x? xmame?
--- Michael <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 09, 2002 at 01:59:52AM -0700, Mike Mestnik wrote:
> > --- Jacek Pop?awski <[EMAIL PROTECTED]> wrote:
> > > On Sun, Jun 09, 2002 at 12:11:58AM -0700, Mike Mestnik wrote:
> > > > Are there any cards or d
--- Leif Delgass <[EMAIL PROTECTED]> wrote:
> On Sun, 9 Jun 2002, Michael wrote:
>
> > On Sun, Jun 09, 2002 at 12:11:58AM -0700, Mike Mestnik wrote:
> > > --- Jacek Pop?awski <[EMAIL PROTECTED]> wrote:
> > > > On Fri, Jun 07, 2002 at 09:42:22AM -040
--- José Fonseca <[EMAIL PROTECTED]> wrote:
> On 2002.06.12 18:49 Keith Whitwell wrote:
> > ...
> >
>
> I totally disagree here...
>
> >
> > That class of power users haven't really emerged, if anything it is the
> > power users who are crying for help in the blackness of dri-users, as
> >
--- David Willmore <[EMAIL PROTECTED]> wrote:
>
> > Keith Whitwell wrote:
> > OK, maybe I'm getting carried away.
> >
> > But as I see it, there aren't many people in total on dri_devel+dri_users.
> > The only people who can really answer dri_users questions are on dri_devel
> > anyway. Why h
--- Alan Hourihane <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 13, 2002 at 09:38:48AM -0700, Linus Torvalds wrote:
> > On a separate topic - have you guys thought about replacing the user
> > mailing list with a real newsgroup? Yes, newsgroups are noisy as hell, but
> > they are also fairly easy to b
Also you might want to know that I had problems getting the wrong kernel
headers under woody. It seams that 'as explained in the docs for
kernel-header-*' the debian headers may not be the same as the kernel headers.
If you compile a kernel module ought side the kernel tree it's doomed to get
th
I did some digging.
CONFIG_RWSEM_GENERIC_SPINLOCK is not set.
This causes thoes unresolved symbols, YOU CANT HAVE THOES :)
There seams to be only one reason why CONFIG_RWSEM_GENERIC_SPINLOCK dose not
get set.
CONFIG_M386 must be set to "y", then CONFIG_RWSEM_GENERIC_SPINLOCK is set to
"y" else i
t_rwsem
>
> and i got no idea what those means!, please keep in mind that i don't know
> C, so you are telling me i should depmod -a radeon.o and it will work?
>
> >From: Mike Mestnik <[EMAIL PROTECTED]>
> >To: Digital Net Assassin <[EMAIL PROTECTED]>
I'm running Debian(Linux) Woody and I just built the bsd-3-0-0 branch and it workes on
my Radeon
7500 QW.
--- Jens Owen <[EMAIL PROTECTED]> wrote:
> Eric Anholt wrote:
>
>
> > Concerns at this point:
> > - I'm still noticing some problems with my Radeon 7500 with DRI (the
> > last lockup was d
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2002-07-08 at 20:17, Tim Smith wrote:
> > On Monday 08 Jul 2002 12:49 am, Michel Dänzer scribed numinously:"
> >
> > > The scratch register values need to be read with DRM_READ32(), which
> > > accounts both for endianness and memory barrier
--- Eric Anholt <[EMAIL PROTECTED]> wrote:
> Currently running Linux GL programs on FreeBSD doesn't work for most
> people because xf86drm.c checks to see if the dri device has the major
> number expected. When using linux *_dri.so's (which use this code) they
> find the FreeBSD dri device, whic
--- Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Tue, 2002-07-09 at 15:04, Mike Mestnik wrote:
> > I'm using the new linux devfs and It seams to me that the DRI can't at this time
>use devfs the
> way
> > it should. If i'm not mistaken the kernel module
--- Alexander Stohr <[EMAIL PROTECTED]> wrote:
> > I'm planing on
> > having DRISUP_BOTH, DRISUP_BSD, DRISUP_LINUX, DRISUP_NONE
> > defined for the 3rd element.
>
> I dont like the "both" thing. The design looks for me rather
> like a bitfild than an enum... so this would be the solution:
>
ID_3DFX 0x121A
-#endif
-#ifndef PCI_DEVICE_ID_3DFX_VOODOO5
-#define PCI_DEVICE_ID_3DFX_VOODOO5 0x0009
-#endif
-#ifndef PCI_DEVICE_ID_3DFX_VOODOO4
-#define PCI_DEVICE_ID_3DFX_VOODOO4 0x0007
-#endif
-#ifndef PCI_DEVICE_ID_3DFX_VOODOO3_3000 /* Voodoo3 3000 */
-#define PCI_DEVICE_ID_3DFX_VOODOO3_3000 0x
It seams that pci_find_device, that DRI uses, has been replaced. This really doesn't
affect DRI
but it's new and the Linux driver would more closely resemble the BSD one once were
doing things
the new way. Also this will pave the road for my next big idea, changing the card%d
device names
to
Yes, I had a simular problem, rebooted and every thing was fine.
I got my kernel mod from cvs (and patched it heavily to support devfs) then I got the
rest of DRM
from http://dri.sourceforge.net/snapshots/radeon-20020710-linux.i386.tar.bz2 I have a
7500 QW
though.
I'l get my 8500 ought of that
#
# List of PCI ID's
#
# Maintained by Martin Mares <[EMAIL PROTECTED]> and other volunteers from the
# Linux PCI ID's Project at http://pciids.sf.net/. New data are always
# welcome (if they are accurate), we're eagerly expecting new entries,
# so if you have anythin
If you man ascii, which on a hunch I did, you will find that...
Hex Char
51Q
57W
4CL
45E
Hence QW 0x5157, QL 0x514C, and the LE would have Product ID 0x4C45 this product ID is
not on
file.
I'll look into why the Xserver it equating 0x4C45 to 0x5157. I was working on having
th
Ok the patch is atttached, you have what we call a "Mach64 LB" or PCI_CHIP_MACH64LB.
In order to use this patch you'l need to build from source.
--- Shan Mignot <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've recently downloaded the dri package
> (mach64-20020705-linux.i386.tar.bz2) for the mach64 ch
I have some new information on this, I built the r200 branch and it stalls on like 330
of
radeon_accel.c, I'm assuming it was the call to EngineReset came from EngineInit
because the last
thing printed(I even sync'ed) is Silken Mouse.
I'm going to try mindlessly disabling code from that functio
This worked for me, but my Radeon 7500 QL is ok with Fast Writes.
What dose this do, just curious?
--- Michal Kozlowski <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> Thanks to the help of Stefan and others I got my r200 to work, from
> Stefans lspci logs I was able to figure out why I lost my s
As a user, and maby as root, Running X (via xinit ./quake3 -- -layout GLLayout), then
closing X,
Waiting for rmmor -k to remove agpgart (and radeon, above agpgart), and typing X.
Will allways
display some garbeg, then a hafway completed Xmesh, then My old background.
_
The install.sh, included with the snapshots,(and make -f Makefile.linux) has allays
built modules
that insmod fine, even print every thing and rmmod, but they don't let X setunique.
getunique
worked fine. The error I get from an strace is no access, when calling the setunique
ioctl.
If I bui
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Michal Kozlowski wrote:
> > On Thu, 11 Jul 2002, Stefan Lange wrote:
> >
> >
> >>compiling from cvs shouldn't be a problem, I just followed the DRI
> >>Compilation Guide from the website and everything went fine (you might
> >>have to compile the
--- Daniel Kasak <[EMAIL PROTECTED]> wrote:
> Marc Poulhiès wrote:
>
> >I know that closed source drivers from ati are not discussed here, but
> >with my radeon 8500 and tribes2 i have exactly the same probleme.
> >Maybe this is a probleme from tribes2 and not the dri :)
> >
> >
> Maybe. But it
There are a number of conditions that I know of that requirer a reboot, thought I
don't know the
cause.
1. When changing from dri to binary nvidia drivers, apps fail to use the new libGLs.
Ldconfig is
not enuf and a reboot may be needed. This was reproducible, and I could not get libGL
to bi
lude "radeon_drv.h"
#include "ati_pcigart.h"
diff -aNur orig/linux/drm/kernel/drm_sup.h myne/linux/drm/kernel/drm_sup.h
--- orig/linux/drm/kernel/drm_sup.h Wed Dec 31 18:00:00 1969
+++ myne/linux/drm/kernel/drm_sup.h Wed Jul 10 05:57:32 2002
@@ -0,0 +1,25 @@
+/* dr
Opps, forgot to say, this patch is fully functional but incomplete. It still needs
PCI ids,
however this is only needed if you have more than one card.
--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> From: Mike Mestnik <[EMAIL PROTECTED]>
> To: "lists.sourceforge
8500, that needs Fast Write to be off.
Thank you for your help, thought I can live with my agpgart static. It's only the DRI
modules that
are so big thay NEED to be unloaded. IMO
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Fri, 2002-07-12 at 01:35, Mike Mestnik wrote:
> &g
ruct?
--- Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Sun, 2002-07-14 at 21:33, Mike Mestnik wrote:
> > I patched my devfs patch so it can be used with the r200 branch. This was needed
>b/c my
> original
> > patch depended upon the shared structure introduced for BSD.
I built with -O3 -march=athlon, thought I'v been doing that for some time now.
ddd reports the segfalut during the pushl of the fd, just befor calling
drmCommandWriteRead.
Dump of assembler code for function r200InitIoctlFuncs:
0x4054eba0 :push %ebp
0x4054eba1 : mov%es
With my Radeon 8500 64M running CVS Head 20020928. I get 200FPS and 225FPS when
moving the moues
/w gears. I also get some jerking(Walls will move back and forth) when moving the
mouse(Turning)
and strafing in Quake3.
__
Do you Yahoo!?
New DSL
SHORT strace dump of glxinfo...
664 write(1, "name of display: :3.0\n", 22) = 22 <<<=== Every thing is hunky dory.
664 writev(3, [{"b\0\3\0\3\0\0\0", 8}, {"GLX", 3}, {"\0", 1}], 3) = 12
664 read(3, "\1\0\7\0\0\0\0\0\1\222S\262\0\0\0\0\1\0\0\0\0\0\0\0\310"..., 32)$
664 brk(0x8056000)
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-08-27 at 18:43, Mike Mestnik wrote:
> > I have something to add to this. Recently I tested gatos drivers going
> > from dri to gatos was painless. However when I went back my computer
> > locked up.
&g
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sat, 2003-08-30 at 18:27, Mike Mestnik wrote:
> > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2003-08-27 at 18:43, Mike Mestnik wrote:
> > > > I have something to add to this. Recently I te
Xfree86 date in radeon_driver.c) copy of DRI and see if there is a smaller change set.
I was
looking at a unified diff /w 42000+ lines. From the gatos web page I can only find
Xdrivers and a
kernel mod, and no GLlib.
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
>
Hello Laurent,
The main goal is to get a working DRI that has the new API, and maby some gatos bells
and
whistles. I'm assuming you read my post that recent DRI is to different from gatos.
My plan was
to diff gatos and DRI and weed ought all the changes that where depreciated. With
that patc
I just updated CVS and patched in
http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/mergedfb-dri.diff
Most everything that warked b4 still workes, there is a small problem with quake3.
Small meaning
not ought of the ordinary for DRICVS, things like textures on the floor appere to be
behi
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Fri, 2003-10-17 at 02:36, Roland Scheidegger wrote:
> > Keith Whitwell wrote:
> > > Alex Deucher wrote:
> > >
> > >> As I recall KDE preloads libGL for some reason. that might have
> > >> something to do with it.
> > >
> > > If you make sure tha
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Fri, 17 Oct 2003 12:10:05 -0700 (PDT)
> Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> > you need to change the DRI config settings:
> >
> > http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure
> >
> > perhaps we shouldn't make s
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Fri, 2003-10-17 at 02:36, Roland Scheidegger wrote:
> > Keith Whitwell wrote:
> > Well, I've never tried to install the whole XFree86 when it's running,
> > but I'm often lazy and just compile the mesa/src/drv/r200 if only small
> > changes happen a
I am, posted Oct 22, 8:14PM CST
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> Is anyone else getting every meesage that is sent to dri-devel twice or
> sometimes even 3 or 4 times? It just started happening over the last
> couple days.
>
> Alex
>
> __
> Do you Ya
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
>
> > On Wed, 29 Oct 2003 08:56:09 -0800
> > Ian Romanick <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Felix Kühling wrote:
> >>
> >>
> >>>I've been thinking about ways to implement a combined "wait for vblank
> >>>and buffer swap" ope
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Fri, 2003-11-07 at 23:05, Andrew Morton wrote:
> >
> > Has anyone actually tested the functionality which this patch is supposed
> > to provide? That loading the DRM module magically triggers a load of AGP?
>
> Haven't tried it, but I doubt it
ssh uses IP4:127.0.0.1, and as many times as ppl have asked for unix socket support it
has allways
been denied. -nolisten tcp is something for the distros to set up, it should be
*usable by
default.
* Meaning all non-devel features on and nothing extra for the user to do.
--- Keith Whitwell <[
This is a MFB problem, I think.
I had just setup gamecon for my nintendo controlers and wanted a fullscreen
experiance. I'm told
I want "[EMAIL PROTECTED]" for the best view. I also want to be able to use my other
head for normal
things. I have a radeon8900. I hooked my Xconfig up with a goo
to
> crtc1. what do you mean by "backwards?" also for mergedfb to use
> modes they have to be listed in the screen section of your config. if
> you are looking for two separate heads (ie, host:0.0 and host:0.1) you
> can't use mergedfb. mergedfb only provides a single
I get it too, maby letters and then numbers if it's not just anyone /w yahoo.
--- Alexander Stohr <[EMAIL PROTECTED]> wrote:
> you were the only one that hit those problem.
> i only have the very same problem report.
> the rest is driven by source forge internals.
>
> maybe its the yahoo origin p
Any way it's gone now, the world may never know.
--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> I get it too, maby letters and then numbers if it's not just anyone /w yahoo.
>
> --- Alexander Stohr <[EMAIL PROTECTED]> wrote:
> > you were the only one that h
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Fri, 2003-11-21 at 21:58, Mike Mestnik wrote:
> > I don't expect GL apps to know what ProjectRoot is set to, would thay be able
> > to find the right client side driver?
>
> All you have to do is install the one
Not at this time, however the work around I have been using is setting up more than
one layout in
my XF86Config. Then I write scripts for common apps/tasks that call the right
xSession and
layout.
I had a dream that apps would be free from persecution of color depth and of
screen/root
number/s
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > The screen size(in pixels or mm) is now x1 + x2 by (y1 > y2) * y1 +
> > (y1 < y2) * y2. Swap (y and
> > x) and (1 and 2) where needed. Then the DPI sho
lspci -vvv
--- Chris Ison <[EMAIL PROTECTED]> wrote:
> After a couple of kernel recompiles I got oprofile to work, and it was
> reporting that most of its time was spend in default_idle for both
> glxgears and qw-client-glx (from QuakeForge CVS).
>
> After speaking to one of the oprofile ppl, the
t;[EMAIL PROTECTED]> wrote:
> On Sat, 2003-12-06 at 07:57, Mike Mestnik wrote:
> > lspci -vvv
> >
> That just tells me the card is capable of using it, doesn't actually
> tell my if DRI is taking advantage of it.
>
> With and without DRI installed it tells me the s
I'm trying to build mach64-0-0-6-branch on my sparc. I'm building on Debian
sid/sarge. In the
mesa building I get this...
make[6]: Entering directory `/root/xfree86/xc-current/lib/GL/mesa/src/SPARC'
rm -f xform.i
/usr/bin/cpp -Dlinux -D__sparc__ -D_POSIX_C_SOURCE=199309L
Not that I know of.
--- Adam K Kirchhoff <[EMAIL PROTECTED]> wrote:
>
> Mike,
>
> Have there been any changes to the status of the "off-by-one"
> problem (ie, 3d rendering works only for apps that don't extend beyond
> that 2047th pixel)?
>
> Adam
>
__
D
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into Br
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into Br
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into Br
s like that can be overcome, application hotkey to run xset for example.
Must CC me in reply.
--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> Date: Sun, 18 Jan 2004 10:10:28 -0800 (PST)
> From: Mike Mestnik <[EMAIL PROTECTED]>
> Subject: driconfig: TMU(s) and s3tc.
> To: &q
--- Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> copy&paste job, I didn't touch anything in the code at all (except
> replacing "r200" with "radeon" a couple of times...). That said, I
I'v heard this alot so I just thought I'd say even thought it's not my place. Don't
you think it
would be
I'm no expert, but with mtex dose more TMUs help?
If so you should try with the patch, I have had 6 enabled with no problems or use.
Also how can I help get this patch commited? I can run test programs.
The patch should be in list arcives dated...
Sat, 3 Jan 2004 00:30:35 +0100
Sun, 4 Jan 2004 1
Three things I don't know are.
1. What needs to be donated so IP issues are paid for?
2. Can programs like UT200? contain there own decompressor for software fallbacks?
3. Has there been any contact from S3?
It's not my intention to flame, don't bother if all you can say in response is NO.
3a.
I have a UltraSparc5 with an onboard Rage3D, workes with the mach64
driver. There are some problems with the kernel and PCI domains, but I
got thoes cleared out. There is still a problem that the chip is stuck in
whaterver mode is set by openboot(the bios), but I can change the bit
depth. Other
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-02-16 at 21:14, Mike Mestnik wrote:
> > [...] Other than that and endianess and byte size issues is there any
> > thing else that might not work?
>
> FWIW, people have been running Mach64 DRI on PPC for a whi
ister pseudo-op
../../../../lib/GL/mesa/sparc/xform.S:30: Error: detected global register
use not covered by .register pseudo-op
../../../../lib/GL/mesa/sparc/xform.S:30: Error: detected global register
use not covered by .register pseudo-op
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
>
I was building mach64 drm for 2.6.3. I had the worst time convincing
Makefile.linux and inturn Makefile.kernel that it was not lessthan25 and
lessthan2552. I finaly gave up once I saw I had to gointo all the .h and
.c files and add #defines there as well. Also I don't have a mach64 pro
so I gues
EMAIL PROTECTED]> wrote:
> On Sun, 7 Mar 2004 04:08:11 -0800 (PST)
> Mike Mestnik <[EMAIL PROTECTED]> wrote:
>
> > I was building mach64 drm for 2.6.3. I had the worst time convincing
> > Makefile.linux and inturn Makefile.kernel that it was not lessthan25
> and
>
This seams like a no brainer to me. The Xserver! It would be a good
place to intercept vblanks, if it dosen't allready, and connects to
clients and card any way. A little more beef for the "?2d driver? or X
server" to keep track of pending swaps for all dri clients, but if it were
GLX it would b
Dose most DACs have dublebuffering or do you realy only have from the
start of the vtrace to the end to do your update? If you can having from
the start of the vtrace untill the end of the next vtrace todo your
swaping is optimal.
- If you only have one FB. Pad each, or some, commands with enuff
At first I thought it just might have been my system. In debuging the
problem I found ought that my chip dose not have triangle setup. It's not
likely that it will be supported by DRI. However the 2d driver gave me
xrendr support, this will help with TV out for me.
As for the kmod if you post t
;t
> have the triangle engine really..
>
> Dave.
>
> On Thu, 11 Mar 2004, Mike Mestnik wrote:
>
> > At first I thought it just might have been my system. In debuging the
> > problem I found ought that my chip dose not have triangle setup. It's
> not
> > like
Just a side note, is the history of these files needed in the mesa tree?
I would think it would only be uasable in the DRI tree and it's archived
there so no need to duplicate that.
The DRM is another storry, ppl may wish to build older versions from the
new module.
--- Michel Dänzer <[EMAIL PRO
This is nothing more than a HUNK fixed copy of the TVOut patch found on
leif's linux page. With this patch the TVOut and other related options
are evaluated and it is posible to use atitvout while in X. However I
notesed some problems with this patch that only a reboot would fix. There
was corup
ing it can do VBE calles.
--- Anish Mistry <[EMAIL PROTECTED]> wrote:
> On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote:
> > This is nothing more than a HUNK fixed copy of the TVOut patch found
> on
> > leif's linux page. With this patch the TVOut and other relate
3 patch later this week to see if I can get it
> to
> work. Have you tried to email Leif I did last week, but got no
> response.
> > --- Anish Mistry <[EMAIL PROTECTED]> wrote:
> > > On Tuesday 23 March 2004 05:16 am, Mike Mestnik wrote:
> > > > This i
I have seen this also on my laptop(mach64) and my desktop(radeon). It
just started happining recently.
--- Daniele Boffi <[EMAIL PROTECTED]> wrote:
> At the beginning I thought is was a hardware problem, even if it started
> immediately after I upgraded to CVS radeon driver. But then, I noticed
>
--- 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
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
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
I was under the impresion that several bugs where found in 4.3.99.902 that
need patching. This work has allready been done twice I shuder to think
any one would bother a third.
--- Alan Hourihane <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 15, 2004 at 08:13:53AM -0700, Alex Deucher wrote:
> > Speaki
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-04-16 at 23:02, Nathanael Nerode wrote:
> > Michel Dänzer wrote:
> > > 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.
> > >
>
1 - 100 of 266 matches
Mail list logo
