I agree that better defaults are required. Most problems I see people run into are either driver limitations/bugs, poorly chosen defaults, or the inability (often avoidable but sometimes not) of a driver to automatically determine some information it needs. I think that putting time into fixing these things would help more people than changing the config file format.
There'll always be some need for a stored configuration, but the goal should be to limit it to user preferences and minimise the amount of essential information it needs to provide. Regarding machine read/write ability, we do have and use a library to read/write the config file. Configuration tools can use it (xf86cfg does, for example). While the configuration format has the disadvantage of not being an accepted standard, it is machine readable/writable today. While I agree that there are legitimate arguments for using XML, I don't think the ability to machine read/write the file is a big one because we can already to that now. If there are problems with our existing library that are discouraging people from writing configuration editing tools, please contact me with details. On Mon, Feb 18, 2002 at 07:45:17AM -0800, Jim Gettys wrote: >It is certainly reasonable to want to see a proposal for an >XML DTD for an XFree86 config file. One of the reasons is that I'm particularly interested to see what the proposed structure would be and how it would look at the data structure level through which the X server and config tools would see it. >The view of reality I see is that, for better or worse, XML is something >familiar to an increasingly large fraction of the user base (particularly >the hacker types who might edit such a file by hand), and the current >XFree86 config file syntax is not (nor is it friendly for building tools >to generate them). So if we take as a given wanting a config file syntax >that is both human and machine read/writeable easily, one can do alot worse >than XML (like where we are right now). > >I've personally been burned by the config file's syntax in the last month >or two, as I reinstalled several of my systems, one of which ended up >broken after insall. And I've been burned by the quoting problem >used as the other example on several occasions. If we were to make our existing config file line-oriented, the quoting issue could be largely eliminated. It's even possible that we could modify the parser to be more flexible in this regard without introducing config file format incompatibilities. I think that the code should work harder than the human user, and one of my problems with XML is that it makes machine reading/writing easier at the expense of editing and reading ease for the human user. >So my opinion goes as follows: > > 1) We need to make the need for the XFree86 config file as small as >possible. We need to work hard at getting defaults right, so they don't >have to be edited in the first place, nor things specified, unless you >are doing something particularly unusual. > >I give as a concrete first hand example: On my Matrox G450, > o the default depth is 8! So for it to be even semi-sane, > you have to go touch what is generated. Or use the '-depth' command line option. We could change the server-wide default. What would be a good/safe default? Probably 16? If there are any drivers that can't do 16, they'd have to request a different default. > o Furthermore, to get TT fonts, you have to go edit the file > to add a module. I still don't understand why there are two > choices here for modules, other than some handwaving Keith gave > me about eastern fonts (we could make the default locale dependent > if necessary). It looks like we've been seeing server crash problems with the x-tt module recently too. I'd really like too see a single module for TT fonts, and wonder if after all this time we can't agree on a mode of operation for that module that will satisfy both camps. > o And the mouse does not default to the most common > forms of mice currently found, (nor autodetect the protocol) etc.... That's a driver limitation (an unnecessary one IMHO). Even so, the defaults chosen with 'XFree86 -configure' do correctly handle the vast majority of cases. > o And the server defaulted to trying to use the absolutely highest > supported resolution of my monitor (2100x1600), which, until we use > scalable fonts everywhere, is probably the wrong answer, much less > the fact the second DAC on the G450 can't go that fast, and will therefore > be wrong for xinerama. My personal preference is to at least pick a size that the monitor can do with a good refresh rate. In cases where we know the physical size of the monitor we could choose one that gave a preferred default DPI. Unfortunately this came up as an issue too late to change for 4.2.0. I don't know that automatically factoring in a second DAC is necessarily a good idea. On the G400, for example, the second DAC is severely limited -- more so than with the G450. Of course, for every change we make to the defaults, there'll be people who don't like it. The tricky part is finding defaults that are OK for most cases. Just look at how many people complained about the change in 4.2.0 to the defaults for the "windows" keys on 104/105-key keyboards. About as many complained after the change as lobbied for it in the first place. >There are therefore at least *four* things a poor user has to do to get >it going, even ignoring xinerama (which I've put off reenabling, preferring >to get work done to messing further with my config file any futher). > >We can/should do *alot* better, folks. We're being sloppy, hiding behind >the fact the distribution vendors often clean up after us. > >The problem with the view that the distro vendors fix it, is that if you >fall off the beaten path, you are currently in XF86Config file hell... >And then we end up with tons of support questions soaking our time, >along with alot of disgruntled people who say: "this open source software >stuff is for the birds". > > Ideally, on sane hardware (which the industry is slowly moving >toward), the file can/should be empty, and the server work decently.... > >I *really* don't want to get a merit badge for editing my configuration >file manually: I deserve one right now, unfortunately. > > 2) we need to bite the bullet and adopt a config file format >that is both amenable to hand editing (which we should minimize by 1), >and by tools (which is what most end users want and need). The >current format is not: or we'd have to build tools to write the format, >and such tools would have different API's than already being used for >other system configuration metadata, which seems to be most often using XML >these days. > >I don't see the current situation as something we can/should live >with for any longer than absolutely necessary. > >Don't take this as a statement of love for XML; I'd have preferred a >s-expression syntax, but due to the history of HTML coming from SGML, >we end up with <> as the dominant way of storing such data. Sigh.... But >it can be machine read and written, validated to a significant degree, >and hand edited when necessary (and then validated). This seems like >a win to me. > > - Jim > > >-- >Jim Gettys >Cambridge Research Laboratory >Compaq Computer Corporation >[EMAIL PROTECTED] > >_______________________________________________ >Xpert mailing list >[EMAIL PROTECTED] >http://XFree86.Org/mailman/listinfo/xpert -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
