(all expressed below is my personal opinion) there is a sound in the below text which i dont like for misc reasons. but ignoring my impressions, there might be some basic clarifications needed.
the xfree86 developers drove the policy to only incoroporate highly "important fixes" for releases that only differ in the last number of the version number from the previous release. "important fixes" were fixes for security holes and could mean code changes for situations where crashes might impact on system accessability and data integrity. having support for a new grafics board means adding a new feature. but those feature changes are typically only added to the development branch which will possibly result in a package with middle number incremented and minor number reset. as of now that will be X4.4.0 or higher. if a feature change is so minor in its impact and so small in size that it is no risk, then it might sneak silently into a fix release. extending for a new and somewhat different asic design does not look to me like a thing of minor risk. i dont understand you complaining... you seem to have a quite viable solution that even copes with the existing binary packages, even then when they are compiled by e.g. RedHat or whichever distribution. its just a single line you have to add and you are done. dont you like operating such things on your own risk. (i hopefully assume now that the man page says that the usage of this option is merely for experimental purposes and that it's usages is totally on your own risk.) if you dont like adding such a line it all the time to your config (how often does an end user delete his config file?) then why not get the source and apply the patch to PCI ID listing for the respective driver. compile the driver and install it. done. hey, are you so keen on a release number? you can even get development tree binaries from misc sources. its a nice habit of the XFree86 project to provide a few binaries aside to the source, but you are on Linux which is partuially a synonym for the GPL FreeSoftware/OpenSource license, so please expect that to be most software a gift from the respective developer, but do not a expect those developers to act like a business company. in order to get things in order, the XFree86 license does grant you much more freedom than the GPL... > I would like to ask if it's possible to support the ATI > radeon 9200 (rv280) in the next update of > xfree86, maybe 4.3.1. I have found the following from > Michael Hamilton ([EMAIL PROTECTED]) > http://users.actrix.co.nz/michael/index.html on > (comp.os.linux.x) below. > Would it be possible to have built in support for this card > using this info? > Note: Most people DO NOT need agp 8x support for this card. > > Thanks > Robert Arkiletian just one thing, each major & minor release of XF86 is an individual release, not an update. only the security fix releases might classify as an update since they were provided as source patches and as binary replacement subset of files only. i dont want to call a fix release a "service pack" because its a difference to service in the comercial sense. since it is a merely open process you can see all the current development results via the publicly readable source repository. and there are even people that build binarys from the development tree with just applying the fetch date and time. no one will grant you that a release is totally free of errors (there never was such a one) so the differences to the development snapshots is often minor. releases just do typically build without problems for most target configurations. further any ongoing shedule and solution is readable in the mailing lists arachives and serachable via your favorite search engine. but feel free(!) to build up your own solution, releases are only one of many paths that you can go when you got to that type of software. your note about agp 8x lets me assume that there is a major problem if people do drive that card that way - so adding what you did request sounds to me like there will be some simplification for a few people whilst an increasing number of people will fall into a big breakage in the resulting code. a fix release should never introduce serious faults. for a major/minor release there is likely more time to find a solution since faults arent acceptable there either. In other words, you are suggesting to integrate only halfway done works to the codebase? i am not perfectly sure, but agp 8x is quite generic for any AGP busmaster grafics adapter, so there is no worry if using a recent AGPGART kernel module. the bigger problem is with the mainboard chipsets which do have a quite "colorfull" bandwidth of individual programming rules for the GART paging table and for e.g. CPU, chipset and memory controller data flusing. some attic grafics adapters did need specific programming byond the AGP standard registes in order to use misc PCI and AGP transfer modes. current adapters just have it 95% setup via AGP caps and the remaining 5% will be done once in display init. maybe there was some sort of thinking in the "false" terms of the all embedding comercial software world. people do have the habit to think linux is just a substitute for their exisisting software systems. in fact Linux is not only a substitute but it is adding up an important amount of "freedom factor" to the systems owner's personal and individual freedom via the FreeSoftware/OpenSource concept. -Alex. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
