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 _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
