CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/09 00:55:51 Log message: Fix for Asus L3000D (740+Chrontel 7019) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init301.c init301.h initdef.h sis.h sis_driver.h vstruct.h Revision ChangesPath 1.37 +54 -37xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.27 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.h 1.20 +2 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/initdef.h 1.73 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.22 +7 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.h 1.18 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/vstruct.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/09 01:30:57 Log message: Remove DDC Sync range substitution; now done by common layer Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis_driver.c Revision ChangesPath 1.138 +10 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/09 04:44:00 Log message: 496. Added USB keyboard support for Solaris/x86 platform (Bugzilla #352, Daniel Rock). Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xfree86/common/: atKeynames.h xc/programs/Xserver/hw/xfree86/os-support/sunos/: sun_kbd.c sun_kbdEv.c Revision ChangesPath 3.2877+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 3.21 +17 -1 xc/programs/Xserver/hw/xfree86/common/atKeynames.h 1.2 +4 -3 xc/programs/Xserver/hw/xfree86/os-support/sunos/sun_kbd.c 1.6 +252 -2xc/programs/Xserver/hw/xfree86/os-support/sunos/sun_kbdEv.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/09 04:45:27 Log message: 496. Added USB keyboard support for Solaris/x86 platform (Bugzilla #352, Daniel Rock). Modified files: xc/programs/xkbcomp/keycodes/: xfree86 xc/programs/xkbcomp/symbols/sun/: Imakefile Added files: xc/programs/xkbcomp/symbols/sun/: usb Revision ChangesPath 3.26 +20 -4 xc/programs/xkbcomp/keycodes/xfree86 1.6 +2 -2 xc/programs/xkbcomp/symbols/sun/Imakefile ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/09 05:40:57 Log message: 497. Add an xf86InitFBManagerLinear() function and implement the Linear allocation routines. These still fallback to XY area allocation if no (or the lack of) linear space is available. It assumes the driver has already called one of the init routines to the FBManager for Areas before this new setup can be used. Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xfree86/common/: xf86fbman.c xf86fbman.h xc/programs/Xserver/hw/xfree86/loader/: xf86sym.c Revision ChangesPath 3.2878+6 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.26 +231 -52 xc/programs/Xserver/hw/xfree86/common/xf86fbman.c 1.14 +8 -1 xc/programs/Xserver/hw/xfree86/common/xf86fbman.h 1.239 +2 -1 xc/programs/Xserver/hw/xfree86/loader/xf86sym.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/09 15:06:37 Log message: Factorize the LinkBuildSonameLibrary() macro move it to Imake.rules. It used to be the same in all files. Moreover it had the 2 same bugs (failing to create $BUILDLIBDIR if not already there and using $BUILDINCTOP instead of $BUILDLIBTOP) in all instances. Modified files: xc/config/cf/: OpenBSDLib.rules bsdLib.rules bsdiLib.rules darwinLib.rules gnuLib.rules lnxLib.rules os2Lib.rules nto.rules Imake.rules Revision ChangesPath 1.7 +1 -7 xc/config/cf/OpenBSDLib.rules 3.21 +1 -8 xc/config/cf/bsdLib.rules 3.2 +1 -8 xc/config/cf/bsdiLib.rules 1.7 +1 -30 xc/config/cf/darwinLib.rules 1.7 +1 -19 xc/config/cf/gnuLib.rules 3.48 +1 -30 xc/config/cf/lnxLib.rules 3.17 +1 -8 xc/config/cf/os2Lib.rules 1.6 +1 -19 xc/config/cf/nto.rules 3.122 +13 -1 xc/config/cf/Imake.rules ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/09 15:43:20 Log message: Revert previous. It still has some issues. Modified files: xc/config/cf/: OpenBSDLib.rules bsdLib.rules bsdiLib.rules darwinLib.rules gnuLib.rules lnxLib.rules os2Lib.rules nto.rules Imake.rules Revision ChangesPath 1.8 +7 -1 xc/config/cf/OpenBSDLib.rules 3.22 +8 -1 xc/config/cf/bsdLib.rules 3.3 +8 -1 xc/config/cf/bsdiLib.rules 1.8 +30 -1 xc/config/cf/darwinLib.rules 1.8 +19 -1 xc/config/cf/gnuLib.rules 3.49 +30 -1 xc/config/cf/lnxLib.rules 3.18 +8 -1 xc/config/cf/os2Lib.rules 1.7 +19 -1 xc/config/cf/nto.rules 3.123 +1 -13 xc/config/cf/Imake.rules ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/09 16:42:32 Log message: Fix compile problems from Mesa merge. Modified files: xc/lib/GL/apple/: Imakefile dri_dispatch.defs dri_dispatch.h dri_glx.h Revision ChangesPath 1.2 +3 -2 xc/lib/GL/apple/Imakefile 1.2 +0 -1 xc/lib/GL/apple/dri_dispatch.defs 1.2 +0 -5 xc/lib/GL/apple/dri_dispatch.h 1.2 +0 -3 xc/lib/GL/apple/dri_glx.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
How to kick off a accelerate draw operation in source code
Hi all, I am writing a customerized graphic card driver in xfree86, and I refered to NV dirver, I can find that NVSetupForSolidLine and NVSubsequentSolidHorVertLine .. functions to manipulate the HW register, I wonder that it is just filling some data in the registers, I want to know when and which instruction kick off the draw operation. Please give me some clue. _ MSN Hotmail http://www.hotmail.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Alt+Tab make
I want to make a function like the Alt+Tab where various windows (Xwindow server) will come in front. The window maybe written in Qwidget, simple widget, or simple Xwindow Api. Any ideas or correspond source to see? Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: What about a kernel module?
Juliusz Chroboczek wrote: AC (Of course, we do this somewhat on Solaris/sparc, Do you document the interface ? Partially - the generic interfaces all frame buffer drivers support are documented in the fbio(7) man page (available online at http://docs.sun.com/ ) and some frame buffer drivers document additional extensions in their man pages. For most of the newer frame buffers though, I believe the details of the more interesting bits are undocumented, private interfaces between the driver, the DDX module, and the OpenGL pipeline module. (All three of those come from our graphics hardware group, not the group I work in, which handles the device-independent parts of X for Solaris, so I don't know all the details.) -- -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: How to render multiple cursors?
Why would you want more than one pointer? and more importantly how would it be used? I wonder if you are not making life more difficult than it needs to be. Actually the more I think about the more I really want to know the answer to thoes two questions. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 4.4 reminder
This is a reminder that the XFree86 4.4 release is planned for mid December 2003, with 15 October 2003 being the final date for the submission of new features. See the release plans page on our web site for further details of the schedule http://www.xfree86.org/releaseplans.html. The 4.3.99.14 development snapshot scheduled for 10 October 2003 will the the last of the automatically generated snapshots in this release cycle. Subsequent snapshots will be generated manually as required until the 4.4 release. Automatically generated snapshots will resume again shortly after the release. As usual, check our development snapshots web page for information about the latest available XFree86 development snapshot http://www.xfree86.org/develsnaps/. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC Marking private symbols in XFree86 shared libraries as private
Jakub Jelinek wrote: 1) could be done by some header which everything uses, doing #if defined HAVE_VISIBILITY_ATTRIBUTE defined __PIC__ #define hidden __attribute__((visibility (hidden))) #else #define hidden /**/ #endif and write prototypes like: void hidden someshlibprivateroutine (void); extern int someshlibprivatevar hidden; etc. I sent you a message about this before (in reference to libGL.so), but I never heard back from you. I think this is a very good idea! I would prefer it if __HIDDEN__ or HIDDEN or something similar were used. That makes it stand out more. Also, is there any reason to not have the symbols be hidden in non-PIC mode? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC Marking private symbols in XFree86 shared libraries as private
On Thu, Oct 09, 2003 at 02:05:47PM +0200, Jakub Jelinek wrote: Looking at various /usr/X11R6/lib/lib*.so* shared libraries, I'm seeing lots of exported symbols which look like they are exported just because they cannot be static (as they are used by some other .o files in the same shared library, but never by anything outside). That is correct. If these could be classified (e.g. some _X* symbols in libX11.so.6, some _Ice* symbols in libICE.so.6 etc. might fall into this category), XFree86 could have smaller and faster shared libraries with less dynamic relocations, which would not need to set up PIC pointer so often and use less instructions to access shared library local variables (by bypassing GOT on some arches). ... and it would discourage applications from using symbols that aren't part of the published interfaces. I'd suggest starting with the library interface specs, exporting only those symbols that are documented as part of the interfaces, and seeing what applications break. If a signficant number of applications do break, that might suggest adjusting the specs to agree with common usage. I had plans of doing this with a linker version script, but it's still fairly low down on my todo list. From an API point of view, I think it would be better to specify the symbols that should be public, rather than identifying all non-statics that shouldn't be. It'd also be good if this could be implemented for as many of the platforms we support as possible. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC Marking private symbols in XFree86 shared libraries as private
On Thu, Oct 09, 2003 at 12:08:55PM -0400, David Dawes wrote: On Thu, Oct 09, 2003 at 02:05:47PM +0200, Jakub Jelinek wrote: Looking at various /usr/X11R6/lib/lib*.so* shared libraries, I'm seeing lots of exported symbols which look like they are exported just because they cannot be static (as they are used by some other .o files in the same shared library, but never by anything outside). That is correct. If these could be classified (e.g. some _X* symbols in libX11.so.6, some _Ice* symbols in libICE.so.6 etc. might fall into this category), XFree86 could have smaller and faster shared libraries with less dynamic relocations, which would not need to set up PIC pointer so often and use less instructions to access shared library local variables (by bypassing GOT on some arches). ... and it would discourage applications from using symbols that aren't part of the published interfaces. I'd suggest starting with the library interface specs, exporting only those symbols that are documented as part of the interfaces, and seeing what applications break. If a signficant number of applications do break, that might suggest adjusting the specs to agree with common usage. I had plans of doing this with a linker version script, but it's still fairly low down on my todo list. From an API point of view, I think it would be better to specify the symbols that should be public, rather than identifying all non-statics that shouldn't be. It'd also be good if this could be implemented for as many of the platforms we support as possible. Well, both version script and __attribute__((visibility (hidden))) can be used at the same time. Anonymous version script works in 2001-12-18 and later binutils and AFAIK in Solaris linker. No idea about other arches. If you think we should list all exported symbols, then maybe we could introduce .sym (or .api) files for each library which would list exported symbols one per line and Imakefile hacks to generate version scripts/whatever else on the fly and use it during linking. In addition to that, at least non-static but not exported variables should be marked with X11_LIBRARY_LOCAL (or whatever other macro you prefer; __HIDDEN__ is IMHO bad since it is OS implementation namespace), for functions unless their address is taken it is much less important. Now, is there some easy way how can the initial .api/.sym files be created from the specs (exported headers or doc/specs or something else)? When that's done, I can surely first see what other symbols other XFree86 libraries need and then harvest some Everything install distribution for other symbols. Second thing is how to define Imakefile macros which will enable __attribute__((visibility (hidden))) and/or version scripts. Should they be just user settable, defaulting to no, or should imake do the autodetection (for that it needs an autoconf like test, since e.g. even when you have GCC 3.3 and later, still visibility attribute doesn't have to be supported if that GCC was compiled against old binutils, etc.)? Jakub ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: What about a kernel module?
Juliusz Chroboczek wrote: I'd like to suggest that you implement device-specific code as a kernel module. Well, that won't happen; we already have working portable driver code in userspace, and there's no chance we'll port that to the Linux kernel. On the other hand, I do think that we'll end up using more kernel-side functionality than we currently do; perhaps someday we'll have enough of that to be able to run non-root servers, at least on hardware that does memory-mapped I/O (the iopl system call is for root only). TR The key problem with this is that kernel modules are Linux-specific, and TR further often need to be kernel-version specific. XFree86 runs quite well TR in many non-Linux environments today. But that doesn't prevent it from using features specific to Linux when needed. Notice for example the use of the vm86old syscall in the Linux/i386 version of the int10 module, or the (optional) use of fbdev in quite a few drivers, or the future use of the /dev/input/event devices (hint, hint). Let alone the DRI. Implementing a kernel module might give access to more resources, like tighter console control, asynchronous accelerations, TR No, I don't think any of that is true. DMA? Smarter polling of FIFO status? Retrace interrupt? For this specific problem : I talked with M. Vojkovich about the yielding problem in that case, then we brought this to linux kernel guys (R. Russel and R. Love), both agreed to say that using sched_yield() will be really incorrect in 2.6, certainly to too much latency. They also both agreed to say that the solution is to use futex to sync the user space driver with the help of a kernel side which would poll the FIFO status (or whatever other conditions we want to wait for). They seemed to be interested in supporting that, so perhaps a joint effort could be successful on both sides so kernel can provide new services the X server could use. Bye Manu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
X scheduler
Hi, Felipe and I are doing some research on interactivity on XFree86 when running with the Linux kernel 2.6. There was an interesting thread on the Linux Kernel Mailing List, where it was pointed [1] an interesting solution to adopt, suggested by Haoqiang Zheng: I have a kernel based solution to this question. The basic idea is: keep the processes blocked by X server in the runqueue. If a certain process (P) of this kind is scheduled, the kernel switch to the X server instead. If the X server get scheduled in this way, it can handle the X requests from this very process (P). By reading this message, it looks like the X scheduler really gives the processor to processes, but from what I understood by reading Efficiently Scheduling X Clients [2], written by Keith Packard, the XFree86's scheduler is used only to choose which process will have it's X requests processed. Can someone point me to a place where it's explained what the X scheduler does with the process that got scheduled? Thanks in advance, Lucas [1]http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8selm=oq3a.6x8.3%40gated-at.bofh.itrnum=12 [2]http://keithp.com/~keithp/talks/usenix2000/smart.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How to render multiple cursors?
On Wed, 8 Oct 2003, Grant Wallace wrote: I earlier had a question regarding how to support multiple pointers. One reply to that was to write a Window Manager to handle this. I can see how the window manager can handle moving windows simultaneously and redirecting input to windows simultaneously. But I'm wondering how would one render multiple cursors from the window manager. It seems if it was just drawn on the root window then other windows would obscure it. Is there a way to draw a top level window that is transparent? Or is there some other trick to getting multiple cursors rendered that will always be on top? The SHAPE extension should let you have a window the shape of the cursor. Just make sure that all the cursor windows stay on top of the window stack. The 8+24 (and any other overlay) modes have two window stacks; don't forget to put the cursors in the top layer. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: What about a kernel module?
On Wed, 8 Oct 2003, Emmanuel ALLAUD wrote: Juliusz Chroboczek wrote: I'd like to suggest that you implement device-specific code as a kernel module. Well, that won't happen; we already have working portable driver code in userspace, and there's no chance we'll port that to the Linux kernel. On the other hand, I do think that we'll end up using more kernel-side functionality than we currently do; perhaps someday we'll have enough of that to be able to run non-root servers, at least on hardware that does memory-mapped I/O (the iopl system call is for root only). TR The key problem with this is that kernel modules are Linux-specific, and TR further often need to be kernel-version specific. XFree86 runs quite well TR in many non-Linux environments today. But that doesn't prevent it from using features specific to Linux when needed. Notice for example the use of the vm86old syscall in the Linux/i386 version of the int10 module, or the (optional) use of fbdev in quite a few drivers, or the future use of the /dev/input/event devices (hint, hint). Let alone the DRI. Implementing a kernel module might give access to more resources, like tighter console control, asynchronous accelerations, TR No, I don't think any of that is true. DMA? Smarter polling of FIFO status? Retrace interrupt? For this specific problem : I talked with M. Vojkovich about the yielding problem in that case, then we brought this to linux kernel guys (R. Russel and R. Love), both agreed to say that using sched_yield() will be really incorrect in 2.6, certainly to too much latency. They also both agreed to say that the solution is to use futex to sync the user space driver with the help of a kernel side which would poll the FIFO status (or whatever other conditions we want to wait for). They seemed to be interested in supporting that, so perhaps a joint effort could be successful on both sides so kernel can provide new services the X server could use. Bye Manu This is more of a hack than a solution. I still see little utility in a kernel module. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How to kick off a accelerate draw operation in source code
The Subsequent functions kick off the operations. You'll have to refer to your hardware documentation for how to do that for your hardware. Mark. On Thu, 9 Oct 2003, xiao john wrote: Hi all, I am writing a customerized graphic card driver in xfree86, and I refered to NV dirver, I can find that NVSetupForSolidLine and NVSubsequentSolidHorVertLine .. functions to manipulate the HW register, I wonder that it is just filling some data in the registers, I want to know when and which instruction kick off the draw operation. Please give me some clue. _ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: error building shared libXau
Matthieu Herrb wrote (in a message from Tuesday April 1) Frank Liu wrote (in a message from Monday 31) I am trying to enable building shared lib for libXau, but got an error: ... gcc -o ./libXau.so.6.0~ -shared -Wl,-rpath,/usr/X11R6/lib -Wl,-soname,libXau.so.6 AuDispose.o AuFileName.o AuGetAddr.o AuGetBest.o AuLock.o AuRead.o AuUnlock.o AuWrite.o + rm -f libXau.so.6 + ln -s libXau.so.6.0 libXau.so.6 + rm -f ../../exports/lib/libXau.so.6 + cd ../../exports/lib /bin/sh: cd: /home/fliu/src/x/xc/exports/lib - No such file or directory apparently nobody created the directory ../../exports/lib I am wondering why I didn't get this error for building other shared libs such as those default libs that have shared enabled? Any ideas? Looks like a bug in many *lib.rules configuration files. The LinkBuildSonameLibrary() macro doesn't build the export/lib directory first. (The LinkBuildLibrary() macro used by non-shared libs does). It currently works with other shared libraries because the 1st built library is precisely libXau and its normally built non-shared only, so its build rule will indeed create the export/lib directory. If the 1st built library is shared and since the shared target appears 1st in Library.tmpl, the directory isn't created. This should be fixed. Better late then never. I just committed a fix for that. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: error building shared libXau
Frank Liu wrote (in a message from Tuesday Apr 1) more errors while final linking of XFree86, Xprt, Xnest, etc. eg: ... os/libos.a(auth.o): In function `LoadAuthorization': auth.o(.text+0x126): undefined reference to `XauDisposeAuth' auth.o(.text+0x135): undefined reference to `XauReadAuth' os/libos.a(xdmcp.o): In function `XdmcpRegisterAuthentication': xdmcp.o(.text+0x2ed): undefined reference to `XdmcpAllocARRAY8' xdmcp.o(.text+0x308): undefined reference to `XdmcpAllocARRAY8' ... If I build libXau and libXdmcp static, those errors will go away. do I need to add -lXau and -lXdmcp in the linking command line? Why static works? Because in the static case the libraries where on the command line as $(DEPLIBXAUTH) and $(DEPLIBXDMCP) - which are empty in the shared case. I'm going to fix that shortly too. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC Marking private symbols in XFree86 shared libraries as private
On Thu, Oct 09, 2003 at 04:55:25PM +0200, Jakub Jelinek wrote: On Thu, Oct 09, 2003 at 12:08:55PM -0400, David Dawes wrote: On Thu, Oct 09, 2003 at 02:05:47PM +0200, Jakub Jelinek wrote: Looking at various /usr/X11R6/lib/lib*.so* shared libraries, I'm seeing lots of exported symbols which look like they are exported just because they cannot be static (as they are used by some other .o files in the same shared library, but never by anything outside). That is correct. If these could be classified (e.g. some _X* symbols in libX11.so.6, some _Ice* symbols in libICE.so.6 etc. might fall into this category), XFree86 could have smaller and faster shared libraries with less dynamic relocations, which would not need to set up PIC pointer so often and use less instructions to access shared library local variables (by bypassing GOT on some arches). ... and it would discourage applications from using symbols that aren't part of the published interfaces. I'd suggest starting with the library interface specs, exporting only those symbols that are documented as part of the interfaces, and seeing what applications break. If a signficant number of applications do break, that might suggest adjusting the specs to agree with common usage. I had plans of doing this with a linker version script, but it's still fairly low down on my todo list. From an API point of view, I think it would be better to specify the symbols that should be public, rather than identifying all non-statics that shouldn't be. It'd also be good if this could be implemented for as many of the platforms we support as possible. Well, both version script and __attribute__((visibility (hidden))) can be used at the same time. Anonymous version script works in 2001-12-18 and later binutils and AFAIK in Solaris linker. No idea about other arches. If you think we should list all exported symbols, then maybe we could introduce .sym (or .api) files for each library which would list exported symbols one per line and Imakefile hacks to generate version scripts/whatever else on the fly and use it during linking. That sounds like a good approach. There are two ways that this is already done for some platforms. OS/2 and Cygwin use files like X11-def.cpp to list the exported symbols. Those lists might be a good starting point, but I suspect that more symbols are exported than are documented in the API specs. Also, X11R6.3 added export description files (like libX11.elist), together with scripts for a few platforms like Solaris, HPUX and AIX to process them. The .elist files are only provided for libX11 and libXt, and they simply export all globals. I don't know if the basic mechanism is worth reusing -- you should look at it and see what you think. They don't provide any useful information about what symbols should be exported for each library though. In addition to that, at least non-static but not exported variables should be marked with X11_LIBRARY_LOCAL (or whatever other macro you prefer; __HIDDEN__ is IMHO bad since it is OS implementation namespace), for functions unless their address is taken it is much less important. Now, is there some easy way how can the initial .api/.sym files be created from the specs (exported headers or doc/specs or something else)? When that's done, I can surely first see what other symbols other XFree86 libraries need and then harvest some Everything install distribution for other symbols. The *-def.cpp files are probably as good a starting place as any, since these are actually used for the OS/2 and Cygwin ports. Second thing is how to define Imakefile macros which will enable __attribute__((visibility (hidden))) and/or version scripts. Should they be just user settable, defaulting to no, or should imake do the autodetection (for that it needs an autoconf like test, since e.g. even when you have GCC 3.3 and later, still visibility attribute doesn't have to be supported if that GCC was compiled against old binutils, etc.)? What happens if you use the visibility attribute with a gcc 3.3 that doesn't have it enabled? If it's simply ignored, then it shouldn't be an issue. Otherwise, is there no pre-defined macro so that you can test for it in the source? If a gcc version check plus gcc feature macro check isn't an option, then I'd suggest adding an imake switch for now, and default it to off. Autodetection could be added to imake too. It'd be nicer if we had a mechanism for caching that information so that imake could do these tests once rather than hundreds of times per build. But nobody seems interested in the incremental approaches for achieving auto-config'd XFree86 builds :-(. But I digress. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: X scheduler
On Thursday 09 October 2003 15:31, Lucas Correia Villa Real wrote: Hi, Felipe and I are doing some research on interactivity on XFree86 when running with the Linux kernel 2.6. There was an interesting thread on the Linux Kernel Mailing List, where it was pointed [1] an interesting solution to adopt, suggested by Haoqiang Zheng: I have a kernel based solution to this question. The basic idea is: keep the processes blocked by X server in the runqueue. If a certain process (P) of this kind is scheduled, the kernel switch to the X server instead. If the X server get scheduled in this way, it can handle the X requests from this very process (P). By reading this message, it looks like the X scheduler really gives the processor to processes, but from what I understood by reading Efficiently Sorry, I have just noticed the handle the X requests sentence on Haoqiang's suggestion. Anyway, wouldn't such solution (kernel based) avoid the computation of things not related to X requests? That is, since the X scheduler only treats X requests, if the X server is going to be scheduled instead of the process (P) then non-X requests will not be processed, and process (P) will hang, right? Or am I wrong? Does anybody wants to share their thoughts about this? Lucas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Fonts] XFree86 4.4 reminder
This is a reminder that the XFree86 4.4 release is planned for mid December 2003, with 15 October 2003 being the final date for the submission of new features. See the release plans page on our web site for further details of the schedule http://www.xfree86.org/releaseplans.html. The 4.3.99.14 development snapshot scheduled for 10 October 2003 will the the last of the automatically generated snapshots in this release cycle. Subsequent snapshots will be generated manually as required until the 4.4 release. Automatically generated snapshots will resume again shortly after the release. As usual, check our development snapshots web page for information about the latest available XFree86 development snapshot http://www.xfree86.org/develsnaps/. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[I18n] XFree86 4.4 reminder
This is a reminder that the XFree86 4.4 release is planned for mid December 2003, with 15 October 2003 being the final date for the submission of new features. See the release plans page on our web site for further details of the schedule http://www.xfree86.org/releaseplans.html. The 4.3.99.14 development snapshot scheduled for 10 October 2003 will the the last of the automatically generated snapshots in this release cycle. Subsequent snapshots will be generated manually as required until the 4.4 release. Automatically generated snapshots will resume again shortly after the release. As usual, check our development snapshots web page for information about the latest available XFree86 development snapshot http://www.xfree86.org/develsnaps/. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[XFree86] that is a problem that i found after installing the linux. How to solve
Hi, this is the system that i found when i using startx command. can you help me to solve it? thank Regards benny _ Download the latest MSN Messenger http://messenger.msn.com.my XFree86.9.log Description: Binary data
[XFree86] Help!
Hi People! I'm new to Mandrake Linux but no to Unix world, so I now a little bit about the OS... Can you help me with this message errors? The X Server dies with Signal 11 while I'm working and I loose everething, this happends too much and I can't work, also I get some core dump messages sometimes... My system is: Micro Intel Pentium 166mhz MMX Mother Intel i430HX - PCIset Intel SB82371SB (all year 95/96) Video Card Trident TGUI9680-1 4MB Modem Conexant/Pine/Rockwell HSF R6793-11 RS56/SP-PCI FM-3711-1 72 MB RAM / HD 3.2 GB With: Mandrake Linux 9.1 Bamboo - kernel 2.4.21-0.13mdk Can you determine what is the problem and what can I do?? See the file XFree86.0.log.old attached please... Thanks for all! Gonzalo G. Alvarez - Buenos Aires, Argentina. _ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com XFree86.0.log.old Description: XFree86.0.log.old
RE: [XFree86] Pseudocolor mode handling...
Hi, I still have problem using XFree86 in Pseudocolor mode. When I use XFree86 V4.1.0 in Pseudocolor Mode, all works fine. I mean that when the X server starts, then no default color are allocated, all the 256 colors are free. But still version 4.2.0 (V4.3.0 too), when I use XFree86 in Pseudocolor mode, then 248 of the 256 colors are allocated when the X server starts, and of course there is no other X application running... So, when I want to use a new distro, like Red Hat V7.x, V8.0, or V9.0, I must put back the V4.1.0 of XFree86, in other our old application works fine in Pseudocolor mode. It's too restricting, especially when we want to use other graphics cards that are not supported in the V4.1.0 of XFree86. So, is the new release of XFree86, V4.4.0 plan for December 2003, take care of this regression in Pseudocolor mode handling? Thank's in advance for your answer, -- Regards, - Patrice Martin You're completely right! This is caused by the render module. One solution is to use a nVidia card with the driver from nVidia. They have an option in their driver 'NoRenderExtension' which disables the render module and gives you your precious colors in pseudocolor mode back! Another option is to rebuild the X server without render module. It is doable (I tested it) but the nVidia solution is much more elegant. Met vriendelijke groet / Mit freundlichen Grüßen / Kind Regards, H.J. ten Berge Test Integration HITT Traffic Oude Apeldoornseweg 41-45 P.O. Box 717 NL-7300 AS, APELDOORN The Netherlands Telephone +31-55-543 26 34 Fax +31-55-543 25 53 E-mail mailto:[EMAIL PROTECTED] Internethttp://www.hitt-traffic.nl ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] zinindie chance deines lebens
die chance deines lebens nur 1dollar und danndownline weltweit bauen mfg stefan balzer http://www.keingeld.net/base-moneygod.htmJORVCFECGMVTLWSC ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Evaluation CD needed
Dear Sir, We have been asked by our partner Fujitsu Lt., Japan to evaluate some microbrowsers,Filesystem,Multimedia and GUI tools that can work in smaller devices such as embedded and handheld devices and appliances. We have choosen your product for evaluation before submitting the results to our client. In this regard, if you send us the full documentation along with a evaluation CD, it will be highly beneficial for us Looking forward to hear from you Thanks and regards peter Dr.C.Pethuru Raj Project Manager Indo-Fuji Information Technologies Pvt. Ltd. BTM Layout, II Stage, 25th main Bangalore, India, 560076 [EMAIL PROTECTED] URL: www.indofuji.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Mouse restrictions under dual-head config
Thank you. That was actually what I had in mind (and I had discovered that earlier). It's just that it feels like kind of a hack to do so. I would have thought that there would be a real way of doing it, if you see what I mean. Oh, and by the way. What I would _really_ want, is to run two different X servers on the same time, but the current VT implementation seems to prevent that. I've heard of some kernel patch or something coming along to fix that. Does anyone know something about this, and in that case, does it work with a dual-headed card like mine or do I need two seperate cards in that case? You can read some about http://startx.times.lv xf86 folk has troubles enough with single X server! linux kernel folk has troubles enough with single current tty! At least it works for me and some funs. My solution is for two separate cards. Kernel patch allow multiple current tty. X parameter vtXX allow choose right tty. Range of ttys may be bounded with separate keyboards. Works with unpatched xf86 binaries (tested Mandrake9.1,Suse8.2). Aivils Stoss ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] See this log file , i`m getting errors with xfs sayin can`t open fixed fonts
- (on the network) email-body was scanned and no virus found -D-Link R D E-Mail Traffic--- XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-8) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.17-0.13smp i686 [ELF] Build Host: daffy.perf.redhat.com 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: Thu Oct 9 17:42:42 2003 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout XFree86 Configured (**) |--Screen Screen0 (0) (**) | |--Monitor SyncMaster (**) | |--Device Intel 815 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7100 (==) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (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.2.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (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.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (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,1130 card 1028,00be rev 04 class 06,00,00 hdr 00 (II) PCI: 00:02:0: chip 8086,1132 card 1028,00be rev 04 class 03,00,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card , rev 11 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2440 card , rev 11 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,244b card , rev 11 class 01,01,80 hdr 00 (II) PCI: 00:1f:2: chip 8086,2442 card , rev 11 class 0c,03,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,2443 card , rev 11 class 0c,05,00 hdr 00 (II) PCI: 00:1f:4: chip 8086,2444 card , rev 11 class 0c,03,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2445 card 1028,00be rev 11 class 04,01,00 hdr 00 (II) PCI: 01:0c:0: chip 10b7,9200 card 1028,00be rev 78 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0x - 0x (0x0) MX[B] (II) Bus 1: bridge is at (0:30:0), (0,1,1), BCTRL: 0x06 (VGA_EN is cleared) (II) Bus 1 I/O range: [0] -1 0xe000 - 0xe0ff (0x100) IX[B] [1] -1 0xe400 - 0xe4ff (0x100) IX[B] [2] -1 0xe800 - 0xe8ff (0x100) IX[B] [3] -1 0xec00 - 0xecff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0xfd00 - 0xfeff (0x200) MX[B] (II) Bus 1 prefetchable memory range: (II) Bus -1: bridge is at (0:31:0), (0,-1,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus -1 I/O range: (II) Bus -1 non-prefetchable memory range: (II) Bus -1 prefetchable memory range: (--) PCI:*(0:2:0) Intel i815 rev 4, Mem @ 0xf800/26, 0xff00/19 (II) Addressable bus resource ranges are [0] -1 0x - 0x (0x0) MX[B] [1] -1 0x - 0x (0x1) IX[B] (II) OS-reported resource ranges: [0] -1 0xffe0 - 0x (0x20) MX[B](B) [1] -1 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [2] -1 0x000f - 0x000f (0x1) MX[B] [3] -1 0x000c - 0x000e (0x3) MX[B] [4] -1 0x - 0x0009 (0xa) MX[B] [5] -1 0x - 0x (0x1) IX[B] [6] -1 0x - 0x00ff (0x100) IX[B] (II) Active PCI resource ranges: [0] -1 0xfdfffc00 - 0xfdfffc7f (0x80) MX[B] [1] -1 0xff00 - 0xff07 (0x8) MX[B](B) [2]
[XFree86] Where can I get the architecture of XFree86
DearMembersofXFree86:IamreadingthecodeofXFree86,andit'snotaneasyjobforme.Itwill,Ithink,savemealotoftimeifIknowthearchitectureofXFree86.IstherespecificationsofthearchitectureofXFree86?WherecanIgetit?Yourtruely!WeiqunSun == °²È«Îȶ¨´óÈÝÁ¿£¬ÊÕ·ÑÒÁÃöùÃâ·Ñ30ÈÕÍêÃÀÌåÑé~ Öйú×î´óµÄÃâ·ÑÓÊÏäÔÚµÈÄã 25Õ׿ռä 4Õ׸½¼þ£¡ µã»÷ÍøÒ×ÅÝÅݾªÏ²ÎÞÏÞ È«Ãâ·ÑÊÖ»ú¶ÌÐÅÈÎÄã·¢!
Re: [XFree86] See this log file , i`m getting errors with xfs sayin can`t open fixed fonts
On Thu, 9 Oct 2003, Suresh Babu wrote: Hai, X Font Server is not running in your machine. start/restart it mannually and start the X. As root : /etc/rc.d/init.d/xfs restart HTH :) -- Bharathi S, IndLinuX Team, (__) DON Lab,TeNeT Group, oo ) IIT-Madras, Chennai-INDIA. (_/\ Known is DROP, Unknown is OCEAN. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] i have a display problem
hi i have a display problem for my red hat linux installation. i am useing a HP Ultra VGA 1280 model d2818a iam attaching the errir log which it has generated. please help us regarding this. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com XFree86.0.log Description: XFree86.0.log
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
Nicolas Joly writes: * NoAccel... ok * Accel ... KO * Accel + SWcursor + 4Mo ... KO * Accel + NeedRingBufferLow ... KO For the NoAccel case, i successfully switched about 20 times to the 4 text consoles and went back to X without any problem. But still no luck with acceleration enabled. 'NeedRingBufferLow' is a variable in the source code, not an option. Did you take this into account? The idea of this variable is to place the ring buffer into the stolen (ie. permanently allocated) memory. When VT switching the agp memory will get unmapped. Therefore other physical pages may get mapped later. The LpRing doesn't seem to like this. Have you tried to do Accel+NeedRingBufferLow+SWcursor? This should move all things that may cause problems out of the danger zone. Also please disable DRI! Egbert. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Horizontal Sync Range and Vertical Sync Range
Hello, sorry to bother you, I got monitor Sony CPD-G200P and i need to setup my XWindows to work in [EMAIL PROTECTED]But i just get [EMAIL PROTECTED]... There is a only one vertical and horizontal sync range in my monitor manual, it brings my monitor to [EMAIL PROTECTED] Hz :( So my question is: Which horizontal and vertical sync range should i specify to work in [EMAIL PROTECTED] P.S. I dont find this informartion in internet and sony website. I hope that you will help me. Thanx. Bye.
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Thu, Oct 09, 2003 at 03:47:22PM +0200, Egbert Eich wrote: Nicolas Joly writes: * NoAccel ... ok * Accel... KO * Accel + SWcursor + 4Mo ... KO * Accel + NeedRingBufferLow... KO For the NoAccel case, i successfully switched about 20 times to the 4 text consoles and went back to X without any problem. But still no luck with acceleration enabled. 'NeedRingBufferLow' is a variable in the source code, not an option. Did you take this into account? I recompiled/installed the i810 driver with the following modifiation: Index: i830_driver.c === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c,v retrieving revision 1.39 diff -u -r1.39 i830_driver.c --- i830_driver.c 8 Oct 2003 15:48:40 - 1.39 +++ i830_driver.c 9 Oct 2003 13:53:43 - @@ -1769,7 +1769,8 @@ pI830-CursorNeedsPhysical = FALSE; /* Force ring buffer to be in low memory for the 845G. */ - if (IS_845G(pI830) || IS_I85X(pI830) || IS_I865G(pI830)) + /* HACK: temporary enable NeedRingBufferLow + if (IS_845G(pI830) || IS_I85X(pI830) || IS_I865G(pI830)) */ pI830-NeedRingBufferLow = TRUE; The idea of this variable is to place the ring buffer into the stolen (ie. permanently allocated) memory. When VT switching the agp memory will get unmapped. Therefore other physical pages may get mapped later. The LpRing doesn't seem to like this. Have you tried to do Accel+NeedRingBufferLow+SWcursor? This should move all things that may cause problems out of the danger zone. I just made the test, but it doesn't work either. Also please disable DRI! I do not have DRI under NetBSD. -- Nicolas Joly Biological Software and Databanks. Pasteur Institute, Paris. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Pseudocolor mode handling (further details)...
Berge, Harry ten wrote: You're completely right! This is caused by the render module. One solution is to use a nVidia card with the driver from nVidia. They have an option in their driver 'NoRenderExtension' which disables the render module and gives you your precious colors in pseudocolor mode back! Another option is to rebuild the X server without render module. It is doable (I tested it) but the nVidia solution is much more elegant. Thank's for your quick answer, I see more clearly now... I've got an Nvidia Vanta card somewhere, so I'm going to try your solution using the Nvidia driver. But for our needs, we must have a solution for other graphics cards . So I aim to rebuild the X server without render module to try this solution, but reading the "installation details for XFree86 4.3.0", I don't found what to do exactly to succed in this solution. Must I do something before using "Xinstall.sh" script? Thank's in advance for your help and instructions doing this step. To finish, is there something in this direction (good Pseudocolor mode handling), using an option, or with a specific question inside the "Xinstall.sh" script, or something else, expected in the further release of XFree86 (now I suppose the V4.4.0 in December 2003), without desable the render module? Once more thank's for your informations and precious details to make progress in my needs, -- Bests Regards, - Patrice Martin --
[XFree86] Re: Pseudocolor mode handling (further details)...
On Thu, 9 Oct 2003, MARTIN Patrice - GRE ( [EMAIL PROTECTED] ) wrote: You're completely right! This is caused by the render module. One solution is to use a nVidia card with the driver from nVidia. They have an option in their driver 'NoRenderExtension' which disables the render module and gives you your precious colors in pseudocolor mode back! Another option is to rebuild the X server without render module. It is doable (I tested it) but the nVidia solution is much more elegant. Use 4.3.0 which solves this problem without requiring any external drivers or modifications. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] FW:
Hello - I am getting the following error when starting windows. Any idea why? Thanks, Gary Gary E. Elliott Senior Technical Staff Member ALABS (ATT Labs) 290 Davidson Ave., Somerset N.J 08875 rm. E2B037 732-805-2329 -Original Message- From: Gary E Elliott 2329 E2B037 [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2003 11:05 AM Subject: XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-72) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-11smp i686 [ELF] Build Host: daffy.perf.redhat.com Module Loader present OS Kernel: Linux version 2.4.18-14 ([EMAIL PROTECTED]) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Wed Sep 4 13:35:50 EDT 2002 PF 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: Thu Oct 9 09:21:34 2003 (==) Using config file: /etc/X11/XF86Config Parse warning on line 75 of section Keyboard in file /etc/X11/XF86Config Ignoring obsolete keyword LeftAlt. Parse error on line 75 of section Keyboard in file /etc/X11/XF86Config Meta is not a valid keyword in this section. (EE) Problem parsing the config file (EE) Error from xf86HandleConfigFile() Fatal server error: no screens found When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Horizontal Sync Range and Vertical Sync Range
BlackCat Hack Palace Admin wrote: Hello, sorry to bother you, I got monitor Sony CPD-G200P and i need to setup my XWindows to work in [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] But i just get [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]... There is a only one vertical and horizontal sync range in my monitor manual, it brings my monitor to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hz :( So my question is: Which horizontal and vertical sync range should i specify to work in [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] P.S. I dont find this informartion in internet and sony website. I hope that you will help me. Thanx. Bye. There is no built-in default mode 1024x768-100 in XFree86. You need a modeline. Doing a bit googling will help. -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XFree86 4.4 reminder
This is a reminder that the XFree86 4.4 release is planned for mid December 2003, with 15 October 2003 being the final date for the submission of new features. See the release plans page on our web site for further details of the schedule http://www.xfree86.org/releaseplans.html. The 4.3.99.14 development snapshot scheduled for 10 October 2003 will the the last of the automatically generated snapshots in this release cycle. Subsequent snapshots will be generated manually as required until the 4.4 release. Automatically generated snapshots will resume again shortly after the release. As usual, check our development snapshots web page for information about the latest available XFree86 development snapshot http://www.xfree86.org/develsnaps/. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] (no subject)
Hello, sorry to bother you, I got monitor Sony CPD-G200P and i need to setup my XWindows to work in [EMAIL PROTECTED] But i just get [EMAIL PROTECTED] There is a only one vertical and horizontal sync range in my monitor manual, it brings my monitor to [EMAIL PROTECTED] Hz :( So my question is: Which horizontal and vertical sync range should i specify to work in [EMAIL PROTECTED] P.S. I dont find this informartion in internet and sony website. I hope that you will help me. Thanx. Bye Best Regards Andrew ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] that is a problem that i found after installing the linux. How to solve
I think you need to upgrade to XFree86 4.3. Your XFree86 version is substantially older than your graphics hardware. Mark. On Thu, 9 Oct 2003, Ong sianyaw wrote: Hi, this is the system that i found when i using startx command. can you help me to solve it? thank Regards benny _ Download the latest MSN Messenger http://messenger.msn.com.my ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Help!
If this happened while you were doing something that uses TrueType fonts (like web browsing), you might want to try replacing Load freetype with Load xtt in the XF86Config file. There are some known fatal conditions in the Freetype module. Mark. On Thu, 9 Oct 2003, [iso-8859-1] Gonzalo G. Alvarez wrote: Hi People! I'm new to Mandrake Linux but no to Unix world, so I now a little bit about the OS... Can you help me with this message errors? The X Server dies with Signal 11 while I'm working and I loose everething, this happends too much and I can't work, also I get some core dump messages sometimes... My system is: Micro Intel Pentium 166mhz MMX Mother Intel i430HX - PCIset Intel SB82371SB (all year 95/96) Video Card Trident TGUI9680-1 4MB Modem Conexant/Pine/Rockwell HSF R6793-11 RS56/SP-PCI FM-3711-1 72 MB RAM / HD 3.2 GB With: Mandrake Linux 9.1 Bamboo - kernel 2.4.21-0.13mdk Can you determine what is the problem and what can I do?? See the file XFree86.0.log.old attached please... Thanks for all! Gonzalo G. Alvarez - Buenos Aires, Argentina. _ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Where can I get the architecture of XFree86
There is alot of documentation in the xc/doc directory in the XFree86 source code. If you have specific questions, you should ask them. Mark. On Thu, 9 Oct 2003, ËïΪȺ wrote: Dear Members of XFree86: I am reading the code of XFree86,and it's not an easy job for me.It will ,I think, save me a lot of time if I know the architecture of XFree86. Is there specifications of the architecture of XFree86? Where can I get it? Your truely! Weiqun Sun ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Evaluation CD needed
Somebody familiar with TinyX should send him some pointers. Mark. On Thu, 9 Oct 2003, Pieter Hulshoff wrote: snip Will one of the developers of XFree86 send this gentleman a proper response, or shall I as a user pick this one up? Regards, Pieter Hulshoff ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] i have a display problem
(--) PCI:*(0:15:0) unknown vendor (0x15ad) unknown chipset (0x0405) rev 0, Mem @ 0xfd00/24, 0xfc00/24, I/O @ 0x10e0/4 Looking this up on the web, this appears to be a VMWARE SVGA II v3.x It looks like there is a driver for this in XFree86 4.3. You should upgrade as your XFree86 version is over two years old. Mark. On Thu, 9 Oct 2003, MADHANA GOPAL PARTHIBAN wrote: hi i have a display problem for my red hat linux installation. i am useing a HP Ultra VGA 1280 model d2818a iam attaching the errir log which it has generated. please help us regarding this. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Horizontal Sync Range and Vertical Sync Range
According to information I see on the web, this monitor supports horizontal frequencies up to 96 kHz. So I would guess: HorizSync 30 - 96 VertRefresh 50 - 120 or something like that. There are no 100 Hz modelines built into XFree86 though, so you'll have to make one. The gtf app that ships with XFree86 4.3 can generate modelines for you. Eg. # 1024x768 @ 100.00 Hz (GTF) hsync: 81.40 kHz; pclk: 113.31 MHz Modeline 1024x768_100.00 113.31 1024 1096 1208 1392 768 769 772 814 -HSync +Vsync # 1152x864 @ 100.00 Hz (GTF) hsync: 91.50 kHz; pclk: 143.47 MHz Modeline 1152x864_100.00 143.47 1152 1232 1360 1568 864 865 868 915 -HSync +Vsync 1280x1024 @ 100Hz has a horizontal frequency that exceeds 96 kHz, unfortunately. Mark. On Mon, 29 Sep 2003, BlackCat Hack Palace Admin wrote: Hello, sorry to bother you, I got monitor Sony CPD-G200P and i need to setup my XWindows to work in [EMAIL PROTECTED] But i just get [EMAIL PROTECTED] There is a only one vertical and horizontal sync range in my monitor manual, it brings my monitor to [EMAIL PROTECTED] Hz :( So my question is: Which horizontal and vertical sync range should i specify to work in [EMAIL PROTECTED] P.S. I dont find this informartion in internet and sony website. I hope that you will help me. Thanx. Bye. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Contradictory informations about video card support
On Sun, 28 Sep 2003, Vincent Thomasset wrote: Date: Sun, 28 Sep 2003 07:44:34 +0200 From: Vincent Thomasset [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Contradictory informations about video card support Hi, i own an ISA Trident TVGA8900B vga card, and i would like to know whether it is supported or not by XFree 4.2.1... For instance, the XF 4.2.1 Driver status page says it is on 3.3.6 AND 4.2.1 but below, in the summary section, it is said : The following (older) chipsets are supported in 3.3.6 and *not* in 4.2.1: ..., TVGA8900B, ... And again, the next paragraph : The TVGA8900B ..., ..., are supported in both 3.3.6 and 4.2.1. Is this a mistake or a i missing something ? I reported this ages ago, either in bugzilla or on the devel@ list, possibly even prior to the list being public.. Don't recall, but there were numerous errors/inaccuracies present. If someone can fix the docs right away, that'd be fine, however I can probably track down my email/whatever of the various problems I discovered and file a bug report if that would be prefered instead. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
