Re: [RFC] libinput configuration interface
On Thu, Mar 27, 2014 at 07:34:37PM +0600, Alexander E. Patrakov wrote: 2014-03-27 19:22 GMT+06:00 Alexander E. Patrakov patra...@gmail.com: (regarding slow scrolling) I don't think so. I have tried to reproduce the bug by hand. It still exists, but ./tools/event-debug still picks the scrolling up correctly. I guess that this tool output already has the finger motion averaging logic applied, so this speaks against your hypothesis. An interesting observation that can ring some bells: Chromium picks up the scroll events if and only if event-debug prints values whose absolute value is greater than 10. Maybe the driver fails to combine several small scroll events into a big one, or rounds the individual scroll amounts instead of the accumulated value? I have also tested regular (X/Y) pointer motion, and noticed the same pattern. event-debug properly reports sub-pixel motion (i.e. prints values below 1.0 if I move the finger slowly), but such multiple sub-pixel motions are never added up into proper pointer events that actually move the X pointer by at least one pixel. yeah, I found that yesterday and it's a xf86-input-libinput issue. Conversion to integers would just drop small values. I've pushed a fix to use valuator masks with doubles now and that seems to fix the issue. Try 1ab6637b56272bb5cef0568a785e2e5948e6b022. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
hey, sorry about the delay, I got moved to other stuff for a while and only now just picked up libinput again. On Sat, Feb 22, 2014 at 03:33:26PM +0600, Alexander E. Patrakov wrote: 2014-02-21 5:26 GMT+06:00 Peter Hutterer peter.hutte...@who-t.net: On Fri, Feb 21, 2014 at 01:29:05AM +0600, Alexander E. Patrakov wrote: Vertical two-finger scrolling works, but is way too sensitive both with constant deceleration 1.0 and with 0.3. that's a xf86-input-libinput bug, Benjamin fixed that but I forgot to push. 761603d..bee8989 now, please re-test that. The speed is now fixed indeed, but scrolling is now subject to the same dirty mouse bug. See the badscroll.rec file in the attached archive. It contains two scoll gestures - one down, and one up. The driver has picked up only the beginning of the up-scroll (i.e. the chromium window was not scrolled as far as I wanted, even though I continued moving both fingers). I've looked at this and I think I know what you mean. I get a massive jump down first, then a slight up only. Looking at the ./tools/event-debug output from libinput it looks like the coordinates for downward scroll are massive too (between 10 and 48), the upwards ones are hanging around the -3 to -4 mark. That would explain the different scrolling. however, that matches the recordings. I think what may be the problem here is the motion averaging between the fingers. the driver currently takes the changed touchpoints and averages the motion between the two for the actual scroll distance. this may slow down slow scrolls, I'll need to run some tests on this. Tapping and tap-and-drag are not usable. They require not tapping, but knocking with force. So this points to the driver being miscalibrated on the pressure axis. Can this also be the reason of the low x/y sensitivity and dirty mouse feeling? that's a bit odd. I'd like to see an evemu-record output from that then. Currently I ignore pressure completely, so any touch should be detected. Actually the first tap after the server start is detected reliably. The problem only affects other taps. See the file tap-libinput.rec in the attached archive. I had a look at the recording files, mainly with the event-debug tools but I'm struggingling to see the same issues. the tap recording has 6 touches, some of which are taps, others are moves. I can spot three taps in there, one in the middle somewhere, two towards the end and that seems to match the recordings. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
2014-02-21 5:26 GMT+06:00 Peter Hutterer peter.hutte...@who-t.net: On Fri, Feb 21, 2014 at 01:29:05AM +0600, Alexander E. Patrakov wrote: Vertical two-finger scrolling works, but is way too sensitive both with constant deceleration 1.0 and with 0.3. that's a xf86-input-libinput bug, Benjamin fixed that but I forgot to push. 761603d..bee8989 now, please re-test that. The speed is now fixed indeed, but scrolling is now subject to the same dirty mouse bug. See the badscroll.rec file in the attached archive. It contains two scoll gestures - one down, and one up. The driver has picked up only the beginning of the up-scroll (i.e. the chromium window was not scrolled as far as I wanted, even though I continued moving both fingers). Tapping and tap-and-drag are not usable. They require not tapping, but knocking with force. So this points to the driver being miscalibrated on the pressure axis. Can this also be the reason of the low x/y sensitivity and dirty mouse feeling? that's a bit odd. I'd like to see an evemu-record output from that then. Currently I ignore pressure completely, so any touch should be detected. Actually the first tap after the server start is detected reliably. The problem only affects other taps. See the file tap-libinput.rec in the attached archive. -- Alexander E. Patrakov rec2.tar.xz Description: application/xz ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
2014-02-21 5:26 GMT+06:00 Peter Hutterer peter.hutte...@who-t.net:
Touchpad data is always subjective :) it depends on finger size,
conductivity and a whole bunch of other factors. what does help though is
having evemu recordings of certain events. They may still be subjective but
they're reproducible, allowing us to fine-tune based on a specific event
sequence and then go from there.
e.g. you can take a recording fo an example one-finger tap and then make
sure that that always produces a tap event. if you build up a database of
these events, you can cover events quite well for a multitude of devices and
users.
OK. Attached are some sample recordings from my touchpad, while the
synaptics driver is in use (for visual feedback).
left-clicks.rec: 10 left clicks. Any pointer movement is not intended
and should be rejected by the driver.
move-and-double-tap{,2}.rec: contains finger movement to a certain
word on the screen, followed by double-tapping on that word. The
synaptics driver, however, converted one of these into a tap-and-drag.
move-tap-and-drag{,2,3}.rec: contains finger movement to a certain
word on the screen, followed by attempting to select a certain part of
it by tapping and dragging. In one case, contains a non-deliberate
vertical-movement error that led to selecting a line of text.
pretend-close-pidgin.rec: just an attempt to move the pointer to the
center f the close button of Pidgin.
pretend-close-pidgin-bad.rec: the same, but, upon removing the finger,
the synaptics driver picks up unwanted motion. Basically, the last
reported point before removing the finger should have been discarded
as invalid.
scroll-up.rec: scrolling the text up, 10 times.
swipe3-right: some three-finger swipes to the right on a touchpad that
can track only two fingers. Contains BTN_TOOL_TRIPLETAP.
--
Alexander E. Patrakov
rec.tar.xz
Description: application/xz
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
20.02.2014 12:21, I wrote: 20.02.2014 11:14, Peter Hutterer wrote: On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote: From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd say that it doesn't solve the whole problem. Here is what goes wrong with the old synaptics driver by default and can be worked around with AreaBottomEdge. Option SoftButtonAreas 4360 0 4000 0 2880 4359 3500 0 Option AreaBottomEdge 3500 1. I move the right-hand index finger on the touchpad, thus moving the pointer to the place where I want to click. 2. I place the left-hand index finger into the virtual-button area, while still keeping the right finger on the touchpad. I cannot remove the right-hand finger: if I do that, while the contact area shrinks, its center also moves, and the driver picks that up. 3. As I increase the pressure on the left-hand finger until the touchpad clicks, the contact area increases. Unfortunately, its center moves, too, and this can accumulate to ~2-3 pixels until it clicks. The important point is that the bad thing happens before the hardware button click, so the quoted solution totally misses the point. So we need something, either a sledgehammer solution in the form of ignoring all motion in the virtual button area (but that would break Sony Vaio Duo 13 because the only usable height of the virtual button area is 100% there), or some very good filter that pays couple of comments here: 2 is a synaptics bug that should really be fixed, the driver shouldn't be that sensible - in fact there's probably something that can be done about making the driver more sensible while the finger is moving and less sensible while the finger is still (just an idea, may not work for small movements). there is also the option of using pressure to counteract movements, i.e. a pressure change will increase the hysteresis to avoid erroneous movements. If you have that many issues with the Sony, I really recommend looking at the evdev-mt-touchpad patches I sent to this list, it'll allow for things like that relatively simple. OK, I will build this on my laptop from git later today. Just did this, but have not looked at the code yet. Tested with xf86-input-libinput, thus had no chance to configure anything specific to libinput. If this has any chance of yielding different results, I will retest with Weston on Saturday. Software versions: * mtdev 1.1.4 (Gentoo) * xorg-server 1.15.0 (Gentoo) * libevdev from git, cf70d0 * libinput from git, 128f98 + your 19 patches * xf86-input-libinput from git, 761603 Hardware: Sony VAIO Z23A4R, the touchpad identifies itself as follows: I: Bus=0011 Vendor=0002 Product=0007 Version=01b1 N: Name=SynPS/2 Synaptics TouchPad P: Phys=isa0060/serio1/input0 S: Sysfs=/devices/platform/i8042/serio1/input/input4 U: Uniq= H: Handlers=mouse0 event3 B: PROP=5 B: EV=b B: KEY=e520 1 0 0 0 0 B: ABS=66080001103 Pointer movement works, but it is too slow by default on this laptop. That is, a VERY quick swipe (not expected during normal work and even during games) from left to right is just enough to move the pointer across the entire screen (1920x1080). Setting constant deceleration to 0.3 or 0.4 makes it more usable in terms of speed, but this might be my personal preference, and I am not sure if the constant deceleration is the correct knob here. With the default constant deceleration (1.0), pointer movement is very precise. It follows the finger equally well in all parts of the touchpad and in all directions, as expected. I get no misplaced clicks. With constant deceleration 0.3, this is not true. It works better in the central part of the touchpad, but, when crossing the physical border between the area for pointer movement (which is rough) and the area for virtual buttons (which is smooth), it starts to behave like a dirty mechanical mouse. Here is what I mean by that: hard to move the cursor diagonally (i.e. there is a strong preference towards horizontal or vertical movements), and the motion is uneven if I move the finger slowly. The same applies to the top part of the touchpad, although there is no sharp line where this appears. In both cases, there is no spurious pointer movement when putting the finger on the touchpad or removing it. I.e., points 2 and 3 are somehow already dealt with. Vertical two-finger scrolling works, but is way too sensitive both with constant deceleration 1.0 and with 0.3. Clicking works. If there are two fingers on the touchpad at the time of clicking, it registers a right-click. As the touchpad cannot track more than two touches, three-finger gestures don't work. OTOH, I have read Documentation/input/multi-touch-protocol.txt: Some devices identify and/or track more contacts than they can report to the driver. I have not yet tested whether this applies to my touchpad, and whether it uses BTN_TOOL_TRIPLETAP. Tapping and tap-and-drag are not usable. They
Re: [RFC] libinput configuration interface
On Fri, Feb 21, 2014 at 01:29:05AM +0600, Alexander E. Patrakov wrote: 20.02.2014 12:21, I wrote: 20.02.2014 11:14, Peter Hutterer wrote: On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote: From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd say that it doesn't solve the whole problem. Here is what goes wrong with the old synaptics driver by default and can be worked around with AreaBottomEdge. Option SoftButtonAreas 4360 0 4000 0 2880 4359 3500 0 Option AreaBottomEdge 3500 1. I move the right-hand index finger on the touchpad, thus moving the pointer to the place where I want to click. 2. I place the left-hand index finger into the virtual-button area, while still keeping the right finger on the touchpad. I cannot remove the right-hand finger: if I do that, while the contact area shrinks, its center also moves, and the driver picks that up. 3. As I increase the pressure on the left-hand finger until the touchpad clicks, the contact area increases. Unfortunately, its center moves, too, and this can accumulate to ~2-3 pixels until it clicks. The important point is that the bad thing happens before the hardware button click, so the quoted solution totally misses the point. So we need something, either a sledgehammer solution in the form of ignoring all motion in the virtual button area (but that would break Sony Vaio Duo 13 because the only usable height of the virtual button area is 100% there), or some very good filter that pays couple of comments here: 2 is a synaptics bug that should really be fixed, the driver shouldn't be that sensible - in fact there's probably something that can be done about making the driver more sensible while the finger is moving and less sensible while the finger is still (just an idea, may not work for small movements). there is also the option of using pressure to counteract movements, i.e. a pressure change will increase the hysteresis to avoid erroneous movements. If you have that many issues with the Sony, I really recommend looking at the evdev-mt-touchpad patches I sent to this list, it'll allow for things like that relatively simple. OK, I will build this on my laptop from git later today. Just did this, but have not looked at the code yet. Tested with xf86-input-libinput, thus had no chance to configure anything specific to libinput. If this has any chance of yielding different results, I will retest with Weston on Saturday. libinput currently exposes no configuration interfaces, so the only differences you may see is in pointer acceleration. Software versions: * mtdev 1.1.4 (Gentoo) * xorg-server 1.15.0 (Gentoo) * libevdev from git, cf70d0 * libinput from git, 128f98 + your 19 patches * xf86-input-libinput from git, 761603 Hardware: Sony VAIO Z23A4R, the touchpad identifies itself as follows: I: Bus=0011 Vendor=0002 Product=0007 Version=01b1 N: Name=SynPS/2 Synaptics TouchPad P: Phys=isa0060/serio1/input0 S: Sysfs=/devices/platform/i8042/serio1/input/input4 U: Uniq= H: Handlers=mouse0 event3 B: PROP=5 B: EV=b B: KEY=e520 1 0 0 0 0 B: ABS=66080001103 Pointer movement works, but it is too slow by default on this laptop. That is, a VERY quick swipe (not expected during normal work and even during games) from left to right is just enough to move the pointer across the entire screen (1920x1080). Setting constant deceleration to 0.3 or 0.4 makes it more usable in terms of speed, but this might be my personal preference, and I am not sure if the constant deceleration is the correct knob here. I have not yet looked into pointer-accel fine-tuning on the touchpad or in xf86-input-libinput. What you're seeing is quite simliar to what I have here - it's slow but not unusable. Sorry, just haven't focused on that yet by any help would be appreciated. I don't think deceleration is the right nob here, but I can't remember what you need to tweak. Generally I try not to touch constant deceleration unless the device is a high-resolution device that sends way too many events. If you need to use a value 0..1 for CD then you're effectively using it to speed things up, the term deceleration should hint that this may not work perfectly :) With the default constant deceleration (1.0), pointer movement is very precise. It follows the finger equally well in all parts of the touchpad and in all directions, as expected. I get no misplaced clicks. With constant deceleration 0.3, this is not true. It works better in the central part of the touchpad, but, when crossing the physical border between the area for pointer movement (which is rough) and the area for virtual buttons (which is smooth), it starts to behave like a dirty mechanical mouse. Here is what I mean by that: hard to move the cursor diagonally (i.e. there is a strong preference towards horizontal or vertical movements), and the motion is uneven if I move the
Re: [RFC] libinput configuration interface
On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote: 19.02.2014 04:52, Peter Hutterer wrote: The set of touchpad patches I sent out recently already handle this by default. When the physical clickpad button is depressed, the driver picks the finger that is pressing the button (sometimes guessing, but hey...). That finger cannot control the pointer movement until the button is released again. In your specific use case, the driver would see two touchpoints and it will select the one closer to the bottom edge as the pressing finger (i.e. your thumb). The index finger can still move while the button is down. From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd say that it doesn't solve the whole problem. Here is what goes wrong with the old synaptics driver by default and can be worked around with AreaBottomEdge. Option SoftButtonAreas 4360 0 4000 0 2880 4359 3500 0 Option AreaBottomEdge 3500 1. I move the right-hand index finger on the touchpad, thus moving the pointer to the place where I want to click. 2. I place the left-hand index finger into the virtual-button area, while still keeping the right finger on the touchpad. I cannot remove the right-hand finger: if I do that, while the contact area shrinks, its center also moves, and the driver picks that up. 3. As I increase the pressure on the left-hand finger until the touchpad clicks, the contact area increases. Unfortunately, its center moves, too, and this can accumulate to ~2-3 pixels until it clicks. The important point is that the bad thing happens before the hardware button click, so the quoted solution totally misses the point. So we need something, either a sledgehammer solution in the form of ignoring all motion in the virtual button area (but that would break Sony Vaio Duo 13 because the only usable height of the virtual button area is 100% there), or some very good filter that pays can you expand on the 100% comment here? is the touchpad too small for anything else? attention to changes in pressure and filters any spurious movement (i.e. any movement that is combined with significant pressure changes) out. But hey, Sony in their new laptops started to ignore the problem under Windows, too, so I think I just have to swallow this and/or use my Bluetooth mouse. couple of comments here: 2 is a synaptics bug that should really be fixed, the driver shouldn't be that sensible - in fact there's probably something that can be done about making the driver more sensible while the finger is moving and less sensible while the finger is still (just an idea, may not work for small movements). there is also the option of using pressure to counteract movements, i.e. a pressure change will increase the hysteresis to avoid erroneous movements. If you have that many issues with the Sony, I really recommend looking at the evdev-mt-touchpad patches I sent to this list, it'll allow for things like that relatively simple. the xorg synaptics driver has for historical reasons and portability a different approach to finger tracking and some of the misbehaviours are easier to fix now. The proposed patches have a different approach to the above: 1 - would be recognised as touchpoint, since no other finger is active it is designated as the pointer-moving touchpoint 2 - second finger recognised, but not assigned as pointer-moving. Movements on that finger have no effect, unless 2-finger scrolling is triggered. 3 - no effect, finger is not moving So really, the goal here is that whatever the motion we see in 2 and 3 is to not go past the trigger 2-finger scrolling threshold. I do have a set of patches not yet ported for the virtual buttons and they add additional tracking, so that a finger that starts (and stays) inside a softbutton area won't contribute to movements, but as you said above that may not work with the vaio. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
On Thu, Feb 20, 2014 at 12:21:53PM +0600, Alexander E. Patrakov wrote: 20.02.2014 11:14, Peter Hutterer wrote: On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote: 19.02.2014 04:52, Peter Hutterer wrote: The set of touchpad patches I sent out recently already handle this by default. When the physical clickpad button is depressed, the driver picks the finger that is pressing the button (sometimes guessing, but hey...). That finger cannot control the pointer movement until the button is released again. In your specific use case, the driver would see two touchpoints and it will select the one closer to the bottom edge as the pressing finger (i.e. your thumb). The index finger can still move while the button is down. From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd say that it doesn't solve the whole problem. Here is what goes wrong with the old synaptics driver by default and can be worked around with AreaBottomEdge. Option SoftButtonAreas 4360 0 4000 0 2880 4359 3500 0 Option AreaBottomEdge 3500 1. I move the right-hand index finger on the touchpad, thus moving the pointer to the place where I want to click. 2. I place the left-hand index finger into the virtual-button area, while still keeping the right finger on the touchpad. I cannot remove the right-hand finger: if I do that, while the contact area shrinks, its center also moves, and the driver picks that up. 3. As I increase the pressure on the left-hand finger until the touchpad clicks, the contact area increases. Unfortunately, its center moves, too, and this can accumulate to ~2-3 pixels until it clicks. The important point is that the bad thing happens before the hardware button click, so the quoted solution totally misses the point. So we need something, either a sledgehammer solution in the form of ignoring all motion in the virtual button area (but that would break Sony Vaio Duo 13 because the only usable height of the virtual button area is 100% there), or some very good filter that pays can you expand on the 100% comment here? is the touchpad too small for anything else? The height of the touchpad is too small (the width is OK). See e.g. http://www.blogcdn.com/www.engadget.com/media/2013/06/dsc00149-1370365891.jpg (Just to avoid confusion: I have a Sony Vaio Z23A4R, don't have a Sony Vaio Duo 13, and don't have a Sony Vaio Pro 13. As for my accent on Sony laptops, that's only because there is a Sony shop nearby.) quite frankly, I think this touchpad is one where you (the user) would have to get used to tap-and-drag and two-finger tapping or two-finger clicking instead virtual button areas. I think that'd be a much better fit for a touchpad like this. Cheers, Peter attention to changes in pressure and filters any spurious movement (i.e. any movement that is combined with significant pressure changes) out. But hey, Sony in their new laptops started to ignore the problem under Windows, too, so I think I just have to swallow this and/or use my Bluetooth mouse. couple of comments here: 2 is a synaptics bug that should really be fixed, the driver shouldn't be that sensible - in fact there's probably something that can be done about making the driver more sensible while the finger is moving and less sensible while the finger is still (just an idea, may not work for small movements). there is also the option of using pressure to counteract movements, i.e. a pressure change will increase the hysteresis to avoid erroneous movements. If you have that many issues with the Sony, I really recommend looking at the evdev-mt-touchpad patches I sent to this list, it'll allow for things like that relatively simple. OK, I will build this on my laptop from git later today. the xorg synaptics driver has for historical reasons and portability a different approach to finger tracking and some of the misbehaviours are easier to fix now. The proposed patches have a different approach to the above: 1 - would be recognised as touchpoint, since no other finger is active it is designated as the pointer-moving touchpoint 2 - second finger recognised, but not assigned as pointer-moving. Movements on that finger have no effect, unless 2-finger scrolling is triggered. 3 - no effect, finger is not moving So really, the goal here is that whatever the motion we see in 2 and 3 is to not go past the trigger 2-finger scrolling threshold. Yes, I think we agree on that. I do have a set of patches not yet ported for the virtual buttons and they add additional tracking, so that a finger that starts (and stays) inside a softbutton area won't contribute to movements, but as you said above that may not work with the vaio. Yes, I would like to see that on my Z23A4R (and it matches the Windows default), but users of Duo 13 definitely would not want that enabled on their laptops. As for Sony Vaio Pro 13, this
Re: [RFC] libinput configuration interface
On Mon, 03 Feb 2014 11:02:42 +1000, Peter Hutterer wrote: tbh, I'm not planning to support every potential option under the sun. There's a fine and rather blurry line between what is a preference and what is merely configuration because we can't commit to a single default. I'd rather have less configuration options and support those well and do the synaptics approach of supporting everything but being quite bad at how the various options interact. snip As for the softbuttons config items, I'm somewhat leaning towards finger movement in the button areas, but no clicks outside the button area. And to actually trigger a button, you need to start inside the button area - which becomes easier when you have proper finger tracking (synaptics currently doesn't). Does that imply the following use case will be supported? Being used to TP trackpoints, I am using the index finger outside the button area (on a touchpad that doubles as one hardware button) and the thumb to click. I'd expect to able to move the pointer with the index finger while clicking, disregarding slight thumb movements while doing so. This seems to very difficult to archieve (if at all) with the synaptics driver; the points jumps widely, especially if the index finger is removed from the touch pad immediately before clicking. I can imagine that this boils down to having areas insensitive to motion, but still working as softbuttons. Dominic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
On Tue, Feb 18, 2014 at 04:33:53PM +, Dominic Jänichen wrote: On Mon, 03 Feb 2014 11:02:42 +1000, Peter Hutterer wrote: tbh, I'm not planning to support every potential option under the sun. There's a fine and rather blurry line between what is a preference and what is merely configuration because we can't commit to a single default. I'd rather have less configuration options and support those well and do the synaptics approach of supporting everything but being quite bad at how the various options interact. snip As for the softbuttons config items, I'm somewhat leaning towards finger movement in the button areas, but no clicks outside the button area. And to actually trigger a button, you need to start inside the button area - which becomes easier when you have proper finger tracking (synaptics currently doesn't). Does that imply the following use case will be supported? Being used to TP trackpoints, I am using the index finger outside the button area (on a touchpad that doubles as one hardware button) and the thumb to click. I'd expect to able to move the pointer with the index finger while clicking, disregarding slight thumb movements while doing so. This seems to very difficult to archieve (if at all) with the synaptics driver; the points jumps widely, especially if the index finger is removed from the touch pad immediately before clicking. I can imagine that this boils down to having areas insensitive to motion, but still working as softbuttons. The set of touchpad patches I sent out recently already handle this by default. When the physical clickpad button is depressed, the driver picks the finger that is pressing the button (sometimes guessing, but hey...). That finger cannot control the pointer movement until the button is released again. In your specific use case, the driver would see two touchpoints and it will select the one closer to the bottom edge as the pressing finger (i.e. your thumb). The index finger can still move while the button is down. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
19.02.2014 04:52, Peter Hutterer wrote: The set of touchpad patches I sent out recently already handle this by default. When the physical clickpad button is depressed, the driver picks the finger that is pressing the button (sometimes guessing, but hey...). That finger cannot control the pointer movement until the button is released again. In your specific use case, the driver would see two touchpoints and it will select the one closer to the bottom edge as the pressing finger (i.e. your thumb). The index finger can still move while the button is down. From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd say that it doesn't solve the whole problem. Here is what goes wrong with the old synaptics driver by default and can be worked around with AreaBottomEdge. Option SoftButtonAreas 4360 0 4000 0 2880 4359 3500 0 Option AreaBottomEdge 3500 1. I move the right-hand index finger on the touchpad, thus moving the pointer to the place where I want to click. 2. I place the left-hand index finger into the virtual-button area, while still keeping the right finger on the touchpad. I cannot remove the right-hand finger: if I do that, while the contact area shrinks, its center also moves, and the driver picks that up. 3. As I increase the pressure on the left-hand finger until the touchpad clicks, the contact area increases. Unfortunately, its center moves, too, and this can accumulate to ~2-3 pixels until it clicks. The important point is that the bad thing happens before the hardware button click, so the quoted solution totally misses the point. So we need something, either a sledgehammer solution in the form of ignoring all motion in the virtual button area (but that would break Sony Vaio Duo 13 because the only usable height of the virtual button area is 100% there), or some very good filter that pays attention to changes in pressure and filters any spurious movement (i.e. any movement that is combined with significant pressure changes) out. But hey, Sony in their new laptops started to ignore the problem under Windows, too, so I think I just have to swallow this and/or use my Bluetooth mouse. -- Alexander E. Patrakov ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
On Sun, Feb 09, 2014 at 01:32:41PM +0100, Eugen Friedrich wrote: On 09.02.2014 05:10, Peter Hutterer wrote: On Thu, Feb 06, 2014 at 11:28:49PM +0100, Eugen Friedrich wrote: Hi together, i would like to put some input from the embedded/ automotive perspective. you can think about huge amount of different configurations for different device types. A lot of configuration in the initial post deals with behavior of buttons and scrolling areas of the touch panels. The good approach could be a kind of general configuration of button and scrolling areas of the touch panels the button area could contain a position and dimension of the button in the device coordinate system and the button code the slider area could contain a position and dimension of the slider along with the range. generally for real touch screens (i.e. not touchpads) I think any interpretation of the valthis should IMO be handled by the compositorues should be on the client side, not in the input library. There just isn't enough context to interpret it otherwise since you're at least partially reliant on UI hints or other elements to make sure you're emulating the right thing. Completely agree, active input elements which are drawn by some application should be handled by this application. For specialized cases like having a permanent input region that maps into semantic buttons (e.g. the button bar on the Android phones) this should IMO be handled by the compositor. Yes this was the aim of my proposal. This would give a flexibility to use different touch panel with different screens and put you permanent buttons and slider wherever you like. Such cases are maybe only important if you are building up a new devices but this configuration possibility would add a big value for the libinput. my main worry here is that the semantics of such buttons are unknown to anyone but the compositor. libinput has _no_ semantics other than here's and area but especially with direct-touch devices you get more complex interactions to this. For example, let's say we have a defined button area at the bottom of the screen: - should the button trigger if the finger moved from the outside into the area? - should the button trigger if the finger left and re-entered the area? - should the button trigger if the finger left the area? -- oh, btw, now you need enter/leave events to notify the compositor - should the button trigger if there is another finger within the area? - should the button trigger if there was extensive movement between press/release in the button area? .. All these usually have fairly obvious answers from a UI perspective, but a low-level library without semantic context would have to provide some matrix to enable all of them or restrict itself to a set of the above. The latter wouldn't be a problem, but we'd have to really see some good use-cases to justify the extra complexity. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinput configuration interface
On Thu, Feb 06, 2014 at 11:28:49PM +0100, Eugen Friedrich wrote:
Hi together,
i would like to put some input from the embedded/ automotive perspective.
you can think about huge amount of different configurations for different
device types.
A lot of configuration in the initial post deals with behavior of buttons
and scrolling
areas of the touch panels.
The good approach could be a kind of general configuration of button and
scrolling areas of the touch panels
the button area could contain a position and dimension of the button in the
device coordinate system and the button code
the slider area could contain a position and dimension of the slider along
with the range.
generally for real touch screens (i.e. not touchpads) I think any
interpretation of the values should be on the client side, not in the input
library. There just isn't enough context to interpret it otherwise since
you're at least partially reliant on UI hints or other elements to make sure
you're emulating the right thing.
For specialized cases like having a permanent input region that maps into
semantic buttons (e.g. the button bar on the Android phones) this should IMO
be handled by the compositor.
Also the weston code contains calibration of the absolute values.
It would be good also to have a calibration possibilities in libinput.
Yes, calibration is a required feature, I forgot to mention that since it's
already supported.
Cheers,
Peter
What do you think?
2014-02-03 6:11 GMT+01:00 Alexander E. Patrakov patra...@gmail.com:
2014-02-03 Peter Hutterer peter.hutte...@who-t.net:
On Fri, Jan 31, 2014 at 08:26:54PM +0600, Alexander E. Patrakov wrote:
Peter Hutterer wrote:
I've been thinking about how to add a device configuration interface
to
libinput, and after getting feedback from Jonas and Benjamin, here's a
proposal (no code yet).
First, I think the configuration should be feature-specific, not
device
specific, so it is independent of a classification or capabilities of
a
device. To the user it doesn't matter if we classify something as
touchpad
or as mouse, if middle mouse button emulation works that's the only
thing
that counts. At least for configuration purposes, this also avoids the
difficult task of classifying a device correctly. Those pesky HW
manufacturers do have a habit of coming up with devices that elude
previously agreed-on classification schemes, e.g. mice with touchpads
on
them.
Aside from setting an item, there should be calls to get the current
value,
and a call to reset to the built-in defaults. And, since we're
feature-based, a call to check if the config item is possible for a
device.
Which leads us the the following quartet for each item:
int libinput_device_config_set_foo(device, value);
int libinput_device_config_get_foo(device, value);
int libinput_device_config_reset_foo(device);
bool libinput_device_config_has_foo(device);
And the actual configuration items I've come up with so far:
* {set|get|reset|has}_tap_single_finger_button
* tap_double_finger_button
* tap_triple_finger_button
* click_finger_single
* click_finger_double
* click_finger_triple
* twofinger_scroll_vertical
* twofinger_scroll_horizonal
* edge_scroll_vertical
* edge_scroll_horizontal
* disable_while_typing
* disable_touch (while pen is in use)
these two could be merged into disable while linked device is in
use
* softbutton_left
* softbutton_middle
* softbutton_right
* emulate_middle_button
* button_mapping
* emulate_wheel
* rotation
* palm_detection
* mode (relative/absolute)
* valid_area
This is needed on tablets that have a different ratio than the
monitor.
Mapping them to the monitor results in uneven x/y movements, so the
easiest approach here is to cut a portion of the tablet off to
match the
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a
right-button
click is to hold the right button down and then tip with the stylus.
Note that the above is not a 1:1 API mapping, e.g. tapping
configuration
could be an API taking nfingers as argument as opposed to 3 different
calls.
Likewise, they can take more than one value argument, e.g. middle
button
emulation could take a boolean to enable it, and a timeout.
This list excludes options we currently have in the X drivers to
adjust for
hw-specific quirks. Such as defining which pressure makes up a tap,
etc. I
really hope this is something we can work out based on the device.
It also excludes configurations that I'd really like to hide away if
possible. For example, on the new T440-style touchpads the top part
of it is
a set of buttons for the trackstick. There's nothing to
Re: [RFC] libinput configuration interface
Hi together,
i would like to put some input from the embedded/ automotive perspective.
you can think about huge amount of different configurations for different
device types.
A lot of configuration in the initial post deals with behavior of buttons
and scrolling
areas of the touch panels.
The good approach could be a kind of general configuration of button and
scrolling areas of the touch panels
the button area could contain a position and dimension of the button in the
device coordinate system and the button code
the slider area could contain a position and dimension of the slider along
with the range.
Also the weston code contains calibration of the absolute values.
It would be good also to have a calibration possibilities in libinput.
What do you think?
2014-02-03 6:11 GMT+01:00 Alexander E. Patrakov patra...@gmail.com:
2014-02-03 Peter Hutterer peter.hutte...@who-t.net:
On Fri, Jan 31, 2014 at 08:26:54PM +0600, Alexander E. Patrakov wrote:
Peter Hutterer wrote:
I've been thinking about how to add a device configuration interface
to
libinput, and after getting feedback from Jonas and Benjamin, here's a
proposal (no code yet).
First, I think the configuration should be feature-specific, not
device
specific, so it is independent of a classification or capabilities of
a
device. To the user it doesn't matter if we classify something as
touchpad
or as mouse, if middle mouse button emulation works that's the only
thing
that counts. At least for configuration purposes, this also avoids the
difficult task of classifying a device correctly. Those pesky HW
manufacturers do have a habit of coming up with devices that elude
previously agreed-on classification schemes, e.g. mice with touchpads
on
them.
Aside from setting an item, there should be calls to get the current
value,
and a call to reset to the built-in defaults. And, since we're
feature-based, a call to check if the config item is possible for a
device.
Which leads us the the following quartet for each item:
int libinput_device_config_set_foo(device, value);
int libinput_device_config_get_foo(device, value);
int libinput_device_config_reset_foo(device);
bool libinput_device_config_has_foo(device);
And the actual configuration items I've come up with so far:
* {set|get|reset|has}_tap_single_finger_button
* tap_double_finger_button
* tap_triple_finger_button
* click_finger_single
* click_finger_double
* click_finger_triple
* twofinger_scroll_vertical
* twofinger_scroll_horizonal
* edge_scroll_vertical
* edge_scroll_horizontal
* disable_while_typing
* disable_touch (while pen is in use)
these two could be merged into disable while linked device is in
use
* softbutton_left
* softbutton_middle
* softbutton_right
* emulate_middle_button
* button_mapping
* emulate_wheel
* rotation
* palm_detection
* mode (relative/absolute)
* valid_area
This is needed on tablets that have a different ratio than the
monitor.
Mapping them to the monitor results in uneven x/y movements, so the
easiest approach here is to cut a portion of the tablet off to
match the
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a
right-button
click is to hold the right button down and then tip with the stylus.
Note that the above is not a 1:1 API mapping, e.g. tapping
configuration
could be an API taking nfingers as argument as opposed to 3 different
calls.
Likewise, they can take more than one value argument, e.g. middle
button
emulation could take a boolean to enable it, and a timeout.
This list excludes options we currently have in the X drivers to
adjust for
hw-specific quirks. Such as defining which pressure makes up a tap,
etc. I
really hope this is something we can work out based on the device.
It also excludes configurations that I'd really like to hide away if
possible. For example, on the new T440-style touchpads the top part
of it is
a set of buttons for the trackstick. There's nothing to be configured
about
this, it should just work.
Comments? Does this sound sane enough? Anything important I've missed?
You missed our disagreement from August about whether finger movement
in the
softbutton area should move the pointer (I suggested that it shouldn't,
you
suggested that it should, and both of us had valid arguments, so it
needs to
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button
clickpad
if a hardware button reports that it is clicked, but there is no finger
in any
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click
(would
be my preference), treat this as left
Re: [RFC] libinput configuration interface
2014-02-03 Peter Hutterer peter.hutte...@who-t.net:
On Fri, Jan 31, 2014 at 08:26:54PM +0600, Alexander E. Patrakov wrote:
Peter Hutterer wrote:
I've been thinking about how to add a device configuration interface to
libinput, and after getting feedback from Jonas and Benjamin, here's a
proposal (no code yet).
First, I think the configuration should be feature-specific, not device
specific, so it is independent of a classification or capabilities of a
device. To the user it doesn't matter if we classify something as touchpad
or as mouse, if middle mouse button emulation works that's the only thing
that counts. At least for configuration purposes, this also avoids the
difficult task of classifying a device correctly. Those pesky HW
manufacturers do have a habit of coming up with devices that elude
previously agreed-on classification schemes, e.g. mice with touchpads on
them.
Aside from setting an item, there should be calls to get the current value,
and a call to reset to the built-in defaults. And, since we're
feature-based, a call to check if the config item is possible for a device.
Which leads us the the following quartet for each item:
int libinput_device_config_set_foo(device, value);
int libinput_device_config_get_foo(device, value);
int libinput_device_config_reset_foo(device);
bool libinput_device_config_has_foo(device);
And the actual configuration items I've come up with so far:
* {set|get|reset|has}_tap_single_finger_button
* tap_double_finger_button
* tap_triple_finger_button
* click_finger_single
* click_finger_double
* click_finger_triple
* twofinger_scroll_vertical
* twofinger_scroll_horizonal
* edge_scroll_vertical
* edge_scroll_horizontal
* disable_while_typing
* disable_touch (while pen is in use)
these two could be merged into disable while linked device is in use
* softbutton_left
* softbutton_middle
* softbutton_right
* emulate_middle_button
* button_mapping
* emulate_wheel
* rotation
* palm_detection
* mode (relative/absolute)
* valid_area
This is needed on tablets that have a different ratio than the monitor.
Mapping them to the monitor results in uneven x/y movements, so the
easiest approach here is to cut a portion of the tablet off to match the
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a right-button
click is to hold the right button down and then tip with the stylus.
Note that the above is not a 1:1 API mapping, e.g. tapping configuration
could be an API taking nfingers as argument as opposed to 3 different
calls.
Likewise, they can take more than one value argument, e.g. middle button
emulation could take a boolean to enable it, and a timeout.
This list excludes options we currently have in the X drivers to adjust for
hw-specific quirks. Such as defining which pressure makes up a tap, etc. I
really hope this is something we can work out based on the device.
It also excludes configurations that I'd really like to hide away if
possible. For example, on the new T440-style touchpads the top part of it
is
a set of buttons for the trackstick. There's nothing to be configured about
this, it should just work.
Comments? Does this sound sane enough? Anything important I've missed?
You missed our disagreement from August about whether finger movement in the
softbutton area should move the pointer (I suggested that it shouldn't, you
suggested that it should, and both of us had valid arguments, so it needs to
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button
clickpad
if a hardware button reports that it is clicked, but there is no finger in
any
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click (would
be my preference), treat this as left click (current situation with the
synaptics driver, and I guess some people would prefer this).
tbh, I'm not planning to support every potential option under the sun.
There's a fine and rather blurry line between what is a preference and what
is merely configuration because we can't commit to a single default. I'd
rather have less configuration options and support those well and do the
synaptics approach of supporting everything but being quite bad at how the
various options interact.
To extend this thought, even the list above is probably too detailed.
IMO tapping should just be a left, right, middle configuration for 1, 2, 3
fingers. Enabling/disabling tapping is a valid configuration but custom
button mapping is excessive (clickfinger is the same).
Likewise, there should be only one scroll method at a time, and one option
to enable horizontal for that scroll method - no two-finger vertical and
edge-horizontal
Re: [RFC] libinput configuration interface
Peter Hutterer wrote:
I've been thinking about how to add a device configuration interface to
libinput, and after getting feedback from Jonas and Benjamin, here's a
proposal (no code yet).
First, I think the configuration should be feature-specific, not device
specific, so it is independent of a classification or capabilities of a
device. To the user it doesn't matter if we classify something as touchpad
or as mouse, if middle mouse button emulation works that's the only thing
that counts. At least for configuration purposes, this also avoids the
difficult task of classifying a device correctly. Those pesky HW
manufacturers do have a habit of coming up with devices that elude
previously agreed-on classification schemes, e.g. mice with touchpads on
them.
Aside from setting an item, there should be calls to get the current value,
and a call to reset to the built-in defaults. And, since we're
feature-based, a call to check if the config item is possible for a device.
Which leads us the the following quartet for each item:
int libinput_device_config_set_foo(device, value);
int libinput_device_config_get_foo(device, value);
int libinput_device_config_reset_foo(device);
bool libinput_device_config_has_foo(device);
And the actual configuration items I've come up with so far:
* {set|get|reset|has}_tap_single_finger_button
* tap_double_finger_button
* tap_triple_finger_button
* click_finger_single
* click_finger_double
* click_finger_triple
* twofinger_scroll_vertical
* twofinger_scroll_horizonal
* edge_scroll_vertical
* edge_scroll_horizontal
* disable_while_typing
* disable_touch (while pen is in use)
these two could be merged into disable while linked device is in use
* softbutton_left
* softbutton_middle
* softbutton_right
* emulate_middle_button
* button_mapping
* emulate_wheel
* rotation
* palm_detection
* mode (relative/absolute)
* valid_area
This is needed on tablets that have a different ratio than the monitor.
Mapping them to the monitor results in uneven x/y movements, so the
easiest approach here is to cut a portion of the tablet off to match the
ratio.
* stylus_button_behaviour(some enum)
Some tablets don't report proximity, the only way to get a right-button
click is to hold the right button down and then tip with the stylus.
Note that the above is not a 1:1 API mapping, e.g. tapping configuration
could be an API taking nfingers as argument as opposed to 3 different calls.
Likewise, they can take more than one value argument, e.g. middle button
emulation could take a boolean to enable it, and a timeout.
This list excludes options we currently have in the X drivers to adjust for
hw-specific quirks. Such as defining which pressure makes up a tap, etc. I
really hope this is something we can work out based on the device.
It also excludes configurations that I'd really like to hide away if
possible. For example, on the new T440-style touchpads the top part of it is
a set of buttons for the trackstick. There's nothing to be configured about
this, it should just work.
Comments? Does this sound sane enough? Anything important I've missed?
You missed our disagreement from August about whether finger movement in the
softbutton area should move the pointer (I suggested that it shouldn't, you
suggested that it should, and both of us had valid arguments, so it needs to
be configurable). Also it was not clearly articulated then, but still, a
potential disagreement/configuration point: what to do on a one-button clickpad
if a hardware button reports that it is clicked, but there is no finger in any
softbutton area (i.e. a clickpad is clicked outside of the designated
softbutton area)? Possible options: ignore the apparently-false click (would
be my preference), treat this as left click (current situation with the
synaptics driver, and I guess some people would prefer this).
Also I don't see how the suggested interface covers the ChromeBook-style
clickpad configuration where there should be no softbuttons and the only way to
right-click is to use two fingers.
--
Alexander E. Patrakov
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
