GNOME Bugzilla – Bug 154029
Add configuration support for touchpads (synaptics)
Last modified: 2009-07-13 05:46:26 UTC
Most laptops have an synaptics compatible touchpad for which a special xfree/xorg driver (http://w1.894.telia.com/~u89404340/touchpad/index.html) exists. It allows to modify run-time configuration using shared memory. This means it is possible to change parameter settings without restarting the X server. It also provides a daemon to disable touchpad while typing at the keyboard and thus avoids unwanted mouse movements. These are however still based on a command-line tool and there is no way to configure them within the Gnome environment. It is possible to enhance the mouse-configuration utility with another tab to configure the touchbad? Of course it should be only available when the driver is loaded. KDE already has such an frontend (http://qsynaptics.sourceforge.net/about.html) It would be nice to have such a similiar tool in Gnome too.
I second this. The mouse preference panel is *useless* for 70% of the laptop users. That creates a redundancy of the pref panel and therefore bad usability. Please add synaptics support in a way that makes sense.
this is working for me in gnome 2.13.1 (ubuntu dapper). I'll ask someone to close the bug for me. Matt
Actually perhaps I have misunderstood this bug. My touchpad is now reacting to configuration in gnome-mouse-properties. If this bug is about something a bit more than that, then please leave open. Otherwise, I think you should be able to close.
gsynaptics (http://gsynaptics.sourceforge.jp) shows us what can be done. Maybe it can be merged as a new tab on mouse configuration applet?
Any progress on this bug?
Not unless there is a developer interested in working on it.
*** Bug 324612 has been marked as a duplicate of this bug. ***
This bug report would be more useful if it described the actual user features that we would like to have rather than just "change parameter settings". As mentioned, the most imporant feature seems to be - Disabling touchpad clicking, to prevent cursor movement during typing.
(In reply to comment #8) > As mentioned, the most imporant feature seems to be > - Disabling touchpad clicking, to prevent cursor movement during typing. - disabling touchpad automatically when external mouse is detected
Created attachment 95536 [details] Screenshot of my implementation I'm working on this. Supported options so far are: - enable touchpad - enable touchpad clicking - enable scrolling As this is the first time I'm working with Gtk+ and C my code is still a (very large) bit rough, though I'm planning to attach a more cleanly implemented patch by next week. Attached is a screenshot of the my current work. Comments appreciated.
Rock on! Perhaps you can steal^Wuse gsynaptics code?
That screenshot looks like a good start, but there are some specific configurables I would like to see in there: - Disable touchpad while typing. I believe the synaptics driver has an option for this that can be hooked into. - Adjust sensitivity with a slider - Adjust the position of the right-side scroll area, which seems to always be in the wrong place to start with
Created attachment 95832 [details] [review] Patch which implements the Touchpad tab
Created attachment 95833 [details] glade file No patch, glade changed too much though I only touched my newly created tab
Created attachment 95834 [details] schema, use gconftool --install-schema-file belongs to libgnome
Created attachment 95835 [details] Screenshot: new tab after applying the patch
This is what I've done so far. It detects if synclient is installed and if SHMConfig is set to TRUE in xorg.conf. Works fine for me, hope it does that for you too and that the patch isn't too bad. Things I'd like to improve are: - handle left handled mouse - disable touchpad while typing
Ok, some comments: * Please try to isolate the touchpad-related changes from the glade stuff. Glade is known to subtly (or not so subtly) break stuff if you don't. * don't use C++-style comments (//...) * I'm not sure what the best way to handle systems without synclient/proper X configuration is. In some cases I'd prefer not to see the tab (or any error messages) at all, in others some kind of feedback is very helpful (though I'm not sure the current messages aren't too technical) * do we have to use the external helper app? no API? * the two sliders desperately need labels ("Enable vertical scrolling? Low/high? WTF?") * "Enable touchpad clicking" isn't quite right, either ("why would I want to click the touchpad...?"), I think. Could be wrong, though, and can't really think of a better string off-hand, but I'll bet there is one. * The tab is called "Touchpad", there shouldn't be another heading also called "Touchpad". Make that "General" or something. * "/desktop/gnome/peripherals/touchpad/off" - the usual convention is to call keys like that ".../enable" I've got a few other minor nitpicks, but I'll leave those until the other stuff is sorted out. Other than that looks nice. We'll have to b quick about it, though, so as not to make the patch obsolete before it can get in. The mouse capplet might be going away soon...
(In reply to comment #18) Hi Jens, thanks for your comments! > * Please try to isolate the touchpad-related changes from the glade stuff. > Glade is known to subtly (or not so subtly) break stuff if you don't. > > * don't use C++-style comments (//...) Yeah, I'll do that when I upload my next patch. > * I'm not sure what the best way to handle systems without synclient/proper X > configuration is. In some cases I'd prefer not to see the tab (or any error > messages) at all, in others some kind of feedback is very helpful (though I'm > not sure the current messages aren't too technical) synclient is provided by the synaptics driver, so it *should* be available if the driver is installed. I included the tab with the error message in case of missing synclient so that people are aware of the possibilities the capplet gives, though I realize that this may annoy non-laptop users. On the other hand, if we assume that synclient is always provided by the synaptics driver, which should only be loaded when there is a touchpad, we could safely hide the tab if synclient isn't there and show the error message if synclient is there, but shared memory configuration is disabled. But I'm really not sure what the best way to this is from a HIG and user's point of view is. > * do we have to use the external helper app? no API? I had a look at the synclient source and could not find an API. The code isn't much more than "write value to address offset_of(key)". But since synclient is provided by the driver, I don't think we need to duplicate that code. > * the two sliders desperately need labels ("Enable vertical scrolling? > Low/high? WTF?") Right, I'll add them. > * "Enable touchpad clicking" isn't quite right, either ("why would I want to > click the touchpad...?"), I think. Could be wrong, though, and can't really > think of a better string off-hand, but I'll bet there is one. What about "Enable clicking with touchpad" oder "Click by pressing the touchpad"? > * The tab is called "Touchpad", there shouldn't be another heading also called > "Touchpad". Make that "General" or something. That's true, I couldn't come up with a better word. "General" sounds good to me. > * "/desktop/gnome/peripherals/touchpad/off" - the usual convention is to call > keys like that ".../enable" I know, but I wanted to be compatible to the keys gsynaptics sets. I don't want to expose all possible options in the UI, so a power user would still be able to use gsynaptics to tweak everything without messing up GNOME's config. > I've got a few other minor nitpicks, but I'll leave those until the other stuff > is sorted out. > > Other than that looks nice. We'll have to b quick about it, though, so as not > to make the patch obsolete before it can get in. The mouse capplet might be > going away soon... I'll try to fix the trivial things before the weekend. Would be nice if we could decide if we want to use synclient/syndaemon or duplicate the code and what to do about showing/hiding the touchpad tab.
(In reply to comment #19) > On the other hand, if we assume that synclient is always provided by the > synaptics driver, which should only be loaded when there is a touchpad, we > could safely hide the tab if synclient isn't there and show the error message > if synclient is there, but shared memory configuration is disabled. That's a sensible compromise, I'd say. I still think the message should be a bit less technical, though. > But I'm really not sure what the best way to this is from a HIG and user's > point of view is. The general recommendation is to not hide options, but in some cases (like the non-laptop user) there are good reasons to deviate. > I had a look at the synclient source and could not find an API. The code isn't > much more than "write value to address offset_of(key)". But since synclient is > provided by the driver, I don't think we need to duplicate that code. Right, poking memory addresses probably can't be considered a stable interface. If there's no library provided with the driver, I guess we'll have to go with synclient. > * "Enable touchpad clicking" isn't quite right, either ("why would I want to > > click the touchpad...?"), I think. Could be wrong, though, and can't really > > think of a better string off-hand, but I'll bet there is one. > > What about "Enable clicking with touchpad" oder "Click by pressing the > touchpad"? Definitely better. "Enable mouse clicks with touchpad"? Other suggestions welcome. > > * "/desktop/gnome/peripherals/touchpad/off" - the usual convention is to call > > keys like that ".../enable" > > I know, but I wanted to be compatible to the keys gsynaptics sets. I don't want > to expose all possible options in the UI, so a power user would still be able > to use gsynaptics to tweak everything without messing up GNOME's config. Hm, ok, I guess that's good enough a reason to do it that way.
Created attachment 95896 [details] [review] Updated patch - implemented Jens' comments - includes patch for glade file - switch TapButtons for left handed mice
Created attachment 95897 [details] Updated Screenshot
I don't think this is the correct approach. It encourages people (and distributions) to set SHMConfig to true, which is a screaming security nightmare (it effectively allows anyone with access to the machine, even remote access, to be able to make the user click on arbitrary points of the screen). The correct approach is to layer the configuration protocol over X, which is something I'm working on.
Can you elaborate? What does this mean for the control center and what's the timeframe we're talking about?
Well, I'd solidly recommend against any approach that uses SHMConfig. It's simply not safe. As far as layering the config over X goes, doing it properly will require modifications to the X server, so we're looking at 6 months or so until their next release.
Oh, yeah - enable touchpad button? Not such a great idea :) (think about the case of machines that only have a touchpad)
Apparently Ubuntu Gutsy has a Touchpad tab in the Mouse control panel, though I can't see it in my Ubuntu Gutsy installation. Quoting from desktop-devel-list: " 26_add_touchpad_to_mouse_settings.patch 27_add_touchpad_to_settings_daemon.patch 28_fixup_touchpad_config.patch 30_extra_touchpad_config_paranoia.patch (http://people.ubuntu.com/~scott/gnome-control-center-patches) "
Gutsy has only these options (for my installation) on the touchpad tab: - Tap on Click - Vertical scrolling - Horizontal scrolling But this does not include the option "disable while typing" which is IMHO the most important for this bug.
*** Bug 543424 has been marked as a duplicate of this bug. ***
Looks like this will be fixable with some new X: http://who-t.blogspot.com/2008/10/device-properties-have-landed.html
*** Bug 558911 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > Gutsy has only these options (for my installation) on the touchpad tab: > > - Tap on Click > - Vertical scrolling > - Horizontal scrolling > > But this does not include the option "disable while typing" which is IMHO the > most important for this bug. > Now that tap on click and vertical scrolling are disabled by default by new synaptics-1.0, I think that a way for configuring this from gnome is even more needed. Maybe ubuntu patch for gnome-control-center-2.25.90 could be a good start point... What do you think? Maybe its problems could be reported to ubuntu maintainers... Thanks a lot
The main problem was that gsypnaptics (and this code) required using the SHM method of configuration, which is very ugly. Any code we add to the control-center would need to use the XInput properties instead. See: http://lwn.net/Articles/315613/ http://www.x.org/wiki/XInputSpec#head-0a74e393ba085d465f78357d56ebf38385051c9c
Turns out Ubuntu has updated their patch to use properties, but never upstreamed it. So, here is Peter Hutterers adaptation of their patch.
Created attachment 132378 [details] [review] patch The corresponding gnome-settings-daemon-patch is in bug 578444
The patch should probably disable the 'while typing' checkbox if syndaemon is not available.
Other than cosmetic changes (same as the other patch) looks good to me.
Created attachment 134243 [details] [review] 0001-Support-touchpad-configuration-through-device-proper.patch style changes (foo() -> foo ()), one if brace moved up and a few whitespace fixes.
+#include <X11/Xatom.h> +#include <X11/extensions/XInput.h> +#include <X11/extensions/XIproto.h> I suspect we need to add XInput checks to configure for this?
Created attachment 135913 [details] [review] 0001-Support-touchpad-configuration-through-device-proper-v2.patch Sorry, wasn't on the CC list and didn't get notified about your comment. Here's the updated patch. Modifications: - last hunk: configure.in check for libXi 1.2, defines HAVE_XINPUT if present - hunk 1: conditionally include xinput headers - hunk 1: remove XIproto.h include, this was a leftover of the original Ubuntu patch and isn't needed - hunk 2: if HAVE_XINPUT is not defined, return False from find_synaptics() - hunk 2: find_synaptics() returns False if the server's version is < 1.5 - hunk 2: call to XListInputDevices moved down a bit to skip it if we bail out early anyway. Note that libXi is on version 1.2 for property support, whereas inputproto is on 1.5. So we check for 1.2 in configure, but 1.5 in the code. This is not a typo :)
Please consider adding an option for disabling the touchpad while there is another mouse present, according to Bug 337367
Ok, g-c-c has finally branched. Full steam ahead. Thanks Peter!
FWIW, the next synaptics version will have a read-only property "Synaptics Capabilities" [1]. This property tracks the physical capabilities of the touchpad and can be used to query whether the device has multi-finger support. If not, the radio button selecting two-finger scrolling should be disabled. If someone finds the time to write the necessary patch, I'll be happy to review it. [1] http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=6b3a032fdf5479cb5be441a01ebef92a39e5fb69
Well, since the patch was marked commit_now, I've pushed it into git. Unfortunatly I can't test it since I don't have a touchpad, but anyone is welcome to re-open this bug or revert the patch if there are problems.