CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 16:57:24 Log message: 327. Build fix for Mac OS X 10.4 (Bugzilla #1545, Torrey T. Lyons). Modified files: xc/config/cf/: darwin.cf Revision ChangesPath 1.53 +7 -5 xc/config/cf/darwin.cf ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 17:05:27 Log message: dmx doc build + minor updates Modified files: xc/programs/Xserver/hw/dmx/doc/: Imakefile dmx.sgml scaled.sgml Revision ChangesPath 1.2 +7 -1 xc/programs/Xserver/hw/dmx/doc/Imakefile 1.2 +10 -5 xc/programs/Xserver/hw/dmx/doc/dmx.sgml 1.2 +6 -1 xc/programs/Xserver/hw/dmx/doc/scaled.sgml ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 17:06:34 Log message: update formatted docs Modified files: xc/programs/Xserver/hw/dmx/doc/: dmx.txt scaled.txt Revision ChangesPath 1.2 +2472 -2982xc/programs/Xserver/hw/dmx/doc/dmx.txt 1.2 +471 -531 xc/programs/Xserver/hw/dmx/doc/scaled.txt ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 17:08:33 Log message: update versions Modified files: xc/programs/Xserver/hw/xfree86/doc/sgml/: defs.ent Revision ChangesPath 1.42 +4 -4 xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 17:09:37 Log message: Use better-named feature test macros in dixfonts. + some TinyX naming consistencies. Modified files: xc/programs/Xserver/dix/: dixfonts.c xc/programs/Xserver/hw/dmx/input/: lnx-ms.c lnx-ps2.c xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xwin/: winscrinit.c Revision ChangesPath 3.31 +4 -4 xc/programs/Xserver/dix/dixfonts.c 1.2 +2 -2 xc/programs/Xserver/hw/dmx/input/lnx-ms.c 1.2 +2 -2 xc/programs/Xserver/hw/dmx/input/lnx-ps2.c 3.3436+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.29 +7 -7 xc/programs/Xserver/hw/xwin/winscrinit.c ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 17:36:55 Log message: formatting fixes Modified files: xc/programs/Xserver/hw/xfree86/doc/sgml/: OpenBSD.sgml chips.sgml Revision ChangesPath 1.35 +3 -2 xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml 3.39 +31 -1 xc/programs/Xserver/hw/xfree86/doc/sgml/chips.sgml ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 17:43:14 Log message: Readability updates (#7424, Georgina Economou). Modified files: xc/programs/Xserver/hw/xfree86/doc/sgml/: SCO.sgml Revision ChangesPath 3.24 +28 -19xc/programs/Xserver/hw/xfree86/doc/sgml/SCO.sgml ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 17:47:39 Log message: update formatted docs Modified files: ./: BUILD Install README RELNOTES xc/programs/xkbcomp/: README.config README.enhancing xc/programs/Xserver/hw/xfree86/doc/: BUILD Install README README.OpenBSD README.SCO README.XKB-Config README.XKB-Enhancing README.apm README.ati README.chips RELNOTES Versions Revision ChangesPath 1.2 +1 -1 xc/BUILD 1.2 +2 -2 xc/Install 1.2 +1 -1 xc/README 1.45 +3 -3 xc/RELNOTES 1.7 +2 -2 xc/programs/xkbcomp/README.config 1.8 +3 -3 xc/programs/xkbcomp/README.enhancing 3.31 +1 -1 xc/programs/Xserver/hw/xfree86/doc/BUILD 1.35 +2 -2 xc/programs/Xserver/hw/xfree86/doc/Install 3.146 +1 -1 xc/programs/Xserver/hw/xfree86/doc/README 1.52 +2 -2 xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD 3.37 +29 -27xc/programs/Xserver/hw/xfree86/doc/README.SCO 1.7 +2 -2 xc/programs/Xserver/hw/xfree86/doc/README.XKB-Config 1.7 +3 -3 xc/programs/Xserver/hw/xfree86/doc/README.XKB-Enhancing 1.13 +2 -2 xc/programs/Xserver/hw/xfree86/doc/README.apm 3.67 +2 -2 xc/programs/Xserver/hw/xfree86/doc/README.ati 3.55 +62 -42xc/programs/Xserver/hw/xfree86/doc/README.chips 3.143 +3 -3 xc/programs/Xserver/hw/xfree86/doc/RELNOTES 1.15 +1 -1 xc/programs/Xserver/hw/xfree86/doc/Versions ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 19:06:02 Log message: Fix typo in writing out Module section. Modified files: xc/programs/Xserver/hw/xfree86/parser/: Module.c Revision ChangesPath 1.18 +2 -2 xc/programs/Xserver/hw/xfree86/parser/Module.c ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 19:08:27 Log message: 328. Fix server crash with -configure option (and -probe option) (Bugzilla #1546 Nicolas Joly, David Dawes). Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xfree86/common/: xf86Config.c xf86Init.c Revision ChangesPath 3.3437+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 3.286 +5 -1 xc/programs/Xserver/hw/xfree86/common/xf86Config.c 3.227 +6 -4 xc/programs/Xserver/hw/xfree86/common/xf86Init.c ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: test (branch: trunk)
CVSROOT:/home/x-cvs Module name:test Changes by: [EMAIL PROTECTED] 05/02/14 19:50:32 Log message: 20. XPROTO/changehost test not setting the host family when testing HostDelete (David Dawes). Modified files: test/xsuite/: CHANGELOG test/xsuite/xtest/tset/XPROTO/chnghsts/: chnghsts.m Revision ChangesPath 1.6 +3 -1 test/xsuite/CHANGELOG 1.2 +2 -1 test/xsuite/xtest/tset/XPROTO/chnghsts/chnghsts.m ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/02/14 20:07:55 Log message: Add DMX docs to the index. Modified files: xc/programs/Xserver/hw/xfree86/doc/sgml/: Imakefile add.sh Revision ChangesPath 3.89 +6 -1 xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile 1.4 +2 -2 xc/programs/Xserver/hw/xfree86/doc/sgml/add.sh ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
Problem restoring console?
I just updated on my dual-card system and with the update I see a problem restoring the console that I did not see previously. If I startx on the primary card and then quit, the primary card is restored correctly. However, if I startx on both cards and quit, the primary card is not restored correctly. I have a hard time imagining how it could be a driver issue since the nv driver knows nothing about the other cards in the layout (nor should it) and does not change its behavior when there is more than one card in the layout. The core server code, on the other hand, does. Have there been changes to vgahw, RAC, PCI config code, console code, etc... that may have caused this regression? Mark. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problem restoring console?
In case it wasn't clear, only dual-card layouts show the problem. I can start just the secondary card and the primary console will be restored correctly, likewise starting on only the primary card works fine. Only when starting on both cards will the primary console be restored incorrectly. This didn't happen before updating. MArk. On Mon, 14 Feb 2005, Mark Vojkovich wrote: I just updated on my dual-card system and with the update I see a problem restoring the console that I did not see previously. If I startx on the primary card and then quit, the primary card is restored correctly. However, if I startx on both cards and quit, the primary card is not restored correctly. I have a hard time imagining how it could be a driver issue since the nv driver knows nothing about the other cards in the layout (nor should it) and does not change its behavior when there is more than one card in the layout. The core server code, on the other hand, does. Have there been changes to vgahw, RAC, PCI config code, console code, etc... that may have caused this regression? Mark. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problem restoring console?
On Mon, Feb 14, 2005 at 04:00:18PM -0800, Mark Vojkovich wrote: I just updated on my dual-card system and with the update I see a problem restoring the console that I did not see previously. If I startx on the primary card and then quit, the primary card is restored correctly. However, if I startx on both cards and quit, the primary card is not restored correctly. I have a hard time imagining how it could be a driver issue since the nv driver knows nothing about the other cards in the layout (nor should it) and does not change its behavior when there is more than one card in the layout. The core server code, on the other hand, does. Have there been changes to vgahw, RAC, PCI config code, console code, etc... that may have caused this regression? Do you know approximately when this problem started? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problem restoring console?
On Mon, 14 Feb 2005, David Dawes wrote: On Mon, Feb 14, 2005 at 04:00:18PM -0800, Mark Vojkovich wrote: I just updated on my dual-card system and with the update I see a problem restoring the console that I did not see previously. If I startx on the primary card and then quit, the primary card is restored correctly. However, if I startx on both cards and quit, the primary card is not restored correctly. I have a hard time imagining how it could be a driver issue since the nv driver knows nothing about the other cards in the layout (nor should it) and does not change its behavior when there is more than one card in the layout. The core server code, on the other hand, does. Have there been changes to vgahw, RAC, PCI config code, console code, etc... that may have caused this regression? Do you know approximately when this problem started? I haven't updated in a long time on that machine. I'll try to figure out when, but I'm not sure how to do that reliably. Mark. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problem restoring console?
On Mon, 14 Feb 2005, Mark Vojkovich wrote: On Mon, 14 Feb 2005, David Dawes wrote: On Mon, Feb 14, 2005 at 04:00:18PM -0800, Mark Vojkovich wrote: I just updated on my dual-card system and with the update I see a problem restoring the console that I did not see previously. If I startx on the primary card and then quit, the primary card is restored correctly. However, if I startx on both cards and quit, the primary card is not restored correctly. I have a hard time imagining how it could be a driver issue since the nv driver knows nothing about the other cards in the layout (nor should it) and does not change its behavior when there is more than one card in the layout. The core server code, on the other hand, does. Have there been changes to vgahw, RAC, PCI config code, console code, etc... that may have caused this regression? Do you know approximately when this problem started? I haven't updated in a long time on that machine. I'll try to figure out when, but I'm not sure how to do that reliably. I can't tell when I last updated on this machine. Mark. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problem restoring console?
On Mon, Feb 14, 2005 at 07:40:40PM -0800, Mark Vojkovich wrote: On Mon, 14 Feb 2005, Mark Vojkovich wrote: On Mon, 14 Feb 2005, David Dawes wrote: On Mon, Feb 14, 2005 at 04:00:18PM -0800, Mark Vojkovich wrote: I just updated on my dual-card system and with the update I see a problem restoring the console that I did not see previously. If I startx on the primary card and then quit, the primary card is restored correctly. However, if I startx on both cards and quit, the primary card is not restored correctly. I have a hard time imagining how it could be a driver issue since the nv driver knows nothing about the other cards in the layout (nor should it) and does not change its behavior when there is more than one card in the layout. The core server code, on the other hand, does. Have there been changes to vgahw, RAC, PCI config code, console code, etc... that may have caused this regression? Do you know approximately when this problem started? I haven't updated in a long time on that machine. I'll try to figure out when, but I'm not sure how to do that reliably. I can't tell when I last updated on this machine. Can you go back to 4.4 as a first step, or do you know it was post-4.4? I tried 4.5.0 RC1 with a multi-head config using a Mach64 and i810, and didn't see any problem like this. I can try some other multi-head configs later this week. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
[XFree86] Problem: DRI is very slow, glxgears is faster w/o DRI enabled. (i855GM)
Hi,
I'm trying set up DRI properly on i855GM. I have installed
ii xserver-xfree8 4.3.0.dfsg.1-8 the XFree86 X server
ii xlibmesa-dri 4.3.0.dfsg.1-1 Mesa 3D graphics library modules [XFree86]
ii xlibmesa-gl4.3.0.dfsg.1-1 Mesa 3D graphics library [XFree86]
ii xlibmesa-gl-db 4.3.0.dfsg.1-1 Mesa 3D graphics library (unstripped) [XFree
ii xlibmesa-gl-de 4.3.0.dfsg.1-1 Mesa 3D graphics library development files [
ii xlibmesa-glu 4.3.0.dfsg.1-8 Mesa OpenGL utility library [XFree86]
ii xlibmesa-glu-d 4.3.0.dfsg.1-1 Mesa OpenGL utility library (unstripped) [XF
ii xlibmesa-glu-d 4.3.0.dfsg.1-8 Mesa OpenGL utility library development file
ii xlibosmesa-dev 4.3.0.dfsg.1-1 Mesa off-screen rendering library developmen
ii xlibosmesa44.3.0.dfsg.1-1 Mesa off-screen rendering library [XFree86]
ii xlibosmesa4-db 4.3.0.dfsg.1-1 Mesa off-screen rendering library (unstrippe
I have also have the following enabled in the kernel
Linux dsl-202-173-141-208.sa.westnet.com.au 2.4.29 #9 9 23:42:05 CST
2005 i686 GNU/Linux
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_DRM=y
CONFIG_DRM_NEW=y
CONFIG_DRM_I830=m
Now the problem:
With DRM support enabled ('glxinfo' says 'yes') i have only ~100fps
according to 'glxgears' :-( while when I disable DRM support I get
~450fps.
I have also tried to replace the agpgart.o and i830.o from the kernel by
the same modules from Xfree86 source tree --- the same problem.
May be someone met such a problem, share ideas, please, or may be there
is a tool to track down the place where the rendering is slowed down?
Thanks in advance,
D.
___
XFree86 mailing list
XFree86@XFree86.Org
http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] switch display between two monitors
Hello. Is there a possibility to switch a display to an other CRT/TV (device) by key-combination? I think of a VT My graficscard (GTS2) has no twinview (only one DAC), but tv-out (s-video) The device option ConnectedMonitor TV should work with driver nvidia for the s-video output. Can I and if possible how can I configure two VTs with that devices? (CRT and TV) Otherwise I'll write a script to choose the output on startup, but there isn't then a possibility to switch. I'll write your answer to LinuxQuestions.org I hope you can give me a positive answer. Many thanks sebastian nvidia options: Option ConnectedMonitor TV Option TVOutFormat SVIDEO Option TVStandard PAL-B What's in XFree86.0.log : (II) Setting vga for screen 0. (**) NVIDIA(0): Depth 16, (--) framebuffer bpp 16 (==) NVIDIA(0): RGB weight 565 (==) NVIDIA(0): Default visual is TrueColor (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) (--) NVIDIA(0): Linear framebuffer at 0xE000 (--) NVIDIA(0): MMIO registers at 0xEC00 (II) NVIDIA(0): NVIDIA GPU detected as: GeForce2 GTS/GeForce2 Pro (--) NVIDIA(0): VideoBIOS: 02.15.01.14.00 (--) NVIDIA(0): Interlaced video modes are supported on this GPU (II) NVIDIA(0): Detected AGP rate: 2X (--) NVIDIA(0): VideoRAM: 32768 kBytes (II) NVIDIA(0): Connected display device(s): CRT-0, TV-0 (WW) NVIDIA(0): Multiple displays connected, but only one display allowed; (WW) NVIDIA(0): using first display (--) NVIDIA(0): Display device CRT-0: maximum pixel clock at 8 bpp: 350 MHz (--) NVIDIA(0): Display device CRT-0: maximum pixel clock at 16 bpp: 350 MHz (--) NVIDIA(0): Display device CRT-0: maximum pixel clock at 32 bpp: 300 MHz ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Odd Screen Overlap
At 10:40 -0500 2/14/05, Carl F. Hall wrote: I have an overlap at the bottom of the screen that is a copy of the first 10-15 pixels of the top of the screen. I'm running at 1280x1024. When I switch to 1024x768, the problem doesn't show. I've tried adjusting the monitor but there are useful things, namely the status bar, behind that overlap. Sounds like a typical hardware problem. The internal adjustment in your monitor is probably called vertical phase. The monitor is failing to synch tightly to the vertical synch pulses form the video card when the rate is pushed too high. If you're lucky it's just an internal adjustment but it's more-often due to change in value of a capacitor on the printed circuit board. I doubt that those pixels are actually copies but if they are I'm all wrong. The video card would have to be thoroughly messed up to send some pixels twice. It's extremely rare for that kind of problem to originate in a video card. -- -- There are 10 kinds of people: those who understand binary, and those who don't -- ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Odd Screen Overlap
On Mon, 14 Feb 2005, Carl F. Hall wrote: Hi all, I've been working in XFree86 4.3 on Debian for a while with no problems. I opted to change my system time using the clock panel thingy and upon saving my changes, the screen went off then on again and I have an overlap at the bottom of the screen that is a copy of the first 10-15 pixels of the top of the screen. I'm running at 1280x1024. When I switch to 1024x768, the problem doesn't show. I've tried adjusting the monitor but there are useful things, namely the status bar, behind that overlap. Any thoughts?? I believe that these lines in the logfile: GetModeLine - scrn: 0 clock: 108000 GetModeLine - hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688 vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5 GetModeLine - scrn: 0 clock: 108000 GetModeLine - hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688 vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5 GetModeLine - scrn: 0 clock: 108000 GetModeLine - hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688 vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5 indicates that some application explicitly changed the modeline through the XF86VidMode extension. One app that I know of that does this is X-Screensaver. My guess is that when you changed your system time, there was some confusion about when the screensaver should come on and the screensaver came on and switched modelines somehow. I assume that quiting and restarting X resolves this problem? Mark. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Odd Screen Overlap
Thanks for the responses on this. It's made for an interesting day at work having to read around the overlap. I've tried rebooting the machine as well as a complete shutdown and still get the same thing. When I try different resolutions (1024x768, 1280x962, etc) the overlaop goes away. Should I check into setting the vertical sync rate and , if so, how do I know what is the right one for my monitor? Mark Vojkovich wrote: On Mon, 14 Feb 2005, Carl F. Hall wrote: Hi all, I've been working in XFree86 4.3 on Debian for a while with no problems. I opted to change my system time using the clock panel thingy and upon saving my changes, the screen went off then on again and I have an overlap at the bottom of the screen that is a copy of the first 10-15 pixels of the top of the screen. I'm running at 1280x1024. When I switch to 1024x768, the problem doesn't show. I've tried adjusting the monitor but there are useful things, namely the status bar, behind that overlap. Any thoughts?? I believe that these lines in the logfile: GetModeLine - scrn: 0 clock: 108000 GetModeLine - hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688 vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5 GetModeLine - scrn: 0 clock: 108000 GetModeLine - hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688 vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5 GetModeLine - scrn: 0 clock: 108000 GetModeLine - hdsp: 1280 hbeg: 1328 hend: 1440 httl: 1688 vdsp: 1024 vbeg: 1025 vend: 1028 vttl: 1066 flags: 5 indicates that some application explicitly changed the modeline through the XF86VidMode extension. One app that I know of that does this is X-Screensaver. My guess is that when you changed your system time, there was some confusion about when the screensaver should come on and the screensaver came on and switched modelines somehow. I assume that quiting and restarting X resolves this problem? Mark. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.306 / Virus Database: 265.8.7 - Release Date: 2/10/2005 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Odd Screen Overlap
I have an LCD monitor that does auto adjustments based on the input and not a lot, but some, adjusting I can do manually outside of color and contrast. Other resolutions seem to work fine so I can't agree with the hardware assessment but I'm not informed enough on the area to completely disagree. Is there anything I can change in the config to change the vertical synch pulses and maybe fix it that way? Doug McNutt wrote: At 10:40 -0500 2/14/05, Carl F. Hall wrote: I have an overlap at the bottom of the screen that is a copy of the first 10-15 pixels of the top of the screen. I'm running at 1280x1024. When I switch to 1024x768, the problem doesn't show. I've tried adjusting the monitor but there are useful things, namely the status bar, behind that overlap. Sounds like a typical hardware problem. The internal adjustment in your monitor is probably called vertical phase. The monitor is failing to synch tightly to the vertical synch pulses form the video card when the rate is pushed too high. If you're lucky it's just an internal adjustment but it's more-often due to change in value of a capacitor on the printed circuit board. I doubt that those pixels are actually copies but if they are I'm all wrong. The video card would have to be thoroughly messed up to send some pixels twice. It's extremely rare for that kind of problem to originate in a video card. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.306 / Virus Database: 265.8.7 - Release Date: 2/10/2005 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Odd Screen Overlap
The monitor's EDID (printed out in the logfile) indicates a prefered mode, which implies the native panel resolution is 1280x1024. It also specifies a vertical sync range of 56-76 Hz and horizontal range of 30-80 kHz (you have 50-75 and 30-65 in your XF86Config). XFree86 chose a [EMAIL PROTECTED] (64KHz) VESA mode with an identical refresh rate to the prefered mode in the EDID. In short, the mode XFree86 chose should have worked, and it sounds like it did at one time, so I guess we can't rule out a hardware issue. You can try changing the sync pulses. It's using the following modeline now: Modeline 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync If you put that line in the Section Monitor XFree86 will use it instead of the internal one. You can change the pulses by changing the +/- before the hsync and/or vsync. You also might want to check your monitor cable to make sure it's plugged in tightly. If this doesn't work you could try lowering that pixel clock (the 108.00) a bit to see if it works any better (eg. something between 102 and 108). Does your video card have a DVI connector? If you use it you will be bypassing your monitor's analog circuitry. Mark. On Mon, 14 Feb 2005, Carl F. Hall wrote: I have an LCD monitor that does auto adjustments based on the input and not a lot, but some, adjusting I can do manually outside of color and contrast. Other resolutions seem to work fine so I can't agree with the hardware assessment but I'm not informed enough on the area to completely disagree. Is there anything I can change in the config to change the vertical synch pulses and maybe fix it that way? Doug McNutt wrote: At 10:40 -0500 2/14/05, Carl F. Hall wrote: I have an overlap at the bottom of the screen that is a copy of the first 10-15 pixels of the top of the screen. I'm running at 1280x1024. When I switch to 1024x768, the problem doesn't show. I've tried adjusting the monitor but there are useful things, namely the status bar, behind that overlap. Sounds like a typical hardware problem. The internal adjustment in your monitor is probably called vertical phase. The monitor is failing to synch tightly to the vertical synch pulses form the video card when the rate is pushed too high. If you're lucky it's just an internal adjustment but it's more-often due to change in value of a capacitor on the printed circuit board. I doubt that those pixels are actually copies but if they are I'm all wrong. The video card would have to be thoroughly messed up to send some pixels twice. It's extremely rare for that kind of problem to originate in a video card. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.306 / Virus Database: 265.8.7 - Release Date: 2/10/2005 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Block unwanted focus
Typing a text in a window when one event tranfer the focus to other window. There are another way to force the focus only by click ? Thanks, Gilmar. Estou digitando o texto em uma janela quando um evento cede a outra janela inadvertidamente o foco. Existe uma forma de forcar o foco ao clique, isto é, a janela só tem o foco após um clique ? Grato, Gilmar. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] X Free On FOSA 8500V Notebook
I am trying to RedHat 9.0 on a FOSA 8500V notebook and I cannot get XFREE configured correctly. At boot time the video appears to be VIA Apollo Pro133AX with 16Meg of video ram. I can do the install using graphics with no problem but cannot get X to start when the installation completes. The boot shows video bios is shadowed. The XF386Config shows a Generic Laptop Display Panel 1024x768. The Videocard shows as a ATI Rage 128 Mobility with 16384 of video memory. When I check the error file it shows a monitor of Hitachi TX38D95VC1CAA Color, Single, TFT Screen(s) found but none have a usable configuration. attachment: image001.jpg
[XFree86] log file
This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org 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.0.1 Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.6.3-3mdkenterprise i686 [ELF] Build Date: 24 March 2004 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: Tue Feb 15 12:01:30 2005 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout layout1 (**) |--Screen screen1 (0) (**) | |--Monitor monitor1 (**) | |--Device device1 (**) |--Input Device Keyboard1 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout en_US (**) XKB: layout: en_US (WW) Option XkbOptions requires an string value (==) Keyboard: CustomKeycode disabled (**) |--Input Device Mouse1 (**) FontPath set to unix/:-1 (==) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (**) Option AllowMouseOpenFail (++) 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.1, 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.1, 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 = 0x80008d48, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3189 card 1458,5000 rev 00 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b168 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:0c:0: chip 10ec,8139 card 10ec,8139 rev 10 class 02,00,00 hdr 00 (II) PCI: 00:10:0: chip 1106,3038 card 1458,5004 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:1: chip 1106,3038 card 1458,5004 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:2: chip 1106,3038 card 1458,5004 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:3: chip 1106,3104 card 1458,5004 rev 82 class 0c,03,20 hdr 00 (II) PCI: 00:11:0: chip 1106,3177 card 1458,5001 rev 00 class 06,01,00 hdr 80 (II) PCI: 00:11:1: chip 1106,0571 card 1458,5002 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:11:5: chip 1106,3059 card 1458,a002 rev 50 class 04,01,00 hdr 00 (II) PCI: 01:00:0: chip 10de,0332 card , rev a1 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: 0x000c (VGA_EN is set) (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xe000 - 0xe1ff (0x200) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xd800 - 0xdfff (0x800) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:17:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(1:0:0) nVidia Corporation unknown chipset (0x0332) rev 161, Mem @ 0xe000/24, 0xd800/27 (II) Addressable bus resource ranges are [0] -1 0 0x - 0x (0x0) MX[B] [1] -1 0 0x - 0x (0x1) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffe0 - 0x (0x20) MX[B](B) [1] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [2] -1 0 0x000f - 0x000f (0x1) MX[B] [3] -1 0 0x000c - 0x000e (0x3) MX[B] [4] -1 0 0x - 0x0009 (0xa) MX[B] [5] -1 0 0x - 0x (0x1) IX[B] [6] -1 0 0x - 0x00ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xd000 from 0xd7ff to 0xcfff (II) Active PCI resource ranges: [0] -1 0 0xe3001000 - 0xe30010ff (0x100) MX[B] [1] -1 0 0xe300 - 0xe3ff (0x100) MX[B] [2] -1 0 0xd000 - 0xcfff (0x0) MX[B]O [3] -1 0 0xd800 - 0xdfff (0x800) MX[B](B) [4] -1 0 0xe000 - 0xe0ff (0x100) MX[B](B) [5] -1 0
[XFree86] External CRT works on 1024x768 but LCD not. Please Help!!!
Hi, Can someone help me, please!? I have a Compal CY27 laptop. The graphics chipset is (as reported by lspci): :00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) :00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) I read all material on the net about the memory/vbios problems with this chipset. I do not think I have this problem because I can change the memory allocated to the graphics card in the BIOS setup program, and the XFree output reflects these changes. I have tried all kinds of patchs, all the latest XFree versions available (including 4.4.0), several distros (FC1, FC2, Mandrake 10 and now, Debian unstable), the IBM driver, asked the dealer and manufacturer for a BIOS update, but my LCD never reaches 1024x768 (only 800x600 and 640x480). Actually, a few months ago, I gave out trying to make the LCD work under 1024x768, after all this dozens of failed trials. I am getting back to this because I just find out that, if I connect a external CRT monitor (actually a Samsung SyncMaster 700p) to the CRT out of my laptop, 1024x768 works on it! I am completely puzzled. If XFree can make the external monitor works on 1024x768, why it can not do the same with the LCD? I was told that my graphics chipset has a vbios problem that prevents Xfree from recognizing its ability to work under 1024x768, but, if this is true, why that external CRT works under 1024x768? I must note that under WinXP the LCD works on 1024x768 and that the XiG X server can also do the same. Now that it is clear that Xfree can produce 1024x768 with my chipset and my LCD supports 1024x768, how can I force Xfree to try 1024x768 on the LCD? My XF86Config-4 can be found here: http://paginas.terra.com.br/educacao/nqnsome/xf86config.txt The XFree output can be found here: http://paginas.terra.com.br/educacao/nqnsome/xfree_output.txt I am really sorry for my bad English. Thanks a lot for your assistance. Regards, Sergio ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Odd Screen Overlap - Fixed
Thanks for the suggestions Mark. I changed the vert sync range and horiz. range to the those you said were in the log file for the monitor's EDID. After doing so, I still had the problem but now have available 75Hz along w/ 60Hz. I didn't think my monitor worked at anything by 60 but whatever. So I selected 75Hz and the overlap went away! If this will detremental to my monitor, someone please let me know. Otherwise, I'm going to keep on going with it. Thanks again for all of the very knowledgeable help. _Carl Mark Vojkovich wrote: The monitor's EDID (printed out in the logfile) indicates a prefered mode, which implies the native panel resolution is 1280x1024. It also specifies a vertical sync range of 56-76 Hz and horizontal range of 30-80 kHz (you have 50-75 and 30-65 in your XF86Config). XFree86 chose a [EMAIL PROTECTED] (64KHz) VESA mode with an identical refresh rate to the prefered mode in the EDID. In short, the mode XFree86 chose should have worked, and it sounds like it did at one time, so I guess we can't rule out a hardware issue. You can try changing the sync pulses. It's using the following modeline now: Modeline 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync If you put that line in the Section Monitor XFree86 will use it instead of the internal one. You can change the pulses by changing the +/- before the hsync and/or vsync. You also might want to check your monitor cable to make sure it's plugged in tightly. If this doesn't work you could try lowering that pixel clock (the 108.00) a bit to see if it works any better (eg. something between 102 and 108). Does your video card have a DVI connector? If you use it you will be bypassing your monitor's analog circuitry. Mark. On Mon, 14 Feb 2005, Carl F. Hall wrote: I have an LCD monitor that does auto adjustments based on the input and not a lot, but some, adjusting I can do manually outside of color and contrast. Other resolutions seem to work fine so I can't agree with the hardware assessment but I'm not informed enough on the area to completely disagree. Is there anything I can change in the config to change the vertical synch pulses and maybe fix it that way? Doug McNutt wrote: At 10:40 -0500 2/14/05, Carl F. Hall wrote: I have an overlap at the bottom of the screen that is a copy of the first 10-15 pixels of the top of the screen. I'm running at 1280x1024. When I switch to 1024x768, the problem doesn't show. I've tried adjusting the monitor but there are useful things, namely the status bar, behind that overlap. Sounds like a typical hardware problem. The internal adjustment in your monitor is probably called vertical phase. The monitor is failing to synch tightly to the vertical synch pulses form the video card when the rate is pushed too high. If you're lucky it's just an internal adjustment but it's more-often due to change in value of a capacitor on the printed circuit board. I doubt that those pixels are actually copies but if they are I'm all wrong. The video card would have to be thoroughly messed up to send some pixels twice. It's extremely rare for that kind of problem to originate in a video card. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.306 / Virus Database: 265.8.7 - Release Date: 2/10/2005 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.306 / Virus Database: 265.8.7 - Release Date: 2/10/2005 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Odd Screen Overlap - Fixed
On Mon, 14 Feb 2005, Carl F. Hall wrote: Thanks for the suggestions Mark. I changed the vert sync range and horiz. range to the those you said were in the log file for the monitor's EDID. After doing so, I still had the problem but now have available 75Hz along w/ 60Hz. I didn't think my monitor worked at anything by 60 but whatever. So I selected 75Hz and the overlap went away! If this will detremental to my monitor, someone please let me know. Otherwise, I'm going to keep on going with it. As long as you have the correct ranges 56-76 vertical, 30-80 Horizontal in the Section Monitor you should be OK. Those were taken from the monitor's EDID (plug and play info). The EDID claims it's a DELL 1701FP. The manufacturer's specifications: http://support.dell.com/support/edocs/monitors/04pjr/en/specs.htm claim that it can do [EMAIL PROTECTED] Mark. Thanks again for all of the very knowledgeable help. _Carl Mark Vojkovich wrote: The monitor's EDID (printed out in the logfile) indicates a prefered mode, which implies the native panel resolution is 1280x1024. It also specifies a vertical sync range of 56-76 Hz and horizontal range of 30-80 kHz (you have 50-75 and 30-65 in your XF86Config). XFree86 chose a [EMAIL PROTECTED] (64KHz) VESA mode with an identical refresh rate to the prefered mode in the EDID. In short, the mode XFree86 chose should have worked, and it sounds like it did at one time, so I guess we can't rule out a hardware issue. You can try changing the sync pulses. It's using the following modeline now: Modeline 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync If you put that line in the Section Monitor XFree86 will use it instead of the internal one. You can change the pulses by changing the +/- before the hsync and/or vsync. You also might want to check your monitor cable to make sure it's plugged in tightly. If this doesn't work you could try lowering that pixel clock (the 108.00) a bit to see if it works any better (eg. something between 102 and 108). Does your video card have a DVI connector? If you use it you will be bypassing your monitor's analog circuitry. Mark. On Mon, 14 Feb 2005, Carl F. Hall wrote: I have an LCD monitor that does auto adjustments based on the input and not a lot, but some, adjusting I can do manually outside of color and contrast. Other resolutions seem to work fine so I can't agree with the hardware assessment but I'm not informed enough on the area to completely disagree. Is there anything I can change in the config to change the vertical synch pulses and maybe fix it that way? Doug McNutt wrote: At 10:40 -0500 2/14/05, Carl F. Hall wrote: I have an overlap at the bottom of the screen that is a copy of the first 10-15 pixels of the top of the screen. I'm running at 1280x1024. When I switch to 1024x768, the problem doesn't show. I've tried adjusting the monitor but there are useful things, namely the status bar, behind that overlap. Sounds like a typical hardware problem. The internal adjustment in your monitor is probably called vertical phase. The monitor is failing to synch tightly to the vertical synch pulses form the video card when the rate is pushed too high. If you're lucky it's just an internal adjustment but it's more-often due to change in value of a capacitor on the printed circuit board. I doubt that those pixels are actually copies but if they are I'm all wrong. The video card would have to be thoroughly messed up to send some pixels twice. It's extremely rare for that kind of problem to originate in a video card. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.306 / Virus Database: 265.8.7 - Release Date: 2/10/2005 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.306 / Virus Database: 265.8.7 - Release Date: 2/10/2005 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Odd Screen Overlap - Fixed
I tried looking around for those specs yesterday but didn't find the page you've noted. I'll be sure to note the document. Everything is back to normal now and work can proceed (and there was much rejoicing, 'yy') Mark Vojkovich wrote: On Mon, 14 Feb 2005, Carl F. Hall wrote: Thanks for the suggestions Mark. I changed the vert sync range and horiz. range to the those you said were in the log file for the monitor's EDID. After doing so, I still had the problem but now have available 75Hz along w/ 60Hz. I didn't think my monitor worked at anything by 60 but whatever. So I selected 75Hz and the overlap went away! If this will detremental to my monitor, someone please let me know. Otherwise, I'm going to keep on going with it. As long as you have the correct ranges 56-76 vertical, 30-80 Horizontal in the Section Monitor you should be OK. Those were taken from the monitor's EDID (plug and play info). The EDID claims it's a DELL 1701FP. The manufacturer's specifications: http://support.dell.com/support/edocs/monitors/04pjr/en/specs.htm claim that it can do [EMAIL PROTECTED] Mark. Thanks again for all of the very knowledgeable help. _Carl Mark Vojkovich wrote: The monitor's EDID (printed out in the logfile) indicates a prefered mode, which implies the native panel resolution is 1280x1024. It also specifies a vertical sync range of 56-76 Hz and horizontal range of 30-80 kHz (you have 50-75 and 30-65 in your XF86Config). XFree86 chose a [EMAIL PROTECTED] (64KHz) VESA mode with an identical refresh rate to the prefered mode in the EDID. In short, the mode XFree86 chose should have worked, and it sounds like it did at one time, so I guess we can't rule out a hardware issue. You can try changing the sync pulses. It's using the following modeline now: Modeline 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync If you put that line in the Section Monitor XFree86 will use it instead of the internal one. You can change the pulses by changing the +/- before the hsync and/or vsync. You also might want to check your monitor cable to make sure it's plugged in tightly. If this doesn't work you could try lowering that pixel clock (the 108.00) a bit to see if it works any better (eg. something between 102 and 108). Does your video card have a DVI connector? If you use it you will be bypassing your monitor's analog circuitry. Mark. On Mon, 14 Feb 2005, Carl F. Hall wrote: I have an LCD monitor that does auto adjustments based on the input and not a lot, but some, adjusting I can do manually outside of color and contrast. Other resolutions seem to work fine so I can't agree with the hardware assessment but I'm not informed enough on the area to completely disagree. Is there anything I can change in the config to change the vertical synch pulses and maybe fix it that way? Doug McNutt wrote: At 10:40 -0500 2/14/05, Carl F. Hall wrote: I have an overlap at the bottom of the screen that is a copy of the first 10-15 pixels of the top of the screen. I'm running at 1280x1024. When I switch to 1024x768, the problem doesn't show. I've tried adjusting the monitor but there are useful things, namely the status bar, behind that overlap. Sounds like a typical hardware problem. The internal adjustment in your monitor is probably called vertical phase. The monitor is failing to synch tightly to the vertical synch pulses form the video card when the rate is pushed too high. If you're lucky it's just an internal adjustment but it's more-often due to change in value of a capacitor on the printed circuit board. I doubt that those pixels are actually copies but if they are I'm all wrong. The video card would have to be thoroughly messed up to send some pixels twice. It's extremely rare for that kind of problem to originate in a video card. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.306 / Virus Database: 265.8.7 - Release Date: 2/10/2005 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.306 / Virus Database: 265.8.7 - Release Date: 2/10/2005 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 -- Carl F. Hall [EMAIL PROTECTED] I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use. Galileo -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.306 / Virus Database: 265.8.7 -
[XFree86] Re:
o o! a o a a ao o -a a, , o, , o , a a a . a a oa a a-, a, o , a a o oo . o a o a a o o o. a, I0 a. . o . . o, I9 /a (232) 99-9 www.vodnik.l00Osize.ru e-mail: [EMAIL PROTECTED] P.S. o o oo. o oao ao oo a - .
