xinput: Do I want xorg.conf? Do I want hal? Do I want udev?

[Peter Hutterer]

On Thu, Nov 26, 2009 at 09:34:38AM -0500, Tom Horsley wrote:
> On Thu, 26 Nov 2009 09:19:52 -0500
> Tom Horsley wrote:
> 
> > That might be the very thing! There is even a fedora package
> > for it. I'm off to crank it up and see if I can get it
> > to work they way I want. Thanks!
> 
> Unfortunately, just like gnome-mouse-properties, there is
> nothing in this tool that will handle the button mapping or
> drag lock changes I want :-(.

As with much of input, we've been in a transitional phase for the last years
to turn from the old static system into a more flexible and dynamic one. X
is on the bottom of the stack, so any change needs to be reflected in the
upper layers - and they're not necessarily there yet.

We're slowly catching up, but not as quick as some would like us and many
options are still not exposed - drag lock being one example.

So here's the cardhouse:
As you said, the single xorg.conf file isn't really suited to evdev (or the
other way round). The input system is now aimed at per-device, per-session
(runtime) configuration. Static configuration is possible, but discouraged.
You can dop keys into the HAL configuration, but that'll go away eventually
with udev. 
The best proposal for static configuration were Dan's xorg.conf.d patches
but I don't know how much they have progressed in the last months. Maybe Dan
can comment on that? 

For said run-time configuration, you need a configuration manager.
gnome-settings-daemon along with gnome-control-center is making steps
towards it, but there's a bit of inertia, not least because it's designed as
a "one device" config tool, not a "per device" config tool. And the manpower
to work on it is limited.

GPointingDeviceSetting is the successor of gsynaptics and aims at per-device
configuration. IMO it could do with better integration into the
control-center capplets but I haven't looked at it in a while so I might be
wrong there.

I don't follow KDE or other desktop environments enough to be qualified to
commment on what's going on there, I really don't know.

If you don't want a session manager or you prefer a different desktop
environment - you're on your own. At least until that environment gets the
configuration tools required.

So for now, not every option exposed by the driver can be enabled
conveniently. Once the xorg.conf.d is there, that'll get easier, especially
if you don't run a session daemon. If you run a session daemon, you're in
for even more fun, since any static configuration may be overridden by the
daemon's configuration. e.g. g-s-d supports basic touchpad configuration and
that overrides whatever the user sets through HAL/xorg.conf.

The key to solving this transitional state is to advance the desktop
environment tools to expose more options to the user.

> I wonder if I can make a generic gnome-settings-daemon
> plugin that will just run user specified scripts on
> dbus events? Then fancy GUI tools can come later, but
> at least people could have a way to get things done
> while waiting for the fancy stuff...

IMO, it's better to go for the fancy GUI tools from the start instead of
hacks that allow user-specified scripts to run at random times.
I cringe at the thought of bugreports with badly-written shellscripts that
conflict with g-s-d settings, they're near impossible to triage.
The time it takes you to write this generic plugin is likely the same as it
takes you to add the options you need to g-s-d (and control-center).
Having done parts of the touchpad tool, I can tell you it's (technically)
quite trivial to add new config options.

Cheers,
  Peter