How to disable Ctrl+Alt+Backspace in tinyx
Hello, do you know how to disable the Ctrl+Alt+Backspace in tinyx. I know that in full x server I have to change the XF86Config file but the tinyx (Xfbdev) does not need the XF86Config file. How Can disable Ctrl+Alt+Backspace in tinyx without the config file? thanks in advance. Gal Yahel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: s3 trio64, color depth problem (see also bug #465)
i have already tried that, but it doesn't help (still the blank screen). steven. maybe try depth 15 rather than 16... as I recall some old cards could only do one or the other. I'm no expert though. Alex ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
State of radeon driver
I have installed xfree86 4.4.0 rc1 on my laptop (an acer 1455LMi_ATI, with an AMD 600+cou, 512MB ram, and rdeon 9200 graphics). I am getting about 1000FPS on glxgears. I would expect more. Also there are some glitches( hesitations, and uneven display). What is the state of the driver? Is there a common source of patches/future versions of it available. I would like to be able to track progress on the driver and install new versions without redoing all of xfree86 which is a minor pain. Thanks, Tom Corner --- |\/\/\___/\/\/| Carol Anne Corner \ o o / Thomas Corner [EMAIL PROTECTED] ) ( 10-Dec-2003 12:15:44 Vienna, Austria ( * * ) mailer: xfmail \___/ Web Page: www.corner.chello.at --- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: State of radeon driver
Any idea whether what support 4.4.0 will have from the Radeo 9600 Pro ? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: State of radeon driver
On Wednesday 10 December 2003 12:48, wim delvaux wrote: Any idea whether what support 4.4.0 will have from the Radeo 9600 Pro ? And now in English ;-( Any idea what support 4.4.0 will have for the Radeo 9600 Pro ? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: State of radeon driver
On Wed, 2003-12-10 at 11:55, wim delvaux wrote: On Wednesday 10 December 2003 12:48, wim delvaux wrote: Any idea whether what support 4.4.0 will have from the Radeo 9600 Pro ? And now in English ;-( Any idea what support 4.4.0 will have for the Radeo 9600 Pro ? ATI haven't released any databooks about newer GPUs like R300 R350, so there's currently no 3D acceleration for these cards (9600, 9800 etc) yet. To the administrator; could the separator above the Devel mailing list be changed to be only -- , so that quoting when replying automatically removes that signature, when using compliant mailers. ___ Devel mailing list -- Torgeir Veimo [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: State of radeon driver
the _ is the mailmain default but can be canged. only the fglrx closed source drivers from ATI for the i386/Linux platform do have 3D. Databooks are no longer state of the art in the information technologies age. On Wednesday 10 December 2003 12:48, wim delvaux wrote: Any idea whether what support 4.4.0 will have from the Radeo 9600 Pro ? And now in English ;-( Any idea what support 4.4.0 will have for the Radeo 9600 Pro ? ATI haven't released any databooks about newer GPUs like R300 R350, so there's currently no 3D acceleration for these cards (9600, 9800 etc) yet. To the administrator; could the separator above the Devel mailing list be changed to be only -- , so that quoting when replying automatically removes that signature, when using compliant mailers. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
of manpages and names
I was wondering if it is possible to get manpages to be named slightly different than default without major surgery. I will illustrate what I want with an example. Say I have a manpage xterm.man. It gets generated as xterm.1 stored in the $(INSTALL_DIR)/man/man1. I want to change the generated file to be xterm.1x instead. How would one accomplish this? Is there some Imake #define that can be set? Thanks a lot, wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: State of radeon driver
On Wednesday 10 December 2003 13:09, Alexander Stohr wrote: the _ is the mailmain default but can be canged. only the fglrx closed source drivers from ATI for the i386/Linux platform do have 3D. Databooks are no longer state of the art in the information technologies age. I have tried these drivers but refuse to work. They think I have an (unsupported) OEM card (=powered by ATI) while according to the identity check programs run under XP it 'should' be an ATI one (=Built by ATI) (phoned to medion - who makes the card - and they claimed that ATI built the card for them ???) Any idea when the data-e-book will be available ;-) W On Wednesday 10 December 2003 12:48, wim delvaux wrote: Any idea whether what support 4.4.0 will have from the Radeo 9600 Pro ? And now in English ;-( Any idea what support 4.4.0 will have for the Radeo 9600 Pro ? ATI haven't released any databooks about newer GPUs like R300 R350, so there's currently no 3D acceleration for these cards (9600, 9800 etc) yet. To the administrator; could the separator above the Devel mailing list be changed to be only -- , so that quoting when replying automatically removes that signature, when using compliant mailers. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: State of radeon driver
I have tried these drivers but refuse to work. They think I have an (unsupported) OEM card (=powered by ATI) while according to the identity check programs run under XP it 'should' be an ATI one (=Built by ATI) There is no general OEM barrier anymore. It only was it was in early days where no one was sure if drivers would work well on those boards. It would be kind if you can you retry this test with latest fglrx drivers and mail me the results in private or public, just as you want. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: State of radeon driver
On Wed, 2003-12-10 at 12:26, wim delvaux wrote: On Wednesday 10 December 2003 13:09, Alexander Stohr wrote: the _ is the mailmain default but can be canged. only the fglrx closed source drivers from ATI for the i386/Linux platform do have 3D. Databooks are no longer state of the art in the information technologies age. I have tried these drivers but refuse to work. They think I have an (unsupported) OEM card (=powered by ATI) while according to the identity check programs run under XP it 'should' be an ATI one (=Built by ATI) (phoned to medion - who makes the card - and they claimed that ATI built the card for them ???) Any idea when the data-e-book will be available ;-) Well, probably not until a certain place in norway freezes over.. -- Torgeir Veimo [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: State of radeon driver
On Wednesday 10 December 2003 13:44, Alexander Stohr wrote: I have tried these drivers but refuse to work. They think I have an (unsupported) OEM card (=powered by ATI) while according to the identity check programs run under XP it 'should' be an ATI one (=Built by ATI) There is no general OEM barrier anymore. It only was it was in early days where no one was sure if drivers would work well on those boards. It would be kind if you can you retry this test with latest fglrx drivers and mail me the results in private or public, just as you want. Sure with pleasure ... where can I download the 'lastest' drivers ? W -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
David Dawes wrote: The patch is necessary for building against freetype 2.1.7, because changes in header file names were hidden behind these macros. BTW, what is this freetype-2.1.7 I keep reading about? Isn't freetype hosted on SourceForge anymore? The latest version I see there is 2.1.5. The freetype project moved somewhere else? My first question is, do you have a clean 4.3.99.901 tree? Yup. The next question is, is '-I/usr/include -I/usr/include/freetype2' on the gcc command lines as it should be? Yes it is. Can you send the actual build log extract for the failing part? Sure: #v+ rm -f ftfuncs.o unshared/ftfuncs.o gcc -c -I/usr/include -I/usr/include/freetype2 -I. -I../../../include/fonts -I../include -I../../../exports/include/X11 -I../../../programs/Xserver/include -I../../../extras/freetype2/src/truetype -I../../../exports/include -I../../.. -I../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXvExtension -DXFree86Server -DXF86VIDMODE -DSMART_SCHEDULE -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXFREE86_FT2 -march=pentium2 -Os -fomit-frame-pointer -s -pipe -DNDEBUG -DG_DISABLE_ASSERT -s -z combreloc ftfuncs.c ftfuncs.c:46:10: #include expects FILENAME or FILENAME ftfuncs.c:47:10: #include expects FILENAME or FILENAME [... CUT! Nearly 600 lines ...] make: *** [ftfuncs.o] Bd 1 #v- Also, check the depend stuff in the Makefile that gets created to see which ft2build.h file it thinks is getting used. After grep ft2build Makefile: ftfuncs.o: ../include/fontutil.h /usr/include/ft2build.h ftenc.o: ../include/fontutil.h ../include/fontenc.h /usr/include/ft2build.h fttools.o: /usr/include/ft2build.h If I replace the '#include ft2build.h' in ftfuncs.c with #include /usr/include/ft2build.h then it builds well. But if I leave the default '#include ft2build.h' it fails. But I think I know what's wrong. The gcc manual says: Directories named by -I are searched before the standard system include directories. So system directories, like /usr/include, have *lowest* priorities. Anything blessed with -I will be checked first. It gets even worse: (...) If the directory dir is a standard system include directory, the option (this means -I) is ignored So you can't do anything about it. The *only* way of solving this would be rearranging xc's includes. If you want gcc to use /usr/include/ft2build.h you need to make sure that gcc gets absolutely no -I pointing to a directory with a second ft2build.h in it. This isn't good, is it? It's not only freetype, it can probably happen to expat, fontconfig etc. Oh, and the troublemaking ft2build.h is, in this case, located in the xc/lib/font/FreeType directory (-I .) Once you remove it, it all works. And now I understand why. Well, this means that to ensure gcc3 compatibility the included external parts, like expat or freetype, would need to be completely isolated from the build process. gcc should not be allowed to learn about those includes unless they are really needed. 'cause if gcc finds them, it will use them instead of /usr/include. If you can figure out what the problem is and send a patch for it, that would be most welcome. It has to work with older versions of flex, as well as lex too. Someone with flexperience would be needed... On my config this does nicely: --- xc/programs/twm/lex.c 2003-12-10 17:10:27.0 +0100 +++ xc/programs/twm/lex.c.new 2003-12-10 17:10:47.0 +0100 @@ -25,6 +25,8 @@ /* flex integer type definitions */ +int yy_prev_more_offset; + #ifndef FLEXINT_H #define FLEXINT_H But it's just a quickdirty hack if someone (like me) is just interested in getting a XFree86 release to compile. I looked a bit at it, and it seems that flex, at least my flex-2.5.31, uses a /usr/include/FlexLexer.h header. I guess this header needs to be included in every flexed C source. However, greping twm for FlexLexer yields no results. But twm/lex.c already includes many, many definitions from FlexLexer.h (some are still missing, like yy_prev_more_offset). I don't know the history of flex - this /usr/include/FlexLexer.h is either something really new, or someone embedded an older FlexLexer.h file in twm sources long ago (which would explain why there are so many parts of FlexLexer.h in it). A good fix would be to kick redundand definitions out of twm/lex.c and put a #include FlexLexer.h there instead. But I don't know if it wouldn't break compatibility with older versions of flex or lex. I never used flex, so I don't know how to solve this. Argh, I don't like it. Two problems and I can't fix even a single one. Oh well, maybe someone else will. -- \hoppke (Grzegorz Grayna Niewgowski) http://lubuska.zapto.org/~hoppke/ ___ Devel mailing list [EMAIL PROTECTED]
Re: External FreeType build problem
Grzegorz Nieweglowski wrote: David Dawes wrote: The patch is necessary for building against freetype 2.1.7, because changes in header file names were hidden behind these macros. BTW, what is this freetype-2.1.7 I keep reading about? Isn't freetype hosted on SourceForge anymore? The latest version I see there is 2.1.5. The freetype project moved somewhere else? For some reason they've put 2.1.7 on their ftp site, but not on the sourceforge download page. You can find it at ftp://ftp.freetype.org/freetype/freetype2/ -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC1
On Wed, Dec 10, 2003 at 02:04:47PM +1000, [EMAIL PROTECTED] wrote: Further to my previous email, the results of a build with Glx give the following errors: rm -f mmx_blend.i /usr/ccs/lib/cpp -Dsun -Di386 -DSVR4 -D__EXTENSIONS__ -D__i386 -DMALLOC_0_RETURNS_NULL -DGLXEXT -DGLX_USE_MESA -DUSE_X86_ASM -DUSE_MMX_ASM -I../../../../../exports/include -I../../../../../include/extensions -I../../../../../extras/Mesa/src -I../../../../../extras/Mesa/src/X86-I../../../include mmx_blend.S | \ grep -v '^\#' mmx_blend.i rm -f mmx_blend.o gcc -c -x assembler -o mmx_blend.o mmx_blend.i Assembler: aline 1403 : Illegal mnemonic aline 1403 : syntax error aline 1403 : Illegal register aline 1403 : Illegal register aline 1414 : Illegal mnemonic aline 1414 : syntax error aline 1414 : Illegal register aline 1414 : Illegal mnemonic aline 1414 : syntax error aline 1414 : Illegal register aline 1414 : Illegal mnemonic aline 1414 : syntax error aline 1414 : Illegal register aline 1414 : Illegal register aline 1414 : Illegal mnemonic aline 1414 : syntax error aline 1414 : Illegal register aline 1414 : Illegal register aline 1414 : Illegal mnemonic aline 1414 : syntax error aline 1414 : Illegal register aline 1414 : Illegal register aline 1414 : Illegal mnemonic aline 1414 : syntax error aline 1414 : Illegal register aline 1414 : Illegal register aline 1414 : Illegal mnemonic aline 1414 : syntax error aline 1414 : Illegal register aline 1414 : Illegal register aline 1414 : Illegal mnemonic Too many errors - Goodbye *** Error code 1 make: Fatal error: Command failed for target `mmx_blend.o' Current working directory /proj3/ere/work/lindsayh/XFree86/xc/lib/GL/mesa/src/X86 The assembler in 2.5.1 probably doesn't support the MMX instructions. The solution is to make sure HasMMXSupport is set to NO for versions older than 2.6 in sun.cf. The entire file is attached. Maybe it is something to do with the use of /usr/ccs/lib/cpp?? David, what did your test builds on 2.6 - 8 use to generate mmx_blend.i? The mmx_blend.i I get looks like yours. The difference is that the assembler on 2.6 (and later) understands these instructions. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
On Wed, Dec 10, 2003 at 06:06:31PM +0100, Grzegorz Nieweglowski wrote: David Dawes wrote: The patch is necessary for building against freetype 2.1.7, because changes in header file names were hidden behind these macros. BTW, what is this freetype-2.1.7 I keep reading about? Isn't freetype hosted on SourceForge anymore? The latest version I see there is 2.1.5. The freetype project moved somewhere else? You can find it if you go to the freetype.org ftp site in France. I didn't see tarballs on the SourceForge site either. My first question is, do you have a clean 4.3.99.901 tree? Yup. The next question is, is '-I/usr/include -I/usr/include/freetype2' on the gcc command lines as it should be? Yes it is. Can you send the actual build log extract for the failing part? Sure: #v+ rm -f ftfuncs.o unshared/ftfuncs.o gcc -c -I/usr/include -I/usr/include/freetype2 -I. -I../../../include/fonts -I../include -I../../../exports/include/X11 -I../../../programs/Xserver/include -I../../../extras/freetype2/src/truetype -I../../../exports/include -I../../.. -I../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXvExtension -DXFree86Server -DXF86VIDMODE -DSMART_SCHEDULE -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXFREE86_FT2 -march=pentium2 -Os -fomit-frame-pointer -s -pipe -DNDEBUG -DG_DISABLE_ASSERT -s -z combreloc ftfuncs.c ftfuncs.c:46:10: #include expects FILENAME or FILENAME ftfuncs.c:47:10: #include expects FILENAME or FILENAME [... CUT! Nearly 600 lines ...] make: *** [ftfuncs.o] Blad 1 #v- Also, check the depend stuff in the Makefile that gets created to see which ft2build.h file it thinks is getting used. After grep ft2build Makefile: ftfuncs.o: ../include/fontutil.h /usr/include/ft2build.h ftenc.o: ../include/fontutil.h ../include/fontenc.h /usr/include/ft2build.h fttools.o: /usr/include/ft2build.h If I replace the '#include ft2build.h' in ftfuncs.c with #include /usr/include/ft2build.h then it builds well. But if I leave the default '#include ft2build.h' it fails. But I think I know what's wrong. The gcc manual says: Directories named by -I are searched before the standard system include directories. So system directories, like /usr/include, have *lowest* priorities. Anything blessed with -I will be checked first. It gets even worse: (...) If the directory dir is a standard system include directory, the option (this means -I) is ignored Do the gcc people give a reason for not allowing a system directory to be blessed with -I? Maybe adding -nostdinc would help, but that would probably have unwanted side-effects. So you can't do anything about it. The *only* way of solving this would be rearranging xc's includes. If you want gcc to use /usr/include/ft2build.h you need to make sure that gcc gets absolutely no -I pointing to a directory with a second ft2build.h in it. This isn't good, is it? It's not only freetype, it can probably happen to expat, fontconfig etc. Oh, and the troublemaking ft2build.h is, in this case, located in the xc/lib/font/FreeType directory (-I .) Once you remove it, it all works. And now I understand why. Well, this means that to ensure gcc3 compatibility the included external parts, like expat or freetype, would need to be completely isolated from the build process. gcc should not be allowed to learn about those includes unless they are really needed. 'cause if gcc finds them, it will use them instead of /usr/include. There is no ft2build.h in the xc/lib/font/FreeType directory in 4.3.99.901 (it got moved to the only place that uses it: xc/lib/font/FreeType/module). That's why I asked if your 4.3.99.901 source was clean :-) I did see this problem myself before moving it. If you can figure out what the problem is and send a patch for it, that would be most welcome. It has to work with older versions of flex, as well as lex too. Someone with flexperience would be needed... On my config this does nicely: --- xc/programs/twm/lex.c 2003-12-10 17:10:27.0 +0100 +++ xc/programs/twm/lex.c.new 2003-12-10 17:10:47.0 +0100 @@ -25,6 +25,8 @@ /* flex integer type definitions */ +int yy_prev_more_offset; + #ifndef FLEXINT_H #define FLEXINT_H But it's just a quickdirty hack if someone (like me) is just interested in getting a XFree86 release to compile. I looked a bit at it, and it seems that flex, at least my flex-2.5.31, uses a /usr/include/FlexLexer.h header. I guess this header needs to be included in every flexed C source. However, greping twm for FlexLexer yields no results. On the FreeBSD 4.x system I'm using right now (which has flex 2.5.4), the only place on the system that FlexLexer.h is installed is /usr/include/g++/ ! But twm/lex.c already includes many, many definitions from FlexLexer.h (some are still missing, like yy_prev_more_offset). I
Re: External FreeType build problem
David Dawes nawypisowywa(a): You can find it if you go to the freetype.org ftp site in France. I didn't see tarballs on the SourceForge site either. Oh, thanks! But that's strange, SourceForge doesn't know about the newest release, even official freetype mirrors are very out of date... it's like they're hiding it from the public... (...) If the directory dir is a standard system include directory, the option (this means -I) is ignored Do the gcc people give a reason for not allowing a system directory to be blessed with -I? I wouldn't call it a reason, but the manual puts it like this: (...) the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated. There is no ft2build.h in the xc/lib/font/FreeType directory in 4.3.99.901 (it got moved to the only place that uses it: xc/lib/font/FreeType/module). That's why I asked if your 4.3.99.901 source was clean :-) I did see this problem myself before moving it. But... but my tree is clean. It just isn't a pure 4.3.99.901 tarball, because some time ago I've downloaded 4.3.99.14 and then gradually patched it up. But all I did was unpack the archive, apply the newest patch and repack it. I tried not to break anything, really :) I know that not all changes can be registered by diff (and reproduced by patch) but I expected it only to affect non-textual files, like some images or maybe binary fonts. Diffpatch are pretty reliable when it comes to creating/removing text files, at least that's my impression. But I guess you'd need to use the '-N' diff option to get that behavior (at least with GNU diff), and the official patches don't do that, they only use -u. Is the -N something available only with some special versions of diff? Or would it be possible to generate future patches with -uN ? If there's a reliable way of knowing when to include FlexLexer.h, then we probably should include it. I've just noticed that my FlexLexer.h requires iostream and maybe some more C++ parts. Maybe that was the reason for merging parts of it into twm - to avoid the dependencies on a C++ compiler? If you would include this header, you would probably need something like g++ to compile twm. Not very nice, is it now. So maybe it would be easier to just play along and keep it the way it is now... just patch twm up a bit so that it compiles with older and newer flex releases... Would my, ekhm, patch cause trouble with older flex versions? -- \hoppke (Grzegorz Grayna Niewgowski) http://lubuska.zapto.org/~hoppke/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: of manpages and names
On Wed, 10 Dec 2003, Warren Turkal wrote: I was wondering if it is possible to get manpages to be named slightly different than default without major surgery. I will illustrate what I want with an example. Say I have a manpage xterm.man. It gets generated as xterm.1 stored in the $(INSTALL_DIR)/man/man1. I want to change the generated file to be xterm.1x instead. How would one accomplish this? Is there some Imake #define that can be set? That's ManSuffix, which is set in several files under config/cf -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: of manpages and names
X11 manpages are stored in /usr/X11R6/man/manx/whatever, not /usr/share/man/..., so filename clashes are not likely. If you change a filename, be sure to change the whatis database (or whatever it is that man uses to determine the manpage for a given command) too. From: Thomas Dickey [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: of manpages and names Date: Wed, 10 Dec 2003 15:15:29 -0500 (EST) On Wed, 10 Dec 2003, Warren Turkal wrote: I was wondering if it is possible to get manpages to be named slightly different than default without major surgery. I will illustrate what I want with an example. Say I have a manpage xterm.man. It gets generated as xterm.1 stored in the $(INSTALL_DIR)/man/man1. I want to change the generated file to be xterm.1x instead. How would one accomplish this? Is there some Imake #define that can be set? That's ManSuffix, which is set in several files under config/cf -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _ Winterize your home with tips from MSN House Home. http://special.msn.com/home/warmhome.armx ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: hi
Foreign messages have come to me at least 4 times in the last month or so, definitely more than a couple a year. You say that foreign language posts are off topic and shouldn't be made at all, while someone else said they can't be helped due to XFree86's international nature, but should in fact be welcomed...go figure. I guess the foreign posts should be ignored by the english sector, and let the foreign guys worry about it. I recently got a warning from the post master for relaying a volunteer request by X.org, and it definitely let me know I was in the wrong...perhaps the postmaster could contact other spammers and give them the same one-two that I got. IMHO, this would put a stop to the advertisements. From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: hi Date: Mon, 08 Dec 2003 14:12:14 -0800 I speak spanish and that seems to say something about your mother, big cow I hope I'm mistaken because that sounds rather rude. By the way, this is the 3rd foreign message I've received in the last week. I made a post about an automatic translation filter that checks the country domain; I'd really like to see it implemented. I've heard of babelfish. What would be the point? Almost all of the foreign language messages to this list are SPAM. In fact, this one would conflict with your recent request to limit profanity. The foreign language messages are OFF-TOPIC and don't belong at all. It would be alot of work to install such a filter, even if one did exist, just for one or two messages a year. When those very rare messages do occur, there are enough people on the list who speak other languages that can either respond or provide a translation if needed. If you see a non- English message on this list, you can safely assume it is SPAM, unless proven otherwise. BTW, this message does reference your mother, but according to it, the big cow is your wife (she's also a whore among other things). I won't go into what it tells you to do to yourself. From: luca bettati [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: hi Date: Fri, 05 Dec 2003 18:39:42 +0100 hai rotto il cazzo: tè, tua madre e quella gran vacca, zoccola, puttana e troia di tua moglie! vatti a farti fottere figlio di PUTTANA ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _ Get holiday tips for festive fun. http://special.msn.com/network/happyholidays.armx ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _ Shop online for kids toys by age group, price range, and toy category at MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: GeForce 4 Ti 4200 on Dell Inspiron 8500 (Filter no 20311056)
So this bug is in recent versions too? not just stoneware? In that case, I shall be posting to bugzilla. From: Mark Vojkovich [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: GeForce 4 Ti 4200 on Dell Inspiron 8500 Date: Mon, 8 Dec 2003 14:39:02 -0800 (PST) On Mon, 8 Dec 2003, Raymond Jennings wrote: That's funny, I had the same problem, only I have a Diamond Stealth II S220 and use the generic SVGA server. Whenever I switch to text mode and ESPECIALLY if I had a virtual resolution, it seems as if the video card isn't beginning the text scans at the right place, it's as if someone scrolled the text display over to the right by a character, and this is confusing because the cursor is correctly placed. If I type a few characters the text mode display jumps back to where it should have been in the first place. Whatever code is responsible for restoring text mode is messing up big time. Is this the kernel, or does the X server handle switches back to text mode? Similar problems on different architectures suggest that this fault is in global code. The driver is responsible for restoring the text mode. It is the XFree86 driver's fault alone when the text mode is not properly restored. Mark. From: Mark Vojkovich [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Christophe Jacquet [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: GeForce 4 Ti 4200 on Dell Inspiron 8500 Date: Sun, 7 Dec 2003 13:07:32 -0800 (PST) On Sun, 7 Dec 2003, Christophe Jacquet wrote: 3) When I switch back from graphics mode to text mode, the text display is messed up: the display is not correctly centered, one pixel out of two remains off, and horizontal lines appear when some text is printed on the last line. Did it used to work? I've never had one of these laptops myself so I've never tested on one. Does hitting the Font key fix it up again? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _ Get holiday tips for festive fun. http://special.msn.com/network/happyholidays.armx ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: State of radeon driver
On Wed, 10 Dec 2003 14:47:27 +0100, wim delvaux [EMAIL PROTECTED] wrote: I haven't seen this posting. ??? There is no general OEM barrier anymore. It only was it was in early days where no one was sure if drivers would work well on those boards. It would be kind if you can you retry this test with latest fglrx drivers and mail me the results in private or public, just as you want. Sure with pleasure ... where can I download the 'lastest' drivers ? Which drivers are we talking about here? I have also the problem that I can't get my 3D acceleration not to work with an ASUS 9800XT, but I have XFree86 4.3.0. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XServer kills console
Hi, On Dec 10 at 08:59:20, Raymond Jennings wrote: If you're using xinit, the xterm is the session, killing it causes the X server to exit. I know, but i'm launching X with /usr/X11R6/bin/X, not xinit. If your console dies, then something screwy is going on. Try the VT switching keys. No vt keys, no ctrl-alt-backspace, the console keyboard is definetely dead. I tried to repeat this bug with XFree86 4.2, but it seems it only happens with 4.3.0. cheers -- David Gómez The question of whether computers can think is just like the question of whether submarines can swim. -- Edsger W. Dijkstra ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: of manpages and names
Thomas Dickey wrote: That's ManSuffix, which is set in several files under config/cf Thanks very much. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: State of radeon driver
On Wednesday 10 December 2003 22:47, Gerhard W. Gruber wrote: On Wed, 10 Dec 2003 14:47:27 +0100, wim delvaux [EMAIL PROTECTED] wrote: I haven't seen this posting. ??? There is no general OEM barrier anymore. It only was it was in early days where no one was sure if drivers would work well on those boards. It would be kind if you can you retry this test with latest fglrx drivers and mail me the results in private or public, just as you want. Sure with pleasure ... where can I download the 'lastest' drivers ? Which drivers are we talking about here? I have also the problem that I can't get my 3D acceleration not to work with an ASUS 9800XT, but I have XFree86 4.3.0. The closed source drivers on the ATI website ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: State of radeon driver
On Thu, 11 Dec 2003 00:39:57 +0100, wim delvaux [EMAIL PROTECTED] wrote: The closed source drivers on the ATI website I tried them, but no success. But I think the problem is with KDE/OpenGL because I managed to get at least the Desktop with Mesa working. Only when I try to activate the ATI provided OpenGL lib I can't start X/KDE anymore. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[PATCH] documentation fix addition for config/cf/README
I moved the GzipCmd to get it in alphabetical order. I also added documentation for DriverManSuffix. wt --- README.old 2003-12-10 20:33:23.0 -0600 +++ README 2003-12-10 20:35:31.0 -0600 @@ -25,7 +25,6 @@ CURDIR current directory relative to top of sources CcCmd command to run C compiler CompressCmd command to run compress program - GzipCmd command to run gzip program ConstructMFLAGS System V option to set MFLAGS make variable CpCmd command to copy one file to another CplusplusCmdcommand to run C++ compiler @@ -50,6 +49,7 @@ FortranCmd command to run Fortran compiler FortranDebugFlags flags for Fortran debug info FortranFlagsFortran compiler flags + GzipCmd command to run gzip program HasBSD44Sockets boolean for system has BSD4.4 sockets HasBsdMake use the 4.4BSD variant of the make program? HasBsearch boolean for libc has bsearch() @@ -218,6 +218,7 @@ DefaultUserPath default user xdm PATH environment variable DependCmd command to run makedepend DependDir build directory containing makedepend program + DriverManSuffix man suffix for driver pages ExtensionDefines-D's for universal extensions ExtensionOSDefines -D's for additional extensions FontCompilerFlags flags for bdftosnf -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Happyness with Radeon 9200 SE
Just as a word of thanks, I was able to successfully use the recent 4.4 snapshot to drive my dual head Radeon 9200SE. The MonitorLayout Option always failed to initiate the DVI port correctly. This is also a problem on the ATI provided drivers recommended for the board. Roger ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] documentation fix addition for config/cf/README
Warren Turkal wrote: I moved the GzipCmd to get it in alphabetical order. I also added documentation for DriverManSuffix. This is an update of the previous. In addition to what is done in the last patch (this patch includes it), I also documented DriverManDir and MiscManDir. wt --- ../../../xc-old/config/cf/README2003-04-25 06:00:03.0 -0500 +++ README 2003-12-10 22:47:32.0 -0600 @@ -25,7 +25,6 @@ CURDIR current directory relative to top of sources CcCmd command to run C compiler CompressCmd command to run compress program - GzipCmd command to run gzip program ConstructMFLAGS System V option to set MFLAGS make variable CpCmd command to copy one file to another CplusplusCmdcommand to run C++ compiler @@ -50,6 +49,7 @@ FortranCmd command to run Fortran compiler FortranDebugFlags flags for Fortran debug info FortranFlagsFortran compiler flags + GzipCmd command to run gzip program HasBSD44Sockets boolean for system has BSD4.4 sockets HasBsdMake use the 4.4BSD variant of the make program? HasBsearch boolean for libc has bsearch() @@ -218,6 +218,8 @@ DefaultUserPath default user xdm PATH environment variable DependCmd command to run makedepend DependDir build directory containing makedepend program + DriverManDirdirectory in which to install driver man pages + DriverManSuffix man suffix for driver pages ExtensionDefines-D's for universal extensions ExtensionOSDefines -D's for additional extensions FontCompilerFlags flags for bdftosnf @@ -246,6 +248,7 @@ ManSourcePath common prefix of man page directories ManSuffix man suffix for programs MiscManSuffix man suffix for miscellaneous pages + MiscManDir directory in which to install misc man pages NeedDefaultDepLibs boolean for enabling default DEPLIBS NlsDir directory in which to install nls files NormalLibFS build libFS.a -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [I18n] Changes for xkb/symbos/pc/br
Hi, One question: the use of pc/[language code] will be the standard in XFree86 4.4? Yes. If you are talking about [language code] for keyboard map name nothing is changed there yet. There were proposals discussed here for new keyboard maps that implied name changes of some maps but that work still isn't complete. If you mean the 'pc' directory for XKB symbols maps it's right too. You see that the maps in symbols/pc differ from ones in symbols directory. The maps were rewritten to allow combining them easy in one multi_layout keymap. But existent maps were left for compatibility and as a fallback for the case of possible issues with new maps. Thus 'old' maps are kept in symbols directory and new maps are in symbols/pc. (The name 'pc' was chosen because other vendor keyboard maps have own directories and it would be right to place in the symbols itself only pieces that are common for all maps.) BTW. I added us(intl) submap (i.e. a variant of US keymap) making it similar to MS Windows US International keymap as much as possible. If one complain on us_intl map you can suggest to try this new one. :) -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Changes for xkb/symbos/pc/br
On Wed, 10 Dec 2003 20:13:52 +0600 (TSK) Ivan Pascal [EMAIL PROTECTED] wrote: Hi, One question: the use of pc/[language code] will be the standard in XFree86 4.4? Yes. If you are talking about [language code] for keyboard map name nothing is changed there yet. There were proposals discussed here for new keyboard maps that implied name changes of some maps but that work still isn't complete. Yes, I read the discussion in the list archive. I do not agree totally about the Country/Language configuration, but I will not discuss in this thread ;) If you mean the 'pc' directory for XKB symbols maps it's right too. You see that the maps in symbols/pc differ from ones in symbols directory. The maps were rewritten to allow combining them easy in one multi_layout keymap. But existent maps were left for compatibility and as a fallback for the case of possible issues with new maps. Thus 'old' maps are kept in symbols directory and new maps are in symbols/pc. (The name 'pc' was chosen because other vendor keyboard maps have own directories and it would be right to place in the symbols itself only pieces that are common for all maps.) OK, I have noted that the maps are different, and I suppose they are in accordance with what you wrote in The XKB internals (I should confess I couldn't understand this text very well...). I would like to try the new maps in pc directory; all I need is to change the XF86Config from: Option XkbLayout br to: Option XkbLayout pc/br ? And I am still using 4.3.0 (I have just downloaded the Xetc.tgz of 4.4 beta); do these maps work on 4.3.0? BTW. I added us(intl) submap (i.e. a variant of US keymap) making it similar to MS Windows US International keymap as much as possible. If one complain on us_intl map you can suggest to try this new one. :) Great :) BTW, the Japanese map is missing in the pc directory... -- Ricardo Yassuo Igarashi E-mail: [EMAIL PROTECTED] Linux HP: http://web.that.com.br/iga ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [XFree86] xf86ReadMmio32 not found
Le 10.12.2003 02:05:50, Eric Anholt a écrit : On Tue, 2003-12-09 at 08:57, manu wrote: Le 09.12.2003 23:06:05, Linus Gasser a écrit : Hello, I installed a brand-new, shiny Radeon 9200 PCI card in my alpha 164 (hoping to be able to play crack-attack ;) and for two weeks tried to install it. Now that I have Full build of XFree86 version 4.3.99.901 ( 2 December 2003) complete. installed (well, cvs is from 6th of december), I hoped to be on my way: (II) RADEON(0): X context handle = 0x0001 (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 19 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808 (II) RADEON(0): Direct rendering enabled but, alas, running glxinfo gives me this: [EMAIL PROTECTED]:~$ LIBGL_DEBUG=1 glxinfo name of display: :0.0 libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed (/usr/X11R6/lib/modules/dri/r200_dri.so: undefined symbol: xf86ReadMmio32) libGL error: unable to find driver: r200_dri.so what did I do wrong that he doesn't find this symbol? Any idea? This file r200_dri.so is the dri module taking care of your gfx chip. Seems that it was not built on your box. You can just download snapshots from the dri website on sourceforge. Be careful that you perhaps need to also download a special X server. Ate least this was needed with 4.3.0 release, I am not sure this is also needed with current cvs, anyona could confirm/infrim please? The log cited shows that the module does exist, it's just that it can't be dlopen()ed because it has an undefined symbol. I don't know why the driver would be referring to an xf86ReadMmio32, though. Oops you're right, my bad, I read that too fast. Still this seems to be a weird error. Bye Manu pgp0.pgp Description: PGP signature
[XFree86] Where i send monitor information ??
Hi, excuse my english pls I have a monitor that is not in xfree database. where, how and what should i send to help providing the need it information. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xf86ReadMmio32 not found
On Wednesday 10 December 2003 19:52, David Dawes wrote: On Wed, Dec 10, 2003 at 09:30:12AM +0100, Linus Gasser wrote: As I wrote, I installed a fresh, new XFree 4.3.99.901, cvs from 6th December, and I also checked that the file that has been compiled in the XFree-tree is the same as in /usr/X11R6/lib/modules/dri/r200_dri.so but I'll check again this evening, just to be sure. What platform are you building on? It looks like the INREG() code in r200_screen.c could expand to this on some platforms. Some code in the radeon_dri.so module that uses INREG is #ifdef'd out for Alpha platforms. Not all of it though, and not the instances of it in the r200_dri.so module. David It's an alpha pc164 (as stated in my first mail ;-), and I stumbled already over a first error that got fixed quite fast (#938, thanks to Alan Hourihane), obviously I should've filed a second bug. I've done so now, and also added the diff with the INREGs #ifdef'd out for Alpha (there was still some in radeon_screen.c, r128_ioctl.c). The bug-# is 967, the attachement is there. Now it works for me! thanks for your fast reply and for the right hint! ineiti -- -- Linus Gasser Chemin des Cèdres 1 1004 Lausanne 021 647 53 05 http://www.linusetviviane.ch -- ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Monitor Resolution
On Wed, 10 Dec 2003, TrustNoOne wrote: I have install the latest Slackware Linux 9.1 distribution which has XFree86 4.3.0. I have an old nVidia RIVA TNT2 graphics adapter and a Hitachi CM650 ET 17'' monitor. I'm also using kernel 2.4.22. My problem is that although I can't find any problems on the log, my x session are stack on a 1024x768 resolution. I'd like a higher resolution but when i try to use a 1152x864 or a 1280x1024 resolution, although at first it seems like the session is going to start that way, in about a second it switches back to 1024x768. I'd really appreciate any kind of help on my problem because I can't do my job with such a small resolution. Thanks in advance. 1) Your resolution problem is not a driver issue. The server thinks your 1280x1024 mode is the default mode and the server switches comes up in that. You may have some weird keyboard thing going on and the ctrlalt+/- that is used to switch modes is mapping to something else. Removing all the modes other than the 1280x1024 mode from the Modes line should fix that in any case. 2) Remove your VideoRam line from the Section Device. The driver will autodetect the amount and you definitely do not have 64 Meg (16 or 32 is more like it). 3) Your kernel doesn't appear to have MTRR support this will cost you much performance. Mark. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xf86ReadMmio32 not found
On Wed, Dec 10, 2003 at 11:06:01PM +0100, Linus Gasser wrote: On Wednesday 10 December 2003 19:52, David Dawes wrote: On Wed, Dec 10, 2003 at 09:30:12AM +0100, Linus Gasser wrote: As I wrote, I installed a fresh, new XFree 4.3.99.901, cvs from 6th December, and I also checked that the file that has been compiled in the XFree-tree is the same as in /usr/X11R6/lib/modules/dri/r200_dri.so but I'll check again this evening, just to be sure. What platform are you building on? It looks like the INREG() code in r200_screen.c could expand to this on some platforms. Some code in the radeon_dri.so module that uses INREG is #ifdef'd out for Alpha platforms. Not all of it though, and not the instances of it in the r200_dri.so module. David It's an alpha pc164 (as stated in my first mail ;-), and I stumbled already over a first error that got fixed quite fast (#938, thanks to Alan Hourihane), obviously I should've filed a second bug. I've done so now, and also added the diff with the INREGs #ifdef'd out for Alpha (there was still some in radeon_screen.c, r128_ioctl.c). The bug-# is 967, the attachement is there. Now it works for me! thanks for your fast reply and for the right hint! I don't know that disabling it is a real solution though. It is clearly better than it was, but some apps are likely to fail. Maybe the DRM driver should be providing this information? I'm not even sure what the security implications are of allowing the MMIO area to be mapped into an app. Doesn't that mean that a rogue DRI app could potentially reprogram the video hardware, unless it is mapped read-only? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xf86ReadMmio32 not found
Actually,
I've just examined the code for reading on alpha, and regardless of
a Jensen or other type of alpha it's always the same for a 32bit read.
So can you reverse your patch and try this
Alan.
Index: r200_screen.c
===
RCS file: /X11R6/x-cvs/xc/lib/GL/mesa/src/drv/r200/r200_screen.c,v
retrieving revision 1.6
diff -u -r1.6 r200_screen.c
--- r200_screen.c 2 Dec 2003 13:02:39 - 1.6
+++ r200_screen.c 11 Dec 2003 00:53:47 -
@@ -65,6 +65,18 @@
#define PCI_CHIP_RV200_QW 0x5157 /* Radeon 7500 - not an R200 at all */
#endif
+#ifdef __alpha__
+
+#define mem_barrier()__asm__ __volatile__(mb : : : memory)
+
+int
+xf86ReadMmio32(pointer Base, register unsigned long Offset)
+{
+mem_barrier();
+return *(volatile CARD32*)((unsigned long)Base+(Offset));
+}
+#endif
+
static r200ScreenPtr __r200Screen;
static int getSwapInfo( __DRIdrawablePrivate *dPriv, __DRIswapInfo * sInfo );
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xf86ReadMmio32 not found
On Wed, Dec 10, 2003 at 07:39:43PM -0500, David Dawes wrote: On Thu, Dec 11, 2003 at 12:25:25AM +, Alan Hourihane wrote: On Wed, Dec 10, 2003 at 07:13:39PM -0500, David Dawes wrote: On Wed, Dec 10, 2003 at 11:06:01PM +0100, Linus Gasser wrote: On Wednesday 10 December 2003 19:52, David Dawes wrote: On Wed, Dec 10, 2003 at 09:30:12AM +0100, Linus Gasser wrote: As I wrote, I installed a fresh, new XFree 4.3.99.901, cvs from 6th December, and I also checked that the file that has been compiled in the XFree-tree is the same as in /usr/X11R6/lib/modules/dri/r200_dri.so but I'll check again this evening, just to be sure. What platform are you building on? It looks like the INREG() code in r200_screen.c could expand to this on some platforms. Some code in the radeon_dri.so module that uses INREG is #ifdef'd out for Alpha platforms. Not all of it though, and not the instances of it in the r200_dri.so module. David It's an alpha pc164 (as stated in my first mail ;-), and I stumbled already over a first error that got fixed quite fast (#938, thanks to Alan Hourihane), obviously I should've filed a second bug. I've done so now, and also added the diff with the INREGs #ifdef'd out for Alpha (there was still some in radeon_screen.c, r128_ioctl.c). The bug-# is 967, the attachement is there. Now it works for me! thanks for your fast reply and for the right hint! I don't know that disabling it is a real solution though. It is clearly better than it was, but some apps are likely to fail. Maybe the DRM driver should be providing this information? I'm not even sure what the security implications are of allowing the MMIO area to be mapped into an app. Doesn't that mean that a rogue DRI app could potentially reprogram the video hardware, unless it is mapped read-only? It is mapped read-only. Good :-) I guess the only way to handle this is to export the memory read/write functions in a library to allow DRI drivers to link against. So we'd have a library that contains xf86ReadMmio32(), xf86ReadMmio16()... Does that sound plausible David ? It looks complicated on Alpha because of the sparse/dense mapping modes, so the XFree86 server has to determine at run-time how to do MMIO. However, if only 32-bit access is used (and you don't need Jensen support) just declaring a local xf86ReadMmio32 function pointer and initialising it to readDense32() should be good enough. I think readDense32() is provided in libc on Alpha. Actually, I take that back for Jensen. I didn't look close enough. Alan. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xf86ReadMmio32 not found
On Wed, Dec 10, 2003 at 07:39:43PM -0500, David Dawes wrote:
On Thu, Dec 11, 2003 at 12:25:25AM +, Alan Hourihane wrote:
On Wed, Dec 10, 2003 at 07:13:39PM -0500, David Dawes wrote:
On Wed, Dec 10, 2003 at 11:06:01PM +0100, Linus Gasser wrote:
On Wednesday 10 December 2003 19:52, David Dawes wrote:
On Wed, Dec 10, 2003 at 09:30:12AM +0100, Linus Gasser wrote:
As I wrote, I installed a fresh, new XFree 4.3.99.901, cvs from 6th
December, and I also checked that the file that has been compiled in the
XFree-tree is the same as in
/usr/X11R6/lib/modules/dri/r200_dri.so
but I'll check again this evening, just to be sure.
What platform are you building on? It looks like the INREG() code in
r200_screen.c could expand to this on some platforms. Some code in the
radeon_dri.so module that uses INREG is #ifdef'd out for Alpha platforms.
Not all of it though, and not the instances of it in the r200_dri.so
module.
David
It's an alpha pc164 (as stated in my first mail ;-), and I stumbled already
over a first error that got fixed quite fast (#938, thanks to Alan
Hourihane), obviously I should've filed a second bug. I've done so now, and
also added the diff with the INREGs #ifdef'd out for Alpha (there was still
some in radeon_screen.c, r128_ioctl.c). The bug-# is 967, the attachement is
there. Now it works for me!
thanks for your fast reply and for the right hint!
I don't know that disabling it is a real solution though. It is
clearly better than it was, but some apps are likely to fail.
Maybe the DRM driver should be providing this information? I'm
not even sure what the security implications are of allowing the
MMIO area to be mapped into an app. Doesn't that mean that a rogue
DRI app could potentially reprogram the video hardware, unless it
is mapped read-only?
It is mapped read-only.
Good :-)
I guess the only way to handle this is to export the memory read/write
functions in a library to allow DRI drivers to link against. So we'd
have a library that contains xf86ReadMmio32(), xf86ReadMmio16()...
Does that sound plausible David ?
It looks complicated on Alpha because of the sparse/dense mapping
modes, so the XFree86 server has to determine at run-time how to
do MMIO. However, if only 32-bit access is used (and you don't
need Jensen support) just declaring a local xf86ReadMmio32 function
pointer and initialising it to readDense32() should be good enough.
I think readDense32() is provided in libc on Alpha.
All other platforms should get handled via the inline's provided
in compiler.h.
In fact, regardless of dense or sparse mapping the read is exactly the
same for 32bit access. It only differs for 8 or 16 bit access. That's
even true for JENSEN. And all readDense32() does is a mem_barrier then
a volatile read - just like normal.
I'm thinking of committing this patch...
Alan.
Index: compiler.h
===
RCS file: /X11R6/x-cvs/xc/programs/Xserver/hw/xfree86/common/compiler.h,v
retrieving revision 3.104
diff -u -r3.104 compiler.h
--- compiler.h 3 Nov 2003 05:11:01 - 3.104
+++ compiler.h 11 Dec 2003 01:05:08 -
@@ -1616,7 +1616,7 @@
extern int (*xf86ReadMmio32)(void *, unsigned long);
extern void (*xf86WriteMmio8)(int, void *, unsigned long);
extern void (*xf86WriteMmio16)(int, void *, unsigned long);
-extern void (*xf86WriteMmio32)(int, void *, unsigned long);
+/* extern void (*xf86WriteMmio32)(int, void *, unsigned long); */
extern void (*xf86WriteMmioNB8)(int, void *, unsigned long);
extern void (*xf86WriteMmioNB16)(int, void *, unsigned long);
extern void (*xf86WriteMmioNB32)(int, void *, unsigned long);
@@ -1625,11 +1625,19 @@
extern void xf86SlowBCopyFromBus(unsigned char *, unsigned char *, int);
extern void xf86SlowBCopyToBus(unsigned char *, unsigned char *, int);
+/* regardless of the type of alpha we have, a 32bit read is always the same */
+static __inline__ unsigned int
+xf86ReadMmio32(pointer Base, register unsigned long Offset)
+{
+mem_barrier();
+return *(volatile unsigned int *)((unsigned long)Base+(Offset));
+}
+
/* Some macros to hide the system dependencies for MMIO accesses */
/* Changed to kill noise generated by gcc's -Wcast-align */
# define MMIO_IN8(base, offset) (*xf86ReadMmio8)(base, offset)
# define MMIO_IN16(base, offset) (*xf86ReadMmio16)(base, offset)
-# define MMIO_IN32(base, offset) (*xf86ReadMmio32)(base, offset)
+# define MMIO_IN32(base, offset) xf86ReadMmio32(base, offset)
# if defined (JENSEN_SUPPORT)
# define MMIO_OUT32(base, offset, val) \
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xf86ReadMmio32 not found
On Thu, Dec 11, 2003 at 12:54:10AM +, Alan Hourihane wrote:
Actually,
I've just examined the code for reading on alpha, and regardless of
a Jensen or other type of alpha it's always the same for a 32bit read.
So can you reverse your patch and try this
Alan.
Index: r200_screen.c
===
RCS file: /X11R6/x-cvs/xc/lib/GL/mesa/src/drv/r200/r200_screen.c,v
retrieving revision 1.6
diff -u -r1.6 r200_screen.c
--- r200_screen.c 2 Dec 2003 13:02:39 - 1.6
+++ r200_screen.c 11 Dec 2003 00:53:47 -
@@ -65,6 +65,18 @@
#define PCI_CHIP_RV200_QW 0x5157 /* Radeon 7500 - not an R200 at all */
#endif
+#ifdef __alpha__
+
+#define mem_barrier()__asm__ __volatile__(mb : : : memory)
+
+int
+xf86ReadMmio32(pointer Base, register unsigned long Offset)
+{
+mem_barrier();
+return *(volatile CARD32*)((unsigned long)Base+(Offset));
+}
+#endif
+
static r200ScreenPtr __r200Screen;
static int getSwapInfo( __DRIdrawablePrivate *dPriv, __DRIswapInfo * sInfo );
xf86ReadMmio32 is declared in compiler.h as a function pointer,
not a function.
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] E-mai1ing serv1ce
Title: ema1l broadcast Bu1k Email - We Send For You! - EMAIL WITH NO FEAR!We offer to send your emails at a speed of 100's of letters per second.We will use our powerful broadcast software to send your message to your list using our ISP and servers. NO TROUBLES FOR YOU!Bu1k Email Market1ng is fast and effective, We do all the mailing for you. You just provide us with the ad! It's that simple!Your email campaign can be underway, often in less than 24 hours.Request more information on our email sending services.. even to compare our prices...If you would rather not rece1ve any further information from us, please
Re: [XFree86] Current DRM modules from http://www.xfree86.org/~alanh/
Ack.. hmm.. Well to start with.. 1. You want to use linux-drm.4.2.0 kernelsource with 4.3.99.12 Xfree86 DRM module with hmm.. the (please tell me which version of X your are running) version of X, with the 2.6.0-test kernel? You are insane. Perhaps you are just misguided. Beating-you- around-the-head-with-a-lumpy-stick First of all.. Pick a version of X. It seems you are running at least 2 if not more different module versions. drm kernel modules that say 4.2.0 are designed to work for 4.2.0 not 4.3.99.12. I'm confused to where you got the developmental drm module. As for your Make -f linux compile problem, You can't compile without building the kernel. It looks to me as though you just downloaded some pre compiled 2.6test kernel. Compiling 2.6 is not for the faint of heart..but if you want to go read some good documentation at www.kerneltrap.org I think that you are way over your head..Forgive me if I am mistaken. I know you want to tweak your system out, but this is alot of developmental stuff not for consumption of end-user, at least not yet.. If I have read your message completely wrong... provide more information and perhaps I can help you better. Gary 2. On December 9, 2003 09:23 pm, Dan Goodes wrote: Hi Folks, just wondering, since i'm having so many troubles with the linux-drm-4.2.0-kernelsource.tar.gz file from the above location, if it's designed for 2.4.X kernels only? I run a 2.6.0-test kernel on fedora core, and the above doesn't compile when i run make -f Makefile.linux. It spits out a LOT of ugly compile errors beginning with : command line:153473382:53672: /lib/modules/2.6.0-0.test10.1.95/build/include/linux/modversions.h: No such file or directory I also have a couple of other questions, if I may... 1) what, if anything, is the state of 3D/DRI support for the Radeon IGP320M (a.k.a. Radeon Mobility U1), in the latest XFree86 snapshots? I've already done a bit of emailing around, and so far I've ascertained that the DRI folk say that the support should be there, once AGPgart support is there. But I'm running, as i said, a 2.6.0-test kernel that appears to support agpgart on the chipset, and still have no 3D. I'm also running 4.4.0-RC1. When I run glxinfo the first line I get is Xlib: extension XFree86-DRI missing on display :0.0. In my Xfree86 log file I have (II) Loading /usr/X11R6/lib/modules/linux/libdrm.a (II) Module drm: vendor=The XFree86 Project compiled for 4.3.99.901, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: synaptics and that's the only mention of DRI anywhere. nothing to say that it failed at all. So basically I'm trying to work out what, if anything, I'm doing wrong to stop it working, and how I can get it to work. All the peices seem to be there, but it just doesn't want to work. Thanks in advance for any advice, help, or beating-around-the-head-with-a-lumpy-stick you can offer :) -Dan ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] the candidate crashed in my - Dell Inspiron 1100 :(
Dell Inspiron 1100 - bios version A23 intel 8245GL Does someone know if it gonna be fixed ? or what can I do to fix it? Thanks Here is the Log file This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.99.901 (4.4.0 RC 1) Release Date: 2 December 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: FreeBSD 5.1-RELEASE i386 [ELF] Current Operating System: FreeBSD blabla.mydomain 5.2-BETA FreeBSD 5.2-BETA #2: Fri Nov 28 15:48:09 AKST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MIKERNEL i386 Build Date: 05 December 2003 Changelog Date: 03 December 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: Wed Dec 10 04:15:53 2003 (==) Using config file: /root/XF86Config (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor My Monitor (**) | |--Device My Video Card (**) |--Input Device Mouse1 (**) |--Input Device Keyboard1 (**) Option AutoRepeat 500 30 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc101 (**) XKB: model: pc101 (**) Option XkbLayout us (**) XKB: layout: us (**) Option XkbVariant us (**) XKB: variant: us (==) Keyboard: CustomKeycode disabled (**) FontPath set to /usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/l ib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/:unscaled,/usr/ X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X 11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.7 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on freebsd (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.3.99.901, 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.99.901, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.7 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (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,2560 card , rev 03 class 06,00,00 hdr 00 (II) PCI: 00:02:0: chip 8086,2562 card 1028,0149 rev 03 class 03,00,00 hdr 00 (II) PCI: 00:1d:0: chip 8086,24c2 card 8086,24c0 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,24c4 card 8086,24c0 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,24c7 card 8086,24c0 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,24cd card 8086,24c0 rev 02 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card , rev 82 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,24c0 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,24cb card 8086,24c0 rev 02 class 01,01,8a hdr 00 (II) PCI: 00:1f:5: chip 8086,24c5 card 1028,0149 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,24c6 card 14e4,4d64 rev 02 class 07,03,00 hdr 00 (II) PCI: 02:01:0: chip 14e4,4401 card 4401,1028 rev 01 class 02,00,00 hdr 00 (II) PCI: 02:04:0: chip 104c,ac56 card fffc, rev 00 class 06,07,00 hdr 02 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,2), 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 2: bridge is at (0:30:0), (0,2,2), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0xd000 - 0xd0ff (0x100) IX[B] [1] -1 0 0xd400 - 0xd4ff (0x100) IX[B] [2] -1 0 0xd800 - 0xd8ff (0x100) IX[B] [3] -1 0 0xdc00 - 0xdcff (0x100) IX[B] [4] -1 0
[XFree86] X server not loading
i recived the following information. sometimes the server was loading and sometimes it isn't. please help. Xfree86 version 4.3.0 (Red Hat Linux Release: 4.3.0-2) Release date: 27 Feburary 2003 X protocol version 11, Revision 0, release 6.6 Build operating system: linux 2.4.20-3bigmem i686[ELF] Build Date:27 Feb 2003 Build Host:porky.devel.redhat.com Module Loader present OS Kernel: Linux Version 2.4.20-8([EMAIL PROTECTED])(gcc ver 3.2.2 20030222(Red Hat Linux 3.2.2-5))#1 Thu Mar 13 17:54:28 EST 2003 (==)Log File:"/var/log/Xfree86.log",Time:sat sep 6 18:48:37 2003 (==)Using config file:"/etc/x11/xf86config" (ww)I810:no matching device section for instance(Bus ID PCI:0:1:0)found (EE)No devices detected Fatal Server Error: No screens found
