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 , 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: > 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 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]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]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 > + > +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]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]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]Save/restore mode issue
On Fri, 22 Nov 2002, Frank Giessler wrote: > I need the opinion from Xpert. I'm running version 4.2.99.2 (CVS from > Nov.14) under OS/2 on a notebook with a Radeon Mobility 7500. When > switching from X to my OS/2 desktop or after terminating X, the > desktop is in most cases (but not always) corrupt in such a way that > only the upper left quadrant is visible and the screen is panning when > moving the mouse out of this region. The desktop driver does have this > zoom feature but I cannot reset to the original resolution (so the > driver seems to think that this is the original resolution). > Is it possible that XFree saves/restores the original state (mode, > registers, whatsoever) incompletely? I don't have the specs for Radeon > (are they available somewhere?) so I can't tell from the source. > Or is it more likely the desktop driver's fault? Even so, fixing this > by modifying something in X is easier because I have the sources. I've > asked the driver's manufacturer and the answer was 'XFree is leaving > the display in a confused state' :-( > Any idea what to do? Thanks, I remember this being discussed several times in the distant past, but it's been a while. The upshot is that, on OS/2, you should start the X server while the OS/2 desktop is in a VGA mode. Apparently, OS/2 provides an automatable way of doing that, but I don't know what that would be. If you start the server from a non-VGA mode, the XFree86 driver is required to restore the timings it sees on entry, but not video memory contents. Your report would imply that's not happening correctly in the radeon 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. ___ 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: > >>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]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]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 . 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: > > 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 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: > > 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 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]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]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]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]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
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=164486&repeatmerged=yes > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164489&repeatmerged=yes > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164491&repeatmerged=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]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
[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 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. > I'm game, but everytime I've pulled cvs, I couldn't get it to compile. > Now I'm no guru, but I do C for a living, but for the life of me I > couldn't figure out the various issues. I'll give it another spin though. > When you say let it hang, I'm not sure I understand. What I believe is > happening is a panic of some sort, which would seem to indicate to me > that there is no further log activity. I've checked the xfree log under > /var/log and it appears to me that the logging has stopped and there's > no real useful information. > Are you suggesting that if I'd wait long enough, X would give up and I'd > have access to the box again? If so, I'd like to kick myself, as all > along, I've been assuming this was a 'no return' problem that was only > resoveable via power down. > That's based on the fact that keyboard leds don't function and I can't > access the box via network from machines that have normal connectivity > to this same box. 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. 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]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]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, 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 Q&D 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: [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 Q&D 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, 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: 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]XFree86 on Solaris Sun Blade 100?
On Mon, 30 Sep 2002, Andrew P. Lentvorski wrote: > After deleting the i810 and i830 drivers (these *really* should be > autodetected as not available when being built under Solaris) from my > setup, XFree86 actually completely builds and installs. I'll assume you've read my cursory comment about this in xfree86.cf (around line 487). But that's not the whole story. While I agree the i810 driver is not particularly relevent to this architecture, I do feel it is important that this driver at least compile cleanly (which it does for me). This, not so much as a measure of its portability, but as an aid in eventually exorcising all architecture and OS concerns from the driver API/ABI. 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? > However, it doesn't detect any PCI interface at all. What obvious thing > did I miss? > 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: Mon Sep 30 22:42:02 2002 > (EE) No OS PCI support available > List of video drivers: > atimisc > r128 > radeon > sunffb > sunleo > suncg6 > suncg3 > suncg14 > suntcx > sunbw2 > glint > mga > tdfx > ati > vesa > vga > fbdev > apm > ark > chips > cirrus > i128 > i740 > imstt > neomagic > newport > nv > rendition > s3virge > savage > siliconmotion > tga > trident > vmware > dummy > No devices to configure. Configuration failed. What does `prtconf -Ppv` say? For that matter, anything interesting in /var/log/XFree86.0.log? Also, I'm curious as to which compiler you used. 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 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]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]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]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. > Would this have any effect with an LCD panel ? He is having problems when > external monitor is not connected. I've seen reports to that effect, yes. 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]Problem compiling kde-base3.0beta2 for lfs
On Fri, 30 Aug 2002, John Gay wrote: > I'm copying both lists because this problem appears to be related to X. > I'm building a Linux From Scratch box and I have XFree86 from cvs working. At > the moment I have xfce running as a window manager but I wanted to try KDE3. > I've got the sources for KDE3.0beta2 from a DVD, so this is what I'm trying > to build. qt and kde-libs built fine and I've made sure I've got all the > misc. libs that I need, but when I built kde-base, the build failed in > kcontrol/kfontinst/kfoninst. Here is the relevant fail info, I think: > Making all in kfontinst > make[4]: Entering directory > `/usr/src/kde/kdebase-3.0beta2/kcontrol/kfontinst/kfontinst' > /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. > -I../../.. -I/usr/include/freetype2 -I/usr/kde/include -I/usr/qt/include > -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -DNDEBUG -DNO_DEBUG > -O2 -O3 -march=i586 -mcpu=i586 -fno-exceptions -fno-check-new > -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -c -o Config.lo `test > -f Config.cpp || echo './'`Config.cpp > g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I/usr/include/freetype2 > -I/usr/kde/include -I/usr/qt/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT > -D_REENTRANT -DNDEBUG -DNO_DEBUG -O2 -O3 -march=i586 -mcpu=i586 > -fno-exceptions -fno-check-new -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT > -DQT_NO_ASCII_CAST -c Config.cpp -fPIC -DPIC -o .libs/Config.o > In file included from Config.cpp:45: > xftint.h:280: declaration of C function `int XftDirScan(XftFontSet *, const > char *)' conflicts with > /usr/X11R6/include/X11/Xft/Xft.h:127: previous declaration `FcBool > XftDirScan(FcFontSet *, const char *, int)' here > xftint.h:392: `XftValueList' was not declared in this scope > xftint.h:392: `v1orig' was not declared in this scope > xftint.h:393: `XftValueList' was not declared in this scope > xftint.h:393: `v2orig' was not declared in this scope > xftint.h:394: parse error before `)' > make[4]: *** [Config.lo] Error 1 > make[4]: Leaving directory > `/usr/src/kde/kdebase-3.0beta2/kcontrol/kfontinst/kfontinst' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/usr/src/kde/kdebase-3.0beta2/kcontrol/kfontinst' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/src/kde/kdebase-3.0beta2/kcontrol' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/src/kde/kdebase-3.0beta2' > make: *** [all] Error 2 > bash-2.05a# > So it seems to be complaining that > function `int XftDirScan(XftFontSet *, const char *)' > in xftint.h conflicts with > declaration `FcBool XftDirScan(FcFontSet *, const char *, int)' > in /usr/X11R6/include/X11/Xft/Xft.h:127: > So you can see why I might think this is related to X as well as KDE. I'm not > much of a programmer and since I've only got a dial-up connection with > pay-per-minute phone rates I don't really want to fetch the latest stable > version of KDE. > Can someone please help me get around this? It seems to be only a small > problem that is stopping me from finishing the build of kde-base. Your xftint.h is out of date. It also seems that KDE provides its own, which doesn't strike me as a very good idea. 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]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]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]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]pci_retry zipping sound
On Tue, 20 Aug 2002, Colin Law wrote: > I currently have and ATI Rage XL using the 'ati' driver of XFree86 4.1 > under debian. Everything looks fine, however, when i drag a window, or > move a scroll bar i get a 'zipping' or 'chopping' effect of the sound. > From what i have read within ALSA documentation, this may be caused by > the graphics card making excessive use of the pci bus. There is also > mention of a pci_retry option within XF86Config-4 that may be used to > help this situation. This pci_retry option does not seem to be supported > by the 'ati' driver. > 1) Is there a similar option for use with the 'ati' driver? No, because such an option isn't needed. > 2) if not, Is there another work-around? There is no workaround (in 4.1). However, there is a bug in the 4.2 and previous drivers that causes the adapter to disable bus timeouts. This bug has since been corrected. My suggestion to you is to compile from sources available through http://xfree86.org/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]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 Thu, 1 Aug 2002, Daniel Sheltraw wrote: > Thank you very much for solving the problem that we (Jing, Vikram > and I) were having with XF86 on the Super Micro MB. It had us > stumped for a week! Do you think Super Micro deserves an email > telling them of possible problems with this board? I doubt you'd get anywhere. Besides, I still would need to change the driver to deal with this situation a little better. 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 Wed, 31 Jul 2002 [EMAIL PROTECTED] wrote: > We are working with Daniel on Super Micro MB problem. As you suggested, > we ran the utility - pcitweak in order to set I/O base address for PCI > card. We performed it in the following manner: > 1. We acquired the information about I/O base address by command >#scanpci -v >following line is information snippet copied from the output of >scanpci -v command. > - >pci bus 0x0 cardnum 0x14 function 0x: vendor 0x1002 device 0x4752 >ATI Mach64 GR >CardVendor 0x1002 card 0x8008 >STATUS0x0290 COMMAND 0x0080 >CLASS 0x03 0x00 0x00 REVISION 0x27 >APBASE0x3000 addr 0x3000 >BLOCKIO 0xff01 addr 0xff00 >REGBASE 0x3100 addr 0x3100 >BASEROM 0xfffe addr 0xfffe not-decode-enabled >MAX_LAT 0x00 MIN_GNT 0x08 INT_PIN 0x01 INT_LINE 0x10 >SPARSEIO 0x2ecBlock IO enabledDisable 0x46E8 > - > 2. We used pcitweak to modify I/O base address by >#pcitweak -w 00:14:0 -h 0x14 0xff01 >#pcitweak -w 00:14:0 -h 0x16 0x > 3. After doing this, we tried running Xwindows but alas, faced the same > problem as we had before. No. On ix86 (among others), I/O bases must be < 64K. Instead do pcitweak -w 0:14:0 0x14 0xnn01 ... where "nn" should be chosen to not conflict with any other I/O range in the system. Furthermore, "nn" must not be "00", nor "ff". This'll reserve I/O ports nn00 to nnff inclusive. 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]4.x and WD90c24
On Sun, 21 Jul 2002, Colin Andrews wrote: > I posted to the newbie list about my troubles about a month ago and > didn't get much help. > I had xfree86 3.3.6 working *ok* on my little compaq elite lte 4/75cx > under Debian Potato. I could get 640x480 at 8 bits per pixel. There is no support for this chipset in 4.* as no one has step up to port the 3.* driver for it. Therefore your best bet is to get using 3.3.6. 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, 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]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]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
0W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ >0xc000/24 > > (--) PCI: (33:11:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ >0xc000/24 > > (--) PCI: (33:12:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ >0xc000/24 > > (--) PCI: (33:13:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ >0xc000/24 > > (--) PCI: (33:14:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 0xbd00/24, BIOS @ >0xc000/24 > > (--) PCI: (33:15:0) Tseng Labs ET4000W32P revC rev 0, Mem @ 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, 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][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 -I > 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]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]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]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]Build problems on FreeBSD 4.5
On Fri, 26 Apr 2002, Mike Pumford wrote: > Fixing this gives: > cd ./config/imake && make -f Makefile.proto all > LD_LIBRARY_PATH=../../exports/lib cc -O2 -ansi -pedantic -Dasm=__asm >GccWarningOptions -I../../include -I../../exports/include/X11 -I../.. >-I../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO >-DCPP_PROGRAM="\"/usr/bin/cpp\""-c imake.c > cc: GccWarningOptions: No such file or directory > *** Error code 1 > I've no idea how to fix this one properly but I've work round it by removing > GccWarningOptions from config/cf/FreeBSD.cf for now. Any suggestions as for a > proper fix? I suspect NetBSD has a similar problem. Have a look at how OpenBSD does this, and submit a corresponding patch for FreeBSD and NetBSD to either myself, Matthieu, or the fixes list. 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]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][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][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]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]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]a problem about Xfree86 4.2.0
On Tue, 23 Apr 2002, Jing Xu wrote: > I updated my X Server from 4.1 to 4.2.0 (built from > source code). The same XF86Config-4 file works in 4.1 > but not in 4.2. The problem is when I execute > 'startx', the screen says, > OUT OF RANGE > H: 99.2 KHZ > V: 123.6 HZ > My graphic card is ATI Rage XL(PCI) and the following > is XF86config-4 file. [...] > Section "Device" > Identifier "ATI Rage XL" > Driver "ati" > BoardName "Unknown" > Option "nodri" > EndSection Add 'Option "NoCompositeSync"' to this 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 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]Fw: XFree86 4.2.0 and an Ultra 5 w/ ATi
On Mon, 1 Apr 2002, surefire wrote: > I have been pulling my hair out trying to get 4.2.0 working on my > system. I have tried with Kernels 2.4.14 and kernels 2.4.18, to no > avail. > I have a hunch that the error i am coming across is architecture > specific. If this is the case please let me know. > The error i am getting is as follows Could not mmap PCI memory. If you > need more details feel free to ask. You should install the XFree86 binaries provided by your distribution. Building from XFree86 4.2.0 sources will not work, as changes for this were introduced into the XFree86 CVS repository after 4.2.0's release. If you have UltraSPARC-specific problems with distribution-provided binaries, contact the distribution maintainers. 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]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]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
