(In reply to Gennady Uraltsev from comment #0)
> For quite many years the default (with synaptics) was 
> 
> 1 finger  -> left mouse
> 2 finger -> middle mouse
> 3 finger -> right mouse

This is not actually true, as from xf86-input-synaptics/src/synaptics.c (and my muscle memory):
    tapButton1 = priv->has_left ? 0 : 1;
    tapButton2 = priv->has_left ? 0 : 3;
    tapButton3 = priv->has_left ? 0 : 2;

In X11 parlance, 1 is left, 2 is middle and 3 is right, so the X11/synaptics behaviour is exactly the same as you describe with libinput.

Ok, agreed. Now with synaptics the default one is the same as libinput. However some time ago it was not so. As a matter of fact when I started using Linux the other was default. Anyway this is not central.

Synaptics allows configuring this mapping, would it be possible to make libinput do the same? I actually looked through the code and from what I understand it is fairly simple. The only problem that I do not know enough about system programming to actually be able to write something that exports this as an option to be modified from outside. I could just switch 3 statements and recompile but this is not very nice for obvious reasons..

first: you're correct that there is no configuration option. This is intentional though and tbh I don't have any plans exposing this as a config option. 

Exporting as yet another config option that needs to be maintained and tested for indefinitely, and the actual benefit is very minimal.

Thank you for your response. As you can imagine I would disagree about the benefit being minimal because I think that This is a configuration option that goes together with the tap-to-click capability. Currently the tap-to-click is by default disabled so the people that enable it are the ones that actively use it. Plasma 5 (the new version) exports the possibility of configuring the buttons in the gui but it is greyed out if not using synaptics. So exporting this option will not make it hidden somewhere below but it will be visible and used.

However I understand that the effort required to export and test this is going to be significant and that you are skeptical about dedicating time to it. Oh well....

Finally I would like to inquire if it would  be reasonable to implement button remapping on a per-device basis? I saw that this option exists:

Option ButtonMapping string

Can it be used on a per device basis? 

Thank you!

I actually have two computers using synaptics, and they are configured differently (mostly because I didn't bother changing the default). In one, I have to use three fingers to get middle click, in the other I only need two. I can confirm that two fingers for middle clicks is easier, especially if the ouchpad is tiny.

(In reply to Mildred Ki'Lya from comment #5)
> I can confirm that two fingers for middle clicks is easier, especially if
> the ouchpad is tiny.

looking into my crystal ball (which may or may not be accurate) I'd say the future of tiny touchpads is in the past :)
libinput replaces the input stack, we keep synaptics around, but optimising for hardware that is on the way out is not ideal.

(In reply to Gennady Uraltsev from comment #4)
> Thank you for your response. As you can imagine I would disagree about the
> benefit being minimal because I think that This is a configuration option
> that goes together with the tap-to-click capability. Currently the
> tap-to-click is by default disabled so the people that enable it are the
> ones that actively use it. Plasma 5 (the new version) exports the
> possibility of configuring the buttons in the gui but it is greyed out if
> not using synaptics. So exporting this option will not make it hidden
> somewhere below but it will be visible and used.

a bit of history here: in synaptics (and other drivers) the default behaviour was that whenever we added a feature, however tiny, we added configuration options for that feature. synaptics has over 70 configuration options which gives us somewhere around 1E101 combinations. the main reason *why* we did this was because we couldn't rely on the underlying hardware to be useful, and the userspace stack didn't exist to make it useful. So adding configuration options was the easy option (and less controversial too) but is a long-term maintenance nightmare. Note that I've been the synaptics maintainer for a number of years, so you can blame me for most of that.

From what I can tell, KDE looked at all the available options and implemented a checkbox for all of them, because if there's a toggle, surely someone wants to tick it. So the presence of a configuration option in KDE is not a good reason for why we need the configuration option. Providing an option doesn't mean it will be used, merely that the option won't be greyed out anymore.

The situation is different now, udev and the udev hwdb are fantastic for fixing devices. And HW itself has improved a lot. the way libinput hooks into the stack means we can have device-specific rules that we couldn't before (e.g. the x230 has a different pointer acceleration profile than other touchpads).
So we try to fix things once for a device (rather than letting users figure out what config option set they need to make a device useful) and only export those options that are very much personal decisions (tapping on/off).
At this point, I don't think that 2-finger middle clicks are that important, sorry.

> Finally I would like to inquire if it would  be reasonable to implement
> button remapping on a per-device basis? I saw that this option exists:
> 
> Option ButtonMapping string
> 
> Can it be used on a per device basis? 

yes, all xorg.conf Options are per-device.

Closing as wontfix, please see comment 6 for an explanation