linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).