On Thu, Mar 05, 2009 at 09:15:32AM +0000, Colin Guthrie wrote: > > If synclient/gsynaptics are insufficient, I'd patch the driver. > > fdi files as configuration were always frowned upon and were mostly used > > because of a lack of alternatives. > > Hmm, strange. I was kinda basing my approach on the comments in the > Fedora synaptic package's FDI file...
we need to leave that in for a bit longer until we have (gui) tools to configure and manage settings at runtime. > Isn't inconcistency worse than breaking this one approach here. At > present only a subset of input drivers are configurable in xorg.conf and > others are not. If I have to explain to a user that they cannot set they > keyboard locale in xorg.conf but they can configure their synaptics > options, is this not a more confusing response to someone? They feel > like you just have to "know" in order to know! > > This is a genuinely open question by me, I'm not trying to put a > particular slant on it or push it one way, I'm just a bit confused now > as to why some drivers work one way and others another. > > Perhaps I'm just not seeing the strategy here... what is the intended > plan moving forward? Push more stuff into hal or less? Or perhaps make > hal+conf parsing augment each other rather than hal overriding the conf? > Whatever the plan is, I'd argue consistency should be a key consideration. I admit, much of the input stuff so far was fire-fighting, more so than a grand strategy. It's one of these times when things get worse before they get better. FWIW, I think we're on the verge of the "getting better" part though. So my opinion for input configuration: - have the driver choose some useable defaults. - fdi files are for driver selection, and for permanent, device-dependent configuration only. One example for a valid use would be a setting that fixes bugs in the hardware, not user-specific configuration. As a general rule, if the resulting fdi file can't be shared across distros, then it's probably not the right place to put a configuration. - have user-specific settings (tapping, acceleration, button mapping, etc.) through device properties, controlled by a settings daemon (usually provided by the desktop environment). This leaves only one place where we run into issues - the login manager. They have to cook up their own solution and somehow communicate with the DE about best picks. This will be similar to the current keyboard layout selection - which isn't perfect, but can be made good enough to make a user log in. Of these three steps, we have the first two done. The third step is half-done - the mechanisms are there, the programs to use them aren't yet. Then we also have to deal with the inertia of having told people to configure in fdi files what they couldn't yet do in the GUI, etc, those who still have their xorg.conf around, etc. Long-term I want permanent storage in config files gone and instead have a run-time program manage user-specific settings. That is for the 90% part of users anyway. I'm not sure myself yet on the 10% yet that require custom configurations for one reason or another. Cheers, Peter PS: the only reason why synaptics still works fine with the xorg.conf is because it grabs the device. We had to get rid of that for evdev. And of course because hotplugging isn't a major requirement for touchpads. _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg