Re: __AMD64__ or __amd64__ ?
On Thu, 4 Mar 2004, Juliusz Chroboczek wrote: MH If the test is just to determine wether or not a 64bit MH architecture is being built for, then __arch64__ is a better MH test. What is a 64 bit architecture? Is it about address bus size? (The MC68020 is a 34-bit architecture?) About data bus size? About register size? (The MC68040 is an 80-bit architecture?) About the size that instructions operate on? (The P6 is a 128-bit architecture?) LP64 has a well-defined technical meaning (it's about the size of data types exported by the C compiler.) I have no idea what ``64-bit architecture'' may mean. There is really no need to be a troll when someone is trying to provide useful helpful advice. If you do not know what __arch64__ is, then by all means read ISO C99 and/or the gcc or other documentation. This mailing list is getting more sickening and useless every day with useless commentary like yours in response to a helpful message. I guess when the ship sinks however, the whole thing goes down, not just part of it. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: X client problem
On Thu, 4 Mar 2004, Manish Lalwani wrote: Date: Thu, 4 Mar 2004 13:16:37 +0400 From: Manish Lalwani [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C401C9.65ADDEC8 Subject: X client problem Hi, I have configured everything on Xserver but when I try and connect from client to Xserver it gives me error saying Can't open display: 172.16.1.151:0.0 Can you please help me out with this. Thanks and Regards, Manish Hi Manish, All that you need to do is to typessh-X remote server IP and then just type the name ofthe client application, and it will use standard ssh X11 forwarding. Itshould just work. Hope this helps. Take care, T TY L ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: BUG: mouse behavior with linux 2.6.x
On Sun, 29 Feb 2004, Michal Kosmulski wrote: I recently upgraded from linux 2.4.23 to 2.6.2 and this caused some problems with my mouse in XFree86. I have XFree86 4.3.0 (official slackware 9.1 build) and I use nvidia's binary video driver (version 5336 at the moment). My mouse is a ps/2 logitech mouse with a mouse wheel (s48). After I upgraded to linux 2.6.2, after starting up X, the mouse cursor didn't react to mouse movement for about 2 seconds of moving the mouse. After that, the mouse pointer did move, but the mouse wheel was not working. At that time I had Protocol set to Auto for my mouse and with kernel 2.4.23 the mouse was detected correctly and the mouse wheel worked. After I manually changed the setting to ImPS/2, the delay in mouse motion stopped and the wheel works again. i didn't find anything non-standard in my XFree86 logs, but there were some messages in the syslog. The first two messages have disappeared after changing Auto to ImPS/2, the rest still appears whenever X is started. I also get strange mouse behavior once in a while (once every 3 days or so): suddenly the mouse starts moving all by itself - it seems to go to one of the screens corners, but I can't really see where it goes. This motion stops at the moment I press any key. I don't think this could be attributed to dust in the mouse mechanism or anything similar - I believe it is also a bug. Excerpt from /var/log/syslog follows: Feb 11 14:54:16 nowy kernel: psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. Feb 11 15:46:17 nowy kernel: psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. Feb 11 16:11:25 nowy kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). Feb 11 16:11:25 nowy kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. Feb 11 16:11:25 nowy kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). Feb 11 16:11:25 nowy kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. This is indeed an XFree86 bug. A few weeks ago David posted a patch to attempt to fix it, however that patch didn't work. I added some debugging patches to the server and tracked the problem down and fixed it in the latest Fedora Core development XFree86 builds. You can grab the latest Red Hat XFree86 src.rpm from rawhide and extract the relevant patch if you like. Hope this helps. P.S. On a side note, before anyone asks ... I'd have submitted my fix in bugzilla, however nobody was motivated to respond to any of my emails on the subject of this bug over the last few weeks while I was trying to help find a solution, so I am not motivated to go out of my way to submit a patch either. Two way street. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Fwd:XFree4.4 no more GPL?
On Mon, 1 Mar 2004, [ISO-8859-1] Frédéric L. W. Meunier wrote: Dominique Dumont wrote: For instance, Debian maintainer (Branden Robinson) will not package Xfree4.4 will its new licence. As always, people can use another distribution, the binaries from http://ftp.xfree86.org/pub/XFree86/4.4.0/binaries/ , or compile it. You mean there is a distribution that actually plans on shipping 4.4.0? ;o) -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Opteron, PCI RADEON and PCIGART
On Tue, 15 Jul 2003, Mark Lane wrote: Date: Tue, 15 Jul 2003 15:20:11 -0600 From: Mark Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Opteron, PCI RADEON and PCIGART Anyone know why GinGin64 would have problems with Forcing PCIMode with a Radeon 7000. The log shows it looping errors about RADEONCP. Hi Mark, GinGin64 was an unsupported technology preview of a port of Red Hat Linux 9 to AMD64. It was intended to let AMD64 users be able to sample the current state of the Red Hat Linux OS on the platform. That said, there are likely many bugs that you'll stumble across, and there are no official updates or bugfixes available as it was not an official OS release. Having said that, Red Hat Enterprise Linux 3 is now available which officially supports the AMD64 architecture, and within the next week or so, Fedora Core 1 for AMD64 will be released as well. The XFree86 included in Fedora Core 1 includes a great number of stability, performance, security fixes, and other enhancements over previous OS releases, including the unofficial GinGin64 technology preview. I have fixed the AGP/PCI autodetection in the radeon driver for good in our latest bits. You might wish to upgrade to the new release once it is available, as you'll likely find the system runs much smoother. Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: __AMD64__ or __amd64__ ?
On Sat, 28 Feb 2004, Matthieu Herrb wrote: While working on OpenBSD/amd64 support for XFree86, I found out that the C preprocessor symbol for AMD64 machines was changed from __x86_64__ to __AMD64__. But looking at what gcc defines on different AMD63 systems (*BSD, Linux), it looks __AMD64__ is never used. Generally __amd64__ is defined. linux.cf add -D__AMD64__ to StandardCppDefines, so the code actually works there. Also, in many places where checks are done for 64 bits arches, the test is in the form #if defined(_LP64) || defined(__alpha__) || defined(__AMD64__). Since on the BSDs gcc defines _LP64, these conditions will be true. But there are a few cases where the _LP64 test is missing. Any clues on how to fix that correctly (after 4.4) ? Instead of enumerating all the LP64 arches in several different places, it would be better imho to make sure _LP64 is defined and only testing on this. If the test is just to determine wether or not a 64bit architecture is being built for, then __arch64__ is a better test. I've noticed a bunch of places in the source which test for each possible 64bit architecture, and which need to have any new 64bit arches added as time goes on. __arch64__ would fix that also. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: problem with X
On Thu, 26 Feb 2004, Julian Terziev wrote: Date: Thu, 26 Feb 2004 22:18:03 +0200 From: Julian Terziev [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary=000602000202050809000402 Subject: problem with X Hello, I try to install the latest update of Xfree, but every time i recieve the same error (: My video card is ATI Radeon 9200 , but even with the vesa driver , X server can't start (: Can you tell me what is the problem ? I attached the log. Is the X server SUID root? If not, make it SUID root. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Having problems with my Fedora Installation running StartX
On Thu, 26 Feb 2004, Haywood Parker wrote: When I run StartX I get errors. XFree86 Version 4.3.0 (Fedora Core 1: 4.5.0-42) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.21-2.ELsmp i686 [ELF] Build Date: 24 October 2003 Build Host: porky.devel.redhat.com I am running on a Compaq Prosignia 300 Pentium 133 with 128meg of RAM Typing StartX gives me an error (EE) Unable to locate/open config file ^ You do not have a configuration file, which means either: 1) you have not configured X or 2) you have deleted the config file something? Does SuperProbe come with my Distribution? If so how do I find it and run it so it will tell me what my video chipset is? SuperProbe is about 5 years obsolete now. Run: redhat-config-xfree86 --reconfig After that, things should just work. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: help new driver
On Thu, 26 Feb 2004, dave wrote: Date: Thu, 26 Feb 2004 12:24:02 +1300 From: dave [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Subject: help new driver I am writing a driver and need to now what copyright GPL stuff I need to put in my source files The existing drivers are under an MIT/X11 style license, which allows their source code to be shared with pretty much anything, including GPL licensed code. Making your driver MIT/X11 licensed, or dual licensing it as MIT/X11 and GPL, would allows other drivers to be able to benefit from sharing code with your driver as well. Of course it is totally up to you what license you would prefer to use. The FSF and/or GNU websites contain information on what you should place in your sources in order to properly legally indicate they are GPL licensed should you decide to not use the traditional MIT/X11 license which is more shareable. Hope this helps. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: kbdrate problem [johnw@zacglen.com.au: (fixes seq: A.525) Bogus switch to VT6]
On Tue, 27 Nov 2001, John Witford wrote: I'm curious why we would remove the code in question though; it should be harmless on any system which has the ioctl. Perhaps the underlying test is broken? yep, good question:( we really should figure out why this doesn't work as planed and fix the ioctl()-support, then the port I/O code isn't needed for decent systems anymore... and how about non-linux systems ? does *BSD* support KDKBDREP It is unlikely that BSD is using the os-support/linux/lnx_io.c code, so disabling this in that file is unlikely to affect BSD at all. IMO if there is no KDKBDREP ioctl then the keyboard rate should be left unchanged. Simple, reliable, and effective. Agreed. Also, 1. Pentium III 900MHz, Focus PS/2 keyboard with Asus CUSL2 mb 2. Pentium I 166MHz, FC PS/2 keyboard with Triton II mb With Linux 2.2.17 and 2.4.9 I note that RedHat configure their systems so that XFree uses virtual screen #6. That cleverly masks the problem. No. A default Red Hat OS installation, be it Fedora Core, Red Hat Enterprise Linux, or Red Hat Linux, will always default to having 6 preconfigured virtual consoles. This is the default which most Linux operating systems have used since as far back as I can remember, at least for the Linux OS's that I have installed, including Slackware as far back as 1994. The XFree86 default, is to start up on the next unused virtual console, which is tty7 on any default Red Hat OS installation (contrary to #6 quoted above). If you are having XFree86 start up on virtual console #6, then your system is not configured to the default that the OS supplied, which is 6 preconfigured console logins in /etc/inittab. Red Hat OSs do not specify which VC XFree86 will start up on. It starts up on the first unused virtual console which is the XFree86 default, and can be overridden if desired by using the vtXX commandline switch to the server (man XFree86). could you please check, why KDKBDREP_ioctl_ok() doesn't seem for you configuration ? if KDKBDREP_ioctl_ok() would work for you, it wouldn't be necessary to comment out that port I/O fallback stuff. I will have a look sometime. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115769 I've narrowed the problem down currently in 4.3.0, to the code in lnx_io.c, which is largely 100% unmodified cut and pasted code directly from lnx_kbd.c. Quite odd that that much code is duplicated between 2 files in the same directory. The ioctl is failing when getting called + /* + * This has the unfortunately side-effect of causing + * the monitor to switch to virtual screen 6! + */ IIRC, this is the very first such report. any chance that you're using rare/strange (broken?) hardware ? Much greater chance that I am using broken software that doesn't work with all hardware! Agreed. Not for long though, I should have a patch that fixes this soon enough. I'm going to change the code also to remove the ioport based access entirely and to log a warning to the log file instead, so that the X server doesn't cause the system to hang if the keyboard repeat rate ioctl fails for any reason. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
full space, this user is limit quota (fwd)
Every time I've posted a message to [EMAIL PROTECTED] for the last week or so, I receive back one of these autoresponder emails. This person's email account seems to be perpetually in full disk quota mode, and it would be convenient if their address could be removed from the subscriber list, to prevent everyone from continuing to get the autoresponder messages. I tried to contact the postmaster at this address several times and that address also results in an out of disk space message. Might be a good idea to check the subscription list of [EMAIL PROTECTED] and remove it from there as well, or alternatively to set both of them to nomail perhaps. TIA -- Mike A. Harris -- Forwarded message -- Date: 22 Feb 2004 19:22:32 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: full space, this user is limit quota full space, that user [EMAIL PROTECTED] can not receive more letter ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: XFree shouldn't access hardware directly errors.
On Sun, 15 Feb 2004, David Dawes wrote: Well, the kernel means what it says. XFree86 boldly goes and accesses the keyboard controller registers when it starts up. This is a bad thing to do, as it can conflict with the kernel using these registers at the same time. The kernel spots this and complains, and in most cases is not affected by the problem. So, unless you are an XFree86 developer and can fix X, ignore this message. ScottG. Yes I know. I should have asked if there are plans to fix it. Does anyone know why the KDKBDREP ioctl fails? Maybe the attached patch would make a difference? Someone just pointed out your email here to me, which I didn't catch as it whizzed by on xfree86 list traffic. ;o) One thing about XFree86 4.3.0 at least, is that both of the following files: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c ... contain the exact same cut and pasted code for the keyboard rate setting. It appears that the code may have originally been in lnx_io.c, and got moved to lnx_kbd.c later on which seems more appropriate, but that the original code never got removed from lnx_io.c, and is still gets called in 4.3.0. I discovered this after patching lnx_kbd.c with debug messages and none of them showed up in the logs. After grepping the tree for other ioport access I discovered that the identical code was in the above two files, so I copied my debugging patch back into itself, and changed the second diff copy to patch lnx_io.c instead, thus patching both files. The patch applies cleanly to both files, and the log file now shows my debugging messages, indicating lnx_io.c is the code that is actually getting used. I will test your patch, and get user feedback as well, and report back wether it fixes the problem or not. Thanks, TTYL -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
On Sun, 22 Feb 2004, [iso-8859-2] Pawe³ Sikora wrote: Date: Sun, 22 Feb 2004 11:13:06 +0100 From: [iso-8859-2] Pawe³ Sikora [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Subject: Re: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. On Sunday 22 of February 2004 06:48, Zuckerman wrote: Hi, I'm from São Paulo / Brasil. In dmesg appear this: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. How I can resolve this? Apply this patch: http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/XFree86-lnx_kbd.patch I've applied that to 4.3.0 and it does not fix the problem. The code that gets called to set the repeat rate is actually in lnx_io.c, as a more or less verbatim cut and pasted copy of lnx_kbd.c's code, and it is what ends up getting called. After closer inspection of things it appears to me, that this was a work in progress that never got finished cleanly perhaps? When the patch is applied to both files, it fails to compile with: lnx_io.c:93: warning: string length `565' is greater than the length `509' ISO C89 compilers are required to support lnx_io.c: In function `xf86SetKbdRepeat': lnx_io.c:216: `pInfo' undeclared (first use in this function) lnx_io.c:216: (Each undeclared identifier is reported only once lnx_io.c:216: for each function it appears in.) I'm currently investigating this issue now as well. Will post back if I get time to figure it out tonight. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: XFree86 4.4.0 RC3
On Wed, 18 Feb 2004, David Dawes wrote: The big deal you are all making about the GPL-incompatibility of the modified XFree86 licence is really quite minor in comparison. Lets face it: Your real objection is to giving credit to XFree86 and its contributors. GPL-incompatibility and FUD about FSF-freeness(*) of the modified licence is just a poor excuse. You're very wrong there David. I believe that the XFree86 project very much deserves credit for any work that the project does do. I have every intention, when using XFree86 project written code, or supplied patches, etc. of giving the project full credit for anything that it has done regardless of whatever license is used. The credit is given not because of some license or legal requirement, but because it is just the proper and moral thing to do. If there is any code from XFree86 which I personally have used and did not give proper attribution for in the past, I definitely want to know about it, so that I can correct the problem. I am a strong believer in giving proper credit where it is due, however I also realize that human err can cause mistakes to happen sometimes. It is in everyone's best interest to work together in pointing out such cases of human error in a friendly way, so that everyone involved has proper credit given to them. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC3
On Tue, 17 Feb 2004, David Dawes wrote: Also check the LICENSE document http://www.xfree86.org/~dawes/pre-4.4/LICENSE.html. There is a lot of FUD being circulated about the licensing, so check here for the facts. Also check out the FSF's Free Software definition and their list of licenses, as well as the OSI's Open Source Definition. There are links to these sites from our LICENSE document. In particular, follow up with the BSD licences (original and revised), the FreeType License (FTL), the SGI Free Software License (which applies to GLX and CID), and the Apache 1.1 licence. Don't rely on the FUD being circulated by people who can barely hide their prejudice. Go straight to the definitive sources on licensing issues, namely the FSF and the OSI, and come to your own conclusions. So I must totally agree with you David. People should indeed go to the definitive sources on open source licensing issues, the FSF and the OSI. Interestingly enough, neither the XFree86 license version 1.0, nor the new 1.1 license are listed as OSI approved open source licenses: http://www.opensource.org/licenses/index.php Going to the Free Software Foundations site to see their list of approved free software licenses, the XFree86 license version 1.0 and 1.1 are also noteably missing: http://www.fsf.org/licenses/license-list.html The FSF does have the following: The X11 license. This is a simple, permissive non-copyleft free software license, compatible with the GNU GPL. XFree86 uses the same license. This is sometimes called the MIT license, but that term is misleading since MIT has used many licenses for software. However that statement is inaccurate, as the parts of the XFree86 source code which are copyright by XFree86.org, are under either the XFree86 license version 1.0, or XFree86 license version 1.1. The simple conclusion, is that XFree86 is not free software, as defined by the Free Software Foundation nor open source software as defined by the Open Source Initiative, however there are a few inaccuracies present on both of these websites which need to be fixed, in order to not mislead people into beleiving XFree86 is MIT/X11 licensed. Of course, others should visit both websites and draw their own conclusions also, which will help to cut down on the FUD going around. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: startx fails
On Tue, 17 Feb 2004, Brian Fuller wrote: I would be happy to send you what is asked for in the error message but I don't know what that is. This work station has been working happily for nearly a year and one day it just stopped letting any of the users run startx. Interestingly, root is able to run startx and once I have console window up as root I I have to type xhost + then su to my user name and get back to work in a fairly normal way. None of the users can execute xhost + until root has done it. Also interesting when any of the users execute XFree86 -version we get the same message as given above when startx fails. The version of XFree86 is 4.2.0 (Red Hat version 4.2.0-8). My version of Red Hat is 2.4.18-18.7.xsmp Wow, your X server and kernel are both ancient and remotely exploitable. Hopefully nobody has tried to hack into your system already. Running up2date immediately after OS installation and upgrading to the latest security updates is always a good idea thank heavens! -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Fwd: XFree86 vulnerability exploit
On Thu, 12 Feb 2004, Scott Gifford wrote: This was posted on Bugtraq earlier today, and I thought it might be of interest here. All currently supported Red Hat OS products have had erratum updates released which address all of the vulnerabilities reported in CAN-2004-0083, CAN-2004-0084, and CAN-2004-0106 security advisories. Supported OS releases include: Red Hat Enterprise Linux 2.1 Red Hat Enterprise Linux 3 Red Hat Linux 9 Fedora Core 1 Users of Red Hat OS products not listed above are urged to upgrade their OS to a currently supported OS release from the above list in order to be protected from this series of vulnerabilities. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: do XFree86 accept XIM projects?
On Wed, 11 Feb 2004, Zhang Weiwu wrote: Hello. I'm zhangweiwu from the minichinput project. This is the first time I post to this list, so please forgive me if I posted to the wrong list. To be brief: minichinput is a Chinese input method server. Can XFree86 accept minichinput as its subproject? Minichinput is one of the most widely used *nix input server among the simplified Chinese users (or at least I think so). Linux distros like RedHat and Turbolinux adopted minichinput as the default input server. minichinput handles both GB, Big5 and UTF8, it is lightweighted, doesn't rely on gtk/qt. Who/what list should I contact if I wish to make minichinput a subproject of XFree86, and release as part of it? Do XFree86 accept this kind of subprojects? Personally, I think having minichinput as it's own separate piece of software is the best thing to do. Everyone is currently trying to get rid of this massive monolithic source code tree which includes everything under the sun. It is easier to maintain applications like minichinput if it is it's own project, and it's easier to package, and to update. Having to recompile the entirity of XFree86 to fix a small bug in a single tiny application is going backwards IMHO. So, while I can't speak for the XFree86 project at all, and I'm definitely not trying to do so, I can at least give you my viewpoint from a distribution engineering perspective. We will continue to ship minichinput as a separately packaged rpm package that is not included with the XFree86 sources, even if the XFree86 project were to include it in their tarball, much in the same way that we now currently ship xterm as a separate package. Other distribution X maintainers that I am in contact with daily on IRC share this sentiment generally, and look forward to having more modular X sources to deal with in the future as well. Note that this is not to discourage your idea in any way, but rather just to indicate that it wont be useful to everyone out there for this to be included directly in XFree86. It may however benefit other OSs and distributions which XFree86 supports which may not already ship minichinput, such as commercial proprietary OSs however. Hope this feedback is useful. Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: Help with S3 TRIO 64 on REDHAT AS 3.0 PPC
On Tue, 10 Feb 2004, Howard Luckenbaugh wrote: Date: Tue, 10 Feb 2004 12:42:20 -0500 From: Howard Luckenbaugh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary=3A319CE7888AEC74946CE681 Subject: Help with S3 TRIO 64 on REDHAT AS 3.0 PPC I am trying to find a driver that will work with REDHAT AS 3.0 PPC for my S# TRiO 64 card. It is trying to use the s3 driver but XFREE86-4.3.0 for PPC does not contain that driver. You can recompile the s3 driver (or any driver) against the XFree86-sdk package if you like. Red Hat doesn't support this driver on PPC of course however. Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: 4.4.0 RC2 and linux 2.6.3-rc1
On Sun, 8 Feb 2004, [iso-8859-2] Martin MOKREJ© wrote: I tried latest kernel and I see some error logged by the system, Should I worry? atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. This happens on 4.3.0 also, and is due to the X server directly bit banging the keyboard controller to set the repeat rate. If you look at the code, it first tries to use the new kernel ioctl, then a fallback, then finally it does bitbanging if the previous methods fail. The kernel people believe that it should not ever directly access the hardware, and that it should only use the ioctl, and if the ioctl isn't available in your kernel (perhaps your kernel is very very ancient), then X should not set the repeat rate at all. The question then is: Why is the ioctl not working? I am currently investigating this matter myself, and there are a few possibilities that could be happening: 1) Compile time problem: The kernel headers on the machine that X is being compiled on, do not have the KDKBDRATE ioctl present, and so the code to use that ioctl does not get compiled in. or 2) The KDKBDRATE ioctl stuff gets built in, but at runtime the ioctl is failing for some reason or another, thus the ioport bitbanging occurs, and can totally hang the machine according to kernel folk. If anyone has any other possibilities, feel free to share. I've written a small debugging patch to put into a future build in order to peek into what's going on, but haven't gotten it into test builds yet. Not an uber-high priority item however, so it'll take a week or two probably for a test build to get out there and get some feedback from people seeing this problem. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: TWM patches
On Sat, 7 Feb 2004, Alexander Pohoyda wrote: Would somebody please have a look at my TWM patches? http://bugs.xfree86.org/show_bug.cgi?id=968 XPM picture format support for icons. http://bugs.xfree86.org/show_bug.cgi?id=1078 Function to change window/icon titles. http://bugs.xfree86.org/show_bug.cgi?id=1124 IconMaxWidth parameter to limit the width of the icon window (Mozilla tends to have very long titles) These all are small enhancements, but I'd like to know if they have any chance to be accepted. Submit them in bugzilla. http://bugs.xfree86.org If they get accepted, they'll go into the CVS head in future development and the bug will be marked FIXED or similar. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: BUG
On Sat, 7 Feb 2004, kaustubh wrote: Date: Sat, 7 Feb 2004 12:28:25 +0530 (IST) From: kaustubh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary=YsV9A30274eC_01234567_9 Subject: BUG I have installed RED HAT LINUX 7.2 on my Pentium2 233 with 64MB RAM.I have SiS6215C as my display card. I am unable to run X Server.I am attaching the LOG file herewith. Plz.give me an URGENT solution. For starters, you appear to be using a stock Red Hat Linux 7.2 installation with zero updates applied. Your first step, would then be to upgrade the system to the latest official Red Hat update packages for 7.2 prior to doing anything else. You should also be aware that Red Hat Linux 7.2 is no longer supported by Red Hat (nor is any 7.x release, nor 8.0), so you are using an obsolete OS release. The version of XFree86 shipped in Red Hat Linux 7.2 is XFree86 4.1.0, which itself is now extremely obsolete. For these reasons, you are unlikely to get any kind of URGENT solution other than people suggesting that you upgrade your operating system (or XFree86) to a newer release which better supports your hardware. The SiS driver is now very actively maintained by Thomas Winischhofer nowadays and is much superior in 4.3.0 and current CVS. Red Hat Linux 9, Fedora Core 1, and Red Hat Enterprise Linux 3 all support XFree86 4.3.0, and either of the 3 would be better than using an unsupported OS release with an unsupported XFree86. Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: TWM patches
On Sat, 7 Feb 2004, Alan Hourihane wrote: Date: Sat, 7 Feb 2004 11:53:42 + From: Alan Hourihane [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: [XFree86] Re: TWM patches On Sat, Feb 07, 2004 at 05:48:27AM -0500, Mike A. Harris wrote: On Sat, 7 Feb 2004, Alexander Pohoyda wrote: Would somebody please have a look at my TWM patches? http://bugs.xfree86.org/show_bug.cgi?id=968 XPM picture format support for icons. http://bugs.xfree86.org/show_bug.cgi?id=1078 Function to change window/icon titles. http://bugs.xfree86.org/show_bug.cgi?id=1124 IconMaxWidth parameter to limit the width of the icon window (Mozilla tends to have very long titles) These all are small enhancements, but I'd like to know if they have any chance to be accepted. Submit them in bugzilla. http://bugs.xfree86.org If they get accepted, they'll go into the CVS head in future development and the bug will be marked FIXED or similar. Mmm, Mike I guess you didn't read his email :-) If they are enhancements I suspect they'll go in once 4.4.0 is out the door. Haha! I read the message, saw URLs, and in all of my blindness didn't realize they were bugzilla URLs to begin with. Brain saw http and assumed some web page. ;o) Just wanted to make sure his efforts didn't get lost. Kindof funny I missed that though. ;o) -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Manufacturers who fully disclosed specifications for agp cards?
On Tue, 3 Feb 2004, Knut J Bjuland wrote: Date: Tue, 03 Feb 2004 15:52:53 +0100 From: Knut J Bjuland [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: Manufacturers who fully disclosed specifications for agp cards? It is possible to gain the specs for a chip by discetion for i.e R300 chip or NV 30 chips with the right tools like a electon microscope? Not unless you're using the electron microscope somehow to break into ATI or Nvidia headquarters, perhaps swinging it from a crane to break a window or something. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Manufacturers who fully disclosed specifications for agp cards?
On Tue, 3 Feb 2004, Ryan Underwood wrote: Is there some special circumstance you have to fall under to qualify for R300 specs? It seems there are a lot of people wishing they had them and not a lot of people saying I've got em... :) And in any way, i guess this doesn't include the 3D/DRI parts. Whoops, that was what I was talking about. I thought this thread was on the DRI list until I just now looked. Do we have at least 2d support for r300 cards in XFree86? For over a year now, yes. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Manufacturers who fully disclosed specifications for agp cards?
On Tue, 3 Feb 2004, Ian Romanick wrote: where is the docs for the VSA based cards (voodoo4/voodoo5)? I have been unable to locate them. In a chest in a basement at Nvidia somewhere, with a lock on it, behind a bunch of old filing cabinets, in a room at the end of a very long hallway, with spiderwebs hanging everywhere, with a sign on the door which reads: Beware of the leopard I can just imagine it in a big warehouse like where the Ark ended up at the end of Raiders. :) Funny you mention Raiders... I just watched it about 3 weeks ago, and the spiderwebs stuck in my mind and after mixing that in my brain mixmaster with some Adams, I came up with the above. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: how to build static XFree86/TinyX and Xlibs
On Fri, 30 Jan 2004, [iso-8859-1] Suresh Chandra Mannava wrote: Date: Fri, 30 Jan 2004 04:57:30 + (GMT) From: [iso-8859-1] Suresh Chandra Mannava [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Subject: how to build static XFree86/TinyX and Xlibs Dear Friends, I like to port Xfree86/TinyX by cross compiling using uclibc static(with out shared library support). My queries are 1)How to build Xfree86/TinyX statically? 2)How to build static Xlibs? 3)What are the modifications in host.def and site.def? I request your help in providing some pointers on above queries. TinyX, aka. 'kdrive' is currently maintained on freedesktop.org in the xserver CVS project 'kdrive' module. This module contains the latest kdrive source code, which you may wish to use instead if you're doing new development, as the source is much newer than what is in XFree86 CVS currently. There's a separate development list on freedesktop.org for discussion of 'kdrive' X server development also, which you might find to be useful, as it is more specific to kdrive. Hope this helps. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Linux-fbdev-devel] Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
On Sat, 31 Jan 2004, Andrew C Aitchison wrote: Yeah, that would be rather problematic, but anyway, most of the things move from the XFree86 code to fbdev code, and most often, it is not code that is copied, but the register information and such. It is always easier to get specs if you are working for XFree86 than if you plan to do some kernel driver work. On Sat, 31 Jan 2004, Benjamin Herrenschmidt wrote: The fact that it is mostly a one way is mostly due to the fact that the main problem here is seeking for HW informations. For several years the mga fb kernel driver has supported dual head and/or dvi on cards which aren't supported by the XFree86 driver (unless you use the mga_hal). I've wanted to use kernel code to add this support to XFree86, but been put off by the licence problem. David Woodhouse was in contact with Petr Vandrovec about this a long time ago, and if I'm not mistaken, there was no problem with using the kernel code to enhance the XFree86 mga driver. I don't know the details so I've cc'd David. I don't know Petr's email address. Various people have tried to get me to implement G400 dualhead support in the XFree86 driver, but I've never been that personally interested, and most people tend to be happy enough once they know hallib exists. Matrox G400 specs were available from Matrox developer relations for quite some time, and might still be. I know I had no difficulty getting ahold of them anyway. So, I think the above argument is a bit of a misnomer IMHO. I totally consider the problem to be purely communicational in nature. Any time I've contacted a kernel developer about stuff like this, or any other person who had code that wasn't under MIT license (ie: GPL), I've had absolutely no problem at all in getting them to permit it to be used in XFree86 if I desired. The only exception was Alan Hourihane's vnc driver stuff, however if I remember correctly, he is unable to relicense that because it contains or is based upon GPL code taken from other authors originally which he isn't the copyright owner of, so can't relicense it. In this case, it is totally understandable, and if I (or someone else) felt it that important, we could probably track down all of the relevant authors by hand. The synaptics driver is GPL licensed. Some of the authors of that were contacted to see if they'd consider relicensing it as MIT/X11, and to my knowledge everyone who was tracked down so far, has agreed. I don't know if there are remaining authors who still need to be contacted for that or not. So it isn't a case of it being a one way road IMHO. It might be a case of engaging in some friendly collaborative chatter with developers of other projects, perhaps even convincing them to dual-license things. That doesn't mean there isn't or never will be problems per se., but I think that it is possible to solve the problems, or most of them simply via open and polite communication between the various people involved. I don't know about others, however I at least, would never purposefully copy code into something else and not give credit for it to the original authors of the code, even if the license of that code didn't demand it. It's just courtesy if nothing else, even if not legally required on something. It also has a tendancy to encourage collaboration and code sharing. If someone came to me and pointed out I'd used their (or someone elses) code without giving credit, I would be embarassed for having somehow letting such a mistake happen, and would immediately provide proper accreditation. That's just the right thing to do. And it is of course possible for people to occasionally make mistakes with things like this unintentionally too. IMHO, the best way to work through such problems is to discuss them with the people in question privately, or publically depending on which is best under the particular circumstances, and try to straighten such matters out in a polite and rational fashion. It's just common courtesy to everyone involved in the particular code, wether that is kernel code, XFree86 code, or code from elsewhere. Just some personal thoughts... TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Manufacturers who fully disclosed specifications for agp cards?
On Sat, 31 Jan 2004, Shaul Karl wrote: Excluding Nvidia and ATI, for which I believe I know the answer, what manufacturers I am likely to see on ebay that: 1) Usually fully and freely publish the specifications of their AGP hardware. The list of vendors that freely publish their video hardware specifications publically and without requiring a non-disclosure agreement is extremely small. 2) Got themselves an X driver? As of the time of this writing, http://search.ebay.com/ws/search/SaleSearch?from=R8ht=1satitle=video+cardsokeywordredirect=1sosortproperty=1sacategory=40156catref=C1 has the following: Other (707) Other is kindof vague... Matrox (82) None of Matrox's specs are public, but some where once avail under NDA. They no longer appear to be available from their private developer website, unless I am looking in the wrong place. Diamond (61) S3 (57) Kindof vague, because Diamond didn't really produce their own chips, but instead produced boards which contained other people's chips. You would have to know the exact model of card first. However Diamond bit the dust long ago (more or less) and their last generation of hardware is considered extremely old nowadays. I'm not sure what, if any of the specs are publically (and legally) available. 3DFX (51) Voodoo 1/2/3/Banshee specs are completely public and open. Voodoo 4/5 were never released publically to my knowledge, but it would have been nice to get a copy of them even if only under NDA. Nvidia bought 3Dfx's assets and is the current owner of those specs. ASUS (29) Does not make their own video chips, you would need to know the specific chip in use on a given board. STB, Visiontek (21) Does not make their own video chips, you would need to know the specific chip in use on a given board. I am looking for a used old agp card. I dunno if anyone has put together a web page with copies of legally obtained and redistributable video hardware specifications (or hyperlinks to them) or not, but perhaps someone else here knows of such a web page. If not, you might want to search google though. I know you'll find the 3dfx docs out there for the above mentioned cards. Hope this helps. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Fall back drivers?
On Sat, 31 Jan 2004, Jerry Haltom wrote: I've been thinking about how to make X more userfriendly. Driver nvidia,vesa Is a line like this possible, or could it be a good suggestion to implement? It would allow fallback from one driver to another in case the first doesn't function. One of the main complaints I've been hearing from various people I'm working with is how X doens't Just Work. In that you can plug it in, and see a screen. Certainly most of this is up to the fault of the packager, but some of it is because they'res some things the packager would need to work around that are difficult, such as detecting that X failed to launch, so switching it to vesa mode and trying again. Generally, either a driver works or doesn't work. For cases of doesn't work, the server either dies and you're dropped back to the prompt if you're lucky, or you might have corrupted video which is not restoreable, and you're dumped back to the prompt and can't see what you're typing, or, your entire machine is hard locked and you have to hit the reset button. The other doesn't work scenario, is that the X server does start ok, the video driver has screen corruption of some kind, and the server has no idea that something is wrong. In this case, there's no way for the server to ever be able to know what's wrong. For cases of works, well... it works. The problem is that there's either: 1) no way to autodetect most if not all of the various failure cases I outlined above. or 2) If you could autodetect a failure case, in most cases the video is hosed and requires a hardware reset anyway, which requires a reboot. or 3) The hardware is totally locked, and not recoverable. There's not very many cases I can think of in which the X server could start up with one video driver, detect some failure mode, and fallback to the vesa or other driver easily. There are a few scenarios, however the number of useful cases this would allow the server to start for, compared to the end user confusion that might result, would make it not worth it IMHO. My personal opinion, is that the rest of the OS should provide a mechanism for detecting the cases where the X server dies immediately, such as a SEGV, and then tries to start a minimal preconfigured safe mode of sorts. This could be done using a driver based-upon the vesa driver. Something akin to Microsoft's VGASAVE driver used in Windows' safe-mode. Just a thought. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: libXinerama
On Tue, 27 Jan 2004, David Dawes wrote: As I remember, we ship with only a static libXinerama becuase we are waiting for some agreement from the standards people (X.org ?) so that we can have a stable, standard interface to the library. How is this progressing ? Until there is a standard we can't assume that Xinerama libraries are interchangable between XFree86, Metro-X, Xi, fd.o, or any other vendor's X libraries. We build pretty much all libraries shared now, with the caveat that major revisions bumps may happen. In CVS head you mean of course, not in 4.3.0 or earlier. Just wanted to clarify that. Another caveat however, is that when distributions start upgrading to 4.4.0, many apps compiled on 4.4.0 will get linked dynamically instead of statically, and will not run on systems that have 4.3.0 installed. A necessary pain of course that can't really be avoided however, but it's going to be a fun time with bug reports. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
On Mon, 19 Jan 2004, William M. Quarles wrote: Also, I need to be a little more explicit as to how I have my file structure setup. I never actually write the file as radeon.o in my kernel modules tree, and I don't actually have a /usr/X11R6 directory. I have a file named radeon-RH.o and a file named radeon-gatos.o, and radeon.o is just a symbolic link to which ever driver that I am using. Same thing with the X11R6 directory. So again nothing gets overwritten. This also allows me to switch drivers, especially important since the GATOS drivers have not been working very well for me. In order to switch drivers, I have exit my XFree86 session, rmmod radeon, switch both symbolic links, and startx again. If I miss any of these steps, it's not a matter of losing DRI, it's a matter of my computer locking up, so I am fairly certain that I am using the GATOS driver when I know that I am using the GATOS driver. AVview also works when using the GATOS driver, but not when using the Red Hat driver. However, since I'm sure my system is going to be doubted, I recompiled and reinstalled the Radeon module and redumped the ATI.2 XFree86 binaries, and saw no improvement. Instead of using symbolic links, you can install custom X modules in any other directory somewhere else, and use the ModulePath directive in the config file to override where the X server looks for modules first. Using multiple config files (or a single well crafted file), you can switch between drivers by using startx with commandline options. Hope this helps. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
On Mon, 19 Jan 2004, MB wrote: How does one check the version of the various items of software running on one's Linux platform, like Xfree86 etc ? xdpyinfo gives the version of the running X server on the display that you are looking at, whereas X -version gives the version number of the X server 'installed' on the computer you have a shell on. If the X server and the shell on the computer are one and the same machine, these two versions generally will match unless you have some customized multiple X server installation or something else funky. Other commands may use commandline switches such as -version, --version, -v, -V, --help or similar. Check the documentation for a given command to see if it has a method to display it's version number. Most applications do, however there is no one method that works with all software. Hope this helps. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: libXinerama
On Wed, 21 Jan 2004, Mark Vojkovich wrote: Date: Wed, 21 Jan 2004 10:10:02 -0800 (PST) From: Mark Vojkovich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: libXinerama It ships with XFree86 and RH should have installed it in /usr/X11R6/lib/ My guess, is that he has a binary application he's downloaded, which was compiled on Gentoo or some other Linux distribution which ships all XFree86 libraries shared by default, and is trying to run it on a Red Hat system, which ships libraries the way XFree86 supplies them by default, which is no shared libXinerama, and having an application failure. I see this type of problem more often than I'd like to, however the solution is simple for users experiencing problems with badly compiled binaries: Download the application's source code and recompile it properly against the Red Hat system (or other distribution conforming to XFree86's library defaults). The application will then link to the _proper_ libraries, and work on any system, including broken systems that ship all libraries shared by default presumeably in an effort to trigger software malfunctions unnecessarily when the default static libraries get incompatible API/ABIs changes without getting .so version bumps. ;o) I see this type of issue reported about libXv the most, libXxf86dga second to that, but presumeably all static-only default libs are affected. Hopefully 4.4.0 changes all static libs in an incompatible way to encourage people to not override XFree86's defaults for shared libraries. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: Upgrading XFree 86 to 4.3.0
On Tue, 20 Jan 2004, Christopher Thom wrote: Anyway, I do not have root access rights and I was wondering if it is still possible to update XFree and if so, how do I proceed? Help would be greatly appreciated. Thanks in advance. I don't know how redhat deals with user-installed packages, but it is highly unlikely that you'll be able to install this without being root. And given the update instructions require you to upgrade packages to meet dependencies, I don't think it's possible. You could certainly compile and install XFree86 into a user defined directory, and the XFree86 Imake config files let you specify the target directory if you want to use one different from the default for some reason. However that would not get you a working X server, as the X server talks directly to the hardware, and must be ran as root. That is done by the X server being ran as root via SUID, or by a wrapper application that is root being SUID. Either way, you must be root in order to set up an X server to run from a nonstandard location, and if someone is trusted to have their custom X server running built out of a user account, since it is a root owned process, they might as well be root to begin with, because they essentially have root if you trust them to compile XFree86 and then allow it to be ran as a root owned process. In any case, it is highly discouraged to try to install XFree86 in a location other than the system supplies unless one is a developer who is knowledgeable about what they are doing, including all pitfalls. For one thing, if you install XFree86 compiled from source, you will no longer be able to upgrade the OS distribution to a new OS release, nor upgrade XFree86 via rpm due to differences in the way which things are installed which have conflicting symlink directions, a situation which is not easily resolved without side effects. Fortunately however, my XFree86 src.rpm will recompile and work on Red Hat Linux 8.0, 9, RHEL 3, Fedora Core 1, and rawhide with appropriate tweaking using the comments at the top of the specfile, and having the required dependancies precompiled and upgraded as need be. If it is a RHL 7.x or other release, all bets are off, good luck, caveat emptor. ;o) Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Upgrading XFree 86 to 4.3.0
On Mon, 19 Jan 2004, Danny Holten wrote: I'm new to Linux and I'm currently running Red Hat 8.0 3.2-7 (kernel 2.4.18-14smp) in combination with a version of KDE that is unknown to me (I don't know how to check my KDE version yet :-S). I'm running XFree86 4.2.1 and wantto upgrade it to 4.3.0 since this version supports the usage of the randr extension through xrandr (it seems that randr support will also be available in KDE 3.2 in the form of krandr, but that's probably not important at this point). Anyway, I do not have root access rights and I was wondering if it is still possible to update XFree and if so, how do I proceed? Help would be greatly appreciated. Thanks in advance. My XFree86 4.3.0 src.rpm is rebuildable on RHL 8.0, but requires a few dependancies to be upgraded first. If you review the [EMAIL PROTECTED] list archives, I posted how to do this in the past. Essentially, you edit the spec file, twiddle the build_ macros, modify Release: field to indicate it is an 8.0 custom build, ie: by adding .80.custom.0 to the end of the existing Release: field. Then rebuild, and you'll get dependancy failures. Rebuild each dependancy from RHL 9 or FC1 src.rpms, and install each dep. Eventually you'll get all of the 3-5 deps figured out, and can build the XFree86 rpm for RHL 8.0. Others on xfree86-list have followed this and gotten it working as well, so there are many there who can offer advice if you need a hand. Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Re: Improvement
by the large number of vesa driver user's bug reports I see, there are numerous broken BIOSes out there which make it difficult to have a failsafe driver. I believe it would be possible to fork the vesa driver into a new driver named failsafe or somesuch, which uses VESA VBE by default, but gets special hacks put in place for systems that are reported to not work, but workarounds can be found, and detected by PCI ID and other mechanisms. I'd like to at least experiment with this in the future to see if it is a crazy idea or not. If everything is OK (after installation = first time) I can change the resolution, frequency and so on from the same Gnome or another desktop manager. I suggest try ( during installation) by default the 800X600 mode and a low refresh frequency ( if there is not plug and play autodetection). I don't disagree, however in order for it to work on _all_ video hardware, including hardware there are no drivers for, and hardware there are drivers for, but the drivers may be buggy, thus preventing the user from using X from the start, a new driver is required, which can provide minimal unaccelerated 2D video using VESA VBE and other fallbacks. Without that, it's just a pipe dream. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Re: Re: Improvement
On Sun, 18 Jan 2004, Pedro M. wrote: the sources first before committing to such an effort however, and make sure you've got a barf bag handy. ;o) This is an interesting idea. A sourceforge project would be a good thing ( with Xconfigurator or a new tool). Ah, so you haven't looked at the Xconfigurator source code yet. ;o) Nonetheless, this is the open source community, and anyone sufficiently motivated enough, can take either utility and revitalize them for their own purposes. There is user´s interest about it . See http://wiki.debian.net/index.cgi?DebianDesktop I see goals of having a friendly useable desktop there, not interest in someone bringing XF86Setup or Xconfigurator back from the dead. ;o) Now, my screen is black, without Xwindow. Why ??. When I could see it in Knoppix LiveCD without problems ??. :? Insufficient information to draw any conclusions... ;o) I think the problem is the monitor frequency, but not sure... I would like to try to change the frequency ( with a help tool that automatically restore to the last value if I don´t press the OK key in a popup window in a certain time after the changes ). This is newbie-proof, isn´t it ?? ( one uses it in Windows too ;) Some people or distributions might be interested in following that approach perhaps. That isn't user friendly however. A user friendly system would have monitors that just worked, requiring zero user intervention or configuration. Any monitor metadata needed for configuration would be supplied by the system (or manufacturers) and included with the OS (or driver updates), just as it is done in Windows. You (and others) may want to have a dialog for punching in this information indefinitely perhaps. Personally, I want to see the problem solved on a higher level, and be automatic, thus having users not need to know anything about their monitor other than how to turn it on. Why when i go to Windows the first time, it goes in a low resolution and frequency and no in XFree ??. Windows starts up generally in 800x600 nowadays (XP). It uses a special driver Microsoft supplies called VGASAVE. Good thing to imitate ;) I agree. I'm not completely at understanding at what this driver is doing specifically, however I believe that it is more or less a VESA BIOS driver, which can fallback to VGA mode if need be, and might possibly have special code in it for certain other hardware. It's more or less a failsafe driver which is good enough in order for a proper native driver to be installed for the video hardware in the system. That´s what I need for my first installation. Later, I can use another driver... Indeed, that is what I'd like to see in the future. The problem is a complex one however to solve. There is so much video hardware out there, that it is impossible to test it all. All a vendor such as us can do, is make changes to our infrastructure and defaults, release beta OS releases, get feedback from users and try to fix things in time for the final OS release. That isn't good enough though, because what's more likely to happen, is that once the OS is released, 100 times as many people use it, find problems that didn't turn up in beta testing or internal testing, and then they wonder why it doesn't work. So I'd like to see a failsafe driver in the future, but I'm not sure what the best approach is to create one in an evolutionary manner, rather than switchover overnight. Also, such a driver would need to exist for x86, ia64, AMD64, ppc, ppc64 for us, and also Alpha, sparc and other systems to be useful across the board. That complicates things a bit. I'd focus on x86 and AMD64 at first, and add bits to other architectures over time, in order to make the problem sanely approachable. I believe it would be possible to fork the vesa driver into a new driver named failsafe or somesuch, which uses VESA VBE by default, but gets special hacks put in place for systems that are reported to not work, but workarounds can be found, and detected by PCI ID and other mechanisms. I'd like to at least experiment with this in the future to see if it is a crazy idea or not. Go ahed with it. You are taking Linux to a next step forwards. Well, it wouldn't be Linux specific per se. It'd be OS neutral more or less, but it would have some architectural ties likely. I'd like to see some kind of driver emerge that is a superset of the vesa driver. I might fiddle with it myself over time as people report problems in the vesa driver to us, although I dont think such hacks belong in the vesa driver itself per se. as that would clutter the existing driver and go against it's purpose IMHO. But a driver based upon it, which gets hacked up over time might suffice. ;o) Take care, TTYL -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Improvement
On Sat, 17 Jan 2004, Ben Phillips wrote: For (transition) Windows users ( this is , the Windows user that are changing from Windows to Linux ), it´s difficult to see the XF86Config-4 file ( because they are newbies and the root, mount, cp - write permission - problems). So, I suggest, when appear the XF86 trouble-announce screen, include an option ( that could be selected using the up/down arrow keys and enter ) : Copy the XF86Config-4 and var/log/XFree86.0.log to a diskette . It would probably be better to tell Red Hat (or your favorite linux distributor) about this, if they have a feature-request page somewhere. Because I don't think there's a reason to modify the actual X server to do this; all you'd really have to do is check X's return value and if it's a failure, start a program that does this. So the linux distribution would be responsible for setting up something like this. The end user really should not ever have to know that there is such a thing as an X server config file. The average Windows user doesn't know about the Windows registry, nor how to get to it or edit it for example. Some do, but the majority of users do not, and that is a good thing. It is intentional that the Windows registry doesn't have an icon for editig it placed on the desktop by default nor in the start menu. It's not something you want end users poking around in unless they are fairly advanced enough to know what they're doing and handle the risks involved. Likewise, end users shouldn't have to edit their X config file or know of it's existance either. That isn't reality for many users quite yet, but that is the direction that things are moving towards largely, both at the distribution level, and at XFree86.org. David's done some work which is in CVS, and will be in 4.4.0 which will further help to make less users need to know the X config file's existance or muck with it. The file is intentionally not modifyable by non-root, and that wont change, however certain things that are configured in there right now, probably should in the future permit per-user overrides via some dotfile in users' homedirs. Any user can _view_ the file, by firing up any file manager, and surfing into the /etc/X11 directory, which for the most part, is even easier in Linux to do than it is for an end user to figure out what the Registry is, fire up regedit by hand, and then get lost in the maze of HKEY_FOO to find what they're looking for, even then guessing mostly. So, it's very unlikely at least on the distribution side of things, that the XFree86 config file is going to be presented to end users in any way other than what it is currently, which is to edit the file using a text editor as root if required. If our configuration tool redhat-config-xfree86 is missing some important functionality however, we welcome requests for enhancments and features. Submitted requests will be reviewed, and possibly implemented in the next OS release, or a future OS release. Keep in mind however the tool is intended to be simple to use, and _minimal_, and is not intended for the configuration of advanced items. It's intended rather to mirror the Window's control panel Display Properties applet in a sense, being simple and easy to use, without a lot of complex configuration items. It's definitely not intended to be a graphical config file editor which turns every conceivable config file option into GUI widgetry. Main goal: KISS Although, it would be nice to just write an XFree86-crash.HOWTO and have the last thing the X server says in the event of a crash be: For help, try typing: less $( locate XFree86-crash.HOWTO ) That is indeed a good idea, and something that I've considered for the future also. What I'd like to do is start out with something like that, but also have some kind of troubleshooter wizard which pops up if the server SEGVs (and the system is still useable in any way). I realize that there are some situations which users may encounter, in which they need to learn way more about the X server and it's configuration file than they would prefer to know, and that they might prefer something simpler than edit the config file as a solution, however developing such a solution goes against the goals of simplicity, and doesn't solve the _real_ problem, which is why the user needs to find the config file in the first place. I think that aside from fixing driver and server bugs so that users don't experience them to begin with, that the focus should be on making things just work, to avoid complex configuration, and any rocket science. Just my personal opinion. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: redhat-config-xfree86
On Thu, 15 Jan 2004, harry wrote: Date: Thu, 15 Jan 2004 13:56:18 +0800 From: harry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary==_NextPart_000_001B_01C3DB6F.5971F840 Subject: redhat-config-xfree86 Hello all, I have a problem during run redhat-config-xfree86 under Xwindow : monitor will be closed (include sync). But run it normally under text console mode. I think that may be brought by driver , because it's ok under Xwindow if using vesa driver. I found exec redhat-config-xfree86 will run python2.2 xconf.py and monitor will closed in cv = FX86HardwareState(xconf) this step May someone know Which XFree86 functions will be called by FX86HardwareState(xconf).Or Where may I find hints? Doesn't sound like an XFree86 problem per se, unless the X server is crashing when r-c-x starts up possibly. What video hardware (brand and model) are you using, and what version of Red Hat Linux? Also try doing: redhat-config-xfree86 --reconfig After this, try to start up X using startx and if it fails, please put your X server log and config file somewhere viewable via http or ftp, and post URLs to the files here. It's possible your particular video card model is not supported, however I'll need the above info first in order to determine/advise. TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: In short
On Thu, 15 Jan 2004, Pedro M. wrote: I suggest Xfree can create a /var/log/XFree86.0.short.log to only show the error , not all the process The purpose of the log isn't just for newbies. In particular, the log file spit out by a default XFree86 installation, is what ALL users will include in bug reports to developers, and on mailing lists and whatnot when they have problems. If that log contains less information, then the person having the problem will get less help. It's hard enough as a developer to even get a user to provide their config file and log file as it is from the start, let alone to have to ask them to then please enable more verbosity so that enough data could be seen in the log file. The log file verbosity *IS* configureable, so feel free to lower the verbosity if you desire (after reading the appropriate documentation), however I would suggest that you not bother posting log files to anyone for help (developer or otherwise) unless they are at least using the default verbosity, as you're just making life on the developer/volunteer harder by providing them with less information. I can't speak for other developers/volunteers, but if I receive a terse log file, I don't go on a handholding session, I either delete or ignore, or at best, request one with full information. This is very important to newbies and for a more easy use ( http://www.wikipedia.org/wiki/user-friendliness ). The log file really isn't there for end users, and thus not for user friendliness. User friendliness would require that users never ever have to ever see the log file or even be aware that it exists. It is a technical piece of data, intended for engineers to debug problems. It's also useful for end users to troubleshoot failures of course, but it's primary purpose is for developers to get detailed information in bug reports. Making that information less detailed by default makes everyone's life, including the newbie, more difficult. Especially the newbie, because they're more likely to not get important information in the log file to be able to troubleshoot their problem, and more likely to need help from someone else. That's my $0.02 anyway. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: XFree86 master cvsup server refuses authentication
On Sat, 20 Dec 2003, David Dawes wrote: It worked up until November first according to my cvsup cronjob logs, at which point it just stopped. However, now that you mention it, I don't remember ever seeing any public announcement that the cvsup server would be decommissioned earlier this year, nor any time prior to it becoming unavailable in November. There was no public announcement because this was never a publicly available service, as you well know since it required an unpublished password for access. Those affected by the change (the committers) were notified of the change. Yes, I am well aware it required a password. I was affected by the change, and I was not a committer. You are the one who gave out the password in the first place. Everyone else has equal access to our public anoncvs site which is well documented on our web site. That is perfectly fine. I am not complaining at all in any way about level of access. I am more than perfectly happy to use the public anonymous access. I find it just a tad duplicitous that you complain about the loss of the privileged access that you yourself campaigned to abolish. Wrong. I am not in any way complaining about loss of priveledged access. In fact, I don't care at all about that, and I have absolutely no interest whatsoever in _ever_ having priveledged access to anything from XFree86.org to be quite honest. So don't twist words thanks. What I am complaining about, is that people, including myself, whom did have authorized access to a particular service, and have been using it for over two years, did not receive proper notification that that service would be terminating. Yes, some of the Nazgul did, but they weren't the only ones with authorized access to those services. All I am asking, is that prior to disabling something people use every day, it is polite to at least notify them of this. The only reason I (or anyone else for that matter) would use the master repositories, is that they are a bit faster, and always more up to date than a mirror. I would have gladly started using the public mirror a year ago however, had I been asked to, or had I known that the master repository access was going bye-bye. It was an oversight that this service wasn't terminated at the same time as the other old member-only services when this list as opened up, and for that oversight I apologise. That's fine, apology accepted. But please don't try to make it look like I'm upset about losing special access, as that is not at all the case. I'm upset because I've done many cvs rdiff operations in which I did not get the results I expected and didn't have the time to figure out why, so I moved on to other things. If there is anything else that I have any priveledged access to with the master XFree86 password, please immediately revoke my access to it, and notify me of the change if you'd be so kind. I would much prefer that over surprises like this. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 master cvsup server refuses authentication
I've been using the master cvsup server to mirror XFree86 to my workstation for about 2.5 years, but for the last week or so I am getting: Server error: Authentication failed The message would seem to indicate that the server is up, but refusing authentication for some reason. Has something changed recently with how cvsup access to the repository is handled? Any help appreciated. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
ATTN: video hardware/driver contact at Intel
I am looking to get in touch with someone at Intel whom is responsible for Linux video driver support, to discuss some issues. I'd have emailed Mathew Sottek, however I haven't seen him post publically for quite a long time, so I'm not sure if he's still involved with Intel video related issues. If someone from Intel could forward this to the proper person, or anyone else reading this who knows whom I should contact, and could provide me with an Intel email address contact, I'd greatly appreciate it. TIA -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: I852/855G and widescreen support.
On Mon, 1 Dec 2003, Davide Dozza wrote: The problem is that the xfree86 driver relies on the video BIOS to provide the mode information. if the BIOS does not have the mode info for 1280x800 then you are out of luck. Unfortunately intel has not provided specs for setting the mode apart from the BIOS. Yes, it's true. The BIOS does not have the support of this resolution, but: - Accelerated-X provides a driver that is working at 1280x768 that is also not supported into the BIOS (not like 1280x800 but much better than 1024x768) Which evidentally means that Intel has given XiG their specifications under NDA, or some other business contract, or XiG has reverse engineered Intel's chips or somesuch. - Windows has drivers working fine. No surprise there, since Intel's Windows video drivers are most likely written by Intel themselves, or by some other party for Intel, and they almost certainly have the complete hardware specifications for every aspect of Intel's chips, and probably even direct access to the hardware engineers themselves. This means that there is a way to overcome this limitation. By saving your money and acquiring Intel Inc., then providing the specifications to the community? Or are you suggesting something else I'm missing. What part of WE DO NOT HAVE THE DAMN SPECIFICATIONS is unclear? The way to overcome that, is for Intel to provide the specifications. What are you missing? Are there any working plan on this matter? Yes. The working plan is: 1) Wait until Intel releases the specifications to the public. 2) Wait until some developer gives a shit about the problem enough to take those specs and do something about the problem. Are there any experimental patches that I can try to use? No. Can I use framebuffer instead of native i810 driver? If so any suggestion where I can find information about? Unless you have a rich Uncle of considerable influence at Intel or something, there is nothing you can find out about and absolutely nothing you can do about this. The code can _only_ be written via having the specifications, or reverse engineering. Feel free to single step the video BIOS, and provide patches to implement the desired functionality. Good luck. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: I need help setting up my video card
On Wed, 26 Nov 2003, Andrew Lester wrote: Date: Wed, 26 Nov 2003 18:38:49 -0600 From: Andrew Lester [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Subject: I need help setting up my video card Hi, I am using Red Hat Linux 9 with Xfree86 4.3 and I have a VisionTek Xtasy 9200 SE 128mb PCI video card, and there are no VisionTek video cards, and VisionTek dosn't make drivers for linux. So I am forced to use my crappy Intel 845 video card, and I can't play UT2003 with it. so If you could point me to drivers to it or put them in the upcoming release of Xfree86 I would greatly appreciate it. Radeon PCI hardware is supported only experimentally with 3D in XFree86 4.3.0. It works for some people and not at all for others. It isn't clear what the problems are, and nobody is working on it currently, however volunteers are always welcome to try to pinpoint the problems on their systems. You need to enable ForcePCIMode for it to work at all. Be sure you are running the latest updates that have just been made available via up2date or ftp also. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Resolution supported by XFree86
On Thu, 13 Nov 2003, pankaj srinivasan wrote: Date: Thu, 13 Nov 2003 20:13:19 -0800 (PST) From: pankaj srinivasan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Resolution supported by XFree86 Hello, I am in an urgent need to obtain a resolution of 1920X1200 using XFree86 4.3.0. I am using LynxOS 4.0 operating system and am running XFree86 4.3.0 on LynxOS 4.0. The graphics card being used is ATI Radeon Mobility 9000 that supports an even higher resolution than that required as mentioned above. Could you please confirm whether XFree86 4.3.0 supports the resolution of 1920X1200. The X server has several built in video modes which are based on the VESA GTF and other standards, but it does not contain an exhaustive list of every possible video mode in every refresh rate, or every possible video mode in other aspect ratios. The X server is, and always has been able to use user supplied video modelines provided in the config file. If you require a video mode which is not built into the X server, you can calculate your own video mode timings and provide them in the X server config file and the new mode will be used assuming it is valid in the current configuration, and specified. You can use various tools to calculate your own video modes, including the gtf tool which comes with 4.3.0. Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: can't start original Red Hat GUI after Xfree86 installation
On Fri, 14 Nov 2003, Pete Maley wrote: I just installed Xfree86 version 4.3.0. In order to do this I had to disable X in the /etc/inittab file and enable the command line login. The installation went smoothly. However, now that it is installed I cannot get back to using the original desktop that I was using before installation. I changed the /etc/inittab file back so that it starts an X session, and I do get an X session when I login, but it isn't the same as what I had before. I am using Red Hat 9. Any help would be appreciated. Red Hat Linux 9 comes with XFree86 4.3.0. Did you install 4.3.0 from elsewhere? -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: ATI radeon IGP 320M
On Fri, 14 Nov 2003, Alex Deucher wrote: Date: Fri, 14 Nov 2003 07:21:10 -0800 (PST) From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: ATI radeon IGP 320M 4.3.0 did not support the IGP chipsets. you either need to upgrade to the cvs version of xfree86 or use a later rawhide RPM. I think redhat included IGP support in its newer rpms. Yep, Fedora Core 1 has the original IGP support that went into CVS many months back (2D only), and there is an erratum in progress right now for Red Hat Linux 9 of XFree86 4.3.0-2.90.43 which is a build of 4.3.0-43 rebuilt for RHL 9 which is almost identical, and also has the Radeon IGP support. This should be available either today or Monday I believe. HTH -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: nv driver obscurities...
On Sun, 9 Nov 2003, Alex Deucher wrote: I agree that with hex values the driver is much harder to read and debug (as a casual developer). that's part of the reason the radeon driver is so well developed and feature-rich. however, I'd say that most drivers in xfree86 use hex values rather than symbolic names so symbolic names are hardly the norm. the nv driver is no more obscured than the trident or 3dlabs, etc. drivers. I'm not trying to fix a bug in the trident or 3dlabs drivers however. However, if I were, I also don't have hardware specs for trident or 3dlabs hardware, and as such, symbolic names would be easier to deal with in both of those, or any other video drivers as well. A moot point however I suppose, as none of those drivers is ever likely to have any major work done on them in the future other than by their respective existing driver maintainers. Let's hope and pray that none of the existing maintainers gets hit by a bus, or we're screwed. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Mon, 10 Nov 2003, Alex Deucher wrote: Date: Mon, 10 Nov 2003 06:38:24 -0800 (PST) From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: nv driver obscurities... Sorry I haven't looked at the glint driver in a while. I was just trying to make a point that lots of drivers out there use hex rather than symbolic names. I seemed to recall glint as being one of them, but I guess I was wrong. That doesn't make it good practice. Symbolic names let people know what things are for, or provide clues at least. They also help to avoid many typo related problems. For example someone mistakenly saying 0x35c somewhere would much more easily go unnoticed than a symbolic name. That's why we have structured programming constructs such as macros to begin with - to make programming more readable and easier to understand. But obviously the point I'm trying to make is a debateable one, and I'm not going to change my mind on my thoughts regarding symbolic names, and I expect you and others aren't going to throw away years of programming and change your opinions either. We both now know what each other's opinions on the topic is, and that none of us are going to convince the other to change their opinion or their coding practices, so further discussion/debate is probably not useful as far as development is concerned. Let's just respectfully agree to disagree with each other on coding practice, and move on without further discussion. Thanks. Respectfully yours, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: Who maintains the monitor databases?
On Sun, 9 Nov 2003, Mark Vojkovich wrote: I don't know of an XFree86 monitor database. It's not really a good solution to the problem (doesn't scale well). Monitor identification based on EDIDs (plug and play info gathered through the video card's I2C bus) is preferable. I agree 100% with you of course, however DDC probe is not always available for one reason or another. If DDC probe is not available, having an end user manually key in their display's horiz/vert ranges and other settings is not a really good solution though. The best solution is to use DDC probed EDID data, and in lieu of that, fall back to a list of predefined known monitors which come from a monitor database of as many monitors as possible, in order to maximize compatibility and user friendliness. That can only really done either with a monolithic database as is common now in various OSS OS distributions, or via distributed per-product and per-vendor metadata files such as Windows .INF files or a similar solution. So, it's definitely prefered to use EDID, but unfortunately KVM's, some video drivers, and other situations require a monitor database to exist, either monolithically or distributed. I'm collecting monitor .INF files in order to try to unify this for all distributions in the future. People can attach .INF files or links to them to the video-hwdata project feature/bug tracker on sourceforge and I'll be putting them together over the next several months hopefully. Take care, TTYL -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: nv driver obscurities...
On Fri, 7 Nov 2003, Mark Vojkovich wrote: Everywhere in the driver hex values are given premultiplied by 4 it seems, and specified as VALUE/4. The register pointers are dword pointers. The register offsets are byte offsets. They are written as VALUE/4 so that I can grep for VALUE. This is done so that it's easier for me to maintain. Converting everything to dword offsets will make my job more difficult. Ah, ok. I'm not sure why you are bringing this up. I'm bringing it up because I have no idea how Nvidia hardware works, have no Nvidia documentation, the source code of the driver is quite obfuscated by not using symbolic names for things, and that was one obfuscation that I thought might be something that could be cleaned up. Having no way of knowing why it is coded the way it is other than making a random guess, or by asking someone who does know, how is one supposed to find out why it is coded this way? I would think it would be obvious that since I am maintaining it, it would be in the form that is easiest for me to maintain. Sure, that works fine for me if that is the case, at least once it is known that there is a valid reason, and that it is done intentionally. But don't assume that I can mind read the intentions of an obfuscated driver. Would you prefer other developers and potential developers did not ask questions at all, and instead went off and worked on other projects? Seems every time someone asks for information on how something works in the codebase that they don't understand, or asks for clarification on something, they can't get a straight or clear answer. It's really no wonder volunteers get put off from contributing to the XFree86 project. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Sun, 9 Nov 2003, Kevin Brosius wrote: Well, gee, Mike... You're question was filled with negative assumptions about why the driver might be 'obfuscated'. You shouldn't take offense if Mark is a little short with you. Focus on asking a question, leaving off the insinuations, and you'll get better answers. A shorter question like I'd find it clearer if the nv driver used #defines for registers rather than hardcoded values. Does anyone object to changing it? would tend to go over smoother. I suppose that is fair enough. I'm trying to debug an annoying problem in the driver for some users having problems, and seeing hexadecimal registers everywhere instead of symbolic names is very frustrating. I suppose I should have thought my posting out more clearly before asking my original question. My response didn't take my original mail into account either, of which I had forgotten my wording. My apologies for the flame. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Sun, 9 Nov 2003, Thomas Winischhofer wrote: I suppose that is fair enough. I'm trying to debug an annoying problem in the driver for some users having problems, and seeing hexadecimal registers everywhere instead of symbolic names is very frustrating. Mike, I really can't imagine how symbolic names would help you if you don't have hardware docs. (Well, unless one uses names like BIT_7_IS_FOR_INTERLACE_BIT_6_IS_FOR_DOUBLESCAN_BITS_5_4_ARE) For me as a developer, if I have the choice between for example SetReg(Part2Port,0x43,0x27); or SetReg(Part2Port,RTVFILCNT,0x27); I will certainly go for the first variant. Datasheets usually are sorted by register number. Using the number instead of a name saves me from 1) remembering the symbolic name I or the datasheet gave the register (Was that with '_' or without in the middle? Did I use caps?), and 2) grepping BOTH the driver AND the datasheet (or my defs.h) every time I check or debug stuff. Just my humble $.2 Having zero datasheet, but having symbolic names is more likely to give useful information than is 0x43. It isn't a substitute for full documentation by far, but it is better than nothing, especially if you are a volunteer trying to fix something for someone else, the more information you have the better. Using non symbolic names is like surfing the web with IP addresses only, the obvious difference to this analogy being that domain names don't always remain pointing to the same IP address. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Upgrade fontconfig in cvs.
On Thu, 6 Nov 2003, Boris wrote: Date: Thu, 6 Nov 2003 10:28:37 -0600 From: Boris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary==_NextPart_000_0005_01C3A450.BD38C8A0 Subject: Upgrade fontconfig in cvs. It seems the fontconfig in cvs is very old (1.0.2) and needs to be upgraded to 2.2.0. Reading varios emails and posts, it seems the older fontconfig has problems with some TrueType fonts and the 2.2.xx files the problem. Also the fc-cache v1.0.2 crashes (segmentation fault) when run during system startup where as 2.2.0 does not have that problem. Any possible way we could get the latest fontconfig into the xfree86 cvs? To avoid the SEGV, run fc-cache as: HOME=/ fc-cache btw. I downloading it from anoncvs and then make World. I recommend just using the upstream fontconfig instead. It's easier to stay current that way, and to update it separately. Wouldn't hurt of course though to update the included fontconfig also, it does have many stability, performance and other improvements. Might be considered too late at this point though, but most Linux and other OS distributions I think ship the newer fontconfigs for quite a while now, so it shouldn't be too hard to find prebuilt packages for many OS's also. Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
nv driver obscurities...
I'm curious about some of the obscurity in the nv driver. In particular, almost everywhere in the driver, registers are addressed numerically, and not by symbolic names. That on it's own is obscure enough to make things difficult to tell what's going on, but we know the deal with Nvidia documentation well enough, so I won't bother to worry about that much... Various people have commented though about certian obscurities like the following being rather odd: chip-Rop= (RivaRop *)(chip-FIFO[0x/4]); Why 0x/4 and not just plain 0x? Everywhere in the driver hex values are given premultiplied by 4 it seems, and specified as VALUE/4. Was that done just to intentionally obfuscate the driver source further? Or was the original driver (or current driver for that matter) actually maintained elsewhere with real symbolic names and whatnot, and then obfuscation scripts ran over them prior to committing to the XFree86 tree? Would cleanups that remove this obfuscation and make the driver more readable be considered useful, and potentially accepted? Or is there some other reason I'm missing as to why the driver is so obfuscated? -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
the nv driver at all, it is a total replacement for it, and it is completely proprietary. There is a very small part of it which the source code is available for which is not driver related, but which is a glue or shim later to glue the Nvidia binary blob to the kernel. This small bit of code is not helpful for video driver authors however, it contains no video control bits, just kernel glue. There are documents on DGA in the XFree86 tree, and you can probably find pointers on the XFree86 web site. As others have said, however, I'm not sure it will help you, because DGA is an application interface that gets called from user-mode. Even if I can't use DGA directly, the source should provide information on how to handle the hardware, so that would help me also. I have to take a look at these. Look at the driver source in XFree86 for foo_dga.c files for example stuff. Hope this helps. Good luck with your work! Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
stuff for you is most likely the 2D XFree86 nv driver source code, and whatever might be in the Linux kernel framebuffer driver, or BSD et al. Since no docs are available for this hardware though, you may have a tough time doing anything with it without the aide of someone familiar with the hardware. Wish you the best of luck nonetheless. Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Does anyone out there use mkxauth at all?
On Tue, 4 Nov 2003, Marc Aurele La France wrote: On the other hand, if it turns out nobody really uses it anymore, it might be best to just drop it from our distribution. I haven't used it in many years myself now, and kindof assumed most people use other mechanisms nowadays too, but didn't want to remove it and face the wrath. ;o) Feedback appreciated. If I were you, I'd make this determination based on whether or not mkxauth is carried by any other vendor. If so, stick a patch for it in our bugzilla (for inclusion post-4.4 timeframe). If not, base your decision on whether or not RedHat wants to continue supporting it. I guess that's as good a way as any to determine wether it is useful. Any Linux or BSD vendors or distributions out there use/ship mkxauth? If so, please speak up. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
; they just call into other functions within that driver. Indeed. I think the key part of your message, and I'm in complete concurrence with you, is read the source Luke. ;o) For the benefit of the original poster, the source of the drivers is in: xc/programs/Xserver/hw/xfree86/drivers The source of the Nvidia proprietary drivers is in: /dev/null ;o) Hope this helps. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Does anyone out there use mkxauth at all?
I'm curious as to wether or not anyone out there uses mkxauth at all out there still. My reason for asking, is that someone here at Red Hat (Jim Knoble) wrote it a long time ago, and we've included it in our distribution for a long time as well, however I'm not sure how many people out there use/require/want/care about it at all. I've not received any bug reports or problems about it forever now, which could be indicative that it doesn't have bugs, or could be indicative that nobody uses it anymore. If people do use it still, and there is usefulness in keeping it around, the original author Jim Knoble has previously authorized me to relicense the script from GPL to MIT in case the script would be considered something useful to include in upstream XFree86 along with xauth. So if anyone out there uses mkxauth at all still, please respond to me and let me know wether you still consider it useful or not, and if you'd miss it if it went away. If there is enough interest in it still, I'd be more than happy to submit the script under MIT license to XFree86.org if they're interested in having it somewhere in the repository. On the other hand, if it turns out nobody really uses it anymore, it might be best to just drop it from our distribution. I haven't used it in many years myself now, and kindof assumed most people use other mechanisms nowadays too, but didn't want to remove it and face the wrath. ;o) Feedback appreciated. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: i830 video ram problems
): Will attempt to tell the BIOS that there is 8128 kB VideoRAM (WW) I810(0): Extended BIOS function 0x5f11 not supported. Looks like your BIOS update may have perhaps removed support for this? Do you have an XFree86 log from an old startup with the old BIOS image? (II) I810(0): Before: SWF1 is 0x0001 (II) I810(0): After: SWF1 is 0x0008 (II) Loading sub module int10 (II) LoadModule: int10 (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a (II) I810(0): initializing int10 (WW) I810(0): Bad V_BIOS checksum (II) I810(0): Primary V_BIOS segment is: 0xc000 (II) I810(0): VESA BIOS detected (II) I810(0): VESA VBE Version 3.0 (II) I810(0): VESA VBE Total Mem: 832 kB (II) I810(0): VESA VBE OEM: Almador Graphics Chip Accelerated VGA BIOS (II) I810(0): VESA VBE OEM Software Rev: 1.0 (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Almador Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): BIOS now sees 832 kB VideoRAM (--) I810(0): Pre-allocated VideoRAM: 892 kByte (**) I810(0): VideoRAM: 8192 kByte (==) I810(0): video overlay key set to 0x101fe (--) I810(0): Maximum frambuffer space: 8040 kByte Although here it shows you do have 8192. Your X configuration is configured to 8bit depth however.. ick. (--) I810(0): A non-CRT device is attached to pipe A. No refresh rate overrides will be attempted. (--) I810(0): Maximum space available for video modes: 832 kByte Indeed, looks like there is a huge problem here. (II) I810(0): Allocated 64 kB for the scratch buffer at 0x7fce000 (II) I810(0): Updated framebuffer allocation size from 1536 to 2048 kByte Hmm, this seems whacky to me, but I don't know a heck of a lot about this particular driver's operation. Perhaps someone who works actively on the driver or someone from Intel can comment. If all you've changed since it worked properly is the BIOS however, and the BIOS CMOS setup is configured properly, I can't see how this could be a driver bug. A flash of the BIOS would generally wipe out whatever configuration settings the CMOS was set to, requiring you to reconfigure it manually first, but if that isn't the problem, I'd consider this a newly introduced BIOS bug. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: XFree (4.3.0) 32b graphics ...
, although if they just read what I wrote above, they are on the path to recovery. ;o) Summary: People confuse computer terminology when refering to colour depth and what that specifically means, and how it is implemented in hardware and how software programs the hardware. What is commonly refered to as 32bit color is incorrect usage of terminology and very misleading. There is no such thing as 32bit color.[3] There are pixels that are 32bits in size, of which only 24 bits contain colour depth information and 8 wasted bits[1]. Both Windows, and XFree86 use this by default regardless of the fact that both name them using different terminology. So if you're using 24bit colour depth in XFree86, and also in Windows (refered to in Windows as 32bit color), then you are using the *exact* same thing period. There is absolutely *no* difference in the amount of color. Footnotes: [1] In 32bit per pixel framebuffer configurations, the 8 bits of pixel space that are not part of the colour depth information are not always wasted. This extra 8 bits is sometimes used to hold alpha-channel information used for translucency. For the intents of discussing the above however it is easier to just treat the non-colour-depth bits as being wasted. I comment on this only because often someone will try to point out these 8 bits are used for alpha on occasion, which is true, but is irrelevant to the oversimplified discussion of colour depth and framebuffer pixel sizes. [2] Some hardware _does_ implement 30 bit colour depth, generally as 10 bits per RGB component and an optional 2 bit alpha channel (mostly useless). This is also highly specialized and not supported nor useful on a modern desktop, not to mention how horribly slow it would probably be with each component being split across byte boundaries. [3] 32bit colour depth could at least in theory exist, however to my knowledge, no video hardware implements a 32bit depth mode in which all 32bits are used for colour depth information. If there is actually such hardware, it is quite irrelevant to modern desktop systems, and would instead be custom hardware/software used in the medical, scientific and perhaps movie making industries. Hopefully this text file clarifies any confusion you might have had concerning 24 vs. 32 bits with respect ot colour depth between XFree86 and Windows. Take care, TTYL -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Server regeneration no longer works
On Thu, 30 Oct 2003, [ISO-8859-1] Frank Gießler wrote: snip cvs rdiff -D 15 October 2003 -D 16 October 2003 Xserver/os gives: snip Thanks, it is indeed the same bug. I've marked the one in Bugzilla as fixed. Is there an easy way to figure out the dates for the diffs? Also, cvsweb.xfree86.org allows easy viewing of changes. That's how I found out. But one has to know which files to investigate, and if more than one file is involved it can be a real PITA. Or am I missing something? Search cvs-commits list archives, and/or use the cvsps tool to generate patchsets. You can find the latter with google. The documentation blows goats but the tool works awesome once you mess with it for hours and hours wasting time until you figure out the right magic. ;o) It's a godsend. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Is it possible to move application displays between hosts?
On Tue, 28 Oct 2003, John Duperon wrote: occassionally we have users login to RedHat Linux machines who have started applications that they would like to keep running in the background while someone else uses the machine. So, say I start a program we have here for one of our microscopes and it is in the midst of processing data. However, someone else needs to be on this machine to capture data. Can I tell the machine to display the graphical interface for this program on another machine once the program has started? I know it is possible to change the DISPLAY variable and xhost + on the other machine. But if the program is already running, is it possible to do the equivalent? If this isn't possible currently, it would be a really great thing to have in the future. Search google for the applications xmove and x2x, also vnc might be useful. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: X Windows is not running
On Wed, 29 Oct 2003, VARSHIKA ANANTHAKRISHNAN wrote: 1. XFree86 version - 4.1.0 2. The Operating System and its version. - RH Linux 4.1.0-25 3. What video hardware you are using. - Intel® 82845G/GE/GL/GV 4. A clear description of the problem. - I am not able to boot into graphical mode Intel i845 video hardware didn't exist until a year or two after XFree86 4.1.0 was released. Your video hardware isn't supported. You need XFree86 4.3.0 or later for this video hardware to be supported. Red Hat Linux 9, Fedora Core 1, and Red Hat Enterprise Linux 3 all ship with 4.3.0 and support this chipset. Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Cygwin/XFree86 Bugs?
On Sat, 25 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: [EMAIL PROTECTED] is an ML anyone can subscribe to. I am, and, I believe, so is Egbert. No, not currently. I usually go to the web interface and look at the open bugs, process new ones that can be handled quickly, or try to assign them to an expert on the specific area. There are a lot more areas than we have experts - in these cases I try to work on the ticket myself. This, and the low quality of some of the submissions, consumes a considerable amount of time. Indeed, you're doing most of the bugzilla work alone; it's a pity there aren't more people helping with that. Perhaps, but Egbert and the others contributing do such a good job, that if everyone at XFree86.org actively used bugzilla, there would be zero open bugs to fix! ;o) Where's the challenge in that? ;o) If everyone used bugzilla, we'd have to go out of our ways to find new bugs to report just to keep everyone busy. ;o) On a much more serious note though, I'm very happy that bugzilla has worked as well as it has, and I'd like to thank everyone both at XFree86.org, and in the community for all the contributions people have made, both reporting bugs, supplying patches, helping track down various issues, and committing fixes to CVS, etc., etc. Good work to everyone who has contributed! -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: compiled XFree 4.30 on RH8, but fonts are ugly now
On Sat, 25 Oct 2003, Brujus wrote: Date: Sat, 25 Oct 2003 08:50:39 +0100 From: Brujus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Subject: compiled XFree 4.30 on RH8, but fonts are ugly now Hi, i use RedHat 8.0, compiled XFree 4.30 sources, everything went smoothly, installed it, everything ok again, checked the XFree86.0.log, everything seems ok, X starts normally, but the fonts are ugly now, antialiasing seems disabled. I even tried to compile FreeType 2.1.4 afterwards, thinking that it could be any freetype related issue, but no (and when i turn off antialiasing at KDE3 it gets even worse). Anyone has any clues/tips? Red Hat XFree86, freetype, Xft, etc. is modified with various enhancements which dramatically improve font display quality. If you recompile any of those components from stock sources, you lose those improvements. Hopefully these improvments will be approved in the next major releases of the upstream freetype, Xft, etc. components and no longer require special patches to achieve these results. In the mean time, the easiest and best way to get 4.3.0 running on Red Hat Linux 8.0, is to recompile the 4.3.0 src.rpm from rawhide, which I intentionally keep it so it works on Red Hat Linux 8.0 and newer. To do this, you need to: Take expat, ttmkfdir, freetype, fontconfig src.rpm from RHL 9, and rpm --rebuild each one of them in RHL 8.0. Upgrade each binary package they produce including the -devel packages. ttmkfdir will probably not allow you to install it so leave it alone for now. Now install the rawhide XFree86 4.3.0 src.rpm with rpm -ivh. Then go into the spec file directory and edit XFree86.spec, near the top you'll find a lengthy comment discussing the build_n target options. You will want to set build_psyche to 1 (Red Hat Linux 8.0), which then sets various conditionals throughout the build process to tweak for RHL 8.0. Set all other build_ options to 0 to disable them. Then edit the Release: line, and add your initials to the end after a ., ie: Release: 41.bt to indicate it's your custom build. That does 3 things: 1) It allows you to upgrade to the new packages with rpm easily 2) It allows you to easily upgrade from this build to the next build later on. 3) Easily differentiates between an official Red Hat build and your custom build. Once XFree86 is built (it takes 1-2Gb of free disk space), you should upgrade to it where the binaries got put, by using: rpm -Uvh XFree86-*.rpm ttmkfdir*.rpm As long as you're running the latest Red Hat official kernel update, you'll also end up with DRI working without any fuss. If you have previously installed XFree86 compiled from raw sources however, you'll have one problem. If you try to install the newly built XFree86 rpms as above and receive an error concerning /etc/X11/xkb, then do the following: rm /etc/X11/xkb rm -rf /usr/X11R6/lib/X11/xkb rpm -Uvh XFree86-*.rpm ttmkfdir*.rpm That should resolve the conflict, and allow X to be installed cleanly. If you have problems, feel free to ask for more help on [EMAIL PROTECTED] as numerous users are there who have used my special instructions above and got it running nicely. I'm also on the list and will help if I see the post and have time. Hope this helps, TTYL -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Xft.h freetype includes qn.
On Sun, 26 Oct 2003, Tyler Retzlaff wrote: Just a quick sanity check to see if I've hosed my X11 headers. If I want to use Xft.h X11/Xft/Xft.h must I add -I /usr/X11R6/include/X11/freetype2 for the freetype/freetype.h? Or should it be unnecessary? Just for some background I'm seeing this: /usr/X11R6/include/X11/Xft/Xft.h:35 :31: freetype/freetype.h: No such file or directory Where freetype/freetype.h is actually in X11/freetype2 not X11/. Always use pkg-config to locate a given library's headers, lib locations, etc. if possible. Freetype supports pkg-config, so as long as your freetype has installed the pkg-config metadata properly, pkg-config will give you the information you need. Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: ATi Radeon TV output
to people due to the volume of email we receive, please visit our website at http://blah to see what is available. But that's just me... :o) -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Sapphire Radeon 9000 dual-head problem
On Sun, 26 Oct 2003, William Gallafent wrote: As mentioned in the subject I have a Sapphire Radeon 9000 dual-head video adapter that I'd really like to get working. I had various problems with dual-head on a Sapphire Radeon 9000 using plain 4.3.0. I advise you to pick up a recent snapshot (or use current CVS, or current DRI CVS) since there have been many improvements since 4.3.0 was released. Dualhead on Radeon is totally broken in 4.3.0 stock due to a bug in the radeon driver which didn't get noticed/fixed prior to release. If you use dualhead, when the mouse crosses from one head to another, the 2nd head will shutdown. That bug is fixed in the XFree86 4.3 (xf-4_3-branch) stable branch, CVS head, and most Linux distribution's 4.3.0 builds. Another option which is generally useful for dualhead is: Monitorlayout CRT CRT Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: FATAL ERROR 4.3.0: make install
On Fri, 24 Oct 2003, Markus Pilzecker wrote: installing in lib/GL/mesa/src/OSmesa... make[4]: Entering directory `/home/war/4.3.0/source/xc/lib/GL/mesa/src/OSmesa' gcc -c -o ../../../../../lib/GL/mesa/src/X86/common_x86_asm.o ../../../../../lib/GL/mesa/src/X86/common_x86_asm.S In file included from ../../../../../lib/GL/mesa/src/X86/common_x86_asm.S:43: ../../../../../lib/GL/mesa/src/X86/matypes.h:9:22: assyntax.h: No such file or directory ../../../../../lib/GL/mesa/src/X86/common_x86_asm.S:44:33: common_x86_features.h: No such file or directory ... I had the same problem, but the origin was located earlier. The build process of XFree86 seems to be very [=too??] tolerant against first errors and a kind of hides them by proceeding on: Already during ``make all´´, I had this problem, and the very reason was, that my /usr/bin/cpp could not have been found due to a permission inconsistency. make World WORLDOPTS= will cause the build to fail immediately in all versions of XFree86. I believe this has been made the default in CVS head. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Shared libraries
On Fri, 24 Oct 2003, David Dawes wrote: even after the recent changes to XFree86-current libGLw, libXau and libXdmcp are still not built shared. I've got a report that this causes problem with certain 3rd party applications which try to build shared objects using these libraries. So may I ask what is the reason that these libraries are not built shared? I'm not sure about the reasons for libGLw. The other two can be built shared providing that the build is setup so that the static versions are always built too, and the X servers (at least) continue to link against the static versions. Linking the X servers against shared versions can be re-examined if necessary after 4.4 is out. I think one of the fixes I've got here for 4.3.0 might resolve this for libXau, and some other libs. We experienced a problem where shared libs trying to link to static libs caused application failures due to non-PIC code being used. I'll have to have a look at this soon and port forward to HEAD if need be, and send a patch in. Not 100% sure that our problem is identical to this one though. TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: startup delay in 4.3
On Thu, 23 Oct 2003, Valentine Kouznetsov wrote: I have weird problem. Using RedHat9 X4.3 takes too much time to start-up. Using the same config file on debian, X 4.2 takes by a factor of 5 less time to startup X. I use the same laptop in both cases (dual Linux boot :). Any clue why it happens. Config files as well as logs are attached. I also confirm the problem installing X4.2 from RH8 on RH9 (but in this case I've got incompatibility among other libraries when I startup kde). Looking at your log file from RHL 9 I see: (II) RADEON(0): Video RAM override, using 16384 kB instead of 16384 kB (**) RADEON(0): VideoRAM: 16384 kByte (64-bit DDR SDRAM) Don't use the VideoRAM option ever, unless it is absolutely required for your hardware to work properly. The Radeon driver in particular properly detects the amount of video memory on all existing Radeon hardware properly. Specifying this option when it isn't needed is known to cause various different problems. It may or may not be causing problems in your case, but it is unnecessary and should be avoided nonetheless. (WW) RADEON(0): Cannot read colourmap from VGA. Will restore with default Looks like it's unable to read the palette. Nice to see whoever wrote that error message spelled colour correctly at least. I haven't looked at the source code, but it's possible there might be a delay caused by this theoretically. This: (II) Bus 0: bridge is at (0:0:0), (0,0,4), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000c (VGA_EN is set) (II) Bus 2: bridge is at (0:30:0), (0,2,4), BCTRL: 0x0006 (VGA_EN is cleared) (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-CardBus bridge: (II) Bus 3: bridge is at (2:3:0), (2,3,3), BCTRL: 0x05c0 (VGA_EN is cleared) (II) PCI-to-CardBus bridge: (II) Bus 4: bridge is at (2:3:1), (2,4,4), BCTRL: 0x05c0 (VGA_EN is cleared) ... looks very fishy to me. Not sure wether or not it's related to your problem though. Also one feature which present in RH9 and X4.3, once I startup X three keyboard indicators (caps lock, etc.) starts blinking. This is not a case of X4.2. That is an indicator that you are having a kernel panic/oops. Check your /var/log/messages for the error messages. I have a hint that if I'll change Protocol for mouse in X4.3 for instance to Microsoft, delay is gone, but of course mouse is crazy. What kind of mouse are you using? Serial/USB/PS2, and what brand/model? Sounds like you're having a problem with the mouse driver trying to autodetect or probe your mouse. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: redhat 9.0 on dell latitude c800
On Thu, 23 Oct 2003, Nathan Zafar wrote: Date: Thu, 23 Oct 2003 21:31:29 -0400 From: Nathan Zafar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Subject: redhat 9.0 on dell latitude c800 hi all. i see others with similar problems but am unable to get this going when i try what's posted. my xserver won't start. i then get put into command line only mode. here is my XFree86.0.log file. It tells you right in the error message in the log file what the problem is: XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2) Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.20-3bigmem i686 [ELF] Build Date: 27 February 2003 Build Host: porky.devel.redhat.com Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.4.20-6 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Feb 27 10:06:59 EST 2003 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 23 20:40:03 2003 (==) Using config file: /etc/X11/XF86Config Parse error on line 115 of section Screen in file /etc/X11/XF86Config ^^^ 1280x1024 is not a valid keyword in this section. ^ Right here. (EE) Problem parsing the config file (EE) Error from xf86HandleConfigFile() So, now we go to line 115 in the Screen section of the config file, as specified in the error message: Section Screen Identifier Screen0 Device Videocard0 MonitorMonitor0 DefaultDepth 24 SubSection Display Depth 24 Modes1600x1200 1400x1050 1280x1024 1280x960 1152x800 1024x768 800x600 640x480 ^ There is no quotation mark here. EndSubSection EndSection Perhaps you just read through the file too quickly and missed your typo... ;o) -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: X Crashing.
On Thu, 23 Oct 2003, gareth wrote: Date: Thu, 23 Oct 2003 09:39:28 +0100 (BST) From: gareth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: X Crashing. Hi. Recently, X has been crashing on my machine whenever I've left it left alone for more than a few hours. Until a week or so ago, this would happen maybe once a week, but now it's doing it every time. I've asked various friends, all of whom are far wiser than me, but they have no idea. I've included below bits of information it seems you would like. But if I have missed things, please let me know what else you want. Thanks, Gareth - From /var/log/gdm/\:0.log : XFree86 Version 3.3.6a / X Window System ^^ Ancient. (protocol Version 11, revision 0, vendor release 6300) Release Date: xx November 2000 ^ 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/FAQ) ^^ Your X server is on the verge of 3 years old currently. The message above indicates if it's more than 6-12 months old, you are using a rather old server and should upgrade to the latest version. The current version of XFree86 X server is 4.3.0, which should support that card ok. Hope that helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Cygwin/XFree86 Bugs?
On Wed, 22 Oct 2003, Harold L Hunt II wrote: Learn something new every day :-). Looks like the subscriber list is publicly viewable (and very small). Where? I see nothing here: http://xfree86.org/lists.html I also get nothing when I try to forge a link to the list: http://www.xfree86.org/mailman/listinfo/developer/ Is there a different mailing list server for bugs.xfree86.org? http://bugs.xfree86.org/mailman/roster/developer Kindof interesting that XFree86.org has finally switched to bugzilla, and none of the developers get bug report emails sent to them except Michel and Marc... Fortunately, Matthieu, Egbert, Alan and others at least use the web UI and take care of the majority of reports that come in, and do so very well, since the number of open reports is quite small compared to the entire size of the database. In that light, I'd consider bugzilla quite a success so far, even if it doesn't even exist to some developers. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: help : vga driver
On Tue, 21 Oct 2003, michael keren wrote: I'm using Linux redhat 7.2, and i'm having a problem with my graphic adapter driver. My graphic adapter driver doesn't listed in the linux drivers library. My graphic adapter is gigabyte ati radeon 9200se 128mb. Could i request driver for my graphic adapter...?thanks Red Hat Linux 7.2 nowadays is very ancient, you should upgrade to Red Hat Linux 9 at least, as 7.x becomes unsupported Dec 31, 2003. Also, the XFree86 release in that version of the operating system is 4.1.0 which is extremely ancient. The Radeon 9200SE is a brand new video card, and is not even supported in the latest official XFree86 release, however it might work in XFree86 4.3.0 (included in Red Hat Linux 9) if you use the ChipID directive (man XF86Config) and tell the X server that it is a Radeon 9000. Rawhide XFree86 contains support for the newer models of Radeon, however the 9200SE is not yet supported. XFree86 developmental/experimental CVS head has support for the latest cards, and I plan on backporting the rest of the ATI Radeon support once I have spare time on a weekend to fiddle with it (hopefully soon). So, here are your options roughly: - Upgrade to Red Hat Linux 9, and fake the card is a 9000 via the config file ChipID option. This should work for 2D, and might possibly even allow 3D acceleration to work as well. - Wait a short while for the next Red Hat OS release Fedora Core 1 to be released. That will occur very soon, and will contain support for this card out of the box, or via an update shortly after (depending on if I have time to hack on it before the final release). - Investigate if ATI's latest proprietary binary only drivers on their website support this card or not currently, and use that instead. ATI's drivers are available usually for XFree86 releases 4.1.0, 4.2.x, and 4.3.0. I don't know if they support 9200SE yet or not however. - Use the vesa driver for now until official XFree86 support for this card is available. - Hack the PCI IDs for this card into the Radeon driver source code, and recompile it yourself. If you've never compiled XFree86 before, this one will be lots of fun. ;o) - Try using Alan Hourihane's XFree86 CVS head binary drivers, if they're up to date, they should have 9200SE support in them I believe. While it's unfortunate you've got a card that is not yet officially supported, the variety of options I've presented above should give you something useable in less than an hour, and give hope for the future at least. ;o) Hope this helps you out. Take care, TTYL -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Re: Re: Radeon 7000 with Red Hat 8
pictures, your X server will say sure, I can hold that for you and will increase 400Mb in size. It has been ages since I've seen someone report a bug like this that actually turned out to be an X server memory leak, so while it is certainly theoretically possible that there is a memory leak, it is much more likely you have buggy applications leaking pixmaps or other resources. With 128Mb of total system memory, and your video hardware configured to use 10Mb of that, that leaves only 118Mb of memory for the system to use. That is not very much at all on a modern Linux/X11 desktop running GNOME or KDE with antialiased fonts, etc.. If you run such low memory systems, you really should consider disabling various things to minimize resource usage, or switching to alternative desktop setups with openbox/fluxbox/blackbox/or some other window manager, and use smaller applications. Mozilla, OpenOffice, Nautilus, and other GNOME/KDE major applications are very resource hungry, and will consume a lot of memory in your system - some of that via the X server. Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Radeon 9000 DRI
On Thu, 23 Oct 2003, [iso-8859-1] Olivier wrote: Date: Thu, 23 Oct 2003 00:11:58 +0200 (CEST) From: [iso-8859-1] Olivier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Subject: Radeon 9000 DRI Does the next xfree release (4.4.0) include the DRI module for 3d acceleration (ATI RADEON 9000) ? Considering that XFree86 4.3.0 has DRI support for Radeon 9000, 4.4.0 most likely will have too. It is very unusual to see a modern already supported video chipset /lose/ support in a new release of XFree86. I'd bet my own Radeon 9000 on it. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Logitech Elite Keyboard Layout
On Mon, 20 Oct 2003, J E Dog wrote: Is this your particular preference? Why yes it is. And it's the most popular preference of most developers working on most software projects who even know how about how to generate patches with diff and apply them with patch also. The majority of developers working on any OSS software that I know, be it XFree86 or something else This is not 'something else'. This is XFree86. There are, at the latest counting, 5 forks of XFree86 code out there. Why don't you spread your good cheer? I've yet to see a single developer of anything stand up and shout that they prefer some other format of diff other than unified diff. I'm not particularly interested in your opinion nor your banter in any case. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Fonts] Re: libfreetype-xtt2 bench
On Tue, 21 Oct 2003, Juliusz Chroboczek wrote: Date: 21 Oct 2003 18:41:54 +0200 From: Juliusz Chroboczek [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: libfreetype-xtt2 bench What exactly are you arguing with ? DD The notion you expressed that adding features to the freetype backend DD goes against a goal of encouraging application developers to move to DD client side fonts, I never said such a thing. I said that adding features to the freetype backend goes against a goal of putting core fonts into maintenance-only mode. IMHO, if xtt's functionality can be obsoleted by including the same functionality into the freetype module, then there is a lot less code to have to care about, and xtt can be removed. The resulting code will be less to have to maintain, and if it is the only codepath to have to care about, all users will be using it. In that case, presumeably if there are problems, the people who contributed the new changes will be interested in fixing them for their own benefit, and contributing those fixes for future releases. I agree with you that core fonts is something that preferably all developers will move away from, and that that is to be encouraged. I don't think it is fair however to encourage this by throwing away useful work that someone has done, or to ignore potential improvements in the code that someone else is interested and/or willing to do. X core fonts may be getting obsolete but they'll be around with us for years to come yet. Best not to be short sighted. ;o) -- Mike A. Harris ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[XFree86] Re: (no subject)
On Tue, 21 Oct 2003, Satish Nair wrote: Date: Tue, 21 Oct 2003 10:03:18 +0530 From: Satish Nair [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Subject: (no subject) Hi, When i am trying to install S3 trio64v2 card on linux 7.x i get the following error; 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: Tue Oct 21 10:31:26 2003 (==) Using config file: /etc/X11/XF86Config Parse warning on line 36 of section Keyboard in file /etc/X11/XF86Config Ignoring obsolete keyword LeftAlt. ^^ Parse error on line 36 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() Your X server configuration file is invalid. My guess is that you're trying to use an XFree86 3.3.6 config file with 4.x. Please let me know whst is to be done to resolve the above issue. Delete your config file, and create a new proper one with Xconfigurator as root. Hope this helps. TTYL P.S. You are using an ancient X server release which contains numerous security flaws, which have since been fixed and released as updates to that OS release. It is recommended that you update all software on your system to the latest updates provided by Red Hat, including XFree86 4.2.1. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Radeon 7000 with Red Hat 8
On Tue, 21 Oct 2003, Shakil Anwar wrote: Is there any way to get a Radeon 7000 to work with Red Hat 8 (which uses XFree86 4.2.x). Of course.. Radeon 7000 has been supported since Red Hat Linux 7.2, and backported to 7.1 via an XFree86 update also. I see that it is supported by XFree86 4.3.x which is installed by Red Hat 9 and indeed this works fine on my system. However I really need to use RH8. Can I simply install XFree86 4.3 onto RH8 to resolve this ?? XFree86 4.3.0 is not in any way required for Radeon 7000. The stock default supplied X server with Red Hat Linux 7.2, 7.3, 8.0, and 9 all support Radeon 7000 out of the box. I am a Linux newbie so apologies if this is a dumb question but I have spent some time searching the web for an answer and got a useless reply from Connect3D support (my Radeon 7000 supplier). If Radeon 7000 does not work for you in Red Hat Linux 8.0 out of the box, present the details of the problem you experience, and most likely you are just doing something wrong, and someone can help you get it working properly. Generally speaking: redhat-config-xfree86 --reconfig ... should result in a working Radeon 7000 setup. Thanks. Also if I do need to install XFree86 4.3.x then is there an .rpm anywhere ? You don't need to install 4.3.0. I have rpms for Red Hat Linux 8.0 and higher however, and instructions on how to obtain and use them were posted to [EMAIL PROTECTED] about a month or so ago, and should appear in the mailing list archives if anyone is interested.. You really do not need 4.3.0 however. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Re: Radeon 7000 with Red Hat 8
On Tue, 21 Oct 2003, Solomon I. Shorser wrote: Is there any way to get a Radeon 7000 to work with Red Hat 8 (which uses XFree86 4.2.x). Of course.. Radeon 7000 has been supported since Red Hat Linux 7.2, and backported to 7.1 via an XFree86 update also. I see that it is supported by XFree86 4.3.x which is installed by Red Hat 9 and indeed this works fine on my system. However I really need to use RH8. Can I simply install XFree86 4.3 onto RH8 to resolve this ?? XFree86 4.3.0 is not in any way required for Radeon 7000. The stock default supplied X server with Red Hat Linux 7.2, 7.3, 8.0, and 9 all support Radeon 7000 out of the box. really? Yes, really. well, I am running RedHat 9 with a Radeon 7000. Redhat can detect the device (so it does indeed look supported) but I can't get direct rendering (or any other sort of 3d hardware acceleration) working. It is definitely supported. I can say that with extremely high degree of confidence because I am the Red Hat XFree86 maintainer, and have been for 3 years. So I very much know what hardware is supported, and have tested it and use it daily personally. Are you using the Red Hat supplied kernel, or your own custom kernel? 3D works out of the box without any special fooling around. I've tried installing dri, but it all it does is cause segfaults when I try to run glxgears. I've gone through every trouble shooting tip and nothing seems to work. You don't need to install anything special or really do anything at all out of the ordinary. The only possible explanation I can remotely think of which would result in 3D not working would be: 1) If your motherboard's AGP chipset does not have kernel agpgart support, or if it is experimental and requires the kernel agp_unsupported=1 commandline option. In this case, it is your motherboard chipset that isn't officially supported, however enabling this might allow you to use 3D. or 2) If you are using a *PCI* Radeon 7000. DRI 3D acceleration is only officially supported on AGP hardware. PCI DRI Radeon support is very experimental, and disabled in the driver by default. It requires using option ForcePCIMode to work, and that option seems broken in 4.3.0 stock release. I haven't tested it lately to see if it works or not. If neither of the above describes your situation, and you are not using a custom kernel, and _are_ using an official Red Hat kernel, then please post your X server config file, log file, and the output of /var/log/messages, as you are definitely experiencing a unique problem. Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Re: Re: Radeon 7000 with Red Hat 8
On Tue, 21 Oct 2003, Solomon I. Shorser wrote: 1) If your motherboard's AGP chipset does not have kernel agpgart support, or if it is experimental and requires the kernel agp_unsupported=1 commandline option. In this case, it is your motherboard chipset that isn't officially supported, however enabling this might allow you to use 3D. Yes it is an AGP. I will try this option and let you know. err... I guess I would add it to the Xfree86Config file in the device section as...? It's not an XFree86 option, it is a kernel agpgart driver option. You use it in modules.conf. It's actually agp_try_unsupported=1, I made a typo above. Or for nonmodular agpgart kernels, it's a kernel commandline option agp=try_unsupported HTH -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: How to make a user to use X application rather everyone on a server?
On Tue, 21 Oct 2003, Myung-Jwa Kim wrote: right now, I made everyone on a server to run X applications(such as xclock) by 'xhost + localhost' but I want one user(such as IMA) to use x application other than root. Is there any commond or way to do that? No idea what IMA is. Presumeably it requires root priveledge to execute from the gist of your statements though. In this case, use the su command or use sudo, or make it SUID root. My server is Redhat 2.1. I installed a application(IMA) that needs to run x application. I guess that that installation did assign x application privilege to the user(IMA) that I used to install that application. I'm not exactly sure what you mean by assign x application priveledge.. Doesn't make much sense but after I did OS updates(including xfree86 something), the IMA can't run x application such as xclock. What is IMA? It's a bad idea to assume everyone is going to know some obscure program name and how it works. one more thing. can I add localhost permanently? I need to type 'xhost + localhost' whenever I reboot system. By default, using both su and su - in Red Hat Linux will have X authorization set up automatically via PAM. You can however set up what you want by reading the xhost manpage, and paying attention to the FILES section where it mentions /etc/X*.hosts Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: RedHat 9 and SGI 1600SW Question
On Tue, 21 Oct 2003, Matthew Bunyard wrote: Date: Tue, 21 Oct 2003 15:11:45 -0500 From: Matthew Bunyard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; format=flowed Subject: RedHat 9 and SGI 1600SW Question I have a RedHat 9 box with a Number 9 IV Revolution video card and XFree86 4.3.0 installed. I have found the documentation on the ModeLines for the XFree86 4.3.0 for the Number Nine card and an SGI flat panel (I have the 1600SW), but need some clarification. Do I just add the ModeLines to the end of the Monitor Section of the XF86Config file? man XF86Config gives the complete syntax of the config file including what directives go into which section(s). Do I remove the HorizSync and VertRefresh lines that are present? Why would you? They specify the monitor's minimum/maximum Horizontal and Vertical refresh rates. That has nothing to do with what video modelines you use, although it does restrict what modes are available to within the safe limits of the monitor. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Logitech Elite Keyboard Layout
On Sun, 19 Oct 2003, J E Dog wrote: I have writen an xkb layout for the Logitech Elite Keyboard. Maybe someone can use it or it will be included into XFree. All code submissions and patches, should be filed in bugzilla at: http://bugs.xfree86.org as individual uncompressed file attachments (not cut and pasted into the comment field). All patches should be in the unified diff format and created against the current CVS head preferably. A unified diff can be created by doing: diff -Naur xc.orig xc yourpatch.patch Excuse me, but I have never seen that rule on the website anywhere. I didn't say that it was a rule on the website anywhere. Please point out where I said that. Where did it come from? It came from the will of hundreds and thousands of open source developers who dislike context diffs and other forms of diff patches, and prefer the unified diff format, as unified diff format seriously saves a lot of time when you're a developer working on a software project, in particular a project as large as XFree86. Is this your particular preference? Why yes it is. And it's the most popular preference of most developers working on most software projects who even know how about how to generate patches with diff and apply them with patch also. The majority of developers working on any OSS software that I know, be it XFree86 or something else usually go as far to straight out refuse all patches that are not in unified diff format. Unified diff is the easiest to read, easiest to understand, and the easiest to hand edit should the need arise. It also applies much more cleanly than the other formats. I'm only preaching to the choir while educating you however, so I wont bore the rest of the people who already know and agree with me, by going into further detail. If so you should state so plainly and not make it a rule of the Project's. Is this your personal opinion? Or the opinion of the XFree86 project? If so please state than plainly when making useless comments in response to useful suggestions by others. In my opinion, you don't exactly contribute much to the XFree86 project other than a rude attitude and obnoxious comments shouted from your high horse from time to time for your opinion to matter much to me about pretty much anything anyway. I'm surprised that I haven't procmailed you to /dev/null yet. And to be quite honest, I'd be more than happy if you'd do the same to me, if for no other reason than I'd see both less of your postings *and* your generally useless responses. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: naming issues
On Sun, 19 Oct 2003, Sebastian Gomez wrote: I'm using XFree86 with Debian in a iBook computer, and also in a iMac running Mac OS X and I think the project name is absolutely incoherent. I don't understand why the name XFree86 refers to an specific piece of hardware. The name is historical. Originally, XFree86 was strictly for Intel x86 (ia32) hardware only. Obviously, when the name was chosen, nobody thought that it might end up being used on non-x86 hardware some time down the road or they would have chosen a name that wasn't linked to x86. The primary goal of the XFree86 Project is to produce XFree86and to make it the best freely-redistributable Open Source implementation of the X Window System by implementing it on as many hardware and software platforms as possible Launching X11 it's like putting a sticker of I love intel on my PPC computers. It's very easy to think another name less computer specific like XFree, XFreePC (yes, mac's are also personal computer's) or something else. XFree86 is not limited to the PC platform either. XFree86 runs on a great number of CPU architectures and computing platforms out there. XFree is probably a better name than XFree86, however changing it would be more cosmetic than anything, not that I'd object to such a name change of course. Congratulations on your great job and I hope you can solve this problem ;P I really don't see it as a problem. The software works, and that is what's important. The amount of effort it would take to go through the entire source code tree, renaming directories containing XFree86 name to something else, and also renaming all permutations of XFree86 throughout the code, documentation, website(s) out there would not only probably cause much more confusion to people, but CVS history would be lost on many files, and there's no doubt a number of other problems that would be created for no real major gain other than a cosmetic change. Also XFree86 is a registered trademark IIRC, and the XFree86 organization is incorporated. It would require reincorporation under a different name probably, and numerous other things. All of the time that numerous people would spend on doing all of that, would most likely be better spent on fixing bugs in the code, and adding new features and improvements. That's my $0.02 anyway... -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Betr: Re: xfs install on RedHat machine
On Fri, 17 Oct 2003, Eamon Walsh wrote: Anyway, the check for /usr/X11R6/bin/X to determine wether or not to start xfs has been removed for quite a while now, as it makes it difficult for people to start xfs, who don't run an X server on the same machine and just want to use xfs for network font serving. It seems like the best way to do it would be to still do the check for /usr/X11R6/bin/X, but only if TCP is disabled. TCP is disabled on all installations by default, and requires a user who very much knows what they're doing in order to enable it. The level of complexity that all this checking this and that requires mixed with the matrix of actual users usage patterns is quite complex. You'd have to grep the configuration file to find this out, though. Don't know if that's worth it. It isn't worth it. The school of KISS (Keep It Simple Stupid) reigns supreme here IMHO. Our X installation uses xfs by default for better or worse, and probably always will do so, so we require xfs to be installed if you install X at all. Our config tools configure X to use xfs for font serving also, and expect it to be there. Again - for better or worse, that is the way it's been for a long time, and there's no major beneficial reason to change that now, especially with the overwhelming majority of all new applications using fontconfig/Xft for font handling. I'm leary of making any major changes to our core fonts handling nowadays, as it would risk breaking a known working system that we have now for little to no real major gain. So, following the KISS principle, if a user installs xfs - it gets started at boot time by default period, because we need to have a default, and the default is chosen based on what is easiest for the general non-technical user out there. Someone who even knows xfs exists, is generally in a position to disable and/or uninstall it if they don't need it and know they don't need it. The general end user isn't necessarily tuned in enough to know what xfs is, or that they need it though. Any amount of AI to determine wether or not xfs should start at boot time would be invalidated in 10 minutes by some user with an obscure startup need out there. The way it is now, it is simple. It starts unconditionally and if you don't want/need it - you know that, and you have the technical skill most likely to disable it easily enough and get your $0.0001 worth of memory wastage back. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proposal for documentation patch - driver man pages, HWCursor, SWCursor
On Fri, 17 Oct 2003, Mark Vojkovich wrote: I checked driver man pages in xc/programs/Xserver/hw/xfree86/drivers/*/*.man Almost every driver implements the options: HWCursor, SWCursor however they are documented differently. Further, having two separate options is silly. It is a two-state switch: either the driver tries to use a HW cursor, or it always forces a SW cursor. What happens if you specify both, or neither? I'll bet different drivers come to different conclusions. That's why I only documented one of them. We could settle on one to document. The nv driver supports both because people seem to use either. This is more for the list than you Mark, as you know this of course. ;o) The X server has a plethora of ways of indicating the same boolean meaning: Option swcursor Option SWcursor Option swcursor yes Option sw cursor TRUE Option hwcursor false Option hwcursor no Option NoHwcursor Option sW___c___u__R S or Y eS all of the above options should do the exact same thing, and enable software cursor (or disable hardware cursor depending on your perspective). Likewise, similar options for hwcursor will enable it. The majority of drivers default to using the hardware cursor in all cases, however some of them default to using swcursor either due to hardware cursor limitations, or bugs in the hardware cursor code in the driver, sometimes just for one chip. The colour ARGB cursors add a new twist to this as well, as some hardware simply doesn't support using ARGB cursors in hardware cursor mode. Without specifying swcursor nor hwcursor you'll generally get hardware cursors if the driver supports it on your hardware and doesn't disable it due to hardware limitations or broken driver workaround hacks. If you're using the new colour mouse cursors, then wether you get hardware cursors or not depends on the driver and chip also. Since you might get hardware or software cursors by default depending on the variety of variables involved, both of the hwcursor and swcursor options make sense in a general X server sense. As a human, I think I want hardware cursors or I want software cursors rather than I want hardware cursors or I want no hardware cursors. Also, removing one of the two options from XFree86 would not really provide any benefit IMHO, and it would break config file compatibility and a lot of pre-existing usage. If it were deemed that this was the way to go anyway, and one of the two options were to be eliminated across the server and all drivers as a whole, I would only find that rational if all other options in the X server followed suit, and thus remove all redundant options at once. There is a lot of redundancy in the config file syntax. That was purported as a feature way back when I presume, and it's debateable wether or not it was a good thing or a bad thing I guess. ;o) Hopefully it doesn't change majorly between non-major X server generations, as that makes upgrades a PITA. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: Where's the cursor?
On Thu, 16 Oct 2003, Randy wrote: I'm in the midst of writing documentation for an application I wrote and I'm using screen dumps for visuals. Why doesn't the mouse cursor get captured during the dump? It gets turned off. Also, mouse cursors are usually done in hardware, and so don't appear in the physical framebuffer memory, they're overlaid visually in hardware. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Where's the cursor?
On Fri, 17 Oct 2003, Mark Vojkovich wrote: It looks like the render extension cursors are merely generated from .png files and don't use an intermediate format. The Bluecurve cursors don't ship with XFree86, but that ones that do (Whiteglass, Redglass) are in the server tree at xc/programs/xcursorgen/whiteglass/... Render extension cursors are something I personally don't know much about, so I don't know if there's a utility to extract data from the .xcf files. .xcf files are gimp's native file format, which are generally used when creating the initial images, which then get converted to .png later with one of a few methods. The Bluecurve cursors were created all in one huge image, and then cut up into individual icon files using Owen Taylor's icon-slicer app. Hope this helps. -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Kernel Module? On second thought...
On Fri, 17 Oct 2003, David Fox wrote: I think that the wisest approach is, instead of suggesting a kernel module to the XFree86 folks, you do two things. First, suggest a kernel module to the Linux folks that implements a protocol for accessing the resource you are trying to use. Then you go to the XFree86 folks and suggest a module to utilize that protocol in the X server. That's not any better. Unless someone comes up with a real problem that isn't just theoretical, and a real solution which requires or will work best being in kernel, and then implements it, and puts their money where their mouth is and proves that the solution not only works, but solves a real problem / really does improve performance, etc. they're not going to be taken seriously. You just aren't going to get anywhere with random hypothetical guesses as to what will be a magic performance boost until you crack out the tools to find performance hits, and write the code to fix them. If that can be done in XFree86 itself - great. If it can be done in the kernel, fine. If it can be done in XFree86 without requiring the kernel, and done as well or better in XFree86, even better, as then reliance on a random OS's kernel module is avoided. The kernel folk are going to tell you the same thing - that you dont just go and implement random code in the kernel and hope it fixes something. You find a problem, and you investigate potential solutions to it. If that involves the kernel - fine. Then you come to both the X developers and the kernel developers (of the particular OS kernel) and say something to the effect of: My following attached patch that implements foo in the Linux (or BSD or whatever) kernel, and an appropriate patch for XFree86 which uses this functionality optionally is attached. I've done performance tests on foobedoo in X and have determined it isn't possible to improve the performance of foobedoo without an additional kernel interface. My kernel interface implements this, and does so as cleanly as I could devise. The performance gain in fooblahblah applications is n% so this is definitely worth it and not just a negligible gain. I'm interested on hearing what other developers think of the patch I have created, and what feedback they can give so I can improve it, or try alternate methods. Or something to that effect. As I said before, making random suggestions to use kernel modules abstractly like it's a godsend for performance isn't going to get anyone anywhere, wether their intentions are extremely wll intentioned or not. So to take the whole topic out of the pie-in-the-sky land, and put it on the concrete ground: What _specific_ area of XFree86 performance are you (or anyone else) thinking needs improvement, what solutions have you investigated or even thought about which could improve this performance by modifying XFree86 itself, a driver, Mesa, or other userland code? If you do think the kernel might help for this problem, what steps have you taken to determine if that is truely reasonable, and have you tested your theory? Have you discussed that one small idea with other developers to see what they think about the alleged problem, wether it even really is a problem at all, how important it is, what other solutions there might be, etc. etc. etc. All of this lets stuff things in the kernel, because kernel code is automatically 2 times faster right? stuff gets boring fast. Show me the code. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Betr: Re: xfs install on RedHat machine
On Thu, 16 Oct 2003 [EMAIL PROTECTED] wrote: Well in the end the answer was much simpler than expected. I am creating a RH kickstart CD and was playing with the packages I should include. I did include xfs but didn't include X. A message from the ini.d/xfs file would have been nice indeed as xfs doesn't start when there is no /usr/X11R6/bin/X. Well, people can't have it both ways. You complain that xfs didn't start, someone else complains that xfs starts and they don't need/want/use it. We have to choose one single thing and everyone gets it. Anyway, the check for /usr/X11R6/bin/X to determine wether or not to start xfs has been removed for quite a while now, as it makes it difficult for people to start xfs, who don't run an X server on the same machine and just want to use xfs for network font serving. Yes, this will probably upset the people out there who don't want xfs to start up if they're not using an X server. As I said above though, people can't have it both ways as we can't read people's minds. The initscript can be disabled like any other system service, so people who install xfs from now on, will have it enabled by default (and it has TCP disabled also by default), and those who don't actually want to use it or need it, can disable it themselves as an end user configuration customization. I feel this makes life the easiest for the largest amount of users out there, and that's one of our goals. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
problems. Whatever someone out there proposes, if it is an obvious good idea, and developers agree it is worth investigating, we're likely to see sometime in the future perhaps. Random end-all-be-all solutions hypothesized from non-technical analasys wont get taken very seriously until real world measureable data exists. There's also the show me the code that implements your brainchild idea phenomenon too, and that sometimes leads to good ideas coming forth, and other times ends up as a substitute for Godwin's law. From the point of view of the actual end user, if they run something and it is visibly slow, the underlying reason why doesn't really matter. They can think it is because X11 is a bad idea perhaps, but it doesn't matter - they aren't going to kill X11, and they couldn't if they tried. However, if they use X and it doesn't perform for their needs, then they obviously should try another implementation, try other drivers, or use some other OS such as Windows or Mac OS/X until popular X implementations can meet their needs acceptably. That might mean implementing new X extensions, or it might mean accelerating stuff in video drivers, or doing some algorithmic and/or assembler optimizations here and there. IMHO, what is most important isn't chitter chatter rumours. What is important, is asking a particular person/user/admin/whatever what problem they are specifically experiencing which a perceived performance problem is occuring. Then we can analyze that problem and fix it, or propose a solution for the future. Until that problem is fixed, any amount of advocacy for X, at least for that person isn't going to meet their needs, even if you can get 1FPS in glxgears. That's the way I see it anyway. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfs install on RedHat machine
On Wed, 15 Oct 2003 [EMAIL PROTECTED] wrote: Date: Wed, 15 Oct 2003 09:10:01 +0200 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Subject: xfs install on RedHat machine I have installed the minimal set of packages with RedHat 9.0 and have installed XFree86 xfs later using rpm. XFS is not running after reboot while it is in init.d and rc.d[12345]. Anyone know what causes this behaviour. run ntsysv as root and enable the xfs service. That will make it start at boot time. You can also use service xfs start to start it from the command prompt. If it does not start, look in /var/log/messages and you will find out why it is not starting. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfs install on RedHat machine
On Wed, 15 Oct 2003, Chris Burghart wrote: I saw a similar problem recently; essentially, the init.d/xfs script was being run, but no xfs got started and there was no clue in the logs about what was failing. Then I realized that my root filesystem was full. After I cleaned up some space and rebooted, everything worked fine. Silly, but true... Kindof funny actually... some people have complained that xfs should be updated to log this using syslog, however in the majority of systems out there, /var/log is on the same partition as /tmp usually is - /, and if the disk is full, the disk is full. I seem to recall xfs was updated to do this anyway, but I'd have to do a test setup to confirm it. Not a priority... -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
