Input device configuration plans (was re: xf86-input-synaptics 1.0.99.3)

[Peter Hutterer]

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.