some changes for (slightly) faster boot

Havoc Pennington hp at redhat.com
Wed Jan 5 04:07:43 UTC 2005


On Tue, 2005-01-04 at 16:08 -0500, Alan Cox wrote:
> 
> Lots of these are both system preferences and user ones with the user able
> to configure some properties or properties within a constraint set by the
> system (eg video mode).

Keep in mind that "user preference" implies a search path
(the default search path is:
 - systemwide mandatory
 - per-user
 - systemwide defaults
 - factory defaults)

Normally we want the "driver layer" (in the sense of
http://mail.gnome.org/archives/desktop-devel-list/2004-November/msg00693.html,
i.e. the layer insulating apps from the specific hardware) to define 
the capabilities and constraints, and user preferences to choose
something within those constraints.

This can be confusing to think about because files like xorg.conf
currently mix the two. But the difference is between setting up the
available resolutions (and perhaps the autoguessed-best resolution for
the current card-monitor pair); and choosing the current resolution from
among those options.

Within the "driver layer" you then want the merge from multiple data
sources (querying the hardware itself, autodetection logic,
factory/oem/local-site overrides) as we were discussing in the earlier
branch of the thread.

It's important to keep distinct these different *kinds* of configuration
or preference. They aren't the same thing. In effect, the historical
situation with the X config file was that you had to change your video
driver to only export one resolution and then the display would use that
resolution. With xrandr, we can export all possible resolutions from the
driver, and then let users choose the one they want.

Anyhow, so the overall situation is quite complex, as we have the chain
of driver setup:
  hardware query -> vendor overrides -> oem overrides -> autoprobe logic
-> site overrides -> whatever else

and the chain of user prefs lookup:
  site defaults -> user's settings -> site mandatory

Havoc





More information about the fedora-devel-list mailing list