<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Add Tap-to-click finger to button mapping support" href="https://bugs.freedesktop.org/show_bug.cgi?id=93531#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Add Tap-to-click finger to button mapping support" href="https://bugs.freedesktop.org/show_bug.cgi?id=93531">bug 93531</a> from <a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>(In reply to Mildred Ki'Lya from <a href="show_bug.cgi?id=93531#c5">comment #5</a>) > 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 <a href="show_bug.cgi?id=93531#c4">comment #4</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>