On Thu, Oct 02, 2003 at 09:13:11AM -0700, Sottek, Matthew J wrote: >Let me start by saying this is at least 5 years overdue. Glad to see David >addressing this problem.
These things only happen when someone cares enough to provide the resources necessary to make them happen. >I would like to suggest that a more aggressive approach be used that would >involve (or allow) driver changes. Using external tools to figure out >which graphics driver and input devices to use sounds like a fine idea; >however, it seems that the driver should be responsible for determining a >set of default settings. Yes, and the drivers already do that, a fact that any form of automatic configuration relies on heavily. In an ideal world that would be enough. But experience with XFree86 drivers has shown that the situation isn't that ideal in reality. The 'XFree86 -configure' method is an attempt at the "let the drivers figure it all out" method, but it hasn't proven as robust as might have been hoped. The approach I've taken amounts to an acceptance of the fact that drivers are of varying quality, something which is completely understandable given that they are usually developed with limited resources. >The driver is in a far better position to detect the monitor. Most drivers >on other platforms have built in EDID parsing and methods to detect >displays that may not even support such standards (Especially common in >embedded market) Additionally the driver knows the availability of >mult-display features from flat panel or TV encoders which cannot be >determined without extensive hardware probing. This probing is already >needed for the driver's operation and could be leveraged for a >self-configuration purpose. Most drivers already do monitor detection. I don't think we currently make maximum use of the EDID data, but we do use it to figure out the basic monitor parameters, and that is exactly what is used for the monitor data in the no-XF86Config mode of operation (with a conservative fallback). >A would suggest that a driver should initialize by the X server asking >(rather than telling) the driver how many screens and what modes are >supported. The driver can obtain this information from the XF86Config file >when available or via it's own detection. The data is then written back >to the XF86Config file at runtime. For most of what you're describing, that's pretty much how it already works. None of this auto-probed data gets written back to a config file though. I'm not sure what puprpose that would serve, compared with storing the user's preferences. >A runtime configuration (via randr, and additional protocols) would also >allow for changing arbitrary display features at runtime and have them >written back to the XF86Config file. Or some other mechanism for storing preferences, yes. >Autoconfiguration is one overdue item, but runtime configuration is every >bit a "required 5 years ago" feature that should be addressed in parallel >since they have overlapping needs. These things don't just happen because they are "required 5 years ago." Someone needs to feel strongly enough about it to provide the resources to make them happen. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
