[Dri-devel] Software rendering and ReadBuffer (was: mach64 testing - xor logicop)
On Tue, 2 Jul 2002, Graham Hay wrote: [...] > I did find a problem running an OpenGL app I wrote for work. > It seems that when I use the XOR logic op for rubber > banded lines/rectangles that it doesn't erase the previously > drawn pixels. They get set to something which looks like an > XOR would, but it stays that way. Maybe the logic op is set > wrong? OK, I've identified the problem here. It seems that the Mesa software rasterizer is reading from the BACK buffer instead of the current DrawBuffer (the FRONT). Using glDrawBuffer(GL_FRONT_AND_BACK) produces the correct result without swapping buffers. Normally, I think the software rendering code should switch to read from the current draw buffer and then restore the context's original ReadBuffer state. This turns out to be the same problem with blending textures rendered in software with the framebuffer in the Mesa texenv demo in front-buffer mode. I tested this by making the driver always read from the draw buffer in the span functions, and it fixed the problem. What I haven't figured out yet is whether the problem is in the driver or the Mesa software rendering functions. The mach64 driver has SetReadBuffer and SetDrawBuffer functions that look like the other drivers. I did confirm that the Rage 128 driver has the same problem with the texenv demo for the GL_BLEND texture environment when there is an environment color (the transparent texture areas are blended against the black of the back buffer instead of the checkerboard in the front buffer -- this is with the background toggled off in the demo). It seems that the Mesa software rendering functions for logic ops and blending in these cases aren't calling the driver's SetReadBuffer function to match the context's DrawBuffer (I put a debug message in the SetReaderBuffer function and it wasn't called). So, when the driver's templated ReadSpan/ReadPixels functions are called, they are reading from the wrong buffer. However, calling glReadBuffer followed by glReadPixels in a GL program _does_ show the SetReadBuffer function being called. Anyone have any ideas? > I wrote a smaller test program for this in C which you can > find here: > > http://www.tardis.ed.ac.uk/~gnh/mach64/xor_test.c > > It should show you what I'm talking about. Also, when the > window first pops up the glClear isn't coincident with the > top left of the window as if the viewport wasn't right, > although the rectangle is in the right place. Another > clear via expose does affect the whole window, but if I > put the window half off screen and drag it back into the > middle, only parts of it are cleared. This clear problem should be fixed in the current cvs. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
Oliver Feiler wrote: > On Saturday 06 July 2002 23:11, Keith Whitwell wrote: > >>Jens Owen wrote: >> >>>Oliver Feiler wrote: >>> On Saturday 06 July 2002 17:36, Oliver Feiler wrote: >On Friday 05 July 2002 13:04, José Fonseca wrote: > >>Keith Whitwell confirmed the readiness of the r200-0-1-branch for >>testing and for binary snapshots. >> >Just tested this driver on a system with original ATI 8500 card. > >With the binary snaphots and with the r200 branch compiled myself the >system crashes immediately when X is started. With DRI disabled X >comes up >and runs without problems. > >>>Oliver, >>> >>>If you have the room for a fully debuggable X Server, try adding this >>>patch before you build the X Server. >>> >>>Then login remotely and run gdb xc/programs/Xserver/XFree86 as root. >>> >>>If you can case the crash like that, post the backtrace to the list. >>> >>>Regards, >>>Jens >>> >>This works if it is a crash, but not if it is a lockup where the system >>freezes overall -- I don't know which Oliver is experiencing... >> > > I will try that later (or tomorrow) when I have access to that computer again. > Unfortunately it's not mine. :) > > All I can say about this crash now is that the system just locks up. The > screen goes black and that's it. I cannot ping the system anymore. I will > still try what Jens suggested, maybe I can get some useful information. As Keith said, this won't help much if your system is hanging. You can carefully crawl up to the edge of the cliff, but you don't know where the edge is :-) Each time you fall, you need to reboot and possibly fsck depending on your file system. Perhaps it's better for you to wait until the driver is more stable. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
Oliver Feiler wrote: > On Saturday 06 July 2002 17:36, Oliver Feiler wrote: > >>On Friday 05 July 2002 13:04, José Fonseca wrote: >> >>>Keith Whitwell confirmed the readiness of the r200-0-1-branch for >>>testing and for binary snapshots. >>> >>Just tested this driver on a system with original ATI 8500 card. >> >>With the binary snaphots and with the r200 branch compiled myself the >>system crashes immediately when X is started. With DRI disabled X comes up >>and runs without problems. >> >>I don't really know how to get more information from X. There are no syslog >>entries and nothing in XFree.0.log. I started X via remote ssh to see X's >>output, but it stops after printing the first few lines so there is nothing >>useful there as well. That's all informtation I can give unfortunately. >> >>Summary: it crashes. ;) >> > > Erm, maybe I should add: the system is a VIA KT333 board, Athlon XP 1800. > Kernel is 2.4.19-rc1 with agpgart compiled in. > > The ATI firegl drivers worked, btw. > > I think you've got to look at things like agp mode, fast writes, etc. The 8500 has the same 2d component as the 7500, so it's suprising to get a crash so early. What version of XFree did you install on top of? Keith --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
On Saturday 06 July 2002 23:11, Keith Whitwell wrote: > Jens Owen wrote: > > Oliver Feiler wrote: > >> On Saturday 06 July 2002 17:36, Oliver Feiler wrote: > >>> On Friday 05 July 2002 13:04, José Fonseca wrote: > Keith Whitwell confirmed the readiness of the r200-0-1-branch for > testing and for binary snapshots. > >>> > >>> Just tested this driver on a system with original ATI 8500 card. > >>> > >>> With the binary snaphots and with the r200 branch compiled myself the > >>> system crashes immediately when X is started. With DRI disabled X > >>> comes up > >>> and runs without problems. > > > > Oliver, > > > > If you have the room for a fully debuggable X Server, try adding this > > patch before you build the X Server. > > > > Then login remotely and run gdb xc/programs/Xserver/XFree86 as root. > > > > If you can case the crash like that, post the backtrace to the list. > > > > Regards, > > Jens > > This works if it is a crash, but not if it is a lockup where the system > freezes overall -- I don't know which Oliver is experiencing... I will try that later (or tomorrow) when I have access to that computer again. Unfortunately it's not mine. :) All I can say about this crash now is that the system just locks up. The screen goes black and that's it. I cannot ping the system anymore. I will still try what Jens suggested, maybe I can get some useful information. Bye -- Oliver Feiler http://www.lionking.org/~kiza/ <-- homepage PGP-key ID 0x561D4FD2--> /pgpkey.shtml --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Argggg so close with S3 Virge/MX, yet so far...
On Saturday 06 July 2002 20:38, David Willmore wrote: > Well, I've been waiting what seems like forever for a driver > for my laptop and now there is one! What a happy day! One > problem, it's an older Compaq laptop and uses a propriatary > chipset (and AGP bridge) so no AGPGART. *do-oh* > > Noone happens to have a AGPGART for it hiding somewhere, do > they? Concacts with Compaq they could twig? This laptop > was retied over a year ago (by compaq support), so they shouldn't > be all to concerned that any competetive information escape > by coughing up the specs for it, one would think. > > Suggestions, anyone? Have you tried with AGPGART "options agpgart agp_try_unsupported=1"? -Dieter --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
Jens Owen wrote: > Oliver Feiler wrote: > >> On Saturday 06 July 2002 17:36, Oliver Feiler wrote: >> >>> On Friday 05 July 2002 13:04, José Fonseca wrote: >>> Keith Whitwell confirmed the readiness of the r200-0-1-branch for testing and for binary snapshots. >>> Just tested this driver on a system with original ATI 8500 card. >>> >>> With the binary snaphots and with the r200 branch compiled myself the >>> system crashes immediately when X is started. With DRI disabled X >>> comes up >>> and runs without problems. >> > > > Oliver, > > If you have the room for a fully debuggable X Server, try adding this > patch before you build the X Server. > > Then login remotely and run gdb xc/programs/Xserver/XFree86 as root. > > If you can case the crash like that, post the backtrace to the list. > > Regards, > Jens This works if it is a crash, but not if it is a lockup where the system freezes overall -- I don't know which Oliver is experiencing... Keith --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
Oliver Feiler wrote: > On Saturday 06 July 2002 17:36, Oliver Feiler wrote: > >>On Friday 05 July 2002 13:04, José Fonseca wrote: >> >>>Keith Whitwell confirmed the readiness of the r200-0-1-branch for >>>testing and for binary snapshots. >>> >>Just tested this driver on a system with original ATI 8500 card. >> >>With the binary snaphots and with the r200 branch compiled myself the >>system crashes immediately when X is started. With DRI disabled X comes up >>and runs without problems. Oliver, If you have the room for a fully debuggable X Server, try adding this patch before you build the X Server. Then login remotely and run gdb xc/programs/Xserver/XFree86 as root. If you can case the crash like that, post the backtrace to the list. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- xc/config/cf/host.def.jens Tue Jun 4 16:32:56 2002 +++ xc/config/cf/host.def Tue Jul 6 13:43:29 2002 @@ -55,7 +55,7 @@ /* #define GlxBuiltInMga YES */ /* #define GlxBuiltInR128 YES */ /* #define GlxBuiltInRadeon YES */ -/* #define DoLoadableServer NO */ +#define DoLoadableServer NO /* Optionally turn this on to change the place where you install the build. * Warning: trailing blanks will cause build failures.
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote:
> Jens,
>
> This works after fixing one thing in this section from DRICloseScreen:
>
> if (pDRIPriv->wrap.AdjustFrame) {
> - ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
> - pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
> - pDRIPriv->wrap.AdjustFrame = NULL;
> + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
> + pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
> + pScrn->AdjustFrame = NULL;
> ^^
> }
>
> That last line should change from:
>
>pScrn->AdjustFrame = NULL;
>
> to:
>
>pDRIPriv->wrap.AdjustFrame = NULL;
>
> This is line 452 in the patched dri.c. Other than that it looks good.
Leif,
As you can probably tell by now, I'm not able to test this path. I've
tried on the Radeon driver, but it, like most drivers has a lot of
failure cases that don't appear to be working properly. What does work
is when the DRI comes up cleanly, or when hitting one of the early
fairly cases...lack of AGP, etc. However, if I force a failure in
RADEONDRIFinishScreenInit, which is after most of the DRI resources have
been setup, I can hang the system.
The fact that you are exercising these paths in the mach64 driver is a
good thing.
I made your change to my last patch and have checked it into the trunk.
Regards,
Jens
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
---
This sf.net email is sponsored by:ThinkGeek
Got root? We do.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Argggg so close with S3 Virge/MX, yet so far...
On Sat, Jul 06, 2002 at 01:38:06PM -0500, David Willmore wrote: > >Well, I've been waiting what seems like forever for a driver >for my laptop and now there is one! What a happy day! One >problem, it's an older Compaq laptop and uses a propriatary >chipset (and AGP bridge) so no AGPGART. *do-oh* > Ouch! :O >Noone happens to have a AGPGART for it hiding somewhere, do >they? Concacts with Compaq they could twig? This laptop >was retied over a year ago (by compaq support), so they shouldn't >be all to concerned that any competetive information escape >by coughing up the specs for it, one would think. Compaq now belongs to HP which as been a big linux supporter lately. On the other hand that can mean nothing. >Suggestions, anyone? I sent a simple message off to support@ >compaq.com. We'll see if that nets me anything, but I'm not >holding my breath. What about adding PCI support to the drivers? It shouldn't be very difficult. I don't know how deep is the complexity of a agp bridge, nor the legal implications this, but in the lack of interest from the vendor, reverse engineering the Window drivers might be feasible last resort option. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Argggg so close with S3 Virge/MX, yet so far...
Well, I've been waiting what seems like forever for a driver for my laptop and now there is one! What a happy day! One problem, it's an older Compaq laptop and uses a propriatary chipset (and AGP bridge) so no AGPGART. *do-oh* Noone happens to have a AGPGART for it hiding somewhere, do they? Concacts with Compaq they could twig? This laptop was retied over a year ago (by compaq support), so they shouldn't be all to concerned that any competetive information escape by coughing up the specs for it, one would think. Suggestions, anyone? I sent a simple message off to support@ compaq.com. We'll see if that nets me anything, but I'm not holding my breath. Cheers, David --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segfault in DRIClipNotify
Jens,
This works after fixing one thing in this section from DRICloseScreen:
if (pDRIPriv->wrap.AdjustFrame) {
- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
- pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
- pDRIPriv->wrap.AdjustFrame = NULL;
+ ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
+ pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
+ pScrn->AdjustFrame = NULL;
^^
}
That last line should change from:
pScrn->AdjustFrame = NULL;
to:
pDRIPriv->wrap.AdjustFrame = NULL;
This is line 452 in the patched dri.c. Other than that it looks good.
-Leif
On Sat, 6 Jul 2002, Jens Owen wrote:
> Leif Delgass wrote:
>
> >>> On Fri, 5 Jul 2002, Jens Owen wrote:
> Okay, try the attached patch. I think I'll do more than this, but it
> would be great if you could test just this, first.
>
>
> Okay, I have attached a more robust patch. Can you try this on your branch?
>
>
> >
> > I'll apply this to the
> > mach64 branch, but I'll let you patch the trunk.
>
>
> I'll apply this new patch to the trunk if it works okay for you.
>
>
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Got root? We do.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
On Saturday 06 July 2002 17:36, Oliver Feiler wrote: > On Friday 05 July 2002 13:04, José Fonseca wrote: > > Keith Whitwell confirmed the readiness of the r200-0-1-branch for > > testing and for binary snapshots. > > Just tested this driver on a system with original ATI 8500 card. > > With the binary snaphots and with the r200 branch compiled myself the > system crashes immediately when X is started. With DRI disabled X comes up > and runs without problems. > > I don't really know how to get more information from X. There are no syslog > entries and nothing in XFree.0.log. I started X via remote ssh to see X's > output, but it stops after printing the first few lines so there is nothing > useful there as well. That's all informtation I can give unfortunately. > > Summary: it crashes. ;) Erm, maybe I should add: the system is a VIA KT333 board, Athlon XP 1800. Kernel is 2.4.19-rc1 with agpgart compiled in. The ATI firegl drivers worked, btw. -- Oliver Feiler http://www.lionking.org/~kiza/ <-- homepage PGP-key ID 0x561D4FD2--> /pgpkey.shtml --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
On Friday 05 July 2002 13:04, José Fonseca wrote: > Keith Whitwell confirmed the readiness of the r200-0-1-branch for > testing and for binary snapshots. Just tested this driver on a system with original ATI 8500 card. With the binary snaphots and with the r200 branch compiled myself the system crashes immediately when X is started. With DRI disabled X comes up and runs without problems. I don't really know how to get more information from X. There are no syslog entries and nothing in XFree.0.log. I started X via remote ssh to see X's output, but it stops after printing the first few lines so there is nothing useful there as well. That's all informtation I can give unfortunately. Summary: it crashes. ;) -- Oliver Feiler http://www.lionking.org/~kiza/ <-- homepage PGP-key ID 0x561D4FD2--> /pgpkey.shtml --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote:
>>> On Fri, 5 Jul 2002, Jens Owen wrote:
Okay, try the attached patch. I think I'll do more than this, but it
would be great if you could test just this, first.
Okay, I have attached a more robust patch. Can you try this on your branch?
>
> I'll apply this to the
> mach64 branch, but I'll let you patch the trunk.
I'll apply this new patch to the trunk if it works okay for you.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
--- xc/programs/Xserver/GL/dri/dri.c.jens Fri Jul 5 13:07:43 2002
+++ xc/programs/Xserver/GL/dri/dri.cSat Jul 6 09:27:10 2002
@@ -383,29 +383,29 @@
/* Wrap DRI support */
if (pDRIInfo->wrap.ValidateTree) {
- pDRIPriv->wrap.ValidateTree = pScreen->ValidateTree;
- pScreen->ValidateTree = pDRIInfo->wrap.ValidateTree;
+ pDRIPriv->wrap.ValidateTree = pScreen->ValidateTree;
+ pScreen->ValidateTree = pDRIInfo->wrap.ValidateTree;
}
if (pDRIInfo->wrap.PostValidateTree) {
pDRIPriv->wrap.PostValidateTree = pScreen->PostValidateTree;
- pScreen->PostValidateTree = pDRIInfo->wrap.PostValidateTree;
+ pScreen->PostValidateTree = pDRIInfo->wrap.PostValidateTree;
}
if (pDRIInfo->wrap.WindowExposures) {
- pDRIPriv->wrap.WindowExposures = pScreen->WindowExposures;
- pScreen->WindowExposures = pDRIInfo->wrap.WindowExposures;
+ pDRIPriv->wrap.WindowExposures = pScreen->WindowExposures;
+ pScreen->WindowExposures= pDRIInfo->wrap.WindowExposures;
}
if (pDRIInfo->wrap.CopyWindow) {
- pDRIPriv->wrap.CopyWindow = pScreen->CopyWindow;
- pScreen->CopyWindow = pDRIInfo->wrap.CopyWindow;
+ pDRIPriv->wrap.CopyWindow = pScreen->CopyWindow;
+ pScreen->CopyWindow = pDRIInfo->wrap.CopyWindow;
}
if (pDRIInfo->wrap.ClipNotify) {
- pDRIPriv->wrap.ClipNotify = pScreen->ClipNotify;
- pScreen->ClipNotify = pDRIInfo->wrap.ClipNotify;
+ pDRIPriv->wrap.ClipNotify = pScreen->ClipNotify;
+ pScreen->ClipNotify = pDRIInfo->wrap.ClipNotify;
}
if (pDRIInfo->wrap.AdjustFrame) {
- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
- pDRIPriv->wrap.AdjustFrame = pScrn->AdjustFrame;
- pScrn->AdjustFrame = pDRIInfo->wrap.AdjustFrame;
+ ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
+ pDRIPriv->wrap.AdjustFrame = pScrn->AdjustFrame;
+ pScrn->AdjustFrame = pDRIInfo->wrap.AdjustFrame;
}
DRIDrvMsg(pScreen->myNum, X_INFO, "[DRI] installation complete\n");
@@ -417,18 +417,42 @@
DRICloseScreen(ScreenPtr pScreen)
{
DRIScreenPrivPtr pDRIPriv = DRI_SCREEN_PRIV(pScreen);
+DRIInfoPtr pDRIInfo;
drmContextPtrreserved;
int reserved_count;
if (pDRIPriv && pDRIPriv->directRenderingSupport) {
+pDRIInfo = pDRIPriv->pDriverInfo;
+
+ /* Unwrap DRI Functions */
+ if (pDRIPriv->wrap.ValidateTree) {
+ pScreen->ValidateTree = pDRIPriv->wrap.ValidateTree;
+ pDRIPriv->wrap.ValidateTree = NULL;
+ }
+ if (pDRIPriv->wrap.PostValidateTree) {
+ pScreen->PostValidateTree = pDRIPriv->wrap.PostValidateTree;
+ pDRIPriv->wrap.PostValidateTree = NULL;
+ }
+ if (pDRIPriv->wrap.WindowExposures) {
+ pScreen->WindowExposures= pDRIPriv->wrap.WindowExposures;
+ pDRIPriv->wrap.WindowExposures = NULL;
+ }
+ if (pDRIPriv->wrap.CopyWindow) {
+ pScreen->CopyWindow = pDRIPriv->wrap.CopyWindow;
+ pDRIPriv->wrap.CopyWindow = NULL;
+ }
+ if (pDRIPriv->wrap.ClipNotify) {
+ pScreen->ClipNotify = pDRIPriv->wrap.ClipNotify;
+ pDRIPriv->wrap.ClipNotify = NULL;
+ }
if (pDRIPriv->wrap.AdjustFrame) {
- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
- pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
- pDRIPriv->wrap.AdjustFrame = NULL;
+ ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
+ pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
+ pScrn->AdjustFrame = NULL;
}
- if (pDRIPriv->pDriverInfo->driverSwapMethod != DRI_KERNEL_SWAP) {
+ if (pDRIInfo->driverSwapMethod != DRI_KERNEL_SWAP) {
if (!drmRemoveSIGIOHandler(pDRIPriv->drmFD)) {
DRIDrvMsg(pScreen->myNum, X_ERROR,
"[drm] failed to remove DRM signal handler\n");
@@ -463,14 +487,14 @@
lockRefCount=0;
DRIDrvMsg(pScreen->myNum, X_INFO,
"[drm] unmapping %d bytes of SAREA 0x%08lx at %p\n",
- pDRIPriv->pDriverInfo->SAREASize,
+
[Dri-devel] r200: unresolved symbol on SMP/HIGHMEM system
depmod: *** Unresolved symbols in /lib/modules/2.4.19-rc1-aa1-pc/kernel/drivers/char/drm/radeon.o depmod: kmap_pagetable /lib/modules/2.4.19-rc1-aa1-pc/kernel/drivers/char/drm/radeon.o /lib/modules/2.4.19-rc1-aa1-pc/kernel/drivers/char/drm/tdfx.o Dual Athlon MP 1900+ MSI K7D Master-L (MS-6501), AMD 760 MPX 1 GB DDR266-SDRAM CL2 OK, latest -AA devel kernel. 2.4.19-rc1-aa1 Yes, it is introduced through HIGHMEM: SunWave1 patches/2.4.19rc1aa1# grep kmap_pagetable * 20_pte-highmem-25:+#define kmap_pagetable(page) kmap_serie(page, KM_SERIE_PAGETABLE) 20_pte-highmem-25:+ kmap_pagetable(__page); \ 20_pte-highmem-25:+ __kvaddr = kmap_pagetable(__page); \ 20_pte-highmem-25:+ * the default kmap on src pagetable, before kmap_pagetable 20_pte-highmem-25:+#define kmap_pagetable(page) kmap(page) 20_pte-highmem-25:+ void * vaddr = kmap_pagetable(page); I'll let you know what I get when I have some spare time later this weekend. -Dieter BTW Any hints where to put the EXPORT? -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fri, Jul 05, 2002 at 02:23:49PM +0100, Alan Hourihane wrote: >On Fri, Jul 05, 2002 at 01:51:50PM +0100, José Fonseca wrote: [...] >> >> Yes, that seems cleaner, since I won't have to bother eliminating the >> compiled stuff away. > >Yep. > >> >What does 'uname -s' return on NetBSD and FreeBSD ? >> >> On the FreeBSD of SF compiler farm it return 'FreeBSD'. > >Just massage the scripts for these cases and copy from the bsd directory >instead. All done. Ok. I've updated the scripts for both things, but I got a lot of errors (missing defines etc) when trying to build the DRM on a machine, and only the most simple DRM got built (tdfx and glint if I'm not mistaken). Is there any missing or did I do something wrong? I also tried to run the script on CF FreeBSD server but it seems that I've been using some GNU specific features of some programs (make -C failed) so it will take a little more massages. I also don't know how the BSD kernel modules(?) works (and the scripts neither!) I don't know what's the demand for BSD binary snapshots, but if someone more keen on BSD wants to give it a try take a look on the http://dri.sf.net/snapshots/scripts/README for an updated description and information on how to use this scripts. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't remove files from trunk
On Fri, Jul 05, 2002 at 11:10:22 -0600, Eric Anholt wrote: > There are files left over in the bsd DRM's driver subdirectories after > the merge to trunk. These got moved a directory above that (or to > shared/drm/kernel/), but the leftovers are getting in the way. I tried > to cvs rm and commit, but I got the following: > > cvs server: failed to remove tag `HEAD' from `gamma/gamma_dma.c' > cvs server: failed to remove tag `HEAD' from `gamma/gamma_drv.c' > cvs server: failed to remove tag `HEAD' from `i810/i810_dma.c' > cvs server: failed to remove tag `HEAD' from `i810/i810_drv.c' > cvs server: failed to remove tag `HEAD' from `i830/i830_dma.c' > cvs server: failed to remove tag `HEAD' from `i830/i830_drv.c' > cvs server: failed to remove tag `HEAD' from `mga/mga_dma.c' > cvs server: failed to remove tag `HEAD' from `mga/mga_drv.c' > cvs server: failed to remove tag `HEAD' from `mga/mga_state.c' > cvs server: failed to remove tag `HEAD' from `mga/mga_warp.c' > cvs server: failed to remove tag `HEAD' from `r128/r128_cce.c' > cvs server: failed to remove tag `HEAD' from `r128/r128_drv.c' > cvs server: failed to remove tag `HEAD' from `r128/r128_state.c' > cvs server: failed to remove tag `HEAD' from `radeon/radeon_cp.c' > cvs server: failed to remove tag `HEAD' from `radeon/radeon_drv.c' > cvs server: failed to remove tag `HEAD' from `radeon/radeon_drv.h' > cvs server: failed to remove tag `HEAD' from `radeon/radeon_state.c' > cvs commit: saving log message in /tmp/cvs80lKSc Done. Alan. --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Core dumped
On Fri, 5 Jul 2002, Eric Anholt wrote: > On Fri, 2002-07-05 at 17:00, Simon Cahuk wrote: > > I get seg fault (core dumped) running glxgears. > > System: > > FreeBSD 4.5-RELEASE, cards banshee, using glide3 ports. > > Glxinfo says DRI is enabled. > > Which exact version of glide3? What compile flags did you give? Did it > spew any error messages before dying? (be sure to use > LIBGL_DEBUG=verbose) Glide3 was built from ports, -current. Glide3 port version:20020113, CFLAGS -O. I buit it: make -DWITH_VOODOO3 and make -DWITH_VOODOO3 install I did export LIBGL_DEBUG=verbose and export FX_GLIDE_NUM_TMU=2 and after this and got this: glxgears libGL: XF86DRIGetClientDriverName: 1.0.0 tdfx (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/tdfx_dri.so libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/tdfx_dri.so drmOpenByBusid: busid is PCI:1:0:0 drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: drmOpenMinor returns 6 drmOpenByBusid: drmGetBusid reports PCI:1:0:0 libGL: using Glide library libglide3.so Segmentation fault (core dumped) Simon > > People have had banshees working on fbsd before. One thing that some > have had to do is: > export FX_GLIDE_NUM_TMU=2 > before running their apps. If you needed it too, I'll try to check in a > fix for the port. > > -- > Eric Anholt <[EMAIL PROTECTED]> > http://people.freebsd.org/~anholt/dri/ > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Bringing you mounds of caffeinated joy. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't remove files from trunk
Eric Anholt wrote: > There are files left over in the bsd DRM's driver subdirectories after > the merge to trunk. These got moved a directory above that (or to > shared/drm/kernel/), but the leftovers are getting in the way. I tried > to cvs rm and commit, but I got the following: > > cvs server: failed to remove tag `HEAD' from `gamma/gamma_dma.c' > cvs server: failed to remove tag `HEAD' from `gamma/gamma_drv.c' > cvs server: failed to remove tag `HEAD' from `i810/i810_dma.c' > cvs server: failed to remove tag `HEAD' from `i810/i810_drv.c' > cvs server: failed to remove tag `HEAD' from `i830/i830_dma.c' > cvs server: failed to remove tag `HEAD' from `i830/i830_drv.c' > cvs server: failed to remove tag `HEAD' from `mga/mga_dma.c' > cvs server: failed to remove tag `HEAD' from `mga/mga_drv.c' > cvs server: failed to remove tag `HEAD' from `mga/mga_state.c' > cvs server: failed to remove tag `HEAD' from `mga/mga_warp.c' > cvs server: failed to remove tag `HEAD' from `r128/r128_cce.c' > cvs server: failed to remove tag `HEAD' from `r128/r128_drv.c' > cvs server: failed to remove tag `HEAD' from `r128/r128_state.c' > cvs server: failed to remove tag `HEAD' from `radeon/radeon_cp.c' > cvs server: failed to remove tag `HEAD' from `radeon/radeon_drv.c' > cvs server: failed to remove tag `HEAD' from `radeon/radeon_drv.h' > cvs server: failed to remove tag `HEAD' from `radeon/radeon_state.c' > cvs commit: saving log message in /tmp/cvs80lKSc > > Can you give a full path to one of the files you're looking at, just for clarity? Keith --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
