>What are you doing now? I assume this is a real product; what are you >putting into the XF86Config file now?
It was a hypothetical example. I don't know of a decent way to do it with XF86Config short of 256*3 Options. Data storage isn't really the issue. I could write a tool to write those options to the config file but unless every driver wants to receive its gamma data in that format it would be a device specific tool wouldn't it? >Cross-platform? As in Windows and X? I never mentioned that. Not cross OS. Cross hardware platform... as in device independent. >> Multi-display: There are two multi-display concepts that XFree >> understands. >Different example, same response: what do you do now? Nobody does it now... that is the point. When building a GUI that will only generate working configurations for Multi-display you would have to know a lot about the hardware and probably communicate with the driver. That means the code behind the GUI is device specific. >Wow, I've haven't seen such total FUD-mongering in a long time. Here, O >vendor: if something doesn't meet your needs, you enhance it and give it >back to the open source community. New widgets, new metadata... whatever >it takes. What are you talking about here? I think this discussion got far too bogged down into details. It is a simple point. The discussion started with the assertion that XFree should have a config tool that was driver independent instead of having driver dependent config portions. My suggestion was simply that you are likely to find configuration options that, for whatever reason, do not fit cleanly into your driver independent GUI. Based on the assumption that this will eventually happen, you should design _in_ the ability for device specific extensions rather than design it _out_. If every configuration parameter could be defined in a device independent manner, every driver in Xfree would use the same set of "Option" lines in XF86Config for the same purpose. >Web servers are supposed to be secure, too. And sendmail. But people >keep finding all those darned root exploits... Anyway, we can all audit >one program or try to audit (hmm, how many hardware vendors' products >work with X?) num programs. There are two (at least) ways to get the config data stored: 1) Have a setuid root config tool that writes out the XF86Config file. Then have a method for X to re-read the config file and reconfigure itself at runtime. I think this is the hard way, and as you said would have to be audited for every config tool. Also as I've pointed out, I think the driver would have an easier time than an external tool. It already has to "know" what is valid/safe for the hardware it is running on. or 2) Have wire protocol for altering configuration on the fly. Then have the X server write the data to the XF86Config file. If the X server does the writing, and the data can only be sent to the X server via wire protocol, then there is only one thing to audit and that is the wire protocol handling. Some parts of this exist already... XVidMode, randr... if their changes could be written back to the config file then you would already have persistent mode setting. Just add one more extension to bi-directionally shuffle opaque config parameters that came from a config tool and save them and you are pretty much done. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
