From: "Pali Rohár" <pali.rohar@gmail.com>
To: Juanito <juanitobananas@posteo.net>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Juanito <juam+kernel@posteo.net>,
linux-input@vger.kernel.org,
"masaki.ota@jp.alps.com" <masaki.ota@jp.alps.com>,
Paul Donohue <linux-kernel@paulsd.com>
Subject: Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint
Date: Fri, 8 Sep 2017 08:48:53 +0200 [thread overview]
Message-ID: <201709080848.53286@pali> (raw)
In-Reply-To: <30e888e8-39a8-6d74-7610-e467ed96815e@posteo.net>
[-- Attachment #1: Type: Text/Plain, Size: 6338 bytes --]
On Friday 08 September 2017 07:00:34 Juanito wrote:
> Hi,
>
> Thanks for that!
>
> > ThinkPad with ALPS? Should not be it Synaptic? Maybe
> > miss-detection?
>
> Sorry, I forgot to mention this. The ThinkPad came with a clickpad I
> **really** disliked, so I bought this on the Internet.
So, here is a problem. ThinkPads works with Synaptic touchpads, not with
ALPS.
> > Anyway, for ALPS devices, buttons below touchpad area are reported
> > from touchpad device and buttons above touchpad are reported from
> > the trackstick device.
> >
> > ALPS DualPoint means device with touchpad + trackpoint
> >
> > ALPS GlidePoint means device with only touchpad (without
> > trackpoint)
> >
> > So error message "Rejected trackstick packet from non DualPoint
> > device" which is generated at time when you click at buttons,
> > would mean that those buttons are reported via trackstick. And if
> > kernel detected that ALPS device as GlidePoint, then events from
> > trackpoint (so also buttons) are dropped.
>
> Is the trackpoint the red thingie between G, H and B?
Yes.
> >>> I have noticed that the touchpad gets assigned different names on
> >>> both distros. On debian it is recognized as a GlidePoint and on
> >>> Ubuntu as a DualPoint. In an upstream kernel 4.13 which I just
> >>> built, it's also recognized as a GlidePoint. Unfortunately it
> >>> doesn't work either.
> >
> > Name is assigned based on detection if trackstick is present.
> > Different kernel versions is probably reasons, maybe one version
> > has wrong detection.
> >
> > Is trackstick movement working? This is probably important to know
> > as it looks like buttons are reported via trackstick, not via
> > touchpad.
>
> If by trackstick you mean the red thingie, it is **not** working.
Ok. And it is working with your patch?
> >>> I am not sure if the device is actually a DualPoint or not (I
> >>> don't really understand the terminology here), but the thing is
> >>> that the buttons work when the kernel believes it to be one.
> >>>
> >>> This is the info I have managed to find about the device while
> >>> running on the non-working debian:
> >>>
> >>> dmesg:
> >>> [ 2.914806] input: AlpsPS/2 ALPS GlidePoint as
> >>> /devices/platform/i8042/serio1/input/input2
> >>>
> >>> lsinput:
> >>> /dev/input/event11
> >>>
> >>> bustype : BUS_I8042
> >>> vendor : 0x2
> >>> product : 0x8
> >>> version : 1792
> >>> name : "AlpsPS/2 ALPS GlidePoint"
> >>> phys : "isa0060/serio1/input0"
> >>> bits ev : (null) (null) (null)
> >>>
> >>> I have played around with the drivers/input/mouse/alps.c file and
> >>> found out the following:
> >>>
> >>> e7 and ec are important (although I don't know what these are
> >>> exactly) and have the following values:
> >>>
> >>> e7: 73 03 0a
> >>> ec: 88 b0 13
> >
> > Masaki should know exact type of device...
> >
> >>> This combination is recognized as an ALPS touchpad, but isn't
> >>> assigned the ALPS_DUALPOINT flag. As far as I can see, it is
> >>> actually being *removed* at this point:
> >>>
> >>> if (alps_probe_trackstick_v3_v7(psmouse, ALPS_REG_BASE_V7) < 0)
> >>>
> >>> priv->flags &= ~ALPS_DUALPOINT;
> >>>
> >>> The bit that says it has a trackpoint (I don't know what this is)
> >>> is apparently saying my device doesn't have one and is removing
> >>> the ALPS_DUALPOINT flag.
> >
> > At least for V3 protocol that function tells touchpad to enable
> > pass- thru mode to trackstick and detect if trackstick is there
> > present. After that leave pass-thru mode.
> >
> >>> This flag makes the buttons work. I am not sure if it breaks
> >>> other stuff.
> >
> > Is that picture of your laptop, do you really have trackstick
> > working?
>
> The picture is not from my laptop, but it might as well just be: mine
> looks exactly the same. Actually it is from a blog which I read which
> inspired be to change my touchpad:
>
> https://www.camerongray.me/2015/02/fitting-physical-trackpoint-button
> s-to-a-lenovo-thinkpad-t440s/
>
> For the record, I don't have a T440 but an S440, should this be
> relevant.
>
> > My idea is that alps_probe_trackstick_v3_v7 does not check presence
> > of trackstick correct and return information that trackstick is
> > not present (which contains also those buttons)...
> >
> > Masaki, can you confirm if there can be problem with that function?
> >
> >>> I have written a pretty dummy patch which actually adds the flag
> >>> again making the buttons work. Again, I am not sure if it breaks
> >>> other stuff but my system isn't whining. Here is the patch:
> >>>
> >>> diff --git a/drivers/input/mouse/alps.c
> >>> b/drivers/input/mouse/alps.c index 850b00e3ad8e..17aba42e846f
> >>> 100644
> >>> --- a/drivers/input/mouse/alps.c
> >>> +++ b/drivers/input/mouse/alps.c
> >>> @@ -2804,6 +2804,9 @@ static int alps_set_protocol(struct psmouse
> >>> *psmouse,
> >>>
> >>> if (alps_probe_trackstick_v3_v7(psmouse,
> >>>
> >>> ALPS_REG_BASE_V7) < 0)
> >>>
> >>> priv->flags &= ~ALPS_DUALPOINT;
> >>>
> >>> + if (priv->fw_ver[1] == 0xb0)
> >>> + priv->flags |= ALPS_DUALPOINT;
> >>> +
> >>>
> >>> break;
> >>>
> >>> case ALPS_PROTO_V8:
> >>> After applying this patch dmesg and lsinput say this:
> >>>
> >>> [ 8.226543] input: AlpsPS/2 ALPS DualPoint Stick as
> >>> /devices/platform/i8042/serio1/input/input13
> >>> [ 8.247595] input: AlpsPS/2 ALPS DualPoint TouchPad as
> >>> /devices/platform/i8042/serio1/input/input2
> >>>
> >>> /dev/input/event11
> >>>
> >>> bustype : BUS_I8042
> >>> vendor : 0x2
> >>> product : 0x8
> >>> version : 1792
> >>> name : "AlpsPS/2 ALPS DualPoint Stick"
> >>> phys : "isa0060/serio1/input1"
> >>> bits ev : (null) (null) (null)
> >>>
> >>> /dev/input/event12
> >>>
> >>> bustype : BUS_I8042
> >>> vendor : 0x2
> >>> product : 0x8
> >>> version : 1792
> >>> name : "AlpsPS/2 ALPS DualPoint TouchPad"
> >>> phys : "isa0060/serio1/input0"
> >>> bits ev : (null) (null) (null)
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2017-09-08 6:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-07 7:05 ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint Juanito
2017-09-07 21:31 ` Dmitry Torokhov
2017-09-07 21:54 ` Pali Rohár
2017-09-08 5:00 ` Juanito
2017-09-08 6:48 ` Pali Rohár [this message]
2017-09-09 8:12 ` Juanito
2017-09-09 8:36 ` Pali Rohár
2017-09-09 18:12 ` Dmitry Torokhov
2017-09-09 18:21 ` Juanito
2017-09-11 2:38 ` Masaki Ota
2017-09-11 11:26 ` Juanito
2018-02-04 18:16 ` Pali Rohár
[not found] ` <f291e382-b90e-baba-fb3c-bdebc991a21d@posteo.net>
2018-02-04 20:21 ` Pali Rohár
2018-02-05 7:48 ` Juanito
2018-02-05 11:19 ` Juanito
2018-02-11 23:01 ` Pali Rohár
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201709080848.53286@pali \
--to=pali.rohar@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=juam+kernel@posteo.net \
--cc=juanitobananas@posteo.net \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@paulsd.com \
--cc=masaki.ota@jp.alps.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).