Re: [Dri-devel] Design draft of a new Configuration Infrastructure
On Fri, 21 Feb 2003 01:36:01 + José Fonseca [EMAIL PROTECTED] wrote: Felix, D. Hageman, On Wed, Feb 19, 2003 at 09:52:47AM +0100, Felix Kühling wrote: Hello list, D. Hageman and I have been bouncing a design document for the new configuration infrastructure back and forth in private mail for the past week. Now we think it's ready for public discussion. You may notice that the structure is quite similar to Ians texmem design. This is the first time I'm writing such a document so I took Ian's work as a good example. The document is attached in plain text format. Nice work. You've covered alot of ground. [...] 2.2 Advertising available options [...] In order to get access to available options a GUI tool would first have to find the driver associated with a particular screen number. The DRI extension provides calls which determine whether direct rendering is supported on a screen and by which driver. Then it can ldopen the driver and obtain the address of a symbol which contains the information about available options in XML format. A GUI written in a scripting language like perl or python may not have bindings for the X protocol and it may not be able to ldopen a shared object file. In this case the GUI could call a small command line program which dumps the available options on its standard output. This program would be part of the DRI/XFree86 distribution. I don't if it is possible at all, but it surely would be nice if we didn't have to rely on having X access at all - e.g., in remote administration or single user mode. Is there any way to avoid this depency? Brian proposed that libGL could find and load the driver to get the available options. It should be possible to do that without X access. Of course you can't find the driver for a specific screen if X is not running. But if you know the driver name, libGL should find it. (someone correct me if I'm wrong) The most complicated step in that sense would be to determine the driver shared library. If the path of the driver shared library was cached in the configuration files, or the parameters description was duplicated in the configuration files, then the GUI/script could use this cached info and do his thing in off-line mode... IMHO adding some sort of offline mode would increasing the complexity of this system quite a lot. The question is whether it's worth it. After all, you can always edit the configuration file manually. I'd expect someone remotely administrating a system to prefer the command line version anyway. And as stated above, dumping the available options of a driver should be no problem, even without X. [...] 3.5 Where would the DTDs be stored so that they are available to the driver and the GUI? Is validating parsing a must? To tell the truth, I havn't looked to much into XML details yet. But my general understanding is, that you want to detect errors in the configuration file instead of silently ignoring them. The good thing about using libxml is, that this is probably possible without much effort for us. Regards, José Fonseca Thanks for your feedback. Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] HEADSUP: bsd-4-0-0-branch merging
On Thu, 2003-02-20 at 16:30, Eric Anholt wrote: I'm currently working on merging bsd-4-0-0-branch to trunk, starting with the merge to the branch. If things stay quiet on the trunk, that would be wonderful. Been a busy night and cvs conflicts have been troubling me. I've got a merged version on my drive and should finish it off tomorrow. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] UT2003 crash with current trunk
On Thu, Feb 20, 2003 at 09:05:27PM -0500, Daniel Vogel wrote: There is no way in hell UT2k3 will run on MGA. It *REQUIRES* ARB_texture_env_combine, which is not supported by that hardware. Even if it didn't require that extension, good grief man, why torture yourself like that?!? :) FWIW, the Windows version of UT2003 even runs (badly) on Intel 810 and Voodoo Banshee cards :) A G400 actually performs better than a TNT2 due to the increased fillrate. (all D3D) I've got a G400 MAX as well -- it does pretty well all things considered when paired with a beefy enough processor to compensate for the lack of TL. Twas briefly the fastest GPU around ISTR, til Nvidia stole the crown with the GeForce... Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] S3TC (again)
OK, I don't exactly want to stir up this hornets nest *again*, but a couple of things aren't entirely clear to me and I'd appreciate any clarifications. As I understand it, the situation is as follows: The S3TC algorithm is patented and therefore no-one can distribute an implementation of the algorithm without a licence from the patent holders. S3TC decompression must be implemented in the hardware (otherwise what's the point), therefore hardware which uses S3TC can be assumed to have a valid licence to use the code, otherwise the patent owners would be down on the hardware manufacturers like the proverbial ton of bricks. As far as I'm aware, the main users of S3TC are modern games with their vast arrays of textures -- presumably such games come with the textures precompressed, or are able to compress them and cache the compressed textures themselves. Presumably again, the authors of the games have paid for a licence to use the S3TC algorithm from the patent holders. Now, if an OpenGL application has a pile of textures already compressed with the S3TC algorithm, then I don't understand why the dri drivers can't simply offer the S3TC interfaces to the hardware, pass the compressed textures to the hardware and let the hardware get on with its licensed decompression of the textures as required. Likewise, if the OpenGL application passes compressed textures to the S3TC API then how it gets hold of the compressed textures in the first place is it's own responsibility -- the OpenGL API just passes them on. This line of reasoning suggests that no software fallback can be provided for S3TC in the Xfree DRI, since such a fallback would require decompressing the textures which would require a patent licence which the DRI doesn't have. However, there should be no barriers to implementing the API in the case where the textures are simply passed from an application to the hardware. Is the reason that this hasn't been done because there a fault in my reasoning (obviously IANAL), or are the DRI developers are just leery of going anywhere near the whole tarball of pain (not being lawyers either) and are happier coding things which don't have patents looming around them? Presumably there's also the issue of hardware documentation to implement the API on top of the hardware -- I'm assuming that this is available obviously. cheers all, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] TRUSTEE NEEDED
Dear Sir My name is LOI C.ESTRADA,The wife of Mr. JOSEPH ESTRADA, the former President of Philippines located in the South East Asia. My husband was recently impeached from office by a backed uprising of mass demonstrators and the Senate. My husband is presently in jail and facing trial on charges of corruption, embezzlement, and the mysterious charge of plunder which might lead to death sentence. The present government is forcing my husband out of manila to avoid demonstration by his supporter. During my husband's regime as president of Philippine, I realized some reasonable amount of money from various deals that I successfully executed. I have plans to invest this money for my children's future on real estate and industrial production. My husband is not aware of this because I wish to do it secretly for now. before my husband was impeached, I secretly siphoned the sum of $30,000,000 million USD (Thirty million United states dollars) out of Philippines and deposited the money with a security firm that transports valuable goods and consignments through diplomatic means. I also declared that the consignment was solid gold and my foreign business partner owned it. I am contacting you because I want you to go to the security company and claim the money on my behalf since I have declared that the consignment belong to my foreign business partner. You shall also be required to assist me in investment in your country. I hope to trust you as a God fearing person who will not sit on this money when you claim it, rather assist me properly, I expect you to declare what percentage of the total money you will take for your assistance. When I receive your positive response I will let you know where the security company is and the payment pin code to claim the money which is very important. For now, let all our communication is by e-mail because my line are right now connected to the Philippines Telecommunication Network services. Please also send me your telephone and fax number. I will ask my son contact you to give you more details on after i have received a responce from you. Thank you and God bless you and family. MRS LOI C ESTRADA --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Design draft of a new Configuration Infrastructure
Felix Kühling wrote: On Fri, 21 Feb 2003 01:36:01 + José Fonseca [EMAIL PROTECTED] wrote: Felix, D. Hageman, On Wed, Feb 19, 2003 at 09:52:47AM +0100, Felix Kühling wrote: Hello list, D. Hageman and I have been bouncing a design document for the new configuration infrastructure back and forth in private mail for the past week. Now we think it's ready for public discussion. You may notice that the structure is quite similar to Ians texmem design. This is the first time I'm writing such a document so I took Ian's work as a good example. The document is attached in plain text format. Nice work. You've covered alot of ground. [...] 2.2 Advertising available options [...] In order to get access to available options a GUI tool would first have to find the driver associated with a particular screen number. The DRI extension provides calls which determine whether direct rendering is supported on a screen and by which driver. Then it can ldopen the driver and obtain the address of a symbol which contains the information about available options in XML format. A GUI written in a scripting language like perl or python may not have bindings for the X protocol and it may not be able to ldopen a shared object file. In this case the GUI could call a small command line program which dumps the available options on its standard output. This program would be part of the DRI/XFree86 distribution. I don't if it is possible at all, but it surely would be nice if we didn't have to rely on having X access at all - e.g., in remote administration or single user mode. Is there any way to avoid this depency? Brian proposed that libGL could find and load the driver to get the available options. It should be possible to do that without X access. Of course you can't find the driver for a specific screen if X is not running. But if you know the driver name, libGL should find it. (someone correct me if I'm wrong) If X is not running, it could be hard to identify the relevant DRI driver(s). You'd probably have to examine /proc/pci and have a way to map PCI Ids to DRI drivers. Going though libGL (with X and DRI's help) lets us avoid that mess (and would let other vendors use the mechanism). Alternately, a config tool could look in the standard directory for DRI drivers and scan all of them for options and let the user twiddle with whichever one(s) he wants. The most complicated step in that sense would be to determine the driver shared library. If the path of the driver shared library was cached in the configuration files, or the parameters description was duplicated in the configuration files, then the GUI/script could use this cached info and do his thing in off-line mode... IMHO adding some sort of offline mode would increasing the complexity of this system quite a lot. The question is whether it's worth it. After all, you can always edit the configuration file manually. I'd expect someone remotely administrating a system to prefer the command line version anyway. And as stated above, dumping the available options of a driver should be no problem, even without X. Right. -Brian --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Design draft of a new Configuration Infrastructure
On Fri, 21 Feb 2003 07:43:24 -0700 Brian Paul [EMAIL PROTECTED] wrote: Felix Kühling wrote: On Fri, 21 Feb 2003 01:36:01 + José Fonseca [EMAIL PROTECTED] wrote: [snip] I don't if it is possible at all, but it surely would be nice if we didn't have to rely on having X access at all - e.g., in remote administration or single user mode. Is there any way to avoid this depency? Brian proposed that libGL could find and load the driver to get the available options. It should be possible to do that without X access. Of course you can't find the driver for a specific screen if X is not running. But if you know the driver name, libGL should find it. (someone correct me if I'm wrong) If X is not running, it could be hard to identify the relevant DRI driver(s). You'd probably have to examine /proc/pci and have a way to map PCI Ids to DRI drivers. Going though libGL (with X and DRI's help) lets us avoid that mess (and would let other vendors use the mechanism). Alternately, a config tool could look in the standard directory for DRI drivers and scan all of them for options and let the user twiddle with whichever one(s) he wants. I was thinking that a command line tool should be able to dump available options of a specific driver even without X access. This is intended for the remote administrator as a reference when editing the configuration file manually. So the question is whether libGL needs X access in order to find the correct driver directory or is that defined at compile-time? I was obviously assuming the latter. A graphical config tool will always have access to X. So you don't need to fiddle with /proc/pci or ask the user for mapping e.g. screen numbers to driver names. This is of course assuming that the config tool runs on a local display. The most complicated step in that sense would be to determine the driver shared library. If the path of the driver shared library was cached in the configuration files, or the parameters description was duplicated in the configuration files, then the GUI/script could use this cached info and do his thing in off-line mode... IMHO adding some sort of offline mode would increasing the complexity of this system quite a lot. The question is whether it's worth it. After all, you can always edit the configuration file manually. I'd expect someone remotely administrating a system to prefer the command line version anyway. And as stated above, dumping the available options of a driver should be no problem, even without X. Right. -Brian Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Design draft of a new Configuration Infrastructure
Felix Kühling wrote: On Fri, 21 Feb 2003 07:43:24 -0700 Brian Paul [EMAIL PROTECTED] wrote: Felix Kühling wrote: On Fri, 21 Feb 2003 01:36:01 + José Fonseca [EMAIL PROTECTED] wrote: [snip] I don't if it is possible at all, but it surely would be nice if we didn't have to rely on having X access at all - e.g., in remote administration or single user mode. Is there any way to avoid this depency? Brian proposed that libGL could find and load the driver to get the available options. It should be possible to do that without X access. Of course you can't find the driver for a specific screen if X is not running. But if you know the driver name, libGL should find it. (someone correct me if I'm wrong) If X is not running, it could be hard to identify the relevant DRI driver(s). You'd probably have to examine /proc/pci and have a way to map PCI Ids to DRI drivers. Going though libGL (with X and DRI's help) lets us avoid that mess (and would let other vendors use the mechanism). Alternately, a config tool could look in the standard directory for DRI drivers and scan all of them for options and let the user twiddle with whichever one(s) he wants. I was thinking that a command line tool should be able to dump available options of a specific driver even without X access. Yes, if you know the name of the driver, and where it's located. This is intended for the remote administrator as a reference when editing the configuration file manually. So the question is whether libGL needs X access in order to find the correct driver directory or is that defined at compile-time? I was obviously assuming the latter. At runtime, we have to ask X for the name of the driver for each X screen. Then, libGL looks at the LIBGL_DRIVERS_PATH env var or uses the default directory (/usr/X11R6/lib/modules/dri/) to dlopen the named driver. Nothing is really known at compile time. A graphical config tool will always have access to X. So you don't need to fiddle with /proc/pci or ask the user for mapping e.g. screen numbers to driver names. This is of course assuming that the config tool runs on a local display. If I write a config tool in Python/wxWindows, it won't know anything about X. In that case, an external utility to get the default driver for the default display's screens will be needed. This is basically what we implemented for the Chromium project. The most complicated step in that sense would be to determine the driver shared library. If the path of the driver shared library was cached in the configuration files, or the parameters description was duplicated in the configuration files, then the GUI/script could use this cached info and do his thing in off-line mode... IMHO adding some sort of offline mode would increasing the complexity of this system quite a lot. The question is whether it's worth it. After all, you can always edit the configuration file manually. I'd expect someone remotely administrating a system to prefer the command line version anyway. And as stated above, dumping the available options of a driver should be no problem, even without X. Right. -Brian Felix -Brian --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] ^Mortgage Rates At 40 year Low 6115CoCz5-301zeaw7895SbyO9--25
Title: ::M::Wqkfeowpefvweviiqkqtqdkudnwmmgnpcxknipesuyn
DYLAN
lfYOxtnn202smj7M2G
4363WpYp6-354KUua8563BOrH3-l25+wzf¢+,¦ì¢·o$¥Év+HÀÞ½éh¥©Þv
騲×(Þ
éì÷×å{ç(uçÚ+Êj{¬x* yö¬µêÂü/[EMAIL PROTECTED]:âj\0ÂÉbrG×(û(º· ~àx:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
