From: Ari Entlich <hidden> Date: 2015-08-06 11:07:20
Hello!
I'm an owner of a Thinkpad T440p, and was always unhappy with the
buttonless trackpad. I was ecstatic when I learned that trackpads from
the 50 series laptops, with buttons, are compatible with 40 series
laptops. I have since performed this mod, and all of the hardware
seems to be working.
The only problem I've been having is a software one. It seems that the
trackpad and trackpoint are usually arranged such that the trackpoint
is "behind" the trackpad and all communication with the trackpoint
goes through the trackpad. This allows the trackpad to provide an
abstraction of the trackpoint for OSes that don't explicitly support
it.
With my old trackpad, which was a Synaptics device, Linux would detect
the trackpoint as its own device with the TPPS/2 protocol. It seems
that it was able to do this because the Synaptics driver has support
for a "pass-through port" which allows the OS to send commands
directly to the trackpoint. However, the new trackpad that I received
is an ALPS v7 device. I see some references to passthrough support in
drivers/input/mouse/alps.c, but it doesn't appear to be used in the
same way as it is in the Synaptics driver and doesn't seem to be
supported at all for v7 devices. Therefore, instead of showing up as
its own special device, the trackpoint shows up as a "DualPoint
Stick". In general this is fine, because the trackpoint works.
However, the dedicated trackpoint driver allows you to modify a few
trackpoint-specific hardware settings, most notably the sensitivity.
This was much more of an issue before this:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=088df2ccef75754cc16a6ba31829d23bcb2b68ed
commit, but I still think it would be nice to be able to control my
hardware as much as possible.
Interestingly, I've been able to find very little discussion of this
limitation of the ALPS driver. Here are the few links that I've been
able to find:
https://bugzilla.kernel.org/show_bug.cgi?id=8864 (comment 24 seems
especially relevant)
https://bugzilla.redhat.com/show_bug.cgi?id=483224http://www.spinics.net/lists/xorg/msg49549.htmlhttp://thinkpad-forum.de/threads/185025-T*50-Clickpad-in-T*40-Trackpoint-Konfiguration
(German)
Since the trackpad that I received is from some Thinkpad model (I
don't know which one though), there presumably should be other 50
series Thinkpad users who are affected by this same issue. It could
just be that the number of people with the right device who use Linux
and want to adjust the hardware sensitivity and care enough to post
about it online is essentially zero, but I've had a hard time
convincing myself of this.
Comment 24 in the first link states that ALPS has been unwilling to
share the secret to the passthrough port for their hardware. However,
this comment is 8 years old, so I'm hoping things have changed. The
second and third links seem to be describing approximately the same
problem, with one difference being that disabling the trackpad in the
BIOS does not cause the trackpoint driver to be used for me - it only
causes the trackpad device to stop emitting events. Perhaps this is
because the buttons are now part of the trackpad device, or maybe it's
just because this is a non-standard mod. The fourth link seems to be
describing the exact problem that I'm having, however my ability to
read German is only as good as Google Translate ability to translate
it.
If there's anything that I can do to help get this implemented, please
let me know. I'd even be willing to try and figure out how the Windows
driver does this, if that becomes necessary.
Also: I am aware that sensitivity/speed/acceleration/whatever can be
adjusted somewhat through libinput settings. That is not what I'm
asking about, so please don't suggest it. :)
Thanks!
Ari
On Thursday 06 August 2015 07:07:19 Ari Entlich wrote:
Hello!
I'm an owner of a Thinkpad T440p, and was always unhappy with the
buttonless trackpad. I was ecstatic when I learned that trackpads from
the 50 series laptops, with buttons, are compatible with 40 series
laptops. I have since performed this mod, and all of the hardware
seems to be working.
The only problem I've been having is a software one. It seems that the
trackpad and trackpoint are usually arranged such that the trackpoint
is "behind" the trackpad and all communication with the trackpoint
goes through the trackpad. This allows the trackpad to provide an
abstraction of the trackpoint for OSes that don't explicitly support
it.
With my old trackpad, which was a Synaptics device, Linux would detect
the trackpoint as its own device with the TPPS/2 protocol. It seems
that it was able to do this because the Synaptics driver has support
for a "pass-through port" which allows the OS to send commands
directly to the trackpoint. However, the new trackpad that I received
is an ALPS v7 device. I see some references to passthrough support in
drivers/input/mouse/alps.c, but it doesn't appear to be used in the
same way as it is in the Synaptics driver and doesn't seem to be
supported at all for v7 devices. Therefore, instead of showing up as
its own special device, the trackpoint shows up as a "DualPoint
Stick". In general this is fine, because the trackpoint works.
However, the dedicated trackpoint driver allows you to modify a few
trackpoint-specific hardware settings, most notably the sensitivity.
This was much more of an issue before this:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=088df2ccef75754cc16a6ba31829d23bcb2b68ed
commit, but I still think it would be nice to be able to control my
hardware as much as possible.
Interestingly, I've been able to find very little discussion of this
limitation of the ALPS driver. Here are the few links that I've been
able to find:
https://bugzilla.kernel.org/show_bug.cgi?id=8864 (comment 24 seems
especially relevant)
https://bugzilla.redhat.com/show_bug.cgi?id=483224http://www.spinics.net/lists/xorg/msg49549.htmlhttp://thinkpad-forum.de/threads/185025-T*50-Clickpad-in-T*40-Trackpoint-Konfiguration
(German)
Since the trackpad that I received is from some Thinkpad model (I
don't know which one though), there presumably should be other 50
series Thinkpad users who are affected by this same issue. It could
just be that the number of people with the right device who use Linux
and want to adjust the hardware sensitivity and care enough to post
about it online is essentially zero, but I've had a hard time
convincing myself of this.
Comment 24 in the first link states that ALPS has been unwilling to
share the secret to the passthrough port for their hardware. However,
this comment is 8 years old, so I'm hoping things have changed. The
second and third links seem to be describing approximately the same
problem, with one difference being that disabling the trackpad in the
BIOS does not cause the trackpoint driver to be used for me - it only
causes the trackpad device to stop emitting events. Perhaps this is
because the buttons are now part of the trackpad device, or maybe it's
just because this is a non-standard mod. The fourth link seems to be
describing the exact problem that I'm having, however my ability to
read German is only as good as Google Translate ability to translate
it.
If there's anything that I can do to help get this implemented, please
let me know. I'd even be willing to try and figure out how the Windows
driver does this, if that becomes necessary.
Also: I am aware that sensitivity/speed/acceleration/whatever can be
adjusted somewhat through libinput settings. That is not what I'm
asking about, so please don't suggest it. :)
Thanks!
Ari
--
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
Hello,
ALPS devices does not support pass-throw mode like Synaptics devices.
But our ALPS driver is good and can detect packet from device contains
data for touchpad or trackpoint. So ALPS driver create two input devices
and send events to userspace via correct input device and userspace see
that there are two different devices (touchpad and trackstick) and not
one "combined".
Looks like that ALPS devices does not support any speed or acceleration
configuration, so everything needs to be implemented in software -- in
userspace. X drivers already have such configuration ether via xorg.conf
or runtime via xinput. Speed or acceleration can be configured per input
device, so this is something which you probably want.
--
Pali Rohár
pali.rohar@gmail.com
--
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
From: Ari Entlich <hidden> Date: 2015-08-07 13:41:09
On Fri, Aug 7, 2015 at 9:26 AM, Pali Rohár [off-list ref] wrote:
Hello,
ALPS devices does not support pass-throw mode like Synaptics devices.
Hmm... Then what are all of these references to passthrough in alps.c?
Does the alps driver use the term "passthrough" in a different way
than the synaptics driver does?
Are we 100% sure that alps devices can't do this? Is there any
possibility that we just don't know how to do it?
Thanks.
Ari
But our ALPS driver is good and can detect packet from device contains
data for touchpad or trackpoint. So ALPS driver create two input devices
and send events to userspace via correct input device and userspace see
that there are two different devices (touchpad and trackstick) and not
one "combined".
Looks like that ALPS devices does not support any speed or acceleration
configuration, so everything needs to be implemented in software -- in
userspace. X drivers already have such configuration ether via xorg.conf
or runtime via xinput. Speed or acceleration can be configured per input
device, so this is something which you probably want.
--
Pali Rohár
pali.rohar@gmail.com
--
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 07 August 2015 09:41:07 Ari Entlich wrote:
On Fri, Aug 7, 2015 at 9:26 AM, Pali Rohár [off-list ref] wrote:
quoted
Hello,
ALPS devices does not support pass-throw mode like Synaptics devices.
Hmm... Then what are all of these references to passthrough in alps.c?
Does the alps driver use the term "passthrough" in a different way
than the synaptics driver does?
For some old ALPS devices which use V1 and V2 protocols (with flag
ALPS_PASS) there is something like that. On that devices touchpad is
behind trackpoint HW. But you cannot wait for data or poll for both
devices at same time -- you need to choose if tou want to talk directly
to touchpad (via passthrough mode) or just to trackpoint. I think
because of this limitation ALPS driver implement all logic in one
driver...
Above was for old ALPS devices. New ALPS devices with V3 or V5 protocols
have trackpoint behind touchpad, so normally OS communicate with
touchpad (and not with trackstick like before). But here touchpad sends
data for both touchpad and trackstick events and so OS does not have
normal access to "hidden" trackstick.
There is a way "jump" into passthrough mode and talk directly to
trackpoint. But it is used only for configuring trackstick and currently
it is used to configure trackstick so it send data (via touchpad) in
format which is supported by our ALPS driver.
On the other hand, synaptics driver and devices support full
"encapsulation" or how can I call it of serio PS/2 device and in this
case you can use full set of PS/2 commands directly with trackstick
(behind synaptics touchpad). ALPS devices do not support something like
that.
Are we 100% sure that alps devices can't do this? Is there any
possibility that we just don't know how to do it?
Note I just wrote information which I understand from driver source code
and with "playing" with touchpads. There can be some mistakes (so
somebody can correct me), but this is how I understand this situation.
I do not have access and I have never seen any "official" documentation.
I can say, that current ALPS driver in kernel does not support it for
100% sure. But maybe we just missing some information which allows us to
do it.
But in my opinion ALPS firmware which is running in ALPS touchpad does
not support something like full passthrough to trackpoint device like
synaptics. For me it does not make sense to add such function into
firmware, because it already send all needed data for OS to allow
processing both touchpad and trackpoint data.
Questions are: Do we need full access to trackpoint hardware? Do we know
if trackpoint (used by ALPS input solutions) supports configuring speed
or acceleration in hardware? It is really not easier to do it in
software?
Thanks.
Ari
quoted
But our ALPS driver is good and can detect packet from device contains
data for touchpad or trackpoint. So ALPS driver create two input devices
and send events to userspace via correct input device and userspace see
that there are two different devices (touchpad and trackstick) and not
one "combined".
Looks like that ALPS devices does not support any speed or acceleration
configuration, so everything needs to be implemented in software -- in
userspace. X drivers already have such configuration ether via xorg.conf
or runtime via xinput. Speed or acceleration can be configured per input
device, so this is something which you probably want.
--
Pali Rohár
pali.rohar@gmail.com
--
Pali Rohár
pali.rohar@gmail.com
--
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
From: Ari Entlich <hidden> Date: 2015-08-07 16:35:35
On Fri, Aug 7, 2015 at 10:12 AM, Pali Rohár [off-list ref] wrote:
For some old ALPS devices which use V1 and V2 protocols (with flag
ALPS_PASS) there is something like that. On that devices touchpad is
behind trackpoint HW. But you cannot wait for data or poll for both
devices at same time -- you need to choose if tou want to talk directly
to touchpad (via passthrough mode) or just to trackpoint. I think
because of this limitation ALPS driver implement all logic in one
driver...
Above was for old ALPS devices. New ALPS devices with V3 or V5 protocols
have trackpoint behind touchpad, so normally OS communicate with
touchpad (and not with trackstick like before). But here touchpad sends
data for both touchpad and trackstick events and so OS does not have
normal access to "hidden" trackstick.
There is a way "jump" into passthrough mode and talk directly to
trackpoint. But it is used only for configuring trackstick and currently
it is used to configure trackstick so it send data (via touchpad) in
format which is supported by our ALPS driver.
On the other hand, synaptics driver and devices support full
"encapsulation" or how can I call it of serio PS/2 device and in this
case you can use full set of PS/2 commands directly with trackstick
(behind synaptics touchpad). ALPS devices do not support something like
that.
It looks to me like the Synaptics passthrough is implemented primarily
via the ability to write directly to the trackpoint. Events coming
from the trackpoint are implemented similarly to the ALPS driver - by
redirecting trackpoint events to the second device which the driver
creates for the trackpoint.
Note I just wrote information which I understand from driver source code
and with "playing" with touchpads. There can be some mistakes (so
somebody can correct me), but this is how I understand this situation.
I do not have access and I have never seen any "official" documentation.
I can say, that current ALPS driver in kernel does not support it for
100% sure. But maybe we just missing some information which allows us to
do it.
But in my opinion ALPS firmware which is running in ALPS touchpad does
not support something like full passthrough to trackpoint device like
synaptics. For me it does not make sense to add such function into
firmware, because it already send all needed data for OS to allow
processing both touchpad and trackpoint data.
The issue isn't so much getting information from the trackpoint but
sending information TO it. The trackpoint driver is able to send
special commands to the trackpoint to modify its behavior. As far as I
can tell, this is pretty much the only thing it does. See
drivers/input/mouse/trackpoint.c for details.
Questions are: Do we need full access to trackpoint hardware? Do we know
if trackpoint (used by ALPS input solutions) supports configuring speed
or acceleration in hardware? It is really not easier to do it in
software?
As I mentioned in my first email, I'm aware that mouse behavior can be
modified in userspace. However, that's not what I'm asking about. I
want to have the same capabilities with this device as I had with the
old one, if at all possible. And anyways, there are some things that
the trackpoint driver can do that cannot be done in software.
Ari
--
Pali Rohár
pali.rohar@gmail.com
--
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
From: Ari Entlich <hidden> Date: 2015-08-13 06:32:24
Can anybody else weigh in on this? I'm especially curious whether [1]
is still relevant, so I've CC'd the author.
Thanks.
Ari
[1] https://bugzilla.kernel.org/show_bug.cgi?id=8864#c24
On Fri, Aug 7, 2015 at 12:35 PM, Ari Entlich [off-list ref] wrote:
On Fri, Aug 7, 2015 at 10:12 AM, Pali Rohár [off-list ref] wrote:
quoted
For some old ALPS devices which use V1 and V2 protocols (with flag
ALPS_PASS) there is something like that. On that devices touchpad is
behind trackpoint HW. But you cannot wait for data or poll for both
devices at same time -- you need to choose if tou want to talk directly
to touchpad (via passthrough mode) or just to trackpoint. I think
because of this limitation ALPS driver implement all logic in one
driver...
Above was for old ALPS devices. New ALPS devices with V3 or V5 protocols
have trackpoint behind touchpad, so normally OS communicate with
touchpad (and not with trackstick like before). But here touchpad sends
data for both touchpad and trackstick events and so OS does not have
normal access to "hidden" trackstick.
There is a way "jump" into passthrough mode and talk directly to
trackpoint. But it is used only for configuring trackstick and currently
it is used to configure trackstick so it send data (via touchpad) in
format which is supported by our ALPS driver.
On the other hand, synaptics driver and devices support full
"encapsulation" or how can I call it of serio PS/2 device and in this
case you can use full set of PS/2 commands directly with trackstick
(behind synaptics touchpad). ALPS devices do not support something like
that.
It looks to me like the Synaptics passthrough is implemented primarily
via the ability to write directly to the trackpoint. Events coming
from the trackpoint are implemented similarly to the ALPS driver - by
redirecting trackpoint events to the second device which the driver
creates for the trackpoint.
quoted
Note I just wrote information which I understand from driver source code
and with "playing" with touchpads. There can be some mistakes (so
somebody can correct me), but this is how I understand this situation.
I do not have access and I have never seen any "official" documentation.
I can say, that current ALPS driver in kernel does not support it for
100% sure. But maybe we just missing some information which allows us to
do it.
But in my opinion ALPS firmware which is running in ALPS touchpad does
not support something like full passthrough to trackpoint device like
synaptics. For me it does not make sense to add such function into
firmware, because it already send all needed data for OS to allow
processing both touchpad and trackpoint data.
The issue isn't so much getting information from the trackpoint but
sending information TO it. The trackpoint driver is able to send
special commands to the trackpoint to modify its behavior. As far as I
can tell, this is pretty much the only thing it does. See
drivers/input/mouse/trackpoint.c for details.
quoted
Questions are: Do we need full access to trackpoint hardware? Do we know
if trackpoint (used by ALPS input solutions) supports configuring speed
or acceleration in hardware? It is really not easier to do it in
software?
As I mentioned in my first email, I'm aware that mouse behavior can be
modified in userspace. However, that's not what I'm asking about. I
want to have the same capabilities with this device as I had with the
old one, if at all possible. And anyways, there are some things that
the trackpoint driver can do that cannot be done in software.
Ari
quoted
--
Pali Rohár
pali.rohar@gmail.com
--
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 07 August 2015 12:35:33 Ari Entlich wrote:
On Fri, Aug 7, 2015 at 10:12 AM, Pali Rohár [off-list ref] wrote:
quoted
For some old ALPS devices which use V1 and V2 protocols (with flag
ALPS_PASS) there is something like that. On that devices touchpad is
behind trackpoint HW. But you cannot wait for data or poll for both
devices at same time -- you need to choose if tou want to talk directly
to touchpad (via passthrough mode) or just to trackpoint. I think
because of this limitation ALPS driver implement all logic in one
driver...
Above was for old ALPS devices. New ALPS devices with V3 or V5 protocols
have trackpoint behind touchpad, so normally OS communicate with
touchpad (and not with trackstick like before). But here touchpad sends
data for both touchpad and trackstick events and so OS does not have
normal access to "hidden" trackstick.
There is a way "jump" into passthrough mode and talk directly to
trackpoint. But it is used only for configuring trackstick and currently
it is used to configure trackstick so it send data (via touchpad) in
format which is supported by our ALPS driver.
On the other hand, synaptics driver and devices support full
"encapsulation" or how can I call it of serio PS/2 device and in this
case you can use full set of PS/2 commands directly with trackstick
(behind synaptics touchpad). ALPS devices do not support something like
that.
It looks to me like the Synaptics passthrough is implemented primarily
via the ability to write directly to the trackpoint. Events coming
from the trackpoint are implemented similarly to the ALPS driver - by
redirecting trackpoint events to the second device which the driver
creates for the trackpoint.
No, passthrough for ALPS and Synaptics differ. Synaptics driver exports
full serio PS/2 bus on which can be attached psmouse.ko driver with full
mouse detection (or any other serio driver) and so there can be full
TPPS/2 trackpoint.c protocol driver.
ALPS allows us for *some* protocol version passthrough data directly to
touchpad (or trackpoint) device. There is no support to exporting full
serio bus with PS/2 access to it (like for Synaptics hardware).
quoted
Note I just wrote information which I understand from driver source code
and with "playing" with touchpads. There can be some mistakes (so
somebody can correct me), but this is how I understand this situation.
I do not have access and I have never seen any "official" documentation.
I can say, that current ALPS driver in kernel does not support it for
100% sure. But maybe we just missing some information which allows us to
do it.
But in my opinion ALPS firmware which is running in ALPS touchpad does
not support something like full passthrough to trackpoint device like
synaptics. For me it does not make sense to add such function into
firmware, because it already send all needed data for OS to allow
processing both touchpad and trackpoint data.
The issue isn't so much getting information from the trackpoint but
sending information TO it. The trackpoint driver is able to send
But because we do not have direct access to serio PS/2 bus to trackpoint
hardware, we cannot use trackpoint.c driver and so trackpoint.c code is
for ALPS devices useless.
special commands to the trackpoint to modify its behavior. As far as I
can tell, this is pretty much the only thing it does. See
drivers/input/mouse/trackpoint.c for details.
quoted
Questions are: Do we need full access to trackpoint hardware? Do we know
if trackpoint (used by ALPS input solutions) supports configuring speed
or acceleration in hardware? It is really not easier to do it in
software?
As I mentioned in my first email, I'm aware that mouse behavior can be
modified in userspace. However, that's not what I'm asking about. I
want to have the same capabilities with this device as I had with the
old one, if at all possible.
Ok, which are those capabilities?
And anyways, there are some things that
the trackpoint driver can do that cannot be done in software.
What cannot be done in software? I still think that trackpoint is
"stupid" HW with firmware which doing all that magic. And I do not see
reason why something implement in firmware software cannot be done in
userspace application (or in kernel driver if it makes sense).
Ari
quoted
--
Pali Rohár
pali.rohar@gmail.com
--
Pali Rohár
pali.rohar@gmail.com
--
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 Thu, Aug 13, 2015 at 01:03:17PM +0200, Pali Rohár wrote:
On Friday 07 August 2015 12:35:33 Ari Entlich wrote:
quoted
On Fri, Aug 7, 2015 at 10:12 AM, Pali Rohár [off-list ref] wrote:
quoted
For some old ALPS devices which use V1 and V2 protocols (with flag
ALPS_PASS) there is something like that. On that devices touchpad is
behind trackpoint HW. But you cannot wait for data or poll for both
devices at same time -- you need to choose if tou want to talk directly
to touchpad (via passthrough mode) or just to trackpoint. I think
because of this limitation ALPS driver implement all logic in one
driver...
Above was for old ALPS devices. New ALPS devices with V3 or V5 protocols
have trackpoint behind touchpad, so normally OS communicate with
touchpad (and not with trackstick like before). But here touchpad sends
data for both touchpad and trackstick events and so OS does not have
normal access to "hidden" trackstick.
There is a way "jump" into passthrough mode and talk directly to
trackpoint. But it is used only for configuring trackstick and currently
it is used to configure trackstick so it send data (via touchpad) in
format which is supported by our ALPS driver.
On the other hand, synaptics driver and devices support full
"encapsulation" or how can I call it of serio PS/2 device and in this
case you can use full set of PS/2 commands directly with trackstick
(behind synaptics touchpad). ALPS devices do not support something like
that.
It looks to me like the Synaptics passthrough is implemented primarily
via the ability to write directly to the trackpoint. Events coming
from the trackpoint are implemented similarly to the ALPS driver - by
redirecting trackpoint events to the second device which the driver
creates for the trackpoint.
No, passthrough for ALPS and Synaptics differ. Synaptics driver exports
full serio PS/2 bus on which can be attached psmouse.ko driver with full
mouse detection (or any other serio driver) and so there can be full
TPPS/2 trackpoint.c protocol driver.
ALPS allows us for *some* protocol version passthrough data directly to
touchpad (or trackpoint) device. There is no support to exporting full
serio bus with PS/2 access to it (like for Synaptics hardware).
At least we do not know how to detect and activate it even if it exists.
Let's add some ALPS people to the thread: maybe they could share some
details on accessing trackpoints behind the touchpads with us.
Thanks.
--
Dmitry
--
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