Re: [Xpert] Re: [Xpert]HEAD compile failure - programs/x11perf/do_traps.c
On Sat, 4 Jan 2003, Daniel Stone wrote: do_traps.c from HEAD fails, ostensibly because XTrapezoid is undefined: gcc -g -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I/usr/include -I/usr/include/freetype2 These are causing your build to pick up stale headers. I have Freetype 2.1.3 installed from the Debian packages; as an addendum, it worked fine with a snapshot from 28th Nov 2002, but fails with 3-1-2003. A previous installation of Freetype is not the issue here. A previous installation of Xrender headers is. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]HEAD compile failure - programs/x11perf/do_traps.c
On Fri, 3 Jan 2003, Daniel Stone wrote: do_traps.c from HEAD fails, ostensibly because XTrapezoid is undefined: gcc -g -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I/usr/include -I/usr/include/freetype2 ^^^ These are causing your build to pick up stale headers. -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-DMITSHM -DXFT -DXRENDER-c -o do_traps.o do_traps.c do_traps.c:113: parse error before `*' do_traps.c:113: warning: type defaults to `int' in declaration of `traps' do_traps.c:113: ANSI C forbids data definition with no type or storage class do_traps.c: In function `InitFixedTrapezoids': do_traps.c:125: `XTrapezoid' undeclared (first use in this function) do_traps.c:125: (Each undeclared identifier is reported only once do_traps.c:125: for each function it appears in.) do_traps.c:125: `curTrap' undeclared (first use in this function) do_traps.c:125: warning: statement with no effect do_traps.c:126: parse error before `color' do_traps.c:132: parse error before `)' do_traps.c:158: `color' undeclared (first use in this function) do_traps.c:186: warning: implicit declaration of function `XDoubleToFixed' do_traps.c:185: warning: value computed is not used do_traps.c: In function `DoFixedTrapezoids': do_traps.c:222: `XTrapezoid' undeclared (first use in this function) do_traps.c:222: `curTrap' undeclared (first use in this function) do_traps.c:222: warning: statement with no effect do_traps.c:223: parse error before `white' do_traps.c:225: `white' undeclared (first use in this function) do_traps.c:225: warning: implicit declaration of function `XftDrawSrcPicture' do_traps.c:226: `black' undeclared (first use in this function) do_traps.c:227: `dst' undeclared (first use in this function) do_traps.c:227: warning: implicit declaration of function `XftDrawPicture' do_traps.c:229: `src' undeclared (first use in this function) do_traps.c:232: warning: implicit declaration of function `XRenderCompositeTrapezoids' make[5]: *** [do_traps.o] Error 1 -- This is with an untouched do_traps.c, and x11perf in general. The lines above it include X11/extensions/Xrender.h, which is where XTrapezoid is defined ... any ideas? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]V_BIOS woes
On Sun, 29 Dec 2002, Adam Goode wrote: I have an SS50 mini PC from Shuttle, and it has on board SiS 6325 AGP video, as well as a Radeon 7500 PCI which I added. There are 2 versions of XFree86 which I've tried: 4.2.1-4 from Debian, and CVS HEAD. The only change I have made to the Debian version is adding the sis driver from Thomas Winischhofer http://www.winischhofer.net/sis/sis_drv.o_4.2.1_261102-1.tar.gz to get the sis card recognized. I've tried the HEAD version as is, downloaded yesterday. I am trying to get Xinerama to work, which it almost does, but then crashes. There are 2x2 configurations I'm using. One dimension is setting in my BIOS setup which video card is initialized as primary: ATI or SiS. The other dimension is the XFree86 version: Debian or HEAD. The only configuration which initializes all the cards and displays a picture across both of them is Debian-SiSPrimary. That is, I set the BIOS to initalize the SiS card first, and rtun the 4.2.1-4 Debian version. Unfortunately, this crashes very soon after I login and start to move windows between the two screens. In the other 3 configurations, I get trouble with not finding V_BIOS and the non-primary card doesn't get initalized at all. A quick table: Version PrimaryResult - HEAD SiSSiS works, ATI driver can't find V_BIOS or init the card HEAD ATIATI works, SiS driver can't find V_BIOS or init the card 4.2.1-4 SiSBoth cards work, int10 finds both V_BIOSes 4.2.1-4 ATIATI works, SiS driver can't find V_BIOS or init the card I'm sure something odd is happening deep with int10, and something between 4.2.1.1 and HEAD has broken at least some previously working configurations. I'm attaching lspci -vvv for both configurations, with ATI as primary card and SiS as primary card. I'm also attaching all 4 XFree86 logs for the configurations in the table above. It would be nice to get int10 working to find V_BIOS in all situations. Any help would be appreciated, and I'll be happy to do anything necessary to provide information to smart int10/pci hackers. A few thoughts here: a) It would appear the SiS's BIOS is imbedded in the system BIOS. Thus the SiS should always be the primary. b) Did you try each of the above cases after a fresh power-down/reboot? I suspect that if this is done, case 1 (HEAD/SiS) would produce the same results as case 3 (Debian/SiS). c) I see no evidence of crashes in these logs. Do you instead mean lockups? Does the SiS work by itself? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]exact integral types
On Tue, 10 Dec 2002, Warren Turkal wrote: A larger issue is that, on some 32-bit systems, this ends up typedef'ing CARD32 as 'unsigned int', and on others, as 'unsigned long'. For reasons I won't get into here, the X sources currently need CARD32 to be typedef'ed as 'unsigned long' for all 32-bit environments. The same issue, without 'unsigned' occurs with INT32. What does it matter if the type is unsigned and 32 bits in length? In point of fact, a similar comment could be made about your patch itself. Technically, you are correct. There is no difference between the two. However, there are more than technical issues to be dealt with here. If you check, you will note that typedef'ing CARD32 as unsigned int on 32-bit systems produces a plethora of warnings, and fixing those produces even more. In practice, these warnings produce two effects that this project must be concerned with. One is related to PR, the other to software maintenance. The PR issue is that compilation warnings advertise poor code quality to those (the majority) that don't have the time nor the gumption to dig deeper. The software maintenance issue is that the more nonsense warnings you produce by default, the less likely it is patch submissions will have been pre-laundered for portability problems. That's simply because nonsense warnings drown out real warnings. So, your task, to my mind, is clear: make sure `make World` logs do not differ whether CARD32 is typedef'ed as 'unsigned long' or 'unsigned int' on 32-bit systems. Then ensure the changes needed do not adversely affect inter-operability between 32-bit and 64-bit systems. After going through that exercise, perhaps, you will have gained a greater appreciation for what portability really means. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]exact integral types
On Tue, 10 Dec 2002, Warren Turkal wrote: On Tuesday 10 December 2002 03:24 pm, Marc Aurele La France wrote: After going through that exercise, perhaps, you will have gained a greater appreciation for what portability really means. Thank you for the explanation. In these places that warnings are produced, should the code call for a CARD32 instead of calling for an unsigned long or something like that? Something like that. Keep in mind though, that this code currently compiles on both 32-bit and 64-bit without any warnings related to long/int or signedness. There are also printf format strings to contend with. I attach the little bit I have on this matter (which includes your patch). Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. C99.diff.gz Description: Binary data
Re: [Xpert]exact integral types
On Sat, 19 Oct 2002, Warren Turkal wrote: Here is a patch that should make Xmd.h use C99 when available. --- /usr/include/X11/Xmd.h2002-10-16 15:14:38.0 -0500 +++ Xmd.h 2002-10-19 14:23:33.0 -0500 @@ -47,6 +47,7 @@ **/ #ifndef XMD_H #define XMD_H 1 + /* $Xorg: Xmd.h,v 1.4 2001/02/09 02:03:22 xorgcvs Exp $ */ /* * Xmd.h: MACHINE DEPENDENT DECLARATIONS. @@ -101,6 +102,36 @@ #define SIZEOF(x) sz_/**/x #endif /* if ANSI C compiler else not */ +#if defined(__STDC_VERSION__) (__STDC_VERSION__ == 199901L) ^^ This should be= + +#include stdint.h + +typedef uint8_t CARD8; +typedef uint16_t CARD16; +typedef uint32_t CARD32; +typedef uint64_t CARD64; + +typedef int8_t INT8; +typedef int16_t INT16; +typedef int32_t INT32; +typedef int64_t INT64; + +typedef CARD8 BYTE; +typedef CARD8 BOOL; + +typedef CARD32 BITS32; +typedef CARD16 BITS16; + +/*is there any reason why B32 and B16 cannot always be defined?*/ +# if defined(WORD64) +#define B32 :32 +#define B16 :16 +# else +#define B32 +#define B16 +# endif + +#else //__STDC_VERSION__ /* * Bitfield suffixes for the protocol structure elements, if you * need them. Note that bitfields are not guarranteed to be signed @@ -165,6 +196,8 @@ #define BOOL CARD8 #endif /* __EMX__ */ +#endif // __STDC_VERSION__ + /* * definitions for sign-extending bitfields on 64-bit architectures */ I have spent the time to review this change and found that it does not work (at least not as intended). First, a minor problem is that even GCC 3.2 #define's __STDC_VERSION__ only if compiling with -std=c99 (or -std=gnu99), but not with -ansi (the default we use). I am given to understand that this will change in some future GCC. A larger issue is that, on some 32-bit systems, this ends up typedef'ing CARD32 as 'unsigned int', and on others, as 'unsigned long'. For reasons I won't get into here, the X sources currently need CARD32 to be typedef'ed as 'unsigned long' for all 32-bit environments. The same issue, without 'unsigned' occurs with INT32. Bottom line: The X sources are not yet ready for C99, and a lot more work than this relatively simple change is needed to make them so. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]CVS Build Failing
On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote: Here's the error I get: make[4]: Leaving directory `/home/kwall/X/cvs/build/programs/Xserver/XTrap' cleaning in programs/Xserver/xfixes... make: Entering an unknown directory make: *** xfixes: No such file or directory. Stop. make: Leaving an unknown directory make[3]: *** [clean] Error 2 make[3]: Leaving directory `/home/kwall/X/cvs/build/programs/Xserver' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/kwall/X/cvs/build/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/kwall/X/cvs/build' make: *** [World] Error 2 I get this error even after removing build/xmakefile and re-executing make World. build is a shadow directory created using lndir. Could someone kindly hit me with a clue bat? Thanks. Stupid question: have you re-run lndir since the xfixes source appeared ? Yes. In fact, I deleted the old build directory and recreated it before sending my cry for help (lnddir -ignorelinks ../xc .), just in case I hadn't. Did you use -d when you last cvs update'd? A common mistake. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X11 problem on a sony vaio fx705 (fxa59)
On Wed, 20 Nov 2002, Tod Russell wrote: Apologies for posting a newbie question, but I am having problems starting X on a sony vaio fx705 laptop (european model identical to a fxa59) running Mandrake 8.2, and XFree86 4.2.0. When I run 'startx' I get a speckled grey screen with a red box in the upper left corner of the screen. I have modified lilo.conf to pass 'vga=788' to the kernel (2.4.18 patched and rebuilt with the acpi patch) as this seemed to work for others running redhat 7.3, but not for me. I have also commented out all modelines to use 'Native Panel Mode'. Other details, 1400x1050 15 SXGA, ATI 3D rage mobility m1. Any help would be greatly appreciated. Attached is my XF86Config-4 and XFree86.0.log. Try 'Option NoCompositeSync' in the M1's Device section of yoyr XF86Config. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xfree86 libint10 in non-x86 environments
On Sat, 23 Nov 2002, Egbert Eich wrote: However, the ATI rage drivers do not deal well with the lack of libint10 and seems to set really bogus video timings as a result (there are other bugs I've fixed where the rage driver will crash if libint10 is not present). In fact in the rage driver only part of the code checks for the existence of libint10 and other parts of the code blithely assumes it's existence. This is a bug. Not at all. That's quite intentional. Therefore we have a situation where on two boxes that are architecturally identical (or at least really really close) and depending on the installed video card libint10 has to be present or absent or really bad things happen. The solution proposed by Marc will solve this problem. I am in contact with HP to get docs for their ZX1-based systems so that I can add support for them (as I've already done for 460GX-based Itanium1's). Until that happens (I'm hoping in time for 4.3), XFree86 won't officially support such systems. As to int10, the intention is to extend it to deal with other ROM types, such as EFI, OF, etc. That means writting an emulator for each type. That won't happen tomorrow, but... Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH] Make xwd -frame -id work
On Thu, 21 Nov 2002, Eric Gillespie wrote: It has always annoyed me that xwd's -frame option does not work when a window id is given with -id. Yes, i know that these are separate windows with separate ids, but the id of the actual client window is much more easily available than the window manager frame's id (for example, easily available to fvwm functions via $w). So i changed the frame_only logic (any way we can change that variable name? It isn't at all accurate...) instead of just skipping the find-the-real-client-window step if -frame is given, it will actually climb the window tree to find the wm frame. What do you think? please, Please, PLEASE, post patches to [EMAIL PROTECTED], not here. That way, you ensure it won't be forgotten in somebody's sea of e-mail. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]V_BIOS error at ATI card.
On Tue, 12 Nov 2002, Yongho Kwak wrote: I would like to resolve some problems in ATI card. I Configured dual VGA card(Nvidia and ATI) setting but ATI do not work. X do not read V_BIOS of ATI card. What can I do for it? The ATI adapter is built into the motherboard, is it not? If so, tell your BIOS to use it as the primary adapter. This is the only way it can be used in a multi-head setup. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI V_BIOS reading
On Fri, 8 Nov 2002, Yongho Kwak wrote: I have a problem with ATI drive. When I configured the XF86Config for dual monitor, there was error for ATI card. (--) PCI:*(0:14:0) NVidia Riva TNT2 M64 rev 21, Mem @ 0xfa00/24, 0xf400/25, BIOS @ 0x8000/16 (--) PCI: (1:0:0) ATI Mach64 GB rev 92, Mem @ 0xfd00/24, 0xfcfff000/12, I/O @ 0xec00/8 // (II) ATI: Candidate Device section ATI 3D Rage Pro. (II) ATI: Shared PCI/AGP Mach64 in slot 1:0:0 detected. (II) ATI: Shared PCI/AGP Mach64 in slot 1:0:0 assigned to active Device section ATI 3D Rage Pro. // (II) Loading sub module atimisc (II) LoadModule: atimisc (II) Loading /usr/X11R6/lib/modules/drivers/atimisc_drv.o (II) Module atimisc: vendor=The XFree86 Project compiled for 4.2.0, module version = 6.4.8 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.5 // (II) Setting vga for screen 0. (II) Setting vga for screen 1. (II) Loading sub module int10 (II) LoadModule: int10 (II) Loading /usr/X11R6/lib/modules/linux/libint10.a (II) Module int10: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (II) NV(0): Initializing int10 (II) NV(0): Primary V_BIOS segment is: 0xc000 (--) NV(0): Chipset: RIVA TNT2 M64 (**) NV(0): Depth 16, (--) framebuffer bpp 16 (==) NV(0): RGB weight 565 (==) NV(0): Default visual is TrueColor (II) Loading sub module vgahw (II) LoadModule: vgahw // (II) Loading sub module fb (II) LoadModule: fb (II) Loading /usr/X11R6/lib/modules/libfb.a (II) Module fb: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 ABI class: XFree86 ANSI C Emulation, version 0.1 (II) Loading sub module xaa (II) LoadModule: xaa (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (II) Loading sub module ramdac (II) LoadModule: ramdac (II) Loading /usr/X11R6/lib/modules/libramdac.a (II) Module ramdac: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (==) ATI(1): Chipset: ati. (**) ATI(1): Depth 16, (--) framebuffer bpp 16 (**) ATI(1): Option reference_clock 14.318MHz (II) Loading sub module int10 (II) LoadModule: int10 (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a (EE) ATI(1): Cannot read V_BIOS (WW) ATI(1): Unable to initialise int10 interface. (EE) ATI(1): Adapter has not been initialised. (II) UnloadModule: ati (II) UnloadModule: int10 (II) UnloadModule: atimisc (II) Unloading /usr/X11R6/lib/modules/drivers/atimisc_drv.o (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 1 0xfcfff000 - 0xfcff (0x1000) MS[B] [1] 1 0xfd00 - 0xfdff (0x100) MS[B] How can I do for this? Start by posting a complete log. You're leaving out a lot of important information. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]256 megs board fails Validation,
On Mon, 4 Nov 2002, Marc Aurele La France wrote: I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits= 2147483648. The Xserver calculates the memory in bits when validating the mode. No, it doesn't. apertureSize is in bytes. apertureSize is indeed in bytes, but in xf86Modes.c, xf86InitialCheckModeForDriver() has this check. This is in XFree86 4.2.0. -- if (mode-HDisplay * mode-VDisplay * scrp-fbFormat.bitsPerPixel scrp-videoRam * (1024 * 8)) return MODE_MEM; -- where: scrp -videoRam = 256 * 1024 ( since videoRam is in Kbytes) When calculating the right hand side of the comparison, the right hand side is equal to 256*1024*1024*8 = 2^31. The left hand side is also calculated in bits, since it multiplies the display by the number of bits per pixel. I stand corrected. I'll take care of this. Thanks for pointing it out. I've committed a change that should be able to handle video memory sizes of up to 8GB. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]256 megs board fails Validation,
On Mon, 4 Nov 2002, Luugi Marsan wrote: There's a problem when validating a given mode. The board I have has 256 megs and it fails crying that it has insufficient memory for the given mode. This happens because the videoRam in bits is equal to 2^31 ( 256 megs). The number passes the numerical limit of an int. I believe that the videoRam should be an unsigned int instead of a signed int. What do you think? Will this change create other problems? Y2K all over again. :) sorry, but your number theory has some error. 2^1 = 2 (1 bit, counting from 0 to 1 = 2 values) 2^2 = 4 (2 bits, counting from 0 to 3 = 4 values) 2^4 = 8 (3 bits counting from 0 to 7 = 8 values) [...] 2^31 = 2 GB 2^32 = 4 GB an integer with 32 bits has 1 bit sign and 31 bits for numeric value. this is (-2GB) to (+2GB-1). so your 256 MB limit must arise from somewhere else. for your case you should better starting the printf debugger or real debugging. maybe PCI or AGP config caps, or MTRR caps are the limiting factor, or its just a driver bug. (wild guessing) I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits= 2147483648. The Xserver calculates the memory in bits when validating the mode. No, it doesn't. apertureSize is in bytes. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]256 megs board fails Validation,
On Mon, 4 Nov 2002, Luugi Marsan wrote: I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits= 2147483648. The Xserver calculates the memory in bits when validating the mode. No, it doesn't. apertureSize is in bytes. apertureSize is indeed in bytes, but in xf86Modes.c, xf86InitialCheckModeForDriver() has this check. This is in XFree86 4.2.0. -- if (mode-HDisplay * mode-VDisplay * scrp-fbFormat.bitsPerPixel scrp-videoRam * (1024 * 8)) return MODE_MEM; -- where: scrp -videoRam = 256 * 1024 ( since videoRam is in Kbytes) When calculating the right hand side of the comparison, the right hand side is equal to 256*1024*1024*8 = 2^31. The left hand side is also calculated in bits, since it multiplies the display by the number of bits per pixel. I stand corrected. I'll take care of this. Thanks for pointing it out. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Bug with virtual screen panning and mouse positioning
On 29 Oct 2002, Gregory Stark wrote: I reported a bug a while ago and didn't receive any response. In recent releases of 4.2.1 the behaviour has changed slightly. The change in behaviour makes me suspect somebody might think they've fixed the bug but in fact it's still present. The problem manifests when in a screen size smaller than the frame buffer size. So for example I normally operate in 1600x1200 but sometimes switch resolution to 800x600 or 640x480 and pan around with the mouse to see small details clearly. When I do this I often see something weird. A small slice of the right side of the screen shows pixels from elsewhere on the frame. For example, right now I'm in 1280x1024 with a 1600x1200 frame buffer, and the rightmost 4 pixels are showing the slice of pixels that also appear 769 from the left of the screen. Ie, as I move windows around in the middle of the screen when they pass the 769 mark i see them on the right edge as well. The hardware mouse does not appear there. However another bug occurs with the mouse. When I hit the edge and the screen pans the mouse hotpoint doesn't stay synced with the pointer. This has the result that whenever I'm in a reduced screen resolution the mouse hotpoint has a random displacement relative to the pointer of up to 4 pixels. This is obvious if you drag an object to the edge, you can see the object move while the mouse stays still, then the screen pans and the mouse leaps ahead of the object. This used to be 8 pixels and the exact behaviour of the hotpoint when panning was subtly different. That's why I suspect somebody may have already tried to fix this bug and the fact that it's been around so long leads me to suspect perhaps they think they fixed it. In fact if anything it's gotten worse with the new problem of the incorrect pixels appearing at the edge. The log shows you are only using the Matrox adapter. So, a few questions arise: - Do you see the same problems using the Mach64 GT? - WRT the mouse problem with the Matrox, what effect does Option SWCursor have? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Source code
On 31 Oct 2002, btouchet wrote: My name is Kiumars Sabeti and I am with S3 Graphics. I would like to submit source code for our SuperSavage Linux driver. Since this the first time that we are submitting source code directly, I need your help to walk me through the submission process. Send, to [EMAIL PROTECTED], a description and a patch against the latest ^ public release (now 4.2.0), or, better, against the current HEAD branch of the XFree86 CVS. You will get an auto-reply as confirmation of receipt. I just ran across this, and would like to know what is the acceptable format for submitting a new driver (tarball, diff, etc)? Should it be against the whole tree (ie. one big patch, indiviual files, etc)? Any clarifications would be appreciated. Done. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Error in building my module--Please help
On Tue, 29 Oct 2002, Roy wrote: Hi,list I'm trying to write a module for X,but I got some error msg witch I can't understand when building them,And I tried to find out the answer in the list but I failed: ../../../../../../programs/Xserver/hw/xfree86/common/xf86str.h:250: warning: comma at end of enumerator list ../../../../../../programs/Xserver/hw/xfree86/common/xf86str.h:250: parse error before `0x10' ../../../../../../programs/Xserver/hw/xfree86/common/xf86str.h:251: warning: comma at end of enumerator list I'd modify the xf86str.h---replace BUS_ISA BUS_PCI with BUS_NONE1 BUS_NONE2,then my module can pass the gcc,by failed to run. Can somebody tell me what's wrong and what can I do? Sounds like your code is #include'ing linux/input.h. Have a look at what is done about this in the acecad and wacom drivers. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xfree 4.2 fails to initialize LCD screen
On Sun, 27 Oct 2002, Charles Moon wrote: I have a Sony Vaio Laptop PCG-FXA59 with a 1400 x 1050 native display powered by an ATI Rage Mobility M1 AGP adapter. When I attempted to install RedHat 8.0, the anaconda graphical setup correctly probed the ATI chip, but returned unknown for monitor. At that point a small white square appeared in the upper left corner of the screen and intermittent flashes of color appeared over the screen. The only way out was to shutdown. After using the text based upgrade over a fully functioning installation of RH 7.2, when I tried to start the x server [startx] the exact same screen abberation happened. Upon further testing I have discovered I can get the LCD display to work IF when I start the Try 'Option NoCompositeSync' in the XF86Config's device section. Thanks for the tip, but it didn't work. Then please send me /var/log/XFree86.0.log, after an attempt to run the server with -logverbose 4 after a power-down/reboot sequence. I can't promise I'll be able to resolve this issue (due to remote debugging considerations et al.), but I'm willing to give it a shot. OK, here's the log. If you see anything particularly incriminating, let me know. I have also uploaded a photo of the screen if you want to see exactly what it is doing http://www.cmgd.net/archive/vaio_on_x.jpg First off, this log was not generated with the -logverbose 4 server flag. Please regenerate and resend. But before you do that, edit /etc/X11/XF86Config, comment out any HorizSync and VertRefresh you find, and restart the server. If that works, forgo resending me the log. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xfree 4.2 fails to initialize LCD screen
On Wed, 23 Oct 2002, Charles Moon wrote: I have a Sony Vaio Laptop PCG-FXA59 with a 1400 x 1050 native display powered by an ATI Rage Mobility M1 AGP adapter. When I attempted to install RedHat 8.0, the anaconda graphical setup correctly probed the ATI chip, but returned unknown for monitor. At that point a small white square appeared in the upper left corner of the screen and intermittent flashes of color appeared over the screen. The only way out was to shutdown. After using the text based upgrade over a fully functioning installation of RH 7.2, when I tried to start the x server [startx] the exact same screen abberation happened. Upon further testing I have discovered I can get the LCD display to work IF when I start the Try 'Option NoCompositeSync' in the XF86Config's device section. Thanks for the tip, but it didn't work. Then please send me /var/log/XFree86.0.log, after an attempt to run the server with -logverbose 4 after a power-down/reboot sequence. I can't promise I'll be able to resolve this issue (due to remote debugging considerations et al.), but I'm willing to give it a shot. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xfree 4.2 fails to initialize LCD screen
On Wed, 23 Oct 2002, Charles Moon wrote: I have a Sony Vaio Laptop PCG-FXA59 with a 1400 x 1050 native display powered by an ATI Rage Mobility M1 AGP adapter. When I attempted to install RedHat 8.0, the anaconda graphical setup correctly probed the ATI chip, but returned unknown for monitor. At that point a small white square appeared in the upper left corner of the screen and intermittent flashes of color appeared over the screen. The only way out was to shutdown. After using the text based upgrade over a fully functioning installation of RH 7.2, when I tried to start the x server [startx] the exact same screen abberation happened. Upon further testing I have discovered I can get the LCD display to work IF when I start the Try 'Option NoCompositeSync' in the XF86Config's device section. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
On 22 Oct 2002, Michel Dänzer wrote: That the new header is being picked up seems the only viable explanantion for the reported symptom. How it got there is irrelevant. Perhaps re-installing glibc from source re-syncs the headers, I don't know. Or, possibly, this system simply does not implement the glibc/kernel version skew some distributions are so prone to. I'm sure you mean the sane technical solution explained in http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html ? I'd be able to tell you if that site currently accepted connections. But, again, where /usr/include/linux/kd.h comes from is irrelevant to the reported problem. As far as I'm concerned, this issue is closed until such a time when the kernel folk again rename something they shouldn't. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
On 22 Oct 2002, Michel Dänzer wrote: As far as I'm concerned, this issue is closed until such a time when the kernel folk again rename something they shouldn't. Can't you see that the kernel folks can do whatever they want, so long as people use a sane setup where there are no kernel headers in /usr/include? glibc's /usr/include/linux/kd.h ultimately hails from the kernel's include/linux/kd.h. The field name change was propagated through this system's upgrade to a bleeding edge glibc. My argument stands. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
On 22 Oct 2002, Michel Dänzer wrote: glibc's /usr/include/linux/kd.h ultimately hails from the kernel's include/linux/kd.h. The field name change was propagated through this system's upgrade to a bleeding edge glibc. Less bleeding edge than the kernel it was built against, apparently, or I'd expect it to deal with the rename. It does, by not caring. This is ioctl data after all. My argument stands. It always does, no need to spell it out... Sorry. I don't mean to sound pedantic. I guess I've been involved in too many discussions trying to go off on a tangent these past weeks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
On 21 Oct 2002, Michel Dänzer wrote:
On Son, 2002-10-20 at 23:57, Marc Aurele La France wrote:
On Sat, 19 Oct 2002, Boris wrote:
Hmm, Seems to be alot of problems in the CVS the last few days. Heres
the latest one.
[elided]
Recently upgraded to a 2.5.42+ kernel did we? If so, harp about this on
LKML. Let me know what the outcome is.
Actually, I just recompiled my 2.4.20pre11 kernel and redownloaded the
latest XFree cvs and I *still* get the same error when doing a make
install. Im running 2.4.20pre11, gcc 3.2, glibc 2.3.1.
Sounds like your /usr/include/{linnux,asm} links are still pointing into
the 2.5.43 kernel.
... but they shouldn't be links to kernel headers at all, but normal
glibc headers. There wouldn't have been a problem in the first place
like that.
That the new header is being picked up seems the only viable explanantion
for the reported symptom. How it got there is irrelevant. Perhaps
re-installing glibc from source re-syncs the headers, I don't know. Or,
possibly, this system simply does not implement the glibc/kernel version
skew some distributions are so prone to.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 Core Team member. ATI driver and X server internals.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]exact integral types
On Thu, 17 Oct 2002, Warren Turkal wrote: Why does X not use the exact integral types in its typedefs? For instance, typedef uint32_t CARD32; instead of all the magic in Xmd.h? These are the ISO C 9X integer types aren't they ? I don't think we have got as far as completely ansi'fing the code yet, never mind using C-9X features. It might be a worthwhile project to make that file use C-9X when available, and only then grovel deep inside systems for older compilers, but basically it is a case of if it ain't broke, don't fix it. In the Xmd.h file, would it be okay to change the preprocessor directives to #if define(symbol) and such? Please post exactly what you have in mind (and what problem you're trying solve) and we'll see. C99 has integer types that have an exact width. For instance, uint32_t is an unsigned integer of 32 bit width. This would put the burden of making the right width integer types on the c library as opposed to the x include. I think that, if possible, getting rid of architecture magic in the include files would make them more understandable and possibly easier to port to other architectures. Some of the systems XFree86 runs on have yet to see C89, let alone C99. Suggesting that this not be so would encounter a lot of resistance IMNSHO. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VTswitch
On 17 Oct 2002, Michel Dänzer wrote: On Don, 2002-10-17 at 04:50, David Dawes wrote: On Tue, Oct 15, 2002 at 12:28:27AM +0200, Charl P. Botha wrote: On Mon, Oct 14, 2002 at 04:14:22PM -0600, Marc Aurele La France wrote: On Tue, 15 Oct 2002, Charl P. Botha wrote: This would mean that the bug is back and people will again have the stupid No, it doesn't. VT switch lockup. What would be the New and Improved Way(tm) way of explicitly re-enabling bus-mastering at RADEONEnterVT() time since xf86EnablePciBusMaster() has been deprecated? Just like the change notice says: When a PCI device is enabled, it's bus mastering is also enabled. This occurs before any driver code is executed. I'm running the DRI tree, so I can't test. However, we still don't know why these cards disabled bus mastering at VT switches (when it was very clearly enabled before the switch), so what guarantees that they won't still do this? Mike (Harris), do you have one of the affected cards running XFree86 HEAD? No, the X server restores changes is makes to the PCI state when it gives up control of the console, so if bus mastering wasn't enabled *before* the X server started, it won't be after VT switching away. Several drivers had bugs where they didn't re-enable it when switching back. Drivers shouldn't assume anything more about the HW state after returning from a VT switch than they would at startup, but unfortunately some still do... Marc's change means that drivers don't need to care about bus mastering being enabled because it will now be enabled automatically for PCI cards that are being used by the X server. Sounds good, unfortunately it doesn't seem to work for the original poster - any idea why? Charl P. Botha did not actually try it. Thus, the key word in your sentence above remains seem. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VTswitch
On Thu, 17 Oct 2002, Charl P. Botha wrote: On Thu, Oct 17, 2002 at 11:17:39AM -0600, Marc Aurele La France wrote: On 17 Oct 2002, Michel Dänzer wrote: Sounds good, unfortunately it doesn't seem to work for the original poster - any idea why? Charl P. Botha did not actually try it. Thus, the key word in your sentence above remains seem. Sorry for the long quote above, but this should be almost the last mail in this thread. I've tested with CVS XFree86, and all is well. Bus mastering gets disabled when switched to VT but gets enabled again when switching back to X. The problem WAS that this re-enabling did not always take place before Marc's changes, which is why we added the explicit call to do this. I've checked the code in current XFree86 CVS, but would very much like to know (just for interest's sake) WHERE exactly the PCI enable (or whatnot) is called from that re-enables bus mastering after a VT switch. The question on my, and David's, mind is whether or not bus mastering was enabled on server entry. I will not answer your query more directly because I think it would be a good thing for you to figure out on your own what line 1309 of the current hw/xfree86/common/xf86Events.c does. Thanks and my apologies for the upset. Indeed. In the future, please differentiate between real and perceived problems. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]exact integral types
On Wed, 16 Oct 2002, Warren Turkal wrote: Why does X not use the exact integral types in its typedefs? For instance, typedef uint32_t CARD32; instead of all the magic in Xmd.h? These are the ISO C 9X integer types aren't they ? I don't think we have got as far as completely ansi'fing the code yet, never mind using C-9X features. It might be a worthwhile project to make that file use C-9X when available, and only then grovel deep inside systems for older compilers, but basically it is a case of if it ain't broke, don't fix it. In the Xmd.h file, would it be okay to change the preprocessor directives to #if define(symbol) and such? Please post exactly what you have in mind (and what problem you're trying solve) and we'll see. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]gram.y:451.3-461.18: type clash (`' `num') on defaultaction
On Thu, 17 Oct 2002, ISHIKAWA Mutsumi wrote: Trying to compile cvs HEAD on a PPC machine running Debian SID: make[3]: Entering directory `/usr/src/xc/programs/twm' bison -y -d gram.y gram.y:451.3-461.18: type clash (`' `num') on default action gram.y:657.9: parse error, unexpected :, expecting ; or | make[3]: *** [gram.c] Error 1 I am guessing this is some sort of development environment problem? Can someone tell me how to get this working? Bison 1.50 doesn't accept ambiguous rules that was no problem prior to bison 1.50. I was sent some patches for building the current XFree86 with bison 1.50 to xfree86 patches ML and Debian BTS. Please refer the message bellow: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164486repeatmerged=yes http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164489repeatmerged=yes http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164491repeatmerged=yes This should now be fixed in current CVS. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]rage pro (16mb) symbol errors
On Fri, 11 Oct 2002, Geoffrey wrote: That's a hang. The box is not responding to anything. I'd like to see what's left of /var/log/XFree86.0.log after the reboot that's needed to get it out of that state. Okay, you ready for this. No file, none, not even a null file. What do you make of that? I tried it twice just to make sure I wasn't losing my mind. Try replacing that Driver r128 line with Driver ati. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VT switch
On Tue, 15 Oct 2002, Charl P. Botha wrote:
You might remember a while back that several Radeon and R128 boards suffered
from a server crash at VT switch time. This was due to the fact that these
cards (for some or other reason) disable bus mastering when switching to VT.
The bug was fixed by adding a call to xf86EnablePciBusMaster() in
{RADEON,R128}EnterVT(). This change was subsequently committed to both DRI
and XFree86 main trees.
I noticed the other day that this change has disappeared again with the
following CVS log message:
revision 1.65
date: 2002/10/08 22:14:05; author: tsi; state: Exp; lines: +1 -8
367. When enabling PCI adapters, also enable their bus mastering capability;
Consequently, deprecate xf86EnablePciBusMaster() (Marc La France).
This would mean that the bug is back and people will again have the stupid
No, it doesn't.
VT switch lockup. What would be the New and Improved Way(tm) way of
explicitly re-enabling bus-mastering at RADEONEnterVT() time since
xf86EnablePciBusMaster() has been deprecated?
Just like the change notice says: When a PCI device is enabled, it's bus
mastering is also enabled. This occurs before any driver code is
executed.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 Core Team member. ATI driver and X server internals.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]rage pro (16mb) symbol errors
On Thu, 10 Oct 2002, Geoffrey wrote: I've been trying to get my dual head radeon ve working, gave up and stuck another card in this box, rage pro (16mb). It appears from the log that both are recognized, but then I get: Symbol fbdevHWGetLineLength from module /usr/X11R6/lib/modules/drivers/r128_drv.o is unresolved! That's hardly the actual problem, we need more info from your log. I've attached it as well as the config file. I appreciate any further insites. Try removing the BusID from the Rage Pro's device section. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]rage pro (16mb) symbol errors
On Fri, 11 Oct 2002, Geoffrey wrote: Try removing the BusID from the Rage Pro's device section. Well, I stuck the rage card into another box, used XFree86 -configure and the card works fine. the BusID entry was added to the config as well, inspite of the fact it's a single card in the box. I don't have another box that has an agp card slot, so I'm not going to be able to test the radeon/rage together until I have some time to figure out why it's locking my box up. Thanks for the insights, further suggestions will be appreciated as I'd really like to get this going. Well, if you want to figure out why it hangs, you'll have to let it hang. What's left of the log when this happens would be useful. However, for that to be most useful, an install of the current sources is in order. Up to you. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 on Solaris Sun Blade 100?
On Tue, 8 Oct 2002, Andrew P. Lentvorski wrote: Well, XFree86 looks like it gets further, but now it has a different failure message: XFree86 Version 4.2.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 26 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: SunOS 5.8 Generic_108528-13 sun4u Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Tue Oct 8 20:15:36 2002 (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on solaris (II) LoadModule: bitmap (WW) Warning, couldn't open module bitmap (II) UnloadModule: bitmap (EE) Failed to load module bitmap (module does not exist, 0) (II) LoadModule: pcidata (II) Loading /tools/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 Fatal server error: Unable to load required base modules, Exiting... Please don't post this anymore. I'd rather see the full /var/log/XFree86.0.log. root@wile:xc# ls /tools/X11R6/lib/modules drivers libfb.a libscanpci.a libxf8_16bpp.a extensions libi2c.a libshadow.a libxf8_32bpp.a inputlibint10.a libshadowfb.alibxf8_32wid.a libcfb.a liblayer.a libvbe.a v10002d.uc libcfb16.a libmfb.a libxaa.a v20002d.uc libcfb24.a libpcidata.a libxf1bpp.a libcfb32.a librac.a libxf24_32bpp.a libddc.a libramdac.a libxf4bpp.a root@wile:xc# ls /tools/X11R6/lib/modules/drivers/ apm_drv.oimstt_drv.o suncg3_drv.o ark_drv.omga_drv.osuncg6_drv.o ati_drv.oneomagic_drv.o sunffb_drv.o atimisc_drv.onewport_drv.osunleo_drv.o chips_drv.o nv_drv.o suntcx_drv.o cirrus_alpine.o r128_drv.o tdfx_drv.o cirrus_drv.o radeon_drv.o tga_drv.o cirrus_laguna.o rendition_drv.o trident_drv.o dummy_drv.o s3virge_drv.ovesa_drv.o fbdev_drv.o savage_drv.o vga_drv.o glint_drv.o siliconmotion_drv.o vmware_drv.o i128_drv.o sunbw2_drv.o i740_drv.o suncg14_drv.o root@wile:xc# ls /tools/X11R6/lib/modules/extensions/ libGLcore.a libextmod.a libpex5.alibxtrap.a libdbe.a libglx.a librecord.a Is anything else required? I kept the World and install logs in case they are required. For some reason, you are missing /tools/X11R6/lib/modules/fonts/ (and /tools/X11R6/lib/modules/codeconv/). Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]problem when compiling X
On Tue, 8 Oct 2002, David Dawes wrote: On Mon, Sep 30, 2002 at 07:12:30PM -0600, Marc Aurele La France wrote: I must admit to being rather surprised that *BSD doesn't have strtoull() yet (but allows long long). I was really hoping to avoid ugly #if's in this code. Oh well, such is life. This'll be fixed shortly. Some do. This from FreeBSD 4.4's strtoul(3)/strtoull(3)/strtouq(3) man page: NAME strtoul, strtoull, strtouq - convert a string to an unsigned long, unsigned long long, or uquad_t integer ... STANDARDS The strtoul() function conforms to ISO/IEC 9899:1990 (``ISO C89''). The strtoull() function conforms to ISO/IEC 9899:1999 (``ISO C99''). The BSD strtoq() function is deprecated. Deprecated it may (permission, not just possibility) be, but necessary for this code in the short-to-medium term. The #if didn't turn out to be all that ugly after all... Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 on Solaris Sun Blade 100?
On Wed, 2 Oct 2002, Marc Aurele La France wrote: On Wed, 2 Oct 2002, Joshua Symons wrote: gcc 3.2 which happens to actually be quite clean on solaris at this point does indeed default to 32 bit, requiring the -m64 switch to compile 64 bit code. OK. I'll verify this and make the appropriate changes. Thanks for the heads-up. I'm now running with an aperture driver generated with gcc 3.2, and have updated the shell archive for the aperture driver accordingly. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]problem in Pci.c
On Thu, 3 Oct 2002 [EMAIL PROTECTED] wrote: This is problem in OpenBSD 3.1 stable , Xfree current. making all in programs/Xserver/hw/xfree86/os-support/bus... rm -f Pci.o gcc -c -O2 -ansi -Dasm=__asm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef-I. -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../../programs/Xserver/include -I../../../../../../exports/include/X11 -I../../../../../.. -I../../../../../../exports/include -DCSRG_BASED -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DRANDR -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -O0 Pci.c In file included from Pci.c:174: /usr/include/signal.h: In function `sigaddset': /usr/include/signal.h:69: warning: redundant redeclaration of `errno' in same scope /usr/include/errno.h:45: warning: previous declaration of `errno' /usr/include/signal.h: In function `sigdelset': /usr/include/signal.h:80: warning: redundant redeclaration of `errno' in same scope /usr/include/errno.h:45: warning: previous declaration of `errno' /usr/include/signal.h: In function `sigismember': /usr/include/signal.h:91: warning: redundant redeclaration of `errno' in same scope /usr/include/errno.h:45: warning: previous declaration of `errno' Pci.c: In function `pciInit': Pci.c:245: syntax error before `}' *** Error code 1 Stop in /usr/src/XF4/xc/programs/Xserver/hw/xfree86/os-support/bus (line 990 of Makefile). *** Error code 1 any ideas and fixes? Mea culpa. Should be fixed now. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 on Solaris Sun Blade 100?
On Wed, 2 Oct 2002, Andrew P. Lentvorski wrote: Besides, I see no complaint here about the other drivers that are in the same boat (e.g. newport, i740, etc). So, what problem did including i810 cause? Some form of missing header, I think. If I get this all working, I'll go back to the beginning of a clean compile and file a report. OK. What does `prtconf -Ppv` say? Do you *really* want all that? Not yet, no. I was trying to get it to recognize the onboard ATI Rage XL chip defined for screen. Here's the pci node: Node 0xf002d0dc screen: '/pci@1f,0/SUNW,m64B@13' mouse: '/pci@1f,0/usb@c,3/mouse@4' keyboard: '/pci@1f,0/usb@c,3/keyboard@2' net: '/pci@1f,0/network@c,1' cdrom2: '/pci@1f,0/ide@d/cdrom@2,0:f' cdrom1: '/pci@1f,0/ide@d/cdrom@1,0:f' cdrom: '/pci@1f,0/ide@d/cdrom@1,0:f' disk: '/pci@1f,0/ide@d/disk@0,0' disk3: '/pci@1f,0/ide@d/disk@3,0' disk2: '/pci@1f,0/ide@d/disk@2,0' disk1: '/pci@1f,0/ide@d/disk@1,0' disk0: '/pci@1f,0/ide@d/disk@0,0' ide: '/pci@1f,0/ide@d' floppy: '/pci@1f,0/isa@7/dma/floppy' ttyb: '/pci@1f,0/isa@7/serial@0,2e8' ttya: '/pci@1f,0/isa@7/serial@0,3f8' name: 'aliases' For that matter, anything interesting in /var/log/XFree86.0.log? Possibly. Here's an excerpt: (II) LoadModule: pcidata (II) Loading /tools/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (WW) xf86LinearVidMem: failed to open /dev/fbs/aperture (No such file or directory) (WW) xf86LinearVidMem: either /dev/fbs/aperture or /dev/xsvc device driver required (WW) xf86LinearVidMem: linear memory access disabled (EE) No OS PCI support available This is the problem. Please read point 1. of section 4. in README.Solaris. You need to install the aperture driver. In looking this documentation over, I see that I forget to mention that the aperture driver must be compiled as a 64-bit binary, something I have been so far unable to coerce gcc into producing. So, for now, I recommend using Sun's cc to build this driver. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 on Solaris Sun Blade 100?
On Wed, 2 Oct 2002, Andrew P. Lentvorski wrote: This is the problem. Please read point 1. of section 4. in README.Solaris. You need to install the aperture driver. Argh. Somehow my brain managed to mangle the meaning of the third paragraph. I think it was the mention of Solaris x86 2.5 followed by For older. Mea culpa. As a side note, your comments about the 64-bitness aperture driver clash with Section 3 Point 1 Paragraph 3 of the README.Solaris file: On SPARCs, regardless of the compiler you use, ensure it generates 32-bit binaries. At this time, 64-bit binaries will probably not work. This comment was the reason why I specifically chose gcc 2.95.3 rather than going to a newer version which would have a better shot at 64-bit binaries. My prohibition against 64-bit applies to userland only, and is a consequence of the current XFree86 source code. The aperture driver however is part of the kernel's context, and must run in a 64-bit environment. Assuming GCC 3.* supports 64-bit ELF binaries, I would still expect it to default to 32-bit (like Sun's compiler does). If that's not the case, I'll need to make changes. In addition, the README.Solaris spends an awful lot of lines on unsupported VT-switching before even getting to XFree86 compiling and configuration. Perhaps the whole README.Solaris needs a good, solid rewrite to match the current state of XFree86. I completely agree. What's there now is simply a QD evolution of what was there before. (You know: us developers don't fancy writing docs, right?) If you have something better, send me a patch against doc/sgml/Solaris.sgml. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 on Solaris Sun Blade 100?
On Wed, 2 Oct 2002, Joshua Symons wrote: This is the problem. Please read point 1. of section 4. in README.Solaris. You need to install the aperture driver. Argh. Somehow my brain managed to mangle the meaning of the third paragraph. I think it was the mention of Solaris x86 2.5 followed by For older. Mea culpa. As a side note, your comments about the 64-bitness aperture driver clash with Section 3 Point 1 Paragraph 3 of the README.Solaris file: On SPARCs, regardless of the compiler you use, ensure it generates 32-bit binaries. At this time, 64-bit binaries will probably not work. This comment was the reason why I specifically chose gcc 2.95.3 rather than going to a newer version which would have a better shot at 64-bit binaries. My prohibition against 64-bit applies to userland only, and is a consequence of the current XFree86 source code. The aperture driver however is part of the kernel's context, and must run in a 64-bit environment. Assuming GCC 3.* supports 64-bit ELF binaries, I would still expect it to default to 32-bit (like Sun's compiler does). If that's not the case, I'll need to make changes. In addition, the README.Solaris spends an awful lot of lines on unsupported VT-switching before even getting to XFree86 compiling and configuration. Perhaps the whole README.Solaris needs a good, solid rewrite to match the current state of XFree86. I completely agree. What's there now is simply a QD evolution of what was there before. (You know: us developers don't fancy writing docs, right?) If you have something better, send me a patch against doc/sgml/Solaris.sgml. gcc 3.2 which happens to actually be quite clean on solaris at this point does indeed default to 32 bit, requiring the -m64 switch to compile 64 bit code. OK. I'll verify this and make the appropriate changes. Thanks for the heads-up. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: Re: [Xpert]problem when compiling X
On Wed, 2 Oct 2002 [EMAIL PROTECTED] wrote: Hello all, i have problem when compile X under OpenBSD 3.1 i386 latest stable and X (current). Any body know how to fix this problem? Yes, I know. You've said that already... I must admit to being rather surprised that *BSD doesn't have strtoull() yet (but allows long long). I was really hoping to avoid ugly #if's in this code. Oh well, such is life. This'll be fixed shortly. I also note *BSD's libc is just as noisy as glibc ;-) I 7 days trying to compile X under OpenBSD 3.1 i386 latest stable and configure my new video card (GForce 4 MX 420), i try current from OpenBSD tree but unable to compile (error in bsd key ...), try 4.2.1 from xfree cvsup, unable to compile and my video card not supported, try current from cvsup.xfree86... unable to compile ( strtoull bla bla). I am very angry, any body know where i can get current snapshot (daily end-day build tree) comiled for OpenBSD 3.1 ? This should now be fixed in XFree86's CVS repository (HEAD branch). I have no interaction with OpenBSD's repository. Talk to them, if that's where you are cvs update'ing from. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]problem when compiling X
On Mon, 30 Sep 2002 [EMAIL PROTECTED] wrote: Hello all, i have problem when compile X under OpenBSD 3.1 i386 latest stable and X (current). Any body know how to fix this problem? Yes, I know. You've said that already... rm -f mmapr.o gcc -c -O2 -ansi -Dasm=__asm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I. -I../../../../../programs/Xserver/hw/xfree86/common -I../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../programs/Xserver/include -I../../../../../exports/include/X11 -I../../../../../programs/Xserver/hw/xfree86/scanpci -I../../../../../programs/Xserver/hw/xfree86/dummylib -I../../../../.. -I../../../../../exports/include -DCSRG_BASED -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DUSE_I386_IOPL mmapr.c In file included from mmapr.c:34: /usr/include/unistd.h:66: warning: redundant redeclaration of `cuserid' in same scope /usr/include/stdio.h:274: warning: previous declaration of `cuserid' /usr/include/unistd.h:92: warning: redundant redeclaration of `lseek' in same scope /usr/include/sys/types.h:142: warning: previous declaration of `lseek' /usr/include/unistd.h:138: warning: redundant redeclaration of `ftruncate' in same scope /usr/include/sys/types.h:143: warning: previous declaration of `ftruncate' /usr/include/unistd.h:206: warning: redundant redeclaration of `truncate' in same scope /usr/include/sys/types.h:144: warning: previous declaration of `truncate' /usr/include/unistd.h:215: warning: redundant redeclaration of `getopt' in same scope /usr/include/stdlib.h:168: warning: previous declaration of `getopt' /usr/include/unistd.h:216: warning: redundant redeclaration of `optarg' in same scope /usr/include/stdlib.h:169: warning: previous declaration of `optarg' /usr/include/unistd.h:217: warning: redundant redeclaration of `opterr' in same scope /usr/include/stdlib.h:170: warning: previous declaration of `opterr' /usr/include/unistd.h:218: warning: redundant redeclaration of `optind' in same scope /usr/include/stdlib.h:171: warning: previous declaration of `optind' /usr/include/unistd.h:219: warning: redundant redeclaration of `optopt' in same scope /usr/include/stdlib.h:172: warning: previous declaration of `optopt' /usr/include/unistd.h:220: warning: redundant redeclaration of `optreset' in same scope /usr/include/stdlib.h:173: warning: previous declaration of `optreset' /usr/include/unistd.h:221: warning: redundant redeclaration of `getsubopt' in same scope /usr/include/stdlib.h:174: warning: previous declaration of `getsubopt' /usr/include/unistd.h:222: warning: redundant redeclaration of `suboptarg' in same scope /usr/include/stdlib.h:175: warning: previous declaration of `suboptarg' mmapr.c: In function `main': mmapr.c:139: warning: implicit declaration of function `strtoull' rm -f mmapr gcc -o mmapr -O2 -ansi -Dasm=__asm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -L../../../../../exports/lib mmapr.o mmapr.o: Undefined symbol `_strtoull' referenced from text segment collect2: ld returned 1 exit status *** Error code 1 Stop in /usr/src/XF4/xc/programs/Xserver/hw/xfree86/etc (line 1223 of Makefile). *** Error code 1 I must admit to being rather surprised that *BSD doesn't have strtoull() yet (but allows long long). I was really hoping to avoid ugly #if's in this code. Oh well, such is life. This'll be fixed shortly. I also note *BSD's libc is just as noisy as glibc ;-) Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 on Solaris Sun Blade 100?
On Wed, 25 Sep 2002, Andrew P. Lentvorski wrote: Has anyone managed to get XFree86 to work on a Sun Blade 100/150/1000/2000 running Solaris? It doesn't necessarily need to work with a Sun graphics card; I would happily go get even a reasonably expensive ATI or nVidia card (which would *still* be much cheaper than anything from Sun). Work on this started after 4.2. You'll need to pick up the CVS HEAD source (see http://xfree86.org/cvs) and read README.Solaris before building it. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]ulong warning fixes
some recent warning fixes break cygwin compiling. e.g. in lib/Xmu/StrToCurs.c:172 a printf(%lu, sizeof(...)) was changed to printf(%lu, (ulong)sizeof(...)) and in lib/Xmu/WidgetNode.c But ulong is not defined on cygwin. What is the correct fix for this. Change the printf type to %u (which might break on 64 bit architectures) or using (unsigned long) or defining ulong for cygwin where it's needed? you must define a format string that matches your machine's size_t. try something like this: #if arch1 #define SIZE_T_FORMAT %lu #elif arch2 #define SIZE_T_FORMAT %u #else #error... #endif ... and then end up with the task of maintaining what arch1 arch2 are. Are you volunteering yourself, your children and your grandchildren for this task? Mine have better things to do. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Cannot build cvs HEAD -- No rule to make target `xf86noBus.o'
On Tue, 17 Sep 2002, Miles Lane wrote: Any idea how I can fix this? make[5]: *** No rule to make target `xf86noBus.o', needed by `libxf86.a'. Stop.make[5]: Leaving directory `/usr/src/xc/programs/Xserver/hw/xfree86/common' The HEAD branch is currently unstable, and likely will be so for the next few days. Bear with us. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]No display on ATI 3D Rage IIC AGP or ATI 3d RAGE II+215GTB
On Thu, 5 Sep 2002, Peter Mastren wrote: I have installed Mandrake 8.2 (XFree86 4.2) on two different computers with these two display adapters with the same result. Everything appears to be working okay, the display is just blanked. I can login (blind of course) and do work, I just can't see what I'm do0ing. Interchanging the adapters between the two boxes does not help (one is AGP and one is PCI). Mandrake 8.1 (XFree86 4.1) works great on both of thes boxes. I've tried Mandrake 9.0beta3 with the same result, no display. Add 'Option NoCompositeSync' to the XF86Config device section. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]bug (?) in xf86pciBus.c
On Thu, 5 Sep 2002, Andy Isaacson wrote:
I have a Vaio r505te laptop, with the i810 chipset. I'm running FreeBSD
4.5. dmesg, XFree86.0.log, and XF86Config are at
http://web.hexapodia.org/~adi/sart/freebsd/
XFree86 (head of CVS as of September 3) was locking up after printing
Setting vga for screen 0.. I fixed it by adding this patch:
Index: hw/xfree86/common/xf86pciBus.c
===
RCS file: /cvsup/XFree86/xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c,v
retrieving revision 3.54
diff -u -r3.54 xf86pciBus.c
--- hw/xfree86/common/xf86pciBus.c2002/08/27 22:07:06 3.54
+++ hw/xfree86/common/xf86pciBus.c2002/09/05 05:37:24
@@ -665,7 +665,7 @@
ptr-current = NULL;
/* walk down */
-while (ptr-primary) { /* no enable for top bus */
+while (ptr-primary ptr != ptr-primary) { /* no enable for top bus */
if (ptr-primary-current != ptr) {
if (ptr-primary-current ptr-primary-current-disable_f)
ptr-primary-current-disable_f(ptr-primary-current);
Would anyone like me to run any tests, or try out test patches, to help
figure out what went wrong here? I don't understand how ptr ==
ptr-primary could possibly happen.
This is a known issue that I hope to address fairly shortly.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 Core Team member. ATI driver and X server internals.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]display problems on Sony Vaio PCG FX-705 notepad
On Fri, 30 Aug 2002, Vladimir Dergachev wrote: I recently installed Red Hat 7.3 on my Vaio notepad. Everything works except for the display, which has the following strange behaviour. If I do startx then I do not get a functioning display and I have tried lots of different settings in Xconfig - none work when I probe. HOWEVER, if I do startx with my laptop plugged into an external monitor AND THEN switch back to the laptop's display then I get a full, high-resolution picture and everything is fine from then on! (But I don't really want to walk round with a 19 CRT monitor). It looks like X fails to setup video mode correctly. When you use hotkey you actually have BIOS switching modes and it should do this task correctly. What does /var/log/XFree86.0.log say ? You might also want to try Option NoCompositeSync in your XF86Config's device section. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xfree86-4.2.0 problems on a sony vaio fxa59
On Tue, 20 Aug 2002, Mike Labriola wrote: i just compiled xfree86-4.2.0 on my brand new sony vaio fxa59 and i'm having some strange issues getting x to start correctly. here's the quick rundown. everything compiled and installed fine, and i'm using the attached XF86Config. as you can see from the attached XFree86.0.log file, there are no obvious error messages popping up on me... but instead of getting a nice x screen when i 'startx', i get a jagged lined (almost like chain links) and speckled grey screen with a little white box in the upper left corner (about 1 square). this is not the x is running but there's no wm screen... the specs sheet that came with the laptop says it has an ATI 3D RAGE MOBILITY-M1 and a 15.0 SXGA TFT screen that's supposed to run at 1400x1050. now i was completely stumped for a while, but i've actually made a positive discovery... oddly enough, if i plug a monitor into the vga out on the laptop and switch the display over to it (which works) and then switch it back to the lcd, the lcd works correctly. now, this is a good thing... but having to plug the thing into a monitor whenever i want to use x kinda defeats the entire purpose of a laptop... ;-) baby steps in the right direction, though. Try 'Option NoCompositeSync' in the device section. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Possible bug in xf86bigfont.c
On 20 Aug 2002, Christopher Keller wrote:
I've tracked down a situation which I believe to be a bug in XFree86.
I'm using RedHat 7.3, version 4.2.0-8.
The gist is a null pointer exception in line 667 668 of xf86bigfont.c.
pFont-info.props is null and it's being assigned without checking
whether it's null or not. I'm not sure if the simple answer is to wrap
the assign statements in a null pointer check or if it's more complex
than that.
I'm not an X developer, but I'd love to assist in the confirmation and
patch of this particular error, as it's causing me a huge headache right
now. I've been hanging out on #xfree86-devel, but I see no traffic.
(gdb) list xf86bigfont.c:667
662 xFontProp* prFP;
663 int i;
664 for (i = 0, pFP = pFont-info.props, prFP =
(xFontProp *) p;
665 i nfontprops;
666 i++, pFP++, prFP++) {
667 prFP-name = pFP-name;
668 prFP-value = pFP-value;
669 if (client-swapped) {
670 char tmp;
671 swapl(prFP-name, tmp);
(gdb) print *pFont
$5 = {refcnt = 142373721, info = {firstCol = 57392, lastCol = 16914,
firstRow = 0, lastRow = 0, defaultCh = 0, noOverlap = 0, terminalFont =
0, constantMetrics = 0, constantWidth = 0, inkInside = 0, inkMetrics =
0, allExist = 0, drawDirection = 0, cachable = 1, anamorphic = 0,
maxOverlap = 0, pad = 0, maxbounds = { leftSideBearing = 2,
rightSideBearing = 18, characterWidth = 18, ascent = 18, descent = 4,
attributes = 0}, minbounds = {leftSideBearing = -3, rightSideBearing =
1, characterWidth = 4, ascent = -2, descent = -11, attributes = 0},
ink_maxbounds = {leftSideBearing = 2, rightSideBearing = 18,
characterWidth = 18, ascent = 18, descent = 4, attributes = 0},
ink_minbounds = {leftSideBearing = -3, rightSideBearing = 1,
characterWidth = 4, ascent = -2, descent = -11, attributes = 0},
fontAscent = 16, fontDescent = 4, nprops = 27, props = 0x0, isStringProp
= 0x8a439a8 \001\001\001\001\001\001}, bit = 0 '\0', byte = 0 '\0',
glyph = 4 '\004', scan = 1 '\001', format = 512, get_glyphs = 0x8121ee8
_fs_get_glyphs, get_metrics = 0x8122418 _fs_get_metrics, unload_font
= 0x8122726 _fs_unload_font, unload_glyphs = 0, fpe = 0x873f2a0,
svrPrivate = 0x0, fontPrivate = 0x87d32b0, fpePrivate = 0x87d32c0,
maxPrivate = 1, devPrivates = 0x8a43724}
(gdb) quit
Humm. Perhaps a better question to ask is why nprops is non-zero when
props is NULL. With that in mind, I've gone through the source to ensure
both are kept in sync. In the process, I tripped over what looks like a
memory leak in the PCF code. The resulting patch is attached. Please try
it and report back whether or not it fixes the problem (or creates new
ones).
Thanks.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 Core Team member. ATI driver and X server internals.
font.diff.gz
Description: Binary data
Re: [Xpert]sunffb on Solaris
On Thu, 1 Aug 2002, Matt Behrens wrote: Anyone know how to get the sunffb driver working on Solaris (9 in my case)? My card is UPA, in an Ultra 10. On 4.2.99.1, XFree86 -configure finds all my PCI cards (I have two PGX32 cards and the onboard video) but never finds sunffb. Adding a device section for sunffb results in nothing. I installed the aperture driver; that was needed for PCI to work anyway. You might want to try the fbdev driver. Keep the following in mind though, as quoted from Domain.note: - The SBUS drivers (sunbw2, suncg14, suncg3, suncg6, sunffb, sunleo and suntcx), the common layer's SBUS code and the fbdev driver have all only been compile tested. There are likely to be Linux'isms within them that remain to be dealt with. It would be great if you could help make some of all of this code portable to Solaris SPARC. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]sunffb on Solaris
On Tue, 20 Aug 2002, Joshua Symons wrote: Anyone know how to get the sunffb driver working on Solaris (9 in my case)? My card is UPA, in an Ultra 10. On 4.2.99.1, XFree86 -configure finds all my PCI cards (I have two PGX32 cards and the onboard video) but never finds sunffb. Adding a device section for sunffb results in nothing. I installed the aperture driver; that was needed for PCI to work anyway. You might want to try the fbdev driver. Keep the following in mind though, as quoted from Domain.note: - The SBUS drivers (sunbw2, suncg14, suncg3, suncg6, sunffb, sunleo and suntcx), the common layer's SBUS code and the fbdev driver have all only been compile tested. There are likely to be Linux'isms within them that remain to be dealt with. It would be great if you could help make some or all of this code portable to Solaris SPARC. Are there any plans for xfree86 to support the raptor graphics cards for solaris or sparc linux? I don't know. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: CVS Update: xc (branch: trunk)
On Sun, 18 Aug 2002, Branden Robinson wrote: CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 02/08/08 01:18:01 Log message: multiple people have sent this fix in, committing it now. Stops tdfx dri driver segfaulting Modified files: xc/lib/GL/mesa/src/drv/tdfx/: tdfx_context.c Revision ChangesPath 1.9 +2 -2 xc/lib/GL/mesa/src/drv/tdfx/tdfx_context.c This patch appears to cause parse errors. To get it to compile again I had to change line 551 to: *((void **)(tmesa-Glide.PTR)) = dlsym(libHandle, NAME); \ instead of *((void **)tmesa-Glide.PTR = dlsym(libHandle, NAME); \ Your checked-out copy of tdfx_context.c is out of sync, as your suggestion above is what was actually committed. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Super Micro MB and XF86 problem
On 30 Jul 2002, Michel Dänzer wrote: OK here are the log files and our XF86config-4 file. the BusID in the XF86config-4 file is correct according to /proc/pci or lspci. If we do not specify the BusID the Xserver finds the wrong card (the AGP card) and runs X on it. The atimisc driver can't detect the chip for some reason. I hope Marc will be able to help. It is because the system BIOS hasn't assigned an I/O base address to the adapter, presumably because it's not primary. Workaround (for now): use pcitweak to set the I/O base before starting X. Or swap the motherboard. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Option nomtrr
On Wed, 24 Jul 2002, Mike A. Harris wrote: A user has suggested that Option nomtrr has solved a problem for him, and would like me to make this option default for his card in the Cards database. I don't see how MTRR behaviour could be adapter-specific. It seems more likely that this user's problem has more to do with his motherboard; more precisely, his particular CPU/chipset combo. I looked through the documentation briefly, and also greped the source tree. I see the option in the sources, but not in the documentation. Just wondering if I'm not looking in the right spot, or if it's just missing from the docs? It's just missing. If it is just missing, let me know and I'll update the XF86Config manpage, and send in a patch. Please do. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI driver kills the monitor - it goes off - withinseconds.
On Fri, 12 Jul 2002, Voluspa wrote: Problem, short version: _XFree86 Version 4.2.0_ SiS 6326 (PCI 4 meg mem) + Facit IntelliScan = OK ATI 3D Rage LT Pro + Facit IntelliScan = Dead monitor ATI 3D Rage LT Pro + Dell UltraScan = OK Solution, shorter: Add 'Option NoCompositeSync' to your device section for the LT Pro. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A few questions regarding the XFree86-DGA extension
On Wed, 26 Jun 2002, Adam Luchjenbroers wrote: 2) If I'm running a DGA application and it stops working, is there any way for me to safely get back out to X or to the shell? Ctrl-Alt-Backspace causes a crash which looks to be the result of DGA not giving control back to X when X tries to quit. Oh, ok, how would I go about trying to fix it? It seems its not restoring control to the X-Server. Video: ATi Mach64 2MB Motherboard: DataExpert TX531 RAM: 128MB PC100 CPU: AMD K6-2 233MHz I have not been able to duplicate this problem. Killing the DGA app causes a return to X. Killing the X server causes a return to text mode. Both as expected. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A few questions regarding the XFree86-DGA extension
On Wed, 10 Jul 2002, Marc Aurele La France wrote: 2) If I'm running a DGA application and it stops working, is there any way for me to safely get back out to X or to the shell? Ctrl-Alt-Backspace causes a crash which looks to be the result of DGA not giving control back to X when X tries to quit. Oh, ok, how would I go about trying to fix it? It seems its not restoring control to the X-Server. Video: ATi Mach64 2MB Motherboard: DataExpert TX531 RAM: 128MB PC100 CPU: AMD K6-2 233MHz I have not been able to duplicate this problem. Killing the DGA app causes a return to X. Killing the X server causes a return to text mode. Both as expected. A bit more on this. If your DGA app looks at keyboard input, then it must implement its own exit sequence. That's because DGA steals keyboard input before the server has a chance to recognise Alt+Ctrl+Backspace. In particular, this means that if the app dives into an infinite loop, for example, the only way, other than rebooting, to return to X (or text mode for that matter) is to kill the app behind the server's back. Yet another reason to get rid of DGA for 5.0. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Rage II blitting problems
On Sat, 6 Jul 2002, Henk de Leeuw wrote: On 9 Apr 2002, Marc Aurele La France wrote: On 9 Apr 2002, Kherry Zamore wrote: I have an ATI Rage II+DVD (Mach64, Rage128 chipset) and am using XFree86 4.1.0 on FreeBSD. I'm stuck with a slightly annoying problem. Artifacts are left on the screen after moving around some windows. I tried disabling a few options and changing resolutions/color depths, but that didn't solve the problem. Another thing I should mention is when I go to console, characters tend to disappear and reappear on the screen when it scrolls. I'm not exactly sure if this is a hardware or software problem since XF86 3.3.6 didn't have any problems when I used it. If anyone has any suggestions, it would be greatly appreciated. Let's narrow this down a bit. See if the artifacts still appear with Option NoAccel. I did not see any follow-up on these posts, and I'm having the same problems. To me, it seems that it is caused when screen content is blitted from display memory to display memory. It appears most pronouncedly when I'm moving a window horizontally. Also, in a Konsole, I notice that pixels of characters are randomly absent. I think that part of video memory is used as a font cache, so this could be indicative of hardware blitting problems also. I tried the Option NoAccel, and problems disappeared. This also seems to point in the direction of hardware blitting trouble. Any more tests I can do? Yes, replace that Option NoAccel with one or more of the following (starting with the most likely culprit(s)) Option XaaNoScreenToScreenCopy Option XaaNoScanlineCPUToScreenColorExpandFill Option XaaNoPixmapCache Option XaaNoOffscreenPixmaps Option XaaNoMono8x8PatternFillRect Option XaaNoSolidFillRect Let me know which mininal set of the above cure all artifacts. BTW, what architecture is this? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RE VGA-Out
On 23 Jun 2002, Michel Dänzer wrote: On Fri, 2002-06-21 at 20:59, Zhicong Liang wrote: Thanks it works, but one more question. Where can I get the document for these Option setting for XConfigure?? They should be documented in the driver manpage, unfortunately the radeon driver doesn't have one yet. (Help would be appreciated there, hint, hint) The config file generated by XFree86 -configure (usually /root/XF86Config.new) should also contain a list of all driver supported options, but the ati driver used to always put the options for the atimisc driver there, don't know if this has been fixed in the meantime. That one was fixed shortly after 4.1, IRC. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]multihead, No matching Device section for instance (BusIDPCI:0:10:0) found
@ 0xbd00/24, BIOS @ 0xc000/24 (--) PCI: (33:16:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ 0xc000/24 (--) PCI: (33:17:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ 0xc000/24 (--) PCI: (33:18:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ 0xc000/24 (--) PCI: (33:19:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ 0xc000/24 (--) PCI: (33:20:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ 0xc000/24 (--) PCI: (33:21:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ 0xc000/24 +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SWcursor with ATI Rage XL
On Tue, 28 May 2002, Brian McGrew wrote: Running XFree86 4.2.0 with RedHat 7.3 on a Dell 1400SC. This machine has an ATI Rage XL card which X uses the Mach64 server for. I need to turn on the copy of SWcursor (or sw_cursor, whichever one is correct). I've looked Option parsing ignores case, underscores, spaces and tab characters. through the docs and can't seem to manage to get this option to turn on. I've placed an 'Option' line in the XF86Config file with no luck. How do I force this option on? The reason being, is that the hw_cursor option option (default?) is eating 1k off the top of my video ram that I need. Please help. My personal preference is to specify such options in the appropriate Device section. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]BlankStart, etc... in Modelines
On Thu, 16 May 2002, Mark Vojkovich wrote: Didn't we allow for blanking parameters (start, width) in Modelines? I can't find documentation on the format anyplace. No, we never have. Even in 3.*, we usually (but not always) set the blanking interval to be the same as the space between [HV]Display and [HV]Total. In the ND, that's even more the case, as the common layer (and vgaHW) tries harder to eliminate overscans. The intent at the time was to implement some kind of overscan option in vgaHW, but that never got done (it wouldn't deal with non-VGA CRTC's anyway). I know the CrtcVBlankStart, etc... get passed to the drivers. I'm just not sure how they get explicitly set. They are set in xf86SetModeCrtc() in common/xf86Mode.c although the limit checks there are specific to a VGA CRTC. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][CVS] make install: compile fails at lib/fontconfig/src/fccharset.c
On Wed, 15 May 2002 [EMAIL PROTECTED] wrote: at a compile failure in lib/fontconfig/src/fccharset.c. -I-I../../../exports/include/freetype2 -I.. -I../../.. ^^ For some reason, that Makefile contains FREETYPE2INCDIR=$(TOP_X_INCLUDES)/freetype2 I've just committed a fix to change this to FREETYPE2INCDIR=$(BUILDINCDIR) in X11.tmpl. There was also another occurrence of the same problem in the setting of FONTCONFIGINCDIR. FREETYPE2INCLUDES = -I$(FREETYPE2INCDIR) where FREETYPE2INCDIR itself is expanded to -Isomething Dropping the -I on the FREETYPE2INCLUDES solved the problem for me - the same breakage exists also in xc/lib/Xft . Did we both do the cvs update incorrectly, or is this broken in cvs ? b). But not any more. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][CVS] make install: compile fails at lib/fontconfig/src/fccharset.c
On Wed, 15 May 2002, Marc Aurele La France wrote: On Wed, 15 May 2002 [EMAIL PROTECTED] wrote: at a compile failure in lib/fontconfig/src/fccharset.c. -I-I../../../exports/include/freetype2 -I.. -I../../.. ^^ For some reason, that Makefile contains FREETYPE2INCDIR=$(TOP_X_INCLUDES)/freetype2 I've just committed a fix to change this to FREETYPE2INCDIR=$(BUILDINCDIR) Ooops, I should have said FREETYPE2INCDIR=$(BUILDINCDIR)/freetype2 Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Unresolved symbols in Xserver startup
On Tue, 14 May 2002, David Dawes wrote: On Mon, May 13, 2002 at 03:46:49PM -0600, Marc Aurele La France wrote: On Mon, 13 May 2002, Mike A. Harris wrote: New versions of the gcc compiler have an optimization called string merging which is enabled by default. The XFree86 module loader chokes on the ELF sections that this optimization adds to the ELF objects. To work around this XFree86 module loader limitation, you need to pass -fno-merge-constants to the linker when modules are being built. This can be done from host.def with: ModuleLdFlags -fno-merge-constants That should have a #define in front of it. This was automatically detected in later 4.1.0 CVS, and also in 4.2.0 CVS however it looks like someone removed the automatic checks in head CVS. No, it wasn't removed. But, it's possible that It looks like the relevant code in got isolated recently. I'll commit a fix. The committed fix makes sense and does explain the reported behaviour. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Unresolved symbols in Xserver startup
On Mon, 13 May 2002, Mike A. Harris wrote: New versions of the gcc compiler have an optimization called string merging which is enabled by default. The XFree86 module loader chokes on the ELF sections that this optimization adds to the ELF objects. To work around this XFree86 module loader limitation, you need to pass -fno-merge-constants to the linker when modules are being built. This can be done from host.def with: ModuleLdFlags -fno-merge-constants That should have a #define in front of it. This was automatically detected in later 4.1.0 CVS, and also in 4.2.0 CVS however it looks like someone removed the automatic checks in head CVS. No, it wasn't removed. But, it's possible that gcc -fmerge-constants -xc /dev/null -S -o /dev/null ... no longer generates a zero return (i.e. is no longer a valid test to determine whether or not the compiler has merge-constants support). Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Fatalities in the vidmode extension
On Wed, 1 May 2002, Mark Vojkovich wrote: With this patch the application no longer runs. It appears that it calls XF86VidModeLockModeSwitch to prevent users from switching modes while in the game, but the application itself switches modes via the vidMode extension while mode switches are locked. Before your patch, this was allowed. After your patch it is not because the xf86SwitchMode function checks the zoomLocked flag. I can get the app to run again by saving zoomLocked in VidModeSwitchMode before calling xf86SwitchMode and then restoring it afterwards. I don't know if that's the solution you'd like to see though. OK. I'll move the zoomLocked check out of xf86SwitchMode() and back into xf86ZoomViewport(). Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]manual page error (XmbDrawString)
On 28 Apr 2002, Robert Vojta wrote: there is an error in manual page XmbDrawString ... XmbDrawString(3X11) -- Release 6.6 -- X Version 11 -- XLIB FUNCTIONS [...] void Xuf8DrawString(display, d, font_set, gc, x, y, string, - void Xutf8DrawString(... If there is anyone who can fix this, please do this. Done. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH] imake broken on FreeBSD
On Mon, 29 Apr 2002, Tony Finch wrote:
The current version of XFree86 from the CVS repo doesn't compile on
FreeBSD-STABLE because of a couple of errors in imake -- imake doesn't
even compile and it doesn't deal with gcc properly.
--- imake.c 2002/04/14 22:01:27 3.52
+++ imake.c 2002/04/29 15:39:01
@@ -1131,7 +1131,7 @@
FILE *objprog = NULL;
int iself = 0;
char buf[10];
- char cmd[MAX_PATH];
+ char cmd[PATH_MAX];
mib[0] = CTL_KERN;
mib[1] = KERN_OSRELDATE;
@@ -1254,7 +1254,7 @@
{
struct stat sb;
static char* gcc_path[] = {
-# if defined(linux) || defined(__NetBSD__) || defined(__OpenBSD__) || defined
(__GNU__)
+# if defined(linux) || defined(__FreeBSD__) || defined(__NetBSD__) ||
defined(__OpenBSD__) || defined (__GNU__)
/usr/bin/cc, /* for Linux PostIncDir */
# endif
/usr/local/bin/gcc,
I've just committed this. Thanks.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 Core Team member. ATI driver and X server internals.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH] correct spacing in xterm's Imakefile
On Mon, 29 Apr 2002, Tony Finch wrote: --- Imakefile 2002/04/04 14:05:59 3.42 +++ Imakefile 2002/04/29 17:28:56 @@ -123,8 +123,8 @@ MAINOBJ = main.o #endif #ifdef TraceXTerm - TRACESRC = trace.c - TRACEOBJ = trace.o +TRACESRC = trace.c +TRACEOBJ = trace.o #endif SRCS1 = button.c charproc.c charsets.c cursor.c \ data.c doublechr.c fontutils.c input.c \ I've committed this one too. Thanks again. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]debian
On Tue, 30 Apr 2002, Branden Robinson wrote: On Mon, Apr 29, 2002 at 07:28:12PM +0200, Martin Voelkle wrote: I don't really know where to post this, so I post it here. I'm just a debian and xfree86 user and I'm asking if you could do something to help Branden Robinson with his ports. See http://lists.debian.org/debian-devel/2002/debian-devel-200204/msg01343.html for more info with his problems. I hope this will help xfree86 to get released quicker under Debian. Thanks for the cheerleading, but I think the XFree86 project has enough to do. :) You know, it's quite encouraging when people prefer to lambbaste a work in progress, rather than contribute to it. Keep up the good work, Branden. I mean it. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Fatalities in the vidmode extension
On Fri, 26 Apr 2002, Mark Vojkovich wrote: It looks to me like maybe the vid mode extension allows switching modes while switched away? I had a bug report that VT switching while playing a certain game (Sid Meier's Alpha Centauri) that uses the vidmode extension causes the server to SIGV. This is with the nv driver. Should VidModeSwitchMode be doing all this when switched away? Certainly not. There're other things here too, like VidModeSwitchMode() using its own copy of xf86ZoomViewport(), consequently ignoring DGA and such. I'll take care of this. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Memory allocation code/kernel interfaces? (ResoundingSilence!)
On Thu, 25 Apr 2002, Jeffery S. Norman wrote: Having heard nothing on my specific problem (I have the Compaq Armada M700/ATI Mobility that seems to break under XFree 4.2.0 and 4.1.x but only after docking in the docking station) ... I am going to try to fix this myself. Option NoCompositeSync ought to help in this regard. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Fatalities in the vidmode extension
On Tue, 30 Apr 2002, Marc Aurele La France wrote: On Fri, 26 Apr 2002, Mark Vojkovich wrote: It looks to me like maybe the vid mode extension allows switching modes while switched away? I had a bug report that VT switching while playing a certain game (Sid Meier's Alpha Centauri) that uses the vidmode extension causes the server to SIGV. This is with the nv driver. Should VidModeSwitchMode be doing all this when switched away? Certainly not. There're other things here too, like VidModeSwitchMode() using its own copy of xf86ZoomViewport(), consequently ignoring DGA and such. I'll take care of this. Try the attached. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. Mode.diff.gz Description: Binary data
Re: [Xpert]a problem about Xfree86 4.2.0
On Tue, 23 Apr 2002, Jing Xu wrote: Yeah!!! It works. Of course, it does. Sheesh. I have another question about Xfree86. This is also the reason why I try Xfree86 4.2. I have two graphic cards in my box, one is ATI Rage XL(PCI) and one is ATI Radeon VE QY(AGP). I would like to control the AGP card from a kernel module we have written (which displays on a projector) and I would like to let X control the PCI card (which displays on a flat panel monitor). While in console mode the kernel module correctly displays images using the AGP card. We used the vesafb driver to configure the AGP card (primary card according to BIOS) to the desired mode of 1024x768. The problem begins when we use startx. The PCI controlled monitor starts X correctly but our kernel module no longer has control of our AGP card (no image displays on projector). We received the reply from Michael Danzer who suggested us that Look at xc/programs/Xserver/hw/xfree86/common/xf86Bus.c, it might be enough to hardcode doFramebufferMode to TRUE. In 4.2.0 doFramebufferMode has been set to TRUE. However, when I run my program in X, still no image displays on projector(AGP card). But an interesting thing is that the color is changed in X Window. In our program we change the color palette, but this is supposed to work on AGP(primary card) not PCI. It seems that PCI card has been set to the primary card by X. How can I prevent X from disabling the AGP card? Right now, you can't. That might be something to address in a future version, but I can't say for sure. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Rage XL XV support
On Thu, 18 Apr 2002, Alexey Dokuchaev wrote: I was looking at the mailing list archive and there were several questions from about a year ago wondering whether the ATI Rage XL based cards would be getting XV support. The answer was that it was in the works. I could find nothing else about it. Does anyone know when/whether these cards have or will have XV support added for them any time soon? Check out http://gatos.sf.net/. They have drivers for XFree86 that support the hardware scaling/colorspace conversion engine on the Mach64 chipsets. AFAIK, their drivers are mature and stable enough to be included in core XFree86 CVS tree, aren't they? In fact, lots of people expected them in 4.2.0. What are official plans with respect to this subject? Will we see Xft2 and gatos' drivers in 4.2.1? ;-) GATOS functionality will be merged in by next release. Cool! Will Xft2 follow too? I'd really like to see Mozilla AA my fonts ;-) That's something I'm not involved in, but I believe this work has already been committed to the XFree86 CVS repository. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xc/doc gcc: specs is a directory
On Sun, 14 Apr 2002, F. Heitkamp wrote: I get a strange error when trying to compile XFree86 from CVS. The makefile in xc/doc does not get made. When I manually try xmkmf in the xc/doc directory gcc complains about specs being a directory. Renaming specs to xspecs and changing the Imakefile appropriately works. I am using gcc-2.95.4-ds8. Known issue. Upgrade gcc. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xterm problem
On Sat, 13 Apr 2002, Dr Andrew C Aitchison wrote:
I'm having problems with the patch
xc/programs/xterm/main.c,v 3.148 2002/04/10 16:20:09 tsi
OK, I'll back it out.
Thanks for changing it, but:
main.c: In function `spawn':
main.c:2958: parse error before `int'
main.c:2964: `pty_name' undeclared (first use in this function)
main.c:2964: (Each undeclared identifier is reported only once
main.c:2964: for each function it appears in.)
main.c:2965: `ptyfd' undeclared (first use in this function)
I think the problem is that line 2948
(void)setsid();
is not an initialisation.
I thought about changing
#ifdef USE_ISPTS_FLAG
if (IsPts) {/* SYSV386 supports both, which did we open? */
#endif
to
#ifdef USE_ISPTS_FLAG
if (IsPts) /* SYSV386 supports both, which did we open? */
#endif
{
(and the matching } else { and }), but I decided that this is too
much of a twisty maze of paths and would somtimes change the scope of
variables.
Maybe it is better to stick with code which has been well tested,
even though compliers warn about it ?
OK, I've reverted this to what it was before.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 Core Team member. ATI driver and X server internals.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xterm problem
On Fri, 12 Apr 2002, Dr Andrew C Aitchison wrote: I'm having problems with the patch xc/programs/xterm/main.c,v 3.148 2002/04/10 16:20:09 tsi @@ -2942,7 +2942,9 @@ */ TRACE_CHILD #if defined(_POSIX_SOURCE) || defined(SVR4) || defined(__convex__) || defined(SCO325) || defined(__QNX__) - int pgrp = setsid();/* variable may not be used... */ +#if !defined(USE_SYSV_PGRP) + int pgrp = setsid(); +#endif #else int pgrp = getpid(); #endif I'm using RedHat 6.2, and I find that with this patch something is up with the controlling terminal (/dev/tty ?). % yppasswd Changing NIS account information for werdna on emu. [1]+ Stopped (tty output)yppasswd % ssh emu [4]+ Stopped (tty input) ssh emu - I then find the message asking me for emu's password appears on the console instead of in the xterm window. The change log says this change was to remove Warnings; I guess the setsid call is needed (at least on Linux), even if the result is never used. OK, I'll back it out. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]missing code in VESA DPMS
On Tue, 9 Apr 2002, Randolph Bentson wrote: I'm trying to get DPMS screen blanking to work on a ViewSonic ViewPad 1000, but I'm concerned about the code which has appeared in 4.2.0. In 4.1.0, DPMSSet indirectly called VESADisplayPowerManagementSet, which called vgaHWDPMSSet, which called stdwriteCrtc via a pointer, which contained the lines outb(hwp-IOBase + hwp-PIOOffset + VGA_CRTC_INDEX_OFFSET, index); outb(hwp-IOBase + hwp-PIOOffset + VGA_CRTC_DATA_OFFSET, value); In 4.2.0, DPMSSet indirectly called VESADisplayPowerManagementSet, which employs the WriteCrtc macro which expands to outb(VGA_CRTC_INDEX_OFFSET, index);\ outb(VGA_CRTC_DATA_OFFSET, value) That seemed clearly bogus, and fortunatly for my peace of mind, in yesterday's 4.2.0 CVS fetch, DPMSSet indirectly called VESADisplayPowerManagementSet, which employs the WriteCrtc macro which now expands to outb(pVesa-ioBase + VGA_CRTC_INDEX_OFFSET, index);\ outb(pVesa-ioBase + VGA_CRTC_DATA_OFFSET, value) From inspection, this seems better, but isn't there still the need for some additional offset? Or was the presence of hwp-PIOOffset a red herring? These are missing VGA_IOBASE_COLOR. I've just committed a fix for this. Thanks for reporting the problem. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Rage problem
On 9 Apr 2002, Kherry Zamore wrote: I have an ATI Rage II+DVD (Mach64, Rage128 chipset) and am using XFree86 4.1.0 on FreeBSD. I'm stuck with a slightly annoying problem. Artifacts are left on the screen after moving around some windows. I tried disabling a few options and changing resolutions/color depths, but that didn't solve the problem. Another thing I should mention is when I go to console, characters tend to disappear and reappear on the screen when it scrolls. I'm not exactly sure if this is a hardware or software problem since XF86 3.3.6 didn't have any problems when I used it. If anyone has any suggestions, it would be greatly appreciated. Let's narrow this down a bit. See if the artifacts still appear with Option NoAccel. BTW, the Rage II+DVD is a Mach64, not a Rage128. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Minimizing VC switch time
On Mon, 8 Apr 2002, Mark Vojkovich wrote: How can I switch between the X servers without them changing the video mode? I'm willing to hack code to make this work if someone can point me in the right direction. You can't. When the server X server enters the VT it is going to reinitialize the mode. When it leaves, it is going to restore the mode it initially saved. Those are the rules. The particular instance of the server doesn't know that another server is just going to reset it to the same mode. If you start the second X server when the first is the active video (and they use the same video mode) then switching one way will only switch between identical modes. Not ideal, but might be a slight improvement on starting both servers from a standard VT, which probably means switching to a different mode, and back again every time you switch between servers. Which mode does the second server restore? It didn't save a text mode if it didn't start in one. If you quit the first server and then quit the second you restore a graphics mode. Also, how does the first server know that it's not supposed restore the text mode on this particular VT switch. Note that if it switches to another VT, where there isn't an X server, it's expected to restore a text mode in that case. This is not a problem that can be solved correctly. No, drivers will always see the original text mode. Regardless of where the second server is started from, it will activate its own VC. This'll cause the first server to switch out, restoring the text mode it saw on entry, in time for the second server's drivers to save it again. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon Xv troubles with XFree86 drivers
On Fri, 29 Mar 2002, Vladimir Dergachev wrote: While you are at it, you might wish to change the default colo[u]rkey from 0. Black is a common enough text colour; with Keith's patch highlighted text shows the video layer beneath :-) I stole a few lines from the R128 driver and stuck them into the radeon driver. The video key is now configurable (option videokey 42) and has a non-zero default value (30). New diff is at: http://keithp.com/~keithp/download/radeon_xv-2002-03-29.diff I note that the config file uses the phrase videokey instead of colo[u]rkey. That conveniently avoids the spelling ambiguity... I just want to point out that GATOS code already supports this. As for 8bbp - I will insert the code to disable hardware Xv support in this case and print a meaningful message. Just my 2 cents' worth. I don't think this is a good idea. It's not necessary to do so in the Mach64 and R128 cases. As for Radeon colorkeying the reason we use RGB values is because Radeon no longer supports keying on the value of graphics pixel, rather it allows you to specify ranges of alpha and R, G, B so all graphics pixels that fall within them are replaced by video. The comparison is done _after_ Radeon has converted framebuffer value into internal 32bpp format. Oh? An alpha channel for 8bpp? If so, where does it come from? The LUT is only 3 * 768 long. Perhaps a specific alpha value can be used as the key. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon Xv troubles with XFree86 drivers
On Fri, 29 Mar 2002, Marc Aurele La France wrote: While you are at it, you might wish to change the default colo[u]rkey from 0. Black is a common enough text colour; with Keith's patch highlighted text shows the video layer beneath :-) I stole a few lines from the R128 driver and stuck them into the radeon driver. The video key is now configurable (option videokey 42) and has a non-zero default value (30). New diff is at: http://keithp.com/~keithp/download/radeon_xv-2002-03-29.diff I note that the config file uses the phrase videokey instead of colo[u]rkey. That conveniently avoids the spelling ambiguity... I just want to point out that GATOS code already supports this. As for 8bbp - I will insert the code to disable hardware Xv support in this case and print a meaningful message. Just my 2 cents' worth. I don't think this is a good idea. It's not necessary to do so in the Mach64 and R128 cases. As for Radeon colorkeying the reason we use RGB values is because Radeon no longer supports keying on the value of graphics pixel, rather it allows you to specify ranges of alpha and R, G, B so all graphics pixels that fall within them are replaced by video. The comparison is done _after_ Radeon has converted framebuffer value into internal 32bpp format. Oh? An alpha channel for 8bpp? If so, where does it come from? The LUT is only 3 * 768 long. Perhaps a specific alpha value can be used as the key. Ooops. Synapse cross. I meant 3 * 256. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building libXpm.a on XF86 4.2
On Fri, 22 Mar 2002, Dave Horsfall wrote: Is there any way to get libXpm.a to be built? I have some old GNU configure scripts that look only for .a files, so it doesn't find libXpm. I can't find any documentation, and Imake is not my strong point... #define ForceNormalLib to YES in your host.def and re-make the World. This'll build static libs for all libraries, in addition to the shared libraries built by default. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH]: XftFreetype.h missing typedef struct onXftFontStruct
On Tue, 19 Mar 2002, Shawn Starr wrote:
After using a recent CVS snapshot GTK+'s pango failed to configure
properly with errors:
configure: WARNING: X11/Xft/XftFreetype.h: present but cannot be compiled.
configure: WARNING: X11/Xft/XftFreetype.h: check for missing prerequisite headers?
configure: WARNING: X11/Xft/XftFreetype.h: proceeding with the preprocessor's result
Error in config.log:
In file included from configure:16193:
/usr/X11R6/include/X11/Xft/XftFreetype.h:77: parse error before '*' token
/usr/X11R6/include/X11/Xft/XftFreetype.h:78: warning: type defaults to `int' in
declaration of `XftFreeTypeOpen'
Solution: Add typedef struct, error gone.
Patch below:
--- XftFreetype.h.old Tue Mar 19 23:36:27 2002
+++ XftFreetype.h Tue Mar 19 23:28:10 2002
@@ -57,6 +57,8 @@ struct _XftFontStruct {
_XFUNCPROTOBEGIN
+typedef struct _XftFontStruct XftFontStruct;
+
/* xftdir.c */
Bool
XftDirScan (XftFontSet *set, const char *dir, Bool force);
As of just over a month ago, this change is no longer needed.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 Core Team member. ATI driver and X server internals.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree 4.2.0 on Chips CT 69000, noaccel
On Mon, 11 Mar 2002, Marc Aurele La France wrote: On Mon, 11 Mar 2002, David Bateman wrote: Does the Egbert's email imply that - Option noaccel - will be required? So far, using just Options XaaNoScreenToScreenCopy has worked reasonably for most cases. Given Egbert reply this means that the CT's need NoAccel in 4.2.0 due to broken Silken Mouse Support. From his reply I also presume that the problem has since been fixed in the CVS. No, it hasn't. Not yet. Soon though. It is now. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]4.2.0: build problem on ppc
On Mon, 18 Mar 2002, Guido Guenther wrote: when trying to build a static X-Server(#define DoLoadableServer NO) on Linux/PPC the final link of XFree86 fails with cfb24/libcfb24.a(cfbglblt8.o): In function `cfbPolyGlyphBlt8Clipped': cfbglblt8.o(.text+0x910): undefined reference to `cfb8ComputeClipMasks32' cfbglblt8.o(.text+0x910): relocation truncated to fit: R_PPC_REL24 cfb8ComputeClipMasks32 cfb32/libcfb32.a(cfbglblt8.o): In function `cfbPolyGlyphBlt8Clipped': cfbglblt8.o(.text+0x690): undefined reference to `cfb8ComputeClipMasks32' cfbglblt8.o(.text+0x690): relocation truncated to fit: R_PPC_REL24 cfb8ComputeClipMasks32 cfb8ComputeClipMasks32 is defined in libcfb.a: nm libcfb.a | grep cfb8ComputeClipMasks32 U cfb8ComputeClipMasks32 01e4 T cfb8ComputeClipMasks32 The link fails cause libcfb24 references the symbol but is linked in after libcfb8: gcc -o XFree86 -O2 ... cfb/libcfb.a cfb16/libcfb16.a cfb24/libcfb24.a ... I could work around this by adding cfb/libcfb.a after libcfb24.a. Like: --- xc/programs/Xserver/Makefile.orig Mon Mar 18 17:40:43 2002 +++ xc/programs/Xserver/Makefile Mon Mar 18 17:41:27 2002 @@ -909,7 +909,7 @@ MFB = mfb/libmfb.a FB = fb/libfb.a -CFB = cfb/libcfb.a cfb16/libcfb16.a cfb24/libcfb24.acfb32/libcfb32.a +CFB = cfb16/libcfb16.a cfb24/libcfb24.a cfb32/libcfb32.a cfb/libcfb.a CFB8 = cfb/libcfb.a CFB4 = cfb/libcfb.a cfb4/libcfb4.a Someone with more clues about Imakefiles should be able to fix this easily. I believe this to in fact be the correct fix, although I'm a bit surprised this doesn't show up on ix86. I further noticed that lib/GLw will not build without having X11 headers installed in /u/i/X11. At least IntrinsicP.h is missing. I'm building with #define BuildServersOnly YES. Is this dependency on system headers intended? Do we need the GLw stuff at all for server only builds? The dependency on system headers is generated by BuildServersOnly. Normally, IntrinsicP.h would be found in xc/exports/include. I see two oversights here. One is GLw's dependency on Xt. There other is that it's probably not necessary to build GLw when BuildServersOnly is YES. Please explicitly set BuildGLwLibrary to NO and see what happens. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]4.2.0: build problem on ppc
On Mon, 18 Mar 2002, Guido Guenther wrote: when trying to build a static X-Server(#define DoLoadableServer NO) on Linux/PPC the final link of XFree86 fails with +++ xc/programs/Xserver/Makefile Mon Mar 18 17:41:27 2002 @@ -909,7 +909,7 @@ MFB = mfb/libmfb.a FB = fb/libfb.a -CFB = cfb/libcfb.a cfb16/libcfb16.a cfb24/libcfb24.acfb32/libcfb32.a +CFB = cfb16/libcfb16.a cfb24/libcfb24.a cfb32/libcfb32.a cfb/libcfb.a CFB8 = cfb/libcfb.a CFB4 = cfb/libcfb.a cfb4/libcfb4.a Someone with more clues about Imakefiles should be able to fix this easily. I believe this to in fact be the correct fix, although I'm a bit surprised this doesn't show up on ix86. Maybe nobody built static servers recently, or are these autobuild for testing? No. I ALWAYS build both static and loader servers, on ix86 and SPARC, and this hasn't shown up before. There might be something amiss that ppc is tickling, but in any case, cfb should be linked after any of the other cfb*'s. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][CRASH] CVS 4.2.99.1 ( 2 week old) - GL Crashing server
On 14 Mar 2002, Shawn Starr wrote: XFree86 Version 4.2.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: xx January 2002 While playing with some of the Xscreensaver 4.01 screensavers using Mesa/GL the server experienced random crashes on a ATI 3D Xpression+ 2MB card. Details? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree 4.2.0 on Chips CT 69000, noaccel
On Mon, 11 Mar 2002, David Bateman wrote: Does the Egbert's email imply that - Option noaccel - will be required? Sofar, using just Options XaaNoScreenToScreenCopy has worked reasonably for most cases. Given Egbert reply this means that the CT's need NoAccel in 4.2.0 due to broken Silken Mouse Support. From his reply I also presume that the problem has since been fixed in the CVS. No, it hasn't. Not yet. Soon though. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A rough sketch of what the screen looks like
On Tue, 5 Mar 2002, Peter Surda wrote: Try Option composite_sync off in the device section. Hehe I actually had the same problem today :-). It seems like composite_sync defaults to on in 4.2.0 and off in 4.1.0 for mach64. ... and reverted back to off in 4.2.0. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]junk following cursor in X (ATI Rage II)
On Sun, 24 Feb 2002, Andrew Daviel wrote: Some time ago when I did a system upgrade I tried Gnome (or KDE) and saw this problem, couldn't be bothered to understand it and just kept running fvwm2. However, I now see it in fvwm2 (and twm) with a just-compiled copy of xdoom, so maybe it's an X problem rather than a Gnome problem. Most everything else I ever run is OK (Netscape, xv, staroffice, xterm,xfig, etc. etc. etc. - I have only seen this problem in I think 2 apps) The problem: In an X app (xdoom, or gnuterm/kterm etc.) there is junk following the cursor around. Under the cursor (invisible in xdoom) is is an imaginary square about 63 pixels on edge which is OK. (The cursor at its upper left vertex). Under this is a translucent blue square superimposed on the screen Under this is another square composed of translucent vertical bars in about 3 colours. The pattern repeats to the bottom of the screen. (Actually they are not all exactly square) My system: RedHat 6.0 upgraded to RedHat 6.2, probably with some apps and libraries left around from old a.out days too. Graphics device ID: ATI RAGE II XFree86-3.3.6-20 XFree86-Mach64-3.3.6-20 DefaultColorDepth 16 Anyone see this before ? Yep. This was fixed in the 4.* series some time ago. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Changes to int10 code?
On Fri, 22 Feb 2002, Mark Vojkovich wrote: Interesting, I have seen someone else report a very similar problem with dual Radeons. I've seen that with my dual radeons. I got past the Screen not configured issue, and then my Xserver started locking up. Much the same as Mark's. I'd assumed it was the fact that nobody had tested the radeon driver with two boards yet, and wrote it off. (and I was thinking of returning the boards and getting NV boards because my feeble hacking wasn't getting them working ;) I've just synced up with top of tree and this seems to work OK. Perhaps things were in an unstable condition the last time I synced up. Now it reports: (II) NV(1): Initializing int10 (II) Truncating PCI BIOS Length to 43008 where previously it reported. (II) NV(1): Initializing int10 (EE) NV(1): Cannot read V_BIOS I don't remember there being a message about truncation last time it was working, but at least it works again. Sounds like the Domain-branch glitch I fixed on Wednesday. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Mach64 GX with a 15kHz Arcade Monitor
On Thu, 7 Feb 2002, FITZSIMMONS THOMAS wrote: I'm trying to get X to output to a Hantarex MTC 9000 arcade monitor. With the attached configuration, I'm getting a horizontal band covering about 1/5th of the screen's height that displays perfectly, and that seems to follow the vertical location that the mouse cursor would be at, except that the cursor doesn't display. Above this band, the screen is blackish, with thin vertical lines, and below the band, it displays alternating light and dark vertical stripes. When I specify the SWCursor option to the ati driver, the entire screen displays only the alternating light and dark vertical stripes. Any ideas what is wrong? You say 15kHz, yet your XF86Config clamps hsync to 15.125-16.125, and the mode you're using syncs at 15.6kHz. That might be a difference that's significant enough. Try an hsync range of 14.75 - 16.25, and a dot clock of 9.6 MHz. Sorry, I should have been more specific. The monitor is actually rated for 15.625+/-0.5kHz horizontal, 45-65Hz vertical, -3dB at 12MHz. I tried your suggestion, but got the same results. Any other suggestions? Thanks for your reply, Let's try to isolate the problem. Try Chipset ativga in the device section. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Mach64 GX with a 15kHz Arcade Monitor
On Wed, 6 Feb 2002, FITZSIMMONS THOMAS wrote: I'm trying to get X to output to a Hantarex MTC 9000 arcade monitor. With the attached configuration, I'm getting a horizontal band covering about 1/5th of the screen's height that displays perfectly, and that seems to follow the vertical location that the mouse cursor would be at, except that the cursor doesn't display. Above this band, the screen is blackish, with thin vertical lines, and below the band, it displays alternating light and dark vertical stripes. When I specify the SWCursor option to the ati driver, the entire screen displays only the alternating light and dark vertical stripes. Any ideas what is wrong? You say 15kHz, yet your XF86Config clamps hsync to 15.125-16.125, and the mode you're using syncs at 15.6kHz. That might be a difference that's significant enough. Try an hsync range of 14.75 - 16.25, and a dot clock of 9.6 MHz. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XFree 4.1-6 crashes on Notebook with ati Grafik card
On Tue, 5 Feb 2002, Wilfried Goesgens wrote: Please excuse me, if I'm wrong here with my problems here and tell me were to go. [EMAIL PROTECTED] The ati driver maintainer reads that list. well, I didn't receive any response from that. Now I've Isolated the program that causes the Crash: It's wmcpu : (gdb) run -ac -nolisten tcp :1.0 on other Term: export DISPLAY=:0.0 wmcpu ... some console-switching... (II) ATI(0): Shutting down Xvideo subsystems Program received signal SIGUSR1, User defined signal 1. 0x4012b774 in __umoddi3 () from /lib/libc.so.6 (gdb) cont Continuing. (==) ATI(0): Write-combining range (0xfd00,0x80) (II) ATI(0): Reinitializing Xvideo subsystems (==) Wacom tablet model : KT-0405-R00 V1.3-6 Wacom unable to read first byte of request '~R' answer after 3 tries WACOM: unable to reread resolution. Using previous values. (==) Wacom IV tablet maximum X=6150 maximum Y=4550 X resolution=1270 Y re 5 to 10 minutes letting wmcpu show my cpu-load and: ... Program received signal SIGSEGV, Segmentation fault. 0x0858d687 in ?? () (gdb) bt #0 0x0858d687 in ?? () #1 0x08593902 in ?? () #2 0x08593ee8 in ?? () #3 0x085942a9 in ?? () #4 0x08594370 in ?? () #5 0x084913ce in ?? () #6 0x080af6ae in ?? () #7 0x080ad5b6 in ?? () #8 0x080bd70b in ?? () #9 0x4007a65f in vfprintf () from /lib/libc.so.6 (gdb) This backtrace might be misleading, but at this point in gdb do call LoaderPrintSymbol(address) ... for every address gdb reports as ?? above. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XFree 4.1-6 crashes on Notebook with ati Grafik card
On Wed, 6 Feb 2002, Branden Robinson wrote: Please excuse me, if I'm wrong here with my problems here and tell me were to go. [EMAIL PROTECTED] The ati driver maintainer reads that list. well, I didn't receive any response from that. Now I've Isolated the program that causes the Crash: It's wmcpu : wmcpu does some sort of nasty stuff and reliably crashes X on all my machines. And it is not an ATI driver thing - the tdfx driver had problems with it too. Avoid like the plague. Yup. I've gotten reports of this from mga and nv driver users as well. Whoever tracks this one down should get a prize. I see. Well, I'm into Slackware myself, so privately send me an un-Debian-ised tarball of wmcpu source, and I'll see what I can dig up. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
