-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
While I'm not a good enough programmer to pull this off myself, I have thought quite a bit about how we currently configure things on *nix boxes. Why don't you have a description file that comes with each driver that maps the options it supports to GUI elements? That way if a card supports something unique, all you'd have to do is add an entry in the description file saying what the setting does, what values it can have, and what name to write it into XF86Config as.
I'd actually like to see everything like this, have a library that reads and writes the config file, that's licensed to be usable by anyone that wants to make a front end. And if written right, the description files would be useful for when you are hand editing and just don't remember which options work with your driver and which ones don't.
Sottek, Matthew J wrote:
|>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 | |
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/fYuOLQfa4PtTyFgRAgx/AKDI243gt4LV5bjC61vZuYSDBGpDTQCbBFhA AMAS6O2a3umFEvB3dZ+ITHc= =nyKv -----END PGP SIGNATURE-----
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
