current cvs bugs
Hi, I tried current cvs from anoncvs.xfree86.org on Linux i386 and have hit several problems: 1) cannot compile krb5 support. I use krb5 implementation from ftp://ftp.pdc.kth.se/pub/heimdal/src , so you should BTW update docs saying not only MIT Krb5 is needed for this. They are compatible usally for apps quite well. See attached file maketxt for compile errors. 2) I cannot compile freetype stuff, see makegentoolike.txt. 3) config/cf/README doesn't include all variables, for example look at those gentoo is using. Many of them are missing! 4) It seems #define Krb5Includes requires as a value -I/usr/heimdal/include, am I right? Similarly for Krb5Libraries. 5) here is missing lib/Xa/ directory. It is referred from lib/Imakefile and eanbled by the XAserver and XAudio variables. What's going on? Please Cc: me in replies, I'm only on the users list. ;). Martin Building XFree86 version 4.4.99.13 (12 September 2004). I hope you checked the configuration parameters in ./config/cf to see if you need to pass BOOTSTRAPCFLAGS. Wed Sep 15 15:13:47 CEST 2004 make[1]: Entering directory `/scratch2/xc' [big cut] make[4]: Entering directory `/scratch2/xc/lib/Xau' rm -f AuDispose.o gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -Wall -Wpointer-arith -Wstrict-prototypes-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I/usr/heimdal/include -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API AuDispose.c rm -f AuFileName.o gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -Wall -Wpointer-arith -Wstrict-prototypes-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I/usr/heimdal/include -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API AuFileName.c rm -f AuGetAddr.o gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -Wall -Wpointer-arith -Wstrict-prototypes-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I/usr/heimdal/include -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API AuGetAddr.c rm -f AuGetBest.o gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -Wall -Wpointer-arith -Wstrict-prototypes-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I/usr/heimdal/include -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API AuGetBest.c rm -f AuLock.o gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -Wall -Wpointer-arith -Wstrict-prototypes-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I/usr/heimdal/include -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API AuLock.c rm -f AuRead.o gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -Wall -Wpointer-arith -Wstrict-prototypes-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I/usr/heimdal/include -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS
Re: UseFBDev makes X-display in several wide bars, each 110 degree rotated, unusable
Michel Dnzer wrote: Hi, sorry for the delay, I didn't get messages Cc: ed, but have subscribed noew and browsed archive. ;) On Fri, 2004-08-27 at 09:14 -0700, Tim Roberts wrote: (**) RADEON(0): *Mode 1400x1050: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 1400x1050 108.00 1400 34208 34320 1672 1050 1050 1053 1063 (**) RADEON(0): *Mode 1280x1024: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 1280x1024 108.00 1280 34208 34320 1672 1024 1050 1053 1063 (**) RADEON(0): *Mode 640x480: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 640x480 108.00 640 34208 34320 1672 480 1050 1053 1063 (**) RADEON(0): *Mode 800x600: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 800x600 108.00 800 34208 34320 1672 600 1050 1053 1063 (**) RADEON(0): *Mode 1024x768: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 1024x768 108.00 1024 34208 34320 1672 768 1050 1053 1063 These aren't right. Every mode in the list (including the 7 default modes I deleted) is shown as having a pixel clock of 108 MHz, horiz of 64.6 kHz, and vert of 60.8 Hz. The sync and blank numbers in the modeline are bonkers, too. Is this a general issue in the 4.4.99 release, or only for this gentleman? This is business as usual with the radeon driver driving a digital connector and not a problem here. My question to the original poster would be whether he absolutely needs UseFBDev and if yes, what for? No, I don't need it. Actually, I don't know what is it really usefull for. I thought it is required for DRI. Anyway, is someone going to fix the code (wherever the code resides) or at least will someone document it in some readme file under xc/ tree? Thanks Martin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: UseFBDev makes X-display in several wide bars, each 110 degree rotated, unusable
Martin MOKREJ wrote: Actually, I didn't know earlier but the radeon should not continue but make X rather die as I have AGP 9200 card, and that's actually the reason why I have to use ati as driver. The naming is bad, but empirically I have figured out which drier works and aslo gives DRI. The credit goes to Philipp Klaus Krause from dri-users list: radeon is the driver for the Radeon 7000 series cards. ati is the one for Radeon 8500 to 9200. Maybe that explains why I got video modes broken. Martin Michel Dnzer wrote: Hi, sorry for the delay, I didn't get messages Cc: ed, but have subscribed noew and browsed archive. ;) On Fri, 2004-08-27 at 09:14 -0700, Tim Roberts wrote: (**) RADEON(0): *Mode 1400x1050: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 1400x1050 108.00 1400 34208 34320 1672 1050 1050 1053 1063 (**) RADEON(0): *Mode 1280x1024: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 1280x1024 108.00 1280 34208 34320 1672 1024 1050 1053 1063 (**) RADEON(0): *Mode 640x480: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 640x480 108.00 640 34208 34320 1672 480 1050 1053 1063 (**) RADEON(0): *Mode 800x600: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 800x600 108.00 800 34208 34320 1672 600 1050 1053 1063 (**) RADEON(0): *Mode 1024x768: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 1024x768 108.00 1024 34208 34320 1672 768 1050 1053 1063 These aren't right. Every mode in the list (including the 7 default modes I deleted) is shown as having a pixel clock of 108 MHz, horiz of 64.6 kHz, and vert of 60.8 Hz. The sync and blank numbers in the modeline are bonkers, too. Is this a general issue in the 4.4.99 release, or only for this gentleman? This is business as usual with the radeon driver driving a digital connector and not a problem here. My question to the original poster would be whether he absolutely needs UseFBDev and if yes, what for? No, I don't need it. Actually, I don't know what is it really usefull for. I thought it is required for DRI. Anyway, is someone going to fix the code (wherever the code resides) or at least will someone document it in some readme file under xc/ tree? Thanks Martin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: UseFBDev makes X-display in several wide bars, each 110 degree rotated, unusable
On Thu, 16 Sep 2004, [ISO-8859-2] Martin MOKREJ© wrote: Martin MOKREJ© wrote: Actually, I didn't know earlier but the radeon should not continue but make X rather die as I have AGP 9200 card, and that's actually the reason why I have to use ati as driver. The naming is bad, but empirically I have figured out which drier works and aslo gives DRI. The credit goes to Philipp Klaus Krause from dri-users list: radeon is the driver for the Radeon 7000 series cards. ati is the one for Radeon 8500 to 9200. Last time I looked, ati was a wrapper driver which used one of the drivers mach64, r128 or radeon as appropriate, and radeon was appropriate for all Radeon cards. Has someone been playing around ? Or have you got different versions of the ati and radeon drivers ? There is also the drver from ATI, I've forgotten what that is called. Come to thing of it, the XFree86 radeon driver only support hardware 3D/GL/DRI for older Radeon cards; maybe that is what Philipp Klaus Krause meant ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: UseFBDev makes X-display in several wide bars, each 110 degree rotated, unusable
Dr Andrew C Aitchison wrote: On Thu, 16 Sep 2004, [ISO-8859-2] Martin MOKREJ wrote: Martin MOKREJ wrote: Actually, I didn't know earlier but the radeon should not continue but make X rather die as I have AGP 9200 card, and that's actually the reason why I have to use ati as driver. The naming is bad, but empirically I have figured out which drier works and aslo gives DRI. The credit goes to Philipp Klaus Krause from dri-users list: radeon is the driver for the Radeon 7000 series cards. ati is the one for Radeon 8500 to 9200. Last time I looked, ati was a wrapper driver which used one of the drivers mach64, r128 or radeon as appropriate, and radeon was appropriate for all Radeon cards. Has someone been playing around ? Or have you got different versions of the ati and radeon drivers ? No, but simply if user is stupid and types according to docs saying something like put on the Driver relevant driver for your card, like vesa, one usually knows ... I have Radeon 9200, OK, let's use radeon as it seems it does exist. So, when I used radeon directly, it caused by system to lockup, LCD display complaining it is out of sync. I propose to modify radeon driver in a way it would refuse to start on cards other than 7000 series. There is also the drver from ATI, I've forgotten what that is called. Yes, I know, I don't use them. The utility is fglrxconfig(1) distributed along with them. :) Come to thing of it, the XFree86 radeon driver only support hardware 3D/GL/DRI for older Radeon cards; maybe that is what Philipp Klaus Krause meant ? Yes. But that has explained why my system locks because I should use ati instead of radeon. You found here the clocks in modelines were screwed up, and I can tell you in addition the system has locked always. So, once more, radeon should kill X server correctly on startup if Radeon 8500-9200 is detected on the relevant bus. I hope I'm clearer now. ;) Martin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
