ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Juanito]

Dear Kernel Hackers,

I hope this is the correct place to post this. If not, please forgive me
and feel free to forward it to someplace else. Thank you very much!

I have a ThinkPad with a touchpad that looks exactly like this:
https://www.camerongray.me/wp-content/uploads/2015/02/SCotlGg.jpg

The three pyhsical buttons on top do not work on my debian stretch
(4.9). I think it isn't being recognized correctly. I see a "Rejected
trackstick packet from non DualPoint device" in my syslog whenever I
click on one of them. On the other hand on a Ubuntu 16.04 (4.4 - patched
by Ubuntu y guess) the buttons *do* work. Interestingly enough, it
doesn't work on 17.04 (4.10).

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.

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

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.

This flag makes the buttons work. I am not sure if it breaks other stuff.

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)

I am a total newbie to kernels and drivers so it would be great if
somebody who actually had some idea could take a look at this and
probably create a patch in a better place. I'll be glad to post more
info if necessary.

Thank you very much!

Cheers,
Juanito

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Dmitry Torokhov]

Hi Juanito,

On Thu, Sep 07, 2017 at 09:05:14AM +0200, Juanito wrote:
> Dear Kernel Hackers,
> 
> I hope this is the correct place to post this. If not, please forgive me
> and feel free to forward it to someplace else. Thank you very much!

Let's add a few more people who's been looking after ALPS...

> 
> I have a ThinkPad with a touchpad that looks exactly like this:
> https://www.camerongray.me/wp-content/uploads/2015/02/SCotlGg.jpg
> 
> The three pyhsical buttons on top do not work on my debian stretch
> (4.9). I think it isn't being recognized correctly. I see a "Rejected
> trackstick packet from non DualPoint device" in my syslog whenever I
> click on one of them. On the other hand on a Ubuntu 16.04 (4.4 - patched
> by Ubuntu y guess) the buttons *do* work. Interestingly enough, it
> doesn't work on 17.04 (4.10).
> 
> 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.
> 
> 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
> 
> 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.
> 
> This flag makes the buttons work. I am not sure if it breaks other stuff.
> 
> 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)
> 
> I am a total newbie to kernels and drivers so it would be great if
> somebody who actually had some idea could take a look at this and
> probably create a patch in a better place. I'll be glad to post more
> info if necessary.
> 
> Thank you very much!
> 
> Cheers,
> Juanito
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Dmitry

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 6596 bytes --]

On Thursday 07 September 2017 23:31:23 Dmitry Torokhov wrote:
> Hi Juanito,
> 
> On Thu, Sep 07, 2017 at 09:05:14AM +0200, Juanito wrote:
> > Dear Kernel Hackers,
> > 
> > I hope this is the correct place to post this. If not, please
> > forgive me and feel free to forward it to someplace else. Thank
> > you very much!
> 
> Let's add a few more people who's been looking after ALPS...
> 
> > I have a ThinkPad with a touchpad that looks exactly like this:
> > https://www.camerongray.me/wp-content/uploads/2015/02/SCotlGg.jpg
> 
> > The three pyhsical buttons on top do not work on my debian stretch
> > (4.9). I think it isn't being recognized correctly. I see a
> > "Rejected trackstick packet from non DualPoint device" in my
> > syslog whenever I click on one of them. On the other hand on a
> > Ubuntu 16.04 (4.4 - patched by Ubuntu y guess) the buttons *do*
> > work. Interestingly enough, it doesn't work on 17.04 (4.10).

ThinkPad with ALPS? Should not be it Synaptic? Maybe miss-detection?

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.

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

> > 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?

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)
> > 
> > I am a total newbie to kernels and drivers so it would be great if
> > somebody who actually had some idea could take a look at this and
> > probably create a patch in a better place. I'll be glad to post
> > more info if necessary.
> > 
> > Thank you very much!
> > 
> > Cheers,
> > Juanito
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-input" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Juanito]

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.

> 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?

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

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

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Pali Rohár]

[-- 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 --]

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Juanito]

Hello,

On 09/08/2017 08:48 AM, Pali Rohár wrote:
> On Friday 08 September 2017 07:00:34 Juanito wrote:
>>
>>> 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.
> 

There definitely seems to be a problem here :)

Do you mean that the alps code might not be detecting the trackpoint
because probably the red thingie works with synaptics?

So could this be the situation:
ALPS driver: Hey touchpad! Do you have a trackstick?
ALPS touchpad: No, I don't.
AD: Ok! (and thinks 'I am going to have to ignore all trackstick packets
that might arrive')

So the driver understands that there can't possibly be any buttons
because there is no trackstick?

>>
>> If by trackstick you mean the red thingie, it is **not** working.
> 
> Ok. And it is working with your patch?
>

No, it isn't :(

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

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1626 bytes --]

On Saturday 09 September 2017 10:12:42 Juanito wrote:
> Hello,
> 
> On 09/08/2017 08:48 AM, Pali Rohár wrote:
> > On Friday 08 September 2017 07:00:34 Juanito wrote:
> >>> 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.
> 
> There definitely seems to be a problem here :)
> 
> Do you mean that the alps code might not be detecting the trackpoint
> because probably the red thingie works with synaptics?
> 
> So could this be the situation:
> ALPS driver: Hey touchpad! Do you have a trackstick?
> ALPS touchpad: No, I don't.
> AD: Ok! (and thinks 'I am going to have to ignore all trackstick
> packets that might arrive')
> 
> So the driver understands that there can't possibly be any buttons
> because there is no trackstick?

IIRC ALPS touchpad hardware itself does not work with non-ALPS 
trackpoint.

Masaki, any comments?

> >> If by trackstick you mean the red thingie, it is **not** working.
> > 
> > Ok. And it is working with your patch?
> 
> No, it isn't :(

I expected... You just created franken-hardware.

Looks like with your hack patch it is possible to make buttons working, 
but I suspect that trackstick would.

Maybe Masaki can provide more information about this fact if we can do 
anything.

Dmitry, what you as maintainer going to do with this problem?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Dmitry Torokhov]

On Sat, Sep 09, 2017 at 10:36:06AM +0200, Pali Rohár wrote:
> On Saturday 09 September 2017 10:12:42 Juanito wrote:
> > Hello,
> > 
> > On 09/08/2017 08:48 AM, Pali Rohár wrote:
> > > On Friday 08 September 2017 07:00:34 Juanito wrote:
> > >>> 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.
> > 
> > There definitely seems to be a problem here :)
> > 
> > Do you mean that the alps code might not be detecting the trackpoint
> > because probably the red thingie works with synaptics?
> > 
> > So could this be the situation:
> > ALPS driver: Hey touchpad! Do you have a trackstick?
> > ALPS touchpad: No, I don't.
> > AD: Ok! (and thinks 'I am going to have to ignore all trackstick
> > packets that might arrive')
> > 
> > So the driver understands that there can't possibly be any buttons
> > because there is no trackstick?
> 
> IIRC ALPS touchpad hardware itself does not work with non-ALPS 
> trackpoint.
> 
> Masaki, any comments?
> 
> > >> If by trackstick you mean the red thingie, it is **not** working.
> > > 
> > > Ok. And it is working with your patch?
> > 
> > No, it isn't :(
> 
> I expected... You just created franken-hardware.
> 
> Looks like with your hack patch it is possible to make buttons working, 
> but I suspect that trackstick would.
> 
> Maybe Masaki can provide more information about this fact if we can do 
> anything.
> 
> Dmitry, what you as maintainer going to do with this problem?

It really depends on Ota-san response. If ALPS needs a special version
of firmware flashed for proper trackstick identification, then I guess
Juanito will have to carry a local patch. I do not think we want to
complicate the driver any further for supporting such after-market
modification.

Does booting with psmouse.proto=imps makes trackstick work?

Thanks.

-- 
Dmitry

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Juanito]

On 09/09/2017 08:12 PM, Dmitry Torokhov wrote:
> On Sat, Sep 09, 2017 at 10:36:06AM +0200, Pali Rohár wrote:
>> On Saturday 09 September 2017 10:12:42 Juanito wrote:
>>> Hello,
>>>
>>> On 09/08/2017 08:48 AM, Pali Rohár wrote:
>>>> On Friday 08 September 2017 07:00:34 Juanito wrote:
>>>>>> 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.
>>>
>>> There definitely seems to be a problem here :)
>>>
>>> Do you mean that the alps code might not be detecting the trackpoint
>>> because probably the red thingie works with synaptics?
>>>
>>> So could this be the situation:
>>> ALPS driver: Hey touchpad! Do you have a trackstick?
>>> ALPS touchpad: No, I don't.
>>> AD: Ok! (and thinks 'I am going to have to ignore all trackstick
>>> packets that might arrive')
>>>
>>> So the driver understands that there can't possibly be any buttons
>>> because there is no trackstick?
>>
>> IIRC ALPS touchpad hardware itself does not work with non-ALPS 
>> trackpoint.
>>
>> Masaki, any comments?
>>
>>>>> If by trackstick you mean the red thingie, it is **not** working.
>>>>
>>>> Ok. And it is working with your patch?
>>>
>>> No, it isn't :(
>>
>> I expected... You just created franken-hardware.
>>
>> Looks like with your hack patch it is possible to make buttons working, 
>> but I suspect that trackstick would.
>>
>> Maybe Masaki can provide more information about this fact if we can do 
>> anything.
>>
>> Dmitry, what you as maintainer going to do with this problem?
> 
> It really depends on Ota-san response. If ALPS needs a special version
> of firmware flashed for proper trackstick identification, then I guess
> Juanito will have to carry a local patch. I do not think we want to
> complicate the driver any further for supporting such after-market
> modification.
> 

If this only happens in this after-market (or franken-hardware...
hahaha), I'd totally understand if you didn't want to patch it upstream,
although it would be nice for me :)

> Does booting with psmouse.proto=imps makes trackstick work?
> 

I am afraid I can't test it now as I don't have access to the laptop. I
won't be able to test until two weeks. Will definitely do as soon as I can.

> Thanks.
> 

Thank **you** (Dmitry and everybody esle) for taking the time to look at
this.

Juanito

RE: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Masaki Ota]

Hi, Juanito,

In my information, ALPS Touchpad is used on Thinkpad E series and L series.
I don't know the device that is ALPS Touchpad + other vendor TrackStick.
But Lenovo might use ALPS Touchpad on such a combination.

And I have found that the V7 protocol device has a special ID for Lenovo.
ALPS assigns the value that is the model type to 0xC399 address.

Could you check 0xC399 address value such like a below code?
reg_val = alps_command_mode_read_reg(psmouse, 0xC399);

If the value is 0x1 or 0x2 or 0x6 or 0x10 or 0xF, it has a Stick buttons.

Best Regards,
Masaki Ota
-----Original Message-----
From: Juanito [mailto:juam+kernel@posteo.net] 
Sent: Sunday, September 10, 2017 3:22 AM
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Pali Rohár <pali.rohar@gmail.com>
Cc: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; linux-input@vger.kernel.org; Paul Donohue <linux-kernel@paulsd.com>
Subject: Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

On 09/09/2017 08:12 PM, Dmitry Torokhov wrote:
> On Sat, Sep 09, 2017 at 10:36:06AM +0200, Pali Rohár wrote:
>> On Saturday 09 September 2017 10:12:42 Juanito wrote:
>>> Hello,
>>>
>>> On 09/08/2017 08:48 AM, Pali Rohár wrote:
>>>> On Friday 08 September 2017 07:00:34 Juanito wrote:
>>>>>> 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.
>>>
>>> There definitely seems to be a problem here :)
>>>
>>> Do you mean that the alps code might not be detecting the trackpoint 
>>> because probably the red thingie works with synaptics?
>>>
>>> So could this be the situation:
>>> ALPS driver: Hey touchpad! Do you have a trackstick?
>>> ALPS touchpad: No, I don't.
>>> AD: Ok! (and thinks 'I am going to have to ignore all trackstick 
>>> packets that might arrive')
>>>
>>> So the driver understands that there can't possibly be any buttons 
>>> because there is no trackstick?
>>
>> IIRC ALPS touchpad hardware itself does not work with non-ALPS 
>> trackpoint.
>>
>> Masaki, any comments?
>>
>>>>> If by trackstick you mean the red thingie, it is **not** working.
>>>>
>>>> Ok. And it is working with your patch?
>>>
>>> No, it isn't :(
>>
>> I expected... You just created franken-hardware.
>>
>> Looks like with your hack patch it is possible to make buttons 
>> working, but I suspect that trackstick would.
>>
>> Maybe Masaki can provide more information about this fact if we can 
>> do anything.
>>
>> Dmitry, what you as maintainer going to do with this problem?
> 
> It really depends on Ota-san response. If ALPS needs a special version 
> of firmware flashed for proper trackstick identification, then I guess 
> Juanito will have to carry a local patch. I do not think we want to 
> complicate the driver any further for supporting such after-market 
> modification.
> 

If this only happens in this after-market (or franken-hardware...
hahaha), I'd totally understand if you didn't want to patch it upstream, although it would be nice for me :)

> Does booting with psmouse.proto=imps makes trackstick work?
> 

I am afraid I can't test it now as I don't have access to the laptop. I won't be able to test until two weeks. Will definitely do as soon as I can.

> Thanks.
> 

Thank **you** (Dmitry and everybody esle) for taking the time to look at this.

Juanito

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Juanito]

Hi Masaki Ota,

Thanks!

On 11.09.2017 04:38, Masaki Ota wrote:
> Hi, Juanito,
> 
> In my information, ALPS Touchpad is used on Thinkpad E series and L series.
> I don't know the device that is ALPS Touchpad + other vendor TrackStick.
> But Lenovo might use ALPS Touchpad on such a combination.
> 

Well, that is probably my fault, as it is not the original touchpad that
was delievered with the laptop. I bought the touchpad (that included
the three buttons) separately because I didn't like the clickpad that
came with my laptop.

> And I have found that the V7 protocol device has a special ID for Lenovo.
> ALPS assigns the value that is the model type to 0xC399 address.
> 
> Could you check 0xC399 address value such like a below code?
> reg_val = alps_command_mode_read_reg(psmouse, 0xC399);
> 
> If the value is 0x1 or 0x2 or 0x6 or 0x10 or 0xF, it has a Stick buttons.
> 

I will check this as soon as I can (I don't have access to the laptop
right now).

> Best Regards,
> Masaki Ota
> -----Original Message-----
> From: Juanito [mailto:juam+kernel@posteo.net] 
> Sent: Sunday, September 10, 2017 3:22 AM
> To: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Pali Rohár <pali.rohar@gmail.com>
> Cc: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; linux-input@vger.kernel.org; Paul Donohue <linux-kernel@paulsd.com>
> Subject: Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint
> 
> On 09/09/2017 08:12 PM, Dmitry Torokhov wrote:
>> On Sat, Sep 09, 2017 at 10:36:06AM +0200, Pali Rohár wrote:
>>> On Saturday 09 September 2017 10:12:42 Juanito wrote:
>>>> Hello,
>>>>
>>>> On 09/08/2017 08:48 AM, Pali Rohár wrote:
>>>>> On Friday 08 September 2017 07:00:34 Juanito wrote:
>>>>>>> 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.
>>>>
>>>> There definitely seems to be a problem here :)
>>>>
>>>> Do you mean that the alps code might not be detecting the trackpoint 
>>>> because probably the red thingie works with synaptics?
>>>>
>>>> So could this be the situation:
>>>> ALPS driver: Hey touchpad! Do you have a trackstick?
>>>> ALPS touchpad: No, I don't.
>>>> AD: Ok! (and thinks 'I am going to have to ignore all trackstick 
>>>> packets that might arrive')
>>>>
>>>> So the driver understands that there can't possibly be any buttons 
>>>> because there is no trackstick?
>>>
>>> IIRC ALPS touchpad hardware itself does not work with non-ALPS 
>>> trackpoint.
>>>
>>> Masaki, any comments?
>>>
>>>>>> If by trackstick you mean the red thingie, it is **not** working.
>>>>>
>>>>> Ok. And it is working with your patch?
>>>>
>>>> No, it isn't :(
>>>
>>> I expected... You just created franken-hardware.
>>>
>>> Looks like with your hack patch it is possible to make buttons 
>>> working, but I suspect that trackstick would.
>>>
>>> Maybe Masaki can provide more information about this fact if we can 
>>> do anything.
>>>
>>> Dmitry, what you as maintainer going to do with this problem?
>>
>> It really depends on Ota-san response. If ALPS needs a special version 
>> of firmware flashed for proper trackstick identification, then I guess 
>> Juanito will have to carry a local patch. I do not think we want to 
>> complicate the driver any further for supporting such after-market 
>> modification.
>>
> 
> If this only happens in this after-market (or franken-hardware...
> hahaha), I'd totally understand if you didn't want to patch it upstream, although it would be nice for me :)
> 
>> Does booting with psmouse.proto=imps makes trackstick work?
>>
> 
> I am afraid I can't test it now as I don't have access to the laptop. I won't be able to test until two weeks. Will definitely do as soon as I can.
> 
>> Thanks.
>>
> 
> Thank **you** (Dmitry and everybody esle) for taking the time to look at this.
> 
> Juanito
> 


Thank you very much!

Best regards,
Juanito

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 5706 bytes --]

On Monday 11 September 2017 13:26:30 Juanito wrote:
> Hi Masaki Ota,
> 
> Thanks!
> 
> On 11.09.2017 04:38, Masaki Ota wrote:
> > Hi, Juanito,
> > 
> > In my information, ALPS Touchpad is used on Thinkpad E series and L series.
> > I don't know the device that is ALPS Touchpad + other vendor TrackStick.
> > But Lenovo might use ALPS Touchpad on such a combination.
> > 
> 
> Well, that is probably my fault, as it is not the original touchpad that
> was delievered with the laptop. I bought the touchpad (that included
> the three buttons) separately because I didn't like the clickpad that
> came with my laptop.

Hi Juanito,

if you are still want to play with your touchpad hardware, I have a good
news for your.

It looks like that at least ALPS rushmore touchpads allow to receive RAW
PS/2 packets from trackstick to host kernel, without modifying them by
touchpad. Plus I was able to tell ALPS touchpad to start "mixing" those
RAW trackstick PS/2 packets with native touchpad packets.

On my configuration trackstick in RAW PS/2 mode by default talks with
standard bare 3 byte PS/2 protocol and touchpad in 6 byte ALPS protocol.
alps.c/psmouse.ko is already able to process and parse such mixed
packets. And trackstick can be switched to some extended 4 byte
protocol...

All this happen when passthrough mode is enabled.

From my understanding it seems that in normal mode, touchpad and
trackstick communicate with that 4 byte protocol and touchpad converts
it into 6 byte ALPS protocol and then send to kernel.

On thinkpads trackstick communicate with TPPS/2 protcol and above 4
byte. So in my opinion ALPS touchpad by default cannot understand it.
But you should be able to enter passthrough mode and then you would
receive that TPPS/2 in alps kernel code.

> > And I have found that the V7 protocol device has a special ID for Lenovo.
> > ALPS assigns the value that is the model type to 0xC399 address.
> > 
> > Could you check 0xC399 address value such like a below code?
> > reg_val = alps_command_mode_read_reg(psmouse, 0xC399);
> > 
> > If the value is 0x1 or 0x2 or 0x6 or 0x10 or 0xF, it has a Stick buttons.
> > 
> 
> I will check this as soon as I can (I don't have access to the laptop
> right now).
> 
> > Best Regards,
> > Masaki Ota
> > -----Original Message-----
> > From: Juanito [mailto:juam+kernel@posteo.net] 
> > Sent: Sunday, September 10, 2017 3:22 AM
> > To: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Pali Rohár <pali.rohar@gmail.com>
> > Cc: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; linux-input@vger.kernel.org; Paul Donohue <linux-kernel@paulsd.com>
> > Subject: Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint
> > 
> > On 09/09/2017 08:12 PM, Dmitry Torokhov wrote:
> >> On Sat, Sep 09, 2017 at 10:36:06AM +0200, Pali Rohár wrote:
> >>> On Saturday 09 September 2017 10:12:42 Juanito wrote:
> >>>> Hello,
> >>>>
> >>>> On 09/08/2017 08:48 AM, Pali Rohár wrote:
> >>>>> On Friday 08 September 2017 07:00:34 Juanito wrote:
> >>>>>>> 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.
> >>>>
> >>>> There definitely seems to be a problem here :)
> >>>>
> >>>> Do you mean that the alps code might not be detecting the trackpoint 
> >>>> because probably the red thingie works with synaptics?
> >>>>
> >>>> So could this be the situation:
> >>>> ALPS driver: Hey touchpad! Do you have a trackstick?
> >>>> ALPS touchpad: No, I don't.
> >>>> AD: Ok! (and thinks 'I am going to have to ignore all trackstick 
> >>>> packets that might arrive')
> >>>>
> >>>> So the driver understands that there can't possibly be any buttons 
> >>>> because there is no trackstick?
> >>>
> >>> IIRC ALPS touchpad hardware itself does not work with non-ALPS 
> >>> trackpoint.
> >>>
> >>> Masaki, any comments?
> >>>
> >>>>>> If by trackstick you mean the red thingie, it is **not** working.
> >>>>>
> >>>>> Ok. And it is working with your patch?
> >>>>
> >>>> No, it isn't :(
> >>>
> >>> I expected... You just created franken-hardware.
> >>>
> >>> Looks like with your hack patch it is possible to make buttons 
> >>> working, but I suspect that trackstick would.
> >>>
> >>> Maybe Masaki can provide more information about this fact if we can 
> >>> do anything.
> >>>
> >>> Dmitry, what you as maintainer going to do with this problem?
> >>
> >> It really depends on Ota-san response. If ALPS needs a special version 
> >> of firmware flashed for proper trackstick identification, then I guess 
> >> Juanito will have to carry a local patch. I do not think we want to 
> >> complicate the driver any further for supporting such after-market 
> >> modification.
> >>
> > 
> > If this only happens in this after-market (or franken-hardware...
> > hahaha), I'd totally understand if you didn't want to patch it upstream, although it would be nice for me :)
> > 
> >> Does booting with psmouse.proto=imps makes trackstick work?
> >>
> > 
> > I am afraid I can't test it now as I don't have access to the laptop. I won't be able to test until two weeks. Will definitely do as soon as I can.
> > 
> >> Thanks.
> >>
> > 
> > Thank **you** (Dmitry and everybody esle) for taking the time to look at this.
> > 
> > Juanito
> > 
> 
> 
> Thank you very much!
> 
> Best regards,
> Juanito
> 

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 3279 bytes --]

On Sunday 04 February 2018 20:39:06 Juanito wrote:
> On 02/04/2018 07:16 PM, Pali Rohár wrote:
> > On Monday 11 September 2017 13:26:30 Juanito wrote:
> >> Hi Masaki Ota,
> >>
> >> Thanks!
> >>
> >> On 11.09.2017 04:38, Masaki Ota wrote:
> >>> Hi, Juanito,
> >>>
> >>> In my information, ALPS Touchpad is used on Thinkpad E series and L series.
> >>> I don't know the device that is ALPS Touchpad + other vendor TrackStick.
> >>> But Lenovo might use ALPS Touchpad on such a combination.
> >>>
> >>
> >> Well, that is probably my fault, as it is not the original touchpad that
> >> was delievered with the laptop. I bought the touchpad (that included
> >> the three buttons) separately because I didn't like the clickpad that
> >> came with my laptop.
> > 
> > Hi Juanito,
> > 
> 
> Hi Pali,
> 
> > if you are still want to play with your touchpad hardware, I have a good
> > news for your.
> > 
> 
> Yeah! I'd love to get it to work! It's just I've been "working" on some
> other projects and my last kernel builds didn't work at all so I gave up
> and never got back to it.
> 
> Thank you very much for that!
> 
> > It looks like that at least ALPS rushmore touchpads allow to receive RAW
> > PS/2 packets from trackstick to host kernel, without modifying them by
> > touchpad. Plus I was able to tell ALPS touchpad to start "mixing" those
> > RAW trackstick PS/2 packets with native touchpad packets.
> > 
> > On my configuration trackstick in RAW PS/2 mode by default talks with
> > standard bare 3 byte PS/2 protocol and touchpad in 6 byte ALPS protocol.
> > alps.c/psmouse.ko is already able to process and parse such mixed
> > packets. And trackstick can be switched to some extended 4 byte
> > protocol...
> > 
> > All this happen when passthrough mode is enabled.
> > 
> > From my understanding it seems that in normal mode, touchpad and
> > trackstick communicate with that 4 byte protocol and touchpad converts
> > it into 6 byte ALPS protocol and then send to kernel.
> > 
> > On thinkpads trackstick communicate with TPPS/2 protcol and above 4
> > byte. So in my opinion ALPS touchpad by default cannot understand it.
> > But you should be able to enter passthrough mode and then you would
> > receive that TPPS/2 in alps kernel code.
> > 
> 
> I don't really understand what you mean. Do I "just" have to set it to
> passthrough mode? How exactly can I do that?

Look at function alps_passthrough_mode_v3(). And try to call it after
touchpad is initialized.

You can also look which alps_command_mode_write_reg() functions are
called for your touchpad and maybe try to figure out what those
registers can enabled/disable.

On http://www.cirque.com/gen4-dev-resources you can find document named
GP-AN- 130823 INTERFACING TO GEN4 OVER I2C (PDF) which contains
some description of those registers (in section 7).

Register C2C8, bit 0 has description "PS2AuxControl.CommandPassThruEnabled"

If trackstick is not detected, it seems you can "force" enable it by
setting bit 7 "PS2AuxControl.AuxDevicePresent" in same register.

> Again, thank you very much!

Have you tried to read from that register which Masaki Ota talked in
previous emails?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Juanito]

[-- Attachment #1.1: Type: text/plain, Size: 3545 bytes --]

On 02/04/2018 09:21 PM, Pali Rohár wrote:
> On Sunday 04 February 2018 20:39:06 Juanito wrote:
>> On 02/04/2018 07:16 PM, Pali Rohár wrote:
>>> On Monday 11 September 2017 13:26:30 Juanito wrote:
>>>> Hi Masaki Ota,
>>>>
>>>> Thanks!
>>>>
>>>> On 11.09.2017 04:38, Masaki Ota wrote:
>>>>> Hi, Juanito,
>>>>>
>>>>> In my information, ALPS Touchpad is used on Thinkpad E series and L series.
>>>>> I don't know the device that is ALPS Touchpad + other vendor TrackStick.
>>>>> But Lenovo might use ALPS Touchpad on such a combination.
>>>>>
>>>>
>>>> Well, that is probably my fault, as it is not the original touchpad that
>>>> was delievered with the laptop. I bought the touchpad (that included
>>>> the three buttons) separately because I didn't like the clickpad that
>>>> came with my laptop.
>>>
>>> Hi Juanito,
>>>
>>
>> Hi Pali,
>>
>>> if you are still want to play with your touchpad hardware, I have a good
>>> news for your.
>>>
>>
>> Yeah! I'd love to get it to work! It's just I've been "working" on some
>> other projects and my last kernel builds didn't work at all so I gave up
>> and never got back to it.
>>
>> Thank you very much for that!
>>
>>> It looks like that at least ALPS rushmore touchpads allow to receive RAW
>>> PS/2 packets from trackstick to host kernel, without modifying them by
>>> touchpad. Plus I was able to tell ALPS touchpad to start "mixing" those
>>> RAW trackstick PS/2 packets with native touchpad packets.
>>>
>>> On my configuration trackstick in RAW PS/2 mode by default talks with
>>> standard bare 3 byte PS/2 protocol and touchpad in 6 byte ALPS protocol.
>>> alps.c/psmouse.ko is already able to process and parse such mixed
>>> packets. And trackstick can be switched to some extended 4 byte
>>> protocol...
>>>
>>> All this happen when passthrough mode is enabled.
>>>
>>> From my understanding it seems that in normal mode, touchpad and
>>> trackstick communicate with that 4 byte protocol and touchpad converts
>>> it into 6 byte ALPS protocol and then send to kernel.
>>>
>>> On thinkpads trackstick communicate with TPPS/2 protcol and above 4
>>> byte. So in my opinion ALPS touchpad by default cannot understand it.
>>> But you should be able to enter passthrough mode and then you would
>>> receive that TPPS/2 in alps kernel code.
>>>
>>
>> I don't really understand what you mean. Do I "just" have to set it to
>> passthrough mode? How exactly can I do that?
> 
> Look at function alps_passthrough_mode_v3(). And try to call it after
> touchpad is initialized.
>

Cool, I'll give this a try!

> You can also look which alps_command_mode_write_reg() functions are
> called for your touchpad and maybe try to figure out what those the
> registers can enabled/disable.
> 
> On http://www.cirque.com/gen4-dev-resources you can find document named
> GP-AN- 130823 INTERFACING TO GEN4 OVER I2C (PDF) which contains
> some description of those registers (in section 7).
> 
> Register C2C8, bit 0 has description "PS2AuxControl.CommandPassThruEnabled"
> 
> If trackstick is not detected, it seems you can "force" enable it by
> setting bit 7 "PS2AuxControl.AuxDevicePresent" in same register.
> 
>> Again, thank you very much!
> 
> Have you tried to read from that register which Masaki Ota talked in
> previous emails?
> 

I tried but I just didn't manage to get it to work, at all and gave up
(I really am a newbie in this whole kernel world). Maybe a fresh start
helps here.

Cheers,
Juanito


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Juanito]

[-- Attachment #1.1: Type: text/plain, Size: 3995 bytes --]



On 02/05/2018 08:48 AM, Juanito wrote:
> On 02/04/2018 09:21 PM, Pali Rohár wrote:
>> On Sunday 04 February 2018 20:39:06 Juanito wrote:
>>> On 02/04/2018 07:16 PM, Pali Rohár wrote:
>>>> On Monday 11 September 2017 13:26:30 Juanito wrote:
>>>>> Hi Masaki Ota,
>>>>>
>>>>> Thanks!
>>>>>
>>>>> On 11.09.2017 04:38, Masaki Ota wrote:
>>>>>> Hi, Juanito,
>>>>>>
>>>>>> In my information, ALPS Touchpad is used on Thinkpad E series and L series.
>>>>>> I don't know the device that is ALPS Touchpad + other vendor TrackStick.
>>>>>> But Lenovo might use ALPS Touchpad on such a combination.
>>>>>>
>>>>>
>>>>> Well, that is probably my fault, as it is not the original touchpad that
>>>>> was delievered with the laptop. I bought the touchpad (that included
>>>>> the three buttons) separately because I didn't like the clickpad that
>>>>> came with my laptop.
>>>>
>>>> Hi Juanito,
>>>>
>>>
>>> Hi Pali,
>>>
>>>> if you are still want to play with your touchpad hardware, I have a good
>>>> news for your.
>>>>
>>>
>>> Yeah! I'd love to get it to work! It's just I've been "working" on some
>>> other projects and my last kernel builds didn't work at all so I gave up
>>> and never got back to it.
>>>
>>> Thank you very much for that!
>>>
>>>> It looks like that at least ALPS rushmore touchpads allow to receive RAW
>>>> PS/2 packets from trackstick to host kernel, without modifying them by
>>>> touchpad. Plus I was able to tell ALPS touchpad to start "mixing" those
>>>> RAW trackstick PS/2 packets with native touchpad packets.
>>>>
>>>> On my configuration trackstick in RAW PS/2 mode by default talks with
>>>> standard bare 3 byte PS/2 protocol and touchpad in 6 byte ALPS protocol.
>>>> alps.c/psmouse.ko is already able to process and parse such mixed
>>>> packets. And trackstick can be switched to some extended 4 byte
>>>> protocol...
>>>>
>>>> All this happen when passthrough mode is enabled.
>>>>
>>>> From my understanding it seems that in normal mode, touchpad and
>>>> trackstick communicate with that 4 byte protocol and touchpad converts
>>>> it into 6 byte ALPS protocol and then send to kernel.
>>>>
>>>> On thinkpads trackstick communicate with TPPS/2 protcol and above 4
>>>> byte. So in my opinion ALPS touchpad by default cannot understand it.
>>>> But you should be able to enter passthrough mode and then you would
>>>> receive that TPPS/2 in alps kernel code.
>>>>
>>>
>>> I don't really understand what you mean. Do I "just" have to set it to
>>> passthrough mode? How exactly can I do that?
>>
>> Look at function alps_passthrough_mode_v3(). And try to call it after
>> touchpad is initialized.
>>
> 
> Cool, I'll give this a try!
> 
>> You can also look which alps_command_mode_write_reg() functions are
>> called for your touchpad and maybe try to figure out what those the
>> registers can enabled/disable.
>>
>> On http://www.cirque.com/gen4-dev-resources you can find document named
>> GP-AN- 130823 INTERFACING TO GEN4 OVER I2C (PDF) which contains
>> some description of those registers (in section 7).
>>
>> Register C2C8, bit 0 has description "PS2AuxControl.CommandPassThruEnabled"
>>
>> If trackstick is not detected, it seems you can "force" enable it by
>> setting bit 7 "PS2AuxControl.AuxDevicePresent" in same register.
>>
>>> Again, thank you very much!
>>
>> Have you tried to read from that register which Masaki Ota talked in
>> previous emails?
>>
> 
> I tried but I just didn't manage to get it to work, at all and gave up
> (I really am a newbie in this whole kernel world). Maybe a fresh start
> helps here.
>

Oh, oh! Currently, my touchpad is just being recognized as a PS/2
Generic Mouse.

On both debian stretch kernel (4.9.0-5-amd64) and on a 4.15.0+ compiled
by me.

I'll try to see if I can find out why this is happening.

Do have any idea why this might be the case (it used to be recognized as
ALPS)?

Cheers,
Juanito


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ALPS touchpad ot correctly recognized: GlidePoint vs DualPoint

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 4602 bytes --]

On Monday 05 February 2018 12:19:48 Juanito wrote:
> 
> 
> On 02/05/2018 08:48 AM, Juanito wrote:
> > On 02/04/2018 09:21 PM, Pali Rohár wrote:
> >> On Sunday 04 February 2018 20:39:06 Juanito wrote:
> >>> On 02/04/2018 07:16 PM, Pali Rohár wrote:
> >>>> On Monday 11 September 2017 13:26:30 Juanito wrote:
> >>>>> Hi Masaki Ota,
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> On 11.09.2017 04:38, Masaki Ota wrote:
> >>>>>> Hi, Juanito,
> >>>>>>
> >>>>>> In my information, ALPS Touchpad is used on Thinkpad E series and L series.
> >>>>>> I don't know the device that is ALPS Touchpad + other vendor TrackStick.
> >>>>>> But Lenovo might use ALPS Touchpad on such a combination.
> >>>>>>
> >>>>>
> >>>>> Well, that is probably my fault, as it is not the original touchpad that
> >>>>> was delievered with the laptop. I bought the touchpad (that included
> >>>>> the three buttons) separately because I didn't like the clickpad that
> >>>>> came with my laptop.
> >>>>
> >>>> Hi Juanito,
> >>>>
> >>>
> >>> Hi Pali,
> >>>
> >>>> if you are still want to play with your touchpad hardware, I have a good
> >>>> news for your.
> >>>>
> >>>
> >>> Yeah! I'd love to get it to work! It's just I've been "working" on some
> >>> other projects and my last kernel builds didn't work at all so I gave up
> >>> and never got back to it.
> >>>
> >>> Thank you very much for that!
> >>>
> >>>> It looks like that at least ALPS rushmore touchpads allow to receive RAW
> >>>> PS/2 packets from trackstick to host kernel, without modifying them by
> >>>> touchpad. Plus I was able to tell ALPS touchpad to start "mixing" those
> >>>> RAW trackstick PS/2 packets with native touchpad packets.
> >>>>
> >>>> On my configuration trackstick in RAW PS/2 mode by default talks with
> >>>> standard bare 3 byte PS/2 protocol and touchpad in 6 byte ALPS protocol.
> >>>> alps.c/psmouse.ko is already able to process and parse such mixed
> >>>> packets. And trackstick can be switched to some extended 4 byte
> >>>> protocol...
> >>>>
> >>>> All this happen when passthrough mode is enabled.
> >>>>
> >>>> From my understanding it seems that in normal mode, touchpad and
> >>>> trackstick communicate with that 4 byte protocol and touchpad converts
> >>>> it into 6 byte ALPS protocol and then send to kernel.
> >>>>
> >>>> On thinkpads trackstick communicate with TPPS/2 protcol and above 4
> >>>> byte. So in my opinion ALPS touchpad by default cannot understand it.
> >>>> But you should be able to enter passthrough mode and then you would
> >>>> receive that TPPS/2 in alps kernel code.
> >>>>
> >>>
> >>> I don't really understand what you mean. Do I "just" have to set it to
> >>> passthrough mode? How exactly can I do that?
> >>
> >> Look at function alps_passthrough_mode_v3(). And try to call it after
> >> touchpad is initialized.
> >>
> > 
> > Cool, I'll give this a try!
> > 
> >> You can also look which alps_command_mode_write_reg() functions are
> >> called for your touchpad and maybe try to figure out what those the
> >> registers can enabled/disable.
> >>
> >> On http://www.cirque.com/gen4-dev-resources you can find document named
> >> GP-AN- 130823 INTERFACING TO GEN4 OVER I2C (PDF) which contains
> >> some description of those registers (in section 7).
> >>
> >> Register C2C8, bit 0 has description "PS2AuxControl.CommandPassThruEnabled"
> >>
> >> If trackstick is not detected, it seems you can "force" enable it by
> >> setting bit 7 "PS2AuxControl.AuxDevicePresent" in same register.
> >>
> >>> Again, thank you very much!
> >>
> >> Have you tried to read from that register which Masaki Ota talked in
> >> previous emails?
> >>
> > 
> > I tried but I just didn't manage to get it to work, at all and gave up
> > (I really am a newbie in this whole kernel world). Maybe a fresh start
> > helps here.
> >
> 
> Oh, oh! Currently, my touchpad is just being recognized as a PS/2
> Generic Mouse.
> 
> On both debian stretch kernel (4.9.0-5-amd64) and on a 4.15.0+ compiled
> by me.

Maybe bug in kernel driver? Can you install older kernel version and
find which worked?

> I'll try to see if I can find out why this is happening.

The best way is to enable debug output and look into dmesg log why
alps.c refused to register your touchpad.

> Do have any idea why this might be the case (it used to be recognized as
> ALPS)?

There were some bugs with ALPS touchpads and IIRC all of them (expect
one) should be fixed in git. So maybe you hit it.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]