[XFree86] XFree86 4.3 question
Would anyone know if XFree86-4.3.0-62.EL had problems with XFillRectangle and newly drawn bitmaps in RHEL 3? I have an application that draws rectangles into bitmaps (depth 1 pixmaps). These bitmaps are set as the stipple bitmap within corresponding full color GCs for a full color pixmap. The intent is to use XFillRectangle to stamp each bitmap into the pixmap with the display being the rectangle. This works fine in RHEL 4 with xorg-X11-6.8.2-1.EL.13.36 and not so fine with RHEL 3 with XFree86-4.3.0-62.EL. On RHEL 3, only some of the bitmaps appear in the final display. I figure the bitmaps are good, because I substitute XCopyPlane for XFillRectangle and the missing bitmaps will appear. I'd use XCopyPlane but it is way to slow for the amount of drawing I'm doing (literally billions of rectangles). Since it works in the one case, I'm hoping I'm just missing something simple like an initialization. But if there's a bug in release, I'll have to look at other options. (Also, are there any good resources on X programming other than the O'Reilly books?) Thanks, Willi ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] xfree86 4.3 config for 1600x1200 support ?
I'm having difficulty getting 1600x1200 support with my Xfree86 4.3 config. Currently, it's using the VESA driver for display. System details: FreeBSD 4.10 on x86 arch Xfree86 4.3 ATI Radeon 9600 SE AGP card Planar px212M LCD monitor (1600x1200 is supported fine on Windows) Does the vesa driver support 1600x1200 in the Xfree86 4.3 version? The probe lines in the xfree86.log indicate 1600x1200 is a future mode. Perhaps this requires upgrading to 4.4? Or perhaps I should be using the radeon driver instead of the automatically configured vesa driver? Any help or recommendations would be appreciated. Thank you, Ted _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Thomas Dickey wrote: This thread actually started on [EMAIL PROTECTED] The problem is that gcc's broken define conflicts with our driver API. ISO C99: 7.16 Boolean type and values stdbool.h 1 The header stdbool.h defines four macros. 2 The macro bool expands to _Bool. Which define is broken in gcc exactly? OK. So broken is a little harsh. Not the first time... recap: one of his header files has a struct with a field named 'bool'. ncurses' curses.h is including stdbool.h (long story). stdbool.h's bool definition interferes with his header file. Well, not his header file, exactly, but I'll let that go. The simplest thing to do is to rename that field in xf86cfg/loader.h. As for the field in common/xf86Opt.h, that header is only used by server code, and server code shouldn't ever use curses. That leaves some future #include stdbool.h in server code, but we can cross that bridge when/if we get there. In the meantime, the API issue is avoided. 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 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86-4.3 Problem
Yoshikazu Nakamura wrote: Dear Sir, I could not start XFree86-4.3 with FreeBSD 5.2-RELEASE although I did't have any problem when I used XFree86-4.2 with 5.1-RELEAEE. I attached logfile output, and I am happy if you could send me any suggestion. Remove load dri from the Modules section of your config file. DRI is not supported in 4.3, and was never under *BSD. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
Redirected from xfree86@ to devel@, where this belongs. On Thu, 19 Feb 2004, Kelledin wrote: On Thursday 19 February 2004 03:42 pm, Marc Aurele La France wrote: Secondly (and perhaps more to the point), is that stdbool.h is a very recent (glibc-wise) invention (read: bleeding edge). So, in your shoes, I'd first talk to the glibc people about the implications of an stdbool.h in the first place. Not that bleeding edge. stdbool.h is part of gcc and has been around since stock 2.95.3 (possibly earlier as well). 2.95.3 is...downright ancient, at least in software terms. Ooops, right. I was only looking at /usr/include. Anyway, some versions of ncurses #undef bool just after #include'ing stdbool.h. Thomas Dickey, ncurses developer, is on this list, so if he's reading this, he probably has some suggestions. 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 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Marc Aurele La France wrote: Redirected from xfree86@ to devel@, where this belongs. On Thu, 19 Feb 2004, Kelledin wrote: On Thursday 19 February 2004 03:42 pm, Marc Aurele La France wrote: Secondly (and perhaps more to the point), is that stdbool.h is a very recent (glibc-wise) invention (read: bleeding edge). So, in your shoes, I'd first talk to the glibc people about the implications of an stdbool.h in the first place. Not that bleeding edge. stdbool.h is part of gcc and has been around since stock 2.95.3 (possibly earlier as well). 2.95.3 is...downright ancient, at least in software terms. Ooops, right. I was only looking at /usr/include. Anyway, some versions of ncurses #undef bool just after #include'ing stdbool.h. Thomas Dickey, ncurses developer, is on this list, so if he's reading this, he probably has some suggestions. I overlooked the beginning of the thread. stdbool.h is a C99 file, which is fine. But defining bool in that file is a gcc-ism. Both gcc's stdbool.h and ncurses.h are trying to solve the same problem (though ncurses.h has a more valid reason - bool is a documented part of X/Open curses, gcc is doing it solely as an extension). In current ncurses (5.4), I don't have an undef for bool following stdbool.h -- there was an undef in the version from last spring. That was to work around (no surprise) a conflict on BeOS with inconsistent definitions of bool. If gcc hadn't added that definition to stdbool.h the #undef wouldn't have been needed. I don't see the original comment on the mail archive - but have the impression that he's trying to use some definition that relies on the bogus bool from stdbool.h - So I guess the best recommendation is that he should update to the regular release version of ncurses rather than one of the development versions. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
Thomas Dickey said: I don't see the original comment on the mail archive - but have the impression that he's trying to use some definition that relies on the bogus bool from stdbool.h - So I guess the best recommendation is that he should update to the regular release version of ncurses rather than one of the development versions. Well, just to bring everyone up to speed...the problem we face is that XFree86 defines a union type called ValueUnion, and names one of the union fields bool. Obviously this wasn't really a great idea. It bites us now because ncurses 5.4 includes stdbool.h, which defines the bool type, which confuses the hell out of gcc when it hits the ValueUnion typedef. :( The simple answer would be to change the ValueUnion field name to xbool or the like. The problem is, this naming snafu has become part of a publicly documented API for XFree86 driver development. IMO modifying ncurses would only be a temporary fix, good only until the next system header decides it needs stdbool.h. BTW--regular version of ncurses? Is 5.4 a stable release or not? FWIW I pulled it off ftp.gnu.org...if it's unstable, it ought to be taken down from there and put on alpha.gnu.org. -- Kelledin If a server crashes in a server farm and no one pings it, does it still cost four figures to fix? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
Marc Aurele La France said: On Fri, 20 Feb 2004, Thomas Dickey wrote: On Fri, 20 Feb 2004, Marc Aurele La France wrote: Anyway, some versions of ncurses #undef bool just after #include'ing stdbool.h. Thomas Dickey, ncurses developer, is on this list, so if he's reading this, he probably has some suggestions. I overlooked the beginning of the thread. stdbool.h is a C99 file, which is fine. But defining bool in that file is a gcc-ism. Both gcc's stdbool.h and ncurses.h are trying to solve the same problem (though ncurses.h has a more valid reason - bool is a documented part of X/Open curses, gcc is doing it solely as an extension). In current ncurses (5.4), I don't have an undef for bool following stdbool.h -- there was an undef in the version from last spring. That was to work around (no surprise) a conflict on BeOS with inconsistent definitions of bool. If gcc hadn't added that definition to stdbool.h the #undef wouldn't have been needed. I don't see the original comment on the mail archive - but have the impression that he's trying to use some definition that relies on the bogus bool from stdbool.h - So I guess the best recommendation is that he should update to the regular release version of ncurses rather than one of the development versions. Thanks for responding. This thread actually started on [EMAIL PROTECTED] The problem is that gcc's broken define conflicts with our driver API. Well, that's rather debatable. From what I can gather on Google, C99 7.16 actually allows for stdbool.h and the relevant macros for bool, true, and false. Of course, it breaks ANSI C89/C90, but as the gcc devs point out, ANSI C89/C90 code shouldn't be including stdbool.h in the first place. Unfortunately, I don't have a copy of C99 (and can't afford to purchase it atm), so I'm in no position to argue the finer points. Furthermore, if we applied this fix, then curses.h would break whenever it got run through gcc -ansi. Perhaps the best solution here is for curses.h to simply not have anything to do with stdbool.h? (and, of course, put the #undef bool at the end, as it was in 5.3) -- Kelledin If a server crashes in a server farm and no one pings it, does it still cost four figures to fix? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Mike A. Harris wrote: On Fri, 20 Feb 2004, Marc Aurele La France wrote: This thread actually started on [EMAIL PROTECTED] The problem is that gcc's broken define conflicts with our driver API. ISO C99: 7.16 Boolean type and values stdbool.h 1 The header stdbool.h defines four macros. 2 The macro bool expands to _Bool. Which define is broken in gcc exactly? recap: one of his header files has a struct with a field named 'bool'. ncurses' curses.h is including stdbool.h (long story). stdbool.h's bool definition interferes with his header file. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] XFree86-4.3 Problem
Dear Sir, I could not start XFree86-4.3 with FreeBSD 5.2-RELEASE although I did't have any problem when I used XFree86-4.2 with 5.1-RELEAEE. I attached logfile output, and I am happy if you could send me any suggestion. Thank you. -- Yoshikazu Nakamura : [EMAIL PROTECTED] XFree86.0.log Description: Binary data
Re: [XFree86] XFree86-4.3 Problem
That looks like an SiS driver bug. I don't know much about the SiS driver myself. Perhaps you could try one of the pre-4.4 XFree86 snapshots? Also, I think you may be able to use the sis driver from 4.2 with your 4.3 server. That is often possible. The server will load drivers older than it (but not newer). Mark. On Fri, 20 Feb 2004, Yoshikazu Nakamura wrote: Dear Sir, I could not start XFree86-4.3 with FreeBSD 5.2-RELEASE although I did't have any problem when I used XFree86-4.2 with 5.1-RELEAEE. I attached logfile output, and I am happy if you could send me any suggestion. Thank you. -- Yoshikazu Nakamura : [EMAIL PROTECTED] ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Wed, 18 Feb 2004, Kelledin wrote: While compiling XFree86-4.3.0.1 recently, I got the following error message: In file included from text-mode.c:47: loader.h:78: warning: ISO C doesn't support unnamed structs/unions loader.h:78: unnamed fields of type other than struct or union are not allowed text-mode.c: In function `TextMode': text-mode.c:208: warning: string length `535' is greater than the length `509' ISO C89 compilers are required to support make[5]: *** [text-mode.o] Error 1 make[5]: Leaving directory `/usr/src/incept/BUILD/xc/programs/Xserver/hw/xfree86/xf86cfg' make[4]: *** [all] Error 2 make[4]: Leaving directory `/usr/src/incept/BUILD/xc/programs/Xserver/hw/xfree86' make[3]: *** [hw/xfree86] Error 2 make[3]: Leaving directory `/usr/src/incept/BUILD/xc/programs/Xserver' make[2]: *** [install] Error 2 make[2]: Leaving directory `/usr/src/incept/BUILD/xc/programs' make[1]: *** [install] Error 2 make[1]: Leaving directory `/usr/src/incept/BUILD/xc' make: *** [install] Error 2 I looked into it, and it's occurring because of the following line in the ValueUnion type: Boolbool; bool is a loaded name. It's a defined type in all C++ compilers, and it's also defined in plain old non-C++ gcc whenever something includes stdbool.h. In my case, I hit it for the first time yesterday because curses.h from ncurses 5.4 now includes the stdbool.h header. So far I see three possible solutions: 1) force ncurses to not include stdbool.h. This definitely isn't ideal, primarily because it won't stop the next package from including stdbool.h, and then we'll be dealing with this garbage all over again. 2) undefine the bool type before defining the ValueUnion type (see attached patch). This is hardly ideal, as several other source files in XFree86 depend on that type, and this could give us headaches down the road. Plus, I don't know how portable this hack is--it might not work on other toolchains besides linux+gcc+libc6. 3) rename the ValueUnion.bool field to something else, like xbool or boolval. This would be the perfect solution, except that ValueUnion.bool is part of a documented API for XFree86 driver modules, and it wouldn't be particularly nice to break the API. I would assume there would be ABI breakage as well, since I'm not sure exactly how unions get handled at link-time across different platforms. What I'd probably do is go with (2) for the current 4.3.0 branch, and implement (3) for 4.4.0 or some later release where a driver API break is marginally acceptable. Anything besides (3) should just be treated as a temporary stopgap measure, as otherwise we'd just be digging ourselves deeper into the same hole. First off, 2) doesn't work if stdbool.h is #included after the headers being modified here. Secondly (and perhaps more to the point), is that stdbool.h is a very recent (glibc-wise) invention (read: bleeding edge). So, in your shoes, I'd first talk to the glibc people about the implications of an stdbool.h in the first place. 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 developer and VP. ATI driver and X server internals. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Thursday 19 February 2004 03:42 pm, Marc Aurele La France wrote: First off, 2) doesn't work if stdbool.h is #included after the headers being modified here. True, it's a nasty hack. I should have foreseen this problem as well...but fortunately, the hack worked this time. I imagine I just got lucky. It may also work to #undef bool after the all headers are included as well, but before anything tries to reference ValueUnion.bool. The #undefs I put in there cover the typedef of ValueUnion already. Secondly (and perhaps more to the point), is that stdbool.h is a very recent (glibc-wise) invention (read: bleeding edge). So, in your shoes, I'd first talk to the glibc people about the implications of an stdbool.h in the first place. Not that bleeding edge. stdbool.h is part of gcc and has been around since stock 2.95.3 (possibly earlier as well). 2.95.3 is...downright ancient, at least in software terms. We might possibly have gcc skip the offending stdbool.h contents whenever __STRICT_ANSI__ is defined. I would consider that fairly proper myself, as this is exactly what gcc -ansi is supposed to address. I'll run off to the gcc devs and see if I can make the case there. If we decide to go that route, we'd also have to make sure the relevant parts of XFree86 compile with gcc -ansi. Then this problem might go away entirely, except for not-so-recent gcc compilers. -- Kelledin If a server crashes in a server farm and no one pings it, does it still cost four figures to fix? ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Thursday 19 February 2004 06:07 pm, Kelledin wrote: We might possibly have gcc skip the offending stdbool.h contents whenever __STRICT_ANSI__ is defined. I would consider that fairly proper myself, as this is exactly what gcc -ansi is supposed to address. I'll run off to the gcc devs and see if I can make the case there. If we decide to go that route, we'd also have to make sure the relevant parts of XFree86 compile with gcc -ansi. Then this problem might go away entirely, except for not-so-recent gcc compilers. Hmm. Well, that's not necessarily a good path either. I've met some resistance from the gcc devs, and now I'm beginning to realize that this might not solve our problems. You see, ncurses uses the bool type in their interface specs and has for a while now. Drastically changing ncurses is probably not an option. So it all comes back to this loaded symbol bool. Our troubles probably won't be over until we rename it (and put up with some temporary discontent from driver developers). -- Kelledin If a server crashes in a server farm and no one pings it, does it still cost four figures to fix? ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
While compiling XFree86-4.3.0.1 recently, I got the following
error message:
In file included from text-mode.c:47:
loader.h:78: warning: ISO C doesn't support unnamed
structs/unions loader.h:78: unnamed fields of type
other than struct or union are not allowed text-mode.c: In
function `TextMode':
text-mode.c:208: warning: string length `535' is greater than
the length `509' ISO C89 compilers are required to support
make[5]: *** [text-mode.o] Error 1
make[5]: Leaving directory
`/usr/src/incept/BUILD/xc/programs/Xserver/hw/xfree86/xf86cfg'
make[4]: *** [all] Error 2
make[4]: Leaving directory
`/usr/src/incept/BUILD/xc/programs/Xserver/hw/xfree86'
make[3]: *** [hw/xfree86] Error 2
make[3]: Leaving directory
`/usr/src/incept/BUILD/xc/programs/Xserver'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/usr/src/incept/BUILD/xc/programs'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/usr/src/incept/BUILD/xc'
make: *** [install] Error 2
I looked into it, and it's occurring because of the following
line in the ValueUnion type:
Boolbool;
bool is a loaded name. It's a defined type in all C++
compilers, and it's also defined in plain old non-C++ gcc
whenever something includes stdbool.h. In my case, I hit it
for the first time yesterday because curses.h from ncurses 5.4
now includes the stdbool.h header.
So far I see three possible solutions:
1) force ncurses to not include stdbool.h. This definitely
isn't ideal, primarily because it won't stop the next package
from including stdbool.h, and then we'll be dealing with this
garbage all over again.
2) undefine the bool type before defining the ValueUnion type
(see attached patch). This is hardly ideal, as several other
source files in XFree86 depend on that type, and this could give
us headaches down the road. Plus, I don't know how portable
this hack is--it might not work on other toolchains besides
linux+gcc+libc6.
3) rename the ValueUnion.bool field to something else, like xbool
or boolval. This would be the perfect solution, except that
ValueUnion.bool is part of a documented API for XFree86 driver
modules, and it wouldn't be particularly nice to break the API.
I would assume there would be ABI breakage as well, since I'm
not sure exactly how unions get handled at link-time across
different platforms.
What I'd probably do is go with (2) for the current 4.3.0 branch,
and implement (3) for 4.4.0 or some later release where a driver
API break is marginally acceptable. Anything besides (3) should
just be treated as a temporary stopgap measure, as otherwise
we'd just be digging ourselves deeper into the same hole.
--
Kelledin
If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?
Submitted By: Kelledin (kelledin at users dot sourceforge dot net)
Date: 2004-02-18
Initial Package Version: 4.3.0
Upstream Status: Reported to maintainers
Origin: Kelledin
Description: XFree86 4.3.x uses a loaded name (bool) for a union type field.
This causes nasty compile problems when other stuff (like
ncurses-5.4) includes the stdbool.h header. This patch is a
workaround for this issue.
diff -Naur xc/programs/Xserver/hw/xfree86/common/xf86Opt.h xc-bool/programs/Xserver/hw/xfree86/common/xf86Opt.h
--- xc/programs/Xserver/hw/xfree86/common/xf86Opt.h 2001-05-04 14:05:30.0 -0500
+++ xc-bool/programs/Xserver/hw/xfree86/common/xf86Opt.h 2004-02-18 14:27:07.0 -0600
@@ -5,6 +5,10 @@
#ifndef _XF86_OPT_H_
#define _XF86_OPT_H_
+#ifdef bool
+# undef bool
+#endif
+
typedef struct {
double freq;
int units;
diff -Naur xc/programs/Xserver/hw/xfree86/xf86cfg/loader.h xc-bool/programs/Xserver/hw/xfree86/xf86cfg/loader.h
--- xc/programs/Xserver/hw/xfree86/xf86cfg/loader.h 2001-07-09 18:45:24.0 -0500
+++ xc-bool/programs/Xserver/hw/xfree86/xf86cfg/loader.h 2004-02-18 14:26:51.0 -0600
@@ -66,6 +66,10 @@
#ifndef LOADER_PRIVATE
/* common/xf86Opt.h */
+#ifdef bool
+# undef bool
+#endif
+
typedef struct {
double freq;
int units;
[XFree86] XFree86 4.3 with Diamond Stealth card
Hi I am frustrated. I have tried everything to get XServer configured but I cannot seem to find the right configuration. Description of my system is: Processor is Pentium Pro S 200 MHz with 32MB memory OS is FreeBSD 4.9 with XFree86 4.3 (I purchased it in 4 CD set) Video Card is Diamond Multimedia Stealth 64 DRAM with 2 MB video Ram and S3 Trio 64 chip Other numbers on the chip inlcude(I have no idea what they mean) GACC2 86C764-P 9519 F32753 Here is my problem: When I try and do a post-install config of Xserver I do not see my Diamond card listed under the video cards section so I choose S3 or generic VGA. Then under the chipset section I choose my chipset which is actually S3 Trio 64 so I choose S3 Trio 32/64. Is my Diamond card supported or not? I get conflicting answers when I search on the web for answers so I am turning to you for HELP!! PLEASE!!
[XFree86] XFree86 4.3 and tdfx
Hello, I have a little problem : I'm currently using XFree4.3.0 and running slackware 9.1 I have a Voodoo 3 2000 Video card. So I'm using the tdfx driver... When I run xinit (or startx), i get the following message : --- TDFX(0) Unknown reason for exception TDFX(0) Cannot continue Then I get only 60 FPS with glxgears, although I used to get 1000 or so before... And glxinfo says Direct Rendering: Yes Below you can find my XFree86 log : i noticed a problem with a VESA BIOS but I don't know if it is the problem. The kernel-module tdfx is shown with lsmod. Excuse me for my bad english, And thanks a lot for your tips Marc. PS: After the XFree86 log is my XF86Config file. - XFree86 Version 4.3.0 Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.22 i686 [ELF] Build Date: 16 September 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. 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: Sat Dec 20 09:51:51 2003 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor Flatron 795FT (LG) (**) | |--Device Voodoo3 (generic) (**) |--Input Device Mouse1 (**) |--Input Device Keyboard1 (**) Option AutoRepeat 500 30 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc102 (**) XKB: model: pc102 (**) Option XkbLayout fr (**) XKB: layout: fr (==) Keyboard: CustomKeycode disabled (WW) `fonts.dir' not found (or not valid) in /usr/X11R6/lib/X11/fonts/100dpi/. Entry deleted from font path. (Run 'mkfontdir' on /usr/X11R6/lib/X11/fonts/100dpi/). (WW) `fonts.dir' not found (or not valid) in /usr/X11R6/lib/X11/fonts/Speedo/. Entry deleted from font path. (Run 'mkfontdir' on /usr/X11R6/lib/X11/fonts/Speedo/). (WW) `fonts.dir' not found (or not valid) in /usr/X11R6/lib/X11/fonts/Type1/. Entry deleted from font path. (Run 'mkfontdir' on /usr/X11R6/lib/X11/fonts/Type1/). (**) FontPath set to /usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/75dpi/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such device) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,7190 card , rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,7191 card , rev 03 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 8086,7110 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 8086,7111 card , rev 01 class 01,01,80 hdr 00 (II) PCI: 00:07:2: chip 8086,7112 card , rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 8086,7113 card , rev 02 class 06,80,00 hdr 00 (II) PCI: 00:10:0: chip 127a,2013 card 1436,2113 rev 01 class 07,80,00 hdr 00 (II) PCI: 00:12:0: chip 10ec,8139 card 1799,5000 rev 10 class 02,00,00 hdr 00 (II) PCI: 00:14:0: chip 1274,1371 card 1274,1371 rev 08 class 04,01,00 hdr 00 (II) PCI: 01:00:0: chip 121a,0005 card 121a,0034 rev 01 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0088
[XFree86] XFree86 4.3
Good day friends. I am Brazilian, my English is bad. I am using a translator. I am with a doubt. When installing XFree86 4,3 the Kde presented the message: Couldn't start Ksmserver. Check Your Installation. Linux Distribution: Conectiva 8 What it had? Thanks
[XFree86] XFree86 4.3 error
I have compile the XFree86 4.3 for my lubbock platform(XScale PXA250) by gcc 2.95.3+glibc 2.2.3+binutils 2.11.2. My kernel is 2.4.19-rmk7-pxa2, framebuffer is set to 16bpp 640*480. When I try to run the XFree86 server, I got the following Error: Fatal server error: xf86EnableIOPorts: Failed to set IOPL for I/O. My XF86Config is placed in the end of this mail, what should I do to correct this problem? Thanks for any help. Hongda Zhao 2003/7/31 Section Files RgbPath /usr/X11R6/lib/X11/rgb FontPath /usr/X11R6/lib/X11/fonts/local/ FontPath /usr/X11R6/lib/X11/fonts/misc/ FontPath /usr/X11R6/lib/X11/fonts/75dpi/:unscaled FontPath /usr/X11R6/lib/X11/fonts/100dpi/:unscaled FontPath /usr/X11R6/lib/X11/fonts/Type1/ FontPath /usr/X11R6/lib/X11/fonts/CID/ FontPath /usr/X11R6/lib/X11/fonts/Speedo/ FontPath /usr/X11R6/lib/X11/fonts/75dpi/ FontPath /usr/X11R6/lib/X11/fonts/100dpi/ ModulePath /usr/X11R6/lib/modules EndSection Section Module Load dbe Loadglx SubSection extmod Option omit xfree86-dga EndSubSection Load type1 Load freetype EndSection Section InputDevice Identifier Keyboard1 Driver keyboard Option AutoRepeat 500 30 Option XkbRules xfree86 Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Mouse1 Driver mouse Option Protocol PS/2 Option Device /dev/mouse EndSection Section Monitor Identifier My Monitor HorizSync 50.0-100.0 VertRefresh 40-90 EndSection Section Device Identifier VESA Framebuffer Driver fbdev EndSection Section Screen Identifier Screen 1 Device VESA Framebuffer Monitor My Monitor DefaultColorDepth 16 SubSection Display Depth 16 Modes 640x480 ViewPort 0 0 EndSubsection EndSection Section ServerLayout Identifier simple layout Screen Screen 1 InputDevice Mouse1 CorePointer InputDevice Keyboard1 CoreKeyboard EndSection ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 4.3 server crashes on Linux 2.4.20/21
On Fri, 13 Jun 2003, Chris Rankin wrote: Hi, I'm experiencing occasional X-server crashes with 4.3, running on my Linux 2.4.20-SMP machine. (The crashes also happen with 2.4.21, BTW.) This machine has 1 GB RAM, dual 933 PIII-Coppermine and a Matrox G400 card. I am also using the current DRI from CVS, except that these crashes don't require me to be running OpenGL applications to happen. For example, I've just had a repeated crash trying to follow a hyperlink on the linux-kernel mailing list website using Mozilla 1.3.1! Try not loading the freetype module. Maybe try xtt instead. Mark. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 4.3 + radeon 7200 (QD)
Florian Scandella wrote: i recently installed xfree 4.3 and am experienceing a major slowdown when running in a 24 bit resolution. as an example i played neverwinternights with no problem, after the upgrade it only runs in 16 bit mode ( unless you like slideshows ). there are some problems with that mode to ( textures, shadows,..) but i think thats not X's fault. direct rendering, agpart and mtrr are enabled. i also set the agp speed to x2. glxinfo shows Mesa DRI Radeon 20020611 AGP 2x x86/MMX/3DNow! TCL as rederer version. There were some recent changes to the Radeon driver in DRI CVS with respect to stencil buffer clears. This seemed to resolve some slow-down problems that other users were having with NWN. Did that resolve your problem as well? ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] xfree86 4.3 on freebsd 5.0
When will 4.3 binaries be available for freebsd 5.0 ? thanks for any info. [EMAIL PROTECTED] -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xfree86 4.3 on freebsd 5.0
Am Sonntag, 23. März 2003 16:55 schrieb rick norman: When will 4.3 binaries be available for freebsd 5.0 ? thanks for any info. [EMAIL PROTECTED] The sources are already in the ports tree! update it and you can build the binaries by yourself! ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86 4.3 bug?
i spent a lot of time fiddling with the Radeon 9000 driver,
both from ATI and XFree86,
it seems that the radeon driver from XFree86 4.3 doesn't support
3D acceleration, (although the config in RedHat 8 gives this option)
because tuxracer and Quake 3 runs extremely slow on my radeon 9000 128MB
card
then I tried to use the fglrx driver from ATI
first X says no module fglrx found, while I can modprobe fglrx
correctly,
then after looking into the X source code a bit, I changed the
XF86Config Driver to the absolute path
/lib/modules/2.4.20/kernel/drivers/char/drm/fglrx.o
this time X says the module is not valid
--
BUG??
_
I looked into xc/programs/Xserver/hw/xfree86/loader/loadmod.c
line 893, function
ModuleDescPtr
LoadModule (const char *module, const char *path, const char **subdirlist,
const char **patternlist, pointer options, const XF86ModReqInfo * modreq,
int *errmaj, int *errmin)
while (!found *path_elem != NULL)
{
found = FindModule (m, *path_elem, subdirlist, patterns);
path_elem++;
/*
* When the module name isn't the canonical name, search for the
* former if no match was found for the latter.
*/
if (!*path_elem m == name)
{
path_elem = pathlist;
m = (char *)module;
}
}
it seems that the first search on canonical name has not yet finished
before m is replaced with the non-canonical name
it looks a bit illogical
Yang
-
below is my /var/log/XFree86.0.log
XFree86 Version 4.3.0
Release Date: 27 February 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.20 i686 [ELF]
Build Date: 27 February 2003
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
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: Fri Feb 28 00:45:08 2003
(==) Using config file: /etc/X11/XF86Config
(==) ServerLayout XFree86 Configured
(**) |--Screen Screen0 (0)
(**) | |--Monitor Monitor0
(**) | |--Device Card0
(**) |--Input Device Mouse0
(**) |--Input Device Keyboard0
(==) Keyboard: CustomKeycode disabled
(**) FontPath set to
/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/CID/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/
(**) RgbPath set to /usr/X11R6/lib/X11/rgb
(**) ModulePath set to /usr/X11R6/lib/modules
(--) using VT number 7
(II) Open APM successful
(II) Module ABI versions:
XFree86 ANSI C Emulation: 0.2
XFree86 Video Driver: 0.6
XFree86 XInput driver : 0.4
XFree86 Server Extension : 0.2
XFree86 Font Renderer : 0.4
(II) Loader running on linux
(II) LoadModule: bitmap
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor=The XFree86 Project
compiled for 4.3.0, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.4
(II) Loading font Bitmap
(II) LoadModule: pcidata
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor=The XFree86 Project
compiled for 4.3.0, module version = 1.0.0
ABI class: XFree86 Video Driver, version 0.6
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1022,700e card , rev 13 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1022,700f card , rev 00 class 06,04,00 hdr 01
(II) PCI: 00:04:0: chip 1106,0686 card 1043,8040 rev 40 class 06,01,00 hdr 80
(II) PCI: 00:04:1: chip 1106,0571 card , rev 06 class 01,01,8a hdr 00
(II) PCI: 00:04:2: chip 1106,3038 card 0925,1234 rev 16 class 0c,03,00 hdr 00
(II) PCI: 00:04:3: chip 1106,3038 card 0925,1234 rev 16 class 0c,03,00 hdr 00
(II) PCI: 00:04:4: chip 1106,3057 card 1043,8040 rev 40 class 00,00,00 hdr 00
(II) PCI: 00:05:0: chip 13f6,0111 card 1043,80e2 rev 10 class 04,01,00 hdr 00
(II) PCI: 00:0a:0: chip 10ec,8139 card 10ec,8139 rev 10 class 02,00,00 hdr 00
(II) PCI: 00:0b:0: chip 1106,3038 card 0925,1234 rev 50 class 0c,03,00 hdr 80
(II) PCI: 00:0b:1: chip 1106,3038 card 0925,1234 rev 50 class 0c,03,00 hdr 80
(II) PCI: 00:0b:2: chip 1106,3104 card 0925,1234 rev 51 class 0c,03,20 hdr 80
(II) PCI: 00:0c:0: chip 1186,1300 card 1186,1301 rev 10 class 02,00,00 hdr 00
(II) PCI: 00:0d:0: chip 1106,3044 card 1106,3044 rev 46 class 0c,00,10 hdr 00
(II)
Re: [XFree86] XFree86 4.3 Radeon Mobility IGP 320M
I have an ati igp 340m on an hp laptop. I would like to test the drivers also. Please email them to me. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
RE: [XFree86] XFree86 4.3 Radeon Mobility IGP 320M
Hi, I'll give it a try. I already have 4.2.99.902. Cheers Adi. -Original Message- From: hy0 [mailto:[EMAIL PROTECTED] Sent: 21 February 2003 05:18 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [XFree86] XFree86 4.3 Radeon Mobility IGP 320M Unfortunately there probably isn't enough time to get IGP 320/340 support in the 4.3 release. I just got my IGP 320M laptop working (2D only), but the time is running out for more testing. Although IGP 320M is a M6 based chip, its UMA issue and other problems can cause the existing Radeon driver to hang in quite a few places. The changes are not just adding device IDs and need more testing. If you are willing to do some tests, I can send the driver on my system to you off the list (you'll need 4.2.99.9xx server to run it). Regards, Hui - Original Message - From: Brandon and Andrea Williams To: [EMAIL PROTECTED] Sent: Thursday, February 20, 2003 10:34 PM Subject: [XFree86] XFree86 4.3 Radeon Mobility IGP 320M I have an HP ZE4145 notebook, which uses the ATI Radeon Mobility IGP 320M chipset. I have been anxiously awaiting your 4.3 release in hopes that this chipset would be supported. I am attaching the error log generated when I try to start the X server. This is from Red Hat's 8.1 beta which was released on February 15. I know it doesn't have the most current 4.3 beta, but I have tried that as well, and it didn't even detect the card as the Radeon Mobility 1U, which the Red Hat beta does. Could you provide me some insight or support on why the X server is failing to start? Please let me know if you need any additional information. Thanks, Brandon Williams - Original Message - From: MELLERS Adrian [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Sent: Thursday, February 20, 2003 5:14 AM Subject: [XFree86] Compaq EVO n1005v Hi, I don't know if this problem has been reported or if I am in fact barking up the wrong tree. I have been busy downloading the newest XFree86 release's now for the past few weeks. I have a laptop a Compaq EVO n1005v which is quite a new model In fact it took two months for contact to supply drivers and rompaqs to get the display functioning in Windows 2000. As soon as I try to load X on the laptop the system freezes requiring a reboot, fsck kicks in and fails and a single use mode scan is required. I am running Debian 3.0 updated from the unstable ftp site. I have included a listing of lspci. lspci.txt I am currently downloading 4.2.99.902 to test. I read somewhere that the ATI Radeon Mobility U1 chipset was to be supported in the next release of XFree86. I'm going to play with my kernel now to see if that helps. Cheers Adi. Technical Support Etam UK Tel +44 (0) 1623 835959 x 3310 E-mail [EMAIL PROTECTED] This e-mail message and any attachments are intended for the addressee only. If you have received this in error please delete it permanently from your mail box and do not store or disseminate the information contained in this mail by any method. Thank you ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86 4.3 Radeon Mobility IGP 320M
I have an HP ZE4145 notebook, which uses the ATI Radeon Mobility IGP 320M chipset. I have been anxiously awaiting your 4.3 release in hopes that this chipset would be supported. I am attaching the error log generated when I try to start the X server. This is from Red Hat's 8.1 beta which was released on February 15. I know it doesn't have the most current 4.3 beta, but I have tried that as well, and it didn't even detect the card as the Radeon Mobility 1U, which the Red Hat beta does. Could you provide me some insight or support on why the X server is failing to start? Please let me know if you need any additional information. Thanks, Brandon Williams xerror.log Description: Binary data
Re: [XFree86] XFree86 4.3 Radeon Mobility IGP 320M
Unfortunately there probably isn't enough time to get IGP 320/340 support in the 4.3 release. I just got my IGP 320M laptop working (2D only), but the time is running out for more testing. Although IGP 320M is a M6 based chip, its UMA issue and other problems can cause the existing Radeon driver to hang in quite a few places. The changes are not just adding device IDs and need more testing. If you are willing to do some tests, I can send the driver on my system to you off the list (you'll need 4.2.99.9xx server to run it). Regards, Hui - Original Message - From: Brandon and Andrea Williams To: [EMAIL PROTECTED] Sent: Thursday, February 20, 2003 10:34 PM Subject: [XFree86] XFree86 4.3 Radeon Mobility IGP 320M I have an HP ZE4145 notebook, which uses the ATI Radeon Mobility IGP 320M chipset. I have been anxiously awaiting your 4.3 release in hopes that this chipset would be supported. I am attaching the error log generated when I try to start the X server. This is from Red Hat's 8.1 beta which was released on February 15. I know it doesn't have the most current 4.3 beta, but I have tried that as well, and it didn't even detect the card as the Radeon Mobility 1U, which the Red Hat beta does. Could you provide me some insight or support on why the X server is failing to start? Please let me know if you need any additional information. Thanks, Brandon Williams - Original Message - From: MELLERS Adrian [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Sent: Thursday, February 20, 2003 5:14 AM Subject: [XFree86] Compaq EVO n1005v Hi, I don't know if this problem has been reported or if I am in fact barking up the wrong tree. I have been busy downloading the newest XFree86 release's now for the past few weeks. I have a laptop a Compaq EVO n1005v which is quite a new model In fact it took two months for contact to supply drivers and rompaqs to get the display functioning in Windows 2000. As soon as I try to load X on the laptop the system freezes requiring a reboot, fsck kicks in and fails and a single use mode scan is required. I am running Debian 3.0 updated from the unstable ftp site. I have included a listing of lspci. lspci.txt I am currently downloading 4.2.99.902 to test. I read somewhere that the ATI Radeon Mobility U1 chipset was to be supported in the next release of XFree86. I'm going to play with my kernel now to see if that helps. Cheers Adi. Technical Support Etam UK Tel +44 (0) 1623 835959 x 3310 E-mail [EMAIL PROTECTED] This e-mail message and any attachments are intended for the addressee only. If you have received this in error please delete it permanently from your mail box and do not store or disseminate the information contained in this mail by any method. Thank you ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86 4.3
Does anyone know when XFree86 4.3 will be released? Thanks ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 4.3
Feigning erudition, Nigel Taylor wrote: % Does anyone know when XFree86 4.3 will be released? smirk When it's ready. /smirk Seriously, RSN after some significant bugs are squashed. Kurt -- All things are possible, except skiing thru a revolving door. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86-4.3!
On Tue, 21 Jan 2003, Ramesh K. Sistla wrote: I am new to the list and XFree86 as such(even though I am using X for past 5 yrs!). I would like to know if 4,3 version of X has been released. Info. reg. this will be of help. No, not yet. There has just been released a new prerelease snapshot (or rather, the newest files in CVS were tagged ;) ). Go back a day or two in the archive to see the schedule for 4.3. -Peter ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86-4.3!
Hello! I am new to the list and XFree86 as such(even though I am using X for past 5 yrs!). I would like to know if 4,3 version of X has been released. Info. reg. this will be of help. Thanks in advance. regards -- :-) ramesh sistla The Prayer of India: lokah samastah suKhino Bhavantu -- Let the entire world be in peace! ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
