Re: elantech-v4 clickpad support
On 03/02/15(Tue) 22:36, Ulf Brosziewski wrote:
On 01/30/2015 11:04 AM, Ulf Brosziewski wrote:
On 01/30/2015 07:15 AM, Martin Pieuchot wrote:
On 30/01/15(Fri) 01:25, Ulf Brosziewski wrote:
Probably I was too sceptical about synaptics.c. The bug I observed
with the ALPS touchpad seems to be due to a kind of mismatch between
the ALPS code in pms and the event handling in wsconscomm. The patch
below contains the initial change as well as what was necessary to
fix this.
Do you think it is possible to fix the pms(4) driver instead of adding
another quirk?
...
Certainly that would be a better solution. For synaptics hardware there
seems to be no specific W value that signals the end of a touch. If I
understand it correctly, the hardware reports zero coordinates instead
and the X driver adjusts its state accordingly. I will try to check soon
whether this is correct and whether the ALPS code could be adapted.
I couldn't test it directly, but according to the Synaptics PS/2 TouchPad
Interfacing Guide synaptics hardware does indeed signal a W value of 0 if
there is no pressure as well as for two-finger contacts. This means that
the ALPS part of pms is correct and shouldn't be changed. For a proper
finger count Z must be checked, and the place to do this is probably in
wsconscomm. I have changed the patch accordingly.
The change in the new version applies to all touchpad/clickpad models and
would require appropriate testing. In my own tests with the ALPS Glidepoint
touchpad and the Elantech Clickpad - and the patched pms version - I didn't
observe any problems.
I'm running with this diff on a pms0: Synaptics clickpad, firmware
8.0. I'm seeing no problem with it, and it seems to improve the
two-finger scrolling situation where previously the cursor would go
crazy.
Since it has been tested on various Synaptics, ALPS and Elantech I think
it is safe to put it in.
Anybody wants to ok this diff?
Btw Ulf, it seems your mail client mangles tab/space. I couldn't apply
your diff correctly :/
diff --git a/wsconscomm.c b/wsconscomm.c
index df3512d..70c103a 100644
--- a/wsconscomm.c
+++ b/wsconscomm.c
@@ -132,12 +132,6 @@ WSConsReadHwState(InputInfoPtr pInfo,
struct wscons_event event;
Bool v;
-/* Reset cumulative values if buttons were not previously pressed */
-if (!hw-left !hw-right !hw-middle) {
-hw-cumulative_dx = hw-x;
-hw-cumulative_dy = hw-y;
-}
-
while (WSConsReadEvent(pInfo, event)) {
switch (event.type) {
case WSCONS_EVENT_MOUSE_UP:
@@ -187,9 +181,11 @@ WSConsReadHwState(InputInfoPtr pInfo,
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_X:
hw-x = event.value;
+hw-cumulative_dx = hw-x;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Y:
hw-y = priv-maxy - event.value + priv-miny;
+hw-cumulative_dy = hw-y;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Z:
hw-z = event.value;
@@ -218,6 +214,10 @@ WSConsReadHwState(InputInfoPtr pInfo,
}
break;
case WSCONS_EVENT_SYNC:
+if (hw-z == 0) {
+hw-fingerWidth = 0;
+hw-numFingers = 0;
+}
hw-millis = 1000 * event.time.tv_sec + event.time.tv_nsec /
100;
SynapticsCopyHwState(hwRet, hw);
return TRUE;
Re: elantech-v4 clickpad support
On 01/30/2015 11:04 AM, Ulf Brosziewski wrote:
On 01/30/2015 07:15 AM, Martin Pieuchot wrote:
On 30/01/15(Fri) 01:25, Ulf Brosziewski wrote:
Probably I was too sceptical about synaptics.c. The bug I observed
with the ALPS touchpad seems to be due to a kind of mismatch between
the ALPS code in pms and the event handling in wsconscomm. The patch
below contains the initial change as well as what was necessary to
fix this.
Do you think it is possible to fix the pms(4) driver instead of adding
another quirk?
...
Certainly that would be a better solution. For synaptics hardware there
seems to be no specific W value that signals the end of a touch. If I
understand it correctly, the hardware reports zero coordinates instead
and the X driver adjusts its state accordingly. I will try to check soon
whether this is correct and whether the ALPS code could be adapted.
I couldn't test it directly, but according to the Synaptics PS/2 TouchPad
Interfacing Guide synaptics hardware does indeed signal a W value of 0 if
there is no pressure as well as for two-finger contacts. This means that
the ALPS part of pms is correct and shouldn't be changed. For a proper
finger count Z must be checked, and the place to do this is probably in
wsconscomm. I have changed the patch accordingly.
The change in the new version applies to all touchpad/clickpad models and
would require appropriate testing. In my own tests with the ALPS Glidepoint
touchpad and the Elantech Clickpad - and the patched pms version - I didn't
observe any problems.
diff --git a/wsconscomm.c b/wsconscomm.c
index df3512d..70c103a 100644
--- a/wsconscomm.c
+++ b/wsconscomm.c
@@ -132,12 +132,6 @@ WSConsReadHwState(InputInfoPtr pInfo,
struct wscons_event event;
Bool v;
-/* Reset cumulative values if buttons were not previously pressed */
-if (!hw-left !hw-right !hw-middle) {
-hw-cumulative_dx = hw-x;
-hw-cumulative_dy = hw-y;
-}
-
while (WSConsReadEvent(pInfo, event)) {
switch (event.type) {
case WSCONS_EVENT_MOUSE_UP:
@@ -187,9 +181,11 @@ WSConsReadHwState(InputInfoPtr pInfo,
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_X:
hw-x = event.value;
+hw-cumulative_dx = hw-x;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Y:
hw-y = priv-maxy - event.value + priv-miny;
+hw-cumulative_dy = hw-y;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Z:
hw-z = event.value;
@@ -218,6 +214,10 @@ WSConsReadHwState(InputInfoPtr pInfo,
}
break;
case WSCONS_EVENT_SYNC:
+if (hw-z == 0) {
+hw-fingerWidth = 0;
+hw-numFingers = 0;
+}
hw-millis = 1000 * event.time.tv_sec + event.time.tv_nsec /
100;
SynapticsCopyHwState(hwRet, hw);
return TRUE;
Re: elantech-v4 clickpad support
On 01/30/2015 07:15 AM, Martin Pieuchot wrote: On 30/01/15(Fri) 01:25, Ulf Brosziewski wrote: Probably I was too sceptical about synaptics.c. The bug I observed with the ALPS touchpad seems to be due to a kind of mismatch between the ALPS code in pms and the event handling in wsconscomm. The patch below contains the initial change as well as what was necessary to fix this. Do you think it is possible to fix the pms(4) driver instead of adding another quirk? ... Certainly that would be a better solution. For synaptics hardware there seems to be no specific W value that signals the end of a touch. If I understand it correctly, the hardware reports zero coordinates instead and the X driver adjusts its state accordingly. I will try to check soon whether this is correct and whether the ALPS code could be adapted.
Re: elantech-v4 clickpad support
Probably I was too sceptical about synaptics.c. The bug I observed
with the ALPS touchpad seems to be due to a kind of mismatch between
the ALPS code in pms and the event handling in wsconscomm. The patch
below contains the initial change as well as what was necessary to
fix this.
diff --git a/wsconscomm.c b/wsconscomm.c
index df3512d..9c5afe7 100644
--- a/wsconscomm.c
+++ b/wsconscomm.c
@@ -132,12 +132,6 @@ WSConsReadHwState(InputInfoPtr pInfo,
struct wscons_event event;
Bool v;
-/* Reset cumulative values if buttons were not previously pressed */
-if (!hw-left !hw-right !hw-middle) {
-hw-cumulative_dx = hw-x;
-hw-cumulative_dy = hw-y;
-}
-
while (WSConsReadEvent(pInfo, event)) {
switch (event.type) {
case WSCONS_EVENT_MOUSE_UP:
@@ -187,9 +181,11 @@ WSConsReadHwState(InputInfoPtr pInfo,
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_X:
hw-x = event.value;
+hw-cumulative_dx = hw-x;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Y:
hw-y = priv-maxy - event.value + priv-miny;
+hw-cumulative_dy = hw-y;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Z:
hw-z = event.value;
@@ -204,8 +200,14 @@ WSConsReadHwState(InputInfoPtr pInfo,
/* XXX magic number mapping which is mirrored in pms driver */
switch (event.value) {
case 0:
-hw-fingerWidth = 5;
-hw-numFingers = 2;
+if (priv-model != MODEL_ALPS) {
+hw-fingerWidth = 5;
+hw-numFingers = 2;
+} else {
+/* For ALPS models pms reports that w is 0 if (z = 0)? */
+hw-fingerWidth = 0;
+hw-numFingers = 0;
+}
break;
case 1:
hw-fingerWidth = 5;
Re: elantech-v4 clickpad support
On 30/01/15(Fri) 01:25, Ulf Brosziewski wrote:
Probably I was too sceptical about synaptics.c. The bug I observed
with the ALPS touchpad seems to be due to a kind of mismatch between
the ALPS code in pms and the event handling in wsconscomm. The patch
below contains the initial change as well as what was necessary to
fix this.
Do you think it is possible to fix the pms(4) driver instead of adding
another quirk?
diff --git a/wsconscomm.c b/wsconscomm.c
index df3512d..9c5afe7 100644
--- a/wsconscomm.c
+++ b/wsconscomm.c
@@ -132,12 +132,6 @@ WSConsReadHwState(InputInfoPtr pInfo,
struct wscons_event event;
Bool v;
-/* Reset cumulative values if buttons were not previously pressed */
-if (!hw-left !hw-right !hw-middle) {
-hw-cumulative_dx = hw-x;
-hw-cumulative_dy = hw-y;
-}
-
while (WSConsReadEvent(pInfo, event)) {
switch (event.type) {
case WSCONS_EVENT_MOUSE_UP:
@@ -187,9 +181,11 @@ WSConsReadHwState(InputInfoPtr pInfo,
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_X:
hw-x = event.value;
+hw-cumulative_dx = hw-x;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Y:
hw-y = priv-maxy - event.value + priv-miny;
+hw-cumulative_dy = hw-y;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Z:
hw-z = event.value;
@@ -204,8 +200,14 @@ WSConsReadHwState(InputInfoPtr pInfo,
/* XXX magic number mapping which is mirrored in pms driver */
switch (event.value) {
case 0:
-hw-fingerWidth = 5;
-hw-numFingers = 2;
+if (priv-model != MODEL_ALPS) {
+hw-fingerWidth = 5;
+hw-numFingers = 2;
+} else {
+/* For ALPS models pms reports that w is 0 if (z = 0)?
*/
+hw-fingerWidth = 0;
+hw-numFingers = 0;
+}
break;
case 1:
hw-fingerWidth = 5;
Re: elantech-v4 clickpad support
On 25/01/15(Sun) 20:07, Alexandr Shadchin wrote: On Wed, Jan 14, 2015 at 12:23:13AM +0100, Ulf Brosziewski wrote: [...] Sorry for the long answer. I tested xenocara part on x201(synaptics touchpad) and x220(synaptics clickpad), this works, no regress, even works click-and-drag :) I have no other touchpads (ALPS, Elantech) and I can not test patch on them. Has anyone else tried this diff? My laptop with an ALPS touchpad is dead so I can no longer test it. But since all touchpad implementations supposedly match what the Synaptics driver is doing, it should be safe. That said, it would be nice to make sure we're not breaking any touchpad at this point of the release. If we don't have more test reports, I'd wait for the next release cycle before committing this. M.
Re: elantech-v4 clickpad support
On 01/25/2015 04:07 PM, Alexandr Shadchin wrote: On Wed, Jan 14, 2015 at 12:23:13AM +0100, Ulf Brosziewski wrote: Currently pms and the wsconscomm module of the synaptics driver offer a somewhat limited support for Elantech clickpads with hardware version 4. Above all, I missed the options of performing click-and-drag operations with two fingers and of using a soft button area for the emulation of right button clicks (tap-and-drag and two-finger tapping are no alternatives for me, usually I don't enable tapping). I have written two patches that provide these options (I'm using them [...] Sorry for the long answer. I tested xenocara part on x201(synaptics touchpad) and x220(synaptics clickpad), this works, no regress, even works click-and-drag :) I have no other touchpads (ALPS, Elantech) and I can not test patch on them. Has anyone else tried this diff? [...] Thanks for the feedback. Meanwhile, I have tested the patch to the synaptics driver with an ALPS touchpad (ALPS Glidepoint, version 0x7321). As expected, it seems that the patch doesn't affect the driver's behaviour as long as clickpad support is disabled. However, when I enabled that support for testing purposes - there is no other reason to do that because the touchpad has two external buttons -, it showed inconsistencies. Making two successive touches while the left button is being pressed may produce cursor jumps. I haven't had the time to look at synaptics.c again, but I could check what a recent Linux version of the driver does with that touchpad: When the clickpad option is enabled, left clicks make the X cursor freeze. Perhaps the clickpad code of the driver wasn't meant to work seamlessly with all touchpads, and if this is the case, then the wsconscomm patch is too simplistic in this form. At least I think it shouldn't unmask such defects, even where the clickpad support makes no sense. I'm sorry that I had to draw these negative conclusions now. It is not clear to me whether these things could be fixed with reasonable means.
Re: elantech-v4 clickpad support
On Wed, Jan 14, 2015 at 12:23:13AM +0100, Ulf Brosziewski wrote:
Currently pms and the wsconscomm module of the synaptics driver offer a
somewhat limited support for Elantech clickpads with hardware version 4.
Above all, I missed the options of performing click-and-drag operations
with two fingers and of using a soft button area for the emulation of
right button clicks (tap-and-drag and two-finger tapping are no
alternatives for me, usually I don't enable tapping).
I have written two patches that provide these options (I'm using them
on an Acer V5-131 netbook with OpenBSD 5.6/amd64, the clickpad hardware
and firmware is identified as Elantech Clickpad, version 4, firmware
0x461f02). There is, however, an open question concerning wsconscomm.
If someone is interested in testing and using the patches, or in
assessing whether they can be useful for the OpenBSD project, some
explanations might help.
Two-finger scrolling and click-and-drag actions on clickpads require
that the multitouch input is filtered or translated into coherent
sequences of coordinate pairs. The pms patch - which I have added
below - implements a simple filter that checks the motion deltas and
ensures that if there is at least one finger moving on the clickpad, a
moving one will be tracked. Some care is needed when the input slot
changes, but this works well even within the infrastructure of wscons,
which doesn't define and handle MT events.
The problem with wsconscomm is related to the X/Linux way of handling
multitouches. If I understand it correctly, it produces MT events with
slot data as well as standard events with coordinates for pointer
control, and the latter are determined by the oldest touch. That
mechanism is sufficient if two fingers are moving in parallel, but it
cannot cover the click-and-drag case because usually only one finger
is moving, and it is not necessarily the one that has touched the
clickpad first. This might be the reason why the synaptics driver
implements an additional mapping. It accumulates the motion deltas
of the multitouch slots in a special coordinate pair. As long as no
button is pressed, the pair isn't used, and its values will be
synchronized with the standard coordinates. When clickpad support is
enabled ($ synclient ClickPad=1) and a button is down, the
cumulative values will be used. This makes the cursor movement
independent of the order of touches (and you can create, e.g., a
diagonal cursor movement by combining a horizontal and a vertical
finger movement).
It seems that the current development version of the synaptics driver
applies the cumulative coordinates to two-finger-scrolling as well
(independently of clickpad support).
In OpenBSD wsconscomm updates the cumulative coordinates when no
button is being pressed, but it does nothing with them otherwise. If
clickpad support is enabled, this has the effect that the X cursor
freezes as long as the clickpad button is down, and no click-and-
drag operation - not even the one-finger variant - is possible (for
this reason I couldn't use soft button areas, which require the
clickpad support).
As wsconscomm doesn't deal with MT events, couldn't it simply always
keep the coordinates in sync? To make click-and-drag work in my
installation I have applied the following patch to wsconscomm.c:
diff --git a/wsconscomm.c b/wsconscomm.c
index 0e0c81d..a6540db 100644
--- a/wsconscomm.c
+++ b/wsconscomm.c
@@ -131,12 +131,6 @@ WSConsReadHwState(InputInfoPtr pInfo,
struct wscons_event event;
Bool v;
-/* Reset cumulative values if buttons were not previously pressed */
-if (!hw-left !hw-right !hw-middle) {
-hw-cumulative_dx = hw-x;
-hw-cumulative_dy = hw-y;
-}
-
while (WSConsReadEvent(pInfo, event)) {
switch (event.type) {
case WSCONS_EVENT_MOUSE_UP:
@@ -186,9 +180,11 @@ WSConsReadHwState(InputInfoPtr pInfo,
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_X:
hw-x = event.value;
+hw-cumulative_dx = hw-x;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Y:
hw-y = priv-maxy - event.value + priv-miny;
+hw-cumulative_dy = hw-y;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Z:
hw-z = event.value;
Please note that this patch might unmask an inconsistent treatment
of multitouches. For example, if I use it without applying the pms
patch, an attempt to click-and-drag can lead to jumps of the cursor
and inverted vertical movements. Could something similar happen with
other hardware where clickpad support would make sense? And if this
is the case, could the change in wsconscomm be restricted in a
reasonable way?
Sorry for the long answer.
I tested xenocara part on x201(synaptics touchpad) and x220(synaptics clickpad),
this works, no regress, even works click-and-drag :)
I have no other touchpads (ALPS,
Re: elantech-v4 clickpad support
Ulf Brosziewski ulf.brosziewski at t-online.de writes: I have written two patches that provide these options (I'm using them on an Acer V5-131 netbook with OpenBSD 5.6/amd64, the clickpad hardware and firmware is identified as Elantech Clickpad, version 4, firmware 0x461f02). There is, however, an open question concerning wsconscomm. Should I try on bios0: ASUSTeK COMPUTER INC. X200CA pms0: Elantech Clickpad, version 4, firmware 0x361f01 or it is somewhat another hardware/firmware?
Re: elantech-v4 clickpad support
On 01/14/2015 02:03 AM, Alexey Suslikov wrote: Ulf Brosziewskiulf.brosziewskiat t-online.de writes: I have written two patches that provide these options (I'm using them on an Acer V5-131 netbook with OpenBSD 5.6/amd64, the clickpad hardware and firmware is identified as Elantech Clickpad, version 4, firmware 0x461f02). There is, however, an open question concerning wsconscomm. Should I try on bios0: ASUSTeK COMPUTER INC. X200CA pms0: Elantech Clickpad, version 4, firmware 0x361f01 or it is somewhat another hardware/firmware? Only the hardware version should play a role here, so this would make sense.
elantech-v4 clickpad support
Currently pms and the wsconscomm module of the synaptics driver offer a
somewhat limited support for Elantech clickpads with hardware version 4.
Above all, I missed the options of performing click-and-drag operations
with two fingers and of using a soft button area for the emulation of
right button clicks (tap-and-drag and two-finger tapping are no
alternatives for me, usually I don't enable tapping).
I have written two patches that provide these options (I'm using them
on an Acer V5-131 netbook with OpenBSD 5.6/amd64, the clickpad hardware
and firmware is identified as Elantech Clickpad, version 4, firmware
0x461f02). There is, however, an open question concerning wsconscomm.
If someone is interested in testing and using the patches, or in
assessing whether they can be useful for the OpenBSD project, some
explanations might help.
Two-finger scrolling and click-and-drag actions on clickpads require
that the multitouch input is filtered or translated into coherent
sequences of coordinate pairs. The pms patch - which I have added
below - implements a simple filter that checks the motion deltas and
ensures that if there is at least one finger moving on the clickpad, a
moving one will be tracked. Some care is needed when the input slot
changes, but this works well even within the infrastructure of wscons,
which doesn't define and handle MT events.
The problem with wsconscomm is related to the X/Linux way of handling
multitouches. If I understand it correctly, it produces MT events with
slot data as well as standard events with coordinates for pointer
control, and the latter are determined by the oldest touch. That
mechanism is sufficient if two fingers are moving in parallel, but it
cannot cover the click-and-drag case because usually only one finger
is moving, and it is not necessarily the one that has touched the
clickpad first. This might be the reason why the synaptics driver
implements an additional mapping. It accumulates the motion deltas
of the multitouch slots in a special coordinate pair. As long as no
button is pressed, the pair isn't used, and its values will be
synchronized with the standard coordinates. When clickpad support is
enabled ($ synclient ClickPad=1) and a button is down, the
cumulative values will be used. This makes the cursor movement
independent of the order of touches (and you can create, e.g., a
diagonal cursor movement by combining a horizontal and a vertical
finger movement).
It seems that the current development version of the synaptics driver
applies the cumulative coordinates to two-finger-scrolling as well
(independently of clickpad support).
In OpenBSD wsconscomm updates the cumulative coordinates when no
button is being pressed, but it does nothing with them otherwise. If
clickpad support is enabled, this has the effect that the X cursor
freezes as long as the clickpad button is down, and no click-and-
drag operation - not even the one-finger variant - is possible (for
this reason I couldn't use soft button areas, which require the
clickpad support).
As wsconscomm doesn't deal with MT events, couldn't it simply always
keep the coordinates in sync? To make click-and-drag work in my
installation I have applied the following patch to wsconscomm.c:
diff --git a/wsconscomm.c b/wsconscomm.c
index 0e0c81d..a6540db 100644
--- a/wsconscomm.c
+++ b/wsconscomm.c
@@ -131,12 +131,6 @@ WSConsReadHwState(InputInfoPtr pInfo,
struct wscons_event event;
Bool v;
-/* Reset cumulative values if buttons were not previously pressed */
-if (!hw-left !hw-right !hw-middle) {
-hw-cumulative_dx = hw-x;
-hw-cumulative_dy = hw-y;
-}
-
while (WSConsReadEvent(pInfo, event)) {
switch (event.type) {
case WSCONS_EVENT_MOUSE_UP:
@@ -186,9 +180,11 @@ WSConsReadHwState(InputInfoPtr pInfo,
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_X:
hw-x = event.value;
+hw-cumulative_dx = hw-x;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Y:
hw-y = priv-maxy - event.value + priv-miny;
+hw-cumulative_dy = hw-y;
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_Z:
hw-z = event.value;
Please note that this patch might unmask an inconsistent treatment
of multitouches. For example, if I use it without applying the pms
patch, an attempt to click-and-drag can lead to jumps of the cursor
and inverted vertical movements. Could something similar happen with
other hardware where clickpad support would make sense? And if this
is the case, could the change in wsconscomm be restricted in a
reasonable way?
If the pms patch is applied without changing wsconscomm, it would only
fix minor flaws in the clickpad behaviour (currently it is possible to
produce a tap by putting two fingers on the clickpad and lifting them
successively within a tap interval; two-finger scrolling may start with
a jump).
The diffs are against the (5.6) release versions, I hope it
