[moved to tech@]
On 27/02/15(Fri) 11:40, patrick keshishian wrote:
> Hi,
>
> On 2/26/15, Ulf Brosziewski <ulf.brosziew...@t-online.de> wrote:
> > On 02/27/2015 03:31 AM, Ulf Brosziewski wrote:
> > ...>
> >> It might be that the following patch to wsmouse.c solves the problem
> >> with the new version of wsconscomm. Tests would be welcome (I could
> >> only verify that the patch does no harm to other touchpad types, i.e.,
> >> Elantech-v4 and Alps Glidepoint).
> [...]
> >
> > Sorry, the change was in the wrong place and would only do a half of
> > the work. It should look like:
> >
> > Index: wsmouse.c
> > ===================================================================
> > RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
> > retrieving revision 1.26
> > diff -u -p -r1.26 wsmouse.c
> > --- wsmouse.c 27 Oct 2014 13:55:05 -0000 1.26
> > +++ wsmouse.c 27 Feb 2015 02:50:06 -0000
> > @@ -433,6 +433,9 @@ wsmouse_input(struct device *wsmousedev,
> > }
> > }
> >
> > + if (sc->sc_z == 0)
> > + sc->sc_w = INVALID_W;
> > +
> > mb = sc->sc_mb;
> > while ((d = mb ^ ub) != 0) {
> > /*
>
> I can confirm this change alone causes no adverse, observable
> change on my x120e's touchpad.
I the long term, I think that having a similar logic in wsmouse_input()
makes sense. As I already told Ulf, it would be really nice to improve
the wsmouse(4)/wscons(4) layer to support modern touchpad features and
get rid of wsconscomm.
But right now this chunk is really intrusive. Plus I believe it should
only be applied on touchpad ``native'' mode. Sure, we could be able to
check for WSMOUSE_INPUT_ABSOLUTE_W, but can it be a bad idea?
What about putting a similar chunk in pms_proc_synpatics() instead?
> However, I would appreciate it if someone could enlighten me
> as to what the Z and W axis refer.
I'm glad you asked, because it really depends on which hardware you're
using :) Plus right now our code use magic values which are most of
the time not documented. Diffs are more than welcome to improve the
situation.
Martin
