On 03/10/2017 12:12 PM, Dmitry Torokhov wrote:
On Fri, Mar 10, 2017 at 10:56:33AM -0800, Andrew Duggan wrote:
On 03/10/2017 09:52 AM, Dmitry Torokhov wrote:
On Fri, Mar 10, 2017 at 04:57:35PM +0100, Benjamin Tissoires wrote:
Hi Dmitry,
On Mar 09 2017 or thereabouts, Dmitry Torokhov wrote:
Hi,
This is refresh of Benjamin's patches trying to bridge PS/2 and SMbus
devices for better support of Synaptics RMI4 touchpads (and Elans later).
Thanks!
I have some issues/comments and am still working on those. Here are some
general comments:
The main difference is that we do not have platform device, as it only
adds another indirection level, and have psmouse create SMBus companion
The purpose of having the platform device was to not have dependency
between psmouse and I2C. Right now I think that patch 6/8 will fail to
compile if I2C=m and PSMOUSE=y (I may be wrong).
This is taken care by the following guards in users if MOUSE_PS2_SMBUS:
depends on I2C=y || I2C=MOUSE_PS2
I am perfectly fine to tie psmouse to I2C *core*, we do not need to have
adapters loaded for it to work (hopefully).
directly. Because serio ports complete registration asynchronously, we do
not deadlock on psmouse_mutex when even if we have a pass-through port.
(Frankly we need to revisit this whole serio and psmouse thing, use of
global serio_mutex and psmouse_mutex is hurting us; they were needed when
driver core could not recursively iterate over device and driver lists).
Agree, this is a giant PITA.
We also do not allow overriding serio driver, instead we teach psmouse
about "special" devices and let it continue own the serio port and make
sure nobody else touches it.
To work around issue with psmouse_reconnect() running sometimes too late,
we add "fast reconnect" option to serio. Not too pretty, but gets the job
done. We may need to revisit whole serio PM story later and stop "cheating"
and pretending that device is resumed when it is not, but for that we need
to teach PM core about devices that are OK not to wait for before resuming
userspace. Anyway, much bigger topic for later.
I thought there was already the ability to say that a driver needs to be
run in a different thread for PM functions (IIRC i2c-hid uses
device_enable_async_suspend(&client->dev); and this "should" do the
trick).
The issue is that currently asynchronous resume still has to complete
before we start resuming userspace, as PS/2 is way too slow. So the
current solution marks device as resumed right away, and mouse may
become responsive 2 seconds later, but that is good as we do not idly
sit and wait but have userspace start turning on the screen and do other
useful stuff. Maybe user can already start typing their password into
screen locker.
We would need to give a way to drivers to indicate to PM core just how
asynchronous our resume can be.
This seems to be working on X1 Carbon and also not breaking my HP 1040 with
forcepad (unfortunately it seems to be using some other SMBus controller
for connecting Synaptics, as I see nothing at 0x2c when loading i2c-i801).
Well, on my T450, the SMBus connection is dead too. I can't seem to talk
to the device at all. This happens when the firmware believes it needs
to stay on PS/2 and gets completely deaf to I2C. I solved this by
calling psmouse_deactivate(), but this time, it looks like some other
function needs to be called.
I'll keep investigating and report back.
I've heard a rumors that HP 1020 uses a Microtech SMbus controller for
its touchpad, it could be that 1040 is similar.
When your SMBus connection is dead do you see anything on the bus? At
that address? Or it is completely unresponsive?
Try the I2C address 0x20 for the HP forcepad. I have gotten previous
versions of Benjamin's SMBus patches working on a similar system. It
is a HP Elitebook Folio 940 and the forcepad was at address 0x20 and
it was on the i801 bus. The HP 1020 does have a microchip I2C
controller, but thats connected to a HID / I2C touchpad. The 1020
was a one off so the 1040 should be the more common SMBus
implementation.
I also have not been able to get this patch series to successfully
switch over to SMBus mode. But, I have not had a chance to do
anything besides apply the patches and build. This is the output
from a Lenovo W541:
[ 9.674826] psmouse serio1: synaptics: queried max coordinates: x
[..5676], y [..4758]
[ 9.705273] psmouse serio1: synaptics: queried min coordinates: x
[1266..], y [1096..]
[ 9.705276] psmouse serio1: synaptics: Trying to set up SMBus access
[ 9.707946] psmouse serio1: synaptics: SMbus companion is not ready yet
[ 9.764848] psmouse serio1: synaptics: Touchpad model: 1, fw:
8.1, id: 0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x10000, board
id: 3053, fw id: 2560
[ 9.764853] psmouse serio1: synaptics: serio: Synaptics
pass-through port at isa0060/serio1/input0
[ 10.418268] psmouse serio2: trackpoint: IBM TrackPoint firmware:
0x0e, buttons: 3/3
...
[ 27.112954] psmouse serio1: synaptics: queried max coordinates: x
[..5676], y [..4758]
[ 27.142555] psmouse serio1: synaptics: queried min coordinates: x
[1266..], y [1096..]
[ 27.142559] psmouse serio1: synaptics: Trying to set up SMBus access
[ 27.169776] psmouse serio1: synaptics: SMbus companion is not ready yet
[ 27.226071] psmouse serio1: synaptics: Touchpad model: 1, fw:
8.1, id: 0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x10000, board
id: 3053, fw id: 2560
[ 27.226087] psmouse serio1: synaptics: serio: Synaptics
pass-through port at isa0060/serio1/input0
[ 27.880282] psmouse serio3: trackpoint: IBM TrackPoint firmware:
0x0e, buttons: 3/3
Yay, that works:
[ 980.124573] psmouse serio3: synaptics: queried max coordinates: x [..5676], y [..4690]
[ 980.155902] psmouse serio3: synaptics: queried min coordinates: x [1266..], y [1162..]
[ 980.155915] psmouse serio3: synaptics: Trying to set up SMBus access
[ 980.229405] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM2685-009, fw id: 1608298
[ 980.293225] input: Synaptics TM2685-009 as /devices/rmi4-00/input/input42
[ 980.305824] rmi4_smbus 9-0020: registered rmi smb driver at 0x20.
Thanks Andrew!
Cool! FYI, forcepads don't have a F30 so currently there is nothing to
report BTN_LEFT or BUTTONPAD which will probably confuse userspace about
what type of device it is. I have a patch which I worked on a year ago
for F21 which is the force function for these devices. It will report a
click when the firmware determines that a certain amount of force has
been applied. I can take a look at that patch again and submit it when I
get a chance now that we are closer to getting these device working in
RMI mode.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
