| Message ID | ada750eb-daeb-c9ae-2452-fcf027a4e704@posteo.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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) >>> -- 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
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)
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... >>> -- 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
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?
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.
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 -- 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
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 -- 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
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 >
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?
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
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
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.
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. > > > 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). Hi Juanito! Now one friend told that he bought on ebay "usable touchpad" to replace default one on Thinkpad T440 (that one without physical buttons). One which he bought is ALPS V7 and it works fine on that T440. And also trackpoint with buttons are working. He told that first time he had connected & assembled it, trackpoint have not worked. And it was because he forgot to connect something in trackpoint. So he need to disassemble it again, check, connect and assemble laptop back. So now I have confirmed that replaced ALPS V7 is working fine at least on some T440 laptops. So if you wrote that buttons (above touchpad) are working, but trackpoint not, maybe you have same problem? Forgot to properly connect trackpoint? If it is really disconnected, then ALPS touchpad is not able to detect it and therefore tell kernel that trackpoint is not available.
On 07/24/2018 06:54 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. >> >>> 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). > > Hi Juanito! Hi Pali, Thank you very much for this! > > Now one friend told that he bought on ebay "usable touchpad" to replace > default one on Thinkpad T440 (that one without physical buttons). > > One which he bought is ALPS V7 and it works fine on that T440. And also > trackpoint with buttons are working. > > He told that first time he had connected & assembled it, trackpoint have > not worked. And it was because he forgot to connect something in > trackpoint. So he need to disassemble it again, check, connect and > assemble laptop back. > > So now I have confirmed that replaced ALPS V7 is working fine at least > on some T440 laptops. > > So if you wrote that buttons (above touchpad) are working, but > trackpoint not, maybe you have same problem? Forgot to properly connect > trackpoint? If it is really disconnected, then ALPS touchpad is not able > to detect it and therefore tell kernel that trackpoint is not available. > What actually bothers me is that the buttons above the touchpad *don't* work. With Ubuntu 14.04 (I think), they definitely worked. *And* I could scroll with two fingers too. It also did work with the crappy patch I sent, although I haven't managed to correctly compile the kernel since then. I am not sure if the trackpoint ever worked because I never really cared for it. I will re-open the laptop at some point and see if there is a flying cable somewhere. Again, thank you very much for taking the time to point this out. Cheers, Juanito
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;
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: 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