We don't have that knowledge ourselves. There's a small list of devices we know about and they have clickfinger enabled by default (chromebooks, apples and some system76 laptops) but we don't have a database that tells us about the physical markings. No plans to start that database either, tbh, at least not at this point.

Those are Allan's take on what the configuration could look like:
https://dl.dropboxusercontent.com/u/5031519/settings/mouse-and-touchpad-new.png

But I would still rather change the default configuration, and relegate this configuration ("behave like on Windows") to tweak-tool for example.

(In reply to Peter Hutterer from comment #1)
> We don't have that knowledge ourselves. There's a small list of devices we
> know about and they have clickfinger enabled by default (chromebooks, apples
> and some system76 laptops) but we don't have a database that tells us about
> the physical markings. No plans to start that database either, tbh, at least
> not at this point.

Another way to ask this question: Does this configuration option do anything on touchpads which aren't capable of multi-touch? Eg. will a touchpad without multi-touch and no physical buttons lose its ability to right-click if we applied the "clickfingers" configuration by default?

One comment on Allan's picture: except for the Lenovo *40 series, no touchpads have software buttons on the top of the touchpad. This picture would definitely need to change.


Answer to your question: if we can't support clickfinger, we won't provide it on a touchpad, so trying to set it would return normal error in the libinput API (and a property BadValue through the xorg driver), same as if you e.g. enable tap on a keyboard.
To my knowledge, there are no clickpads that don't support clickfinger. Only touchpads with physical buttons won't enable it, but they don't need it anyway. Switching it to default is safe.

Created attachment 314725 [details] [review]
schemas: Change default click method for touchpads

Use "Mac-style" click method for touchpads, with the whole touchpad
being available for navigating, two and 3-finger clicks are used to
emulate the right and middle buttons.

The default setting on "Windows" machines is a remnant of the olden
crappy touchpads days where the hardware vendor would have removed the
hardware buttons but didn't have multi-touch support in the touchpad,
likely in addition to Windows not supporting multi-touch gestures well
enough for those devices.

This does not change the behaviour of physical buttons associated with
touchpads or trackpoints, or the click regions on touchpads for
touchpads not capable of multi-touch clicks.

If we changed the default for how to click, is there anything why we should ever have two-finger scroll disabled? Default to "enabled" and remove the switch? Or is that not relevant.

libinput originally didn't have edge scrolling on clickpads, but enough people want it apparently. It can be a bit more precise than 2-finger scrolling, especially on gesture-capable touchpads.

So I'd leave the option to switch there.

(In reply to Peter Hutterer from comment #6)
> libinput originally didn't have edge scrolling on clickpads, but enough
> people want it apparently. It can be a bit more precise than 2-finger
> scrolling, especially on gesture-capable touchpads.
> 
> So I'd leave the option to switch there.

We don't give that option in the mouse settings though. If the touchpad supports two-finger scrolling, we only offer a way to disable it, not any way to enable edge scrolling.

oh, really? I thought you'd revert to edge scrolling in that case. Surprised that hasn't caused any outrage. But yeah, in that case I don't think you need a checkbox to disable scrolling. I can't quite see the point that, two-finger scrolling isn't easy to trigger accidentally (unlike edge scrolling), so the checkbox would likely be unused.

It used to be. It was changed recently (Bug 756863). I suppose it will cause an outrage soon. See description on the right side in the mockup to understand current behavioral:
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/system-settings/mouse-and-touchpad/mouse-and-touchpad-new.png

ok, assuming that design, I'd say you don't need a toggle at all then, I can't really think of a good reason why you'd need to disable scrolling. It's either at the edge where it's out of the way anyway, or it's two-finger which isn't an interaction easy to screw up. And when it does, it's likely libinput's fault anyway, not yours.

Review of attachment 314725 [details] [review]:

This does not apply on top of master. Besides that, did we actually agree on this patch? From the discussion, it looks like so.

Created attachment 367288 [details] [review]
schemas: Change default click method for touchpads

Use "Mac-style" click method for touchpads, with the whole touchpad
being available for navigating, two and 3-finger clicks are used to
emulate the right and middle buttons.

The default setting on "Windows" machines is a remnant of the olden
crappy touchpads days where the hardware vendor would have removed the
hardware buttons but didn't have multi-touch support in the touchpad,
likely in addition to Windows not supporting multi-touch gestures well
enough for those devices.

This does not change the behaviour of physical buttons associated with
touchpads or trackpoints, or the click regions on touchpads for
touchpads not capable of multi-touch clicks.

(In reply to Georges Basile Stavracas Neto from comment #11)
> Review of attachment 314725 [details] [review] [review]:
> 
> This does not apply on top of master. Besides that, did we actually agree on
> this patch? From the discussion, it looks like so.

It applied fine on top of gsettings-desktop-schemas :)

Let's try this out.

Attachment 367288 [details] pushed as 77ff1d9 - schemas: Change default click method for touchpads

The right-click on my Thinkpad T460 doesn't work anymore. Could it be related to this patch?

(In reply to Kai Mast from comment #15)
> The right-click on my Thinkpad T460 doesn't work anymore. Could it be
> related to this patch?

Try reverting the setting and file a new bug if it fixes it.

This has broken an existing workflow for end-users without any warning or sensible default migration.

I lost many hours of productivity trying to work out why my right-button was not working after the update.

Also you've managed to break what the default setting used to be, which was to be able to use both methods.

(In reply to Lisa from comment #17)
> This has broken an existing workflow for end-users without any warning or
> sensible default migration.
> 
> I lost many hours of productivity trying to work out why my right-button was
> not working after the update.
> 
> Also you've managed to break what the default setting used to be, which was
> to be able to use both methods.

It was mentioned in the release notes, including how to switch it back:
https://help.gnome.org/misc/release-notes/3.28/

"
All touchpads now use a gesture for secondary click (the equivalent to right click on a mouse) by default. To use the gesture, keep one finger in contact with the touchpad and tap with another finger. In many cases this replaces tapping areas of the touchpad as the default secondary click method. A choice between the two behaviors is available in the Tweaks application.
"

If you know any other way to inform users about changes in configuration, do let us know.

(In reply to Bastien Nocera from comment #18)
> If you know any other way to inform users about changes in configuration, do
> let us know.

You could have a configuration change assistant that notifies you when you log in for the first time after a version upgrade.
It would know what default settings had changed, and would check your personal settings to see if you have left them on defaults, and would then highlight the potential issue along with a note on how to get the old behaviour back.

Bonus points if it even had a clickable link that took you to the correct place in g-c-c or tweaks.

Rationale behind not just telling users to read the release notes: If their system is maintained by an IT administration team then they may not even be aware that the version of GNOME they are running is new.

Hi,

I just read Peter's blog post about this and I must say I was very surprised both by the change and by this not being discussed more widely first.

The button areas method is basically what every recent PC user ever expects, clickfingers is really a Mac only thing, one of the arguments against the button areas methos is discoverability on laptops which miss the middle marker (of which there are few, most have a middle marker), but how is clickfingers any more discoverable ??? So now we have a non discoverable method going against users expectations how is this an improvement in any way?

But there is an even more important argument against clickfingers: it will not work on a significant portion of non Mac laptops, I dare say probably more then half of them. The "click" of the click pad is done by pressing down a hardware button hidden beneath the clickpad. In many laptops you cannot "click" the entire pad, they have their touchpad hinged along the top edge and a physical button beneath the bottom edge, so you can only click aprox. the bottom half, using click fingers or "press anywhere" as the new control-panel-applet mockup calls it will not work properly on these devices, because one can NOT press anywhere, any attempts to do clickfinger style button presses in the top area will utterly fail. So we're defaulting to a click method which can not work reliable on a significant amount of the hardware out there.

This feels like it has been pushed through without first being thought trough I think we really first need to have a public discussion about this and make a list of the pros and cons and then make an informed decision, in the mean time this change should be reverted IMHO.

Regards,

Hans

So I just checked the first 4 laptops without physical buttons which I have handy and all 4 of them have their touchpad hinged at the top, including my skylake (so not that old) based XPS 15.  I believe it is safe to say that PC style hardware simply is not designed to be used with clickfingers and defaulting to it thus is a bad idea.

One of the 4 laptops I tested is a Lenovo Miix 310, which has detachable keyboard and Lenovo has chosen to not export the touchpad as a HID multitouch device there, but instead it is exported through HID emulation, using the standard PC style button areas method of right click emulation, which we cannot change.
So not only are we defaulting to a method for which the hardware is clearly not designed, on some systems the hardware does the emulation itself and the new default will cause inconsistent behavior when moving from one laptop to another.

A few general comments:

other than the *40 series from Lenovo, the one with the software top buttons, I think virtually all touchpads are hinged at the top. But: Apple hardware is the same and you cannot easily trigger the click in the top third of the touchpad. Despite that, OS X/macOS has used clickfinger since inception. However, I do appreciate that the mac's reliance on right-click is less and thus the whole thing is less of an issue there.

Note that clickfinger behaviour has been in the legacy synaptics driver for ages too, so it's not a completely novel interaction. And Windows (while not default) supports it too although IIRC you can't explicitly enable it, it just does it when you disable the button areas.

> on some systems the hardware does the emulation itself and the new default will > cause inconsistent behavior when moving from one laptop to another.

That's already the case anyway because we can't guarantee how these emulations work. Some have the tap button mapping different to what we have (LMR instead of LRM), some have two-finger scrolling that behaves differently and no edge scrolling, etc. Given that the majority of users don't regularly switch between laptops, I'm not sure that particular argument is something we have to worry about too much.

(In reply to Hans de Goede from comment #20)
> I just read Peter's blog post about this and I must say I was very surprised
> both by the change and by this not being discussed more widely first.

This isn't a democracy. It was discussed amongst stakeholders, here, for about 3 years, and acted upon. If you have problems with specific hardware, you know how to get a hold of Peter.

The change was also announced in the release notes, but it seems that nobody reads them these days.

FWIW, I welcome this change.

However, I want to say that being snippy about "nobody reads the release notes these days" is not helping, and I don't think you should dismiss Lisa's comment about discoverability so easily as "it was in the release notes."

To add to that, if I'm a nontechnical user of a Linux distribution (let's say Fedora), I probably have some vague idea that I'm using GNOME but not really any notion of 3.28 or the GNOME release cycle. The GNOME release notes aren't on my radar at all, and I don't see anything about this change in the Fedora 28 release notes... if I even land there, because there's also nothing in the Fedora upgrade process that links or encourages you to take a look at the release notes. I expect this is much the same for other popular Linux distributions. Now what Fedora does with their release notes is not GNOME's problem, just saying that you can't assume that most GNOME users will have read the GNOME release notes.

I'm not saying that we have a good solution for this at the moment :-/ Just that I feel it's a problem we need to acknowledge rather than dismiss.

(In reply to Bastien Nocera from comment #18)
> (In reply to Lisa from comment #17)
> > This has broken an existing workflow for end-users without any warning or
> > sensible default migration.
> > 
> > I lost many hours of productivity trying to work out why my right-button was
> > not working after the update.
> > 
> > Also you've managed to break what the default setting used to be, which was
> > to be able to use both methods.
> 
> It was mentioned in the release notes, including how to switch it back:
> https://help.gnome.org/misc/release-notes/3.28/
> 
> "
> All touchpads now use a gesture for secondary click (the equivalent to right
> click on a mouse) by default. To use the gesture, keep one finger in contact
> with the touchpad and tap with another finger. In many cases this replaces
> tapping areas of the touchpad as the default secondary click method. A
> choice between the two behaviors is available in the Tweaks application.
> "

I finally understood how the right click works in this new configuration. I have two C.S. degrees and it took me quite a while to get a hang of it...

I think you should provide this setting + an explanation on how to the two methods work in the regular gnome-control-center. This is the first place folks go when things don't work as expected.

I just ran into this on upgrade to F28 and had no goddamn idea what was going on. I think changing people's input expectations on upgrade with absolutely no notification is an absolutely terrible idea.

I remember when a OS X upgrade enabled "natural scrolling" for all users without notification. New combinations of swearing were invented.

What I don't like:
1. Changing it by default, but also not including in the primary Mouse & Touchpad interface, a way to change it.
2. Referencing in release notes a non-existent application to change it, Tweaks.
3. Touchpad Off? Huh? Let's try it! Holy shit I'm fucked. Why in the world would this toggle be in the default UI but changing the input behavior be in a completely different tool, that's also not installed by default?

For added amusement, my HP Spectre upgraded from Fedora 27 to 28, hasn't changed input behavior as described in the release notes or in this bug. And in Tweaks, there is no "A choice between the two behaviors is available in the Tweaks application." to be found anywhere. *shrug*

I upgraded to Fedora 28 and had no idea why the right click stopped working. I suspected a driver, I checked kernel messages. I tried Ctrl-click, Alt-click, Shift-click, long click - nothing worked as a right-click. A few days later, I tried googling for the issue and was lucky to find this bug.

I was a Mac user for two years and I had no idea of that feature on Macs. Please note that Macs have Ctrl-click and long click for the menu, which I used on Mac and which I tried on Fedora unsuccessfully.

I wanted to use the new setting, but it is not working for me. Specifically when right-clicking on a misspelled word, the cursor moves away if I click with two fingers. I don't know, maybe Mac ignore small movements before the double click. Or maybe it's a problem with my fingers.

So I had to install gnome-tweaks to enable an accessibility feature (the old right-click behavior). I checked other options in gnome-tweaks, and I don't see any other accessibility features there. Accessibility should be in Universal Access.

Just in case, I have Dell Inspiron 7348.

> the cursor moves away if I click with two fingers

Please file a bug for libinput for this. Similar bug for this is already here, same cause https://bugs.freedesktop.org/show_bug.cgi?id=99268