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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Re: How to render multiple cursors?
On Wed, 15 Oct 2003, david mattatall wrote: Why would you want more than one pointer? and more importantly how would it be used? 1. It's quite conciveable that two cursors could be used to perform two actions at the same time, I mean most of us use multitasking OS'es so the cursors should reflect that. 2. USE YOUR IMAGINATION! Two usb mice, one in your left hand, one in your right. You use one to click and drag a window out of the way and you use the other to choose your favorite song on XMMS. The uses of the technology will expand to fit the technology, that's what OpenSource development is all about. (actually what first is needed is someone with ambition AND coding skills. Like many others, I only have the latter.) I find it rather unlikely that someone would use a mouse in each hand for any real world non-hypothetical because I can sense. Come up with an actual *tangible* reason, and then it's something to discuss IMHO. Open source development isn't all about devising and implementing useless features nobody will use for any useful purpose. I wonder if you are not making life more difficult than it needs to be. How? By proposing an Idea? I see no demand for your idea out there. Actually the more I think about the more I really want to know the answer to thoes two questions. See above :) Feel free to implement it, and then fix all window managers and other affected applications out there, then propose it as an enhancement if you like. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
On Tue, 14 Oct 2003, Alexander Shopov wrote: Kernel modules are not inherently faster. the reason directx (and openGL) seem so fast on windows is because the manufacturers and MS tweak the drivers for every last bit of performance. Plus they are able to utilize interfaces that are not accessable in xfree86 due to IP concerns. Some xfree86 drivers actually are faster or support more features than their windows counterparts. Hi Alex, How can we prove this with real life data? I do realize XFree86 is VERY fast in some situations - for example I have seen Quake 3 running faster on GNU/Linux than on Windows - on the same hardware. I'm not quite convinced that that is an objective comparison however. Was Quake 3 running in both operating systems with the exact same 3D settings? Windows drivers support the full hardware featureset, and games are more likely IMHO to use the full hardware set of features in Windows. The XFree86 open source drivers support only a limited set of the functionality available in Windows. If you disable all hardware features in Windows which are not available under Linux, and configure everything else to be as close as possible for an accurate apples to apples comparison does Linux perform better? My experience is that while Linux DRI support is decent for most users, it doesn't outperform Windows. One needs to also make sure the same AGP mode is being used, etc. and that MTRR is functional... Of course I'm not discounting your claims, just a bit skeptical as to how the exact tests were ran, and how it was instrumented, or if it was just a placebo'ish it seems faster type of thing, etc... What can we really do to prove to infidels that XFree86 works great? Logic most of the times fails, explanation like usage of IPC, latency tests etc. also fails, people just scream Kernel graphics gd, X bd and it is demos like this that help me shut them up. What can we do? Quite frankly... random uninformed people making claims that X is slow, without any shred of a clue or properly deduced scientifically measured and reproduceable instrumented data, will always be out there. We can't stop people from spreading unfounded rumours nor from making random guesses as to why they or someone they know may be experiencing slowdowns in some application or another. X itself isn't slow by any stretch of the imagination, and there have been studies done that show this precicely. I don't think trying to prove anything to people who will believe whatever they want to believe helps us any at all personally... The best thing any of us can do, is continue to properly and scientifically analyze the X server, it's video drivers, and other related technologies, profile them, optimize them, etc. Right now, the biggest hit on the desktop is probably unaccelerated RENDER operations. That's what most users likely see as desktop slowdowns currently. Over time, those things will improve as people write support. The most important thing, when comparing Linux/X/XFree86 to Windows performancewise however, is that apples to apples comparisons are being made, and to understand exactly what component and/or level of the puzzle any problems that are found reside in. In the case of RENDER for example, that isn't an X11 performance problem, it is an XFree86 video driver limitation currently. Nothing that can't be overcome in the future. For video games and 3D however (to get back on specific topic), proprietary drivers that implement all of the hardware's special do-dads are very likely to always outperform the OSS drivers, simply because more resources are spent on the proprietary drivers, and more engineers with more deeper knowledge of the hardware are working on them. Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SiliconMotion - unable to restore VGA screen on exit
On Fri, 10 Oct 2003 [EMAIL PROTECTED] wrote: What is the status of the problem of being unable to restore the VGA screen using the SiliconMotion drivers? The status of the problem is whatever the bug report states. If it doesn't state what you'd like to hear, then that is because nobody has anything to comment as of yet about the report(s), and nobody is likely investigating the problem. Bugzilla 124 702 have reported the problem. Some comments indicate there is a working patch, while some comments (and my experience) indicate that the problem still exits, even using the latest 4.3.99.x XFree86. It's not clear if anyone is actively working on the problem. The bug is reported against XFree86 4.3.0 on ia32. I doubt there are many people who: 1) Even have silicon motion hardware 2) Have the hardware you are having problems with 3) Are running NetBSD 4) Can reproduce your problem 5) Have had the time and interest in investigating the issue. I would add that in my case, using a Panasonic CF-28 ToughBook (laptop), the problem exists using Solaris 8 and 4.3.99.x XFree86, but does NOT exist using RedHat Linux with 4.2 XFree86 on the same machine. Also, as I reported in Bugzilla 702, using Solaris 8 and 4.0.2 XFree86 Porting Kit, I did not have the problem either. If 4.2.x works for you, why don't you just continue using 4.2.x? Or alternatively, extract a binary 4.2.x driver module from the older release and rename the 4.3.0 driver and plop the old one that worked in its place. I would appreciate feedback on any planned efforts on this problem. If any XFree86 Developer in the LA area needs to look at my machine, I may be able to accommodate them to get this problem solved. Everyone working on XFree86 does so as a volunteer. When people report bugs, if there is a volunteer who works in that area of code, be it a library, the X server, or a driver module, etc. and they have the time and inclination, and the problem interests them to fix, they generally respond to reports and fix them. If you display all bug reports, you'll notice the majority of them are fixed and closed. Since this issue is open still, that possibly means nobody is interested in hacking on an ancient video driver for ancient video hardware, so the bug stays open until someone comes along and volunteers to fix it, and submits a patch. That could well be an existing XFree86 developer, or someone such as yourself. More likely than not however, whoever fixes it (if it ever does get fixed) will be someone who actually has the hardware themselves. There really aren't enough volunteer developers out there to endlessly maintain every single video driver and keep it working on every piece of video hardware, and respond to problem reports instantly and fix all issues and fix them quickly. If you're unable to fix the problem yourself and submit a patch onto that bug report, you might find my previous suggestion of using the 4.2.1 video driver in 4.3.0 to be a useable workaround for now. Hope this helps. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SiliconMotion - unable to restore VGA screen on exit
On Sat, 11 Oct 2003, Egbert Eich wrote: I would appreciate feedback on any planned efforts on this problem. If any XFree86 Developer in the LA area needs to look at my machine, I may be able to accommodate them to get this problem solved. I don't know if there is any XFree86 Developer in the LA area. In fact there may by fewer XFree86 Developer around the world than you expect. It seems to be a popular misconception that this project has hundreds of active developers. Another popular misconception that people have is that the developers that are actually working on the code have endless hours to volunteer, and each have a warehouse containing one of every piece of video hardware ever made including one of every laptop, as well as complete technical specification of all of that hardware, and that fixing bugs even in _ancient_ hardware is a high priority for them. ;o) It's kindof funny... Once in a while I get a rude response on a bug report from someone along the lines of Um.. Is *ANYONE* looking at this??? Is there any MOVEMENT on this?? *WHAT* do I need to do to get this problem fixed IMMEDIATELY?? Of course I rarely respond, but the answer I'm thinking in my mind - the true answer, is You need to go backwards in time, and remove your last comment from the bug report so that when time moves forward again, I have never seen it. Then you need to send me $1. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Deadlock with radeon DRI
On Fri, 10 Oct 2003, Keith Whitwell wrote: Date: Fri, 10 Oct 2003 21:55:57 +0100 From: Keith Whitwell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: DRI Devel [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: [Dri-devel] Deadlock with radeon DRI John Dennis wrote: The locking problem is solved, my original analysis was incorrect. The problem was that DRM_CAS was not correctly implemented on IA64. Thus this was an IA64 issue only, this is consistent with others who showed up in a google search describing the problem, all were on IA64. I have filed an XFree86 bug report on this. I could not find a DRI specific bug reporting mechanism other than the dri-devel list. This list is good. Can you put together a patch to correct the behaviour? http://bugs.xfree86.org/show_bug.cgi?id=778 has John's patch that fixes this. Thanks Keith, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Starting XFree86 without an XF86Config file
On Fri, 3 Oct 2003, Sottek, Matthew J wrote: Absolutely nothing says that both can't co-exist. If the default tools try to allow configuration of everything, even some hardware specific things, they can try where possible and feasible to generalize these things, or in cases where that isn't possible, they can provide hardware specific customization. Your example is exactly as I was suggesting, I just worded it badly. Try to put things in a generalized GUI but don't be too concerned about odd features that don't fit. Feature Foo that only applies to an odd usage case doesn't need to clutter the generalized GUI. As long as there is ability for someone to extend it in a device specific manner all will be well in the world. That would be fine. It depends on who writes the tool, what their objectives are, and what they're willing to accept into their project, be it hardware generic or hardware specific. Anyone can re-implement the whole thing in a different manner as you stated, but wouldn't it be nice if the de-facto one provided by XFree was the most flexible. In my opinion, no not really. That might be useful for Joe user who downloads XFree86 sources and compiles them himself, however if it comes with XFree86, then it will almost certainly use a 300 year old hideous widget set like Xaw or Xt, and thus look disgusting on today's modern desktops. A visually attractive tool which integrates visually into the user's desktop is IMHO much more perferred by the masses, which would mean using GTK+ or Qt for the majority of desktops out there, however that means it's very unlikely to be included in XFree86. Mostly a moot point however since distributions will ship software which works well, and integrates with the desktop they're shipping, so it doesn't much matter if XFree86 itself comes with the ubertool IMHO. I know I'd like a make install to have all the updated drivers and configuration tools without having to look for updated config tools from other sources. I disable/delete the config tools that come with XFree86, as they're too archaic. That sounds perfectly fine. And vendor in this sense could mean anything from open source project (including XFree86) to OS vendor to video hardware vendor. Yes exactly. Vendor is a misleading word. Whoever is producing the driver or config tools is the vendor. Fair enough. What would be nice IMHO for the future, is a unified tool which can use either GTK+ or Qt, and is distribution neutral. That would allow every distro to contribute to one tool, rather that the current mess of everyone shipping their own custom made GTK/Qt tool. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VideoRAM option
On Thu, 2 Oct 2003, Marc Aurele La France wrote: My goal is to disable this option by default in drivers which correctly detect video memory on all supported cards, at least for our shipped drivers. I've disabled this setting in our radeon driver for example as that driver correctly detects video memory on all supported hardware. The atimisc module has been VideoRAM specifications for a long time. In ^ Finger check:ignoring the case of ATI adapters at least, if the driver doesn't properly detect video memory size, I'd consider it a bug. Marc. Ok, thanks Marc, this is a case in point of what I'm wanting to do. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VideoRAM option
On Thu, 2 Oct 2003, Kevin Brosius wrote: larger amount specified by the user ? I'm not sure whether breaking the convention that user config overrides probed values is a good idea or not here. Well, it seems that this is a case of trying to fix the problem in the wrong place. No, not at all. There are two problems. One is that some video drivers simply do not require that option at all for any good reason other than for developer usage. Any other usage of the option would be very non-general. The Radeon driver is such an example, as it perfectly detects video memory for all Radeon hardware on all architectures. If for any reason someone can point out a case where it doesn't, I'm almost certain that myself, Michel Daenzer, someone from ATI, or another Radeon developer could fix the problem easily enough. For other drivers in which this is the case, the same logic applies. Mike admits that some config tools make it entirely to easy to change the videoram setting, and then proposes that it be worked around by changing a fairly long standing methodology in the video drivers. Possibly adding a second option to override it. I vote for working on fixing the config tools instead. Fixing config tools to not permit users to have a method of changing this setting is one fix for one problem, and to that I do not disagree at all. However that does _not_ fix _all_ of the problem cases that I care about, and am planning on fixing for my own personal reasons, mainly which center upon bogus bug reports. Some of those bug reports due to config tools exposing the option and users gratuitously setting it, other bug reports due to user thinking they have more video RAM than they really do and going and setting it anyway by hand or whatever. Again, I restate here, that _my_ intention, is to fix _my_ problem, and do so in any way possible. I would like for my solution to be flexible and rational enough that it can be included into XFree86.org stock sources, and I will make whatever changes I make towards that secondary goal. However, my primary goal, is removing this mostly gratuitous option from being valid in places where it really is not necessary. So far, feedback I've been given indicates that: atimisc, savage drivers have disabled this option already, and for quite some time - presumeably because the authors of those drivers have encountered the same types of irritating bug reports that I have gotten, and the option is more burden to them than of any benefit to 99.9% of users out there. The radeon driver in our rawhide builds now disables this option due to various people setting it incorrectly and reporting bugs - regardless of how or why they set it. Some people have indicated the matrox driver has a need for the VideoRAM option due to hardware which the driver does not currently detect the video memory. Since I never get bug reports about Matrox hardware in which the problem is due to the user using this option, I don't really care much about leaving the option in this driver, however wether there are bugs in the hardware or not, Microsoft Windows drivers for this hardware seem to know how much video memory these cards have, so that indicates it is possible to autodetect it one way or another, and so I consider it a driver bug. Intel hardware uses the option to allow the user to configure the amount of video memory from UMA. As long as that driver has proper safety checks and doesn't allow the user to set ti to crazy settings, there is certainly no problem there at all. In this case it's actually a convenience to users, and making the GUI tools allow runtime configuration of their UMA stolen memory might be a useful feature. S3 hardware pre-savage I rarely get bug reports about anymore anyway, and I consider the hardware to be legacy hardware supported as is with drivers shipped for end user convenience, and supported upstream only (or not at all even), so those drivers arent a problem. So, in short, I've got a large part of my answer already from people. ;o) Now I just need to know if the nv driver needs this option for any purpose due to broken hardware and/or UMA, and the majority of cases I'm concerned about will be more or less handled cleanly. For mga, I'll probably only disable the option on hardware I know autodetects properly. Config tool bugs/misfeatures are a totally secondary issue, and that definitely needs to be addressed also, however you can't easily fix things that are widely deployed on tens of thousands of systems. You can fix things for the future only. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: help : Touch screen driver
On Fri, 3 Oct 2003, Mayur Thakare wrote: i am a final year student of computer engineering, as part of curriculam i am developing a driver of touch screen in linux. But even after mind blogging hours of interpreting data on com port i failed to recognise exactly what data come on port (touch screen, for which i am developing driver, is connected to com port, this is an external touch screen) can any one give me hint of exactly what data comes on port from touch screen. I will be really greatful to you. Do you have the hardware specifications for the touch screen? If so, they should describe everything. If you do not have them, did you attempt to get them from the vendor of the device, or search for them on google perhaps? That is the best way to obtain them likely. Otherwise you'll have to reverse engineer it yourself. Without the hardware specifications, nobody can easily answer your question without reverse engineering it themselves, because every piece of hardware will work differently. If all touchscreens output the same data, then there would only need to be one driver, and you wouldn't need to write one. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Starting XFree86 without an XF86Config file
On Thu, 2 Oct 2003, Sottek, Matthew J wrote: The thing is, a unified device-configuring front-end would be better than having every driver writer roll their own. (I mean, we can follow Windows if we want, but why incur development risk by developing what essentially is several versions of the same thing?) Windows does it the way it does for a reason (the Advanced button on the display prefs GUI) You will never be able to create a GUI that covers everything that is configurable across a wide variety of vendor products... nor should you try. Every vendor would like to have the ability to control unique features of their driver in a unique way. It is fine to standardize the basics, but if there is a Custom output filer Foo feature then the vendor should be able to design a custom GUI to control it. No matter how much you try to add to your standard GUI you will always have vendors that would like to control one more, or they will not like the controls for the features that exist. Absolutely nothing says that both can't co-exist. If the default tools try to allow configuration of everything, even some hardware specific things, they can try where possible and feasible to generalize these things, or in cases where that isn't possible, they can provide hardware specific customization. It depends on who writes the tool, what their objectives are, and what they're willing to accept into their project, be it hardware generic or hardware specific. Any hardware vendor, or other 3rd party is free to then roll their own tools in any way they see fit, and multiple tools can co-exist easily together, so both groups of people can have their cake and eat it too. What you are suggesting, attempts to limit one's choices, either as a user or as a developer. Thankfully, open source prevents such tunnel vision control. In such a world, the device driver would have to somehow describe what parameters it understands, what legal values may be assigned, and allow for a callback that would allow configuration setting and querying. Hmm. This isn't hard. XFree is basically just the man in the middle with regard to the config client program. The client says Foo filter = 4 and X passes that info to the driver without knowing or caring what that means. It can also save/restore the persistent data without knowing the details. I would advocate a config system that has a basic set of well known parameters. Width, Height, Depth ... maybe muti-display details too. And everything else is left up to the Vendor to implement in their own config program. That sounds perfectly fine. And vendor in this sense could mean anything from open source project (including XFree86) to OS vendor to video hardware vendor. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VideoRAM option
On Fri, 3 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: drivers simply do not require that option at all for any good reason other than for developer usage. Any other usage of the option would be very non-general. The Radeon driver is such an example, as it perfectly detects video memory for all Radeon hardware on all architectures. The radeon driver doesn't really support your point though, from radeon_driver.c: No... It doesn't support your personal interpretation of my point. It does however support my real point. /* Some production boards of m6 will return 0 if it's 8 MB */ if (pScrn-videoRam == 0) pScrn-videoRam = 8192; Such problems can always occur, which is precisely what the VideoRam directive is for. The only problem I see is config tools presenting it as something it isn't. Sure they can occur. And if a problem occurs where the Radeon driver does not detect memory on a given board, either due to a driver bug, BIOS bug, hardware bug, then it is a bug period, and that can be addressed by a video driver update. Regardless of what XFree86.org is willing to accept into the Radeon driver, *I* am willing to accept that into my version of the driver, as it solves real world problems for me and our customers and users. The number of users it might cause problems for, currently is estimated at zero. Should someone report a bug, then that will be estimated at slightly-more-than-zero, and that bug can be fixed, either via information provided by ATI's documenation and/or engineers, or by modifyingy my patch to not disable the option on that one chip that has a problem. The code fragment above indicates that a specific chip required special handling, either due to a hardware difference, or possibly due to a bug, and my interpretation of the code, is that the memory is properly detected by that code workaround. If I remember correctly, I reported that actual problem to Hui Yu about 1-2 years ago, and he fixed it with that workaround. Other drivers have had VideoRAM option disabled for them already and that seems to not cause problems for users of those drivers, or people would file bug reports about it. At any rate, as I stated multiple times now, I am solving a problem for myself, and our X users. If that solution is useful to a wider audience, they're welcome to it of course, and I'll do what I can to make it useful to others. If for any reason someone can point out a case where it doesn't, I'm almost certain that myself, Michel Daenzer, someone from ATI, or another Radeon developer could fix the problem easily enough. The delay imposed by deploying such a fix seems far from ideal though. I see no evidence of this being a problem in real world usage in any of the video drivers that already do this. If a user does report a problem to me, I can have them an updated test driver within about 15 minutes from receiving the bug report, partially due to the amount of time resources I save not having to chase down bogus bug reports caused by people who have that option gratuitously set. The ideal fix, is to have the drivers non-broken to begin with, and autodetect everythign properly. XFree86 has a goal of making things easier to work for people out of the box without requiring configuration, and that is evidenced by David's latest development efforts posted recently. I'm sure anything that hampers autodetection will be important where possible to fix. Again however - my solution, which _will_ solve my problems, is not in any way forced upon you personally, nor anyone else. Not unless you use my XFree86 builds anyway. And if a legitimate problem can be pointed out to me which I consider relevant and not just pedantic bickering and hypothetical situations, I'm very open minded about fixing problems in ways that benefit people, as long as it doesn't cause more work for me overall due to support problems and bug reports received. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
VideoRAM option
Most modern drivers currently autodetect the proper video RAM amount on all hardware they support. Unfortunately, some X configuration tools allow users to override this option too easily, and if they think they have more video memory than they really do have, then they can create problems for themselves where those problems do not really need to exist, simply by incorrectly overspecifying their videoram amount, or in some cases underspecifying it - in particular with DRI and low memory. I've had various problems tracked down to people specifying this where they need not and should not. As such, I'm trying to determine which video hardware really does require a manually specified videoRAM setting in order for the card to work properly. My goal is to disable this option by default in drivers which correctly detect video memory on all supported cards, at least for our shipped drivers. I've disabled this setting in our radeon driver for example as that driver correctly detects video memory on all supported hardware. Which other drivers might be safe candidates for this? All Nvidia hardware should autodetect properly IIRC, except possibly a few really old cards, in which case I could modify the driver to only allow that option on cards that explicitly require it. Ditto for the mga driver. If people (both other developers and end users) who _require_ the VideoRAM option in order for the proper amount of video memory to be useable with their card, could send me privately their: lspci -vvn or alternatively scanpci output (if lspci isn't available to them), that would help me assess how feasible this would be to do. My end-goal here, is to determine which hardware truely requires the VideoRAM option, and limit the usage of that option in our own XFree86 packages to those specific drivers and cards to limit the amount of bogus incoming bug reports and end user problems created by unnecessary overconfiguration. I might also add another option to re-enable VideoRAM override if people see cases where autodetection does work, but want to override it anyway, such as a global AllowVideoRAMOverride setting. ie: user has card with bad videoram, but by limiting videoram to a lower amount they can disable the bad area of memory. If this is considered to be a useful thing to do in the upstream XFree86 as well, please let me know and I'll be sure to submit the end result for possible inclusion in 4.4.0. -- 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
Re: using externally built libs (Xcursor, Xrender, Xft)
On Fri, 26 Sep 2003, Owen Taylor wrote: Here is another patch from the Debian project. It comes in 3 parts. I basically allows XFree86 to build using an externally built libs. http://bugs.xfree86.org/show_bug.cgi?id=741 It wouldn't let me classify into multiple libraries...so I just associated it with other. I don't see how building against an external Xrender/etc works, since those libraries depend on libX11; to avoid a dependency loop, we copy the libraries into the X11 tarball and do various munging. Sorry to be pedantic on you Owen.. ;o) But we do not modify the XFree86 tarball, rather the pristine XFree86 sources (exported from CVS tag) are decompressed, then Xft/Xrender is moved out of the way, and the new Xft/Xrender decompresed into the tree, then our patches are applied. Fixing that isn't really possible without splitting up of main tarball. Yep, but fortunately there is so few applicatioins, etc with dependancies on those libs that it's easily doable IMHO. xterm is already separate upstream. There are a couple others like xditview, xclock, etc. which could be separated out, or in some cases just dropped completely IMHO. Again, sorry to be pedantic.. ;o) Just don't want people to think our XFree tarball isn't pristine. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Enum windows in order to get process id
On Tue, 16 Sep 2003, Owen Taylor wrote: i am new in Xwin programming. I made an enumwindow function. For each visible window i get a Window structure. My main consern is to get the process id of the window and i am puzzled the way i should terminate that process if necessery. To elaborate on Mark's response, the REASON you cannot get a process ID for a given window is that, in the X world, that window might have been generated by a program on an entirely different computer, running an entirely different operating system, across the network. That being said, the ICCCM defines the WM_CLIENT_MACHINE property: WM_CLIENT_MACHINE(STRING) = poincare.devel.redhat.com and the freedesktop.org WM spec defines the _NET_WM_PID property: _NET_WM_PID(CARDINAL) = 23397 So, if the toolkit that creates the window supports these specifications, you can find out the client machine and process ID. The concept of a PID however is not portable across all operating systems 100%. Also there's the issue of 16bit vs. 32bit PID, or perhaps 64bit PID even. It's also likely some OS's out there don't have a concept of a PID, such as running Desqview/X on an MSDOS system. Granted, that's an unlikely scenario in modern times, but I'm not sure relying on a PID being available or relying on a POSIX type of OS being on the remote system is a good idea. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: setjmp needs fixing again, here's the issues
On Wed, 10 Sep 2003, John Dennis wrote:
JD alignment requirement right how do we specify the alignment requirement
JD to the compiler in a portable way such that it will build on a variety
JD of systems and compilers?
Juliusz typedef union {int i[1024]; long long l;} jmp_buf;
Yes, I thought of that too, but long long isn't portable, right?
Plus it still leaves us guessing we've covered the requirements.
long long is ISO C99
--
Mike A. Harris
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Mosue double click interval
On Wed, 3 Sep 2003, Ping Cheng wrote: Date: Wed, 3 Sep 2003 17:31:21 -0700 From: Ping Cheng [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C3727B.DD496728 Subject: Mosue double click interval Is there a call to get/set the mouse double click interval? The concept of double, triple, etc. clicks is outside the scope of the X server. The X server just provides mouse click/release events basically. It's entirely up to an application or intermediate windowing toolkit wether or not there is a concept of double clicking the mouse. You need to consult the documentation for the toolkit you're using, ie: GTK+/Qt/etc. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: synaptics lockups (was Re: radeon lockups ...)
On Mon, 1 Sep 2003, Warren Turkal wrote: In that case it can hardly be an X problem. Sounds rather like the kernel (anything interesting in its output? Does the same thing happen with 2.4 kernels?) or hardware. I am testing 4.2.1 at this point to see if I come up with the same issues as with 4.3.0. Warren Turkal I came up with the same issues as with 4.3. It turns out that I was running a not-the-latest version of the synaptics event driver for XFree86. I looked in the changelog of the newest one, and it claims to have a work around for a bug in XFree86 that could cause lockups. Does this bug still exist? Here is link to the driver: http://w1.894.telia.com/~u89404340/touchpad/index.html I guess my personal suspicions that it was only locking while I was using the touchpad could have had some merit. I am sorry I did not mention that earlier. Is the synaptics driver to be included in XFree86 anytime soon since it is required with 2.6 kernels on computers with synaptics touchpads? You cannot use a regular ps2 mouse driver without lots of contortions (ie kernel options). It's GPL licensed unfortunately. Only MIT licensed code is accepted into XFree86, so this driver will never be included. That means once kernel 2.6 is standard, the majority of laptop users with synaptics touchpads will have to rely on their OS distribution to provide the GPL driver, or will have to compile it themselves. The only other option would be for someone to write a brand new driver for synaptics and license it as MIT, without looking at the GPL driver's source code. It's possible to do a clean room implementation, but I'm not sure if anyone would really want to bother when there's a working driver already. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: synaptics lockups (was Re: radeon lockups ...)
On Tue, 2 Sep 2003, Daniel Stone wrote: Date: Tue, 2 Sep 2003 20:30:58 +1000 From: Daniel Stone [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=qjNfmADvan18RZcF Subject: Re: synaptics lockups (was Re: radeon lockups ...) On Tue, Sep 02, 2003 at 02:04:00AM -0400, Mike A. Harris wrote: It's GPL licensed unfortunately. Only MIT licensed code is accepted into XFree86, so this driver will never be included. That means once kernel 2.6 is standard, the majority of laptop users with synaptics touchpads will have to rely on their OS distribution to provide the GPL driver, or will have to compile it themselves. The only other option would be for someone to write a brand new driver for synaptics and license it as MIT, without looking at the GPL driver's source code. It's possible to do a clean room implementation, but I'm not sure if anyone would really want to bother when there's a working driver already. Well, couldn't the upstream author just relicense it? That depends on wether or not the code is original code, or if it is a derivative of any other GPL sources. It's possible theoretically, but dependant on the history of the code, and also the author(s) wishes. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: synaptics lockups (was Re: radeon lockups ...)
On Tue, 2 Sep 2003, Daniel Stone wrote: The only other option would be for someone to write a brand new driver for synaptics and license it as MIT, without looking at the GPL driver's source code. It's possible to do a clean room implementation, but I'm not sure if anyone would really want to bother when there's a working driver already. Well, couldn't the upstream author just relicense it? That depends on wether or not the code is original code, or if it is a derivative of any other GPL sources. It's possible theoretically, but dependant on the history of the code, and also the author(s) wishes. That was kind of implicit. To you perhaps, but not to everyone out there. Many people think you can just relicense code on a whim if you're the author, regardless of wether your work contains GPL'd bits from other things or not. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
In the very early days of [EMAIL PROTECTED] Sven Luther and I discussed something like this. Eventually this discussion faded out in the heat of these days Doesn't the following CVS commits implement such an API? No, but it is the beginning of one. Right now, you cannot specify the device driver you want to talk to; you specify the Display and screen. But it certainly can be generalized, so any device driver can receive/reply to messages. Ok, I see what's perceived as missing now. Yeah, that would be useful functionality. TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch to include some kernel info in banner
On Tue, 12 Aug 2003, Daniel Stone wrote: This patch puts the kernel version in the banner, on Linux, and also whether or not it's tainted (providing it's a sufficiently recent kernel). Thanks to Mike Harris for this patch (slightly altered to remove RH_CUSTOM, etc). Please do not accept this Linux-specific hack of a patch; I merged it to Debian, and Mike asked me not to send it upstream. Granted, as the patch stands. However, I don't mind doing the minimal fixing up for inclusion, as this information would be extremely useful in some logs. Feel free to make it more generic and include it - that would definitely be cool. Why the extra symbol, if I may ask, instead merely using defined(linux)? I don't know, I just grabbed it off Mike and did s/RH_CUSTOM/KERNEL_VERSION_IN_BANNER/; I think RH_CUSTOM is a catch-all for Red Hat's whacky stuff. Yes, I wrote the patch to more or less do what I wanted it to do, but in as little time as possible. It works, however it is far from clean code. Just a very very ugly quick hack, not suitable for inclusion. I used RH_CUSTOM to indicate that it is just an ugly custom hack, as I know nobody would include code upstream with such slop in it. My intention, was to some time down the road, rewrite it in an OS and distribution neutral manner, and clean up the ugliness, then offer it for potential inclusion. I figured I'd finish off a number of other hacks first and include them in one fell swoop, once they were in clean enough shape to send upstream. In general, if you see me use RH_CUSTOM, or something else that is obvious wouldn't get accepted upstream, I've done it to indicate that the patch is just a temporary kludge/fix/hack or similar depending on what it's doing. It's intended to be an indicator to others to feel free to use/modify the bits if they like, but to not submit it upstream as-is. The novelty of the quick hack was too great to leave it out until I had time for a proper generic solution. Seeing that information in bug reports has been a tremendous God send, in particular the kernel version running, buildhost, and tainting flags. Of course you're free to tidy it up as you have, and use it as well. I see something has been commited to CVS based on my original, so I'm glad to see someone liked the idea enough to do the dirty work I never got around to doing quite yet. I've got some other patches in current rpms which change the server error messages to be more modern and contain more info. The messages are currently Red Hat centric though - again, to get what I needed done ASAP, with intention to genericize and submit upstream. Basically I've changed the messages to point to bugzilla to report bugs, and a few other similar things. ftp://people.redhat.com/mharris/testing/unstable/XFree86/4.3.0-22/sources/XFree86-4.3.0-redhat-bug-report-address-update.patch That patch in our current rpms, is distro specific, but what I'd like to do before submitting it upstream, is modify it so that the X server default build, has an XFree86 specific message for the project itself, but permits distribution specific overrides to allow various OS distros to override the bug report address and mechanism to find updates. For example, a Red Hat user would want to know both how to report a bug to Red Hat via bugzilla, and to XFree86.org via bugzilla, and they'd want to get updates via our up2date tool if possible, or via ftp from our ftpsite, or alternatively from XFree86.org site's binaries or source tarballs. Assuming the idea is considered sane and acceptable, the exact text of the XFree86.org generic strings I can write up something I think might work best for the project itself, and then submit the patch which allows distro overrides to that text to bugzilla, and David or someone can review and modify to taste and commit it if they deem it a sensible addition. It's a trivial amount of work to do, so I can probably whip out something in short order if deemed to be something useful generically in XFree86. Any feedback appreciated. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch to include some kernel info in banner
On Sun, 24 Aug 2003, Marc Aurele La France wrote: This patch puts the kernel version in the banner, on Linux, and also whether or not it's tainted (providing it's a sufficiently recent kernel). Thanks to Mike Harris for this patch (slightly altered to remove RH_CUSTOM, etc). Please do not accept this Linux-specific hack of a patch; I merged it to Debian, and Mike asked me not to send it upstream. Granted, as the patch stands. However, I don't mind doing the minimal fixing up for inclusion, as this information would be extremely useful in some logs. Feel free to make it more generic and include it - that would definitely be cool. Done. I opted to use uname(2) instead. This doesn't say anything about Linux's tainted thingie, but Mike can send a patch to include it if he, or anyone else, feels that strongly about it. Yeah, my original patch used uname(), but one of the critical pieces of information I wanted in the output was the kernel tainting flags, so I know if someone is running X under a tainted kernel or not. Also, uname output lacked some of the additional useful things the /proc/version file contains which are helpful in troubleshooting. I switched from uname to /proc/version to get the extra kernel build info and whatnot. Both of these things however are very non-generic and the code looks like crap... but it worked well. ;o) I wasn't sure what would be best to submit upstream other than using uname() as you've done, and possibly having conditionalized Linux specific code. That's still a bit ugly though. Once I update my rpms to the latest codebase, I'll see if I can brainstorm some way of getting the best of both worlds without it looking like a horrible mess. If not, it's best keeping the horrible mess as a vendor addition. Just as an additional note, I've tried to keep the convention of using Red Hat specific patches not intended to be submitted upstream in the form XFree86-a.b.c-redhat-foo.patch I made comments in our spec file to explain this, so people are clearer that these patches are not intended for upstream, but they're of course useable/modifyable/etc. to anyone who thinks they're useful, including the XFree86 project. Just trying to keep the ugly stuff buried. ;o) Thanks Marc. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64 page size
On Sun, 10 Aug 2003, Warren Turkal wrote: Date: Sun, 10 Aug 2003 19:06:58 -0500 From: Warren Turkal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: patch for ia64 page size Here is a patch for page size problems on ia64 and radeon. Patch by Chris Ahna: Fixes critical page size problems on ia64 architecture. See following URL for details: https://external-lists.valinux.com/archives/linux-ia64/2001-August/002037.html Comment by [EMAIL PROTECTED]: Why are you submitting _my_ patch, without even asking me about it? If you had, I'd have told you that that patch is an ugly mess, not suitable for upstream submission for numerous reasons. It works, but it is far from clean and ready for inclusion in CVS. Before submitting my patches upstream, please contact me first to find out what my own plans are. I generally send patches upstream myself personally when I feel they are ready to be included upstream. If I haven't, it is a good idea to ask me why not first. I can save you some headaches. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64 page size
On Mon, 11 Aug 2003, Alex Deucher wrote: Date: Mon, 11 Aug 2003 06:25:21 -0700 (PDT) From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: patch for ia64 page size You might want to create a bug in bugzilla (bugs.xfree86.org) and attach the patches there. that way people can comment on the patches and the committers usually post a comment there if they decide to include it. No, please don't. Those pagesize patches are ugly hacks currently, and are not suitable for XFree86.org. Don't waste their time please. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Undeliverable message returned to sender
On Tue, 19 Aug 2003, it was written: Date: Tue, 19 Aug 2003 16:22:15 + (UCT) From: Content Filter To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: Undeliverable message returned to sender This message was created automatically by mail delivery software. Delivery failed for the following recipients(s): [EMAIL PROTECTED] The message you sent contained an attachment which the recipient has chosen to block. Usually these sort of attachments are blocked to prevent malicious software from being sent to the recipient in question. The name(s) of the blocked file(s) follow: details.pif To send this file, please place it in a compressed archive using WinZip (http://www.winzip.com) or the archive software of your choice. - Original Message Header - Received: by mail1-haw (MessageSwitch) id 1061310135892237_13519; Tue, 19 Aug 2003 16:22:15 + (UCT) Received: from COMPCHEM (wkstn233-167.nrb.georgetown.edu [141.161.233.167]) by mail1-haw.bigfish.com (Postfix) with ESMTP id 5C74AA4539 for [EMAIL PROTECTED]; Tue, 19 Aug 2003 16:22:14 + (UCT) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Approved Date: Tue, 19 Aug 2003 12:22:38 --0400 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_NextPart_000_1E2F7733 Message-Id: [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel I am on vacation currently, and will not be in the office for a while. If this matter is urgent. *cough* please try sending it again to waste even more bandwidth on the net and slow things down even more than the viruses spreading around already. If we each do our part of adding more layers of autoresponders, we can achieve the end goal of making the Internet completely useless for communication. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pls give me some docs
On Mon, 18 Aug 2003, [gb2312] Tao, Qian (ÌÕ IES) wrote: Date: Mon, 18 Aug 2003 08:54:24 +0800 From: [gb2312] \Tao, Qian (ÌÕ IES)\ [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C36523.44C3E4D5 Subject: pls give me some docs I want to know how to write a linux driver for a graphic card(like radeon,nvidia). I searched for a while,but there is too little about the control flow and architect of a graphic card's driver. The docs that are available are included with XFree86 source code. The best docs are the source itself (aside from the DESIGN doc and XAA-HOWTO et al.). The technical specifications for Nvidia hardware are not available to the general public at all, not even under NDA. The technical specifications for most ATI video hardware are available only under NDA to those who are employed to work directly on XFree86 video driver work, and a small number of other people, such as some of the DRI project members et al. If you're just starting out working on video drivers, you'll basically have to select hardware to which the specs are publically available to everyone, such as 3Dfx Voodoo 3, Banshee, Cyrix MediaGX, some older Intel boards, etc. Video hardware vendors generally speaking do not allow public non-NDA access to video hardware documentation. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Sun, 20 Jul 2003, Sven Luther wrote: Date: Sun, 20 Jul 2003 14:58:56 +0200 From: Sven Luther [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: Rant (was Re: ATI Drivers.) I've responded to Sven off list, simply because the message was getting very long, and there are probably not many people interested in reading our conversation anymore, and it is also quite off the topic of XFree86 development. There wasn't anything inherently private about it however, so if anyone wanted to know my response, I'll be glad to email it to them. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
an answer to your problem. Or something to that effect, only to be told off, spit on, bitched at, or for the person to ignore me, and continue to proceed to try and get me to help them. After having this happen 50 billion times, I asked other people both internally and externally both at other companies and just people in the community in general how they handle these types of emails, in particular when the volume of them is often 20-40 per day. The almost unified response I got from everyone was Respond to whoever you think you can help and have the time to put into it, and just delete the rest, and the ones you think will be a waste of time or negative experiences. So... as I said I now respond to some if I have time, and I redirect some people still too, but I now delete a lot of them unread, because frankly, my typing fingers are not scalable, and there are only 24 hours in the day, and I'm not paid a cent to help people via email. Anyone who is offended by that, can contact me for $60/hour on the weekends and I'll help them, because just like all open source development that occurs, it is either motivated by volunteerism satisfaction or other personal motivations which are a positive experience, or it is motivated by money. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Fri, 18 Jul 2003, Fred Heitkamp wrote: I appreciate all the work various folks have done to move Linux along. I have used Linux since about kernel 0.99. Now for me at least Linux has become my daily OS. (I used to use OS/2 daily and Linux as my secondary OS.) Many Thanks to All! I also understand the capitalist elements you detail. I am not a hard core (meaning religious or fanatical) open source advocate. Open source just makes good sense. I could go into the various reasons why, but I won't and it's probably obvious to anyone on this list anyway. I am a quite hardcore open source advocate, although I do not classify myself as religious or fanatical though. One of the differences that separate me from some other advocates however, is that I understand some of the capitalistic elements very well that arise such as this one we've been discussing, and I am able to put myself into a neutral mind state, and look at the open source angle, and express my desires to have all hardware specifications available and as much open source code as possible, as well as understanding the corporate angle of the vendor, and why their decisions are chosen for what is best or perceived to be the best for their own likelyhood. Even if I very strongly desire to see something open sourced, I realize if the other party can not legally do something, or does not see the benefit of doing so, to *THEM* in their *OWN* eyes for reasons they *CARE* about for their financial success, and other factors important to *THEM*, then it stands to reason they wont do it. Would you? In fact, doing something like that might even get them in trouble with the SEC, and they'd most surely have to inform stockholders via SEC reports of the risks they'd be taking by open sourcing their stuff (assuming they legally could, which is almost certainly not true). More likely than not, a day later their stock would plummet and their competitor's stock would raise. I wish some sort of compromise could be reached where the proprietary never-to-be-open-sourced bits could be made to coexist with the open bits in a timely manner. Matrox does this for some of their stuff via hallib. It does not however do everything that the other full proprietary drivers from other vendors do though, and the Matrox hallib does not make the mga driver comparable to their Windows driver offerings. It just improves the support of mode setup, adds dualhead on G400, and makes TVout work among a few other things. One thing that *could* be done which would be beneficial to OSS users, would be to have the large GPU engine removed from the kernel and done in userland, with a fast method of communicating to the hardware. That is completely possible in theory, and it would be great to see happen sometime. Not likely to happen until it is considered something financially worthy of spending the resources on though. What I mean is that I don't like waiting for months and months for various hardware and features to be supported by Linux. I don't mean just with Xfree, but with other parts of Linux as well, like media players and so forth. (My goal is never to have to boot Windows for anything.) I don't know what a workable solution from a technology aspect would be. Perhaps some consistent pluggable module API or library scheme? Who likes waiting for anything? Everyone would like hardware to be supported with equal or better attention spent developing Linux/OSS support as is paid to Windows. I just isn't realistic however to expect a corporation to spend 50% of their development time supporting an OS that generates 1% of their revenue (or 0.01% or whatever). If anything, I would guess that many hardware vendors _already_ spend more percentage of resources on Linux development than they see percentagewise return of revenue for doing so. Of course that is likely true for some types of hardware and probably totally false for other types of hardware. I also have no statistics to back up this opinion, and I very well could be very wrong. I'll also likely change my opinion in 12 months, and then again every 4 to 6 months after that, as Linux's mainstream desktop usage curve increases. BTW, XFree86 has a module API ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
. They are unlikely to flame me, or to even know if I got it. However, if I say We do not support foo in product x.y because there are very few users out there who use it, and the amount of engineering resources that would have to be spent to develop this support would be far greater than the benefit it provides to our users overall, compared to those engineering resources being spent on other features and support that we could be working on that would benefit a much larger group of users. If I say that, I might get back a hmm, you have a point there, I must agree, and sometimes I do. More often I get back WTF? I bought your product and paid $nn, and you're telling me you wont add support for foo? Too hell with you then! I'm going to use vendor bar's product next time and you can go to hell! Anyone in my position who has to deal with these types of support questions or customer/user feedback, will very likely know exactly where I am coming from, and will strongly back up my statement that it is often better to just shut the hell up and not say anything to a customer/user about something than it is to be honest and then upset them even more, possibly getting them to spread their negativity around and generate more bad publicity or angst toward your company. Not responding at all ... that's something else again. Maybe there are legal reasons. Maybe they just want to protect their IP. Whatever. Respond. It doesn't matter to end users anyway. What matters is that nVidia's cards just work, and the reason is that nVidia have made the effort to make things work. ATI have made some efforts to make some things work. I disagree, and for the reasons given above. And I'll add to what I said above, that if you do respond, you'll most likely get SOME kind of email back, and most likely very negative, and with arguments/debates and more questions. The majority of time you are the messenger, not the decision maker, and you're now in an argument you want no part of, with some user/customer who is going ballistic at you over a decision that is likely not made by you. Do you then respond back and likely make things even worse? Or do you now be quiet and hope they just go away? Perhaps they get 3 other people to email you or phone you too, and now you have to deal with 3 people who you KNOW are going to disagree with you and want to argue/debate/state their mind about something you KNOW that there is ZERO chance of anything they say changing the situation. Worse, you waste your time doing so, and your company time. Should these companies hire 50 people to respond to all of these emails to listen to users argue with them? No. Hit delete, and let it go. The user may be upset for not getting a response, but they're going to more often be a lot less upset than hearing the truth and wanting to argue with you and waste a lot of your time doing so. Also, your company is paying for your time, so if you're responding to 5000 users a day to listen to them argue, that is hardly worthy usage of your time. Fortunately, it is Saturday, so I can argue with you until Monday. After that, I'll have to delete your mails. ;o) The sad thing is that I would actually really like a Radeon 9800. But I would be a fool if I bought one. Previous experience tells me I'd be far better off with a GeForce - even my friend's hand-me-down GeForce 2 MX. You're the best judge of what works best for you, especially after personally testing various things. And while you might decide to purchase card A and B above and find B works best for you, and A does not work well at all, just as many other people out there are likely to buy card A and B and find card A works better for them. That is what I see by analyzing postings to the XFree86 mailing lists, 2 bugzilla databases, and 4 IRC channels devoted to X11 anyway. What works for one person great, might not work worth shit for another. Your mileage will definitely vary. Do experiment though, and find something that does work good for you, preferably on loaner/trial if possible. TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
is willing to provide support if you will not. At that point, the sheer volume of sales that are involved are likely to make it viable, and the debate is over. Until that happens, I really can't see anything happening other than what we're lucky to get now, be it open or closed source (but preferably open). And really, the XFree86 project has absolutely zero control over any of this, so why bitch about it here where NOBODY can remotely do anything about it? XFree86 has an interest in the drivers that have been forked into other projects. And, the group has a working relationship with the vendors in question, which means that such concerns can be expressed in places that will result in the best possible result. Rather than Random people (never call them customers) that use the vendors hardware can use the hardware in a manner befitting the quality of the hardware's design. I can't officially speak for the silent XFree86 developers of whom you might be speaking about, however I would bet money that the majority if not all of them understand the whole issue and don't want to get involved with another pointless debate about it as they've been watching the same discussions likely for 5, 8, 10 years or more, and know the ropes very well. They also do have relationships with the hardware vendors, and they know the hardware vendor's position very well. There is no point of them arguing with the hardware vendor as any amount of begging or demanding is not going to mean jack squat to any hardware vendor. A hardware vendor is very unlikely to budge unless they see numbers dancing on a spreadsheet with dollar signs in front of them. That might suck for _us_, but that is really the truth of the matter. As to why I haven't learned my lesson.. Well I had thought that things had gotten better. And they have, since the start of the Gatos project when folks at ATI said Linux what? At that time they said that there was no work being done to support things because there was no interest being expressed by customers. The open source community tends to measure interest in thousands or tens of thousands perhaps at best. I would very strongly assume that a hardware vendor saying there is no interest really means to say the amount of interest that has been expressed to us to support that platform thus far, has not even moved the needle on our care-o-meter. Come back when you have 10 times the number of paying customers interested, and when the major IHV's demand support because their customers demand it from them. Of course it would not sound very nice for a company to say that, and so it gets filtered via public-relations-speak into something ilke we have not received sufficient interest from our customers to support that platform. If someone really wants to convince vendors to do anything, don't call them, call Dell/HP/IBM or whoever your computer system vendor is, and demand that they support Linux or you will not purchase their products. Demand that the system have supported video drivers also, and tell them which video hardware vendor is your preference. When the masses of people out there can convince one or more of the major computer IHV's to officially support Linux, this whole debate will start to become moot. Until then, don't count on much changing though. That might not taste good to swallow, but it is an honest reality... at least of course IMHO. I could be wrong though, perhaps tomorrow, we'll see a major announcement from all top video vendors on slashdot announcing they've released their source code because the number of Linux systems has skyrocketed over night from 0.01% of sales to 50%. grin -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Fri, 18 Jul 2003, Tim Roberts wrote: On the other hand.. If more people who didn't want to have to run another OS to access features that are not well supported because of lack of knowledge on how to support them would comment/complain (oh alright -BITCH-) maybe the hardware vendors would realize that there is a viable market for their devices to be used on the second class OS's The reality of the business end of this is just brutal. The unfortunate fact is that your viable market is completely insignificant. ATI doesn't make money from you. ATI doesn't make money from the few tens of thousands of Linux users out there. At their margins, that probably pays for part of one engineer's salary. No, ATI makes money when IBM orders 2 million Rage chips for their next generation laptop. If IBM made the deal conditional on ATI providing high- quality, high-functionality XFree86 drivers, you can bet they would trip over their shoelaces in providing that. However, they don't. IBM makes the deal conditional on great WinXP drivers and great DX9 support, because to 3 standard deviations, that's what its customers want. In business terms, the Linux market is not relevant. Sad but true. I would actually be satisfied with Binary only drivers that would support the whole card. But, there aren't enough people letting them know that there is an interest (OOPS that would be BITCHING!). And even if EVERY person let them kinow there was an interest, it still wouldn't be enough. There just aren't enough of us. Sigh... Once again you say more or less in about 10 sentences what I am thinking and trying to relay in 300 sentences. Are you for hire or what? ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Fri, 18 Jul 2003, Mark Vojkovich wrote: No, ATI makes money when IBM orders 2 million Rage chips for their next generation laptop. If IBM made the deal conditional on ATI providing high- quality, high-functionality XFree86 drivers, you can bet they would trip over their shoelaces in providing that. However, they don't. IBM makes the deal conditional on great WinXP drivers and great DX9 support, because to 3 standard deviations, that's what its customers want. In business terms, the Linux market is not relevant. Sad but true. For consumer desktop that's true. There is one potential business case in the professional desktop market. SGI's, HP's and Sun's old workstation customers have been moving over to Linux. All the film studios are using Linux, for instance. The volume is small but the margins on the professional cards is high so there is a chance that it might actually make money some day. If it weren't for this potential in the professional market, NVIDIA probably wouldn't have any binary Linux drivers. The real target of those drivers is the NVIDIA Quadro line not the GeForce line. I've been trying to tell pretty much every person who comes to me talking about _any_ company's proprietary video hardware drivers, that those drivers were not written for fun, nor for gaming. They were written for high end 3D customers such as the movie industry, scientific, geological, medical, etc. However, some people are brainlocked to think that the drivers are written for video gaming in Linux. Nobody wants to believe that there has to be a business case for this stuff to exist for some reason, and just thinks companies write drivers like the Nvidia, ATI, and other drivers and provide them for download for video gaming or charity or something. With your permission, I'd like to be able to forward your email to people in the future, to help them understand this right from the horse's mouth so to speak. And if so, I thank you very much. ;o) Ironically, the Linux desktop community doesn't target the only potential business case there is. It's often at odds with it. Workstation users like a platform that doesn't change and anything that risks damaging OpenGL behavior (like RandR support or alpha blended cursors) is generally not well accepted. Indeed. With new features getting added each release, it's hard to both progress toward the current technology trend and also sustain a stable supportable platform, while also supporting the latest video hardware. To stick with an older XFree86 release for example, means you might not get the latest features, but your X server does not change drastically every n months. However, then when a new video card comes out and you need to use it, you have no choice but to upgrade to a new XFree86 release. I see this very problem very often, and it's not easily solveable IMHO, because you've got the needs of the end user, the needs of the OS vendor, the needs of the driver developer/provider and the needs of the X11 implementation project all conflicting to a certain extent (while overlapping in others). I believe however that it is possible to increase the overlapping of needs in the mid to long run, and minimize the amount of conflicting needs, but it will take time to get there. As for the viability of a particular market, here's an example. Yahoo's business section lists NVIDIA as having 1513 employees and revenue over the last year was $1731 Million. This is revenue of over $1 Million per employee per year. That 1513 includes everybody including secretaries, etc... so there is obviously well over a Million dollars revenue per engineer. One man year of extra work is generally expected to generate at least a Million extra dollars of revenue. If a particular market can't generate that, resources are best allocated to another project. That backs up what I've been trying to say the last 3-4 messages very well, only again with less verbiage than I, and with more numerical information. ;o) I think I can just about shut the F up soon now. Thanks. ;o) Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Sat, 19 Jul 2003, Fred Heitkamp wrote: For consumer desktop that's true. There is one potential business case in the professional desktop market. SGI's, HP's and Sun's old workstation customers have been moving over to Linux. All the film studios are using Linux, for instance. The volume is small but the margins on the professional cards is high so there is a chance that it might actually make money some day. If it weren't for this potential in the professional market, NVIDIA probably wouldn't have any binary Linux drivers. The real target of those drivers is the NVIDIA Quadro line not the GeForce line. If the server market is the biggest (and for Linux it is) then only 2D support if that is required. I'd bet even the big film studios don't use Linux to view the final rendering. They probably use a Mac (Apple OS of some kind) or a PC running Windows. Search google for Dreamworks SKG stories involving Linux. You'll be surprised. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Sat, 19 Jul 2003, Daniel Stone wrote: No, there you are exagerating. I hardly doubt that they would go broke or whatever if they released open source drivers. If anything, they would sell more boards. Not very many, and their competitirs would then have access to all their IP, so could out-do them in the next generation of cards. I doubt that it would involve hardware as much as it would involve the driver aspect and the JIT compiler for the GPU perhaps. Having never seen the complete source code of any modern proprietary full featured video driver however, it's very hard to say. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Rant (was Re: ATI Drivers.)
/whatever is on as many desktops as Windows or other popular desktop operating systems are, then you might see the attention spent on unified drivers for XFree86 that are spent on Windows driver development. To spend 50% of engineering on Windows development for 95%+ of the market, and and 50% of engineering on Linux development for 1-2% or whatever of the market doesn't line up on financial executive's calculators very well. If you want drivers for video hardware that expose all the features of your hardware, you're using the wrong operating system and graphical environment. Come back in 2-3 years and perhaps Linux will own 50% of the desktop and we can expect driver development to then be spent by the hardware vendors as 50% on Windows, and 50% on X11. It's simple mathematics really. If I sound like the devil's advocate, I assure you I'm not. I'm just tired of hearing random people bitch and beak off about this type of crap who don't put any sort of thought whatsoever into the business, legal, copyright/trademark/patent, or engineering costs and other factors that affect these types of decisions in companies out there. Try to look at things from the angle of the given company out there for once. And really, the XFree86 project has absolutely zero control over any of this, so why bitch about it here where NOBODY can remotely do anything about it? /rant -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Distributing new DDX for testing
On Mon, 14 Jul 2003, Chris Edgington wrote: Date: Mon, 14 Jul 2003 17:00:26 -0500 From: Chris Edgington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Distributing new DDX for testing I've completed the addition of Silicon Motion SM731 support to the siliconmotion driver. This obviously required modifying the driver and a few non-driver specific files - extrapci.ids and xf86PciInfo.h. I'm now preparing to send the driver to someone else for some additional testing. If the receiver is already running XFree86 4.3.x, what files (binary files) do I need to send to them? Is the following list sufficient: XFree86, scanpci, siliconmotion_drv.o? The best thing to do is file a bug report in bugzilla at http://bugs.xfree86.org and attach your patch to the bug report as a unified diff (diff -Naur) to the report using the bugzilla file attachment feature. You should ensure the patch applies to the current developmental CVS head first, and compiles ok. If you've got binary drivers pre-prepared, you might want to attach them to the report as well, or point people to a URL where to download them. To determine which binary files are needed, simply take a 4.3.0 installation, and install your driver over top of the supplied one. You may need other modules updated as well. Hope this helps. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Bugzilla and XFree86 version
A number of bug reports have gotten filed against XFree86 4.3 which are actually CVS head bugs. I think it makes sense to add CVS as a version also, so people can choose that too. Might want to add CVS 4.3.99.n versions too, but that might be overkill. I can report this in bugzilla against bugzilla so it is tracked, but I wanted to ask about it here first. -- 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
Re: a small twm/Imakefile patch
On Mon, 7 Jul 2003, Alexander Pohoyda wrote: Date: Mon, 7 Jul 2003 18:39:38 +0200 (CEST) From: Alexander Pohoyda [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=utf-8 Subject: a small twm/Imakefile patch Does not really deserves a Bugzilla report (1K): http://www.alexander-pohoyda.privat.t-online.de/patches/twm.Imakefile.diff Most likely, it doesn't deserve to tracked or applied either then. Bugzilla is for both tracking open bugs, and for submitting patches that fix things or add functionality, etc. things stay open in bugzilla until someone has the time and inclination to investigate and fix/apply. Patches sent to mailing lists get lost if nobody is interested in looking at them immediately. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RH9 Display Settings Card List
On Fri, 4 Jul 2003, Chris Edgington wrote: Date: Fri, 4 Jul 2003 12:28:12 -0500 From: Chris Edgington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: RH9 Display Settings Card List Does anyone know where the RH9 display settings applet gets its list of video cards when you click the Configure button on the advanced tab? I'm adding support for the new SiliconMotion Cougar3DR (730 chipset) to the siliconmotion driver. The server is working, but I'd like to get it to show up properly in the RH list. I grepped through the xfree86 source tree for Lynx (generic) (an entry that shows up in the list) and I could not find a file containing that, so I figured maybe I searching for the wrong thing or its not part of xfree86. Does the list come from a file / query in xfree86, or is it something RH9 specific? The list of video cards is in the Cards file. However, the one that comes with XFree86 is massively outdated, and I believe unmaintained, so we maintain our own Cards database separately, which is part of our hwdata rpm package. That said, our database is MIT licensed as the original was, and anyone is free to use the contents of it in any way that is useful, including merging it into XFree86 CVS if desired. Ditto for the MonitorsDB database. I plan on replacing the Cards database in Red Hat Linux with a new mechanism sometime in the future which will be much more flexible, allow per architecture overrides, allow the config tool to know what hardware supports DRI and on what specific architectures, and other useful things that are desperately needed. This would also allow drop in drivers to also drop in new database files which could supplement the database that comes with the OS, or override specific entries, or allow multiple drivers to be alternatives for a particular card. HTH -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: S3 Trio64UV+, S3 Trio64V2/DX
On Thu, 3 Jul 2003, Alex Deucher wrote:
Date: Thu, 3 Jul 2003 07:10:09 -0700 (PDT)
From: Alex Deucher [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Subject: Re: S3 Trio64UV+, S3 Trio64V2/DX
open a bug at http://bugs.xfree86.org/ and include your patch so that
it doesn't get lost. hopefully it will get fixed up and integrated.
Be sure to regenerate the patch without gratuitous whitespace
changes though.
Only 8,16 bit depths work.
64V2/DX may be needed slow_dram_refresh option.
diff -u s3.bak/s3_driver.c s3/s3_driver.c
--- s3.bak/s3_driver.c2003-02-27 22:59:43 +0200
+++ s3/s3_driver.c2003-07-02 18:24:02 +0300
@@ -127,11 +127,13 @@
/* supported chipsets */
static SymTabRec S3Chipsets[] = {
-{ PCI_CHIP_964_0,964-0},
-{ PCI_CHIP_964_1,964-1},
-{ PCI_CHIP_968,968 },
-{ PCI_CHIP_TRIO, Trio32/64 },
-{ PCI_CHIP_AURORA64VP,Aurora64V+ },
+{ PCI_CHIP_964_0,964-0},
^
is that necessary?
+{ PCI_CHIP_964_1,964-1},
+{ PCI_CHIP_968,968 },
+{ PCI_CHIP_TRIO, Trio32/64 },
+{ PCI_CHIP_AURORA64VP,Aurora64V+ },
+{ PCI_CHIP_TRIO64UVP, Trio64UV+ },
+{ PCI_CHIP_TRIO64V2_DXGX,Trio64V2/DX/GX },
{ -1, NULL }
};
@@ -142,6 +144,8 @@
{ PCI_CHIP_968, PCI_CHIP_968, RES_SHARED_VGA },
{ PCI_CHIP_TRIO, PCI_CHIP_TRIO, RES_SHARED_VGA },
{ PCI_CHIP_AURORA64VP,PCI_CHIP_AURORA64VP,
RES_SHARED_VGA },
+{ PCI_CHIP_TRIO64UVP,PCI_CHIP_TRIO64UVP, RES_SHARED_VGA
},
+{ PCI_CHIP_TRIO64V2_DXGX,PCI_CHIP_TRIO64V2_DXGX,
RES_SHARED_VGA },
{ -1,-1, RES_UNDEFINED }
};
@@ -531,6 +535,8 @@
case PCI_CHIP_AURORA64VP:/* ??? */
pS3-S3NewMMIO = FALSE;
break;
+case PCI_CHIP_TRIO64V2_DXGX:
+case PCI_CHIP_TRIO64UVP:
case PCI_CHIP_968:
pS3-S3NewMMIO = TRUE;
break;
@@ -580,6 +586,15 @@
outb(0x102, 0x01);
outb(0x46e8, 0x08);
+if (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
+{
+ outb (0x3d4, 0x86);
+ outb (0x3d5, 0x80);
+
+ outb (0x3d4, 0x90);
+ outb (0x3d5, 0x00);
These should not be hard coded register values.
+}
+
if (!pScrn-videoRam) {
/* probe videoram */
outb(vgaCRIndex, 0x36);
@@ -1118,7 +1133,9 @@
if (pS3-Chipset == PCI_CHIP_968)
shift = 1;/* XXX IBMRGB */
-else if (pS3-Chipset == PCI_CHIP_TRIO)
+else if (pS3-Chipset == PCI_CHIP_TRIO ||
+ pS3-Chipset == PCI_CHIP_TRIO64UVP ||
+ pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
shift = -(pS3-s3Bpp 1);
return shift;
diff -u s3.bak/s3.h s3/s3.h
--- s3.bak/s3.h2002-12-11 19:30:47 +0200
+++ s3/s3.h2003-06-27 12:40:22 +0300
@@ -240,6 +240,8 @@
#define S3_964_SERIES()((pS3-Chipset == PCI_CHIP_964_0) ||
\
(pS3-Chipset == PCI_CHIP_964_1))
#defineS3_TRIO_SERIES()((pS3-Chipset == PCI_CHIP_TRIO) ||
\
- (pS3-Chipset == PCI_CHIP_AURORA64VP))
+ (pS3-Chipset == PCI_CHIP_AURORA64VP) || \
+ (pS3-Chipset == PCI_CHIP_TRIO64UVP) || \
+ (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX))
Again, a bit of gratuitous whitespace change. I'd tidy all of
these things up before submitting to increase the chance of it
being committed.
Hope this helps.
--
Mike A. Harris
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Dell C400 fix applied to 855GM?
On Mon, 30 Jun 2003, Alex Deucher wrote: Date: Mon, 30 Jun 2003 09:55:44 -0700 (PDT) From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: Dell C400 fix applied to 855GM? why aren't the windows drivers affected? they must be a way around it without needing a new bios... The same thing was claimed the last time around with the 830s and dell never fixed the bios, but someone came up with a work around. Simple. Because the Windows drivers have workarounds built into them which manually program the chipset to do what the BIOS should, but is not doing. Why do they just work in Windows? Because 95% of the desktop market is Windows, and the various companies involved have a lot of money tied up in making sure things just work the first time they hit the public eye the majority of time. As such problems like this are fixed in Windows-land long before end users ever realize there was a problem that needed to be fixed. In the land of OSS however, we do not have that same status. We get specifications for hardware long after the fact if ever from the majority of video hardware companies, and when someone releases hardware with a broken BIOS that needs software driver workarounds, someone needs to know what the exact problem is, and then also have access to the specifications to know how to code those workarounds, and also have the hardware in question in order to test it. So it is no surprise that what works in Windows is not any form of indicator of what works in XFree86. They are 2 different environments, not privy to the same amount of technical information as each other, and with very different number of manpower working on each, and with IHV pressure also being quite different for each. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Someone has re-implemented ucs2any.pl in C
On Thu, 12 Jun 2003, Egbert Eich wrote: Yes, there are plans to ship all bitmap fonts converted to ttf. This however requires bdf-ttf and ttf-bdf converters. I don't know the status of these converters. Even then we'd still need bitmap fonts in different encodings for systems that still require the old bitmap renderers for some reason. Therefore a ucs2any converter written in C will be useful in any case. If you want to invest the time to test the results of your converter against the perl version I'd think it would make sense to switch to it. Could you post the code of the converter to the bugzilla? Ok, I'll go ahead and finish off fixing the last few quirks and test it. Once I've quality/sanity tested it I'll submit it to bugzilla and likely post a comment here also. It should be portable to any platform which adheres to ISO C99 and SuSv3, but I'll be more than glad to fix any portability issues to other platforms as well if any issues pop up. TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
libXi maintainer...
Who (if anyone) is the current official maintainer of libXi? -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC: OpenGL + XvMC
On Sun, 1 Jun 2003, Andrew C Aitchison wrote: Just curious, as I'm not too familiar with XvMC yet, but would this provide another Xv adapter that used the 3D texture engine to display videos rather than othe video overlay? or something else. Sorry for my ignorance. ... ... ... --- Mark Vojkovich [EMAIL PROTECTED] wrote: I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function to XvMC. I have implemented this in NVIDIA's binary drivers and am able to do full framerate HDTV video textures on the higher end GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer contents into a texture. I don't really know any more than you but my guess is that while this may be presented as another Xv adapter, what it really does is make a video source available as a texture. This would allow you to, for instance, display a virtual reality living-room and whenever the camera falls on the TV it would be showing live pictures from a video feed. Another more useful use would be CNN like video effects where the fullscreen shrinks to an inset and then rotates on a 3D angle, etc. Various nifty 3D video effects for video editing/production could be done. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Having trouble getting CVS to compile
On 27 May 2003, Scott White wrote: Could anyone point me at some instructions to help me compile the XFree86 cvs, I'm having trouble. I want to get access to the via driver recently added to the CVS so I can run X not in vesa mode on my Via Mini-itx based hush PC running Redhat 9. The easiest way to get the via driver without damaging your Red Hat supplied X installation, is to wait a few days or so, and I'll be integrating it into XFree86 4.3.0 in rawhide. Rawhide XFree86 should be a fairly clean upgrade from the stock RHL 9 XFree86. It'll likely be in 4.3.0-14 or 4.3.0-15. You can find me in IRC on freenode #xfree86 if you'd also like to ping me on wether I've added it yet or not. HTH -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Userland - X driver message passing API
On Sat, 5 Apr 2003, Bryan W. Headley wrote: Date: Sat, 05 Apr 2003 18:51:30 -0600 From: Bryan W. Headley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Userland - X driver message passing API Hey, Is anyone aware of a project to allow a userland tool, such as a front-end GUI, communicate with an X input driver? Yes, you may wish to contact Havoc Pennington or Owen Taylor about that. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Userland - X driver message passing API
On Sat, 5 Apr 2003, Bryan W. Headley wrote: Is anyone aware of a project to allow a userland tool, such as a front-end GUI, communicate with an X input driver? This is what I want to do, and yeah, there is a bit of overlap Zephaniah Hull's evdev: there are several parameters to my Aiptek tablet driver which should be modifiable once X is running. Among those are active area settings, mouse/stylus button transposal settings and the like. I'd like for it to be bidirectional, insofar as it needs to report it's settings as well as configure itself. To do this properly entails implementing a callback method in the drivers (e.g., it's not for input events but rather for configuration), and something at a higher level that listens to a socket, named pipe, jms, smtp, m-o-u-s-e and can route/dispatch messages to the appropriate driver. Where evdev comes in (I think) is that it establishes a channel of communications to pass along hardware insertion/removal events generated by hotplug. So there's some infrastructure there already: the question is whether leveraging off of that is a good way to go... Any guilty heads out there? ARGH. I am guilty of reading the subject and very quickly skimming the body without actually reading it all. Ignore my last post ;o) I was trying to give a quick and helpful reply without taking the time to read everything you said, and only after i hit reply did a couple words catch me that indicated to me what you wanted wasn't what I was alluding to. ;o) Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Colormap Problems in Matrox G450 under FreeBSD 4.8
On Thu, 3 Apr 2003, Peter Gervais wrote: Date: Thu, 03 Apr 2003 15:30:47 -0500 From: Peter Gervais [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: Colormap Problems in Matrox G450 under FreeBSD 4.8 Thank you for answering my e-mail. I've noticed as well that this very same application will not update the screen unless the mouse is inside it's window area. This is a Air Traffic Control radar type of application which must be continuously updated no matter if the mouse is in the screen or not. The X lib calls are being made but yet the display will not update until the mouse is in the radar display. Again , same code as HP-UX and Solaris and works fine on those system. Is there a server option which will force update to occur if the mouse is not in the screen? Just for everyone's personal safety... Which airport is this being used at? ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
