Bug 93586

I am using libinput 1.1.4

Could this be restricted by the hardware? If so, how can I check that?

libinput doesn't provide clickfinger on touchpads with physical buttons, please use the actual buttons instead. It does however provide middle button emulation, so if you press both buttons at the same time you'll get a middle click.

Is there a reason why you wouldn't want to implement clickfingers for touchpads with physical buttons? Would you accept a contribution to add this feature?

For example, Apple computers from 2007 do have touchpads with a single physical button that are not clickpads. On Mac OS X, the clickfinger behaviour is implemented.

apple hasn't made touchpads with a single button since at least 2009 which is roughly 7 years ago now. there may still be laptops from 2007 floating around, but tbh it's not where our priority goes. remember that any specific hardware feature requires a bunch of testing and maintenance well beyond the initial patch to enable the feature.

I'm not aware of any other touchpad with a single button only, all others have two buttons. in which case you have access to left and right immediately, and middle by clicking both buttons. clicking real buttons is superior to clickfinger as they provide immediate haptic feedback, so there is no need to have clickfinger in addition to the button + middle button emulation.

Clicking on the two buttons is very impractical on some models, and I thought that because an option existed to have the clickfinger behaviour, I could implement it without adding too much complexity to the code. The configuration and special code paths are already there.

Also, I still to have a mac laptop from 2007.

I agree that a feature like that shouldn't add complexity, but if it is simple enough, does it have a change of being integrated?

tbh, I don't quite understand why it's more impractical to click on two buttons than putting three fingers down and pressing the button with a fourth finger.

it's not about the code itself as much as it is about the maintenance efforts of writing tests for it, making sure future feature additions are compatible, etc. usually adding a feature is the easiest part, keeping it for a couple of years while other features are added and hardware changes is the hard bit. so no, I'm not planning on integrating this, sorry.

> tbh, I don't quite understand why it's more impractical to click on two buttons than putting three fingers down and pressing the button with a fourth finger.

It's the position of the hand that is different. You rest two fingers on the touchpad while clicking with you thumb, your hand not far away from the keyboard. it's more difficult to click on the two buttons at the same time. It requires coordination and to move the hand far away from the keyboard.

> it's not about the code itself as much as it is about the maintenance efforts of writing tests for it, making sure future feature additions are compatible, etc.

I understand you want to keep the code simple and not end up with a mess like synaptics, but if I were you, I would accept such contribution at the condition that it simplifies the code overall. Especially since no new configuration option must be added (it's already there.

However, I don't want to spend time trying to find an elegant solution here if I have no chance to get my patch upstream.

Looking at the code, the physical button code is very different from the clickfinger button. So I think you are right, I don't see an easy way to implement this without cluttering the implementation.

However, do you know if it is possible to make libinput think tp->buttons.is_clickpad is always true, regardless of the actual touchpad model?

that information comes from the kernel in the form of the INPUT_PROP_BUTTONPAD property. unfortunately, properties can't be set manually, so short of patching libinput or the kernel, you can't force a touchpad to appear as a clickpad, sorry.

unlike synaptics, we don't have a config option or udev rule here that can override that, we just fix the kernel for the devices where it's wrong.