Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
Branden Robinson wrote: > I think the original code from patch #100 is wrong, so I am dropping > that hunk of the patch, and patch #400 entirely since it just #ifdefs > off the patch I'm dropping. Since I did the original hacking to build xfree86 for hppa, I might be responsible for that. But I can't check. "apt-get source xfree86" gets me 4.1.0-17 sources. Where are you hiding the 4.2.x sources? Sorry, I just don't have time to hunt them down. FWIW, I am running 4.2.x-3 bits on a B180 using FB driver. I think Ishikawa built the debs a week or two ago but didn't save the URL where they came from. > I will want to hear from Mach64 users on SPARC, m68k, and HP-PA as to > what the effects of my changes are. (I'm pretty sure it will compile, > since I'm essentially restoring this part atimach64.c to its current > state on xf-4_2-branch.) FWIW, ati was never an HP official supported device for hppa. thanks, grant
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
On Mon, Sep 02, 2002 at 01:53:34AM +0200, Michel Dänzer wrote: > MMIO_OUT32 would probably be the macro for this. The original code did this: switch (iDWord) { case 0: MMIO_MOVE32(pDst + 0, 0, *(pSrc + 0)); case 1: MMIO_MOVE32(pDst + 1, 0, *(pSrc + 1)); case 2: MMIO_MOVE32(pDst + 2, 0, *(pSrc + 2)); etc. -- G. Branden Robinson| "I came, I saw, she conquered." Debian GNU/Linux | The original Latin seems to have [EMAIL PROTECTED] | been garbled. http://people.debian.org/~branden/ | -- Robert Heinlein pgp5MK6MEw14j.pgp Description: PGP signature
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
On Mon, 2002-09-02 at 01:29, Branden Robinson wrote: > On Sun, Aug 25, 2002 at 02:20:17AM +0900, ISHIKAWA Mutsumi wrote: > > On m68k, mac64 dynamic loading driver cannot have worked from > > before. Because xf86WriteMmio32Be is not defined anywhere. > > > > Perhaps, we should define xf86WriteMmio32Be function in > > xc/programs/Xserver/hw/xfree86/common/compiler.h. > > I think this is a bug in ati/atimach64.c: > > apocalypse:~/packages/xfree86/4.2.0/xfree86-4.2.0/build-tree/xc/programs/Xserver/hw/xfree86> > grep -r xf86WriteMmio32Be * > common/compiler.h:xf86WriteMmio32Be(__volatile__ void *base, const unsigned > long offset, > common/compiler.h:xf86WriteMmio32BeNB(__volatile__ void *base, const unsigned > long offset, > common/compiler.h:xf86WriteMmio32Be(__volatile__ void *base, const unsigned > long offset, > common/compiler.h:xf86WriteMmio32Be(__volatile__ void *base, const unsigned > long offset, > common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) > common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) > common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) > common/compiler.h:xf86WriteMmio32BeNB(base, offset, (CARD32)(val)) > common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) > drivers/ati/atimach64.c:case 0: xf86WriteMmio32Be(pDst + > 0, 0, *(pSrc + 0)); > drivers/ati/atimach64.c:case 1: xf86WriteMmio32Be(pDst + > 1, 0, *(pSrc + 1)); > drivers/ati/atimach64.c:case 2: xf86WriteMmio32Be(pDst + > 2, 0, *(pSrc + 2)); > drivers/ati/atimach64.c:case 3: xf86WriteMmio32Be(pDst + > 3, 0, *(pSrc + 3)); > drivers/ati/atimach64.c:case 4: xf86WriteMmio32Be(pDst + > 4, 0, *(pSrc + 4)); > drivers/ati/atimach64.c:case 5: xf86WriteMmio32Be(pDst + > 5, 0, *(pSrc + 5)); > drivers/ati/atimach64.c:case 6: xf86WriteMmio32Be(pDst + > 6, 0, *(pSrc + 6)); > drivers/ati/atimach64.c:case 7: xf86WriteMmio32Be(pDst + > 7, 0, *(pSrc + 7)); > drivers/ati/atimach64.c:case 8: xf86WriteMmio32Be(pDst + > 8, 0, *(pSrc + 8)); > drivers/ati/atimach64.c:case 9: xf86WriteMmio32Be(pDst + > 9, 0, *(pSrc + 9)); > drivers/ati/atimach64.c:case 10: xf86WriteMmio32Be(pDst + > 10, 0, *(pSrc + 10)); > drivers/ati/atimach64.c:case 11: xf86WriteMmio32Be(pDst + > 11, 0, *(pSrc + 11)); > drivers/ati/atimach64.c:case 12: xf86WriteMmio32Be(pDst + > 12, 0, *(pSrc + 12)); > drivers/ati/atimach64.c:case 13: xf86WriteMmio32Be(pDst + > 13, 0, *(pSrc + 13)); > drivers/ati/atimach64.c:case 14: xf86WriteMmio32Be(pDst + > 14, 0, *(pSrc + 14)); > drivers/ati/atimach64.c:case 15: xf86WriteMmio32Be(pDst + > 15, 0, *(pSrc + 15)); > > This file is the only part of any XFree86 video driver code that ever > references any of the xf86WriteMmio functions. > > The other files that reference them are: > > loader/xf86sym.c > os-support/bsd/bsd_video.c > os-support/linux/lnx_video.c > > Therefore I get the feeling that atimach64.c is doing something wrong. > compiler.h does go to a lot of trouble to set up macros that expand to > these various functions. MMIO_OUT32 would probably be the macro for this. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
[Please followup to debian-x. I am not subscribed to debian-hppa.] On Sun, Sep 01, 2002 at 06:29:44PM -0500, Branden Robinson wrote: > On Sun, Aug 25, 2002 at 02:20:17AM +0900, ISHIKAWA Mutsumi wrote: > > On m68k, mac64 dynamic loading driver cannot have worked from > > before. Because xf86WriteMmio32Be is not defined anywhere. > > > > Perhaps, we should define xf86WriteMmio32Be function in > > xc/programs/Xserver/hw/xfree86/common/compiler.h. > > I think this is a bug in ati/atimach64.c: > > apocalypse:~/packages/xfree86/4.2.0/xfree86-4.2.0/build-tree/xc/programs/Xserver/hw/xfree86> > grep -r xf86WriteMmio32Be * > common/compiler.h:xf86WriteMmio32Be(__volatile__ void *base, const unsigned > long offset, > common/compiler.h:xf86WriteMmio32BeNB(__volatile__ void *base, const unsigned > long offset, > common/compiler.h:xf86WriteMmio32Be(__volatile__ void *base, const unsigned > long offset, > common/compiler.h:xf86WriteMmio32Be(__volatile__ void *base, const unsigned > long offset, > common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) > common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) > common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) > common/compiler.h:xf86WriteMmio32BeNB(base, offset, (CARD32)(val)) > common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) > drivers/ati/atimach64.c:case 0: xf86WriteMmio32Be(pDst + > 0, 0, *(pSrc + 0)); > drivers/ati/atimach64.c:case 1: xf86WriteMmio32Be(pDst + > 1, 0, *(pSrc + 1)); > drivers/ati/atimach64.c:case 2: xf86WriteMmio32Be(pDst + > 2, 0, *(pSrc + 2)); > drivers/ati/atimach64.c:case 3: xf86WriteMmio32Be(pDst + > 3, 0, *(pSrc + 3)); > drivers/ati/atimach64.c:case 4: xf86WriteMmio32Be(pDst + > 4, 0, *(pSrc + 4)); > drivers/ati/atimach64.c:case 5: xf86WriteMmio32Be(pDst + > 5, 0, *(pSrc + 5)); > drivers/ati/atimach64.c:case 6: xf86WriteMmio32Be(pDst + > 6, 0, *(pSrc + 6)); > drivers/ati/atimach64.c:case 7: xf86WriteMmio32Be(pDst + > 7, 0, *(pSrc + 7)); > drivers/ati/atimach64.c:case 8: xf86WriteMmio32Be(pDst + > 8, 0, *(pSrc + 8)); > drivers/ati/atimach64.c:case 9: xf86WriteMmio32Be(pDst + > 9, 0, *(pSrc + 9)); > drivers/ati/atimach64.c:case 10: xf86WriteMmio32Be(pDst + > 10, 0, *(pSrc + 10)); > drivers/ati/atimach64.c:case 11: xf86WriteMmio32Be(pDst + > 11, 0, *(pSrc + 11)); > drivers/ati/atimach64.c:case 12: xf86WriteMmio32Be(pDst + > 12, 0, *(pSrc + 12)); > drivers/ati/atimach64.c:case 13: xf86WriteMmio32Be(pDst + > 13, 0, *(pSrc + 13)); > drivers/ati/atimach64.c:case 14: xf86WriteMmio32Be(pDst + > 14, 0, *(pSrc + 14)); > drivers/ati/atimach64.c:case 15: xf86WriteMmio32Be(pDst + > 15, 0, *(pSrc + 15)); > > This file is the only part of any XFree86 video driver code that ever > references any of the xf86WriteMmio functions. > > The other files that reference them are: > > loader/xf86sym.c > os-support/bsd/bsd_video.c > os-support/linux/lnx_video.c > > Therefore I get the feeling that atimach64.c is doing something wrong. > compiler.h does go to a lot of trouble to set up macros that expand to > these various functions. > > I'll see if I can puzzle it out. I found the problem. It's a Debianism. The inappropriate xf86WriteMmio32Be() stuff comes from patch #100, PCI domain support, applied for the benefit of our SPARC users. Patch #400 turns that stuff off for hppa. I think the original code from patch #100 is wrong, so I am dropping that hunk of the patch, and patch #400 entirely since it just #ifdefs off the patch I'm dropping. I will want to hear from Mach64 users on SPARC, m68k, and HP-PA as to what the effects of my changes are. (I'm pretty sure it will compile, since I'm essentially restoring this part atimach64.c to its current state on xf-4_2-branch.) This code path is excercised in accelerated color expansion fills, so a good test case is probably some fast text scrolling in an xterm with XAA enabled. (I.e., make sure you're not disabling acceleration in your XF86Config-4 file.) -- G. Branden Robinson|The first thing the communists do Debian GNU/Linux |when they take over a country is to [EMAIL PROTECTED] |outlaw cockfighting. http://people.debian.org/~branden/ |-- Oklahoma State Senator John Monks pgp5V6RwfbRUV.pgp Description: PGP signature
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
On Sun, Aug 25, 2002 at 02:20:17AM +0900, ISHIKAWA Mutsumi wrote: > On m68k, mac64 dynamic loading driver cannot have worked from > before. Because xf86WriteMmio32Be is not defined anywhere. > > Perhaps, we should define xf86WriteMmio32Be function in > xc/programs/Xserver/hw/xfree86/common/compiler.h. I think this is a bug in ati/atimach64.c: apocalypse:~/packages/xfree86/4.2.0/xfree86-4.2.0/build-tree/xc/programs/Xserver/hw/xfree86> grep -r xf86WriteMmio32Be * common/compiler.h:xf86WriteMmio32Be(__volatile__ void *base, const unsigned long offset, common/compiler.h:xf86WriteMmio32BeNB(__volatile__ void *base, const unsigned long offset, common/compiler.h:xf86WriteMmio32Be(__volatile__ void *base, const unsigned long offset, common/compiler.h:xf86WriteMmio32Be(__volatile__ void *base, const unsigned long offset, common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) common/compiler.h:xf86WriteMmio32BeNB(base, offset, (CARD32)(val)) common/compiler.h:xf86WriteMmio32Be(base, offset, (CARD32)(val)) drivers/ati/atimach64.c:case 0: xf86WriteMmio32Be(pDst + 0, 0, *(pSrc + 0)); drivers/ati/atimach64.c:case 1: xf86WriteMmio32Be(pDst + 1, 0, *(pSrc + 1)); drivers/ati/atimach64.c:case 2: xf86WriteMmio32Be(pDst + 2, 0, *(pSrc + 2)); drivers/ati/atimach64.c:case 3: xf86WriteMmio32Be(pDst + 3, 0, *(pSrc + 3)); drivers/ati/atimach64.c:case 4: xf86WriteMmio32Be(pDst + 4, 0, *(pSrc + 4)); drivers/ati/atimach64.c:case 5: xf86WriteMmio32Be(pDst + 5, 0, *(pSrc + 5)); drivers/ati/atimach64.c:case 6: xf86WriteMmio32Be(pDst + 6, 0, *(pSrc + 6)); drivers/ati/atimach64.c:case 7: xf86WriteMmio32Be(pDst + 7, 0, *(pSrc + 7)); drivers/ati/atimach64.c:case 8: xf86WriteMmio32Be(pDst + 8, 0, *(pSrc + 8)); drivers/ati/atimach64.c:case 9: xf86WriteMmio32Be(pDst + 9, 0, *(pSrc + 9)); drivers/ati/atimach64.c:case 10: xf86WriteMmio32Be(pDst + 10, 0, *(pSrc + 10)); drivers/ati/atimach64.c:case 11: xf86WriteMmio32Be(pDst + 11, 0, *(pSrc + 11)); drivers/ati/atimach64.c:case 12: xf86WriteMmio32Be(pDst + 12, 0, *(pSrc + 12)); drivers/ati/atimach64.c:case 13: xf86WriteMmio32Be(pDst + 13, 0, *(pSrc + 13)); drivers/ati/atimach64.c:case 14: xf86WriteMmio32Be(pDst + 14, 0, *(pSrc + 14)); drivers/ati/atimach64.c:case 15: xf86WriteMmio32Be(pDst + 15, 0, *(pSrc + 15)); This file is the only part of any XFree86 video driver code that ever references any of the xf86WriteMmio functions. The other files that reference them are: loader/xf86sym.c os-support/bsd/bsd_video.c os-support/linux/lnx_video.c Therefore I get the feeling that atimach64.c is doing something wrong. compiler.h does go to a lot of trouble to set up macros that expand to these various functions. I'll see if I can puzzle it out. -- G. Branden Robinson| Q: How does a Unix guru have sex? Debian GNU/Linux | A: unzip;strip;touch;finger;mount; [EMAIL PROTECTED] |fsck;more;yes;fsck;fsck;fsck; http://people.debian.org/~branden/ |umount;sleep pgpQwq9fyZnuY.pgp Description: PGP signature
Re: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
On Mon, 2002-08-26 at 14:36, Scott Henson wrote: > On Mon, 2002-08-26 at 03:46, Michel Dänzer wrote: > > On Mon, 2002-08-26 at 04:27, Scott Henson wrote: > > > > and I cannot start it with startx as a normal user, though root can. > > > xinit does bring up XF86 though. When using startx the x server fails > > > silently with out any errors or warnings. I also cannot find a > > > difference in the log files between startx as a normal user and startx > > > as root. > > > > Weird. I haven't had any problems like that so without more information > > I can't really do anything. > > What information do you need? When I type startx as a normal user the > xserver looks like its going to start up then just dies with the only > message on the screen being that It is waiting for X to die. That's what it says at the end of the session, so it sounds like there's a problem with the session, and it aborts. Anything in ~/.xsession-errors? > I can use xinit to start the xserver as the normal user then start a > gnome-session from the xterm. Or xinit /usr/bin/gnome-session . > > > I also have noticed a slow down in the system as a whole. > > > > Can you be more specific? At least the operation of the X server should > > definitely become faster or in the worst case stay the same... > > I thought this as well, but the system operation as a whole is much > slower than with the old xfree86 debs. There is more memory usage(main > memory not the card's memory) Did you use the DRI before? It uses 8 megs of RAM for DMA buffers etc. > as well as programs taking forever to start. Before I could expect things > like galeon to come up in less than 5 seconds but now it is taking as > much as 20 seconds. I dont know if this is directly related to the > xserver, but it wasnt happening till after I instaled it. It's hardly directly related. Could rather be because there's less RAM available? > Though the lines that appeared after windows while dragging them have > significantly diminished as well as a few other annoyances with the > old xserver. These sound like bugs, have you reported them? > Is there anyway I can tell for sure if Im using hardware acceleration? Look at the log. > A way to turn it on if Im not? It's on by default so you'd have to deliberately turn it off. (2D acceleration; 3D is another story. Please read some documentation like the DRI user guide on http://dri.sf.net if you want to know about that) > > > Maybe someone could tell me how to simply remove these debs and replace > > > them with Branden's(which work wonderfully without any problems on this > > > system). > > > > sudo apt-get remove xserver-xfree86-dri-trunk xlibmesa3+ > > This was the first thing I tried, but it wants to remove about 80 other > packages that Im guessing depend on having an xserver installed. xserver-xfree86-dri-trunk depends on xserver-xfree86... did you have the xlibmesa3+ ? > I still would like to get hardware acceleration working, but is there > anyway to switch between the two? Like using update alternatives to > point to Branden's xserver and switch it to accelerated xserver when I > want the hardware acceleration? Thanks. Sure, either just enable or disable the DRI as you wish or install or remove xserver-xfree86-dri-trunk and friends. I personally don't see the point in giving up 3D acceleration as well as 2D performance for no benefit (except a bit of stability maybe) though... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Re : xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
Updated sources.list, apt-get update and then dist-upgrade. Worked fine, no problems during the upgrade. Runs great, not experienced any problems, thus far. One point of interest though : >From running startx, gnome (1.4) launches much quicker than on XF86 4.1.x (used to be about 10 secs from startx > gnome splash screen - it's now about 2 sec - thanks!). System is running unstable, P3 750, Radeon (1st gen) 32MB.
Re: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
On Mon, 2002-08-26 at 03:46, Michel Dänzer wrote: > On Mon, 2002-08-26 at 04:27, Scott Henson wrote: > > > GATOS doesn't do 2D acceleration AFAIK, don't you mean 3D anyway? > > > > > > Either way, try > > > > > > deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ > > > > I upgraded recently to these deb on my radeon 7000 system. Now after > > upgrade XF86 no longer comes up automatically > > You mean with a display manager? Beware that these debs are missing the > XdmAuth code which xdm and others use by default; at least xdm can be > set up to work without it though. Makes sense. Im the only one using the machine so not a big problem. > > and I cannot start it with startx as a normal user, though root can. > > xinit does bring up XF86 though. When using startx the x server fails > > silently with out any errors or warnings. I also cannot find a > > difference in the log files between startx as a normal user and startx > > as root. > > Weird. I haven't had any problems like that so without more information > I can't really do anything. What information do you need? When I type startx as a normal user the xserver looks like its going to start up then just dies with the only message on the screen being that It is waiting for X to die. Then when I startx as root the server comes up and everything works properly, except for the fact that KDE freezes and the xserver has to be killed. Root seems to have KDE setup as its default environment(probably because Im using KDM) and I have gnome-session setup as mine. I diffed the XFree86.0.log s from each time and I did not get any difference except the header line which contained the time. I can use xinit to start the xserver as the normal user then start a gnome-session from the xterm. Then everything seems to work just fine. > > I also have noticed a slow down in the system as a whole. > > Can you be more specific? At least the operation of the X server should > definitely become faster or in the worst case stay the same... I thought this as well, but the system operation as a whole is much slower than with the old xfree86 debs. There is more memory usage(main memory not the card's memory) as well as programs taking forever to start. Before I could expect things like galeon to come up in less than 5 seconds but now it is taking as much as 20 seconds. I dont know if this is directly related to the xserver, but it wasnt happening till after I instaled it. Though the lines that appeared after windows while dragging them have significantly diminished as well as a few other annoyances with the old xserver. Is there anyway I can tell for sure if Im using hardware acceleration? A way to turn it on if Im not? > > Maybe someone could tell me how to simply remove these debs and replace > > them with Branden's(which work wonderfully without any problems on this > > system). > > sudo apt-get remove xserver-xfree86-dri-trunk xlibmesa3+ This was the first thing I tried, but it wants to remove about 80 other packages that Im guessing depend on having an xserver installed. I still do have Branden's debs installed, but it still wants to remove a bunch of packages. I still would like to get hardware acceleration working, but is there anyway to switch between the two? Like using update alternatives to point to Branden's xserver and switch it to accelerated xserver when I want the hardware acceleration? Thanks. -- -Peace kid Scott Henson [EMAIL PROTECTED] "God's the ultimate playa, so naturally He's going to have some haters," rapper Ice Cube said. "But these haters need to realize that if you mess with the man upstairs, you will get your ass smote. True dat."
Re: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
On Mon, 2002-08-26 at 04:27, Scott Henson wrote: > On Sat, 2002-08-24 at 21:08, Michel Dänzer wrote: > > On Sun, 2002-08-25 at 02:55, Csan wrote: > > > > > > > > is there any chance for gatos deb's for i386 and powerpc? > > > > > > > What do you need it for? If it's about Mach64, try > > > > > > > deb http://penguinppc.org/~daenzer/debian/dri-mach64/ ./ > > > > > > I would need 2d acceleration for my ATI Radeon 7200 (VIVO 64MB DDR) very > > > bad. > > > I'd like to dive myself into Quake 3 mapping with GTKRadiant map editor, > > > but I > > > can't since the ati driver shipped with the current xserver, does not > > > contains > > > any 2d acceleration... > > > > > > Are there any plans for integrating gatos 2d aacceleration into the xfree6 > > > project's next debian release. > > > > GATOS doesn't do 2D acceleration AFAIK, don't you mean 3D anyway? > > > > Either way, try > > > > deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ > > I upgraded recently to these deb on my radeon 7000 system. Now after > upgrade XF86 no longer comes up automatically You mean with a display manager? Beware that these debs are missing the XdmAuth code which xdm and others use by default; at least xdm can be set up to work without it though. > and I cannot start it with startx as a normal user, though root can. > xinit does bring up XF86 though. When using startx the x server fails > silently with out any errors or warnings. I also cannot find a > difference in the log files between startx as a normal user and startx > as root. Weird. I haven't had any problems like that so without more information I can't really do anything. > I also have noticed a slow down in the system as a whole. Can you be more specific? At least the operation of the X server should definitely become faster or in the worst case stay the same... > Maybe someone could tell me how to simply remove these debs and replace > them with Branden's(which work wonderfully without any problems on this > system). sudo apt-get remove xserver-xfree86-dri-trunk xlibmesa3+ -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Re: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
On Sat, 2002-08-24 at 21:08, Michel Dänzer wrote: > On Sun, 2002-08-25 at 02:55, Csan wrote: > > > > > > is there any chance for gatos deb's for i386 and powerpc? > > > > > What do you need it for? If it's about Mach64, try > > > > > deb http://penguinppc.org/~daenzer/debian/dri-mach64/ ./ > > > > I would need 2d acceleration for my ATI Radeon 7200 (VIVO 64MB DDR) very > > bad. > > I'd like to dive myself into Quake 3 mapping with GTKRadiant map editor, > > but I > > can't since the ati driver shipped with the current xserver, does not > > contains > > any 2d acceleration... > > > > Are there any plans for integrating gatos 2d aacceleration into the xfree6 > > project's next debian release. > > GATOS doesn't do 2D acceleration AFAIK, don't you mean 3D anyway? > > Either way, try > > deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ I upgraded recently to these deb on my radeon 7000 system. Now after upgrade XF86 no longer comes up automatically and I cannot start it with startx as a normal user, though root can. xinit does bring up XF86 though. When using startx the x server fails silently with out any errors or warnings. I also cannot find a difference in the log files between startx as a normal user and startx as root. I also have noticed a slow down in the system as a whole. Any advice on what I should do? Maybe someone could tell me how to simply remove these debs and replace them with Branden's(which work wonderfully without any problems on this system). I would appreciate any help I could get. Thankyou. -- -Peace kid Scott Henson [EMAIL PROTECTED]
Re: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
Hey guys, Michael's dri-trunk stuff works. Splendid... ! This is actually the first time GTKRadiant and Quake3 works at the same time! I am extremely excited and thankful to you. (Especially Michael? :)) And thanks for the explanatin, Mike, it helped a lot to understand what was going on. :) I'd already tried to use the gatos binaries in my Debian context several times before, but I could never get both Quake3 and GTKRadiant to run without having to switch back and forth between the gatos and debian ati drivers (maybe I hadn't tried disabling DRI, but that is now all history for me). I'm looking forward to a clean XFre86 4.3.0 .deb set (when does the 6 months devcycle end? :)) Keep up the good work! and take care... I'm heading back now enjoying Quake3 mapping :) Cheers, Csan Janos Holanyi Association of Hungarian Linux Users Email: csaniATlme.linux.hu Quoting Michel Dänzer <[EMAIL PROTECTED]>: > On Sun, 2002-08-25 at 07:20, Mike A. Harris wrote: > > > > > >I would need 2d acceleration for my ATI Radeon 7200 (VIVO 64MB DDR) very > bad. > > >I'd like to dive myself into Quake 3 mapping with GTKRadiant map editor, > but I > > >can't since the ati driver shipped with the current xserver, does not > contains > > >any 2d acceleration... > > > > > >Are there any plans for integrating gatos 2d aacceleration into the > xfree6 > > >project's next debian release. > > > > Radeon 2D acceleration is implemented in two different ways. The > > first method, MMIO, is used when DRI is disabled. The second > > way, uses the Radeon CP engine, and is only used when DRI is > > enabled. > > > > The problem though, is that the CP engine 2D code was not as > > fully implemented as the MMIO code was, so earlier XFree86 > > releases will show a slowdown in 2D acceleration when DRI is > > enabled. XFree86 4.2.0 has the situation improved slightly, but > > it still isn't up to par with the MMIO code. Michel Daenzer has > > implemented a bit more of the CP 2D code in DRI-CVS, which brings > > the CP 2D code much closer to the level of the MMIO codepath. > > In fact, on the reinit-0-0-1-branch in DRI CVS, I've brought it up to > par (in terms of accelerated operations - the CP is faster of course :). > I hope this will get into 4.3.0. > > > > I've got a patch for 4.2.0 to add the latest code, however it was > > reported as not fully working so I disabled it until I have time > > to debug/troubleshoot. > > Can you be a bit more specific than 'not fully working'? > > > If anyone wants a copy of the patch, let me know and I'll put it up on > FTP. > > I'd be interested to see the patch if there are problems with it. > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > - This mail sent through IMP: http://horde.org/imp/
Re: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
On Sun, 2002-08-25 at 15:13, Mike A. Harris wrote: > On 25 Aug 2002, Michel Dänzer wrote: > > >> I've got a patch for 4.2.0 to add the latest code, however it was > >> reported as not fully working so I disabled it until I have time > >> to debug/troubleshoot. > > > >Can you be a bit more specific than 'not fully working'? > > Not currently.. I put the patch in, and did a build.. I got > internal complaints X was broken shortly after, so I disabled the > patch and rebuilt. Haven't had time to investigate it since. If > I get time though, I'll provide feedback. It could be something > I screwed up backporting it. > > > >> If anyone wants a copy of the patch, let me know and I'll put it up on FTP. > > > >I'd be interested to see the patch if there are problems with it. > > Sure thing.. > > ftp://people.redhat.com/mharris/testing/bleeding-edge/XFree86/4.2.0-67/raw-sources-patches-specfile/ > > The patch is: > > XFree86-4.2.0-ati-radeon-cp-colorexpansion-imagewrite-enhancement.patch Hmm, it may not work properly without other enhancements I've made to the CP handling in DRI CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Re: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
On 25 Aug 2002, Michel Dänzer wrote: >> >Are there any plans for integrating gatos 2d aacceleration into the xfree6 >> >project's next debian release. >> >> Radeon 2D acceleration is implemented in two different ways. The >> first method, MMIO, is used when DRI is disabled. The second >> way, uses the Radeon CP engine, and is only used when DRI is >> enabled. >> >> The problem though, is that the CP engine 2D code was not as >> fully implemented as the MMIO code was, so earlier XFree86 >> releases will show a slowdown in 2D acceleration when DRI is >> enabled. XFree86 4.2.0 has the situation improved slightly, but >> it still isn't up to par with the MMIO code. Michel Daenzer has >> implemented a bit more of the CP 2D code in DRI-CVS, which brings >> the CP 2D code much closer to the level of the MMIO codepath. > >In fact, on the reinit-0-0-1-branch in DRI CVS, I've brought it up to >par (in terms of accelerated operations - the CP is faster of course :). >I hope this will get into 4.3.0. Fantastic! >> I've got a patch for 4.2.0 to add the latest code, however it was >> reported as not fully working so I disabled it until I have time >> to debug/troubleshoot. > >Can you be a bit more specific than 'not fully working'? Not currently.. I put the patch in, and did a build.. I got internal complaints X was broken shortly after, so I disabled the patch and rebuilt. Haven't had time to investigate it since. If I get time though, I'll provide feedback. It could be something I screwed up backporting it. >> If anyone wants a copy of the patch, let me know and I'll put it up on FTP. > >I'd be interested to see the patch if there are problems with it. Sure thing.. ftp://people.redhat.com/mharris/testing/bleeding-edge/XFree86/4.2.0-67/raw-sources-patches-specfile/ The patch is: XFree86-4.2.0-ati-radeon-cp-colorexpansion-imagewrite-enhancement.patch Thanks Michel, TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris
Re: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
On Sun, 2002-08-25 at 07:20, Mike A. Harris wrote: > > > >I would need 2d acceleration for my ATI Radeon 7200 (VIVO 64MB DDR) very bad. > >I'd like to dive myself into Quake 3 mapping with GTKRadiant map editor, but > >I > >can't since the ati driver shipped with the current xserver, does not > >contains > >any 2d acceleration... > > > >Are there any plans for integrating gatos 2d aacceleration into the xfree6 > >project's next debian release. > > Radeon 2D acceleration is implemented in two different ways. The > first method, MMIO, is used when DRI is disabled. The second > way, uses the Radeon CP engine, and is only used when DRI is > enabled. > > The problem though, is that the CP engine 2D code was not as > fully implemented as the MMIO code was, so earlier XFree86 > releases will show a slowdown in 2D acceleration when DRI is > enabled. XFree86 4.2.0 has the situation improved slightly, but > it still isn't up to par with the MMIO code. Michel Daenzer has > implemented a bit more of the CP 2D code in DRI-CVS, which brings > the CP 2D code much closer to the level of the MMIO codepath. In fact, on the reinit-0-0-1-branch in DRI CVS, I've brought it up to par (in terms of accelerated operations - the CP is faster of course :). I hope this will get into 4.3.0. > I've got a patch for 4.2.0 to add the latest code, however it was > reported as not fully working so I disabled it until I have time > to debug/troubleshoot. Can you be a bit more specific than 'not fully working'? > If anyone wants a copy of the patch, let me know and I'll put it up on FTP. I'd be interested to see the patch if there are problems with it. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Re: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
On Sun, 25 Aug 2002, Csan wrote: >Date: Sun, 25 Aug 2002 02:55:25 +0200 >From: Csan <[EMAIL PROTECTED]> >To: debian-x@lists.debian.org >Content-Type: text/plain; charset=ISO-8859-1 >Subject: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source, >i386)available at the X Strike Force) > >Hi, > >> > is there any chance for gatos deb's for i386 and powerpc? > >> What do you need it for? If it's about Mach64, try > >> deb http://penguinppc.org/~daenzer/debian/dri-mach64/ ./ > >I would need 2d acceleration for my ATI Radeon 7200 (VIVO 64MB DDR) very bad. >I'd like to dive myself into Quake 3 mapping with GTKRadiant map editor, but I >can't since the ati driver shipped with the current xserver, does not contains >any 2d acceleration... > >Are there any plans for integrating gatos 2d aacceleration into the xfree6 >project's next debian release. Radeon 2D acceleration is implemented in two different ways. The first method, MMIO, is used when DRI is disabled. The second way, uses the Radeon CP engine, and is only used when DRI is enabled. The problem though, is that the CP engine 2D code was not as fully implemented as the MMIO code was, so earlier XFree86 releases will show a slowdown in 2D acceleration when DRI is enabled. XFree86 4.2.0 has the situation improved slightly, but it still isn't up to par with the MMIO code. Michel Daenzer has implemented a bit more of the CP 2D code in DRI-CVS, which brings the CP 2D code much closer to the level of the MMIO codepath. 4.2.0 is your best bet for stable 2D right now, while DRI-CVS provides the latest code. I've got a patch for 4.2.0 to add the latest code, however it was reported as not fully working so I disabled it until I have time to debug/troubleshoot. If anyone wants a copy of the patch, let me know and I'll put it up on FTP. Take care, TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris
Re: # Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
On Sun, 2002-08-25 at 02:55, Csan wrote: > > > > is there any chance for gatos deb's for i386 and powerpc? > > > What do you need it for? If it's about Mach64, try > > > deb http://penguinppc.org/~daenzer/debian/dri-mach64/ ./ > > I would need 2d acceleration for my ATI Radeon 7200 (VIVO 64MB DDR) very bad. > I'd like to dive myself into Quake 3 mapping with GTKRadiant map editor, but I > can't since the ati driver shipped with the current xserver, does not contains > any 2d acceleration... > > Are there any plans for integrating gatos 2d aacceleration into the xfree6 > project's next debian release. GATOS doesn't do 2D acceleration AFAIK, don't you mean 3D anyway? Either way, try deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
# Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386)available at the X Strike Force)
Hi, > > is there any chance for gatos deb's for i386 and powerpc? > What do you need it for? If it's about Mach64, try > deb http://penguinppc.org/~daenzer/debian/dri-mach64/ ./ I would need 2d acceleration for my ATI Radeon 7200 (VIVO 64MB DDR) very bad. I'd like to dive myself into Quake 3 mapping with GTKRadiant map editor, but I can't since the ati driver shipped with the current xserver, does not contains any 2d acceleration... Are there any plans for integrating gatos 2d aacceleration into the xfree6 project's next debian release. Thanks. Regs, Csan PS: pls Cc: me, thx. Janos Holanyi Association of Hungarian Linux Users Email: csaniATlme.linux.hu - This mail sent through IMP: http://horde.org/imp/
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
> In <[EMAIL PROTECTED]> > Rick Younie <[EMAIL PROTECTED]> wrote: >> ISHIKAWA Mutsumi wrote: >> I wonder if the problems will turn out to be big-endian related? >> It would be nice to be able to debug it on a faster arch than >> m68k. >> >> I'll see if Branden has the old patch and I'll try and find what >> has changed. I've tracking down the SPARC problem. I found that some drivers still have some hardware depend codes. For example radeon_drv and r128_drv does require VGA related functions defined in xc/programs/Xserver/hw/xfree86/vgahw/vgaHW.{c,h}. But SPARC does not have VGA, so vgaHW.o is not linked in XFree86 server. This does cause a trouble when we wish to build a static linked X server. On the static linked X server, functions symbols resolution will be done at the time of linking. vs On the dynamic loading X server, functions symbol resolution will be done at the time of staring the server. On m68k, mac64 dynamic loading driver cannot have worked from before. Because xf86WriteMmio32Be is not defined anywhere. Perhaps, we should define xf86WriteMmio32Be function in xc/programs/Xserver/hw/xfree86/common/compiler.h. -- ISHIKAWA Mutsumi <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Re: Build fail on sparc (Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force)
> In <[EMAIL PROTECTED]> > ISHIKAWA Mutsumi <[EMAIL PROTECTED]> wrote: >> > In <[EMAIL PROTECTED]> >> >Branden Robinson <[EMAIL PROTECTED]> wrote: >> >> [1 ] >> >> On Thu, Aug 22, 2002 at 01:16:25AM +0900, ISHIKAWA Mutsumi wrote: >> >> > > In <[EMAIL PROTECTED]> >> >> > > Branden Robinson <[EMAIL PROTECTED]> wrote: >> >> > >> >> > >> Changes: >> >> > >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low >> >> > >> . >> >> > >>*** THIS IS AN EXPERIMENTAL RELEASE. FEEDBACK SHOULD GO TO >> >> > >>*** . DO NOT FILE BUGS AGAINST THIS >> >> > >> RELEASE WITH >> >> > >>*** THE DEBIAN BUG TRACKING SYSTEM. ANY SUCH REPORTS WILL BE >> >> > >> CLOSED. >> >> > >> . >> >> > >>* TODO: more mips weirdness; somehow BuildHtmlManPages is getting >> >> > >> set to YES >> Build on SPARC was failed with these error bellow. >> gcc -o XFree86 -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes >> -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls >> -Wnested-externs -L../../exports/lib -L/usr/X11R6/lib >> ../../programs/Xserver/hw/xfree86/drivers/drvConf.o >> ../../programs/Xserver/hw/xfree86/input/drvConf.o >> ../../programs/Xserver/hw/xfree86/drivers/libdriver.a >> ../../programs/Xserver/hw/xfree86/ramdac/libramdac.a >> ../../programs/Xserver/hw/xfree86/ddc/libddc.a >> ../../programs/Xserver/hw/xfree86/i2c/libi2c.a >> ../../programs/Xserver/hw/xfree86/xaa/libxaa.a >> ../../programs/Xserver/hw/xfree86/fbdevhw/libfbdevhw.a >> ../../programs/Xserver/hw/xfree86/xf8_32wid/libxf8_32wid.a >> ../../programs/Xserver/hw/xfree86/xf8_32bpp/libxf8_32bpp.a >> ../../programs/Xserver/hw/xfree86/xf8_16bpp/libxf8_16bpp.a >> ../../programs/Xserver/hw/xfree86/xf24_32bpp/libxf24_32bpp.a >> ../../programs/Xserver/hw/xfree86/xf4bpp/libxf4bpp.a >> ../../programs/Xserver/hw/xfree86/xf1bpp/libxf1bpp.a .. /.. >> /programs/Xserver/hw/xfree86/shadowfb/libshadowfb.a >> ../../programs/Xserver/hw/xfree86/input/libidriver.a >> ../../programs/Xserver/hw/xfree86/common/xf86Init.o >> ../../programs/Xserver/hw/xfree86/common/xf86IniExt.o >> ../../programs/Xserver/hw/xfree86/common/libxf86.a >> ../../programs/Xserver/hw/xfree86/rac/librac.a >> ../../programs/Xserver/hw/xfree86/parser/libxf86config.a >> ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a >> ../../programs/Xserver/hw/xfree86/int10/libint10.a >> ../../programs/Xserver/hw/xfree86/common/libxf86.a miext/shadow/libshadow.a >> dix/libdix.a os/libos.a ../../exports/lib/libXau.a >> ../../exports/lib/libXdmcp.a fb/libfb.a cfb16/libcfb16.a >> cfb24/libcfb24.acfb32/libcfb32.acfb/libcfb.a >> mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libext.a xkb/libxkb.a >> Xi/libxinput.albx/liblbx.a >> ../../lib/lbxutil/liblbxutil.a dbe/libdbe.a record/librecord.a >> XTrap/libxtrap.a GL/glx/libglx.a >> GL/mesa/src/X/libGLcoreX.aGL/mesa/src/libGLcore.a >> GL/dri/libdri.a render/librender.a >> ../../programs/Xserver/hw/xfree86/common/libxf86.a mi/libmi.a >> ../../programs/Xserver/hw/xfree86/scanpci/libscanpci.a >> ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a >> ../../programs/Xserver/hw/xfree86/ddc/libddc.a ../../lib/font/libXfont.a >> dix/libxpstubs.a -lz -lm >> -Wl,-rpath-link,../../exports/lib >> ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(r128_drv.o): In >> function `R128PreInit': >> r128_drv.o(.text+0x7154): undefined reference to `vgaHWGetHWRec' >> r128_drv.o(.text+0x74a8): undefined reference to `vgaHWFreeHWRec' snip >> ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(radeon_drv.o): In >> function `RADEONPreInit': >> radeon_drv.o(.text+0x7518): undefined reference to `vgaHWGetHWRec' >> radeon_drv.o(.text+0x752c): undefined reference to `vgaHWGetIndex' >> radeon_drv.o(.text+0x753c): undefined reference to `vgaHWGetIOBase' >> radeon_drv.o(.text+0x78a4): undefined reference to `vgaHWFreeHWRec' snip >> collect2: ld returned 1 exit status >> make[5]: *** [XFree86] Error 1 >> make[5]: Leaving directory >> `/home/ishikawa/work/XFree86/xfree86-4.2.0/build-tree/xc-xserver-xfree86-dbg/programs/Xserver' Hmm, I understand the problem. radeon_drv and r128_drv require some vga related functions, defined in xc/programs/Xserver/hw/xfree86/vgahw/vgaHW.{c,h}. But on SPARC environment vgaHW.c will not build because SPARC machines does not have VGA, so XF86VgaHw is set as NO. Under build-tree/xc-xserver-xfree86-dbg, we will build the static linked x server. Symbols are resolved on build time. Perhaps, we should drop r128 and radeon driver support when the x server build without XF86VgaHw define. (or r128 and radeon drivers should update to be able to build and run without vgaHW). -- ISHIKAWA Mut
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
On Thu, Aug 22, 2002 at 10:52:37AM -0500, Branden Robinson wrote: > On Thu, Aug 22, 2002 at 10:55:57PM +1000, Drew Parsons wrote: > > Thanks for the hard work. Is there any specific issue holding XFree86 from > > upload to unstable, or are you simply taking the time to make "due > > diligence", > > as the suits call it? > > Partly due diligence, partly this: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139212&repeatmerged=yes > I see. Document licence problems. > Since the FTP admins have decreed that That Shalt Not Redact An > .Orig.Tar.Gz After It Has Been Uploaded, I want to make sure the 4.2.0 > .orig is totally kosher the first time around. > Yes, I think I ran into that problem at one point too in one of my packages ;/ By the way, xprint-xprintorg is all but ready to ship. I'm waiting for confirmation of the name (if upstream is happy with that package name), since xprint.org doesn't actually exist yet. Any other problems with the package can be fixed in subsequent uploads, but I want to at least be sure I got the name right first time. I should probably upload to experimental in the meanwhile, I suppose. When it's all ready, I'll probably ask you to add a Depends: to xprt on xprt-common, and maybe also a Recommends: on xprt-xprintorg. Thanks for the reply, Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A pgpOWd8DSUdJt.pgp Description: PGP signature
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
> In <[EMAIL PROTECTED]> > ISHIKAWA Mutsumi <[EMAIL PROTECTED]> wrote: >> > In <[EMAIL PROTECTED]> >> >Branden Robinson <[EMAIL PROTECTED]> wrote: >> >> >> Changes: >> >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low >> >> . >> >>*** THIS IS AN EXPERIMENTAL RELEASE. FEEDBACK SHOULD GO TO >> >>*** . DO NOT FILE BUGS AGAINST THIS >> >> RELEASE WITH >> >>*** THE DEBIAN BUG TRACKING SYSTEM. ANY SUCH REPORTS WILL BE CLOSED. >> >> . >> >>* TODO: more mips weirdness; somehow BuildHtmlManPages is getting set >> >> to YES >> I'll build for these architectures binaries: >> >> alpha >> sparc >> hppa >> m68k >> sh4 OK, alpha, hppa and sh4 binaries available on the URL bellow. Please merge these binaries on X Strike Force tree, Branden :-) http://people.debian.org/~ishikawa/XFree86/4.2.0-0pre1v3/alpha/ http://people.debian.org/~ishikawa/XFree86/4.2.0-0pre1v3/hppa/ http://people.debian.org/~ishikawa/XFree86/4.2.0-0pre1v3/sh4/ mirror: http://hanzubon.jp/Linux/Debian/XFree86-4.2.0-0pre1v3/alpha/ http://hanzubon.jp/Linux/Debian/XFree86-4.2.0-0pre1v3/hppa/ http://hanzubon.jp/Linux/Debian/XFree86-4.2.0-0pre1v3/sh4/ Sparc and m68k build was failed. I'll track down these problem on this week end. -- ISHIKAWA Mutsumi <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Build fail on sparc (Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force)
> In <[EMAIL PROTECTED]> > Branden Robinson <[EMAIL PROTECTED]> wrote: >> [1 ] >> On Thu, Aug 22, 2002 at 01:16:25AM +0900, ISHIKAWA Mutsumi wrote: >> > > In <[EMAIL PROTECTED]> >> > > Branden Robinson <[EMAIL PROTECTED]> wrote: >> > >> > >> Changes: >> > >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low >> > >> . >> > >>*** THIS IS AN EXPERIMENTAL RELEASE. FEEDBACK SHOULD GO TO >> > >>*** . DO NOT FILE BUGS AGAINST THIS >> > >> RELEASE WITH >> > >>*** THE DEBIAN BUG TRACKING SYSTEM. ANY SUCH REPORTS WILL BE CLOSED. >> > >> . >> > >>* TODO: more mips weirdness; somehow BuildHtmlManPages is getting >> > >> set to YES >> > >> > I'll build for these architectures binaries: >> > >> > alpha >> > sparc >> > hppa >> > m68k >> > sh4 >> >> Thanks a lot, as usual. :) I can handle PowerPC and possibly IA-64. Build on SPARC was failed with these error bellow. I'm not tracking down the problem yet because I don't have enough time for analyzing the problem on today and tomorrow... I put the full build log and build tree tar ball on these URL, If someone are interesting to solve the problem, please welcome to download these :-) http://hanzubon.jp/Linux/Debian/XFree86-4.2.0-0pre1v3/sparc/0pre1v3_build.log http://hanzubon.jp/Linux/Debian/XFree86-4.2.0-0pre1v3/sparc/xfree86_sparc_build_tree.tgz Be carful to download the build tree tar ball. It is very huge. -rw-r--r--1 ishikawa ishikawa 400918082 2002-08-23 00:57 xfree86_sparc_build_tree.tgz gcc -o XFree86 -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -L../../exports/lib -L/usr/X11R6/lib ../../programs/Xserver/hw/xfree86/drivers/drvConf.o ../../programs/Xserver/hw/xfree86/input/drvConf.o ../../programs/Xserver/hw/xfree86/drivers/libdriver.a ../../programs/Xserver/hw/xfree86/ramdac/libramdac.a ../../programs/Xserver/hw/xfree86/ddc/libddc.a ../../programs/Xserver/hw/xfree86/i2c/libi2c.a ../../programs/Xserver/hw/xfree86/xaa/libxaa.a ../../programs/Xserver/hw/xfree86/fbdevhw/libfbdevhw.a ../../programs/Xserver/hw/xfree86/xf8_32wid/libxf8_32wid.a ../../programs/Xserver/hw/xfree86/xf8_32bpp/libxf8_32bpp.a ../../programs/Xserver/hw/xfree86/xf8_16bpp/libxf8_16bpp.a ../../programs/Xserver/hw/xfree86/xf24_32bpp/libxf24_32bpp.a ../../programs/Xserver/hw/xfree86/xf4bpp/libxf4bpp.a ../../programs/Xserver/hw/xfree86/xf1bpp/libxf1bpp.a ../.. /programs/Xserver/hw/xfree86/shadowfb/libshadowfb.a ../../programs/Xserver/hw/xfree86/input/libidriver.a ../../programs/Xserver/hw/xfree86/common/xf86Init.o ../../programs/Xserver/hw/xfree86/common/xf86IniExt.o ../../programs/Xserver/hw/xfree86/common/libxf86.a ../../programs/Xserver/hw/xfree86/rac/librac.a ../../programs/Xserver/hw/xfree86/parser/libxf86config.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a ../../programs/Xserver/hw/xfree86/int10/libint10.a ../../programs/Xserver/hw/xfree86/common/libxf86.a miext/shadow/libshadow.a dix/libdix.a os/libos.a ../../exports/lib/libXau.a ../../exports/lib/libXdmcp.a fb/libfb.a cfb16/libcfb16.a cfb24/libcfb24.a cfb32/libcfb32.acfb/libcfb.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libext.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a dbe/libdbe.a record/librecord.aXTrap/libxtrap.a GL/glx/libglx.a GL/mesa/src/X/libGLcoreX.aGL/mesa/src/libGLcore.a GL/dri/libdri.a render/librender.a ../../programs/Xserver/hw/xfree86/common/libxf86.a mi/libmi.a ../../programs/Xserver/hw/xfree86/scanpci/libscanpci.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a ../../programs/Xserver/hw/xfree86/ddc/libddc.a ../../lib/font/libXfont.a dix/libxpstubs.a -lz -lm -Wl,-rpath-link,../../exports/lib ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(r128_drv.o): In function `R128PreInit': r128_drv.o(.text+0x7154): undefined reference to `vgaHWGetHWRec' r128_drv.o(.text+0x74a8): undefined reference to `vgaHWFreeHWRec' ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(r128_drv.o): In function `R128Save': r128_drv.o(.text+0x8ca4): undefined reference to `vgaHWGetIndex' r128_drv.o(.text+0x8cd4): undefined reference to `vgaHWUnlock' r128_drv.o(.text+0x8ce4): undefined reference to `vgaHWSave' r128_drv.o(.text+0x8cec): undefined reference to `vgaHWLock' ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(r128_drv.o): In function `R128Restore': r128_drv.o(.text+0x8d58): undefined reference to `vgaHWGetIndex' r128_drv.o(.text+0x8df4): undefined reference to `vgaHWUnlock' r128_drv.o(.text+0x8e04): undefined reference to `vgaHWRestore' r128_drv.o(.text+0x8e0c): undefined reference to `vgaHWLock' ../../p
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
On Thu, Aug 22, 2002 at 10:55:57PM +1000, Drew Parsons wrote: > Thanks for the hard work. Is there any specific issue holding XFree86 from > upload to unstable, or are you simply taking the time to make "due diligence", > as the suits call it? Partly due diligence, partly this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139212&repeatmerged=yes Since the FTP admins have decreed that That Shalt Not Redact An .Orig.Tar.Gz After It Has Been Uploaded, I want to make sure the 4.2.0 .orig is totally kosher the first time around. -- G. Branden Robinson|It's like I have a shotgun in my Debian GNU/Linux |mouth, I've got my finger on the [EMAIL PROTECTED] |trigger, and I like the taste of http://people.debian.org/~branden/ |the gunmetal. -- Robert Downey, Jr. pgpwMYBXzG9pW.pgp Description: PGP signature
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
> In <[EMAIL PROTECTED]> > Branden Robinson <[EMAIL PROTECTED]> wrote: >> [1 ] >> On Thu, Aug 22, 2002 at 01:16:25AM +0900, ISHIKAWA Mutsumi wrote: >> > > In <[EMAIL PROTECTED]> >> > > Branden Robinson <[EMAIL PROTECTED]> wrote: >> > >> > >> Changes: >> > >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low >> > >> . >> > >>*** THIS IS AN EXPERIMENTAL RELEASE. FEEDBACK SHOULD GO TO >> > >>*** . DO NOT FILE BUGS AGAINST THIS >> > >> RELEASE WITH >> > >>*** THE DEBIAN BUG TRACKING SYSTEM. ANY SUCH REPORTS WILL BE CLOSED. >> > >> . >> > >>* TODO: more mips weirdness; somehow BuildHtmlManPages is getting >> > >> set to YES >> > >> > I'll build for these architectures binaries: >> > >> > alpha >> > sparc >> > hppa >> > m68k >> > sh4 >> Thanks a lot, as usual. :) I can handle PowerPC and possibly IA-64. Welcome ;) Alpha binaries are available on the URL bellow: http://hanzubon.jp/Linux/Debian/XFree86-4.2.0-0pre1v3/alpha/ P.S I can not connect to people.debian.org. Is gluck.debian.org stopped now? -- ISHIKAWA Mutsumi <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
On Tue, Aug 20, 2002 at 10:07:30PM -0500, Branden Robinson wrote: > Changes: > xfree86 (4.2.0-0pre1v3) unstable; urgency=low > . >*** THIS IS AN EXPERIMENTAL RELEASE. FEEDBACK SHOULD GO TO >*** . DO NOT FILE BUGS AGAINST THIS RELEASE > WITH >*** THE DEBIAN BUG TRACKING SYSTEM. ANY SUCH REPORTS WILL BE CLOSED. > . Thanks for the hard work. Is there any specific issue holding XFree86 from upload to unstable, or are you simply taking the time to make "due diligence", as the suits call it? Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A
Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force)
On Thu, 2002-08-22 at 12:08, Philipp Schmidt wrote: > On Thu, 2002-08-22 12:29:59 +0200, Michel D?nzer <[EMAIL PROTECTED]> > wrote in message <[EMAIL PROTECTED]>: > > On Thu, 2002-08-22 at 11:58, Philipp Schmidt wrote: > > > On Wed, 2002-08-21 14:35:04 -0500, Branden Robinson <[EMAIL PROTECTED]> > > > wrote in message <[EMAIL PROTECTED]>: > > > > On Thu, Aug 22, 2002 at 01:16:25AM +0900, ISHIKAWA Mutsumi wrote: > > > > > > In <[EMAIL PROTECTED]> > > > > > > Branden Robinson <[EMAIL PROTECTED]> wrote: > > > > > > > > > > >> Changes: > > > > > >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low > > > > > > is there any chance for gatos deb's for i386 and powerpc? > > > > What do you need it for? If it's about Mach64, try > > > > deb http://penguinppc.org/~daenzer/debian/dri-mach64/ ./ > > i want to get the tv-out to work - watching DVD's on TV ;-) Don't bother then, the TV-Out only works on x86 machines. Cheers -- /Bastien Nocera http://hadess.net signature.asc Description: This is a digitally signed message part
Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force)
On Thu, 2002-08-22 12:29:59 +0200, Michel D?nzer <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Thu, 2002-08-22 at 11:58, Philipp Schmidt wrote: > > On Wed, 2002-08-21 14:35:04 -0500, Branden Robinson <[EMAIL PROTECTED]> > > wrote in message <[EMAIL PROTECTED]>: > > > On Thu, Aug 22, 2002 at 01:16:25AM +0900, ISHIKAWA Mutsumi wrote: > > > > > In <[EMAIL PROTECTED]> > > > > > Branden Robinson <[EMAIL PROTECTED]> wrote: > > > > > > > > >> Changes: > > > > >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low > > > > is there any chance for gatos deb's for i386 and powerpc? > > What do you need it for? If it's about Mach64, try > > deb http://penguinppc.org/~daenzer/debian/dri-mach64/ ./ i want to get the tv-out to work - watching DVD's on TV ;-) AVE! phils... -- PHILIPP SCHMIDT / phils - - + - - > [EMAIL PROTECTED] ` - - > http://home.pages.de/~phils/ --> ONLINE fuer Berlin & BRB? IN-Berlin! ([EMAIL PROTECTED]) <-- Lbh unir whfg ivbyngrq gur Qvtvgny Zvyraavhz Pbclevtug Npg ol oernxvat gur cebgrpgvba bs pbclevtugrq zngrevny. Vs lbh ner abg n pvgvmra be erfvqrag bs gur HFN, lbh evfx orvat vzcevfbarq naq uryq jvgubhg onvy sbe hc gb gjb jrrxf hcba ragel gb gur HFN (c) Copyright 2001 by Hartmann Schaffer (signature only) :wq
Re: Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force)
On Thu, 2002-08-22 at 11:58, Philipp Schmidt wrote: > On Wed, 2002-08-21 14:35:04 -0500, Branden Robinson <[EMAIL PROTECTED]> > wrote in message <[EMAIL PROTECTED]>: > > On Thu, Aug 22, 2002 at 01:16:25AM +0900, ISHIKAWA Mutsumi wrote: > > > > In <[EMAIL PROTECTED]> > > > > Branden Robinson <[EMAIL PROTECTED]> wrote: > > > > > > >> Changes: > > > >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low > > is there any chance for gatos deb's for i386 and powerpc? What do you need it for? If it's about Mach64, try deb http://penguinppc.org/~daenzer/debian/dri-mach64/ ./ -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Gatos deb's (was: Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force)
On Wed, 2002-08-21 14:35:04 -0500, Branden Robinson <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Thu, Aug 22, 2002 at 01:16:25AM +0900, ISHIKAWA Mutsumi wrote: > > > In <[EMAIL PROTECTED]> > > > Branden Robinson <[EMAIL PROTECTED]> wrote: > > > > >> Changes: > > >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low is there any chance for gatos deb's for i386 and powerpc? i don't want to break out x of the packageing system - if tere aren't any debs for gatos - what need's to be done? AVE! phils... -- PHILIPP SCHMIDT / phils - - + - - > [EMAIL PROTECTED] ` - - > http://home.pages.de/~phils/ --> ONLINE fuer Berlin & BRB? IN-Berlin! ([EMAIL PROTECTED]) <-- Lbh unir whfg ivbyngrq gur Qvtvgny Zvyraavhz Pbclevtug Npg ol oernxvat gur cebgrpgvba bs pbclevtugrq zngrevny. Vs lbh ner abg n pvgvmra be erfvqrag bs gur HFN, lbh evfx orvat vzcevfbarq naq uryq jvgubhg onvy sbe hc gb gjb jrrxf hcba ragel gb gur HFN (c) Copyright 2001 by Hartmann Schaffer (signature only) :wq pgpH18gk7kcnn.pgp Description: PGP signature
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
ISHIKAWA Mutsumi wrote: > Rick Younie <[EMAIL PROTECTED]> wrote: > > >> I'm about half way through a build for m68k on crest.debian.org. > >> Let me know if I should kill it please. > > Please keep and upload m68k binaries :-) Will do. > > >> Will you, ishikawa, be doing m68k regularly? > > I'm not m68k specialist and perhaps I will be very busy > after September on my own job. So, I am happy if you can > handle m68k build. I don't know about specialist but I admin an m68k build daemon anyhow. Rick --
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
> In <[EMAIL PROTECTED]> > Rick Younie <[EMAIL PROTECTED]> wrote: >> Branden Robinson wrote: >> > >> > On Thu, Aug 22, 2002 at 01:16:25AM +0900, ISHIKAWA Mutsumi wrote: >> >> > In <[EMAIL PROTECTED]> >> >> > Branden Robinson <[EMAIL PROTECTED]> wrote: >> >> >> >> >> Changes: >> >> >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low >> >> >> . >> >> >>*** THIS IS AN EXPERIMENTAL RELEASE. FEEDBACK SHOULD GO TO >> >> >>*** . DO NOT FILE BUGS AGAINST THIS >> >> >> RELEASE WITH >> >> >>*** THE DEBIAN BUG TRACKING SYSTEM. ANY SUCH REPORTS WILL BE >> >> >> CLOSED. >> >> >> . >> >> >>* TODO: more mips weirdness; somehow BuildHtmlManPages is getting >> >> >> set to YES >> >> >> >> I'll build for these architectures binaries: >> >> >> >> alpha >> >> sparc >> >> hppa >> >> m68k >> >> sh4 >> I'm about half way through a build for m68k on crest.debian.org. >> Let me know if I should kill it please. Please keep and upload m68k binaries :-) >> Will you, ishikawa, be doing m68k regularly? I'm not m68k specialist and perhaps I will be very busy after September on my own job. So, I am happy if you can handle m68k build. -- ISHIKAWA Mutsumi <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
Branden Robinson wrote: > > On Thu, Aug 22, 2002 at 01:16:25AM +0900, ISHIKAWA Mutsumi wrote: >> > In <[EMAIL PROTECTED]> >> > Branden Robinson <[EMAIL PROTECTED]> wrote: >> >> >> Changes: >> >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low >> >> . >> >>*** THIS IS AN EXPERIMENTAL RELEASE. FEEDBACK SHOULD GO TO >> >>*** . DO NOT FILE BUGS AGAINST THIS >> >> RELEASE WITH >> >>*** THE DEBIAN BUG TRACKING SYSTEM. ANY SUCH REPORTS WILL BE CLOSED. >> >> . >> >>* TODO: more mips weirdness; somehow BuildHtmlManPages is getting set >> >> to YES >> >> I'll build for these architectures binaries: >> >> alpha >> sparc >> hppa >> m68k >> sh4 I'm about half way through a build for m68k on crest.debian.org. Let me know if I should kill it please. Will you, ishikawa, be doing m68k regularly? Rick --
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
On Thu, Aug 22, 2002 at 01:16:25AM +0900, ISHIKAWA Mutsumi wrote: > > In <[EMAIL PROTECTED]> > > Branden Robinson <[EMAIL PROTECTED]> wrote: > > >> Changes: > >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low > >> . > >>*** THIS IS AN EXPERIMENTAL RELEASE. FEEDBACK SHOULD GO TO > >>*** . DO NOT FILE BUGS AGAINST THIS RELEASE > >> WITH > >>*** THE DEBIAN BUG TRACKING SYSTEM. ANY SUCH REPORTS WILL BE CLOSED. > >> . > >>* TODO: more mips weirdness; somehow BuildHtmlManPages is getting set > >> to YES > > I'll build for these architectures binaries: > > alpha > sparc > hppa > m68k > sh4 Thanks a lot, as usual. :) I can handle PowerPC and possibly IA-64. -- G. Branden Robinson| Debian GNU/Linux | Ab abusu ad usum non valet [EMAIL PROTECTED] | consequentia. http://people.debian.org/~branden/ | pgplts8cq8RMO.pgp Description: PGP signature
Re: xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
> In <[EMAIL PROTECTED]> > Branden Robinson <[EMAIL PROTECTED]> wrote: >> Changes: >> xfree86 (4.2.0-0pre1v3) unstable; urgency=low >> . >>*** THIS IS AN EXPERIMENTAL RELEASE. FEEDBACK SHOULD GO TO >>*** . DO NOT FILE BUGS AGAINST THIS RELEASE >> WITH >>*** THE DEBIAN BUG TRACKING SYSTEM. ANY SUCH REPORTS WILL BE CLOSED. >> . >>* TODO: more mips weirdness; somehow BuildHtmlManPages is getting set to >> YES I'll build for these architectures binaries: alpha sparc hppa m68k sh4 -- ISHIKAWA Mutsumi <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
xfree86 4.2.0-0pre1v3 (source,i386) available at the X Strike Force
Changes: xfree86 (4.2.0-0pre1v3) unstable; urgency=low . *** THIS IS AN EXPERIMENTAL RELEASE. FEEDBACK SHOULD GO TO *** . DO NOT FILE BUGS AGAINST THIS RELEASE WITH *** THE DEBIAN BUG TRACKING SYSTEM. ANY SUCH REPORTS WILL BE CLOSED. . * TODO: more mips weirdness; somehow BuildHtmlManPages is getting set to YES . * patch #000_post_xf-4_2_0: - include DPMS fix for r128 driver (thanks to Stuart Anderson for pulling the patch over to xf-4_2-branch) * patch #000_stolen_from_HEAD: - Fix SEGV in 3dfx DRI driver. (Alan Hourihane) - Fix enabling of i810 DRI when XvMC is disabled (#5208, Matthew Sottek, Intel). * patch #000_stolen_from_HEAD_nv_driver: - Refence the "nv" driver. PPC and Alpha users should test this. Especially to see if this solves the problem with color expansion hangs. (Mark Vojkovich) . * patch #001: turn off modular XFree86 server for MIPS architectures since the ELF loader isn't yet working on those platforms, per Guido Guenther * patch #075: new; don't ship the XIE headers if we're not building the library * patch #076: new; xterm now works around hateful lies from GNU libc's getpt() function (see #121899) * patch #077: new; define DriverManSuffix as 4x and MiscManSuffix as 7x on GNU and Linux systems per suggestion from Colin Watson (see #157020) (Closes: #85297) * patch #078: new; fix i810 crash on VT switch due to call to Sync() while switched away (Andris Pavenis) (Closes: #78395) * patch #313: new; tell xdm that more architectures have "fragile" /dev/mem devices (i.e., only read above 1MB) (might fix #107311) * patch #600: new; patch from Guido Guenther to fix some newport driver bugs: - broken 24bpp mode setup - black console after starting X - screensaver blanking the console - off-by-one errors in the RefreshArea code . * debian/MANIFEST.*: updated * debian/control: - new package: xserver-xfree86-dbg -- a monolithic XFree86 server binary complete with debugging symbols for your SEGV backtracing pleasure - add ${shlibs:Depends} for library debugging packages * debian/local/{XF86Config.7,Xsession.5,Xsession.options.5, Xwrapper.config.5,dexconf.8,update-fonts-alias.8,update-fonts-dir.8, update-fonts-scale.8,xdm.options.5,xfs.options.5,xvfb-run.1}: update manpage reference to reflect change from patch #077 (see above) * debian/local/Xsession: remove unused *MODMAP variables (see #157396) * debian/local/update-fonts-alias: only start writing new alias file if there are any aliases to process (thanks, Ian Zimmerman) (Closes: #144780) * debian/rules: - new rules; "genscripts" and "cleanscript", and some miscellaneous cleanup - add infrastructure to support new xserver-xfree86-dbg package - add workaround for dpkg-shlibdeps brain damage so that xlibs does not end up depending on itself (see #80340) * debian/{xdm,xfs}.postinst.in: only invoke update-rc.d if init script exists (user may have removed it) (Closes: #151023) * debian/xfree86-common.files: update to new manpage filenames (see above) * debian/xfree86-common.postinst.in: include a confmodule-sourcing fragment * debian/xlibs.links: remove obsolete symlinks to XIE and PEX5 libraries * debian/xlibs.shlibs.dummy: kludge file to work around dpkg-dev bug #80340 (see above) * debian/xserver-xfree86-dbg.files: new; ship XFree86-debug executable * debian/xserver-xfree86.files*: update to new manpage filenames (see above) * debian/xserver-xfree86.files.hppa: ship nv(4) manpage * debian/xserver-xfree86.files.m68k: ship driver modules and manpages for nv and savage drivers * debian/xserver-xfree86.files.mips: remove server modules (see above) * debian/xserver-xfree86.files.powerpc: ship driver modules and manpages for nv and savage drivers * debian/xserver-xfree86.templates: - document that the maximum supported color depth is 8 on old ATI hardware (see #76291) - mention that the vbe module depends on the int10 module (Closes: #139755) * debian/xserver-xfree86.templates.nl: added Dutch translation (needs update) (thanks, Wouter Verhelst) (Closes: #139231) * debian/xserver-xfree86.templates.sv: updated Swedish translation (thanks, Mikael Hedin) (Closes: #143477) -- G. Branden Robinson|I've made up my mind. Don't try to Debian GNU/Linux |confuse me with the facts. [EMAIL PROTECTED] |-- Indiana Senator Earl Landgrebe http://people.debian.org/~branden/ | pgpN811HbHT1P.pgp Description: PGP signature