Re: [Dri-devel] xc/xc
Today, Daryll Strauss wrote: On Fri, Apr 20, 2001 at 05:24:37PM +0100, Alan Hourihane wrote: On Fri, Apr 20, 2001 at 05:17:25PM +0100, Philip Willoughby wrote: Is there a good reason for the xc directory nested in the DRI CVS xc directory? I ask because it requires 119Mb of disk space, takes an age to download for new users, and it is not used by `make World' or `make install'. If it is not needed, could it be removed? I think your mistaken. That is THE! DRI tree. There isn't any other. Due to a goof when I first created the project we ended up with two directory levels xc/xc instead of just one. At that point it was difficult enough to fix that we left it that way. Alan's right that xc/xc IS all the DRI code. Errr. What you see doesn't seem to be what I see... After the following command: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri \ update -d xc `ls xc' gives me: CVSLABEL RELNOTES-X.org doc fontsnls util INSTALL-X.org Makefile bug-report exports include programs xc Imakefile RELNOTES config extras lib registry xmakefile and `ls xc/xc' gives me: CVSLABEL RELNOTES-X.org doc include programs INSTALL-X.org Makefile bug-report extras lib registry Imakefile RELNOTES config fonts nls util Further, making a copy of this tree, then running `rm -fr xc/xc ; cd xc ; make World install' gives me a working X server and 3D accelleration on my radeon. I haven't tried `make World' etc. in `xc/xc'. I had assumed that the top-level tree was the one to use since it was the larger of the two, and if that assumption was wrong I'm definitely running the wrong X server aren't I... Anyway, if xc/xc is the one to use, what is all the stuff in xc for - could this be removed if it is not needed (256 megs less would make a big difference on a modem)? Regards, Philip Willoughby -- echo [EMAIL PROTECTED] | tr "bizndfohces" "pwgd9ociaku" ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] xc/xc
Philip Willoughby wrote: Today, Daryll Strauss wrote: On Fri, Apr 20, 2001 at 05:24:37PM +0100, Alan Hourihane wrote: On Fri, Apr 20, 2001 at 05:17:25PM +0100, Philip Willoughby wrote: Is there a good reason for the xc directory nested in the DRI CVS xc directory? I ask because it requires 119Mb of disk space, takes an age to download for new users, and it is not used by `make World' or `make install'. If it is not needed, could it be removed? I think your mistaken. That is THE! DRI tree. There isn't any other. Due to a goof when I first created the project we ended up with two directory levels xc/xc instead of just one. At that point it was difficult enough to fix that we left it that way. Alan's right that xc/xc IS all the DRI code. Errr. What you see doesn't seem to be what I see... After the following command: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri \ update -d xc `ls xc' gives me: CVSLABEL RELNOTES-X.org doc fontsnls util INSTALL-X.org Makefile bug-report exports include programs xc Imakefile RELNOTES config extras lib registry xmakefile I just get: CVS xc and `ls xc/xc' gives me: CVSLABEL RELNOTES-X.org doc include programs INSTALL-X.org Makefile bug-report extras lib registry Imakefile RELNOTES config fonts nls util Further, making a copy of this tree, then running `rm -fr xc/xc ; cd xc ; make World install' gives me a working X server and 3D accelleration on my radeon. I haven't tried `make World' etc. in `xc/xc'. I had assumed that the top-level tree was the one to use since it was the larger of the two, and if that assumption was wrong I'm definitely running the wrong X server aren't I... Anyway, if xc/xc is the one to use, what is all the stuff in xc for - could this be removed if it is not needed (256 megs less would make a big difference on a modem)? You've got something messed up on your end. The upper xc directory should only have CVS/ and xc/ subdirectories. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] MGA on 2.2, backport drm ?
Hi, I have a G450 card at work. Currently I am trying to build the latest drivers into a deb package, which painfully (took me a week :() succeeded. Now I have installed the stuff, and surprise surprise, it does want a new kernel module... 3.0.x, and not 2.0.0. Major trouble, since there is a rule not to switch workstations from 2.2 to 2.4 unless it is stable enough... The new drm code is very 2.4 centric, so I wondered: 1) Are people busy with a 2.2. backport? 2) Is there interest I'm starting with a backport right now, so any hints will be greately appreciated... -- mail up 18+11:13, 4 users, load 0.40, 0.14, 0.08 mistar1 up2+20:37, 8 users, load 2.00, 2.00, 2.00 Let your government know you value your freedom: sign the petition: http://petition.eurolinux.org ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA on 2.2, backport drm ?
On Fri, Apr 20, 2001 at 08:13:34PM +0200, [EMAIL PROTECTED] wrote: Hi, I have a G450 card at work. Currently I am trying to build the latest drivers into a deb package, which painfully (took me a week :() succeeded. Ouch, you're going to be annoyed that you missed this, but .debs are already available[0], still a little rough. (I need to generate the module source packages, and get it building somewhere via cron.) Now I have installed the stuff, and surprise surprise, it does want a new kernel module... 3.0.x, and not 2.0.0. Major trouble, since there is a rule not to switch workstations from 2.2 to 2.4 unless it is stable enough... The new drm code is very 2.4 centric, so I wondered: 1) Are people busy with a 2.2. backport? Not that I know of, sadly. 2) Is there interest Probably quite a bit actually. Zephaniah E. Hull. (Debian developer.) 0: For /etc/apt/sources.list deb http://people.debian.org/~warp/dri/ ./ deb-src http://people.debian.org/~warp/dri/ ./ I'm starting with a backport right now, so any hints will be greately appreciated... -- mail up 18+11:13, 4 users, load 0.40, 0.14, 0.08 mistar1 up2+20:37, 8 users, load 2.00, 2.00, 2.00 Let your government know you value your freedom: sign the petition: http://petition.eurolinux.org ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Never attribute to malice that which can be adequately explained by stupidity" - Hanlon's Razor PGP signature
RE: [Dri-devel] libdrm.a Bugs
Oh, That explains some things. I am not using your cvs as it would be more trouble than it is worth. The XvMC portions are very fresh in the XFree tree and I don't think you've merged them in, so I am using the XFree cvs. However, I also need the latest kernels so my drm sources are from kernel 2.4.3 which apparently is pretty behind for drm sources. I guess I should probably stay with the drm and libdrm from the XFree tree, but since your patches don't always make it over there for a while we end up with periods of time where the drm's from XFree don't work on the latest kernels, and probably your drm's don't work with the latest XFree. It would be nice if there was a published time when you get your sources merged into XFree and it happened on a more frequent basis than just right before an XFree release. XFree at MM/DD/ HH:mm:ss UTC == DRI at the same time. then make sure the merges happen at least monthly so that there isn't so much divergence. Now that XFree has a stable and devel branch there shouldn't be much of an issue getting your head (stable) branch merged on a regular schedule. In fact since XFree has a devel branch I don't really see why your head branch shouldn't _BE_ the XFree devel branch. DRI cvs could just be the various dri development branches, but when something is stable it is merged into XFree cvs and dri users who are not debugging or developing should just be on the XFree devel branch. -Original Message- From: Jeff Hartmann [mailto:[EMAIL PROTECTED]] Sent: Friday, April 20, 2001 8:38 AM To: Sottek, Matthew J Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] libdrm.a Bugs Sottek, Matthew J wrote: All, I'm doing a direct rendered HWMC (XvMC protocol) driver for the i81x, I am compiling the drm Libs outside of the X server and have run into a problem. The current Linux kernel is allocating minor numbers for the device dynamically, but the drm Libs don't seem to have caught up with this idea. Here is the broken scenario: Actually we moved away from using dynamic minor numbers in cvs recently to make the drm more portable. Are you using a recent version of our cvs tree? Or is this based on 4.0.x? The current cvs should use major 226, minor 0 for the first card I believe. -Jeff ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA on 2.2, backport drm ?
On Fri, Apr 20, 2001 at 05:08:20PM -0400, Zephaniah E. Hull wrote: On Fri, Apr 20, 2001 at 08:13:34PM +0200, [EMAIL PROTECTED] wrote: I have a G450 card at work. Currently I am trying to build the latest drivers into a deb package, which painfully (took me a week :() succeeded. Ouch, you're going to be annoyed that you missed this, but .debs are already available[0], still a little rough. (I need to generate the module source packages, and get it building somewhere via cron.) I did not miss it, that is the basis :). There were only so much patches that did not work, and stupid me did it on my workstation (128MB, single ide), instead of the development server (dual smp, 1GB, soft raid 5, 4 disks). Each run takes a considerable amount of time, before finding out something is wrong :( I am not completely apt-get into it ;) Now I have installed the stuff, and surprise surprise, it does want a new kernel module... 3.0.x, and not 2.0.0. Major trouble, since there is a rule not to switch workstations from 2.2 to 2.4 unless it is stable enough... The new drm code is very 2.4 centric, so I wondered: 1) Are people busy with a 2.2. backport? Not that I know of, sadly. 2) Is there interest Probably quite a bit actually. At least by me :) Zephaniah E. Hull. (Debian developer.) Me: debian user ;) 0: For /etc/apt/sources.list deb http://people.debian.org/~warp/dri/ ./ deb-src http://people.debian.org/~warp/dri/ ./ Not up to 18-4 :) Hmmm, if you do the patcheing etc. (which you already do), I do the backport ;) I need at least a .deb package of a stable mga implementation that I can work on. (I mean, the 2d has to work, and it has to have the recent mga rework of gareth). -- mail up 18+14:43, 3 users, load 0.00, 0.02, 0.00 mistar1 up3+00:07, 8 users, load 2.87, 2.77, 2.72 Let your government know you value your freedom: sign the petition: http://petition.eurolinux.org ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI under FreeBSD
Hi! Does DRI work under FreeBSD? Can I compile glide under it (my chip is banshee)? Thanks Simon ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] G400 and blending
On Fri, Apr 20, 2001 at 04:43:55PM -0600, Brian Paul wrote: Pasi Krkkinen wrote: Hello! Are there known blending bugs in the mga-driver (g400)? When I render many additive polygons on the top of each other with small alpha-value (something like 0.05) the result is something it shouldn't be with g400. With software-mesa it's correct as well as with nvidia's drivers. If this is not a known issue, I might do little app that demonstrates this.. I've found that the accuracy of blending isn't always very good on some hardware. Not much can be done about that. -Brian Pasi, does this happen if you're running Windows drivers on the same card? -- -=|JP|=-"I'm not unemployed, my career's just in a holding pattern" Jon Pennington | Debian 2.4 -o) [EMAIL PROTECTED] | Auto Enthusiast/\\ Kansas City, MO, USA| Proud Husband and Father _\_V ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Dri-devel digest, Vol 1 #740 - 15 msgs
From: "John X" [EMAIL PROTECTED]
Subject: [Dri-devel] Radeon SDR provlems fixed (for me at least)
My Radeon SDR is now working perfectly. I haven't yet had a crash or
sonsole corruption (or serious visual glitch) with the radeon-20010418
drivers. uptime is 1 day and 6 hours so far. I had GL demos
(xscreensaver modules) running for an entire night with no problems.
Whatever you guys did to fix the Radeon SDR drivers they work great now.
You guys are great!
I also updated to the CVS veriosn 20010418 and for a while it seemed
really good. gears program was rotating quite long before it hang but in
the end it hang to the
--
radeonWaitForFrameCompletion (rmesa=0x80761e8) at radeon_ioctl.c:402
402 for ( i = 0 ; i 1024 ; i++ ) {
(gdb) p radeon_ioctl.c:400
No symbol "radeon_ioctl" in current context.
(gdb) b radeon_ioctl.c:400
Breakpoint 1 at 0x40509428: file radeon_ioctl.c, line 400.
--
like so many times before :(
--
(gdb) list
395 frame = INREG( RADEON_LAST_FRAME_REG );
396 #endif
397 if ( sarea-last_frame - frame = RADEON_MAX_OUTSTANDING ) {
398 break;
399 }
400 wait++;
401 /* Spin in place a bit so we aren't hammering the bus */
402 for ( i = 0 ; i 1024 ; i++ ) {
403 delay();
404 }
--
This time frame == 3 and does not change and sarea-last_frame == 65002
I was following the INREG() macro and it seems to do some 32bit MMIO?
I'm still clueless as to what causes this. I'm ruling out broken
motherboard since there was never any problems with Voodoo3000 card. Or
could this be that Radeon is not compatible with my mobo? (their customer
support is VERY SLOW). I finally managed to get the board to work somehow
in windows (2000 this time) but it's not stable there either but can't say
is this because of games or what (3DMark2000 goes trough properly). (and
no I'm not overclocking)
--
Janne
echo [EMAIL PROTECTED] | tr acefhiklnptu utpnlkihfeca
___
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
