On synaptics on a clickpad, if you click with one finger and move the other, you get a drag and drop. On libinput if you do the same you get a right click, because it sees two touches, even if the fingers are not close enough to be a right click. This might be a deliberate change in behavior from the old driver, but it should be documented because it is likely to annoy users accustomed to old way of clicking and dragging. This is libinput master as of today.
Hans, can I punt this one to you? Giovanni: pls evemu-describe your device so we know what type of touchpad it is, thanks.
Hi Giovanni, You are right in libinput we do not look at the finger distance, you should be able to left-click drag and drop in clickfinger mode by clicking with one finger and then adding a second finger to move the cursor around, instead of having both fingers down when clicking. At this point in time we've no intention to start looking at finger distance(s) when deciding what to do when in clickfinger mode. Does clicking with a single finger and then adding the second finger work for you, and can you get used to that, or should we re-evaluate this ? Regards, Hans
I think this should be reevaluated. I'll try to explain. I come from years using a previous laptop with a touchpad without working multitouch, so I'm used to clicking using physical buttons. In practice, this translated to using the middle finger to move the pointer, and the index finger for primary click. On a clickpad, this is also natural: to click, I lift the middle finger and click with the index, and the hand movement is roughly the same on the two touchpads (the old one was quite small, so physical buttons were in reach). To drag, this translates also naturally: just don't lift the index finger, put the middle finger back and move the mouse. On the other hand, your proposed behavior would require me to click using the middle finger, and then keep moving it until the drag distance triggers, or the keep it clicked without other fingers until the drag timeout. I understand that there is added complication in looking at the finger distance, but there is also existing code in synaptics to handle this, and again IMHO it feels very natural, especially for someone coming from a touchpad with physical buttons, so I'd like you to reconsider. evemu-describe attached. The clickpad in question is a standard Apple touchpad.
Created attachment 113854 [details] evemu-describe
Hi Giovanni, The way you are describing how you want things to work, with one finger resting ready to click, and one moving the pointer around, sounds like you want the clickpad to work with 2 softbutton areas at the bottom, emulating the old physical buttons, like most pc clickpads, rather then as an apple clickpad with so called clickfinger mode. If you've the latest xf86-input-libinput you should be able to switch clickmethod from the commandline. I don't have a laptop handy atm, so here is a generic blurb about setting mouse speed: [hans@shalem ~]$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ USB OPTICAL MOUSE id=8 [slave pointer (2)] ⎜ ↳ Lite-On Technology Corp. USB Multimedia Keyboard id=11 [slave pointer (2)] ⎜ ↳ SINO WEALTH USB Composite Device id=13 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Lite-On Technology Corp. USB Multimedia Keyboard id=9 [slave keyboard (3)] ↳ Lite-On Technology Corp. USB Multimedia Keyboard id=10 [slave keyboard (3)] ↳ SINO WEALTH USB Composite Device id=12 [slave keyboard (3)] ↳ Burr-Brown from TI USB Audio DAC id=14 [slave keyboard (3)] And then: [hans@shalem ~]$ xinput list-props 8 Device ' USB OPTICAL MOUSE': Device Enabled (132): 1 Coordinate Transformation Matrix (134): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Accel Speed (264): -0.469058 libinput Natural Scrolling Enabled (265): 0 libinput Send Events Modes Available (250): 1, 0 libinput Send Events Mode Enabled (251): 0, 0 libinput Left Handed Enabled (266): 0 libinput Scroll Methods Available (267): 0, 0, 1 libinput Scroll Method Enabled (268): 0, 0, 0 libinput Button Scrolling Button (269): 0 Device Node (252): "/dev/input/event5" Device Product ID (253): 5593, 2639 [hans@shalem ~]$ xinput set-float-prop 8 "libinput Accel Speed" -1 And now I've configured my mouse to the slowest setting, the accel scale goes from -1.0 to +1.0 with 0.0 being the default. You should see something similar to the "Scroll Methods" above for click methods with Available being 1, 1 and Enabled in your case being 0, 1, if you change that to 1, 0 then you get softbutton areas at the bottom of your clickpad. I'm still reluctant to add the finger distance thingy, because it is almost impossible to get right for all model touchpads and I've the feeling it is not really necessary. Whenever possible I try to avoid these kind of heuristic thingies, since heuristics are never 100%, and it can be better to be consistenly wrong, then to be right in 90% of the time and wrong in 10% of the time. The main reasoning here is that if we are consistent in our behavior it us much easier for users to figure out how the touchpad is behaving and for them to adapt. Regards, Hans
I see your point, and you are probably right that what I'm looking for is soft button areas - even if the touchpad is quite big and there's no markings so I don't know where the areas are and if they would work when my fingers are in the middle. In any case, I'll try to adapt to the new world order and I'll reopen if this is still a problem. Thanks for the support and detailed feedback.
Hi, (In reply to Giovanni Campagna from comment #6) > I see your point, and you are probably right that what I'm looking for is > soft button areas - even if the touchpad is quite big and there's no > markings so I don't know where the areas are and if they would work when my > fingers are in the middle. > In any case, I'll try to adapt to the new world order and I'll reopen if > this is still a problem. > Thanks for the support and detailed feedback. Ok, note that although as said I'm reluctant to change things here, we are very much open to feedback, so if you come to the conclusion that what we currently have in libinput really does not work for you do not hesitate to open this bug and re-raise the issue.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.