Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Mon, 12 Apr 2004 13:06:51 +0200 Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Mon, 2004-04-12 at 06:45, Dave Airlie wrote: > > > > Log message: > > Import mach64 into trunk - still insecure but don't build it by default.. > > I'm not sure it's as simple as that... this means it'll get merged into > other trees, and may end up in releases. The same would be true for savage. I'm confident that people who merge DRI into other trees know what they are doing. ;-) Felix --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Mon, 2004-04-12 at 06:45, Dave Airlie wrote: > > Log message: > Import mach64 into trunk - still insecure but don't build it by default.. I'm not sure it's as simple as that... this means it'll get merged into other trees, and may end up in releases. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Felix Kühling <[EMAIL PROTECTED]> wrote: > This commit works fine on the ProSavage but on the SavageIX there are > two new problems. :( > > 2D performance is a lot worse now. Moving opaque windows is really > slow. > > And I get this from mplayer on movies that worked before: > > VO: [xv] 352x272 => 352x272 Planar YV12 > X11 error: BadAlloc (insufficient resources for operation) > Sorry. I reverted a change that fixed acceleration a while back. fixed now. what's weird is that I swear I had it working fine after the changes I made, which is why I reverted it in the first place. Alex __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
This commit works fine on the ProSavage but on the SavageIX there are two new problems. :( 2D performance is a lot worse now. Moving opaque windows is really slow. And I get this from mplayer on movies that worked before: VO: [xv] 352x272 => 352x272 Planar YV12 X11 error: BadAlloc (insufficient resources for operation) MPlayer interrupted by signal 6 in module: flip_page - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug. Successfully enabled DPMS Xlib: unexpected async reply (sequence 0x5a)! I'm not sure if the latter problem is really a bug since I run 1280x1024 with 8MB graphics memory. Did you allocate memory for something else that was available for Xv before? Regards, Felix On Tue, 23 Mar 2004 13:11:37 -0800 Alex Deucher <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvs/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/savage/ > Changes by: [EMAIL PROTECTED] 04/03/23 13:11:37 > > Log message: > - re-enable AGPMode option > - add AGPSize option > - fix Xv interpolation on old streams engine > > Modified files: > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/: > savage.man savage_accel.c savage_dri.c savage_driver.c > savage_driver.h savage_video.c > > Revision ChangesPath > 1.3 +12 -0 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage.man > 1.17 +3 -5 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_accel.c > 1.3 +7 -5 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_dri.c > 1.19 +36 -7 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c > 1.12 +1 -0 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.h > 1.7 +17 -12 > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_video.c > > > > --- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > -- > ___ > Dri-patches mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-patches > --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
After this update I tried running a new 3D driver without restarting the Xserver. I only got indirect rendering. After restarting the Xserver direct rendering started working again. This was with the savage driver. Is there a binary compatibility issue? I tried LIBGL_DEBUG=verbose with the old Xserver. I got no error messages but the output got only as far as: libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6-DRI/lib/modules/dri/savage_dri.so All the drmOpen stuff was just missing. With the new Xserver and direct rendering working again I get this: libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6-DRI/lib/modules/dri/savage_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 Regards, Felix On Wed, 03 Mar 2004 13:58:02 -0800 Ian Romanick <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvs/dri > Module name: xc > Repository: xc/xc/programs/Xserver/GL/mesa/X/ > Changes by: [EMAIL PROTECTED] 04/03/03 13:58:01 > > Log message: > Merged driinterface-0-0-3 > > Modified files: > xc/xc/include/GL/: > glxtokens.h > xc/xc/lib/GL/GL/: > Imakefile > xc/xc/lib/GL/dri/: > XF86dri.c dri_glx.c dri_util.c dri_util.h xf86dri.h > xc/xc/lib/GL/glx/: > Imakefile glcontextmodes.c glcontextmodes.h glxclient.h > glxcmds.c glxext.c > xc/xc/lib/GL/mesa/drivers/dri/mga/: > Imakefile.inc > xc/xc/lib/GL/mesa/drivers/dri/r200/: > Imakefile.inc > xc/xc/programs/Xserver/GL/: > glxmodule.c > xc/xc/programs/Xserver/GL/dri/: > dri.c > xc/xc/programs/Xserver/GL/glx/: > Imakefile g_disptab.c g_disptab.h glx-def.cpp glxcmds.c > glxcmdsswap.c glxcontext.h glxdrawable.h glxext.h > glxscreens.c glxscreens.h glxutil.c glxutil.h > xc/xc/programs/Xserver/GL/mesa/X/: > xf86glx.c xf86glxint.h > > Revision ChangesPath > 1.12 +6 -0 xc/xc/include/GL/glxtokens.h > 1.9 +40 -40xc/xc/lib/GL/GL/Imakefile > 1.17 +25 -48xc/xc/lib/GL/dri/XF86dri.c > 1.33 +22 -5 xc/xc/lib/GL/dri/dri_glx.c > 1.29 +541 -306 xc/xc/lib/GL/dri/dri_util.c > 1.17 +65 -13xc/xc/lib/GL/dri/dri_util.h > 1.8 +12 -18xc/xc/lib/GL/dri/xf86dri.h > 1.19 +2 -1 xc/xc/lib/GL/glx/Imakefile > 1.6 +96 -1 xc/xc/lib/GL/glx/glcontextmodes.c > 1.3 +4 -0 xc/xc/lib/GL/glx/glcontextmodes.h > 1.48 +121 -11 xc/xc/lib/GL/glx/glxclient.h > 1.77 +203 -70 xc/xc/lib/GL/glx/glxcmds.c > 1.39 +307 -74 xc/xc/lib/GL/glx/glxext.c > 1.3 +1 -1 xc/xc/lib/GL/mesa/drivers/dri/mga/Imakefile.inc > 1.3 +1 -1 xc/xc/lib/GL/mesa/drivers/dri/r200/Imakefile.inc > 1.6 +0 -1 xc/xc/programs/Xserver/GL/glxmodule.c > 1.51 +9 -9 xc/xc/programs/Xserver/GL/dri/dri.c > 1.4 +5 -2 xc/xc/programs/Xserver/GL/glx/Imakefile > 1.7 +20 -20xc/xc/programs/Xserver/GL/glx/g_disptab.c > 1.7 +6 -0 xc/xc/programs/Xserver/GL/glx/g_disptab.h > 1.2 +0 -1 xc/xc/programs/Xserver/GL/glx/glx-def.cpp > 1.13 +275 -97 xc/xc/programs/Xserver/GL/glx/glxcmds.c > 1.7 +104 -85 xc/xc/programs/Xserver/GL/glx/glxcmdsswap.c > 1.7 +0 -1 xc/xc/programs/Xserver/GL/glx/glxcontext.h > 1.5 +3 -2 xc/xc/programs/Xserver/GL/glx/glxdrawable.h > 1.6 +11 -3 xc/xc/programs/Xserver/GL/glx/glxext.h > 1.18 +2 -82 xc/xc/programs/Xserver/GL/glx/glxscreens.c > 1.7 +5 -1 xc/xc/programs/Xserver/GL/glx/glxscreens.h > 1.5 +5 -57 xc/xc/programs/Xserver/GL/glx/glxutil.c > 1.5 +0 -1 xc/xc/programs/Xserver/GL/glx/glxutil.h > 1.3 +123 -93 xc/xc/programs/Xserver/GL/mesa/X/xf86glx.c > 1.3 +1 -6 xc/xc/programs/Xserver/GL/mesa/X/xf86glxint.h --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
> > CVSROOT: /cvs/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/savage/ > Changes by: [EMAIL PROTECTED] 04/02/22 08:14:43 > > Log message: > Merged the DRI-enabled Savage 2D driver from the savage-2-0-0-branch > into the trunk. > > Modified files: > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/: > Imakefile savage_accel.c savage_bci.h savage_cursor.c > savage_dga.c savage_driver.c savage_driver.h savage_i2c.c > savage_regs.h savage_vbe.c savage_video.c > Added files: > xc/xc/programs/Xserver/hw/xfree86/drivers/savage/: > savage_dri.c savage_dri.h savage_dripriv.h savage_drm.h > savage_hwmc.c savage_sarea.h savage_util.c savage_util.h > videodev2.h We can actually remove savage_util.c, savage_util.h, and videodev2.h as they are no longer used by the driver. Also, at some point (if we get to test it), we may want to add the rest of the savage XvMC stuff to /lib/XvMC/ just so it doesn't get lost. Alex __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Am Mittwoch, 10. Dezember 2003 02:04 schrieb Alan Hourihane: > On Tue, Dec 09, 2003 at 04:54:24PM -0800, Eric Anholt wrote: > > On Tue, 2003-12-09 at 16:34, Alan Hourihane wrote: > > > On Tue, Dec 09, 2003 at 04:14:09PM -0800, Eric Anholt wrote: > > > > On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote: > > > > > On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: > > > > > > On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: > > > > > > > CVSROOT: /cvs/dri > > > > > > > Module name: xc > > > > > > > Repository: xc/xc/config/cf/ > > > > > > > Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 > > > > > > > > > > > > > > Log message: > > > > > > > move NormalLibExpat definition into OS specific config files > > > > > > > that'll help the merge from/to XFree86 at a later stage. > > > > > > > > > > > > The build is still broken on FreeBSD. Would it be objected to if > > > > > > I make the static expatness optional depending on platform? I'd > > > > > > rather not be linking statically for our ports version of the > > > > > > DRI, anyway. > > > > > > > > > > Can you explain what's broken in the FreeBSD build ? > > > > > > > > > > Also - Is expat available on all FreeBSD versions ? > > > > > > > > First it dies with not finding expat.h. Adding EXPATINCLUDES to > > > > common/Makefile.in fixed that. Then it dies on -lexpat because expat > > > > wasn't built (even with HasExpat YES not being defined in > > > > FreeBSD.cf). > > > > > > O.k. I've fixed the Imakefile. As for HasExpat YES, there's UseExpat > > > which should default to YES because BuildXF86DRI is set. UseExpat > > > should override it. > > > > But BuildExpat is (UseExpat && !HasExpat), right? > > Yes. Missed that essential piece. I'd moved straight down to see the > #if UseExpat furthur down X11.tmpl. > > > > > expat is available in ports, and I feel pretty safe saying everyone > > > > ever using the DRI on FreeBSD will already have it installed (having > > > > already installed XFree86-4-libraries which depends on it). I've > > > > never heard a single complaint in my memory about HasExpat already > > > > being set unconditionally in FreeBSD.cf. > > > > > > I've got a FreeBSD 4.3 box, I'll check if expat is installed by > > > default. > > > > If you mean in the base install, no, it isn't (well, except as > > libbsdxml, but it's renamed for a reason). But you can't build the DRI > > from a base FreeBSD install, last I knew of; you first need to install > > XFree86. If you are doing it properly on FreeBSD that means using > > ports, which means XFree86-4-libraries which depends on libexpat. If > > people install XFree86 from source, I hope XFree86 is installing its > > libexpat in the right place, but I don't care about that too much. > > Their system is probably going to end up broken in odd ways when they > > try to use ports after that anyway. > > O.k. I'll defer to your decision on that. > > > > > > > What I'm trying right now is making an ExpatLibrary definition in > > > > > > Imake.tmpl that is used in the drivers build. It's overridden > > > > > > for non-FreeBSD in host.def. > > > > > > > > > > Can you send a patch first ? > > > > > > > > > > Alan. > > > > > > > > http://www.freedesktop.org/~anholt/dri-expatfix.diff > > > > > > > > Apoligies for the mess in it; there are some other changes in there. > > > > It's what I've just tested on FreeBSD and Linux, with the linking > > > > looking like it ended up right (ldd shows no libexpat on linux) > > > > > > > > Unless there's some compelling reason to have expat linked > > > > statically, I'll have to end up patching to fix linking in ports, > > > > which will be annoying. > > > > > > The problem of putting the StaticLibrary() bits back in host.def > > > results in the build linking against the dynamic version when merged > > > back into XFree86 at a later date. I'm trying to modify the OS cf files > > > now so that we don't lose that functionality. > > > > > > So if you want to do > > > > > > #ifndef ExpatLibrary > > > #define ExpatLibrary StaticLibrary($(BUILDLIBDIR),expat) > > > #endif > > > > > > in the linux.cf instead of the host.def that's fine with me. That'll > > > leave the FreeBSD and OpenBSD architectures linking dynamically. > > > > So Linux has to have it linked statically in XFree86, too? Not seeing > > the reason for that, but OK. > > Actually, I've had a rethink about this. Leave it in host.def for now > as you've got it. We may need to revisit it later. Didn't we have "expat" on all _new_ distros? SuSE 9.0 for example. SunWave1 /opt/Mesa# rpm -qa | grep expat expat-1.95.6-80 SunWave1 /opt/Mesa# rpm -ql expat-1.95.6-80 /usr/bin/xmlwf /usr/include/expat.h /usr/lib/libexpat.a /usr/lib/libexpat.la /usr/lib/libexpat.so /usr/lib/libexpat.so.0 /usr/lib/libexpat.so.0.4.0 /usr/share/doc/packages/expat /usr/share/doc/packages/expat/COPYING /usr/share/doc/packages/expat/Changes /usr/share/doc/packages/expat/MANIFEST /usr/share/doc/packages/e
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-12-09 at 16:34, Alan Hourihane wrote: > On Tue, Dec 09, 2003 at 04:14:09PM -0800, Eric Anholt wrote: > > On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote: > > > On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: > > > > On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: > > > > > CVSROOT: /cvs/dri > > > > > Module name: xc > > > > > Repository: xc/xc/config/cf/ > > > > > Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 > > > > > > > > > > Log message: > > > > > move NormalLibExpat definition into OS specific config files that'll help > > > > > the merge from/to XFree86 at a later stage. > > > > > > > > The build is still broken on FreeBSD. Would it be objected to if I make > > > > the static expatness optional depending on platform? I'd rather not be > > > > linking statically for our ports version of the DRI, anyway. > > > > > > Can you explain what's broken in the FreeBSD build ? > > > > > > Also - Is expat available on all FreeBSD versions ? > > > > First it dies with not finding expat.h. Adding EXPATINCLUDES to > > common/Makefile.in fixed that. Then it dies on -lexpat because expat > > wasn't built (even with HasExpat YES not being defined in FreeBSD.cf). > > O.k. I've fixed the Imakefile. As for HasExpat YES, there's UseExpat which > should default to YES because BuildXF86DRI is set. UseExpat should override > it. But BuildExpat is (UseExpat && !HasExpat), right? > > expat is available in ports, and I feel pretty safe saying everyone ever > > using the DRI on FreeBSD will already have it installed (having already > > installed XFree86-4-libraries which depends on it). I've never heard a > > single complaint in my memory about HasExpat already being set > > unconditionally in FreeBSD.cf. > > I've got a FreeBSD 4.3 box, I'll check if expat is installed by default. If you mean in the base install, no, it isn't (well, except as libbsdxml, but it's renamed for a reason). But you can't build the DRI from a base FreeBSD install, last I knew of; you first need to install XFree86. If you are doing it properly on FreeBSD that means using ports, which means XFree86-4-libraries which depends on libexpat. If people install XFree86 from source, I hope XFree86 is installing its libexpat in the right place, but I don't care about that too much. Their system is probably going to end up broken in odd ways when they try to use ports after that anyway. > > > > What I'm trying right now is making an ExpatLibrary definition in > > > > Imake.tmpl that is used in the drivers build. It's overridden for > > > > non-FreeBSD in host.def. > > > > > > Can you send a patch first ? > > > > > > Alan. > > > > http://www.freedesktop.org/~anholt/dri-expatfix.diff > > > > Apoligies for the mess in it; there are some other changes in there. > > It's what I've just tested on FreeBSD and Linux, with the linking > > looking like it ended up right (ldd shows no libexpat on linux) > > > > Unless there's some compelling reason to have expat linked statically, > > I'll have to end up patching to fix linking in ports, which will be > > annoying. > > The problem of putting the StaticLibrary() bits back in host.def results > in the build linking against the dynamic version when merged back into > XFree86 at a later date. I'm trying to modify the OS cf files now so > that we don't lose that functionality. > > So if you want to do > > #ifndef ExpatLibrary > #define ExpatLibrary StaticLibrary($(BUILDLIBDIR),expat) > #endif > > in the linux.cf instead of the host.def that's fine with me. That'll > leave the FreeBSD and OpenBSD architectures linking dynamically. So Linux has to have it linked statically in XFree86, too? Not seeing the reason for that, but OK. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Dec 09, 2003 at 04:54:24PM -0800, Eric Anholt wrote: > On Tue, 2003-12-09 at 16:34, Alan Hourihane wrote: > > On Tue, Dec 09, 2003 at 04:14:09PM -0800, Eric Anholt wrote: > > > On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote: > > > > On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: > > > > > On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: > > > > > > CVSROOT:/cvs/dri > > > > > > Module name:xc > > > > > > Repository: xc/xc/config/cf/ > > > > > > Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 > > > > > > > > > > > > Log message: > > > > > > move NormalLibExpat definition into OS specific config files that'll help > > > > > > the merge from/to XFree86 at a later stage. > > > > > > > > > > The build is still broken on FreeBSD. Would it be objected to if I make > > > > > the static expatness optional depending on platform? I'd rather not be > > > > > linking statically for our ports version of the DRI, anyway. > > > > > > > > Can you explain what's broken in the FreeBSD build ? > > > > > > > > Also - Is expat available on all FreeBSD versions ? > > > > > > First it dies with not finding expat.h. Adding EXPATINCLUDES to > > > common/Makefile.in fixed that. Then it dies on -lexpat because expat > > > wasn't built (even with HasExpat YES not being defined in FreeBSD.cf). > > > > O.k. I've fixed the Imakefile. As for HasExpat YES, there's UseExpat which > > should default to YES because BuildXF86DRI is set. UseExpat should override > > it. > > But BuildExpat is (UseExpat && !HasExpat), right? Yes. Missed that essential piece. I'd moved straight down to see the #if UseExpat furthur down X11.tmpl. > > > expat is available in ports, and I feel pretty safe saying everyone ever > > > using the DRI on FreeBSD will already have it installed (having already > > > installed XFree86-4-libraries which depends on it). I've never heard a > > > single complaint in my memory about HasExpat already being set > > > unconditionally in FreeBSD.cf. > > > > I've got a FreeBSD 4.3 box, I'll check if expat is installed by default. > > If you mean in the base install, no, it isn't (well, except as > libbsdxml, but it's renamed for a reason). But you can't build the DRI > from a base FreeBSD install, last I knew of; you first need to install > XFree86. If you are doing it properly on FreeBSD that means using > ports, which means XFree86-4-libraries which depends on libexpat. If > people install XFree86 from source, I hope XFree86 is installing its > libexpat in the right place, but I don't care about that too much. > Their system is probably going to end up broken in odd ways when they > try to use ports after that anyway. O.k. I'll defer to your decision on that. > > > > > What I'm trying right now is making an ExpatLibrary definition in > > > > > Imake.tmpl that is used in the drivers build. It's overridden for > > > > > non-FreeBSD in host.def. > > > > > > > > Can you send a patch first ? > > > > > > > > Alan. > > > > > > http://www.freedesktop.org/~anholt/dri-expatfix.diff > > > > > > Apoligies for the mess in it; there are some other changes in there. > > > It's what I've just tested on FreeBSD and Linux, with the linking > > > looking like it ended up right (ldd shows no libexpat on linux) > > > > > > Unless there's some compelling reason to have expat linked statically, > > > I'll have to end up patching to fix linking in ports, which will be > > > annoying. > > > > The problem of putting the StaticLibrary() bits back in host.def results > > in the build linking against the dynamic version when merged back into > > XFree86 at a later date. I'm trying to modify the OS cf files now so > > that we don't lose that functionality. > > > > So if you want to do > > > > #ifndef ExpatLibrary > > #define ExpatLibrary StaticLibrary($(BUILDLIBDIR),expat) > > #endif > > > > in the linux.cf instead of the host.def that's fine with me. That'll > > leave the FreeBSD and OpenBSD architectures linking dynamically. > > So Linux has to have it linked statically in XFree86, too? Not seeing > the reason for that, but OK. Actually, I've had a rethink about this. Leave it in host.def for now as you've got it. We may need to revisit it later. Go ahead and commit the patch you've got. Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Dec 09, 2003 at 04:14:09PM -0800, Eric Anholt wrote: > On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote: > > On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: > > > On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: > > > > CVSROOT:/cvs/dri > > > > Module name:xc > > > > Repository: xc/xc/config/cf/ > > > > Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 > > > > > > > > Log message: > > > > move NormalLibExpat definition into OS specific config files that'll help > > > > the merge from/to XFree86 at a later stage. > > > > > > The build is still broken on FreeBSD. Would it be objected to if I make > > > the static expatness optional depending on platform? I'd rather not be > > > linking statically for our ports version of the DRI, anyway. > > > > Can you explain what's broken in the FreeBSD build ? > > > > Also - Is expat available on all FreeBSD versions ? > > First it dies with not finding expat.h. Adding EXPATINCLUDES to > common/Makefile.in fixed that. Then it dies on -lexpat because expat > wasn't built (even with HasExpat YES not being defined in FreeBSD.cf). O.k. I've fixed the Imakefile. As for HasExpat YES, there's UseExpat which should default to YES because BuildXF86DRI is set. UseExpat should override it. > expat is available in ports, and I feel pretty safe saying everyone ever > using the DRI on FreeBSD will already have it installed (having already > installed XFree86-4-libraries which depends on it). I've never heard a > single complaint in my memory about HasExpat already being set > unconditionally in FreeBSD.cf. I've got a FreeBSD 4.3 box, I'll check if expat is installed by default. > > > What I'm trying right now is making an ExpatLibrary definition in > > > Imake.tmpl that is used in the drivers build. It's overridden for > > > non-FreeBSD in host.def. > > > > Can you send a patch first ? > > > > Alan. > > http://www.freedesktop.org/~anholt/dri-expatfix.diff > > Apoligies for the mess in it; there are some other changes in there. > It's what I've just tested on FreeBSD and Linux, with the linking > looking like it ended up right (ldd shows no libexpat on linux) > > Unless there's some compelling reason to have expat linked statically, > I'll have to end up patching to fix linking in ports, which will be > annoying. The problem of putting the StaticLibrary() bits back in host.def results in the build linking against the dynamic version when merged back into XFree86 at a later date. I'm trying to modify the OS cf files now so that we don't lose that functionality. So if you want to do #ifndef ExpatLibrary #define ExpatLibrary StaticLibrary($(BUILDLIBDIR),expat) #endif in the linux.cf instead of the host.def that's fine with me. That'll leave the FreeBSD and OpenBSD architectures linking dynamically. Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote: > On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: > > On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: > > > CVSROOT: /cvs/dri > > > Module name: xc > > > Repository: xc/xc/config/cf/ > > > Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 > > > > > > Log message: > > > move NormalLibExpat definition into OS specific config files that'll help > > > the merge from/to XFree86 at a later stage. > > > > The build is still broken on FreeBSD. Would it be objected to if I make > > the static expatness optional depending on platform? I'd rather not be > > linking statically for our ports version of the DRI, anyway. > > Can you explain what's broken in the FreeBSD build ? > > Also - Is expat available on all FreeBSD versions ? First it dies with not finding expat.h. Adding EXPATINCLUDES to common/Makefile.in fixed that. Then it dies on -lexpat because expat wasn't built (even with HasExpat YES not being defined in FreeBSD.cf). expat is available in ports, and I feel pretty safe saying everyone ever using the DRI on FreeBSD will already have it installed (having already installed XFree86-4-libraries which depends on it). I've never heard a single complaint in my memory about HasExpat already being set unconditionally in FreeBSD.cf. > > What I'm trying right now is making an ExpatLibrary definition in > > Imake.tmpl that is used in the drivers build. It's overridden for > > non-FreeBSD in host.def. > > Can you send a patch first ? > > Alan. http://www.freedesktop.org/~anholt/dri-expatfix.diff Apoligies for the mess in it; there are some other changes in there. It's what I've just tested on FreeBSD and Linux, with the linking looking like it ended up right (ldd shows no libexpat on linux) Unless there's some compelling reason to have expat linked statically, I'll have to end up patching to fix linking in ports, which will be annoying. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: > On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: > > CVSROOT:/cvs/dri > > Module name:xc > > Repository: xc/xc/config/cf/ > > Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 > > > > Log message: > > move NormalLibExpat definition into OS specific config files that'll help > > the merge from/to XFree86 at a later stage. > > The build is still broken on FreeBSD. Would it be objected to if I make > the static expatness optional depending on platform? I'd rather not be > linking statically for our ports version of the DRI, anyway. Can you explain what's broken in the FreeBSD build ? Also - Is expat available on all FreeBSD versions ? > What I'm trying right now is making an ExpatLibrary definition in > Imake.tmpl that is used in the drivers build. It's overridden for > non-FreeBSD in host.def. Can you send a patch first ? Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: > CVSROOT: /cvs/dri > Module name: xc > Repository: xc/xc/config/cf/ > Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 > > Log message: > move NormalLibExpat definition into OS specific config files that'll help > the merge from/to XFree86 at a later stage. The build is still broken on FreeBSD. Would it be objected to if I make the static expatness optional depending on platform? I'd rather not be linking statically for our ports version of the DRI, anyway. What I'm trying right now is making an ExpatLibrary definition in Imake.tmpl that is used in the drivers build. It's overridden for non-FreeBSD in host.def. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Sun, 2003-10-19 at 16:35, Eric Anholt wrote: > CVSROOT: /cvs/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/ > Changes by: [EMAIL PROTECTED] 03/10/19 16:35:59 > > Log message: > - SMPng lock the DRM. This is only partial -- there are a few code paths used > by root (the X Server) which are not locked. However, it should deal with > lost-IRQ issues on -current which I think people have been experiencing but > I am unable to reproduce (though I understand why they would occur, because of > a bug of mine). Note that most of the locking (DRM_LOCK()/UNLOCK()) > is all covered by Giant still, so it doesn't matter yet. > - Remove locking on FreeBSD-stable and NetBSD. These are covered by the fact > that there is no reentrancy of the kernel except by interrupts, which are > locked using spldrm()/splx() instead. I thought I had this one tested pretty thoroughly, but I just found a rough spot: We could sleep in the sysctl code with the device's lock held. Witness will complain loudly on a sysctl hw.dri. I'll fix this when I can. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Sorry. I documented the MergedDPI option. Alex --- Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Sat, 2003-10-18 at 18:53, Alex Deucher wrote: > > > > Log message: > > Update radeon man page. > > Sorry to be pedantic, but this log message is redundant: > > > Modified files: > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > radeon.man > > It would have been interesting what changed though. > > > -- > Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI > developer > Software libre enthusiast \ > http://svcs.affero.net/rm.php?r=daenzer > > > > --- > This SF.net email sponsored by: Enterprise Linux Forum Conference & > Expo > The Event For Linux Datacenter Solutions & Strategies in The > Enterprise > Linux in the Boardroom; in the Front Office; & in the Server Room > http://www.enterpriselinuxforum.com > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Sat, 2003-10-18 at 18:53, Alex Deucher wrote: > > Log message: > Update radeon man page. Sorry to be pedantic, but this log message is redundant: > Modified files: > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > radeon.man It would have been interesting what changed though. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
Felix Kuehling wrote: CVSROOT:/cvs/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/sis/ Changes by: [EMAIL PROTECTED] 03/10/17 06:26:08 Log message: Fixed linking of DRI drivers with common object files. Now each driver only links with those common objects that it really needs. hwlog.o is not used anymore. Removed a last left-over include "hwlog.h" from common/mm.c. Lets remove hwlog.[ch] then. Keith --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 2003-10-17 at 17:41, Alex Deucher wrote: > --- Michel Dnzer <[EMAIL PROTECTED]> wrote: > > > > The case I was concerned about was multiple Radeon cards, that used > > to fail rather spectacularly. > > I thought that had something to do with rom loading on secondary cards, > although you may be speaking of a different issue. I am, at least one instance would get confused in the ring or even MMIO handling. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Fri, 2003-10-17 at 05:14, Eric Anholt wrote: > > > > Log message: > > - Converted Linux drivers to initialize DRM instances based on > PCI IDs, not > > just a single instance. Moved the PCI ID lists from _drv.c > in BSD to > > .h. The PCI ID lists include a driver private field, which > may be used > > by drivers for chip family or other information. Based on work > by jonsmirl. > > - Make tdfx_drv.c and tdfx.h match other drivers. > > - Fixed up linking of sis shared files. > > > > Tested with Radeon and SiS on Linux and FreeBSD, including a > Linux setup with > > 2 SiS cards in a machine, but only one head being used (with DRI) > > The case I was concerned about was multiple Radeon cards, that used > to > fail rather spectacularly. > > I thought that had something to do with rom loading on secondary cards, although you may be speaking of a different issue. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 17 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: > On Fri, 2003-10-17 at 04:41, Alex Deucher wrote: > > > > Log message: > > *Re-wrote MergedFB validate mode function from scratch based on crt1 validation > > rather than the old clone validation code. > > So does it work more or less like the old clone mode by default now? :) > > > > *Fixed mode validation on systems without libint10.a; MergedFB should work on > > Freebsd, however, I don't have such a system to test on. It works fine on linux > > without libint10.a. Well, I updated, recompiled, and installed under FreeBSD. I launched X and it didn't crash. I'm not actually in front of the machine, so I can't confirm that it hasn't destroyed my monitors, but it looks like it's running fine :-) Adam --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 2003-10-17 at 05:14, Eric Anholt wrote: > > Log message: > - Converted Linux drivers to initialize DRM instances based on PCI IDs, not > just a single instance. Moved the PCI ID lists from _drv.c in BSD to > .h. The PCI ID lists include a driver private field, which may be used > by drivers for chip family or other information. Based on work by jonsmirl. > - Make tdfx_drv.c and tdfx.h match other drivers. > - Fixed up linking of sis shared files. > > Tested with Radeon and SiS on Linux and FreeBSD, including a Linux setup with > 2 SiS cards in a machine, but only one head being used (with DRI) The case I was concerned about was multiple Radeon cards, that used to fail rather spectacularly. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Fri, 2003-10-17 at 04:41, Alex Deucher wrote: > > > > Log message: > > *Re-wrote MergedFB validate mode function from scratch based on > crt1 validation > > rather than the old clone validation code. > > So does it work more or less like the old clone mode by default now? > :) Should work more like it :) > > > > *Fixed mode validation on systems without libint10.a; MergedFB > should work on > > Freebsd, however, I don't have such a system to test on. It > works fine on linux > > without libint10.a. > > Note that AIUI, the problem was never a missing libint10.a, but the > generic one vs. the Linux specific one. > > That's what I meant, sorry for any confusion. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 2003-10-17 at 04:41, Alex Deucher wrote: > > Log message: > *Re-wrote MergedFB validate mode function from scratch based on crt1 validation > rather than the old clone validation code. So does it work more or less like the old clone mode by default now? :) > *Fixed mode validation on systems without libint10.a; MergedFB should work on > Freebsd, however, I don't have such a system to test on. It works fine on linux > without libint10.a. Note that AIUI, the problem was never a missing libint10.a, but the generic one vs. the Linux specific one. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Thu, 2003-10-16 at 19:00, Keith Whitwell wrote: > Felix Kühling wrote: > > IIRC, the radeon driver still uses AGP writeback. This doesn't work > > reliably on my system and I disabled it in my local tree. Some people > > (including myself) have been thinking about an efficient algorithm to > > detect unreliable writeback, but AFAICT nobody came up with anything yet > > (at least no implementation). Should we just disable it for good? > > How often do we actually look at the read pointer? It's only really useful > for detecting an empty ring, and we have other registers for that. The other > time it's examined is for a *full* ring. > > If we read it lazily, and only when the ring appears to fill, that actually > wouldn't be that many reads. True. OTOH, once we're using the recommended memory layout (I'm almost done with the transition), we could use plain PCI transfers for the writeback, which should be more reliable. Also, I have code for clients to read the values directly from the writeback page, which could save some context switches. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Felix Kühling wrote: IIRC, the radeon driver still uses AGP writeback. This doesn't work reliably on my system and I disabled it in my local tree. Some people (including myself) have been thinking about an efficient algorithm to detect unreliable writeback, but AFAICT nobody came up with anything yet (at least no implementation). Should we just disable it for good? How often do we actually look at the read pointer? It's only really useful for detecting an empty ring, and we have other registers for that. The other time it's examined is for a *full* ring. If we read it lazily, and only when the ring appears to fill, that actually wouldn't be that many reads. Keith --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
IIRC, the radeon driver still uses AGP writeback. This doesn't work reliably on my system and I disabled it in my local tree. Some people (including myself) have been thinking about an efficient algorithm to detect unreliable writeback, but AFAICT nobody came up with anything yet (at least no implementation). Should we just disable it for good? Regards, Felix On Thu, 16 Oct 2003 07:18:52 -0700 Michel Daenzer <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvs/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/ > Changes by: [EMAIL PROTECTED] 03/10/16 07:18:52 > > Log message: > * Introduce COMMIT_RING() as in radeon DRM, stop using error prone > writeback for ring read pointer (Paul Mackerras) > * Get rid of some superfluous stuff, minor fixes > > Modified files: > xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/: > r128_cce.c r128_drv.h r128_state.c > > Revision ChangesPath > 1.12 +9 -30 > xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_cce.c > 1.10 +32 -25 > xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_drv.h > 1.10 +24 -8 > xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_state.c > > > > --- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net hosts over 70,000 Open Source Projects. > See the people who have HELPED US provide better services: > Click here: http://sourceforge.net/supporters.php > ___ > Dri-patches mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-patches > __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Thu, 2003-10-16 at 15:41, Alex Deucher wrote: > --- Michel Dnzer <[EMAIL PROTECTED]> wrote: > > On Thu, 2003-10-16 at 08:36, Alex Deucher wrote: > > > > > > Log message: > > > Clean up of the mode validation code for MergedFB. > > > > Does it behave the same as pre-MergedFB by default now? > > I haven't put back the old clone code, although the code that's there > should work (it's an almost identical code path, the only real > difference is how the crtc2 modes are stored in the driver). It works > for me, but it may not work perfectly for others. It's less important which code it is, so long as it behaves the same by default, which obviously wasn't the case. Is this fixed now? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Thu, 2003-10-16 at 08:36, Alex Deucher wrote: > > > > Log message: > > Clean up of the mode validation code for MergedFB. > > Does it behave the same as pre-MergedFB by default now? I haven't put back the old clone code, although the code that's there should work (it's an almost identical code path, the only real difference is how the crtc2 modes are stored in the driver). It works for me, but it may not work perfectly for others. This was mostly a clean up I've been working on for a while. Unfortunately, it still crashes when you run mergedfb mode without libint10.a. I haven't been able to track that down yet. > > > Also enable MergedFB autoconfig which will automatically set the > virtual > > desktop size and/or metamodes if you forget to specify them. > Also added > > MergedFBAuto option which will automatically run single head or > dualhead > > depending on whether it detects one or two attached monitors. > > Is that option really needed? Shouldn't that be the default? Yeah, I guess it should :) it was late, when I finally got it working. I'll make that the default tonight. > > > PS: The name of Option "NoMergedXinerama" is broken. The option > handling > code will automatically treat "NoXXX" as "XXX" "off". > I'll take a look. thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Thu, 2003-10-16 at 08:36, Alex Deucher wrote: > > Log message: > Clean up of the mode validation code for MergedFB. Does it behave the same as pre-MergedFB by default now? > Also enable MergedFB autoconfig which will automatically set the virtual > desktop size and/or metamodes if you forget to specify them. Also added > MergedFBAuto option which will automatically run single head or dualhead > depending on whether it detects one or two attached monitors. Is that option really needed? Shouldn't that be the default? PS: The name of Option "NoMergedXinerama" is broken. The option handling code will automatically treat "NoXXX" as "XXX" "off". -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Thu, 2003-10-16 at 00:11, Felix Kühling wrote: > This should make life easier for developers. You'll get annoying > warnings though. For my conscience: it is still a lot better than the > old scheme as the values from the environment are properly checked and > converted before use. :) Yes, I think this is a very good solution, thanks. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
This should make life easier for developers. You'll get annoying warnings though. For my conscience: it is still a lot better than the old scheme as the values from the environment are properly checked and converted before use. :) Regards, Felix On Wed, 15 Oct 2003 15:02:58 -0700 Felix Kuehling <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvs/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/common/ > Changes by: [EMAIL PROTECTED] 03/10/15 15:02:58 > > Log message: > Allow option values to be overridden by environment variables. > > Modified files: > xc/xc/lib/GL/mesa/src/drv/common/: > xmlconfig.c > > Revision ChangesPath > 1.5 +16 -4 xc/xc/lib/GL/mesa/src/drv/common/xmlconfig.c > __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Eric Anholt wrote: On Tue, 2003-10-07 at 10:42, Alex Deucher wrote: I have a question about the license at the top of these new files. what should I put for the copyright? Some of the the code was written by me, but much of it was taken from the sis and mga drivers. Also, what to I put for the top line? the one that looks like this: /* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c,v 1.25 2003/08/29 21:07:57 tsi Exp $ */ thanks, Alex Accepted practice, as far as I can tell, is that when you take code from one driver and adapt it into new files in another driver, you get to put your copyright on it. I've done this in the sis code, and VIA/S3 did it in the Savage code which still has a lot of Matrox code #ifdeffed out (or not, and just unused) in it. Yep, this is fine. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-10-07 at 10:42, Alex Deucher wrote: > I have a question about the license at the top of these new files. > what should I put for the copyright? Some of the the code was written > by me, but much of it was taken from the sis and mga drivers. Also, > what to I put for the top line? the one that looks like this: > /* $XFree86: > xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c,v 1.25 > 2003/08/29 21:07:57 tsi Exp $ */ > > thanks, > > Alex Accepted practice, as far as I can tell, is that when you take code from one driver and adapt it into new files in another driver, you get to put your copyright on it. I've done this in the sis code, and VIA/S3 did it in the Savage code which still has a lot of Matrox code #ifdeffed out (or not, and just unused) in it. For the XFree86 CVS ID in a new file, just put: /* $XFree86$ */ and it'll get expanded by CVS when it's committed to the XFree86 repo. Or, you can leave it out and I think the XFree86 folks take care of adding it when it goes into their repo. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
I have a question about the license at the top of these new files. what should I put for the copyright? Some of the the code was written by me, but much of it was taken from the sis and mga drivers. Also, what to I put for the top line? the one that looks like this: /* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c,v 1.25 2003/08/29 21:07:57 tsi Exp $ */ thanks, Alex --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote: > > Log message: > > Add Merged Framebuffer (MergedFB) support to the radeon driver. > On > > dualhead cards this creates a single shared framebuffer with 2 > viewports > > looking into it. This allows things like the DRI to work on both > heads. > > This also adds support for pseudo-xinerama so that xinerama aware > apps > > will behave as expected in a dualheaded setup when used with > MergedFB. > > > > Modified files: > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > radeon.h radeon.man radeon_cursor.c radeon_driver.c > > radeon_video.c > > > > Revision ChangesPath > > 1.39 +77 -7 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h > > 1.3 +125 -17 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.man > > 1.15 +126 -75 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c > > 1.65 +1505 -202 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c > > 1.18 +174 -44 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c > > Ugh. radeon_driver.c is getting out of hand in it's shear size now. > > Could this work be separated out into a radeon_mergedfb.c ? > > Then all the Xinerama related code is easily spotted when we can > separate > this stuff out into it's own support module that other drivers can > use. > > Alan. > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Yeah. I'll work on that this week unless anyone has any objections. Alex --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote: > > Log message: > > Add Merged Framebuffer (MergedFB) support to the radeon driver. > On > > dualhead cards this creates a single shared framebuffer with 2 > viewports > > looking into it. This allows things like the DRI to work on both > heads. > > This also adds support for pseudo-xinerama so that xinerama aware > apps > > will behave as expected in a dualheaded setup when used with > MergedFB. > > > > Modified files: > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > radeon.h radeon.man radeon_cursor.c radeon_driver.c > > radeon_video.c > > > > Revision ChangesPath > > 1.39 +77 -7 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h > > 1.3 +125 -17 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.man > > 1.15 +126 -75 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c > > 1.65 +1505 -202 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c > > 1.18 +174 -44 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c > > Ugh. radeon_driver.c is getting out of hand in it's shear size now. > > Could this work be separated out into a radeon_mergedfb.c ? > > Then all the Xinerama related code is easily spotted when we can > separate > this stuff out into it's own support module that other drivers can > use. > > Alan. > > __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote: > Log message: > Add Merged Framebuffer (MergedFB) support to the radeon driver. On > dualhead cards this creates a single shared framebuffer with 2 viewports > looking into it. This allows things like the DRI to work on both heads. > This also adds support for pseudo-xinerama so that xinerama aware apps > will behave as expected in a dualheaded setup when used with MergedFB. > > Modified files: > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > radeon.h radeon.man radeon_cursor.c radeon_driver.c > radeon_video.c > > Revision ChangesPath > 1.39 +77 -7 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h > 1.3 +125 -17 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.man > 1.15 +126 -75 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c > 1.65 +1505 -202 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c > 1.18 +174 -44 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c Ugh. radeon_driver.c is getting out of hand in it's shear size now. Could this work be separated out into a radeon_mergedfb.c ? Then all the Xinerama related code is easily spotted when we can separate this stuff out into it's own support module that other drivers can use. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Alan Hourihane wrote: On Tue, Sep 30, 2003 at 11:31:04AM +0200, Michel Dänzer wrote: On Tue, 2003-09-30 at 11:13, Alan Hourihane wrote: I looked at your original commit message and it didn't give any reason why you did it in the first place. I followed up to your commit, check out the dri-devel archives (and maybe check your filters? :) . I would have appreciated if you had asked before removing it to boot. Add it back if your that bothered. I'm not. Martin, can you repost your orignal email? I'd like to have one approach which is agreed by all parties and this back & forth isn't going anywhere... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Sep 30, 2003 at 11:31:04AM +0200, Michel Dänzer wrote: > On Tue, 2003-09-30 at 11:13, Alan Hourihane wrote: > > > > I looked at your original commit message and it didn't give any reason > > why you did it in the first place. > > I followed up to your commit, check out the dri-devel archives (and > maybe check your filters? :) . I would have appreciated if you had asked > before removing it to boot. Add it back if your that bothered. I'm not. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-09-30 at 11:13, Alan Hourihane wrote: > > I looked at your original commit message and it didn't give any reason > why you did it in the first place. I followed up to your commit, check out the dri-devel archives (and maybe check your filters? :) . I would have appreciated if you had asked before removing it to boot. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Sep 30, 2003 at 02:43:17AM +0200, Michel Dänzer wrote: > On Sun, 2003-09-28 at 18:03, Alan Hourihane wrote: > > On Sun, Sep 28, 2003 at 04:33:47PM +0200, Felix Kühling wrote: > > > On Fri, 26 Sep 2003 10:26:40 -0700 > > > Alan Hourihane <[EMAIL PROTECTED]> wrote: > > > > > > > CVSROOT:/cvs/dri > > > > Module name:xc > > > > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > > > > Changes by: [EMAIL PROTECTED] 03/09/26 10:26:40 > > > > > > > > Log message: > > > > no longer need radeon_pci.h since the XFree86 merge > > > > > > > > Modified files: > > > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > > > radeon_driver.c > > > > Removed files: > > > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > > > radeon_pci.h > > > > > > > > Revision ChangesPath > > > > 1.64 +1 -1 > > > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c > > > > > > After a cvs update -d and make World I get errors during compilation. > > > radeon_pci.h is still included by radeon_dri.c and radeon_probe.c. > > > > > > Time to revive the file? > > > > No. I'm not quite sure why it was added in the first place, as these > > kinds of references should have been made to xf86PciInfo.h anyway. > > Didn't you get my rationale? Is this some kind of guessing game Michel ? I looked at your original commit message and it didn't give any reason why you did it in the first place. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Sun, 2003-09-28 at 18:03, Alan Hourihane wrote: > On Sun, Sep 28, 2003 at 04:33:47PM +0200, Felix Kühling wrote: > > On Fri, 26 Sep 2003 10:26:40 -0700 > > Alan Hourihane <[EMAIL PROTECTED]> wrote: > > > > > CVSROOT: /cvs/dri > > > Module name: xc > > > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > > > Changes by: [EMAIL PROTECTED] 03/09/26 10:26:40 > > > > > > Log message: > > > no longer need radeon_pci.h since the XFree86 merge > > > > > > Modified files: > > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > > radeon_driver.c > > > Removed files: > > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > > radeon_pci.h > > > > > > Revision ChangesPath > > > 1.64 +1 -1 > > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c > > > > After a cvs update -d and make World I get errors during compilation. > > radeon_pci.h is still included by radeon_dri.c and radeon_probe.c. > > > > Time to revive the file? > > No. I'm not quite sure why it was added in the first place, as these > kinds of references should have been made to xf86PciInfo.h anyway. Didn't you get my rationale? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Sun, Sep 28, 2003 at 04:33:47PM +0200, Felix Kühling wrote: > On Fri, 26 Sep 2003 10:26:40 -0700 > Alan Hourihane <[EMAIL PROTECTED]> wrote: > > > CVSROOT:/cvs/dri > > Module name:xc > > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > > Changes by: [EMAIL PROTECTED] 03/09/26 10:26:40 > > > > Log message: > > no longer need radeon_pci.h since the XFree86 merge > > > > Modified files: > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > radeon_driver.c > > Removed files: > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > radeon_pci.h > > > > Revision ChangesPath > > 1.64 +1 -1 > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c > > After a cvs update -d and make World I get errors during compilation. > radeon_pci.h is still included by radeon_dri.c and radeon_probe.c. > > Time to revive the file? No. I'm not quite sure why it was added in the first place, as these kinds of references should have been made to xf86PciInfo.h anyway. So, I've fixed these files to include it. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Sun, 2003-09-28 at 18:02, Alan Hourihane wrote: > > Log message: > remove radeon_pci.h and add xf86PciInfo.h No comment on the rationale why I added radeon_pci.h? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
just remove the '#include radeon_pci.h' line from those files. Also radeon_dri.c contains some references to AMD_SOMETHING that is undefined. if you comment out that statement all works fine. Alex --- Felix Kühling <[EMAIL PROTECTED]> wrote: > On Fri, 26 Sep 2003 10:26:40 -0700 > Alan Hourihane <[EMAIL PROTECTED]> wrote: > > > CVSROOT:/cvs/dri > > Module name:xc > > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > > Changes by: [EMAIL PROTECTED] 03/09/26 10:26:40 > > > > Log message: > > no longer need radeon_pci.h since the XFree86 merge > > > > Modified files: > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > radeon_driver.c > > Removed files: > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > radeon_pci.h > > > > Revision ChangesPath > > 1.64 +1 -1 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c > > After a cvs update -d and make World I get errors during compilation. > radeon_pci.h is still included by radeon_dri.c and radeon_probe.c. > > Time to revive the file? > > Felix > > __\|/_____ ___ > - > Felix ___\_e -_/___/ __\___/ __\_ You can do anything, >Kühling (_\Ä// /_/ /) just not everything > [EMAIL PROTECTED] \___/ \___/ Uat the same time. > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 26 Sep 2003 10:26:40 -0700 Alan Hourihane <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvs/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > Changes by: [EMAIL PROTECTED] 03/09/26 10:26:40 > > Log message: > no longer need radeon_pci.h since the XFree86 merge > > Modified files: > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > radeon_driver.c > Removed files: > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > radeon_pci.h > > Revision ChangesPath > 1.64 +1 -1 > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c After a cvs update -d and make World I get errors during compilation. radeon_pci.h is still included by radeon_dri.c and radeon_probe.c. Time to revive the file? Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 2003-09-26 at 19:26, Alan Hourihane wrote: > > Log message: > no longer need radeon_pci.h since the XFree86 merge Then it was never needed. I added it in order to * try and confine radeon driver merges between XFree86 and DRI CVS to the ati driver directory (as mentioned in the CVS log of the initial revision) * allow the driver to build against an older SDK -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-09-16 at 13:26, Alan Hourihane wrote: > On Tue, Sep 16, 2003 at 01:05:14PM +0200, Michel Dänzer wrote: > > On Tue, 2003-09-16 at 12:56, Alan Hourihane wrote: > > > On Tue, Sep 16, 2003 at 12:47:55PM +0200, Michel Dänzer wrote: > > > > On Tue, 2003-09-16 at 12:38, Alan Hourihane wrote: > > > > > > > > > > Log message: > > > > > update XFree86 tags & use X_BYTE_ORDER > > > > > > > > Why X_BYTE_ORDER? I thought the drivers were moving to Mesa in the long > > > > run. > > > > > > These are X's Imakefiles and pick up the config from xc/config/cf > > > > I know, but what's the point of defining X_BYTE_ORDER if the drivers > > aren't using it? > > Well, either it must have been used at some point, because the change > I'm making is going from. > > DRI_DEFINES = GlxDefines -DX_BYTE_ORDER=ByteOrder > > to: > > DRI_DEFINES = GlxDefines -DX_BYTE_ORDER=$(X_BYTE_ORDER) > > That's all. I'm not checking it's usage. Ah, I thought you added the definition, should have checked. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Sep 16, 2003 at 01:05:14PM +0200, Michel Dänzer wrote: > On Tue, 2003-09-16 at 12:56, Alan Hourihane wrote: > > On Tue, Sep 16, 2003 at 12:47:55PM +0200, Michel Dänzer wrote: > > > On Tue, 2003-09-16 at 12:38, Alan Hourihane wrote: > > > > > > > > Log message: > > > > update XFree86 tags & use X_BYTE_ORDER > > > > > > Why X_BYTE_ORDER? I thought the drivers were moving to Mesa in the long > > > run. > > > > These are X's Imakefiles and pick up the config from xc/config/cf > > I know, but what's the point of defining X_BYTE_ORDER if the drivers > aren't using it? Well, either it must have been used at some point, because the change I'm making is going from. DRI_DEFINES = GlxDefines -DX_BYTE_ORDER=ByteOrder to: DRI_DEFINES = GlxDefines -DX_BYTE_ORDER=$(X_BYTE_ORDER) That's all. I'm not checking it's usage. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-09-16 at 12:56, Alan Hourihane wrote: > On Tue, Sep 16, 2003 at 12:47:55PM +0200, Michel Dänzer wrote: > > On Tue, 2003-09-16 at 12:38, Alan Hourihane wrote: > > > > > > Log message: > > > update XFree86 tags & use X_BYTE_ORDER > > > > Why X_BYTE_ORDER? I thought the drivers were moving to Mesa in the long > > run. > > These are X's Imakefiles and pick up the config from xc/config/cf I know, but what's the point of defining X_BYTE_ORDER if the drivers aren't using it? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Sep 16, 2003 at 12:47:55PM +0200, Michel Dänzer wrote: > On Tue, 2003-09-16 at 12:38, Alan Hourihane wrote: > > > > Log message: > > update XFree86 tags & use X_BYTE_ORDER > > Why X_BYTE_ORDER? I thought the drivers were moving to Mesa in the long > run. These are X's Imakefiles and pick up the config from xc/config/cf Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-09-16 at 12:38, Alan Hourihane wrote: > > Log message: > update XFree86 tags & use X_BYTE_ORDER Why X_BYTE_ORDER? I thought the drivers were moving to Mesa in the long run. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
> > On which server are you doing these commits? From the looks of it, > > you're doing them on the SourceForge server. I thought we weren't going > > to do that anymore. Is the freedesktop server ready for prime-time > > (i.e., does it have the "latest" CVS ,v files)? > > I guess it doesn't matter at the moment, as Michel tells me that Eric > can't get the latest repository tarball from SF. But now when he does > that he'll get the merged stuff too. yeah sf.net had yet another CVS hickup and lost all the tarballs, it could be a while before they are made available agani.. I think we will need to draw a line in the sand at some point, and pause development for probably a week, so no-one commits anything anywhere, wait about 48 hrs (at least at a guess about 4 days) until the tarball catches up with the frozen CVS, grab tarball, move to freedesktop, start developing again.. afaik the tarballs are generated from the backup server making them about as useful as Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, Sep 12, 2003 at 07:22:31AM -0700, Ian Romanick wrote: > Alan Hourihane wrote: > > >CVSROOT: /cvsroot/dri > >Module name: xc > >Repository: xc/xc/ > >Changes by: [EMAIL PROTECTED] 03/09/12 04:23:10 > > On which server are you doing these commits? From the looks of it, > you're doing them on the SourceForge server. I thought we weren't going > to do that anymore. Is the freedesktop server ready for prime-time > (i.e., does it have the "latest" CVS ,v files)? I guess it doesn't matter at the moment, as Michel tells me that Eric can't get the latest repository tarball from SF. But now when he does that he'll get the merged stuff too. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
Alan Hourihane wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/ Changes by: [EMAIL PROTECTED] 03/09/12 04:23:10 On which server are you doing these commits? From the looks of it, you're doing them on the SourceForge server. I thought we weren't going to do that anymore. Is the freedesktop server ready for prime-time (i.e., does it have the "latest" CVS ,v files)? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
315 is NOT from the 300 series! it will NOT work! that is the new series from sis and has a new core. Check out Thomas' page for more info: http://www.winischhofer.net/linuxsisvga.shtml from the page: "There are currently four groups of SiS VGA controllers: * The old series (5597/5598, 6326/AGP/DVD, 530, 620), * the 300 series (300, 540, 630/S/ST, 730), * the 315 series (315/E/H/PRO, 550, 650, 651, M650, 740, 661FX, M661FX, 741), and * the Xabre series (330)." Alex --- Martin Spott <[EMAIL PROTECTED]> wrote: > Alex Deucher <[EMAIL PROTECTED]> wrote: > > > [...] you can still find > > 300/305 PCI/AGP cards on some websites usually labeled as "sis 305 > > 32mb" or similar. > > Thanks for explaining. I assume I found a card with an SiS 315. > I'll see if it works, otherwise I'll give it to a friend running > Windows ;-) > > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends > are ! > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Alex Deucher <[EMAIL PROTECTED]> wrote: > [...] you can still find > 300/305 PCI/AGP cards on some websites usually labeled as "sis 305 > 32mb" or similar. Thanks for explaining. I assume I found a card with an SiS 315. I'll see if it works, otherwise I'll give it to a friend running Windows ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
There aren't really any major brands that make sis cards that I've heard of... usually they are sold labeled as "3D video card" or "Super VGA card" with no discernable manufacturer on the box. some older oem notebooks (clevos and such) use 630 chips; Sony made slim desktops (LX-700/800/900) for a while with 630s as well. you can still find 300/305 PCI/AGP cards on some websites usually labeled as "sis 305 32mb" or similar. Alex --- Martin Spott <[EMAIL PROTECTED]> wrote: > Alex Deucher <[EMAIL PROTECTED]> wrote: > >> Eric Anholt <[EMAIL PROTECTED]> wrote: > >> > >> > If anyone wants to test, [...] > >> > >> Which video card would you recommend for trying ? I'd see if I can > >> get one, > >> > > An card from the 300 series sis cards should work: > > > 300, 305, 540, 630/S/ST, 730 > > On SiS' website they only talk about the chips themselves. Would > anyone > suggest an AGP card that applies or does this fall under unwanted > commercial promotion ? > > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends > are ! > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Am Montag, 8. September 2003 09:26 schrieb Eric Anholt: > On Sun, 2003-09-07 at 07:42, Dieter Nützel wrote: > > Am Samstag, 6. September 2003 23:29 schrieb Eric Anholt: > > > On Sat, 2003-09-06 at 14:16, Eric Anholt wrote: > > > > CVSROOT:/cvs/dri > > > > Module name:xc > > > > Repository: xc/xc/ > > > > Changes by: [EMAIL PROTECTED] 03/09/06 14:16:32 > > > > > > > > Log message: > > > > Second test of committing in freedesktop.org CVS. > > > > > > > > Modified files: > > > > xc/xc/: > > > > test > > > > > > > > Revision ChangesPath > > > > 1.2 +1 -1 xc/xc/test > > > > > > I've been working with keithp the last couple of days on getting > > > dri.freedesktop.org set up. Anonymous and developer CVS access both > > > work, along with cvsup. Instructions can be found at > > > http://dri.freedesktop.org/ > > > > > > As far as I know, only myself, Michel Dänzer, and Keith Whitwell have > > > made accounts there so far. Again, for existing developers without > > > accounts there, forward [EMAIL PROTECTED] your ssh dsa key and > > > he can set one up for you. > > > > Some progress: > > > > SOURCE/dri-trunk> cd xc/ > > Directory: /tmp/INSTALL/SOURCE/dri-trunk/xc > > > > dri-trunk/xc> cvs update > > protocol error: directory '/cvs/ > > ri/xc/xc/programs/Xserver/hw/xfree86/os-support' not within root > > '/cvs/dri' > > Not sure what would be going on there. I just cvs updated as both > anonymous and as a developer, with no problems. Some hours later, YES. > And it was blazing fast, too. Yes, GREAT! > Actually, what happened with that output there, > "/cvs/ri/xc/xc/..." not "/cvs/dri/xc/xc/..."? Yes, the former. Very weird;-) But I saw a broken ./xc/programs/Xserver/hw/xfreo86 folder (yes, with an 'o'), too... Now, we need some file updates in the "new" CVS tree. [-] Am Dienstag, 9. September 2003 00:22 schrieb Ian Romanick: > Dieter Nützel wrote: > > Building executable /opt/VTK/V4.0/VTK/bin/vtk... > > /usr/X11R6/lib/libGL.so: undefined reference to > > `glXGetContextReadDrawable' collect2: ld returned 1 exit status > > This was fixed by file version 1.59 of lib/GL/glx/glxcmds.c on 9/2. I > can't wait until the anon CVS problems are 100% resolved. :) [-] Thank you very much! -Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Alex Deucher <[EMAIL PROTECTED]> wrote: >> Eric Anholt <[EMAIL PROTECTED]> wrote: >> >> > If anyone wants to test, [...] >> >> Which video card would you recommend for trying ? I'd see if I can >> get one, >> > An card from the 300 series sis cards should work: > 300, 305, 540, 630/S/ST, 730 On SiS' website they only talk about the chips themselves. Would anyone suggest an AGP card that applies or does this fall under unwanted commercial promotion ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Sun, 2003-09-07 at 07:42, Dieter Nützel wrote: > Am Samstag, 6. September 2003 23:29 schrieb Eric Anholt: > > On Sat, 2003-09-06 at 14:16, Eric Anholt wrote: > > > CVSROOT: /cvs/dri > > > Module name: xc > > > Repository: xc/xc/ > > > Changes by: [EMAIL PROTECTED] 03/09/06 14:16:32 > > > > > > Log message: > > > Second test of committing in freedesktop.org CVS. > > > > > > Modified files: > > > xc/xc/: > > > test > > > > > > Revision ChangesPath > > > 1.2 +1 -1 xc/xc/test > > > > I've been working with keithp the last couple of days on getting > > dri.freedesktop.org set up. Anonymous and developer CVS access both > > work, along with cvsup. Instructions can be found at > > http://dri.freedesktop.org/ > > > > As far as I know, only myself, Michel Dänzer, and Keith Whitwell have > > made accounts there so far. Again, for existing developers without > > accounts there, forward [EMAIL PROTECTED] your ssh dsa key and he > > can set one up for you. > > Some progress: > > SOURCE/dri-trunk> cd xc/ > Directory: /tmp/INSTALL/SOURCE/dri-trunk/xc > > dri-trunk/xc> cvs update > protocol error: directory '/cvs/ > ri/xc/xc/programs/Xserver/hw/xfree86/os-support' not within root '/cvs/dri' Not sure what would be going on there. I just cvs updated as both anonymous and as a developer, with no problems. And it was blazing fast, too. Actually, what happened with that output there, "/cvs/ri/xc/xc/..." not "/cvs/dri/xc/xc/..."? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Am Samstag, 6. September 2003 23:29 schrieb Eric Anholt: > On Sat, 2003-09-06 at 14:16, Eric Anholt wrote: > > CVSROOT:/cvs/dri > > Module name:xc > > Repository: xc/xc/ > > Changes by: [EMAIL PROTECTED] 03/09/06 14:16:32 > > > > Log message: > > Second test of committing in freedesktop.org CVS. > > > > Modified files: > > xc/xc/: > > test > > > > Revision ChangesPath > > 1.2 +1 -1 xc/xc/test > > I've been working with keithp the last couple of days on getting > dri.freedesktop.org set up. Anonymous and developer CVS access both > work, along with cvsup. Instructions can be found at > http://dri.freedesktop.org/ > > As far as I know, only myself, Michel Dänzer, and Keith Whitwell have > made accounts there so far. Again, for existing developers without > accounts there, forward [EMAIL PROTECTED] your ssh dsa key and he > can set one up for you. Some progress: SOURCE/dri-trunk> cd xc/ Directory: /tmp/INSTALL/SOURCE/dri-trunk/xc dri-trunk/xc> cvs update protocol error: directory '/cvs/ ri/xc/xc/programs/Xserver/hw/xfree86/os-support' not within root '/cvs/dri' Regards, Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Sat, 2003-09-06 at 14:16, Eric Anholt wrote: > CVSROOT: /cvs/dri > Module name: xc > Repository: xc/xc/ > Changes by: [EMAIL PROTECTED] 03/09/06 14:16:32 > > Log message: > Second test of committing in freedesktop.org CVS. > > Modified files: > xc/xc/: > test > > Revision ChangesPath > 1.2 +1 -1 xc/xc/test I've been working with keithp the last couple of days on getting dri.freedesktop.org set up. Anonymous and developer CVS access both work, along with cvsup. Instructions can be found at http://dri.freedesktop.org/ As far as I know, only myself, Michel Dänzer, and Keith Whitwell have made accounts there so far. Again, for existing developers without accounts there, forward [EMAIL PROTECTED] your ssh dsa key and he can set one up for you. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
An card from the 300 series sis cards should work: 300, 305, 540, 630/S/ST, 730 Alex --- Martin Spott <[EMAIL PROTECTED]> wrote: > Eric Anholt <[EMAIL PROTECTED]> wrote: > > > If anyone wants to test, [...] > > Which video card would you recommend for trying ? I'd see if I can > get > one, > > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends > are ! > -- > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Eric Anholt <[EMAIL PROTECTED]> wrote: > If anyone wants to test, [...] Which video card would you recommend for trying ? I'd see if I can get one, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 2003-09-05 at 17:02, Eric Anholt wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/sis/ > Changes by: [EMAIL PROTECTED] 03/09/05 17:02:09 > > Log message: > Update the SiS DRI driver for Mesa 5. The updated driver is MMIO-only (though > it works on AGP cards), but AGP support is expected to follow. Until then the > old render files (sis_render.c, sis_linefunc.h, sis_trifunc.h) are left around. > Includes many whitespace changes, which I apologize for. It will remain > disconnected from the build until more widespread testing is done. This is the current state of my update for the SiS. I've done as much testing of it as I can, and I'm down to the following things on my TODO: - Re-add using AGP for vertices (this is a major speed issue I think) - Figure out why the game part of quake3 doesn't work. - Implement GL extensions. If anyone wants to test, edit xc/config/cf/host.def and add sis to XF86CardDrivers and DriDrivers and make World ; make install. Most likely you'll want the updated DRM, which allows for DRI without sisfb. I'm interested in anything that doesn't work right or doesn't match software. Software can be tested withthe environment variable LIBGL_ALWAYS_INDIRECT=1 set, or using SIS_FORCE_FALLBACK=1 which uses the software fallbacks in the driver. I'd like to thank LinuxFund for sponsoring this work. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
Ian Romanick <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/glx/ > Changes by: [EMAIL PROTECTED] 03/09/02 14:47:24 > Log message: > Fixed a typo that caused problems linking (but not running) > applications. Thanks a lot - I was already a bit deranged because some 'configure' script did not correctly detect presence of OpenGL support Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Mon, 2001-11-26 at 15:59, Keith Whitwell wrote: > Michel Dänzer wrote: > > > > On Mon, 2001-11-26 at 14:28, Keith Whitwell wrote: > > > > > Log message: > > > Put drm version back from 3.0 to 2.2; XFree86 4.1 is the baseline for > > > versioning information. > > > > > > Modified files: > > > xc/xc/lib/GL/mesa/src/drv/r128/: > > > r128_xmesa.c > > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > > r128_dri.c > > > xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: > > > r128_drv.c > > > > > > Revision ChangesPath > > > 1.25 +3 -3 xc/xc/lib/GL/mesa/src/drv/r128/r128_xmesa.c > > > 1.27 +3 -3 >xc/xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c > > > 1.42 +2 -2 >xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_drv.c > > > > But you're aware that the major should have been bumped for 4.1 already? > > It doesn't work with 4.0.x DRM and vice versa. > > Yes. That's life. What's important is compatibility of future versions with > 4.1. 4.0 is a lost cause. Bumping the version number now doesn't make up for > not doing it earlier, and even worse, we've promised not to bump the version > numbers from the 4.1 base line without *extremely* good reason. Keith, David, I hadn't looked at it that way, but it's of course very reasonable. Thanks for explaining. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk) 4.1.0
Hello, UT show the same texture corruption running XFree86 DRI 4.1.0 (after David's update) with the tdfx driver (V5 5500, 1280x1024x24) as I reported some days ago for the trunk-branch. Every other thing I've tested looks OK. Even Xv (good work Alan). But I have some Linux 2.4.5-ac14 shm problems, now. Read my post here about it or at LKM. Regards, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
