Re: [Dri-devel] Configuration file format survey
Philip Brown wrote:
On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote:
If anyone has serious objections to XML, please let us know (mail to
dri-devel will suffice ;-).
I object. Using xml inevitably leads to files that are completely
human-unreadable, except perhaps to the original developers.
Please stick with ye olde standard XF86Config type format.
It could be better, but it is CERTAINLY better than XML.
Perhaps it would be better if there was an example of the type of
configuration that would be expressed in the putative configuration file.
Why would an XFree86 (which I don't much like) or a simple
[blah]
foo=bar
bb={sheep, cows, emus}
type format be insufficient?
-d
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Mon, 27 Jan 2003 22:37:06 -0600 (CST) D. Hageman [EMAIL PROTECTED] wrote: C code can be edited with any text editor, too. But the percentage of DRI users that can usefully DO that, is a very small number, comparative to the overall number of users. Hence the GUI ... I think I have covered all the arguments that needed to be addressed. Um. this is unix. dont forget the command line. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, 28 Jan 2003 02:55:22 -0600 (CST) D. Hageman [EMAIL PROTECTED] wrote: So what are the technical advantages of XML in this case? Quick List -- *) Text Based - easy to edit. Text based does NOT imply easy to edit. look at USBsnopys' output. its completely illegible. *) Well known basic format (think each tag must be ended, etc.) Not a valid argument. no two schemas are alike. *) Million and one tools already exist that handle XML if you didn't want to edit by hand. Way more code than necessary. bloat. *) Every major programming language has some library to handle XML (say if you hacked togther a library that does the XF86Config file format ... this wouldn't be the case). Irrelevant in this case. *) Extensible, no painting ourselves into a corner. One can easily extend the spec without having to rewrite the entire parser. Also irrelevant. the USERS will never need to do this. The parser is also non-trivial. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, 28 Jan 2003 01:25:48 -0600 (CST) D. Hageman [EMAIL PROTECTED] wrote: what alternative do you propose that would be faster? Are we talking seconds, minutes, hours ... what? On some systems, every nanosecond counts. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, 28 Jan 2003 02:05:34 +0200 Arkadi Shishlov [EMAIL PROTECTED] wrote: It is also possible to rebuild XML parser in some binary incompatible way.. or find someone compiled their own broken one. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Mon, Jan 27, 2003 at 10:41:20PM -0600, D. Hageman wrote: Those are some excellent examples of abuse. It doesn't have to be like that. [..] If we went with libxml2 it has no exterior dependencies that I am aware. Probably I was harsh when I said no to XML. Using libxml is good from code reuse point for view. Parsing and emiting XML is simple. But, please make it readable for those who do not want to use GUI. The last thing, I suspect, many of us want to see is a config with tons of param-nameparam/param-nameparam-valuevalue/param-value. I think libxml is OK, as you said it is already in XFree86. Parsing time is not an issue, /bin/ls doesn't use DRI, OpenGL programs are rare started up. arkadi. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, Jan 28, 2003 at 10:37:03AM +, Ian Molton wrote: On Tue, 28 Jan 2003 02:55:22 -0600 (CST) D. Hageman [EMAIL PROTECTED] wrote: So what are the technical advantages of XML in this case? Quick List -- *) Text Based - easy to edit. Text based does NOT imply easy to edit. look at USBsnopys' output. its completely illegible. Well, i think there is a misunderstanding on what 'easy to read' mean. After all, some would say, it is ok to use a binary format, after all, you just need an hex editor and you can modify it to your hearts content. I personally think xml is not really all that readable, especially because of the end tag, which maybe is not really needed, altough i don't know exactly what we are going to store. *) Extensible, no painting ourselves into a corner. One can easily extend the spec without having to rewrite the entire parser. Also irrelevant. the USERS will never need to do this. Well, i think this is relevant and a good advantage to using xml. Maybe the user will not need to use it, but imagine that each driver will need to support a different set of parameters or something such, so there will be a common set of parameters, and each driver can extend it to define driver specific parameters. Maybe before we continue in this xml flamewar, it would be best to define what exactly we are going to express in this config file. Will it include only booleans and numeric values, or maybe also matrices, or even other stuff (graphic programs ?). Friendly, Sven Luther --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
Philip Brown wrote: On Mon, Jan 27, 2003 at 10:37:06PM -0600, D. Hageman wrote: On Mon, 27 Jan 2003, Philip Brown wrote: Preferably in an area that XML was designed for: in exchanging data between programs and OTHER programs, not between humans and programs. Simplify: GUI configuration tool (program) -- Driver (program) There are GUI tools for Xfree configuration too, and they have managed to get along fine without using XML. If you want a Library for config file parsing, cant you just use whatever the x server itself uses? There are two other things to consider here, whatever format is chosen. 1. We'd like to have other people be able to make configuration utilities. Looking at the number and variety of configuration utilites just for Nvidia's close-source drivers shows that this is a worthwhile goal. 2. Our first spin of a configuration utility will probably be written in Python or Tcl or someother scripting language. The idea being that we could prototype something functional quickly. I suspect that the XFree86 config file parser is not available for either of those languages. This is one of the reasons that using a VERY simple Python dictionary as the file format was considered. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
Ian Molton wrote: On Tue, 28 Jan 2003 02:55:22 -0600 (CST) D. Hageman [EMAIL PROTECTED] wrote: *) Every major programming language has some library to handle XML (say if you hacked togther a library that does the XF86Config file format ... this wouldn't be the case). Irrelevant in this case. *) Extensible, no painting ourselves into a corner. One can easily extend the spec without having to rewrite the entire parser. Also irrelevant. the USERS will never need to do this. Of all the items on his list, I would say that these are the two that are relevant. Having easy-access for multiple languages makes it easier for other people to create programs that will use the format. I, personally, would really like to multiple, independent configuration utilities made. Survival of the fittest will see which lasts. If we select a fairly obscure format, there will likely be fewer utilities made and the quality will (in some way) suffer. People don't have infinite time, so if they have to spend it working on a config file parser, the aren't spending it on something else. Having the format be easilly extensible is relevent to us. I don't think that we will ever need to add anything to the file format beyond the initial offering, but we may. It sure would be nice if such a transition could be made as transparent as possible. If everyone that makes a configuration utility has to update their program in order for it to work at all with the updated format (taking advantage of the new elements of the format is another issue), the transition would be less transparent. This is bad for users. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Gazete keyfini yasayin!
Title: GAZETE KEYFÝ Gazete Keyfi...Her sabah güne baþlarken içinizi ýsýtacak bir site burasý...Sýcacýk çayýnýzý yudumlarken ya da yemekten sonra kahvenizi içerken alacaðýnýz keyfi ikiye katlayacak, Türkiye ve Dünyada neler olup bittiðini izleyebileceðiniz, günlük bulmacanýzý çözebileceðiniz, elinizin altýnda olmasý gereken bütün linklere ulaþabileceðiniz bir site... Dergileri, yerel ve günlük gazeteleri, iþ ilanlarýný, televizyonlarý, radyolarý, tiyatrolarý, sinemalarý ve günlük yaþama dair herþeyi bir arada bulabileceðiniz, ana sayfanýz olmaya aday bir site...Bekliyoruz...www.gazetekeyfi.comDuyuru listemizden çýkmak için lütfen týklayýnýz... To be removed from our mailing list, please click here... --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
Damien Miller wrote:
Philip Brown wrote:
On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote:
If anyone has serious objections to XML, please let us know (mail to
dri-devel will suffice ;-).
I object. Using xml inevitably leads to files that are completely
human-unreadable, except perhaps to the original developers.
Please stick with ye olde standard XF86Config type format.
It could be better, but it is CERTAINLY better than XML.
Perhaps it would be better if there was an example of the type of
configuration that would be expressed in the putative configuration file.
Why would an XFree86 (which I don't much like) or a simple
[blah]
foo=bar
bb={sheep, cows, emus}
type format be insufficient?
A win.ini type file format was initially considered. In fact, the Kyro
binary-only drivers for Linux use this type of format for this same
purpose. Using a win.ini format was my first idea, if for no other
reason than to follow the precedent of the Kyro drivers. There were two
reasons this was rejected, neither of which was relevant for the people
making the Kyro drivers.
We would like to have a single configuration file for all cards in a
system. Each of these cards may have differenent hardware and want
different settings. Sections in the config file need a way to signal
that they are global settings (apply to all cards) or which card /
screen they are for. We need the same type of selection based on
application. Users will likely want to tune differently for Maya than
for UT 2k3. That basically gives us a sparse 2D matrix of
configurations. There's no logical way to do this with a win.ini file,
but we could do it with something that is heirarchical and semi-free form.
The other reason we rejected a win.ini format is that we want the driver
to describe the available options to the configuration utility using the
same or similar file format as the configuration file. A win.ini format
just didn't feel like a good fit for that purpose.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Config file processing time (was Re: [Dri-devel] Configuration fileformat survey)
Ian Molton wrote: On Tue, 28 Jan 2003 01:25:48 -0600 (CST) D. Hageman [EMAIL PROTECTED] wrote: what alternative do you propose that would be faster? Are we talking seconds, minutes, hours ... what? On some systems, every nanosecond counts. There are four times when the configuration file format would need to be processed. 1. When some utility (either a GUI configuration tool or just a dump utility) reads the list of available settings from the driver. 2. When some utility reads the configuration file to present the current settings to the user. 3. When some utility writes the configuration file. 4. When an OpenGL application starts. Specifically, the configuration file would be processed when the first GL context is created, which may not be immediatly when the application starts. Of the four, only the fourth has performance requirements that cannot be measured using a stopwatch. Nanoseconds is too harsh of a metric, but there is certainly a reasonable limit to how much time we can spend processing a configuration file. This sounds like a good case for a conformance test. We'll need to figure out, for a baseline platform, what upper-bound is for the time spent on a pathological config file. Coming up with a pathological case should be done sooner rather than later. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Keith Whitwell wrote: Ian Romanick wrote: Did you ever monkey around with their 16-sample texture filter (the anisotropic mode)? I played with that a bit, but every time I selected that mode it would crash the graphics chip. :( No, never tried it. Do you have to somehow dedicate both texture units to the task? If you do, it sure doesn't make any mention of it in the documentation, but that doesn't seem to mean anything. :) The only restrictions that it mentions is that transparency must be disabled and filteralpha must be enabled. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Configuration file format survey
When we did the powervr.ini file structure we ported code from our Win32
drivers which used the same file structure. But Win32 offers an API to
read/write those kind of files, while for the Linux driver we had to rewrite
it from scratch. (not fun always :). But it satisfied our needs good enough.
But if you guys decide on a format we might adhere to it since it would be
nice if we simplify our drivers by using a loadable library. Also as far as
time goes we generally cache the file in memory and we flush whenever there
is a write. But then our files are small and timing was not THAT essential.
Vlad Stamate
www.powervr.com
-Original Message-
From: Ian Romanick [mailto:[EMAIL PROTECTED]]
Sent: 28 January 2003 16:19
To: DRI developer's list
Subject: Re: [Dri-devel] Configuration file format survey
Damien Miller wrote:
Philip Brown wrote:
On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote:
If anyone has serious objections to XML, please let us know (mail to
dri-devel will suffice ;-).
I object. Using xml inevitably leads to files that are completely
human-unreadable, except perhaps to the original developers.
Please stick with ye olde standard XF86Config type format.
It could be better, but it is CERTAINLY better than XML.
Perhaps it would be better if there was an example of the type of
configuration that would be expressed in the putative configuration file.
Why would an XFree86 (which I don't much like) or a simple
[blah]
foo=bar
bb={sheep, cows, emus}
type format be insufficient?
A win.ini type file format was initially considered. In fact, the Kyro
binary-only drivers for Linux use this type of format for this same
purpose. Using a win.ini format was my first idea, if for no other
reason than to follow the precedent of the Kyro drivers. There were two
reasons this was rejected, neither of which was relevant for the people
making the Kyro drivers.
We would like to have a single configuration file for all cards in a
system. Each of these cards may have differenent hardware and want
different settings. Sections in the config file need a way to signal
that they are global settings (apply to all cards) or which card /
screen they are for. We need the same type of selection based on
application. Users will likely want to tune differently for Maya than
for UT 2k3. That basically gives us a sparse 2D matrix of
configurations. There's no logical way to do this with a win.ini file,
but we could do it with something that is heirarchical and semi-free form.
The other reason we rejected a win.ini format is that we want the driver
to describe the available options to the configuration utility using the
same or similar file format as the configuration file. A win.ini format
just didn't feel like a good fit for that purpose.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
I'm not a developer and I know nothing about XML and so have no real opinion as to what the file format should be. I am however woried about comments like the ones quoted below. The notion that users dont edit config files by hand may be all fine and good in the microsoft world but last time I checked I was using linux. You can't make the same assumptions about what users want to do as you can in the microsoft world. Most linux users are power users and want to have complete control over everything. If the XML can be kept relativly simple to read and edit then fine but the end user should never have to use a config tool if they don't want to. So please keep it as simple as possle. In my opinion the readability of the config file should be a much bigger concern then having a multitued of configuration programs out there. Even the best config program will have it's limits and I for one don't want to be constrained by them. Sincerily, Steven Lilly Alan Cox wrote: XML printed sensibly is ok for human editing (not ideal). Users dont edit config files however they use apps to do this. and Users want config files that work, they expect to use applications to edit them, and they also expect things like downgrading to work with the same configuration file - which XML can do. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
[...] The notion that users dont edit config files by hand may be all fine and good in the microsoft world but last time I checked I was using linux. You can't make the same assumptions about what users want to do as you can in the microsoft world. I'd like to add _strong_ support to this opinion, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
Vlad Stamate wrote: When we did the powervr.ini file structure we ported code from our Win32 drivers which used the same file structure. But Win32 offers an API to read/write those kind of files, while for the Linux driver we had to rewrite it from scratch. (not fun always :). But it satisfied our needs good enough. I figured that it was probably something like that. But if you guys decide on a format we might adhere to it since it would be nice if we simplify our drivers by using a loadable library. Also as far as time goes we generally cache the file in memory and we flush whenever there is a write. But then our files are small and timing was not THAT essential. That is VERY good news to my ears! After we have most of our stuff done, we're going to have to try to talk the various vendors of OpenGL drivers for Linux into using our system. Having one vendor tenetively agree before we even ask is nice. :) As far as caching goes, I guess I don't understand. Does that mean that if someone changes settings while an OpenGL application is running, the changes will take effect in the running app? Will it only take effect if the app creates a new rendering context? I had always just assumed that we would take a snap-shot of the settings when the app created its first context. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 3DNow normalization bug
Hi, I recently discovered some problem with normal vectors in the gflux hack on my Duron, Radeon 7500 with and without TCL, even with RADEON_NO_RAST=1. LIBGL_ALWAYS_INDIRECT works correctly, though. A workaround is MESA_NO_3DNOW=1. Another way is to normalize the normals in gflux and change glEnable(GL_NORMALIZE) to glEnable(GL_RESCALE_NORMAL). By playing around with the -squares option of gflux I could determine that every 216th normal vector is not normalized correctly. The normalization function used is _mesa_3dnow_transform_normalize_normals in xc/extras/Mesa/src/X86/3dnow_normal.S. I don't understand where the magical 216 comes from. My guess is that _mesa_3dnow_transform_normalize_normals always gets 216 normals to transform and forgets one of them (first one or last one, can't tell). I hope this info helps someone to spot the error quickly. 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: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Configuration file format survey
Well, you are right. When a new app starts it does cache the file. So if something else modifies the file (ini file) the OpenGL app will only know if it needs to write and therefore synch. BTW there is tool that modifies our files: KLT (Kyro Linux Tools). Anyway I am glad to be of help. Vlad Stamate. www.powervr.com -Original Message- From: Ian Romanick [mailto:[EMAIL PROTECTED]] Sent: 28 January 2003 17:22 To: DRI developer's list Subject: Re: [Dri-devel] Configuration file format survey Vlad Stamate wrote: When we did the powervr.ini file structure we ported code from our Win32 drivers which used the same file structure. But Win32 offers an API to read/write those kind of files, while for the Linux driver we had to rewrite it from scratch. (not fun always :). But it satisfied our needs good enough. I figured that it was probably something like that. But if you guys decide on a format we might adhere to it since it would be nice if we simplify our drivers by using a loadable library. Also as far as time goes we generally cache the file in memory and we flush whenever there is a write. But then our files are small and timing was not THAT essential. That is VERY good news to my ears! After we have most of our stuff done, we're going to have to try to talk the various vendors of OpenGL drivers for Linux into using our system. Having one vendor tenetively agree before we even ask is nice. :) As far as caching goes, I guess I don't understand. Does that mean that if someone changes settings while an OpenGL application is running, the changes will take effect in the running app? Will it only take effect if the app creates a new rendering context? I had always just assumed that we would take a snap-shot of the settings when the app created its first context. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Compilation problems...
Hello all :-) I have an unusual problem I'm hoping someone can help me with. I'm trying to compile the DRI from within a chrooted linux environment on FreeBSD. I've encountered a few errors that I've been able to work through (I needed to install perl, create /tmp, etc.), but this one has me stumped. When it starts to compile the ATI drivers, I begin to get this error over and over: In file included from r128_dga.c:9: r128.h:462: parse error before `R128CCEGetBuffer' r128.h:462: warning: type defaults to `int' in declaration of `R128CCEGetBuffer' r128.h:462: warning: data definition has no type or storage class make[7]: *** [r128_dga.o] Error 1 It actually manges to compile the radeon_drv.o XFree86 module, but the XFree86 DRI library (r200_dri.so) fails to build, as does the libGL.so library. This would appear to be the only actual errors from the build. Anyone want to offer a suggestion? :-) Adam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
D. Hageman wrote: Hence the GUI ... GUI... Seriously, if you a technical reason why ... I would love to hear it. Technical reason? XML is Bad By Nature, what reason do you expect? :) Never heard such a lame thing as using a GUI (who needs that) to edit XML (who needs that) ... (pls don't answer, I'm just some external flamethrower;) -- Gabucino MPlayer Core Team msg08813/pgp0.pgp Description: PGP signature
Re: [Dri-devel] Compilation problems...
Adam K Kirchhoff wrote: I'm trying to compile the DRI from within a chrooted linux environment on FreeBSD. I've encountered a few errors that I've been able to work through (I needed to install perl, create /tmp, etc.), but this one has me stumped. When it starts to compile the ATI drivers, I begin to get this error over and over: In file included from r128_dga.c:9: r128.h:462: parse error before `R128CCEGetBuffer' r128.h:462: warning: type defaults to `int' in declaration of `R128CCEGetBuffer' r128.h:462: warning: data definition has no type or storage class make[7]: *** [r128_dga.o] Error 1 It actually manges to compile the radeon_drv.o XFree86 module, but the XFree86 DRI library (r200_dri.so) fails to build, as does the libGL.so library. This would appear to be the only actual errors from the build. It seems to be barfing because drmBufPtr is not defined. That comes from programs/Xserver/hw/xfree86/os-support/xf86drm.h. I can't see how xf86drm.h ever gets included by either r128.h or r128_dga.c. xf86drm.h gets included by xf86dri.h r128_dri.h. There are other r128 files that included it, but they live in a different part of the tree. r128_dri.h gets included by a couple files in drivers/ati, but not by r128.h or r128_dga.c. xf86dri.h isn't included by anything relevant. Basically, I can't see how r128_dga.c ever compiles correctly. :/ Try including xf86drm.h at the start of r128.h and see if that helps. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, 28 Jan 2003, Dieter Nützel wrote: Am Dienstag, 28. Januar 2003 08:22 schrieb D. Hageman: On Mon, 27 Jan 2003, Philip Brown wrote: I am trying to point out that none of [-] On the other hand, DRI is meant to integrate with XFree86. XFree86 has a standard configuration file format. We should follow the 'principle of least surprise', and use the same format they are used to for X11 configuration DOES seem to make a good deal of sense, when considering the needs of users as more important than the needs of developers. Two things: 1) Don't kick a gift horse in the mouth. If the users really want something in a certain way are more the happy to do it. 2) The XF86Config file format does what it does very well. It isn't necessarily what we are looking for. It also isn't exactly a library that one can just use. It is a very custom built parser for a very specific purpose. We don't need to re-invent the wheel here. Make the file format as simple as possible. Absolutely. The XML format is already well known and very straight forward. A million and one tools exists for manipulation of these files. Not only for the users but think about remote editing/managing even if it is meant as a local config file. This was good Unix thinking for ages. Absolutely. XML is text based so any text editor can modify it. Assuming we can stick to your first request, then it only follows that it would be easy to do remotely with a simple vi session or ... X11 remote running of applications could do it graphically as well. So what are the technical advantages of XML in this case? Quick List -- *) Text Based - easy to edit. *) Well known basic format (think each tag must be ended, etc.) *) Million and one tools already exist that handle XML if you didn't want to edit by hand. *) Every major programming language has some library to handle XML (say if you hacked togther a library that does the XF86Config file format ... this wouldn't be the case). *) Extensible, no painting ourselves into a corner. One can easily extend the spec without having to rewrite the entire parser. *) Assume that we have to in the future change the format specification: A simple XSLT file could transform the current into the other format without issues or having to write a bunch of C/perl/python code. 'nuff said? In some ways it is over kill. I have this philosophy though: If you do it right the first time and maybe go that extra mile you don't have to worry about it later. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Merge from trunk to texmem-0-0-1
[ Ian wrote ] There have been rumblings on [EMAIL PROTECTED] about problems with Radeon in 4.2.99.4, but I didn't think that those problems had propogated into DRI CVS yet. That's a shame. :( I think it's the other way round: The DRI stuff that got merged into XFree86 4.2.99.x 'releases' has _never_ever_ been usuable with FlightGear on Radeon7500, so it's not surprising that problems show up with XFree86 pre releases :-/ In purpose to find something usuable for FlightGear that features TL on my Radeon7500 I'm now testing every branch I can find in CVS ;-))) Maybe sometime we could offer a recommendation of what would be useful to get merged into XFree86 In the mean time, you ought to be able to revert back to texmem-0-0-1-20030123-trunk-premerge and update everything EXCEPT programs/Xserver/hw/xfree86/drivers/ati/. [...] Thanks, I'll try ASAP (I'll be out of office for a few days, I think I'll need a DRI capable Notebook ;-), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Compilation problems...
Well, that solved that particular problem :-) I don't think that's fixed all my problems, though. Let me grab a clean copy of the CVS, patch that file, do a make World again, and post any more problems I end up having. Adam On Tue, 28 Jan 2003, Ian Romanick wrote: Adam K Kirchhoff wrote: I'm trying to compile the DRI from within a chrooted linux environment on FreeBSD. I've encountered a few errors that I've been able to work through (I needed to install perl, create /tmp, etc.), but this one has me stumped. When it starts to compile the ATI drivers, I begin to get this error over and over: In file included from r128_dga.c:9: r128.h:462: parse error before `R128CCEGetBuffer' r128.h:462: warning: type defaults to `int' in declaration of `R128CCEGetBuffer' r128.h:462: warning: data definition has no type or storage class make[7]: *** [r128_dga.o] Error 1 It actually manges to compile the radeon_drv.o XFree86 module, but the XFree86 DRI library (r200_dri.so) fails to build, as does the libGL.so library. This would appear to be the only actual errors from the build. It seems to be barfing because drmBufPtr is not defined. That comes from programs/Xserver/hw/xfree86/os-support/xf86drm.h. I can't see how xf86drm.h ever gets included by either r128.h or r128_dga.c. xf86drm.h gets included by xf86dri.h r128_dri.h. There are other r128 files that included it, but they live in a different part of the tree. r128_dri.h gets included by a couple files in drivers/ati, but not by r128.h or r128_dga.c. xf86dri.h isn't included by anything relevant. Basically, I can't see how r128_dga.c ever compiles correctly. :/ Try including xf86drm.h at the start of r128.h and see if that helps. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Configuration file format survey
Hallo We've been discussing general issues regarding the new DRI configuration system recently on IRC. The most user-visible issue is the configuration file format (until there is a GUI tool ;-). In any case we need a more structured (nested) format than win.ini since we want to be able to set parameters per driver/screen/application or any combination of those. I take it that you set your options for the driver, andoverride them on a per screen basis, whih acre in turn overridden on a per application basis? If so I like that. We tentatively decided to use XML for the configuration file as well as for the drivers' specification of available parameters. Other alternatives which were discussed AFAIR are a Lisp-like syntax as in the mesa config file, python dictionaries (see Ians mail Configuration idea) or something completely home-made. Unfortunately there seem to be no IRC logs of relevant meetings :-( If anyone has serious objections to XML, please let us know (mail to dri-devel will suffice ;-). Ja, I like .conf style, plaintext. If you want to implement it in XML then I'd definitely want a plain text file which I can edit by hand, in case graphical editing program gets broken, is unavilable, no GUI is available etc. If you can't do it via GUI and the command line its not a good thing. Liam it depends --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Compilation problems...
Ian, Well, the build isn't done yet, but it's much further along now, having built the GL library and the Direct Rendering Library, as well as the 2D drivers. FYI, the problem with the r128 driver also exists in the texmem branch, which errored at the same point. I don't know, however, how long it's been like that :-) Adam On Tue, 28 Jan 2003, Adam K Kirchhoff wrote: Well, that solved that particular problem :-) I don't think that's fixed all my problems, though. Let me grab a clean copy of the CVS, patch that file, do a make World again, and post any more problems I end up having. Adam On Tue, 28 Jan 2003, Ian Romanick wrote: Adam K Kirchhoff wrote: I'm trying to compile the DRI from within a chrooted linux environment on FreeBSD. I've encountered a few errors that I've been able to work through (I needed to install perl, create /tmp, etc.), but this one has me stumped. When it starts to compile the ATI drivers, I begin to get this error over and over: In file included from r128_dga.c:9: r128.h:462: parse error before `R128CCEGetBuffer' r128.h:462: warning: type defaults to `int' in declaration of `R128CCEGetBuffer' r128.h:462: warning: data definition has no type or storage class make[7]: *** [r128_dga.o] Error 1 It actually manges to compile the radeon_drv.o XFree86 module, but the XFree86 DRI library (r200_dri.so) fails to build, as does the libGL.so library. This would appear to be the only actual errors from the build. It seems to be barfing because drmBufPtr is not defined. That comes from programs/Xserver/hw/xfree86/os-support/xf86drm.h. I can't see how xf86drm.h ever gets included by either r128.h or r128_dga.c. xf86drm.h gets included by xf86dri.h r128_dri.h. There are other r128 files that included it, but they live in a different part of the tree. r128_dri.h gets included by a couple files in drivers/ati, but not by r128.h or r128_dga.c. xf86dri.h isn't included by anything relevant. Basically, I can't see how r128_dga.c ever compiles correctly. :/ Try including xf86drm.h at the start of r128.h and see if that helps. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-devel][patch] 3DNow normalization bug
Felix Kühling wrote: It seems I like answering my own mails ;-) I fixed this problem but it is probably not optimal. A simple patch is attached. It seems that this error was introduced by an atempt to optimize prefetching. The next normal was read into MM0 and MM1 at the end of the G3TN_norm loop. So in the first cycle MM0 and MM1 were undefined. Furthermore it read one extra normal at the end of the array which was never processed. The patch moves the load operations back to the front of the loop as in the G3TN_norm_w_lengths case. Good catch. It looks like this went into the Mesa tree back in October of 2001...over a year ago! It looks like Andres Lewycky gave Brian some bad patches. :( I realize that AMD recommends reading memory backwards, but would a quick-fix be to just use the 3Dnow! prefetch instructions? Since these functions are globally exported, it might be worth it to write a quick test that calls the various _transform_normalize_normals functions to make sure that they all produces the same (or close enough) results. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration File Format Example
D. Hageman wrote: On Tue, 28 Jan 2003, Ian Romanick wrote: How do we want to handle the case where a user changes video cards? Some of the parameters are likely to be generic, but a lot will be very device specific. The issue here is that the set of available parameters will change. A releated issue is when the set of availble parameters change from one driver release to another. So, do we want to key options on hardware device, screen (in the X sense), or something else? The answer to this question will likely dictate how we handle multi-head. The more I play around with this in my head the more I lean towards keying to the device. The screen is a very generic term and it is supposed to be that way for the abstraction of X11 to work. It however does not lend itself to specific driver tweaking ... hence why the option parameters go in the Device section. What would we use as the device key, then? Would this match the device's name from the XF86Config file? There are a few odd corner cases that we need to make sure and get right the first time. User's changing cards and multi-head cards (even though we don't support direct rendering on them now) are the two big ones that I can think of. I think we're going to end up with two keys. One is the application (with a default available) and the other will be something to identify the device and/or screen. How do we want to specify them? By this I mean, do we want to select the application then the screen (like you suggest above) or the other way around? In all honesty I threw out my example to start some discussion. Not too much thought had went into it. I saw a couple let us see a schema posts so I thought I would see what happen if I posted one. I think the real way it should be done is device, then application. device id=0 application name=... ... /application application name=... ... /application /device I'm coming to conclusion more the more I think about it. I really can't come up with a good, real-world case to argue for application-then-device. Most of the cases where you'd want the application at the top level could be handled by putting a 'device id=*' around it. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration File Format Example
device id=0 application name=... ... /application application name=... ... /application /device I'm coming to conclusion more the more I think about it. I really can't come up with a good, real-world case to argue for application-then-device. Most of the cases where you'd want the application at the top level could be handled by putting a 'device id=*' around it. I would think that the common case would be: most general settings device 0 settings device 1 settings application x settings settings specific to device 0 on application x etc I don't think settings specific to device 0 on application x would ever actually come up, but the structure suggested would allow it. -- Russ Dill [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
Hi Just one little XFree-related pro-XML story. Not from DRI, from XKB life. You know, XKB configuration is generally held in /usr/X11R6/lib/xkb directory and several subdirectories. All this would be fine if the format of the files in these directories would be something good, structured, readable (by human and machine). But historically it never was. So some people (mainly me and Ivan Pascal) had a lot of headache trying to make some central configuration repository for XFree 4.3. Do you know which format we choosen? Right, XML. Because developers can edit it. Because GUI configuration tool (I am the author of the one for GNOME) can parse it. Because the structure is rather complex (though we definitely could FIT it into some standard name=value format). Finally, because we could easily provide i18n using intltool. Well, I have to admit there were several files which initially were intended to keep the registry of the configuration. But they were extremely poorly structured. And the format required some special parsing (implemented deep inside XFree). So I found no (GT)UI tools which would actually use them. With new XML format people finally got a hope (and gnomers actually got the implementation) for decent GUI configuration tools for XKB. I am not DRI developer. But if you care about users (using GUI tools), developers (easily prototyping these tools using perl/python/etc) - please go XML. Cheers, -- Sergey signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] Configuration file format survey
On Tue, Jan 28, 2003 at 03:51:26PM -0500, Jamie Guinan wrote: If the XML can be kept relativly simple to read and edit then fine but the end user should never have to use a config tool if they don't want to. So please keep it as simple as possle. In my opinion the readability of the config file should be a much bigger concern then having a multitued of configuration programs out there. Even the best config program will have it's limits and I for one don't want to be constrained by them. I can see 3 ways this can work out: 1) The new format is tolerably readable XML, and power users learn to see around/through/between the all 's. 2) An XF86Config-ish format is used, with an XML layer on top that some tool boils down to the XF86Config-ish format (I think the Red Hat printer config tools do something like this). DRI won't be any the wiser. 3) The inverse of [2], where the DRI format is XML, and a tool to convert from XF86Config-ish syntax to XML is created, just to make the power users happy. Why did you leave out 4) an XF86Config-ish format is used, we use the libx86config library, (or whatever the name of the lib is :-) and no XML is involved at all ? That is the best fit to meeting the requirements of the initial paragraph. If you think about it, what *really* matters is the bytes inside DRI. The XF86Config syntax is just sugar to make it easy to get the right values in there for people handy a text editor. An XML syntax is just different kind of sugar which makes it *trivial* to write tools for people handy with a mouse. Not to mention facilitating features like preventing invalid configurations from being saved, and other stuff that comes essentially free with XML. The writing tools bit is handled already, given the existence of the xf86 config library. So XML makes it easier to write tools is an invalid argument. Not to mention that people handy with a mouse, and not code, should not be writing tools for this stuff in the first place! And the preventing invalid configurations stuff is not free. As I understand it, you have to write lengthy XML stuff to set rules, etc, etc. The argument was previously made, of Well, we'll keep the XML syntax simple, so the bloated XML argument wont apply. I would think writing all the XML rules, and then having all the current developers have to *learn* all the XML syntax, so they can figure out what the heck is wrong with what they want to add to the config file, lands back in the bloated XML side. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, 2003-01-28 at 12:00, Sven Luther wrote: Just my experience for when file-roller (part of gnome) upgrades its configuration, it takes minutes on a Atlhon 1700+, but i admit, the configuration file-roller manages are, if not big, at least there are many of them. Thats something else. Arguments about XML load/parse time are about the micro/milliseconds involved. XSLT formatting is another matter but XSLT is XML-something translation and not what you would want to do for a configuration except maybe with some kind of back end tool generating configurations for hundreds of desktops where you can take XSLT rules and XML card/monitor descriptions and turn out config files to order. Thats a whole layer above anything XFree cares about --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-devel][patch] 3DNow normalization bug
Felix Kühling wrote: It seems I like answering my own mails ;-) I fixed this problem but it is probably not optimal. A simple patch is attached. It seems that this error was introduced by an atempt to optimize prefetching. The next normal was read into MM0 and MM1 at the end of the G3TN_norm loop. So in the first cycle MM0 and MM1 were undefined. Furthermore it read one extra normal at the end of the array which was never processed. The patch moves the load operations back to the front of the loop as in the G3TN_norm_w_lengths case. Felix On Tue, 28 Jan 2003 18:02:57 +0100 Felix Kühling [EMAIL PROTECTED] wrote: Hi, I recently discovered some problem with normal vectors in the gflux hack on my Duron, Radeon 7500 with and without TCL, even with RADEON_NO_RAST=1. LIBGL_ALWAYS_INDIRECT works correctly, though. A workaround is MESA_NO_3DNOW=1. Another way is to normalize the normals in gflux and change glEnable(GL_NORMALIZE) to glEnable(GL_RESCALE_NORMAL). By playing around with the -squares option of gflux I could determine that every 216th normal vector is not normalized correctly. The normalization function used is _mesa_3dnow_transform_normalize_normals in xc/extras/Mesa/src/X86/3dnow_normal.S. I don't understand where the magical 216 comes from. My guess is that _mesa_3dnow_transform_normalize_normals always gets 216 normals to transform and forgets one of them (first one or last one, can't tell). I hope this info helps someone to spot the error quickly. I've applied the patch to the Mesa and DRI trees. Thanks! -Brian --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
Philip Brown wrote: If you think about it, what *really* matters is the bytes inside DRI. The XF86Config syntax is just sugar to make it easy to get the right values in there for people handy a text editor. An XML syntax is just different kind of sugar which makes it *trivial* to write tools for people handy with a mouse. Not to mention facilitating features like preventing invalid configurations from being saved, and other stuff that comes essentially free with XML. The writing tools bit is handled already, given the existence of the xf86 config library. So XML makes it easier to write tools is an invalid argument. Not to mention that people handy with a mouse, and not code, should not be writing tools for this stuff in the first place! I believe that the people handy with a mouse comment was referring to who the tools were for, not who would write them. That aside, I fully plan to prototype out an initial version of the GUI tool in Python. Will I be able to use libxf86cfg? I have yet to see an answer either way. And the preventing invalid configurations stuff is not free. As I understand it, you have to write lengthy XML stuff to set rules, etc, etc. The argument was previously made, of Well, we'll keep the XML syntax simple, so the bloated XML argument wont apply. I would think writing all the XML rules, and then having all the current developers have to *learn* all the XML syntax, so they can figure out what the heck is wrong with what they want to add to the config file, lands back in the bloated XML side. The rules that are written for XML formats basically amount to little grammars. Learning the syntax of the grammar is pretty easy to pick up. It's a lot simpler than learning yacc, that's for sure! :) If it take you more than 20 or 30 minutes to pick it up, then you should quit ordering documentation in Egyptian hieroglyphs! :) The thing that makes most XML so unpleasant is the same thing that makes most HTML and most BASIC unpleasnt: it's written by people who aren't engineers. The thing that makes XML worse is that it gives people an extra degree of freedom. This amounts to giving people more rope with which to shoot themselves in the foot. Whatever format is chosen, I think having some sort of rule-checker is a good idea. If we want to encourage 3rd parties to generate tools, then we really want to have a reference point to proove that everyone is working correctly. It's the same reason that most programming language standards bodies produce a reference parser as part of their work. If a user writes code that they belive should compile, but doesn't, they (and the compiler vendor) can refer to the reference parser. Having an authoritative source makes it a LOT easier to settle correctness arguments. It is doable no matter what format we choose. One of the advantages of XML is that it will be easier to do, and it will be easier to maintain over time. Is that a significant advantage? Perhaps. Is that a big enough advantage to push us over to XML-land? Dunno. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
If you think about it, what *really* matters is the bytes inside DRI. The XF86Config syntax is just sugar to make it easy to get the right values in there for people handy a text editor. An XML syntax is just different kind of sugar which makes it *trivial* to write tools for people handy with a mouse. Not to mention facilitating features like preventing invalid configurations from being saved, and other stuff that comes essentially free with XML. The writing tools bit is handled already, given the existence of the xf86 config library. So XML makes it easier to write tools is an invalid argument. Not to mention that people handy with a mouse, and not code, should not be writing tools for this stuff in the first place! set lurk=off set devils_advocate=on The operating system bit is handled already, given the existence of Microsoft Windows. So Linux makes it easier to write software is an invalid argument. Not to mention that people handy with a CLI, and not GUIs, should be be writing visual tools in the first place! Yes, XML can lead to feature creep in the config syntax, and its die-hard advocates often go overboard, but so what? If it allows more people to have greater control over their system, what's wrong with that? And if they can do it with less effort, great. I am/was a Slackware/Debian user, but I'm lazy; there's nothing wrong with a mouse. And the preventing invalid configurations stuff is not free. As I understand it, you have to write lengthy XML stuff to set rules, etc, etc. AFAIK, you only have to write those rules it if you want your XML document to be fully validated when your library initially parses the document. And preventing invalid configurations is not free with any library, XML or not. The argument was previously made, of Well, we'll keep the XML syntax simple, so the bloated XML argument wont apply. I would think writing all the XML rules, and then having all the current developers have to *learn* all the XML syntax, so they can figure out what the heck is wrong with what they want to add to the config file, lands back in the bloated XML side. again, devil's advocate: I would think writing all the XFree86 rules, and then having all the current devlopers have to *learn* all the XFree86 syntax, so they can figure out what the heck is wrong with what they want to add to the config file, lands back in the bloated XFree86 side. --end A simple XML config file with a reasonable layout allows for all sorts of parsers and config tools in all sorts of languages in a very cross-platform manner. Someone might even write a program to transform the XML format into the current XFree86 format, which you can then edit/transform with libxf86whatever, and then transform back into XML. -jdm, (who will now head back into his cave in his asbestos suit) Department of Computer Science, Duke University, Durham, NC 27708-0129 Email: [EMAIL PROTECTED] Web:http://www.cs.duke.edu/~justin/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3DNow normalization bug
On Tue, 28 Jan 2003 13:10:41 -0800 Ian Romanick [EMAIL PROTECTED] wrote: Felix Kühling wrote: It seems I like answering my own mails ;-) I fixed this problem but it is probably not optimal. A simple patch is attached. It seems that this error was introduced by an atempt to optimize prefetching. The next normal was read into MM0 and MM1 at the end of the G3TN_norm loop. So in the first cycle MM0 and MM1 were undefined. Furthermore it read one extra normal at the end of the array which was never processed. The patch moves the load operations back to the front of the loop as in the G3TN_norm_w_lengths case. Good catch. It looks like this went into the Mesa tree back in October of 2001...over a year ago! It looks like Andres Lewycky gave Brian some bad patches. :( Yeah, but until November 2002 (DRI trunk) there was a comment in 3dnow.c that the 3dnow-normal code is broken and it was not used. I realize that AMD recommends reading memory backwards, but would a quick-fix be to just use the 3Dnow! prefetch instructions? The prefetch instructions used are and must be 3DNow instructions. On Intel Prefetch was introduced with the SSE extension on the PentiumIII. They're not available on older Athlons and K6's. Anyway, all that prefetching looks odd to me. In the first transform loop in _mesa_3dnow_transform_normalize_normals memory is prefetched which is never read but only written. This is obviously useless. Then in the normalize loop the memory which was written before is prefetched again. I think this is not necessary. The array is small enough to be still in the cache. I'll see if I can clean this up a bit. On the mesa-4-0-4 branch this code is disabled anyway, so there is not really a hurry to apply my stupid little patch. About this reading backward thing, where is that documented. I have an AMD Athlon optimization guide from February 2002 which doesn't mention it. Since these functions are globally exported, it might be worth it to write a quick test that calls the various _transform_normalize_normals functions to make sure that they all produces the same (or close enough) results. And: _transform_normalize_normals_no_rot _transform_rescale_normals_no_rot _transform_rescale_normals _transform_normals_no_rot _transform_normals _normalize_normals _rescale_normals These should be tested too, while we're at it. 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: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, Jan 28, 2003 at 09:56:09PM +, Sergey V. Oudaltsov wrote: Hi Just one little XFree-related pro-XML story. Not from DRI, from XKB life. You know, XKB configuration is generally held in /usr/X11R6/lib/xkb directory and several subdirectories. All this would be fine if the format of the files in these directories would be something good, structured, readable (by human and machine). But historically it never was. .[...] Good story. But right there, you point out the main difference between your example, and the XFree86 config format. BTW: I hope you folks will fix it so that it is finally possible to have /usr/X11R6 be read-only The only culprit stopping this, as far as I know, is the xkb stuff. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, 28 Jan 2003, Philip Brown wrote: If you think about it, what *really* matters is the bytes inside DRI. The XF86Config syntax is just sugar to make it easy to get the right values in there for people handy a text editor. An XML syntax is just different kind of sugar which makes it *trivial* to write tools for people handy with a mouse. Not to mention facilitating features like preventing invalid configurations from being saved, and other stuff that comes essentially free with XML. The writing tools bit is handled already, given the existence of the xf86 config library. So XML makes it easier to write tools is an invalid argument. In general, it *does* make it easier, because you don't have to learn a new library/API every time you want to write a configurator. Not to mention that people handy with a mouse, and not code, should not be writing tools for this stuff in the first place! By people handy with a mouse I meant the end-users, not the coders. :) And the preventing invalid configurations stuff is not free. As I understand it, you have to write lengthy XML stuff to set rules, etc, etc. Good point there, you do have to backfill the rules, but at least the technique is standardized if you want to do it. I was thinking/worrying more about the hand-editing model, which the original poster was trying to make sure didn't go away. Anyway, it looks like Ian Romanick and others are already tossing bits of XML back and forth... -Jamie --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3DNow normalization bug
Felix Kühling wrote: On Tue, 28 Jan 2003 13:10:41 -0800 Ian Romanick [EMAIL PROTECTED] wrote: Felix Kühling wrote: The patch moves the load operations back to the front of the loop as in the G3TN_norm_w_lengths case. Good catch. It looks like this went into the Mesa tree back in October of 2001...over a year ago! It looks like Andres Lewycky gave Brian some bad patches. :( Yeah, but until November 2002 (DRI trunk) there was a comment in 3dnow.c that the 3dnow-normal code is broken and it was not used. D'oh! I realize that AMD recommends reading memory backwards, but would a quick-fix be to just use the 3Dnow! prefetch instructions? The prefetch instructions used are and must be 3DNow instructions. On Intel Prefetch was introduced with the SSE extension on the PentiumIII. They're not available on older Athlons and K6's. Anyway, all that prefetching looks odd to me. In the first transform loop in _mesa_3dnow_transform_normalize_normals memory is prefetched which is never read but only written. This is obviously useless. Then in the normalize loop the memory which was written before is prefetched again. I think this is not necessary. The array is small enough to be still in the cache. I believe that prefetchw tells the processor to warm up the cache line because it's going to be written soon. I think the prefetching in the first loop is probably correct. The prefetchw of (%eax) might need to be before the add. I'd have to benchmark it. I'm not sure if I have a 3dnow capable box around anymore. If I do, it will be an old K6-III. :) I'll see if I can clean this up a bit. On the mesa-4-0-4 branch this code is disabled anyway, so there is not really a hurry to apply my stupid little patch. About this reading backward thing, where is that documented. I have an AMD Athlon optimization guide from February 2002 which doesn't mention it. I've seen a reference posted to dri-devel a couple times. Here's a couple references the Dieter posted on 09-Jan-2003: http://marc.theaimsgroup.com/?l=linux-kernelm=103548024914815w=2 http://208.15.46.63/events/gdc2002.htm I'm not sure if this applies to the K6 family or just to Athlons. I suspect it may only apply to Athlons, but we may have to test it. Since these functions are globally exported, it might be worth it to write a quick test that calls the various _transform_normalize_normals functions to make sure that they all produces the same (or close enough) results. And: _transform_normalize_normals_no_rot _transform_rescale_normals_no_rot _transform_rescale_normals _transform_normals_no_rot _transform_normals _normalize_normals _rescale_normals These should be tested too, while we're at it. Agreed. Brian: If such tests do get written, where should they live in the tree? --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, 28 Jan 2003, Ian Romanick wrote: The thing that makes XML worse is that it gives people an extra degree of freedom. This amounts to giving people more rope with which to shoot themselves in the foot. LOL. /me holds rope /me looks at foot /me scratches head -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
Good story. But right there, you point out the main difference between your example, and the XFree86 config format. Keep in mind - it is not XF68Config, it is just configuration repository. The tree of available modeuls/layouts/variants/options. Not actually chosen one (which is still in XF86Config). So it is just one very large (especially in future - with all translations) read-only XML file. The only culprit stopping this, as far as I know, is the xkb stuff. Actually I did not hear about it. What is the problem here? I'm afraid it is xkbcomp which spoils things - though I can be wrong. Well, we are going offtopic. Shall we continue about XKB here? Cheers, -- Sergey signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] Configuration file format survey
On Tue, 28 Jan 2003, Ian Romanick wrote: As far as caching goes, I guess I don't understand. Does that mean that if someone changes settings while an OpenGL application is running, the changes will take effect in the running app? Will it only take effect if the app creates a new rendering context? I had always just assumed that we would take a snap-shot of the settings when the app created its first context. (messy post, I know -- sorry) http://perkypants.org/projects/gnome-2.0-interviews/gconf/ http://developer.gnome.org/feature/archive/gconf/gconf.html http://developer.gnome.org/doc/API/gconf/ http://developer.gnome.org/feature/archive/gconf/gconf.html http://freshmeat.net/projects/gconf/?topic_id=809 The author, Havoc Pennington, presented a journal article on it at Ottawa Linux Symposium 2002. It begins on page 414 in the proceedings: http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz gconf works outside of Gnome. The current back-end uses XML files. It supports defaults and locked down configuration items at the sysadmin's discretion -- the remaining stuff can be changed by an ordinary user. There is a GUI editor for changing the configuration settings without having to much with XML. Programs can watch a configuration entry and react instantly if it is modified. This is just to inform people that instantaneous reactions to configuration changes is possible... I'm not trying to push for an overengineered design - in fact it gives me the willies when people here say XML is cool. XML is typically not used in a way that I would call simple. -Peter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3DNow normalization bug
On Tue, 28 Jan 2003, Felix Kühling wrote: prefetching looks odd to me. In the first transform loop in _mesa_3dnow_transform_normalize_normals memory is prefetched which is never read but only written. This is obviously useless. Then in the No -- at least not *obviously* useless. Whether it *actually* is useless or not depends on the write allocate policy of the cache. On some caches it is a good idea to prefetch something you are going to write to because if it weren't in the case the write would have to trigger a read anyway so you might as well do that early on. Can't remember the K6 details, though, so it might be unnecessary. -Peter ``Average programmers should be rounded up and placed in internment camps to keep them away from keyboards.'' --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3DNow normalization bug
Am Mittwoch, 29. Januar 2003 00:05 schrieb Ian Romanick: Felix Kühling wrote: On Tue, 28 Jan 2003 13:10:41 -0800 Ian Romanick [EMAIL PROTECTED] wrote: Felix Kühling wrote: The patch moves the load operations back to the front of the loop as in the G3TN_norm_w_lengths case. Good catch. It looks like this went into the Mesa tree back in October of 2001...over a year ago! It looks like Andres Lewycky gave Brian some bad patches. :( Yeah, but until November 2002 (DRI trunk) there was a comment in 3dnow.c that the 3dnow-normal code is broken and it was not used. D'oh! ;-) I realize that AMD recommends reading memory backwards, but would a quick-fix be to just use the 3Dnow! prefetch instructions? Block Prefetch, page 18, see below. The prefetch instructions used are and must be 3DNow instructions. On Intel Prefetch was introduced with the SSE extension on the PentiumIII. They're not available on older Athlons and K6's. It all depends on steppings... Some output from MPlayer, best optimized OSS app I know: CPU: Advanced Micro Devices Athlon 4 PM Palomino/Athlon MP Multiprocessor/Athlon XP eXtreme Performance (Family: 6, Stepping: 2) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0 Kompiliert für x86 CPU mit folgenden Erweiterungen: MMX MMX2 3DNow 3DNowEx SSE Anyway, all that prefetching looks odd to me. In the first transform loop in _mesa_3dnow_transform_normalize_normals memory is prefetched which is never read but only written. This is obviously useless. Then in the normalize loop the memory which was written before is prefetched again. I think this is not necessary. The array is small enough to be still in the cache. I believe that prefetchw tells the processor to warm up the cache line because it's going to be written soon. I think the prefetching in the first loop is probably correct. The prefetchw of (%eax) might need to be before the add. I'd have to benchmark it. I'm not sure if I have a 3dnow capable box around anymore. If I do, it will be an old K6-III. :) I'll see if I can clean this up a bit. On the mesa-4-0-4 branch this code is disabled anyway, so there is not really a hurry to apply my stupid little patch. About this reading backward thing, where is that documented. I have an AMD Athlon optimization guide from February 2002 which doesn't mention it. I've seen a reference posted to dri-devel a couple times. All from me;-) Here's a couple references the Dieter posted on 09-Jan-2003: http://marc.theaimsgroup.com/?l=linux-kernelm=103548024914815w=2 http://208.15.46.63/events/gdc2002.htm And here are some numbers: nuetzel/Entwicklung ./athlon-DN 1600.081 MHz clear_page by 'normal_clear_page'took 12757 cycles (489.9 MB/s) clear_page by 'slow_zero_page' took 12478 cycles (500.9 MB/s) clear_page by 'fast_clear_page' took 9684 cycles (645.4 MB/s) clear_page by 'faster_clear_page'took 4257 cycles (1468.0 MB/s) copy_page by 'normal_copy_page' took 9063 cycles (689.6 MB/s) copy_page by 'slow_copy_page'took 9051 cycles (690.5 MB/s) copy_page by 'fast_copy_page'took 8125 cycles (769.3 MB/s) copy_page by 'faster_copy' took 5468 cycles (1143.0 MB/s) copy_page by 'even_faster' took 5538 cycles (1128.5 MB/s) copy_page by 'no_prefetch' took 4462 cycles (1400.7 MB/s) I'm not sure if this applies to the K6 family or just to Athlons. I suspect it may only apply to Athlons, but we may have to test it. According to AMD (see the gdc2002.htm Presentation) it applies to _all_ modern x86 CPU's out there. Since these functions are globally exported, it might be worth it to write a quick test that calls the various _transform_normalize_normals functions to make sure that they all produces the same (or close enough) results. And: _transform_normalize_normals_no_rot _transform_rescale_normals_no_rot _transform_rescale_normals _transform_normals_no_rot _transform_normals _normalize_normals _rescale_normals These should be tested too, while we're at it. Yes. -Dieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 blend
On Wed, 29 Jan 2003, Arkadi Shishlov wrote: Hi. I'm working on QuakeForge engine, and some things related to transparency (player damage blood) and 'dynamic lighting' (grenade explosion) are very slow. Quake3 runs faster in mean time. Quake3 has some hacks built in to work around the mach64's limitations. I think it looks for Rage Pro in the Renderer string to enable them. I want to investigate problem further on Quake side, but I want to be sure I understood mach64 limitation correctly from what I've read at http://www.retinalburn.net/linux/dri_status.html - glEnable(GL_FOG) and glEnable(GL_BLEND) cannot be enabled at the same time. Correct. Enabling fog when blending is enabled will have no effect (there's no software fallback). Enabling blending when fog is enabled will disable fog. So fog should not cause any slowdowns as a result of falling back to software. - 'Texture environment modes: GL_BLEND is done in software..' - mean glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated. GL_MODULATE with GL_LUMINANCE_ALPHA is software. Right. GL_BLEND texture environment is not possible on mach64. Also, the card can't modulate alpha values when texturing, so texture environments where Final A = A fragment * A texture aren't fully compliant, e.g. GL_MODULATE with GL_RGBA textures. The case of GL_MODULATE/GL_RGBA is not done as a fallback since it's very common. Hardware accelerated: environment texture base format GL_DECAL any valid format - GL_RGB, GL_RGBA GL_REPLACEGL_LUMINANCE, GL_RGB, GL_RGBA GL_MODULATE GL_LUMINANCE, GL_RGB, GL_RGBA(not fully compliant) Software fallbacks: -- environment texture base format GL_BLEND any GL_REPLACEGL_ALPHA, GL_LUMINANCE_ALPHA, GL_INTENSITY GL_MODULATE GL_ALPHA, GL_LUMINANCE_ALPHA, GL_INTENSITY And of course anything more recent than these core environments isn't supported, e.g ADD, COMBINE, etc. cvs co -r mach64-0-0-5-branch xc/xc/lib/GL/mesa/src/drv/mach64 are the right files to investigate for additional limitations? Yes. Look at mach64UpdateTextureEnv in mach64_texstate.c for the above and mach64_state.c for fog, blending and other state. BTW, when particular operation is implemented in software but require some on-screen content, driver copy already rendered chunk from framebuffer, pass it to Mesa, then copy back? To be honest, I don't know the gory details of the Mesa software rasterizer yet, but any primitives needing a texture application that can't be done in hardware would be completely software rendered and written to the framebuffer, I think. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Bug in compilation?
I am attempting to recompile DRI on my newly configured Mandrake 9.0 system.. but it cuts out with an error on line 14282 or so of my log file.. with an error in a gcc line.. it's the only place it tries to use the Xpm library "-lXpm" and for some reason, it says it can't find it. Any ideas? Thanks.. -- John S. Chalice a.k.a. crysaliq
Re: [Dri-devel] Configuration File Format Example
On Tue, 28 Jan 2003, Ian Romanick wrote: How do we want to handle the case where a user changes video cards? Some of the parameters are likely to be generic, but a lot will be very device specific. The issue here is that the set of available parameters will change. A releated issue is when the set of availble parameters change from one driver release to another. So, do we want to key options on hardware device, screen (in the X sense), or something else? The answer to this question will likely dictate how we handle multi-head. The more I play around with this in my head the more I lean towards keying to the device. The screen is a very generic term and it is supposed to be that way for the abstraction of X11 to work. It however does not lend itself to specific driver tweaking ... hence why the option parameters go in the Device section. I think we're going to end up with two keys. One is the application (with a default available) and the other will be something to identify the device and/or screen. How do we want to specify them? By this I mean, do we want to select the application then the screen (like you suggest above) or the other way around? In all honesty I threw out my example to start some discussion. Not too much thought had went into it. I saw a couple let us see a schema posts so I thought I would see what happen if I posted one. I think the real way it should be done is device, then application. device id=0 application name=... ... /application application name=... ... /application /device One nice side-effect of this is that it becomes very easy to move, delete, or import profile sections. If you want to import a set of application preferences for a specific screen (perhaps from a file that shipped with the application), you just insert its tree in the correct place. If you un-install an application and want to remove its profile, you just delete its subtree. This works with the nesting in either order, as far as I can tell. I'm pretty sure both expat and libxml have the ability to do this easilly. Absolutely. Then there's the issue of how to specify the preferences. How does the driver communicate the set of available options to the various utilities (GUI or otherwise)? This issue is a bit more complicated than it seems. There needs to be a way to specify dependencies (i.e., this option is only available is some other option is set / not set). If we settle on a small set of option types, things are simplified a bit. I'm thinking something similar to the set of available form input types HTML. I think boolean, enum, float, and perhaps string should cover everything we would need. A multi-select enum might also be needed. Sounds reasonable. In the config file, I think the options could be specified as simple name / value pairs. Something like 'option name=tcl_enabled value=true/'. For multiselect enums, the value would be a comma separated list of the selected options. I don't fully understand the nesting in your example. Ah, let me toss out what I was thinking by using the debug node. debug type=verbose Essentially set all debuging to be verbose. texture enable=yes/ Enable texture debugging. ioctl enable=yes/ Disable ioctl debuging /debug It can just as easily been done with option name= value=/ as well. I went with the name of the option in the tag to be more explicit in each scenerio. As an aside, I believe that all of this so far would work with an XF86Config style file format as well. Sometimes you can fit a square peg in a round hole ... I agree. Another thing to consider is internationalization. We should make it possible to specify different translations of text with in the driver's list of options. A utility could read the list of options from the driver and present the user's prefered langauge, if available. As we shift to a Joe User mindset, internationalization will become more and more important. Good call! -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration File Format Example
I think a better approach would be to add a level of indirection between the app and the card - reason to follow this example: device card=radeon setting name=games tcl=enabled/ dramclock=100MHZ/ ... /setting setting name=detailwork tcl=enabled/ dramclock=70MHZ/ ... /setting setting name=debug debug=enabled/ logfile=/tmp/gl_log /setting /device device card=nVidia setting name=games ... /device application name=RtCW program name=rtcw.x86/ setting name=games/ /application application name=foobar_game program name=~/foobar/ setting name=games/ setting name=debug/ device name=tdfx assertion_code=on/ /device /application The advantages this has are: 1) Less redundancy - many programs will likely share settings, so let them be in 1 place. 2) Driver abstraction - you can say that by default a driver's setup tool will create a section games, a section debug, and so on. Then the programs can quickly query that setting. In fact, it might even be possible to create an API so that a program could query what settings exist for a card and present that to the user. 3) Inheritance - a program can use multiple setting names, with the last item winning for any common parameters. 4) If needed, a program can tweak card parmeters directly. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration File Format Example
On Tue, 28 Jan 2003, Ian Romanick wrote: D. Hageman wrote: On Tue, 28 Jan 2003, Ian Romanick wrote: How do we want to handle the case where a user changes video cards? Some of the parameters are likely to be generic, but a lot will be very device specific. The issue here is that the set of available parameters will change. A releated issue is when the set of availble parameters change from one driver release to another. So, do we want to key options on hardware device, screen (in the X sense), or something else? The answer to this question will likely dictate how we handle multi-head. The more I play around with this in my head the more I lean towards keying to the device. The screen is a very generic term and it is supposed to be that way for the abstraction of X11 to work. It however does not lend itself to specific driver tweaking ... hence why the option parameters go in the Device section. What would we use as the device key, then? Would this match the device's name from the XF86Config file? It would have to as no other keying would be reasonable or at least none that I can think of at the momment. There are a few odd corner cases that we need to make sure and get right the first time. User's changing cards and multi-head cards (even though we don't support direct rendering on them now) are the two big ones that I can think of. The way I see some of this is that we just don't have the capability of being super smart about some of this. If a person changes a card then it would indeed invalidate the DRI configuration if it isn't the same variety of card. I don't think that in and of itself is an unreasonable expection. It would be nice to be able to provide some feedback to the user and claim that they have done something screwy. Part of this endeavor should standardize at least the basic configuration options so at least the configuration should be ... reasonably unusable if a card was switched. On a multi-head box the device names should be different so we should be convered there, right? I'm coming to conclusion more the more I think about it. I really can't come up with a good, real-world case to argue for application-then-device. Most of the cases where you'd want the application at the top level could be handled by putting a 'device id=*' around it. Sounds good - I think I am right there along beside on that one. Let me mention as a footnote that I will be out of town starting tomorrow evening. I have to make a quick trip over the big blue pond to see some friends so after tonight I won't be taking part in this discussion until early next week. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
