Bug 554884 - Reenable Tapping on touchpads in X?
Summary: Reenable Tapping on touchpads in X?
Status: RESOLVED WONTFIX
: 660264 729488 751100 (view as bug list)
Alias: None
Product: openSUSE 11.3
Classification: openSUSE
Component: X.Org (show other bugs)
Version: Factory
Hardware: Other Other
: P3 - Medium : Normal with 5 votes (vote)
Target Milestone: Factory
Assignee: Stefan Dirsch
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 561157 561163
  Show dependency treegraph
 
Reported: 2009-11-12 12:38 UTC by Richard Brown
Modified: 2012-03-08 10:51 UTC (History)
11 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Brown 2009-11-12 12:38:18 UTC
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.5) Gecko/20091103 SUSE/3.5.5-2.1 Firefox/3.5.5

openSUSE 11.2 GNOME has touchpad mouse clicks disabled by default, in line with upstream GNOME. https://bugzilla.novell.com/show_bug.cgi?id=551686

During the openSUSE 11.2 installation however, touchpad mouse clicks are enabled throughout, leading to the possibility of confusion when this feature suddenly turns off on the first boot.

Installation should probably have touchpad mouse clicks disabled for consistency.

Reproducible: Always
Comment 1 Vincent Untz 2009-11-20 15:07:57 UTC
The installer is yast, so there's not much the GNOME team can do there. Maybe the solution is to change the default in X, which would be in the hands of the X team?
Comment 2 Steffen Winterfeldt 2009-11-20 16:51:16 UTC
Stefan?
Comment 3 Stefan Dirsch 2009-11-20 17:15:14 UTC
So we now want to use

<merge key="input.x11_options.TapButton1" type="string">0</merge>
<merge key="input.x11_options.TapButton2" type="string">0</merge>
<merge key="input.x11_options.TapButton2" type="string">0</merge>

in /usr/share/hal/fdi/policy/10osvendor/11-x11-synaptics.fdi as default? What's the default in a KDE4, xfce, ... Xsession? Check with 'synclient -l' ...
Comment 4 Stefan Dirsch 2009-11-20 21:43:24 UTC
Apparently KDE4 doesn't enable TapButtons by default, so let's disable it in a consistent way.
Comment 5 Stefan Dirsch 2009-11-20 22:00:12 UTC
fixed in X11:XOrg and submitted to openSUSE:Factory.
Comment 6 Hans-Peter Holler 2009-12-06 19:11:40 UTC
Why dropping a feature lasting since ages?
Just because in GNOME environment someone decided this should be disabled by default?
@Richard: who wanted this?
@Stefan: as long as you are involved in X you've rejected these "enhancement requests", why now this turn?

see bugs #561163 #561157
Comment 7 Richard Brown 2009-12-06 19:29:47 UTC
@Hans-Peter
As I posted in bug #551686 and reiterated here, I feel that openSUSE should try and provide a consistent GUI experience for the user. 

In this case, as both KDE4 and Gnome disable TapButtons by default, and KDE4 and Gnome have equal status as WM's in openSUSE 11.2, it seems anomalous that the 11.2 installation routine breaks from the example and default set by both WM's and has TapButtons turned on throughout the installation process.

The current behaviour is causing confusion, when a user gets to use TapButtons throughout the install just to find it not working as they login for the first time.

So to answer your question, I wanted this, and am happy that it seems the teams involved all decided to set it one way or another.
Comment 8 Stefan Dirsch 2009-12-06 19:38:55 UTC
You will always find users want to have tapping enabled and the other way round. Not matter what you're doing, it will always be wrong. At least now we have a consistent behaviour. The same applies to horizontal scrolling ...

Feel free to discuss on your favorite opensuse ML ...
Comment 9 Clayton smaug42 2009-12-06 21:44:40 UTC
I have two issues with this change:

1.  Touchpad tap is *enabled* by default on all KDE4.3.1 and 4.3.4 installs I've checked.  I cannot find a KDE4 install (from oS 11.2) on a laptop/netbook where this is *disabled* as Stefan said.

2.  There is no Configure Desktop > Mouse option in KDE4 to toggle this back on for users that prefer touchpad tap (Gnome does have this option).  Installing 3rd party apps such as Synaptics to control this is not an acceptable workaround.  

Touchpad tap is a common thing on other common OSes.  OSx has it.. Windows has it.  Users coming from those OSes expect it in my observation.  I don't care what the default is, but being able to switch it back on for users coming from OSX/Windows is rather important.
Comment 10 Vincent Untz 2009-12-06 22:12:33 UTC
(In reply to comment #9)
> Touchpad tap is a common thing on other common OSes.  OSx has it.. Windows has
> it.  Users coming from those OSes expect it in my observation.  I don't care
> what the default is, but being able to switch it back on for users coming from
> OSX/Windows is rather important.

At least in GNOME, it's really easy to change the behavior: just open the mouse preferences and check a checkbox... This bug was really just about the default setting.
Comment 11 Clayton smaug42 2009-12-06 22:16:01 UTC
If the default is changed, does this carry over into KDE4?
Comment 12 Stefan Dirsch 2009-12-07 00:09:42 UTC
(In reply to comment #9)
> I have two issues with this change:
> 
> 1.  Touchpad tap is *enabled* by default on all KDE4.3.1 and 4.3.4 installs
> I've checked.  I cannot find a KDE4 install (from oS 11.2) on a laptop/netbook
> where this is *disabled* as Stefan said.

What I said is that KDE does not enable it. I didn't say that it disables it.
Apparently it's happy with the X default. BTW, if changing the default in KDE
to enabled then we can forget about consistency again.

> 2.  There is no Configure Desktop > Mouse option in KDE4 to toggle this back 
> on for users that prefer touchpad tap (Gnome does have this option).  
> Installing 3rd party apps such as Synaptics to control this is not an 
> acceptable workaround.  

Well, there is at least synclient. ;-)

> Touchpad tap is a common thing on other common OSes.  OSx has it.. Windows has
> it.  Users coming from those OSes expect it in my observation.  I don't care
> what the default is, but being able to switch it back on for users coming from
> OSX/Windows is rather important.

How should I know? I never use any of those OSes. This begs the question why GNOME believes it's a good idea to have it disabled by default.
Comment 13 Stefan Dirsch 2009-12-07 00:14:54 UTC
(In reply to comment #11)
> If the default is changed, does this carry over into KDE4?

Apparently yes, unless KDE4 changes it back to enabled.
Comment 14 Clayton smaug42 2009-12-07 07:51:37 UTC
So, if touchpad tap is disabled in X, and KDE uses whatever X is set to... where does this leave KDE4 users who want touchpad tap enabled.  As far as I can see, there is no visible option to turn it back on. (new Bugzilla time?)
Comment 15 Stefan Dirsch 2009-12-07 08:29:46 UTC
I suggest to open a new bug against KDE to enable tapping in KDE4 or provide a tool, with which you can easily do this. In the discussion on opensuse-factory there were mentioned several tools.

"You can use Synaptiks or kcm_touchpad (I had the best luck with the former)
from kde4:community repository - or Touchfreeze from Packman repository."
Comment 16 Clayton smaug42 2009-12-07 08:36:20 UTC
Anything from the community repo only works IF you have internet access.  That leaves users standing with no simple way to enable touchpad tap in KDE4 (just to keep consistent with Gnome which in this case is inconsistent with all other OSes I've used on laptops)

Is that a new bug against KDE in Novel bugzilla or the upstream KDE bugzilla?
Comment 17 Stefan Dirsch 2009-12-07 08:46:03 UTC
(In reply to comment #16)
> Is that a new bug against KDE in Novel bugzilla or the upstream KDE bugzilla?

Good question. But I think our KDE developers are going to tell you if they think
it's good idea to report this upstream. So I would try to report this in Novell bugzilla first.
Comment 18 Rihards Olups 2010-09-03 13:25:05 UTC
hmm. i believe this has been a very bad decision :)

1. users expect tapping to work. i don't know about other operational systems, but as somebody noted, on other systems it works by default.

i expected it to work - i almost filed a bug that it's broken...

2. the argument that it should be changed because gnome has it disabled by default is not valid.
a) the purpose of the distribution for many people is to have software defaults changed in case developers hav no idea about usability ;)
b) suse changes lots and lots of defaults from the upstream - even in places like bash.

i understand and fully support the drive for consistency, it's just that i believe in this case reaching for a minor improvement (consistency) a major problem has been created - just look at all the users being confused...

additionally, this is a significant problem with the live cd, which was the first time i noticed tapping not working and considered filing a bug. i did not file one because i was SURE this glaring and simple bug would be with a patch shortly after the release.

so i would suggest reopening this issue and changing the default for the tapping to be enabled.
Comment 19 Clayton smaug42 2010-09-03 14:23:45 UTC
Not that it matters much to those that made this decision, but other Gnome centric distros have tap enabled (eg Ubuntu).  In other words, openSUSE is NOT consistent with other major Gnome based distros, and not consistent with Windows and OSX behavior.  It doesn't matter that it can be turned back on with some system setting... the core problem is that we've set a default that is exactly opposite to what is expected.
Comment 20 Stefan Dirsch 2010-09-03 14:35:30 UTC
Aren't we back to my comment #15?
Comment 21 Rihards Olups 2010-09-03 14:40:26 UTC
definitely not. while having it working in kde would be nice, having it _not_ working during the installation would be crappy.

additionally, the initial goal of the change, consistency, would be broken anyway, and we would be in a worse situation than we begun with.
Comment 22 Stefan Dirsch 2010-09-03 14:49:23 UTC
FWIW, having tapping disabled is the upstream default in latest 
xf86-input-synaptics driver release 1.3.0. Anyway, some project manager should decide about the behaviour for installation, GNOME and KDE. If KDE/Gnome want to use different settings a consistent behaviour for installation and afterwards is simply not possible. I don't care much about the default in X, but I would like to avoid to change it back and forth all the time.
Comment 23 Clayton smaug42 2010-09-03 14:52:23 UTC
openSUSE/KDE4/Gnome has the ability to enable touch tap in the
config settings.  The enable/disable setting is there in a default openSUSE
install for at least Gnome and KDE4.  

The issue isn't that you can re-enable it, it's that it's disabled in the first
place.  

People coming to openSUSE from... say... Ubuntu... install and expect a similar
experience.  A default Gnome install from Ubuntu has touch tap enabled (or is
has on every default 10.04 install I've done lately)... the user then installs
openSUSE.. no touch tap, and they are either confused (as a new user) or
annoyed.  They expect touch tap to "just work"... not something they have to
configure.  I've had to explain countless times now to new-to-Linux users that
the OS isn't broken, and yes their touchpad works correctly in Linux, they just
need to enable it.

I don't care which we have since I know how to enable/disable it, but I do
expect a consistent experience compared to other equivalent distros and OSes...
and we're not providing that... I think that's the point here.  People don't
expect to have to enable what is standard functionality on other desktops/OSes
(just like they don't expect to have to configure something like a scroll wheel
on a  mouse).

We do a good job in general in providing a nice smooth user experience with
defaults etc, but this touch-tap thing is one that many users seem to trip over
(at least those I deal with when I provide support for openSUSE installs seem
to get trapped by this setting.).
Comment 24 Stefan Dirsch 2010-09-03 14:56:02 UTC
The bug has been reopened, Coolo as project manager of openSUSE has to decide about that. What else do you expect from me?
Comment 25 Clayton smaug42 2010-09-03 14:59:47 UTC
@Stefan:  Nothing :-)  I think we're just trying to bring up the point that we'd like this revisited... not resolved right now, immediately, with a decision in 10 minutes.  Theres time between now and 11.4.  So... no worries.
Comment 26 Vincent Untz 2010-09-03 17:28:56 UTC
(In reply to comment #23)
> The issue isn't that you can re-enable it, it's that it's disabled in the first
> place.  

FWIW, I disagree. You're talking about consistency with other OS, but did you check Fedora, for example? And what about consistency with upstream behavior?
Comment 27 Stephan Kulow 2010-09-06 09:23:52 UTC
I don't buy the "people coming from ubuntu" argument - if the upstream default of both GNOME and synaptics driver are off and KDE has no default at all I see no reason to argue against that. 

If ubuntu enables it, there might actually be people who are relieved they don't have to disable it in openSUSE.

That said, I have no touchpad, so I have to trust upstream there. I would go for no patch.
Comment 28 Stefan Dirsch 2010-09-06 09:55:28 UTC
Thanks for taking a decision here, Coolo. Closing as WONTFIX now.
Comment 29 Stefan Dirsch 2010-12-18 12:12:13 UTC
*** Bug 660264 has been marked as a duplicate of this bug. ***
Comment 30 Rihards Olups 2010-12-18 13:21:35 UTC
well, this decision didn't seem to me to be good at all, so...

1) it might be worth on this bug even though it is closed, just to see how annoying it is;
2) https://features.opensuse.org/310811 is a request for 11.4 to reenable taping
Comment 31 Stefan Hundhammer 2010-12-30 19:24:33 UTC
I can't believe this. People who freely admit that they don't know the first thing about it (comment #27: "I have no touchpad") get to decide that the behaviour that used to be the default for openSUSE for years (tapping enabled) as well as the default for all flavours of Windows (XP, Vista, Win7, ...) is changed to "make it unusable for the average user".

What would you say if somebody disabled your left mouse button with the same reasoning, claiming you can always hit [Return] on the keyboard instead?

Adding insult to injury, NONE of the specialists involved here offers a workable solution for the average user. synclient - yes, but it's a hassle to start it at the appropriate place. Some KDE4 extension - well, not useful if you don't use KDE4.

So here is a workaround for those few users who haven't moved on to Kubuntu yet:

Edit /etc/X11/xorg.conf.d/20-synaptics.conf (as root) and add one "Option" line:

Section "InputClass"
    ...
    Option "TapButton1" "1"
    ...
EndSection


-- Stefan Hundhammer <sh@exsuse.de>
Comment 32 Stefan Dirsch 2011-01-06 13:34:54 UTC
> I can't believe this. People who freely admit that they don't know the first
> thing about it (comment #27: "I have no touchpad")

My guess is that Coolo is using a Lenovo Thinkpad, which only has a joystick instead of a touchpad. This is what I call unusable. ;-)
Comment 33 Stephan Kulow 2011-01-10 09:29:32 UTC
I did _NOT_ decide to change anything. I was asked for an oppinion and I gave mine. If you have a different one -> fine.
Comment 34 Stefan Dirsch 2011-11-10 10:59:33 UTC
*** Bug 729488 has been marked as a duplicate of this bug. ***
Comment 35 Christopher Yeleighton 2011-11-10 21:09:07 UTC
{ man 4 synaptics; }

> Tapping is disabled by default for touchpads with one or more physical buttons.

Introduced: <URL: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/src/synaptics.c?id=102d1d6cfbc1cf3df3845b56ad1deb82a40d1cb8 >

This is a big patch that also introduces several other autodetect features that may be useful.  I do not think it is useful to disable TapButton1 because it is a widely used function even with devices equipped with physical buttons, but that is just my opinion (incidentally shared by several other customers who dared report this as a bug here and to Fedora) while the authors may have been distracted from reality with the idea of showing off how smart they now are ;-)  In other words, the current implementation suffers from logical perfection.

Anyway, { synclient TapButton1=1; } does the trick painlessly in no time.  The driver has a myriad of interesting options so there is a good chance you would want to configure it with synclient for your personal use anyway :-)

I suppose this bug is INVALID.
Comment 36 Stefan Dirsch 2012-03-08 10:51:38 UTC
*** Bug 751100 has been marked as a duplicate of this bug. ***