David Dawes writes: > > My point is that this is just one example of a class of problem > that is not unique to the vesa driver. Therefore solving it within > the vesa driver, while useful, does not solve the underlying problem. > Also, this class of problem is not limited to "vintage" hardware. > With the configuration work I'm doing, I'm interested in dealing > with the underlying problems. >
Right this class of problems includes all cases where drivers may support a certain chipset but not the specific combination of hardware found on a card - like DACs. In this case an automatic configuration mechanism needs to make decisions about a possible fallback path and this can only be done after PreInit() returns - like many other cases where a specific mode may not be supported and the configuration mechanism has to decide about possible tradeoffs and fallsbacks. Lee was calling for a change in paradigms in '-configure' to overcome its weaknesses. It attempts to detect any hardware it can find provided it is either generically detectable or there is a device specific probe for it. It doesn't guarantee that all hardware it detects will run. It will also fail if a certain HW cannot be probed generically or has a specific probe function. The future may however be an automatic configuration process that dynamically attempts to find the optimally possible settings. Egbert. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
